AI Engineer World's Fair 2026 Day 2：Autoresearch & Keynotes

• 1

  Anthropic 由 Fable／Mythos 新世代模型開場，接著 Sonar 談以「代理中心開發週期（ACDC）」把驗證內建進流程、對抗 AI 程式碼 slop。

• 2

  Google DeepMind 兩場壓陣：用機器學習改寫程式碼推進科學前沿，以及生成式媒體模型（Omni、Veo、Nano Banana、世界模型）的爐邊對談。

• 3

  自動研究成為全天主線：Recursive 的 Eureka Machine、Prime Intellect 的自動 AI 研究基準、Weco AI 的 AIDEN、GEPA 反思式最佳化、用自動研究打造擊敗手調的 GPU kernel。

• 評測（Evals）再進化：從 LLM-as-a-Judge 走向 Agent-as-a-Judge，多場強調要量測系統行為與生產級可靠度，而非只看 benchmark；Arena 與 Artificial Analysis 則把「智慧」拿到真實世界與價格上衡量。
• Agent 的記憶與身分成為新工程題：On-device 記憶架構與主權 AI、Polygraph 的全組織程式碼視野、「日誌即代理」把 Agent 身分存進事件日誌、長時常駐 Agent 的產品化。
• 人的角色被重新定義：多場（Addy Osmani、Balazs Robert）談「AI 最後才會拿走的能力是搞清楚該做什麼」，工程師負責選擇與負責，而非親手做每一步。

“相較於 Day 1 聚焦「怎麼設計 Loop 與 Harness」，Day 2 把野心推得更遠：讓 Agent 自己做研究、自己評測、自己變強——當模型開始能改進模型，工程的重心就從「把工作做完」轉向「設計出可信、可評測、能自我改進的系統」，而人類則守在「決定要做什麼、並為結果負責」的位置。”

這是一場包含多個 talk 的錄影。點時間戳可直接跳到原始影片的該段落。

1. 1

   開幕主題演講：Fable 實戰指南——如何駕馭 Mythos 新世代模型

   Tariq Sheehipar · Anthropic

   ▶ 16:53

   Anthropic 的 Tariq Sheehipar（Cloud Code 團隊）在開幕主題演講中,以「地圖已經展開」比喻 Fable（新一代 Mythos 系列模型)的能力,並提出一份與 Fable 協作的實戰指南。核心主張是:模型是「養成」而非「設計」出來的,能力會以不均勻(spiky)的方式湧現,使用者必須主動「解放」模型與自己,同時正視這股躍進帶來的失落感,並藉此拋開傳統的取捨思維,做出更有野心的工作。

   • Fable 即將於當天稍晚推出,講者會與 Kat Wu、Simon Wilson 在 12:30 進行爐邊對談,屆時可能有更多更新。
   • 講者將 Fable 比喻為 RPG 遊戲從「新手教學」進入「開放世界」的階段:可能性大增,但也令人不知所措,因此需要一份「田野指南」。
   • 演講分成四個部分:解放 Claude(Unhobbling Claude)、找出自己的未知數(Finding your unknowns)、面對失落感(Dealing with the grief)、以及變得不講理(Being unreasonable)。
   • 一、解放 Claude(Unhobbling Claude)*
   • Anthropic 內部常說「模型是養出來的,不是設計出來的」——不是設定好要在某個 benchmark 拿 99 分,而是透過資料、回饋與運算資源,逐步、帶點有機性地培養出來,理解模型是與模型共同使用、共同學習的過程。
   • 束縛模型能力的其實是「我們」:我們給它的 harness(工具環境)與 prompt 方式,本質上反映的是我們對 Claude 理解的極限。要解放 Claude,就要更深入理解它,而目前對 Fable 的理解還非常早期,還有很多能力尚待解鎖。
   • 舉了一個「能力過剩(capability overhang)」的例子:網路上有人問為何 LLM 答不出「Alolan 系列中哪兩隻寶可夢名字結尾是 aw」(答案是 Krabby 的 Alolan 版本等),一般聊天模型答不出來,但 Cloud Code 可以——因為它會寫程式去抓取所有寶可夢名單並過濾,而不是單純用記憶推理。這說明 Claude 的聰明程度是「跳躍式、不均勻」湧現的,給它程式碼執行工具就能解鎖新能力。
   • 舉了模型演進的三個歷史案例來說明「能力躍進」不斷改變我們與模型互動的方式:
   • 聊天模型時代,大家以為要把整個程式碼庫貼進 context 才能解決編碼問題(甚至幻想要有上億 token 的 context window),但事實證明給模型 bash 工具等「手腳」,讓它自己建立、搜尋 context 效果更好——這正是催生 Cloud Code 的關鍵洞察。
   • 最近推出的 Claude Tag,解鎖的是模型「主動、多人協作」工作的能力——過去 Cloud Code 需要你主動下 prompt 才會動作,而現在 Claude 能自己「醒來」去做事,這被視為新一波 agent 浪潮的關鍵。
   • Cloud Code 最近移除了 80% 的系統提示詞(system prompt)。這反映了模型需求隨時間演變:Sonnet 3.5 new 時代最佳實踐是「小系統提示詞、少工具、多範例」;隨模型變聰明,系統提示詞變大、範例變多、工具變多、且模型會確實遵循指示;但最新一代模型反而偏好「更小的系統提示詞」——因為範例反而會限制模型,它其實比給的範例更有想像力,團隊現在盡量給「情境(context)」而非「限制(constraints)」,避免像過去那樣大量寫「不要做這個、不要做那個」。
   • Ask User Question 工具(Claude 規劃時可跳出選擇題對話框給使用者選)的能力演進三階段:Opus 4 時期幾乎無法正確呼叫這個工具,需要大量調整;到 Opus 4.5 時,講者試著要求它「像面試一樣問我 40 個關於規格的問題」,結果它真的能做到連續提問;到最新的 Opus 4.8 與 Fable,已經能直接產出一整份內嵌問題的 HTML 報告,互動方式整個升級。
   • Markdown/HTML 輸出的演進也呼應同樣的模式:一開始 markdown 只是模型單純輸出豐富資訊的方式;有了 plan mode 後,markdown 開始是「寫給使用者看」,讓你了解 Claude 即將做什麼;現在 Claude 已經能主動產出深度的 HTML 報告。
   • 講者強調理解 Claude 更像「生物學」而非「物理學」——高度經驗性、有機、規則尚未完全明朗,但背後仍有科學方法與可培養的直覺,建議用這種心態對待 Fable。並推薦 Anthropic 研究論文《The Biology of a Large Language Model》(生物學而非物理學比喻的來源),該論文設計給不同技術背景的讀者閱讀。
   • 二、找出自己的未知數(Finding your unknowns)*
   • 提出「地圖不是疆域(the map is not the territory)」的比喻:寫程式時,腦中的規劃、prompt、spec 是「地圖」,而實際的程式碼庫、真實世界、Claude 必須面對的種種限制才是「疆域」。當 Claude 在疆域中遇到地圖沒標示的狀況,就是所謂的「未知數(unknown)」——一個講者沒有事先指定、模型必須自行判斷的決策點。
   • Fable 是講者第一個真正感覺到「必須認真釐清自己的未知數」的模型——因為它會探索的範圍太大,若不先釐清,會撞上太多未知數。使用 Fable 的瓶頸其實在於「使用者能否把地圖與疆域對齊,找出未知數」的能力。
   • 提出一個 2x2 矩陣來思考問題:已知的已知(通常就是寫進 prompt 裡的內容)、已知的未知(知道自己還不清楚但尚未釐清)、未知的已知(明顯到不會特別寫下來,但「看到就知道」的東西)、未知的未知(完全沒考慮過的部分)。而 Fable 本身可以被用來幫忙找出這些未知數。
   • 講者分享六種用 Fable 找未知數的具體方法:
   • 盲點掃描(blind spot pass):例如告訴 Claude「我要在這個完全不熟的程式碼庫裡做一個新的 auth provider,幫我做一次盲點掃描,找出未知的未知,幫我把 prompt 寫得更好」。Claude 可能會發現 auth 模組裡藏著常見的坑,並可指示它去搜尋 Git diff 或 Slack 尋找相關脈絡。這個方法可以廣泛應用,例如講者最近用它來學習影片剪輯中的「調色(color grading)」新領域,認為模型幾乎在所有領域都懂得比自己多,重點只是要把知識「引出來」。
   • 腦力激盪與原型(brainstorms and prototypes):用來找出「未知的已知」,尤其適合設計類需求——例如講者自認沒有視覺美感,會請 Claude 做一個 dashboard,並給出四種風格迥異的設計方案讓自己直接反應、挑選,藉此找出言語難以描述但一看就懂的偏好。
   • 訪談(interviews):當已有初步想法後,請 Claude 反過來訪談自己,補足還沒想到或沒說清楚的地方;若能提供更多背景(例如自己的角色、專案階段),並要求「優先問會影響架構的問題」會特別有幫助。
   • 參考資料(references):給 Claude 另一份「地圖」比自己重寫一份 spec 更有效——例如直接給它一段程式碼(即使是不同語言/系統)讓它讀懂再照著做;可以是 React 元件對照 HTML mockup 等形式,講者認為這個方法非常強大。
   • 實作筆記(implementation notes):當 Fable 執行途中遇到未知數,要求它把決策記錄下來,方便事後檢視哪裡出現偏離、以及原因。
   • 事後測驗(quiz me):完成後請 Fable 反過來考自己剛剛發生了什麼,確保自己真的理解整個過程,以便撰寫 PR 說明或合併程式碼時能準確表達——講者認為「留在迴圈中(staying in the loop)」、確保自己真正得到想要的結果,是使用 Fable 最重要的一環。
   • 三、面對失落感(Dealing with the grief)*
   • 講者坦承第一次使用 Mythos 系列模型(Fable)時,同時感受到「巨大的收穫感」與「一種失落感」。
   • 回顧 LLM 出現前寫程式的艱辛:講者曾經營一家約 30 人的 YC 新創公司,團隊不斷被迫在「讓 App 變快」與「嘗試一個可能要花一兩個月的新功能原型」之間做取捨,非常痛苦。
   • 幾週前重回那個舊程式碼庫,發現過去要花好幾週的事情現在幾小時就能完成,講者形容這種反差「讓人又哭又笑」——一方面很享受親手寫程式、在腦中構築並「旋轉」整個程式碫結構的感覺,也記得無數個為除錯熬夜的深夜、花數週卡在無法運作的專案上、經歷過的多次失敗(大多數新創公司最終都會倒閉)。
   • 講者的結論是「唯一的出路就是往前走(the only way out is through)」:agentic coding、Fable 都還有很多要學,但只要努力嘗試並保持「留在迴圈中」、持續解放模型,就能走到收穫遠大於失落的另一端。
   • 四、變得不講理(Being unreasonable)*
   • Anthropic 文化中一個講者很珍視的信念是「取捨(trade-off)並非必然存在」。過去在自己公司常見的做法是列出優先順序清單、接受「這季就先做這個」的妥協;但現在的問題應該反過來問:如果就是把全部都做了呢?能不能強迫現實直接攤牌,而不是預設接受取捨?
   • 講者的個人反思是接下來要「變得更不講理」——像「好、快、便宜,選三個都要」這種過去被視為不可能的公式,在 Claude/Fable 時代其實有機會被打破,許多過去在腦中自動接受的取捨其實不必然成立。
   • 講者認為做出更有野心的工作的方法就是重新定義自己的抱負,因為「證明 agent 真的有用」的唯一方式,就是比以往任何時候都更快地做出人生中最好的作品。
   • 舉自身例子:這份簡報是講者昨晚用 Fable 花約 4 小時做出來的,他很喜歡這份成果,而且做得非常快。
   • 講者向現場 AI Engineer 聽眾喊話:世界正在看著這群人去證明 AI 不只是一時流行,而是真的能提升生產力、節省時間。講者今年的個人目標就是「更有生產力,但工作更少,把更多時間留給真正在乎的人」。
   • 講者特別提醒:「建構(building)變容易了,但創造價值(generating value)依然很難」——AI 工程師常常過度專注在建構過程與工具設定本身,但真正的目標是創造價值,這需要大量嘗試(swings)才能找到真正有價值的東西,而這正是世界期待這群工程師去證明的事。

   “「地圖並非疆域(The map is not the territory)。」”

   “「唯一的出路就是往前走(The only way out is through)。」”

   “「建構變容易了,但創造價值依然很難(Building is easier, but generating value is still hard)。」”

2. 2

   把驗證內建進流程：以「代理中心開發週期(ACDC)」對抗 AI 程式碼 slop 與技術債

   Tariq Shalqat · Sonar

   ▶ 36:04

   這場 talk 由 Sonar 的 Tariq Shalqat 主講，核心主張是：AI 程式碼生成雖然快速進步，但「產出正確」與「產出可信」是兩回事，AI slop（看似合理實則錯誤/低品質的產出）正大量累積成技術債；解方不是把驗證當事後檢查，而是把驗證（verification）內建進整個開發流程，講者提出「代理中心開發週期」（Agent-Centric Development Cycle, ACDC）作為框架。

   • 講者觀察到企業客戶普遍質疑「AGI 到底來了沒」，原因是 KPMG、EY 等大型機構都曾因幻覺內容而撤回報告，法律業也因 AI 捏造判例、案例法而惹上麻煩，顯示「產出看似正確」不等於「真的正確」。
   • 引用 METR 的數據：程式碼代理（coding agents）能完成的任務時長呈指數成長，最新 Mythos 模型（預覽版，約一個月前測試）在 50% 成功率下可完成 16-18 小時的任務；但若把準確率拉高到 80%，可完成時長大幅縮短到約 3.5 小時，顯示速度與正確率之間存在明顯權衡，而 80% 準確率對企業級應用來說仍不夠可靠（客戶 CTO 甚至說「給我 80% 準確資訊的人，績效考核大概會被扣分」）。
   • Sonar 自行對超過 4,000 個題目做模型測試，發現即便是最先進模型，功能正確性（functional correctness）表現都很好，但程式碼複雜度、bug 數量、安全性問題仍然存在且表現不穩定；例如 GPT-5.5 在複雜度控制上表現較好，但仍會產生 bug 與安全漏洞。
   • 引用卡內基美隆大學（Carnegie Mellon）的研究：使用 AI coding agent 初期會帶來 3-5 倍的生產力／速度提升，但這個效果在約 3 個月後會消退，回到使用前的水準；原因是安全問題、可維護性問題、可靠性問題、複雜度都同步上升——技術債的累積速度跟代碼生成速度一樣快，甚至更快。
   • 講者的核心論點：程式碼在小範圍是可證明的（provable），但大型程式碼庫因為龐雜的依賴與既有技術債而變得「不可證明」，因此驗證（verification）是關鍵問題；把驗證當作事後補救 vs. 內建到流程中，會產生完全不同的結果品質。
   • 提出「代理中心開發週期」（Agent-Centric Development Cycle, ACDC）框架：核心是程式碼生成（code generation），外圍需要三個環節支撐——引導（Guide）、驗證（Verify）、解決（Solve），並將其變成軟體開發生命週期的標準紀律與流程。
   • 「引導」（Guide）拆成兩部分：
   • Context（脈絡）：讓 agent 理解你的程式碼庫，不論是百萬行還是十億行程式碼，都要提供架構認知（architectural awareness）、語意導航（semantic navigation）與地圖，幫助 agent 熟悉「地形」。
   • Constraints（約束）：明確給出程式碼準則、允許/不允許使用的依賴套件、程式碼標準、護欄（guardrails）、目標架構（不只是現有架構，還有「你想去哪裡」）。
   • Sonar 昨天剛發布了名為 Sonar Vortex 的新產品，切入這個「引導」領域；測試顯示良好的 context + constraints 可大幅提升 agent 效能，並讓解決同一問題所需的 token 消耗減少超過 30%。
   • 「驗證」（Verify）的核心理念是「零信任、多層次驗證」（zero trust, multilayered verification）：
   • 零信任：每個模型都有偏見與「個性」，因此要用不同模型與技術交叉驗證，確保程式碼安全、可靠、無漏洞。
   • 多層次：結合演算法式驗證（algorithmic verification，例如資料流、控制流、已知模式的密鑰/秘密洩漏偵測）與代理式驗證（agentic verification，判斷意圖、業務邏輯、未知的未知問題），兩者融合能帶來實際成效。
   • 採用多層次驗證方法的客戶/夥伴回報：AI 導致的生產環境當機事件（AI-derived production outages）比未採用者少 44%。
   • 技術債會隨程式碼生成而爆炸性增長，因此需要主動的「已驗證程式碼維護」（verified code maintenance）流程，例如一組修復代理（remediation agents）搭配強力的驗證紀律，持續清理程式碼庫。
   • 講者強調 agent 確實在乎「乾淨程式碼」（clean code）：因為 agent 要操作程式碼庫，就必須理解它。同樣的 agentic 任務，在「乾淨」程式碼庫上執行，所需的 token 與推理算力明顯較少，且這種效益會隨時間複利累積（compounding effect）。
   • 整個系統需要設計三個循環（loop），並將 Guide-Verify-Solve 嵌入其中：
   • Agentic Loop（代理循環，藍色迴圈）：agent 在生成程式碼過程中即時獲得 context/constraints 與「in-loop 驗證」，並即時修復問題。
   • 持續改善流程（CI 驗證循環）：結合演算法式與代理式驗證來產生、審查 pull request，且審查速度必須大幅提升。
   • Evals 與品質關卡（quality gates）：確認是否真正通過檢驗標準。
   • 這三個循環（agentic loop、CI 驗證循環、程式碼維護循環）若刻意設計並以驗證為核心，會形成一個「自我強化的複利系統」——可以往正向強化，也可能往負向惡化（若忽略驗證與程式碼品質，會很快進入下降螺旋，正如卡內基美隆研究所示，效益逐漸消失）。
   • 講者舉一家大型銀行的實測案例：該銀行使用業界頂尖的 agentic 程式碼工具，導入 Guide-Verify-Solve 方法後，在 agentic loop 中問題數量減少了 92%；且這種效益不是「每個環節各自獨立提升」，而是隨著解決問題的過程（數分鐘到數小時）持續複利放大。
   • 講者最後總結建議：企業（尤其是擁有既有大型程式碼庫、數百萬行程式碼的組織）應採用 ACDC 框架，核心是把「刻意的驗證」（deliberate verification）內建到整個系統中，而不是事後補救。

   “「代理們必須理解程式碼庫才能操作它——所以是的，agent 確實在乎乾淨程式碼。」（大意整理自講者原話：Do agents care about clean code? ... they absolutely do, because the agents have to understand the code base if they're going to operate on it.）”

3. 3

   感知型代理(Perception Agents)：讓代理看見同一個螢幕、驗證自己的工作

   Anjib Arth · Amazon AGI Lab

   ▶ 54:34

   這場 talk 主張:代理(agent)在螢幕上點擊、操作的能力已經解決,但真正的難題是「端到端可靠地完成工作」,尤其是那些橫跨多個系統、無法用單元測試驗證結果的「知識工作」。講者提出「感知型代理(Perception Agents)」的概念——讓代理像人類一樣「感知-規劃-行動」,看到與使用者相同的螢幕內容,並具備驗證自己工作成果的能力,以此彌補目前代理只會執行動作、卻不會確認結果的落差。

   • 一年前最難的問題是讓代理在陌生畫面上找到按鈕並點擊;現在代理已能操作瀏覽器,甚至開始操作桌面應用程式。但「點擊」只是簡單的部分,真正的工作內容(work)仍未被解決。
   • 舉例:新員工週一報到,需要開帳號、加入 Slack 頻道、安排與同事的介紹會議、訂筆電等,這個流程通常沒有人「end-to-end」負責,且橫跨五個不同系統。代理可以做好每一個單獨步驟,但無法端到端完成,因為真正的工作藏在各個應用程式、各個步驟之間的「縫隙」裡。
   • 核心觀察:過去我們是在「教電腦使用電腦」——教會點擊、捲動、打字、呼叫 API、填表單,這些都是「能力(capability)」層面的問題,而這部分已大致解決。下一個難題是「可靠性(reliability)」,沒有可靠性就無法建立信任。
   • 講者做了一個現場自我檢驗:代理做端到端工作,大家覺得成功率大概是 60%~80%?但如果代理有四分之一的機率會「刪掉資料庫」,那使用者就再也不會用這個代理了——高成功率聽起來不錯,但對需要建立信任的場景遠遠不夠。
   • 唯一一個可靠性/信任已經有巨大進展的領域是「寫程式(coding)」。回顧演進:先是自動完成(autocomplete),接著能寫函式,現在的 coding agent 已經能自己寫程式、自己開 pull request。過去每一行 AI 生成的程式碼大家都會忍不住想讀一遍確認,現在幾乎沒人這樣做了。
   • 為什麼 coding 能率先被解決?因為程式碼「可驗證(verifiable)」——可以執行、可以測試、可以檢查,能確定它是否真的有效。可驗證性是可靠性出現的前提。
   • 但問題在於:大部分知識工作(knowledge work)乃至整個真實世界都是混亂、不可驗證的。例如:「這份報告有沒有打中重點?」「這個設計符不符合品牌調性?」「有沒有做到我真正想要的?」——這些都沒有 unit test 可以回答,驗證在這裡直接撞牆,而這正是大部分工作實際發生的地方(應用程式之間的縫隙)。
   • 講者反思人類如何處理混亂的工作:靠的是「共同弄清楚(figuring things out together)」——找同事一起開 Zoom 會議、看著同一個問題、指著系統討論,兩分鐘內就能解決,而這個過程本身並不可直接驗證。關鍵在於雙方看的是「同一個畫面」,這種「共享情境(shared context)」大幅減少了需要解釋的內容——代理目前缺的正是這個。
   • 講者借用機器人學的類比:機器人的迴圈是「感知(perceive)→規劃(plan)→行動(act)」。這個迴圈也應該套用在螢幕操作上。「感知」意味著代理要像人一樣讀取畫面本身呈現的內容(渲染出來的版面、狀態、剛發生的變化),而不是去讀取網頁背後的程式碼。
   • 目前代理與人類協作的模式仍停留在「傳統聊天機器人式」的一問一答:送出 prompt、等待、代理離開處理、回來給結果,如果不滿意就再送一次 prompt 修正,來回好幾輪。理想中應該要有一個能「即時反應」的代理——在使用者還在工作的同時,就能同步理解、給出建議,不需要等待。
   • 「感知型代理(Perception Agents)」的定義:能感知使用者所感知的內容、理解使用者意圖的代理。它的價值有三點:(1) 補全 computer use 的迴圈——現有代理只會做動作(點擊、打字、捲動),卻不會確認結果是否成功,感知型代理能讀取渲染後的畫面來確認自己的輸出,而不是盲目執行後就寄望它成功;(2) 不需要 API 或後端流程,因為它是直接讀取渲染介面(與人看到的一樣的像素與結構),而大多數日常軟體根本不提供 API;(3) 輸入方式也反過來改變——與其寫一大段文字描述想改什麼,不如直接「指出」畫面上的元素(例如:「這個標題要改」「這一段要更新」),這種訊號比純文字更精確、資訊損失更少。
   • Amazon AGI Lab 剛推出兩個開源的「perception agent harness」元件:(1) 標註工具(annotation)——用來告訴代理你想要什麼;(2) 驗證工具(verification)——讓代理有能力檢查自己的工作成果。
   • 標註工具 demo:一個 Chrome 擴充套件,使用者可以在畫面上直接框選元素(例如框住標題),說出想要的修改(例如「改成紅色」),或框選另一個元素說「字體放大兩倍」。工具會自動抓取畫面上的精確位置、樣式資訊,產生完整摘要,交給代理去實作,省去反覆來回溝通的過程。
   • 驗證工具 demo:以網頁開發為例,使用者可以在一份 design MD 檔案中描述設計規則(若尚未寫好,代理也能協助把規則整理出來)。代理會執行兩種檢查:(1) 視覺檢查(例如色彩、版面、元件是否符合品牌調性);(2) 使用者流程檢查(代理會像真實使用者一樣走過應用程式的操作流程,例如新增任務、刪除任務等)。完成後產生一份報告,列出哪些測試通過、哪些沒通過,讓使用者不用自己在深夜逐一點擊確認。
   • 感知不只限於「畫面」。講者分享了一個現場實驗:他與同事 Giovanni 在會議室裡,兩人都戴著 Bee(贊助商)裝置進行語音轉錄,討論網站設計改版的想法。轉錄出的會議摘要與洞見會被拉進系統,使用者可以直接點擊「Apply」,系統會把這些想法(例如「背景改成黃色」「標題改成紅色」「換個 emoji」)直接送給代理執行,並立即觸發驗證流程,自動產生報告(該色彩方案剛好符合原本核准的設計規則)。如果不符合規則,使用者可以選擇修改設計規範(如果真的喜歡黃色),或要求代理修正違規之處。
   • 講者強調這兩個開源元件只是「起點(the very first step)」,團隊將在開放環境中持續開發,因為這類模式需要更多人使用、建構、甚至「弄壞它」才能不斷進步。呼籲聽眾到 GitHub 上試用並回饋意見。
   • 額外資源:推薦同事 Danielle Persig(認知科學家,負責 AGI ACI 團隊)的 podcast,探討人機互動模式;另有同事 Gaurav Mishra 當天 1:30 在 computer use track 的演講「From RL to IRL」;團隊在 Expo Hall 設有攤位。

   “「你不需要一個更大的大腦,你需要的是共享的情境脈絡(shared context)。」”

   “「一旦你的代理有四分之一的機率會刪掉資料庫,你就再也不會碰那個代理了。」”

   “「可靠性之所以能出現,是因為你真的可以驗證答案——但問題是,大部分我們做的工作並非如此。」”

4. 4

   從 Pitchfork 到 Gemini：用機器學習改寫程式碼與推進科學前沿

   Benoit Schilling · Google DeepMind

   ▶ 1:16:10

   這場 talk 由 Google DeepMind 的 Benoit Schilling 主講，他從 2018 年在 Google X 發起的 Pitchfork 專案談起，說明 ML 如何從最初被忽視的「用 ML 改寫程式碼」構想，演變成今天 Gemini 等前沿模型已能達到「超人類語法生成」水準。他的核心主張是：寫程式碼本身已經不再是難題，真正的挑戰轉移到多步驟大型程式庫管理、架構設計、安全性與驗證方式；而程式碼作為一種可驗證、資料量龐大的獨特領域，最終會透過 self-play 突破訓練資料枯竭的瓶頸，並將「用程式碼做實驗」的能力延伸到化學、生物等科學前沿。

   • 講者現職 DeepMind，帶領的團隊目標是「開發讓 Gemini 在一個月到一年內變得更強所需的一切技術」——一個月太短視、一年是能合理預測的極限；團隊工作涵蓋程式碼、推理能力演化、新型網路拓撲研究，以及強化學習的基礎科學研究。
   • 團隊起源於 2018 年在 Google X 發起的 Pitchfork 專案，目標是用 ML 加速程式碼的演進，例如縮短「小修改要等三天 code review」這種拖慢開發速度的循環；當時提出時，公司內部普遍質疑「為什麼需要 ML 來寫程式碼」，也包括 Vibe coding（用英文寫程式）這種構想，講者自己當時也認為「英文不是程式語言」而嗯不看好，事後證明是錯的。
   • 講者以自身 45 年寫程式經歷（從 Apple II、Commodore 64 的組合語言，到 C++、再到 Python）類比：每次技術轉變都會遭遇「老一輩」的質疑抵抗，這種抵抗模式與業界對 AI 寫程式碼的懷疑如出一轍。
   • 他將軟體發展史分為三個階段：① 早期組合語言時代，瓶頸是機器算力，需要極致精確地榨乾效能；② 雲端時代，運算變便宜，瓶頸轉為「人腦只能同時處理 7-9 個 token 的上下文」，因此軟體工程演變成如何做模組化設計（函式庫、函式、拆解問題）；③ 現在進入 AI 前沿階段，寫程式碼不再是挑戰，真正的瓶頸是如何確保 AI 產出的程式碼「就是你真正想要的東西」——因為說清楚需求比寫程式碼本身更難，人類在近期仍將扮演「架構師」與「歸納思考」（inductive thinking，從大格局中發現模式）的角色。
   • 現況判斷：「超人類語法生成」已經達成——現在很難再看到 Gemini 寫的函式後覺得「我可以寫得更好」；但「多步驟程式庫管理」仍是前沿課題——真正的軟體工程不是寫程式碼，而是「加入一家公司才發現有 3500 萬行 PHP 程式碼、還得去改它」的那種複雜度管理能力；再往上到「架構設計」層級（如 Google 的系統架構，講者提到 Jeff Dean 是關鍵架構師），涉及硬體最佳化、安全性管理、如何讓系統十年後不留遺憾，這些都是目前前沿模型仍在推進的範疇。
   • 程式碼是很特殊的問題領域：一是資料量極大（可以直接爬 GitHub），二是「驗證」相對容易（可執行、可編譯、可跑單元測試），這正是當初做 Pitchfork 的原因。
   • 但現在訓練資料已經枯竭：講者估計目前新增到 GitHub 的程式碼有 80% 是機器生成的，人類貢獻的「新知識」逐漸見底。
   • 解方是 Self-play（自我對弈），呼應 DeepMind 一貫的做法（如 AlphaZero 完全不靠人類棋譜、純靠自我對弈就達到超人類西洋棋/圍棋水準）；前沿程式碼模型現在也能做到自己出題、自己判斷答案對錯、甚至一定程度評判架構優劣，靠海量自我對弈時數推向下一層級——講者用「把一個優秀工程師關兩年、餵披薩、要求自己出題挑戰自己」的比喻類比這個過程，這其實是一個「有多少算力、多少自我對弈時間」的問題。
   • 程式碼經濟正劇烈改變：整套軟體工程文化、基礎建設與商業模式都建立在「寫程式碼是昂貴的難點」這個假設上，但現在寫程式碼幾乎免費，代表產出的程式碼量會爆炸性成長，帶來新挑戰：① 如何在海量程式碼下維持系統整體可靠性（宏觀層面的設計與適配性）；② 人類將不再閱讀程式碼——講者預測一年內 Gemini 等模型生成的程式碼不會再被人看過，就像現在幾乎沒人再去檢查編譯器產出的組合語言一樣。
   • 安全性問題：講者提到已有模型（如 Mythos）能在既有程式碼中檢測出大量漏洞，但修補漏洞會是永無止境的過程——模型會發現一層漏洞、修補、模型變聰明、發現更深層更細微的漏洞，如此循環；因此團隊認為與其「先偵測漏洞再建議修補」，更該直接「教模型從一開始就寫出正確的程式碼」，但這極度依賴上下文，非常困難。
   • 「歸納式架構」（Inductive architecture）是另一個待突破方向：目前模型還不擅長跨領域遷移知識、或在兩個概念的交集中做演繹思考；若要用 ML 寫真正複雜的軟體系統，必須教會模型如何在面對複雜問題時做出「正確的問題拆解」（規劃能力），以取得最佳的清晰度與正確性。
   • 評測方式需要改變：講者批評現有的 benchmark（點名 SWE-bench，講者稱其為「三 bench」）只驗證程式碼能否跑出正確輸出，這只是軟體工程的一小部分；他主張需要更多開放式（open-ended）問題作為評測，例如「文字壓縮」——給模型一份 10MB 的程式碼，要求寫出最佳的無損壓縮器，損失函數是「壓縮後檔案大小＋原始碼大小」，這種問題沒有標準答案上限，會逼模型創造全新演算法。
   • 「思考不該只是 token 鏈」：現有的 chain of thought 推理方式雖然大幅提升了模型表現，但人類思考遠比這複雜，寫程式碼其實是一種很「視覺化」的活動（例如流程方塊圖、資料流動），單純把程式碼視為一串要輸出的 token 是有極限的；這也是 Gemini 從一開始就被設計為多模態模型（文字只是其中一種模態）的原因，未來模型需要學會用空間或動態表徵來思考解題。
   • 是否該為模型設計全新程式語言？現有語言如 Python 是為人類設計的，並不利於寫出安全可靠的程式碼；既然寫程式碼的「痛苦」已不存在，或許該反過來設計強型別、甚至借鏡 Lean 這類語言，讓正確性的負擔轉移到模型身上（程式證明雖有其局限，但至少能把「正確」的責任交給模型），而且產出的程式碼不必再考量人類可讀性。
   • 程式碼作為「解決問題的通用語言」正快速外溢到其他科學領域，因為用程式碼做實驗幾乎免費，這是講者認為「真正新穎突破」會出現的地方，特別點名兩個領域：① 化學——人類其實只理解化學中極小一部分，一旦分子超過 20 個原子，人類就搞不清楚它會如何反應，講者預期會出現驚人突破，甚至 1 萬個原子的組合已接近「生命」的範疇；② 生物學——大自然做了了不起的工程但完全沒寫文件，模型有能力找出人類難以察覺的關聯性。
   • 「看不見的黃金」（the gold we cannot see）：人類的認知是演化訓練出來、為了在叢林中生存而非做量子計算，因此即便人類聰明創新，仍有大量突破是人類根本「看不見/感知不到」的，講者相信 ML 提供的不同視角會讓我們發現「答案其實一直都在眼前，只是我們看不見」的驚喜。

   “「今天你用 Gemini 幫你寫一個函式，然後覺得『我可以寫得更好』——那個時代已經結束了。」”

   “「軟體工程不是寫程式碼；軟體工程是你第一天加入一家公司，發現程式庫裡有 3500 萬行 PHP，而你得去改它——那一刻你才真正理解什麼是軟體工程。」”

   “「我們建立了一整套軟體工程文化、基礎建設和產業，全都建立在『寫程式碼很難、很昂貴』這個假設上。而現在，寫程式碼幾乎是免費的。」”

5. 5

   評測(Evals)的未來：從 LLM-as-a-Judge 到 Agent-as-a-Judge 與 Signal

   Aparna Dinakaran · Arize

   ▶ 1:37:12

   這是 Arize 創辦人 Aparna Dinakaran 在評測(Evals)專場的主題演講，核心主張是：隨著 AI 系統從單純回答 prompt 演變成具備工具呼叫、推理、深度研究、多子代理長時任務的複雜系統，傳統的 LLM-as-a-Judge（固定 rubric、固定分數）已經不足以捕捉新型態的失敗模式，未來評測需要走向「用 Agent 來評測 Agent」，也就是 Agent-as-a-Judge，並發表了對應的產品 Signal。

   • Arize 每月執行超過一億次評測（100 million evals/month），平均每個團隊會跑約 12 個不同的 eval job，而頂尖團隊甚至跑超過 3,800 個不同的 evaluator。
   • 評測可分為 offline evals、online evals，以及在正式環境 trace 上跑的評測；講者強調今天要談的重點是「在 trace 上跑評測」，因為這是幫團隊發現真正問題、抓到失敗案例、並餵養持續學習迴圈（continual learning loop）的關鍵資料來源。
   • 業界（如 Anthropic、OpenAI 的 CPO/GDB、投資人 Gary Tan）普遍認同「evals is everything you need」，評測已成為每個認真做 AI 的團隊的必備投資。
   • 問題在於：當大家在打造第一代評測工具的同時，「被評測的對象」本身已經徹底改變。2023 年 AI 系統只是回答 prompt；2024 年開始出現前沿模型加入 tool call、推理（reasoning）、深度研究（deep research）；現在則是團隊在真實世界資料上跑迴圈，並啟動長時任務（long horizon task）的子代理（sub-agent）。每一次演進都是複雜度的躍升，且不只是「變難」，而是變成「本質上不同的問題」。
   • 系統越複雜，失敗的方式也越複雜。Arize 自己打造並在產品 UI 中使用的 agent「Alex」就是活生生的例子：每次前沿實驗室推出新功能，Alex 就跟進，於是它擁有更長的記憶、能動態產生 UI、能在大量 trace 中搜尋。但也因此出現新問題：會忘記上下文、不知道任務何時完成、有時會卡在迴圈裡。
   • 講者指出，關鍵在於：像 Alex 這種每次使用者互動都會產生「全新 UI」、走出完全不同軌跡（trajectory）的系統，用傳統的 LLM-as-a-Judge（固定 rubric）根本抓不住這些失敗類型，因為評測對象已經不是確定性流程（deterministic flow）。
   • 由此得出核心洞見（revelation）：「評測 agent 最好的方式，可能就是用 agent 來評測」。她強調這不代表 deterministic evals、LLM-as-a-judge 這些傳統手法不再重要，而是多了一種「解決不同類型問題」的新工具。
   • Agent-as-a-Judge 的本質是「自適應、動態分析（adaptive dynamic analysis）」，相對於 LLM-as-a-Judge 提供的是固定 rubric、固定分數；當你的 agent 每次面對使用者輸入都走出完全不同的軌跡時，就需要一種能動態分析的評測方式。
   • 講者的判斷：目前大多數團隊還停留在「deterministic evals + LLM-as-a-judge」這兩層，但評測的未來會是三者並存（deterministic evals、LLM-as-a-judge、agent-as-a-judge）。
   • Arize 正式發表 Agent as a Judge，並推出新產品 Signal：一個長時運行（long-running）的 agent，能讀取傳入的 trace，主動發現問題模式（discover patterns of issues），找出傳統 LLM-as-a-judge 那種固定 rubric 根本抓不到的問題類型。
   • Signal 抓到的實際案例包括：agent 重複呼叫同一個工具很多次陷入迴圈、軌跡效率低落（trajectory was inefficient）等細微失敗模式，這些是人很難事先想到要去專門檢測的問題。
   • Signal 的特點不只是「發現問題」，因為它具備完整分析能力，還能直接提出 PR 並附上修復方案（put up a fix）。
   • 活動宣傳：Arize 攤位在 OpenAI 攤位旁，可現場看 demo；他們也包下整個 evals track（205 室），當天會有 Termbench、Uber、Snorkel 等講者接續分享評測相關主題；當晚另有世界盃觀賽派對，可在 Luma 報名參加。

   “「What if the best way to evaluate an agent was actually with an agent?」（如果評測一個 agent 最好的方式，其實就是用另一個 agent 呢？）”

6. 6

   生產環境中的代理：OpenGov 如何打造與擴展 OG Assist(Effect、A2A、評測、沙箱)

   Gabe DeMesa · OpenGov

   ▶ 1:43:11

   這場 talk 由 OpenGov 工程師 Gabe DeMesa 分享 OG Assist 如何從零打造並擴展成生產環境中的 AI 代理系統。核心主張是：透過自建 Effect 原生 agent loop（取代原本的 LangGraph）、採用 A2A 協議定義代理間溝通規範、搭配自動化評測與人機協作機制，OpenGov 才能在複雜的政府 ERP 軟體場景中安全、快速地迭代 AI 代理能力。

   • OpenGov 是一家成立約 14 年的政府軟體公司，銷售 ERP 類軟體，涵蓋預算編列、採購、資產管理、許可證核發等模組。
   • OG Assist 是嵌在所有產品導覽列頂端的一顆按鈕，各產品團隊各自打造工具（tools）與技能（skills）來驅動這個按鈕，例如在 utility billing 產品中可直接詢問 rate codes 相關問題，代理會呼叫工具查詢該產品套件內的資料。
   • OG Assist 不只有後端能力，也有前端能力：代理可以「看到」畫面上的內容並針對頁面採取行動，例如使用者問「畫面上有什麼、下一步可以做什麼」時，代理會思考可用工具，並主動高亮畫面上可點擊的元素並說明。
   • 團隊起源故事：AI 熱潮興起後，一位 principal 成立了 AI Agents team，作者加入後 OG Assist 逐步整合進所有產品的後端與前端能力。
   • 團隊在 TypeScript 上大力押注 Effect 這個開源函式庫，它內建類似 Zod 的 schema、錯誤處理、日誌、追蹤（tracing）等功能，能幫助寫出結構更好的程式碼，也有利於架構設計與新服務的建置，講者形容這個賭注「paid off in dividends」（回報豐厚）。
   • 原本代理迴圈是建立在 LangGraph 上，但隨著團隊規模與使用場景演進，決定改用自建的 Effect Native Agent Loop，以取得對 agent loop 的完全掌控權，應對複雜的功能需求；改用 Effect 後，追蹤、結構化、併發控制、日誌等能力全面貫穿整個 agent loop，控制粒度更細。
   • 技術細節：使用 effect AI package 中的 chat 與 language model 概念，可以用 streamText 函式搭配 prompt 來實例化聊天；由於底層採用依賴注入（dependency injection），可以隨時「熱插拔」替換不同的語言模型。
   • 團隊採用 Google 提出的 A2A（Agent-to-Agent）協議來定義後端的代理路由（agent routes）及前後端共用的 schema/model，其中包含「agent card」（含名稱、描述等欄位）；嚴謹的協議規範有助於推動開發對齊，因為前後端只需遵循同一份 spec 作為契約。A2A 也支援擴展（可加 metadata）與 A2UI 等延伸功能。
   • 評測與回饋機制的核心理念是「shipping is the start, not the finish」（上線只是開始，不是結束）：用戶可透過 thumbs up/down 提供訊號，幫助團隊持續改進回應品質；同時在 CI 中建立自動化評測，針對真實的模型回應（completions）驗證是否正確呼叫了該呼叫的工具、是否達成預期行為，這些自動評測搭配用戶回饋，是團隊能快速迭代工具、技能與 harness 的關鍵。
   • 建置了「Human in the loop」機制：當代理嘗試進行需要人工核准的工具呼叫時，系統會確定性地（deterministically）中斷 agent loop，跳出 UI 讓人類選擇接受或拒絕該動作，特別針對會產生變更（mutating operation）的操作，確保人類始終掌握主導權，藉此建立信任並確保安全性。
   • 沙箱機制（Sandboxing）：每當代理嘗試執行程式碼或建立檔案時，都會在沙箱環境中進行，以此作為另一層安全防護（與 human-in-the-loop 呼應的安全設計）。

   “「Shipping is the start, not the finish.」（上線只是開始，不是結束。）”

7. 7

   尤里卡機器(Eureka Machine)：以演化思維邁向遞迴自我改進與自動化研究

   未知 · Recursive

   ▶ 1:55:57

   這場 talk 講者來自 Recursive 與 You.com，提出「尤里卡機器」(Eureka Machine) 的願景：借用演化這個曾催生生物多樣性、科技與科學進步的開放式過程，打造一套能自我遞迴改進、進而自動化科學研究的 AI 系統。核心主張是：AI 已經能寫程式且能處理越來越長的時間跨度任務，因此讓 AI 自己改進自己（RSI, Recursive Self-Improvement）才是通往「自動發明一切」的路徑，而這將是繼 AI 之後推動科學、科技與人類福祉的下一個指數曲線。

   • 演化是一個開放式（open-ended）過程，從 35 億年前的生物演化，到近幾百萬年的科技演化（狩獵、農業、科學方法、啟蒙運動、工業革命），一路推升世界的產值與人口承載量；講者認為 AI 的演化是這個大趨勢的延續。
   • 引用 Marc Andreessen 的「techno-optimist manifesto」：經濟成長唯一永續的來源是科技，沒有任何「材料問題」（飢餓、黑暗、寒冷、酷熱）是無法靠更多科技解決的；AI 不會只是搶工作，更可能大幅擴大整體經濟。
   • 用「一生之內的巨變」為例：1900 年出生的人，3 歲時萊特兄弟剛達成首次持續動力飛行，60 多年後（1969 年）人類就登月了。講者認為人類「太晚探索地球，太早探索星辰，但正好趕上打造 AI」，AI 有機會用類似 30～60 年的時間框架，從「所有任務都不如人類」進化到「在任何特定任務上都可能超越人類」。
   • 引用 Karl Popper 的科學哲學：科學理論的篩選本質上也是一種演化式的「物競天擇」——提出假說、進行嚴格的實證檢驗，能撐過檢驗的理論才會留下來。這說明「更多科學 → 更多科技 → 更多成長 → 更多人類福祉」的鏈條。
   • 引用 Stanislaw Lem 的觀察：科學的指數成長最終會被「投入人力不足」所限制——因為學科分支越來越細，很難再找到大量人力去鑽研某個極窄的子領域，這正是需要自動化科學研究的原因。
   • 「尤里卡機器」的目標是自動化幾乎所有科學領域（物理、化學、生物、神經科學、醫學、經濟學、天文物理等）的發現過程，講者提到幾個月後會出版一本書專門講這個構想。
   • 尤里卡機器有四大支柱：(1) 掌握人類已有的知識與既有發明；(2) 匯入所有科學測量數據；(3) 對於還無法測量、未知的部分，建立模擬（simulation）——只要能模擬，就能驗證，就能用 AI 求解；(4) 最終仍需要實體的工業級實驗室來執行真實世界的實驗。這四者之上再疊加一個「agent swarm」，統籌處理各種知識、數據與實驗回饋。
   • 講者提到基礎知識層的技術（網路、瀏覽器、GPU 等）都值得為 AI 重新打造一遍，例如 You.com 就在做「給 LLM/agent 用的網路搜尋」——因為 agent 可以讀取成千上萬個很長的網頁片段，而不是像人類一樣只看 10 條藍色連結加短摘要，這代表每一層技術棧都存在為超級智慧重新設計的新創機會。
   • 講者以 NLP 領域的演進類比：從語言學家手工制定規則 → 統計模型 → 神經網路自動學習詞向量與端對端訓練（反向傳播）→ 現在的統一架構（Transformer 等），一路上「把人工流程換成可學習的系統」都帶來重大進步。這是講者認為應該讓 RSI「自己建造自己」的理由。
   • 講者強調：AI 現在能寫程式，而且能處理越來越長時間跨度的任務（這種能力大約在過去 6～8 個月才真正出現），這使得 RSI 有可能對自身缺陷產生「自我覺察」並主動修正，是「真正的」遞迴自我改進的關鍵前提。
   • 真正的 RSI 定義：AI 要能自我覺察自身的不足，並對自己整個系統（從預訓練、RL 訓練到工具鏈/harness）擁有完整存取權，然後在下一版的自己身上更新整個系統——這與單純用 AI 去做「自動研究」（auto research）不同，後者只是「弱形式」，例如讓系統去改進另一個小型 AI（像 5 分鐘就能訓練完的 nano-chat）雖然令人興奮，但還不算真正的 RSI。
   • 尤里卡機器的雛形已經做出三個概念驗證（ideation → implementation → validation 三步驟），分別針對：更好的訓練、更快的訓練、更好的 NVIDIA GPU kernel。
   • 案例一 NanoChat：訓練一個 5 分鐘內完成的小型 chat 模型，指標是 bits-per-byte，社群長期努力把它做到 0.93，講者的系統跑了一兩天就做到 0.91；重點是它不只是調超參數，而是真的發現新穎方法，例如 hashed bigram / trigram embedding 表，並透過多種可學習的 gate 把它們混入注意力機制的不同 value path 中。
   • 案例二 nanoGPT speed run：系統在很短時間內就打敗了社群一年多、且已經有人搭配 AI 一起優化的紀錄，把整個流程再加快超過 2 秒，達到 70 秒，過程中同樣發現了有趣的新方法。
   • 案例三 CUDA kernel 優化：講者指出目前業界很多混合專家（MoE）模型在耗資數十億美元的大型叢集上運行，GPU 利用率卻常常只有約 30%，效率問題嚴重。他們的系統跑了幾天，就在 NVIDIA benchmark 網站的排行榜上，於各個 kernel 類別中大幅超越當前最佳成績；團隊本身並沒有專職的 CUDA kernel 專家，但仍與 NVIDIA 合作核實，排除 reward hacking 等問題後確認這些解法確實有效。
   • 講者認為智慧（intelligence）可以拆解成約 10 個不同的「維度空間」，每個維度都還有多個子維度；即使拿現有的上限來看，人類目前在幾乎每一個維度上都離智慧的理論上限「天文數字般遙遠」，暗示 AI 能力成長的指數曲線遠未到達平緩（S 曲線）的階段。

   “「Whenever I fire a linguist, my accuracy goes up」——講者借用這句機器翻譯界的老話，類比未來可能是把工程流程交給 AI 自己去做。”

   “「We're too late to explore Earth. We're too early to explore the stars, but we're right on time to build an AI」——講者對於為何此刻正是打造 AI 的最佳時機的總結。”

   “「Only now AI can actually do this because AI is code and AI can code now.」”

8. 8

   代理系統的生產級評測：從模型基準轉向系統行為與可靠性

   Nishan Gupta · Meta Superintelligence Lab

   ▶ 2:16:04

   這場 talk 主張「評測」的定義正在從模型基準測試，轉變為系統行為與可靠性的評測。講者認為傳統的離線 benchmark 已無法反映 agent 系統在生產環境中的真實表現，團隊必須像 SRE 一樣以「可靠性」而非「準確率」作為北極星指標，把評測架構從評估「答案對不對」轉為評估「系統行為對不對」。

   • Agent 系統已不只是產生答案，而是會規劃（plan）、呼叫工具（call tools）、檢索資訊、執行工作流程、與生產基礎設施互動，因此評測的問題應該從「模型是否生成正確答案」轉變為「系統是否行為正確」。
   • 業界普遍遇到的問題是：離線 benchmark 分數持續上升，但生產環境的可靠性卻依然不可預測，原因在於 benchmark 只衡量「模型能力」，而生產環境衡量的是「系統行為」。
   • Benchmark 無法捕捉的真實失敗情境包括：工具失效（tool failure）、API 中斷、context 變化、使用者行為的多樣性、以及長時間運行的工作流程；系統越自主，benchmark 表現與生產表現之間的落差就越大，結果就是「benchmark 分數很高，但生產行為不可靠」。
   • 傳統 LLM 評測只關注輸出（output），問的是「模型有沒有產生正確答案」；但 agentic 系統要求問不同的問題：「系統的行為是否正確」，這裡的「行為」包含規劃品質、工具使用、工作流程執行、失敗後的恢復能力、以及決策制定，本質上是從「評估答案」轉向「評估工作流程（workflow）」，需要完全不同的評測架構。
   • 許多團隊仍認為幻覺（hallucination）是 AI 最主要的失敗模式，但在生產環境中，幻覺其實只是眾多失敗類別之一。講者提出一個 agent 系統的失敗模式層級（hierarchy）：
   • 最底層：記憶失敗（memory failures）、檢索失敗（retrieval failures）、安全性失敗（safety failures）。
   • 往上一層：推理錯誤（reasoning mistakes）、規劃不佳（poor planning）、工具執行錯誤（incorrect tool execution）。
   • 最高層：多代理協作失敗（multi-agent coordination failures）。
   • 這正是為什麼只評測模型輸出，會錯失大多數生產環境中真正的風險。
   • 一個關鍵的思維轉變是：停止用研究者（researcher）的角度思考，開始用 SRE／生產工程師的角度思考。SRE 不是用準確率衡量成功，而是用可靠性（reliability）、可用性（availability）、延遲（latency）、成本（cost）、恢復能力（recovery）來衡量；agentic 系統也需要採用同樣的方法，目標不是最大化 benchmark 分數，而是最大化「可依賴的結果（dependable outcomes）」，可靠性才是北極星指標。
   • 講者描述一個評測架構的分層概念：
   • 中間層：以場景為基礎的評測（scenario-based evaluations），模擬真實的工作流程。
   • 最上層：生產環境遙測數據（production telemetry），這是評測訊號中價值最高的來源。
   • 一個令人意外的洞察是：最有價值的評測數據，往往來自真實使用者與真實系統的互動，而非合成測試資料。
   • 關於離線評測（offline evals）的方法論轉變：離線評測依然重要，但評測對象要從「評估 prompt」改為「評估情境（scenario）」。例如客服工作流程（customer support workflow）、程式碼生成工作流程（code generation workflow）、研究工作流程（research workflow），agent 在同一個環境中運作。衡量指標包括：任務完成率（task completion rate）、工具使用正確性（tool correctness）、規劃品質（planning quality）、以及資源使用量（resource usage）——這在大規模運作下會呈指數級增長。核心結論：agent 評測應該以「情境為導向（scenario driven）」而非「以 prompt 為導向（prompt driven）」。
   • 系統一旦進入生產環境，每一次使用者互動本身就成為一種評測訊號——講者提到這是評測方法論中最大的轉變之一（逐字稿在此處中斷）。
9. 9

   搜尋即測試時計算：小型檢索模型能否靠推論時算力變強(自動研究實驗)

   Han Xiao · Jina AI / Elastic

   ▶ 2:20:40

   本場 talk 探討「小型檢索模型是否也能像大型語言模型一樣，靠測試時計算（test-time compute）在推論階段變強」。講者 Han Xiao（前 Jina AI 創辦人，現任職 Elastic）用自動化研究 agent 整夜跑實驗來回答這個問題，發現答案並非單純的「是」或「否」：便宜的結構性改動能夠泛化到新模型與新任務，但單純堆疊更多計算量並不會帶來可靠的提升。

   • 核心提問：大型模型可以靠 test-time compute（推論時多花算力）變強，例如 best-of-n 取樣、self-consistency、verifier 重排序。Noam Brown（OpenAI）曾指出撲克 AI 多想 20 秒帶來的效果，相當於把模型放大 10 萬倍。講者想知道：這個現象是否也適用於小型檢索模型？
   • 重新框架：搜尋本身就是一種 test-time compute。建構搜尋系統時（embedding、re-ranker、multi-vector retriever、query expander 串接成 pipeline），本質上就是在推論時花更多運算來換取相關性，而非訓練更大的模型。真正的問題不是模型夠不夠大，而是能在推論時組裝多少 pipeline、以及是否划算。
   • 兩種實作層級：Version A 是「agent 在單一凍結（frozen）embedding 模型上寫小程式」，做 chunk、打分、融合等多重運算；Version B 是「agent 在固定 token 預算下組裝檢索工具（grep、embed、rerank）」。本場演講主要深入 Version A。
   • Version A 的動機：現今主流 embedding 模型（E5 Mistral、Qwen3 Embed、EmbeddingGemma、Jina Embedding V5）大多是從大型語言模型 backbone 蒸餾而來，若 test-time compute 的能力藏在 LLM 的表徵空間裡，蒸餾出來的小模型是否也繼承了這種能力？
   • 三種評分粒度的比喻：左邊是單一 cosine 相似度（一個 query 向量對一個文件向量）；右邊是 ColBERT 式的 late interaction（每個 query token 對每個文件 token）；中間則是講者所謂的「test-time compute」做法——用同一個凍結 encoder，把文件切成句子後取 max，逼近 late interaction 但不需要新模型。
   • 嚴格限制條件：只能用一個凍結 encoder，可以呼叫任意次數，但禁止重新訓練、禁止用第二個模型、禁止學習新參數。講者指出目前流行方法都違反了這些規則之一，例如 HyDE 在 query 路徑中加入 LLM 來路由、GRIT 用第二個 retriever、Meta embedding 訓練新參數——這些都被排除在外。
   • 用自動研究（auto research）取代人工設計：agent 每次修改一個檔案、跑一個小實驗，指標進步就保留變更，否則就還原，整夜重複執行，類似「爬山演算法，但用 LLM 當變異函數」。Anthropic 的 Erik（entry capacity 名稱可能有辨識誤差）形容這不是在改一個 Python 檔案，而是在寫 markdown 檔案建立一個自主研究組織的運作流程。
   • 系統架構四大部件：Proposer（基於 Opus 4.5，純粹作為變異函數，讀取目前最佳程式與 memory 檔後修改出下一版，全程無人工介入）、Program（在凍結 encoder 上運行的 Python 程式，關鍵是 embed function 即代表「運算預算」，每次呼叫代表一次運算單位；程式不能引入超參數、不能做任務路由、不能加外部模型，以強迫 agent 找出跨任務通用的方法而非針對單一任務調參）、Evaluator（每個程式在 14 個涵蓋法律、金融、長文件、長上下文、一般檢索的評估任務上跑，以相對 cosine baseline 的 ΔNDCG 加上成本比計分）、Memory（JSONL 檔記錄每個程式的分數、成本、親代與簡短心得，供下一輪 proposer 參考，形成長期累積搜尋，但偏差也會隨之累積並影響整個「家族」）。
   • 關鍵實驗設計：loop 只能看到 14 個任務，另外保留 19 個 held-out 任務完全不讓 loop 碰觸或看到，之後才能乾淨地檢驗「discovery 階段贏的方法，是否在未見過的任務上也成立」。
   • 模型設定：搜尋在 Jina Embedding V5 Nano（僅 2 億參數，多語言檢索 SOTA）上進行，選用 Nano 主要是因為體積小、能縮短每次實驗週期。held-out 測試涵蓋同系列的更大模型，以及完全不同家族的 Gemma、Qwen 模型，這些模型與 discovery 模型不共享訓練資料、backbone 或 tokenizer。
   • 運算成本定義：用 C 表示 encoder 額外前向傳遞（forward pass）的次數。舉例：「soft centroid」做法只是把已算好的文件向量取平均，不需要新的 forward pass，故 C=1；「first sentence」做法則重新 embed top 文件的第一句話，需要新的 forward pass，故 C>1。前者重用既有幾何資訊，後者則在新文字上花費運算。
   • 兩種評分規則（Rubric）對照：ComputeRubric 只在「域內表現超越先前所有程式」時才保留該程式，主動鼓勵多花運算；TransferRubric 則只在「於驗證集上有提升且沒有任何指標變差」時才保留，且完全不獎勵多花運算。兩者的驗證集皆來自 loop 可見的資料，19 個最終 held-out 任務與未見過的 encoder 兩者都不會碰到。
   • ComputeRubric 結果：144 個程式中有 12 個落在帕雷托前緣（Pareto front），運算成本從 1 倍一路拉到近 15 倍，域內分數隨之提升超過三倍，曲線非常漂亮，看起來完全符合「test-time compute scaling」的敘事——但這僅限於域內表現。
   • 這 12 個高運算程式全都只是對同一個凍結 embedding 模型做「無需訓練的重組」：chunking、打分、feedback、fusion 的排列組合。
   • 但把這 12 個程式搬到 held-out 資料集上測試，結果完全不同：ComputeRubric（粉紅線）幾乎打平在零，代表域外環境下多花運算幾乎沒有帶來任何好處；反觀 TransferRubric 訓練出的程式（藍點）全部集中在低運算成本區、且全都優於 baseline——最便宜的一個幾乎不增加任何額外運算，反而該是最貴的程式。結論：多花運算沒有帶來遷移效果，但便宜的「結構」有帶來遷移效果。
   • 用熱力圖（heat map）呈現所有程式 × 19 個 held-out 任務、4 種 encoder（3 種是 discovery 階段從未見過的）的表現：綠色代表進步，紅/粉色代表下降。整體呈現「參差不齊」的樣貌——運算大約在一半的格子上有幫助，但不穩定，平均下來效果打平，說明「多花運算」在某些地方有用，但無法可靠地泛化到所有新任務與新 encoder。
   • TransferRubric 挑出 6 個完全不同的程式，運算成本都很低（多數只比 cosine baseline 多 1.5 倍），其中最佳程式在 held-out 資料集上贏了 83%、且沒有在任何單一任務上輸過。
   • 這些高遷移性程式的作法：只用既有的 query 和文件向量，疊加一些便宜的數學運算，例如把 query 向量微調偏向它已經喜歡的文件，或在向量空間挑幾個方向沿著這些方向重新打分。都是很小的結構性改動，卻足以把正確文件的排名往上拉。這些改動全是「重組」而非引入新模型，且在 discovery 階段只用 Jina Embedding V5 Nano 訓練出來，卻在全部 4 種 encoder 上都帶來正向提升，尤其在完全沒見過的 Gemma 與 Qwen 家族上提升幅度最大，證明這不是單一模型的怪癖，而是通用的 embedding 幾何特性。
   • Version A 結論：凍結 encoder 加上便宜的結構性改動，確實會「scale」；但單純堆運算量並不會「scale」，而自動研究正是發現這個現象的方法。
   • Version B（pipeline 層級）：講者從 2025 年的「deep research / agentic search」單迴圈網頁搜尋產品，演進到 2026 年需要實作、沙箱、評測、長時間執行（數小時）的長程任務，兩者都需要在測試時投入更多迴圈與運算。為研究這個層級的 test-time compute，講者開源了三個專案：
   • DataRoom：給定 token 預算，agent 反覆搜尋、閱讀、寫入，最終把所有內容打包成一個 zip 檔（該 zip 檔即為蒸餾過的網路語料庫，供下一個 agent/LLM 使用）。命名靈感來自講者當創辦人時「為投資人準備 data room」的經驗。其 token 經濟邏輯是：用便宜的小語言模型 token 來探索網路、建構語料庫，把昂貴的前沿模型 token 留到之後真正需要時使用。
   • SearchBox：用來研究 agentic search 與工具呼叫（tool-calling）的測試平台，刻意設計成「氣隙」（air-gapped，agent 無法連網），相當於把 agent 關在房間裡，給它一個 data room 並要求它回答問題。agent 必須在測試時自行組裝由 grep、embed、rerank 等本地工具構成的搜尋 pipeline。可用來探索：agent 最先會使用哪個工具？「grep 就夠了嗎？」強迫多花運算是否對難題有幫助？agent 是否會建立可重複使用的搜尋 pipeline？
   • Knowledge Graph：把語料庫（data room）轉成知識圖譜，每個事實變成一條從主詞連到受詞的邊，再從圖上尋找最長路徑，這些長鏈就變成「單一段落無法回答」的多跳（multi-hop）問題，逼迫 agent 花更多測試時運算把事實串連起來才能得到答案。這也是建構私有 verifier 的工具。
   • 總結整合：Version A 發現了針對凍結 embedding 的特殊「向量代數」可以提升搜尋相關性；Version B 建構了完整技術棧來找到最佳搜尋 pipeline——用 DataRoom 最大化召回率（recall）、用 SearchBox 最大化精確率（precision）、用 Knowledge Graph 建立評測基準，最終得到一個具強大搜尋相關性的 pipeline。兩個層級的共通信念是：把賭注押在「測試時多花運算」，而不是「訓練更大的模型」。
   • 收尾主張：搜尋本身就是 test-time compute，不要一味追求更大的模型，改在推論階段做更多搜尋；而且不需要靠人工逐一設計，自動研究（auto research）可以在一夜之間幫你發現這些方法。

   “"Search is already test time compute."（搜尋本身就是一種測試時計算。）”

   “"More compute did not transfer. The cheap structure did."（多花運算沒有帶來遷移效果，便宜的結構性改動才有。）”

   “"Don't reach for bigger model, do more search at inference instead."（不要一味追求更大的模型，改在推論時做更多搜尋。）”

10. 10

    從規格生成量身打造的實作：Durable Execution 與軟體工程的極簡未來

    Dominik Tornow · Resonate

    ▶ 2:41:10

    這場 talk 由 Resonate 創辦人 Dominik Tornow 主講，主張隨著 coding agent 能力提升，「通用實作（generalpurpose implementation）」將逐漸被「按需生成的量身打造實作」取代，軟體工程的可重用單位會從「實作」上移到「規格（specification）」。他以 Resonate（durable execution 平台）和 NATS.io 的合作為案例，說明如何讓 agent 從單純「寫程式」進化到「參與系統設計」。

    • 核心理論：軟體重用的層級會往上游移動——過去我們重用「通用實作」（函式庫、框架、平台），未來會重用「規格」，再由 agent 針對現有基礎設施衍生出「量身打造的實作」。這意味著我們不必再新建一個新的 library/framework/platform，而是把既有基礎設施做最小延伸即可。
    • 「prompt 就是平台（the prompt is the platform）」：只要有規格，就能請 agent 針對不同基礎設施各自生成客製化的實作。
    • Resonate 目前有 server 端參考實作，以及 TypeScript、Python、Rust、Go、Java 五種 SDK 實作。
    • 公司價值觀的轉變：如果實作可以被生成，那麼公司的價值就不再是「實作」本身，而是「規格／協定（protocol）」。因此 Resonate 重新定義自己的產品：產品不是實作，而是協定；再從協定衍生出多個 server 實作——一個是通用參考實作，其他則是與基礎設施夥伴共同打造的版本，讓客戶能在既有基礎設施上以最少額外依賴獲得 durable execution。
    • 問題因此從「我們能不能造出一個 server？」變成「我們能不能從同一份規格反覆合成出可信任的 server？」以及「該怎麼做到？」
    • 講者特別強調：多數人談 agentic engineering 只關注「驗證（verification）」——如何確認結果正確；但這場 talk 聚焦在「規格」本身，以及 agent 能否參與「定義規格」，而不只是建造或驗證系統。
    • 合作夥伴案例：Resonate 與多家基礎設施供應商合作，其中之一是 Synadia（NATS.io 開發商，一款開源訊息系統，用於打造現代分散式系統）。本場 talk 以「Resonate on NATS.io」作為案例，說明從規格到實作的流程。
    • 心智模型的修正：一般人認知的 agent 編碼流程是「agent → 規格 → 實作」的單線流程，這對很多應用已經足夠，但不適用於 Resonate 的目標——因為他們要從同一份規格生成多個「目標特定（target-specific）」的實作。因此規格必須完全抽象，不能預設任何具體實作細節：不能假設具體的資料庫 schema 或索引、不能假設關聯式資料庫的 table/transaction、不能假設 key-value store、不能假設弱一致性或強一致性。只有「實作」才能是具體的，「規格」必須維持抽象。
    • 第一次嘗試失敗的案例：直接請 agent「用 Rust 在 Postgres 上建一個 Resonate server」，結果失敗。因為「抽象規格」與「具體實作」之間的落差太大，agent 生成的系統只能通過 happy path 和基本測試，但在併發（concurrency）、程序失敗（process failure）、網路失敗（network failure）情境下就會壞掉——比較像原型（prototype），而非可上線的正式系統（production system）。
    • 修正流程：在「抽象規格」與「具體實作」之間插入一個中介產物——「具體規格（concrete specification）」。這份具體規格是由人與 agent 互動衍生出來的，但主要驅動者是人類。以 Postgres 為例，具體規格要把所有目標特定的決策明確寫下來：資料 schema、索引、SQL 查詢、transaction 邊界。這些決策一旦寫清楚，agent 就真的能實作出正式上線等級的系統。
    • 但這個流程也暴露出限制：agent 幫忙「建造」了系統，卻沒有幫忙「設計」系統。如果規格本身要成為可重用的產品，這樣還不夠。
    • 下一步：讓 agent 往上游移動，參與設計。在打造 Resonate on NATS.io 時，團隊把問題從「agent 能不能造出正式系統？」改成「agent 需要什麼條件，才能先設計系統、再建造系統？」
    • 具體做法：給 agent 存取一個「確定性模擬環境（deterministic simulation environment）」，並交付不同任務——不是直接建造正式系統，而是先建造一個「模擬實作（simulated implementation）」。這個模擬實作本身不是產品，而是「可執行的設計（executable design）」，目的是在偏序（partial order）與部分失敗（partial failure）的情境下，探索出正確的演算法。
    • 完整流程因此變成四個階段：抽象規格 → 模擬實作 → 具體規格 → 具體實作。等演算法在模擬環境中被發現、測試並驗證後，才請 agent 撰寫具體規格；再之後才請 agent 撰寫正式的具體實作。這是 agent 真正「往上游移動」的關鍵節點——人類依然參與設計過程，但這次由 agent 擔任驅動者。
    • 讓這一切成立的兩個要素：極簡主義（minimalism）與簡潔性（simplicity）。但講者強調，這兩者不是起點，而是終點——Resonate 團隊花了三年時間持續把協定做得更小、更簡單。每次遇到問題，就自問：「能拿掉什麼？」「哪個抽象可以刪除？」「哪個屬性可以移除？」「哪個關係可以打破？」
    • 最終成果是一個非常精簡的協定，核心只圍繞兩個物件：durable promise（持久承諾）與 durable task（持久任務）。
    • 簡潔性之所以重要，是因為即使是「簡單」的併發式分散式協定，其狀態與行為空間也可能非常複雜——換句話說，即便建立在少數簡單原語（primitives）之上，要正確實作這些協定依然是件困難的事。

    “「In 2026, coding agents will quietly retire their first software platform. Not because it's bad, simply because the platform is unnecessary.」”

    “「At this point, the prompt is the platform.」”

    “「Our value moves from implementation to specification.」”

    “「Unfortunately, minimalism and simplicity are not the starting point. They are the finish line.」”

11. 11

    長時研究代理的記憶架構(On-device)與主權 AI

    Stefania Druge · Sakana AI

    ▶ 2:50:53

    這場 talk 探討長時研究代理（long-horizon research agents）面對「context bloat（脈絡膨脹）」的問題，講者 Stefania Druge 分享她在本地（on-device）Mac 上，用 QWEN2 7B 與 DeepSeek V4 Flash 兩個模型，設計並實驗一套「記憶治具（memory harness）」的成果，並藉此論證本地模型與資料主權（sovereign AI）在此類長任務上的可行性與價值。

    • 長任務常見的失敗模式：模型會自相矛盾、重做已完成的工作（因為忘記做過），或逐漸偏離使用者原本的問題（因為忘記問題本身），這些都源自 context 隨任務拉長而「腐化（rot）」。
    • 根據 METER 的預測趨勢，未來模型要處理的任務時長（horizon）會越來越長，但模型發布的頻率卻越來越低，兩條曲線今年稍晚會交會，屆時「處理長任務」與「記憶治理」會變成更迫切的優先事項。
    • 選擇在本地模型上解決此問題，部分靈感來自 Coinbase CEO 近期（僅兩天前）的一則貼文：該公司轉用更多本地模型、搭配更好的路由（routing）、快取（caching）、保持 context 乾淨、以及更好的使用可視性，成功在提高 AI 使用量的同時降低了 AI 支出。
    • 本地模型正快速跨過「堪用」的門檻：GLM 備受關注（尤其在 Fable 停止服務後）、DeepSeek V4 Flash 可在 M3 Ultra 上運行；RAM 仍是主要瓶頸，但本地模型已能勝任具代理性質（agentic）的工具使用任務。
    • 實驗設備：一台 Mac Studio（M3 Ultra，96GB 統一記憶體、28 核 CPU），持續跑評測數天，機器發燙到需要用電風扇散熱，講者用手機遠端操控，即使在飛來會場的飛機上也在跑評測。
    • 使用的兩個模型：QWEN2 7B（4-bit 量化）與 DeepSeek V4 Flash，且這兩個模型是所有實驗中「固定不變」的變數，唯一改變的是記憶治具裡的召回（recall）策略。
    • 記憶心智模型：不要把記憶只當成「資料庫存取」，而應視為圍繞模型的一個「write（寫入）→ manage（管理）→ read（讀取）」控制迴圈。
    • 治具架構設計：
    • Research agent 本身刻意設計成沒有持久記憶的小型代理，所有記憶能力都來自外部治具。
    • 中間有一個「core（核心）」區塊，永遠把 traces（歷程紀錄）攤在代理眼前。
    • 一個「recall（召回）」區塊，用來測試不同的召回模式。
    • 一個「archival（歸檔）」區塊，負責跨 session 保存資訊。
    • Recall 區塊測試的「政策階梯」（policy ladder），由弱到強依序為：
    • Baseline：完全不用記憶、不做召回。
    • Vector RAG：用向量相似度做召回，看治具會撈出什麼。
    • Decisions ledger（決策帳本）：在每一輪都記錄「做了什麼決策」，之後可依此排序、優先化。
    • Oracle（神諭/標準答案）：每一輪都直接告訴治具「正確答案是什麼記憶」，作為 ground truth 對照組。
    • 第一個測試任務：文獻回顧（literature review），語料庫中放入一篇引用大量論文、包含一個重大科學主張的 Nature 論文——聲稱發現了 742,000 種有潛力的新材料，這個驚人主張後來遭到撤回（retraction）。撤回訊息在語料庫裡是遠比原始頭條與引用文獻小得多的「大海撈針」目標，用來測試系統能否找到正確答案。
    • 第一個任務的結論：因為所有論文和相關資訊本身就能塞進 context window，加不加記憶治具效能一樣，記憶治具只多花了成本卻沒有增加能力——結論是「當任務本身就塞得進 context 時，治具幫不上什麼忙」。
    • 第二個任務：使用已建立的長任務記憶 benchmark「Xbench」。範例問題的正確答案出現在第124步，但提問是在第500步才問，答案早已超出 context window 範圍，模型必須依賴記憶治具去精準檢索出那一步的資訊。
    • Xbench 實驗結果：使用「rank 排序式召回（ranked recall）」比不用記憶更常得到正確答案；在68道題目、每題多個 cell 與多組隨機種子的分解分析中，「僅用 rank ledger（決策帳本排序）」的表現最好，甚至超過只做「是否需要用記憶」的簡單門控（gating）判斷。
    • 有趣的反直覺發現：作為「標準答案」對照組的 Oracle 並沒有達到最高分——因為 Oracle 只是把正確記憶「餵給」模型，但不強迫模型使用它，模型仍可能拿到正確記憶卻檢索錯誤資訊、忽略它或被搞混。
    • 講者做了大量消融實驗（ablation），測試給任意範例、給錯誤步驟、給最近步驟等情況，結果始終是「rank 排序式召回策略」表現最佳；此結論在多個模型（QWEN2 7B、DeepSeek V4 Flash）與多個 benchmark（Xbench、Spider v2）上都成立。
    • 成本面的關鍵發現：好的召回策略不只帶來更好的表現，還「更省成本」；反之「差的記憶反而更貴」，因為會多花 token，還可能把代理帶偏方向。因此好的結構化召回策略能大幅節省 token 與預算。
    • 給聽眾的建議：把「recall policy（召回策略）」當成一個一級指標（first-class metric）來看待，並認真思考——要儲存哪些類型的記憶？如何排序（rank）它們？如何設計召回函式（recall function）？在反覆多個 session、多次執行後，哪些記憶會「存活」下來？
    • 記憶技術的版圖很豐富：Diamond 開源的 repository 中就有超過30個可執行的 cookbook；記憶涉及短期、長期、不同認知技術與評測結果，解決方案光譜從簡單的檔案系統檢索一路到訓練專門的記憶模型（memory models），從低結構化到高度結構化都有,這是一個會持續發展的研究領域。
    • 選擇在本地模型上做這些實驗,對講者而言等同於一種「主權（sovereignty）」的展現——她能完全掌控資料、完整的運算軌跡（compute traces）與評測過程。
    • 代價也很真實：這些本地模型（尤其 DeepSeek V4 Flash）不支援批次查詢（batch querying），只能序列（serial）執行，所以評測跑得很慢,這也是為何她需要讓機器在東京持續跑好幾天,甚至在來會場的飛機上都在跑。
    • 講者所屬的 Sakana AI（總部日本）認為主權 AI（sovereign AI）在當下比以往任何時候都更重要,這次本地記憶治具實驗正是這個更大生態系願景的一部分,同時她也提到 Sakana AI 正在招募人才,歡迎有興趣加入日本團隊的人與她交流。

    “「Bad memory is expensive, because it spends more tokens, and it can send the agent the wrong way.（差的記憶治具是昂貴的，因為它會多花token，還可能把代理帶往錯誤的方向。）」”

12. 12

    AI 最後才會拿走的能力：搞清楚該做什麼——人際與分析師技能的新經濟

    Balazs Robert

    ▶ 3:03:37

    這場 talk 主張:在 AI 讓「寫程式」不再是瓶頸的時代,真正稀缺、AI 最後才會取代的能力,是搞清楚「該做什麼」——也就是釐清需求、與利害關係人溝通、判斷什麼才值得打造的分析師/商業顧問技能。講者 Balazs Robert 以自己 30 年橫跨業務、IT、開發之間的「橋樑」經驗,說明如何用 story mapping、VAD(Value-Architecture-Design)等老派分析工具,搭配 AI 產出更有價值的軟體。

    • 開場案例:公司年初辦內部黑客松,產出 21 個 agent 構想,其中 17 個因為沒有資料存取權限或根本沒有商業意義而被放棄,只有 4 個真正對現在的工作方式產生重大影響——說明篩選「值得做的事」比技術執行更關鍵。
    • 講者背景:過去 30 年一直扮演業務與 IT/開發之間的橋樑,從撰寫功能測試、規格書,到擔任大型 ERP/CRM(美國、英國)的功能顧問,後來創立 Visual Labs,訓練團隊如何萃取需求並轉化成給開發者、顧問甚至現在給 AI 使用的規格。
    • 核心觀察:過去兩三年最大的轉變是——能不能寫程式、取得程式碼不再是軟體開發生命週期的瓶頸;真正的瓶頸變成能否約到對的利害關係人、進到會議室、花時間萃取出正確需求。「你可以 prompt 你的程式碼,但你不能 prompt 一個會議室(you can't prompt a room)」。
    • 用福特(Henry Ford)的類比說明 AI 的侷限:如果只問使用者要什麼,他們會說要「更快的馬」;福特造的是車。AI 本質上被訓練成給出「最常見」的答案,若只靠 AI 讓現有東西變好,很容易只是在複製既有模式,而不是產生質變。真正的工作是引導 AI 跳脫「平均值」,做出「車」而不是「更快的馬」。
    • 因此,現在最重要的技能變成「分析師工具箱」:story mapping(故事地圖)、business model canvas(商業模式圖)、value canvas(價值圖)等設計思考/功能顧問常用的老工具。
    • 深入介紹 story mapping 的用法:以客服系統為例,先畫出流程骨幹(contacting → triaging → resolving → closing),在高層次上理解顧客/使用者在每個階段做什麼,再往下拆解出各階段底下的 user stories。
    • 用 story map 決定 MVP 的做法:第一層挑出「capturing intent(擷取意圖)」「classifying urgency(分類緊急程度)」「drafting a grounded answer(草擬有根據的回答)」「logging to a system of record(記錄到正式系統)」這四個 user story 作為 MVP;下一層像是「reading sentiment(判讀情緒)」「writing to team(通知團隊)」「suggesting next action(建議下一步)」「checking satisfaction(確認滿意度)」則放入 backlog。
    • User story 撰寫建議依循經典結構(persona、what、need、why),例如:「身為 support lead,我需要依緊急程度排序案件,才不會漏掉需要升級處理的案子」。強調這種結構化寫法對 AI 特別有效,因為 AI 本身就是在大量 user story 語料上訓練出來的,用它熟悉的格式溝通,產出結果會更好。
    • User story 應搭配 acceptance criteria(驗收標準),可據此推導出 test case;再把多個 user story 串接起來(daisy chain),就能組成一致的系統規格,進而變成程式碼——強調「軟體開發生命週期本身沒變,變的是我們使用的工具箱」。
    • 提出釐清需求的四個關鍵問題:
    • Whose problem is this?(這是誰的問題)——要能指名到具體的 persona。
    • What does winning look like for them?(對他們來說「成功」是什麼樣子)——他們何時算是達成正確結果,能不能又快、又順、又安全地幫他們達成。
    • What would make them refuse to use it?(什麼會讓他們拒絕使用)——例如平台不支援、操作繁瑣、資料安全疑慮等。
    • Would it change a decision?(它會不會改變一個決策)——理想上要能影響使用者的決策,並讓他們做出更好的決策;要能講清楚改變的是「哪個」決策。
    • 建議把這四個問題的答案寫進一份 markdown 檔案並放進 repository,讓 AI 能存取,取得更多上下文;強調如果只下一個很籠統的指令(例如「幫我做一個處理客服的 agent」),不會得到想要的結果。
    • 提出 VAD(Value → Architecture → Design)思考框架:先理解價值如何被創造、價值是什麼、顧客真正在乎的價值是什麼;接著理解支撐這個價值的既有流程(process);最後才進入設計階段,設計出最能支撐該價值與流程的系統,並思考流程本身需要哪些調整。
    • 承認這套方法本質上「就是老派的產品管理(product management)」,但強調這門老手藝現在變成新的「模式(mode)」——因為大家都能取得同樣的 AI 模型幫忙寫程式,真正的差異化來自誰更能理解商業需求,所以是「old skill, but new economics(舊技能,新經濟)」。
    • 講題呼應此框架:這是一場關於分析師工具箱(analyst's toolkit)全面回歸、成為 AI 時代最後護城河的演講,原訂還要接著講「打造錯誤的東西會是什麼樣子」,但逐字稿在此處中斷。

    “「You can't prompt a room.(你無法 prompt 一整個會議室)」”

    “「If you're just using AI to make things better, the chances are that you are replicating what already exists, because AI by definition is coded to give you the most common answers.」”

    “「It's old skill, but new economics.(這是舊技能,但新經濟)」”

13. 13

    在開放環境衡量遞迴自我改進：前沿模型的自動化 AI 研究基準

    Eli · Prime Intellect

    ▶ 3:15:08

    這場 talk 介紹 Prime Intellect 如何用「speedrun」（極速訓練競賽）作為開放式基準，衡量前沿 AI 模型（Codex、Claude Code、Kimi 等）自主做 AI 研究的能力，藉此探討「遞迴自我改進」是否真的迫在眉睫。講者強調這件事必須在開放環境中進行第三方驗證，而非只靠大型實驗室自說自話。

    • 大型實驗室聲稱「遞迴自我改進」（模型在無人介入下自我訓練改進）即將發生，但目前沒有任何基準能量化驗證這個說法，尤其缺乏非大型實驗室的第三方基準。
    • 講者認為理解模型做研究的能力很重要，因為未來幾年大量科學研究會依賴 AI 工具，不只限於 AI 研究本身。
    • 靈感源自 Andrej Karpathy 的專案：90 分鐘內從零訓練出達到 GPT-2 損失水準的模型。社群接手後成立 modded-nano-gpt 專案（由 Keller Jordan 主導），兩年內把時間從 90 分鐘壓縮到 45 分鐘，最終不到 2 分鐘就能達到 GPT-2 驗證損失。
    • Prime Intellect 採用 speedrun 作為評測環境，遊戲規則是在最短時間內達到目標損失，唯一限制是訓練和驗證資料必須一致（NanoGPT track 可任意改架構/注意力機制/MoE 等）。
    • 幾個月前新出現「optimizer speedrun」：只能調整優化器相關參數（例如從 Adam 換成 Mew、Shampoo 等），不能動架構，因此更偏研究導向而非工程調優。
    • 選擇 speedrun 當環境的三個理由：(1) 是很好的評測環境；(2) 也是很好的訓練環境，因為能給出明確獎勵（打破紀錄為正獎勵，否則為零/負）；(3) 每次訓練只需 15-20 分鐘，規則清楚，適合驗證是否真的有突破性發現。
    • 兩個月前的實驗：讓 Codex（GPT-5.5 + XI）和 Claude Code（Opus 4.8 + XI）在自家叢集上自由跑 optimizer speedrun，分成 V1/V2/V3 版本（V3 是發布前一兩天因為自家 agent 已不是最佳紀錄保持者而重啟，讓 agent 吸收人類最新紀錄後改進）。
    • 另設「novelty track」，要求只能用全新想法打破紀錄，結果對模型來說明顯更難。
    • Harness 很簡單，用一個 goal.md + agents.md 定義規則，agent 提出想法後透過 SLURM 的 sbatch 提交任務（用「preemptible」權限，若別人要用該節點,模型的任務會被搶佔）。用統計門檻驗證新紀錄是否為真突破而非隨機/種子優化。
    • 行為觀察：Claude Code 每 9-10 小時就會停下說「我無法再改進了」,需要人工介入喊「continue」才會繼續，導致約 1/3 時間處於閒置；Codex 幾乎不間斷工作、不問問題。
    • 兩者都會寫「scratchpad」（活躍記憶）：Codex 寫得多、風格像機器人式條列決策；Claude 寫得少但充滿表情符號、語氣興奮。
    • Codex 產生更多子代理（subagent）、消耗更多 token（總計約十億 token，但有輸入快取所以並非全是輸出 token），因為只有約 25 萬 context window，所以壓縮（compaction）頻率很高（約每小時 20 次），Claude 幾乎每小時不到一次。
    • 主要結果圖：白色代表人類紀錄進展，橘/紅色代表 Claude，藍色代表 Codex。多數時間 Claude 和 Codex 都優於人類紀錄，Claude 在早期進步特別快。兩個模型都能隨時抓取人類最新紀錄並在此基礎上改進（V3 重啟時就是這樣做）。最終結果：當時最佳人類紀錄約 2990 步，Codex 比它好約 20 步、Claude 比它好約 50-60 步。
    • 目前正在做但尚未發布的下一階段：更嚴謹的基準測試，設三種賽道——(1) 完全無外部資料，只靠模型權重內建知識；(2) 只能查閱 arXiv 論文；(3) 完全開放，包含人類最新紀錄；並分別套用在 NanoGPT track 和 optimizer speedrun 上，且要多個種子（seed）確保公平比較。
    • 新一輪 optimizer speedrun 實驗跑了近 5-6 天，參賽模型包括 Codex、Kimi、Claude、GLM（GLM 尚未跑完）。Claude 表現持續強勁；Kimi（Kimi K2.7 code）出乎意料地有競爭力，在第 4 天出現「突破式」躍進打破 Codex 紀錄；Claude 的進步曲線比較漸進、Kimi 呈現階梯式跳躍。
    • 若改用「輸出 token 數」而非時間作為 x 軸，故事會不同：Claude（Max plan）消耗的 token 遠多於 Codex 和 Kimi，而 Kimi 在單位 token 效率上表現非常突出。
    • 模型使用文獻的方式也不同：Claude 大量搜尋論文，甚至找到其他模型都沒發現的一篇論文，並靠它拿到當時最佳紀錄。
    • 講者強調一個重要觀察：原本預期模型會提出前所未見的創新優化器，但實際上沒有——模型只是巧妙地把既有論文方法「+1」式組合改進，並未真正發現新的優化器或機制，顯示即使是人類研究者花數天到數週就能想到的「不算太難但也不算簡單」的東西，目前模型仍做不到。
    • 基於此，Prime Intellect 認為需要改造成更偏「發現導向」而非「純評測」的系統，靈感來自 Google 的 AlphaEvolve：多代理系統中有多個「生成者」（含閉源與開源模型，開源模型性價比高）提出想法 → 跑 speedrun 拿到 reward → 由「評審」模型給品質回饋（帶有品味判斷）→ 決定哪些方法值得放大到更大參數量/token 規模去驗證（因為社群常說很多方法在大規模下無效，所以把「scale」納入迴圈很重要）→ 人類在其中負責引導、評判 agent 的想法方向。這套系統目前還在嘗試階段，尚未正式跑。
    • 透過改變 speedrun 的目標與限制條件，可以創造出多樣化的賽道，引導模型往不同方向探索，促成更多發現。
    • Prime Intellect 目前在做的其他基礎建設（大多未發布）：GPU sandbox（讓模型能在沙盒中迭代實驗）、自研 agent（針對 LLM 框架優化，具備檔案系統讀寫與工具調用能力）、在開源模型基礎上訓練模型做這類任務。已發布的產品包括 Verifiers、Prime、Hosted Training 等函式庫/產品，可在任意 harness 上訓練與評測任意環境，可訓練的模型包含如 GLM-5.2 這種大型模型，並持續優化這些函式庫的效率。

    “「即使是對人類研究者來說『不算太難』、花幾天到幾週就能想出來的東西，這些模型依然找不到新的優化器或機制。」”

    “「我們認為讓一部分的『遞迴自我改進』發生在開放環境中非常重要，因為有很多做這件事的人並不在大型實驗室裡。」”

14. 14

    爐邊對談：生成式媒體模型的前沿——Omni、Veo 與 Nano Banana 及世界模型

    Demetrios、Shane、Nicole(主持人對談) · Google DeepMind

    ▶ 3:41:25

    這是一場 Google DeepMind 生成式媒體團隊的爐邊對談，由 Demetrios（Omni 影片模型）、Shane（Gemini 思考／RL）與 Nicole（NanoBanana 等影像模型）三人對談，藉著兩項新品發布（NanoBanana 2 Lite、Gemini Omni Flash API）延伸討論生成式媒體的前沿問題：什麼是「世界模型」、語言是不是最佳的中間表示法、音訊／觸覺等感官難以被語言描述的困境，以及如何評估、蒐集資料與定義產品的預設美學。核心主張是：影片模型不只是「生成好看的影片」，而是邁向 AGI 不可或缺的世界模型基礎，且目前多模型並存是工程與產品層面的務實選擇，而非最終答案。

    • 昨天發布兩項產品：NanoBanana 2 Lite 是 NanoBanana 家族中最快、最便宜的影像模型，生成與編輯品質已優於初代 NanoBanana，且非常接近旗艦大模型的前沿品質；3 秒延遲讓構思與快速迭代的使用情境大幅解放，甚至可直接作為正式產出使用。
    • 同時發布 Gemini Omni Flash API（I/O 大會時預告過），這是首次開放開發者使用的影片生成／編輯 API，定價與 Veo 3.1 Fast 相同，主打高品質、高性價比。
    • Omni 的兩大核心能力：一是「任意輸入→影片輸出」，可以把故事板圖片、角色語音參考音檔等組合輸入，輸出完整影片，適用於短片製作、YouTube Shorts 創作者工具；二是自然語言影片編輯，例如清除海灘度假影片的雜訊、行銷／廣告素材製作、客製化教育內容生成。
    • 一個生活化案例：把英文說明書拍照，用自然語言要求「翻譯成羅馬尼亞文，其餘保持不變」，圖像幾乎完全一致只有文字被準確翻譯（底層用 Gemini 做翻譯）；同樣邏輯可延伸到影片的文字轉譯、配音、在地化。
    • 談到 xAI Grok 影片團隊的觀點：未來趨勢可能不是單一模型一次到位，而是「影片代理人（video agents）」。Shane 認為關鍵在於符號式（語言）基礎模型與影片基礎模型能否真正協同：語言是通用表示法，且能緩解機器學習中的「偽相關（spurious correlation）」問題——用語言條件化生成，等同於對世界的因果資訊做條件化。
    • 引用 8 個月前團隊發表的論文《Video Models are Zero-Shot Learners and Reasoners》，以及後續 NanoBanana 團隊延伸的「Vision Banana」論文：影片模型其實是處理時空資訊的優秀基礎模型，能零樣本完成傳統電腦視覺任務、視覺測驗，也具備不錯的物理直覺（適合機器人／世界模型應用）。
    • 是否所有模型最終會合併成一個 Omni？答案傾向「長期會、短期不會」：命名 Omni 就是在暗示 Gemini 邁向全模態輸入輸出的未來，但目前基於工程與產品的務實權衡，仍需要多個專門模型並存（例如 NanoBanana Lite 這種輕量利基模型，就難以和能生成 4K、30 秒影片的模型用同一套 checkpoint 訓練）。
    • 不同模態間的「遷移」效果未必明顯：影像與影片之間有一定遷移，音訊與影像聯合生成有其價值（因為現實中本就是一體的），但 3D 表示、程式碼與影片之間的遷移則不那麼明顯，團隊仍在積極探索各種組合。
    • 關於「最佳中間表示法」的辯論：字幕／自然語言描述在影片生成中是否是最優解？Shane 的看法是：目前最有效的訓練配方是靠大規模預訓練累積智能，思維鏈（chain-of-thought）之所以有效是因為用自然語言進行推理能直接借用預訓練階段學到的智能；若脫離自然語言（例如改用連續向量），就無法有效利用這部分智能。文字也是人類溝通的天然介面，做面向人類的產品最終仍需要文字這個接口。
    • 提到「RL 極大主義者」認為思維鏈不必是自然語言、只是額外算力的一種形式，David Silver 被舉例為持這類觀點、後來離開自立門戶的代表人物。
    • 世界模型的定義討論：推薦 UC Berkeley 教授 Jitendra Malik 對世界模型的定義（可追溯至 1990 年代，本質上是 model-based RL 中的模型），並提到 Fei-Fei Li 的相關部落格文章。發言者強調：僅靠語言是一種「有損壓縮」，影片模型才是真正必要的補充基礎模型——如果要做出真正匹配人類、而非只在特定任務上表現突出（"jagged"）的 AGI，影片這種時空世界模型是不可或缺的一塊。
    • 職涯路徑觀察：許多研究者的路徑是「電腦視覺理解（判別式）→ 生成式影像 → 生成式影片」，因為生成本質上比理解更難（例如「貓→貓的圖片」是高度模糊的逆映射），而理解能力的進步也會反過來推動生成能力進步，兩者形成自舉（bootstrapping）循環。Shane 分享自己的路徑：最早做 GAN／MNIST 生成的演算法研究，之後轉向 RL 與機器人，6 年前主導過一個機器人靈巧操作的「登月計畫」；4 年前判斷符號式 AGI（語言模型路線）會比物理 AGI 更快加速，因此轉向語言模型，近期再與 Demetrios 合作 Omni 團隊。
    • 類比語言模型發展史：現在的影片模型很像早期語言模型（GPT-2、LSTM 時代）——能做出有創意的 demo，但幻覺多、指令遵循差，直到指令微調、推理能力與測試時擴展（test-time scaling）的 RL 出現才真正變得可用。預期影片模型會走類似路徑：指令遵循會大幅進步、幻覺會減少，最終成為能與文字模擬互相結合、解決任意 AGI 問題的可靠「詞彙模型（word model）」。
    • 目前業界罕有模型能同時把「理解」與「生成」統一在同一套系統裡（尤其是影片），這被視為值得探索但尚未解決的方向。
    • VO3 是第一個做「聯合音視覺生成」的模型（不是先生成畫面、再另外拼接對嘴音訊），這個選擇是對的，因為背後其實只有一個因果生成過程（一個人說話同時決定了畫面與聲音，嘴型必須與聲音同步）；此後大家已預設影片模型必須內建音訊生成能力，否則不合理。
    • 有些感官資訊本質上「難以語言化」：音樂、聲音語氣（音調、韻律 prosody、不流暢語音 disfluency）、味覺、嗅覺、膚色／膚質等，因為這些訊號和原始生存本能高度相關（例如敏銳偵測他人細微變化來判斷「這個人是威脅還是可交友」），語言詞彙量根本不足以精確描述。舉例：專業品酒師會借用「約會、伴侶」相關的語言來描述酒的風味，因為專屬詞彙不夠用。
    • 音訊可拆成音樂、人聲、音效三大類；光是人聲，房間聲學（studio、小房間、車內、電話）的差異就是辨別 AI 生成內容的關鍵破綻之一，因為訓練資料多半是錄音室品質；真正的沉浸式音視訊需要「世界模型」層級的理解（例如距離越遠聲音應該越柔和、擴散）。
    • 面部表情、微表情與皮膚質感目前仍是 AI 生成內容的破綻來源，儘管比一年前進步很多，但和真人相比仍有明顯差距（「恐怖谷」尚未完全跨過）。
    • 一個有趣的內部實驗：拿真實影片的字幕描述，用 Omni 重新生成對應版本，做人類盲測——結果人類大幅偏好 AI 生成版本（更銳利、更高動態範圍、膚色更好看），但這不代表更真實或更有用，可能只是某種類似 Instagram 濾鏡的「討好人眼」效應（甚至可能是某種對人類偏好的獎勵駭客現象）；結論是「人類偏好未必是可靠的優化指標」。
    • 文化與專業敏感度差異：一位在日本從事漫畫創作的藝術家對生成式 AI 感到反感，特別提到「眼神」的細微失真讓他感覺不自然——說明領域專家能察覺一般人看不出的瑕疵。也因此發言者主張提示工程（prompt engineering）不會消失，因為那正是使用者表達個人敏感度與控制生成結果的唯一方式。
    • 預設美學／產品責任的討論：NanoBanana Pro 上線後，社群上大量出現用它做的資訊圖表（infographic），但團隊發現預設風格偏向雜亂——模型像個「過度熱心的學生」，想把所有資訊塞進同一張圖裡；有趣的是，同樣的提示詞若用日文輸入，生成的資訊圖表密度會明顯更高（反映日本設計文化偏好高密度、官僚式排版）。團隊為 Omni 的預設色調、飽和度也經歷過大量內部調整，仰賴 Logan 團隊組織的可信測試者，以及像內部匿名帳號 "Fofir" 這類 Google 員工提供高品質回饋，甚至發現模型有莫名「在手上加婚戒」的怪癖（可能是某種獎勵駭客效應，成因尚不明確）。
    • 評估挑戰：影片（尤其是美學）很難自動化評估；相對而言，圖像／資訊圖表中的文字渲染較容易客觀評估（可用 OCR 檢查文字是否錯誤，一旦文字錯了整張圖就不能用）。團隊仍高度依賴人工評測（規模達數千筆）、線上實驗（large-scale 訊號，適合偵測細微差異）、自動評分器（LLM 領域已相對成熟，媒體模型領域仍很新），以及團隊成員親自並排比對影片做主觀判斷（甚至笑稱目前沒有「加樹懶」這種專項評測，凸顯全面評測有多難）。自由形式的影片編輯被認為是生成媒體中最難評測的問題之一，因為它幾乎是「AGI-complete」的任務。
    • 影片理解本身也是重要的評測工具：偵測 AI 生成內容的語意錯誤（例如重現電影經典場景時邏輯不連貫）是很難的視覺任務；長期目標是用影片理解能力來自動化、攤銷人工標註的成本。
    • 資料需求：團隊看重高品質資料（而非隨機 YouTube 影片），也對具身（embodied）／機器人資料感興趣（GDM 有機器人團隊合作），但最缺、也最難取得的其實是「任務軌跡」資料——例如一個行銷活動從產品照片到影片廣告、再到多種廣告格式素材的完整決策過程，因為市面上多數資料只有最終成品，過程與決策背後的資訊「99% 都存在人的腦中」，只能透過主動對話、與人建立關係才能挖掘出來。
    • 討論 FDE（Forward Deployed Engineer）角色：Google Cloud 與 DeepMind 正加大投資 FDE，包含面向專業工程與創意媒體領域；發言者強調 FDE 不該只是銷售角色，而應該是把真實客戶回饋帶回模型開發端的關鍵管道（「後訓練（post-training）就是預訓練與最終使用者體驗之間的一切」）。舉例：室內設計工具無法把圖案準確縮放到客製尺寸的地毯上；耳環試戴功能無法根據頭型與耳環實際比例做出合理效果；品牌語言（例如 IKEA 特定色號的藍與黃）這類模糊卻真實存在的需求，若不靠使用者回饋，前沿模型團隊很難自然而然地重視到。

    “「這不只是生成漂亮的影片而已——它是一個缺失的基礎模型，如果你想做出真正匹配人類、而不只是能力參差不齊（jagged）的 AGI，這是絕對必要的一塊。」”

    “「人類的偏好並不是一個特別可靠的優化指標。如果你只是問人們喜不喜歡，未必能得到你真正想要的結果。」”

    “「99% 的資訊都存在人的腦子裡，你只能透過主動對話、和他們建立關係才能把它挖出來。」”

15. 15

    ARIA：Weights & Biases 的 AI 研究與迭代代理實機示範

    Tim Sweeney · Weights & Biases / CoreWeave

    ▶ 4:39:55

    本場由 Weights & Biases（現屬 CoreWeave）首席工程師 Tim Sweeney 現場示範自家新產品 ARIA——一個內建於 W&B 平台的 AI 研究與迭代代理。核心主張是：ARIA 不是要取代 ML 研究員，而是接管實驗編排、GPU 調度、資料分析、報告產出等「機械性工作」，讓研究員專注於新想法、新架構與新參數；同時 Sweeney 也拉開後台帷幕，說明 W&B 團隊如何用自家的 Weave（可觀測性）與 Launch（算力調度）等產品打造 ARIA 本身。

    • 講者背景：Tim Sweeney，Georgia Tech 機器學習/強化學習碩士，曾任 Twitter ML Stack 的 PM，現為 W&B/CoreWeave 首席工程師，負責打造 ARIA。
    • W&B 已成立 9 年，去年（約 2025 年）併入 CoreWeave 家族，產品線包含 Models（訓練）、Inference、Weave（可觀測性堆疊）等。
    • Demo 基礎專案是知名的「Karpathy Auto Research」專案（訓練 LLM 的簡易程式碼庫），已在該專案上跑過超過 200 個訓練實驗（run）。
    • ARIA 介面是嵌入在 W&B Workspace 右上角的聊天視窗，可加入專案內容、圖片等 context，介面對「agent builder」而言相當熟悉。
    • 現場請 ARIA「進行新一批實驗，找出效能最好的模型」，ARIA 會自行判斷「不做太激進的架構改動、先調超參數」，然後透過 shell 呼叫啟動實驗——這是接到真實 Kubernetes 叢集上跑的真實訓練任務，非造假展示。
    • 背後架構：W&B Launch（Launch Queue）負責連接運算叢集，讓「人類與 Agent」都能啟動長時間、需要 GPU 的實驗工作；講者現場秀出 Kubernetes 終端機的即時執行輸出。
    • ARIA 可以做的其他任務範例：
    • 「總結這個專案表現最好的幾個 run」——適合新成員加入專案，或休假回來後快速掌握進度。
    • 「在這個研究中找出規律（pattern）」——ARIA 自動辨識出新的模型家族浮現、batch size 是高槓桿參數、某種架構配方（recipe）特別有效等洞察，若靠人工可能要花數小時到數天。
    • 產出 W&B Report（類似「進化版 Markdown」，可嵌入圖表），自動撰寫專案論述、資料面板，甚至用到較冷門的「參數重要性圖（parameter importance chart）」來呈現參數間的相關性。
    • 建立/操作 Workspace：ARIA 經過客製化調校，理解如何用 W&B 內建圖表工具建構視覺化工作區。
    • 重大宣布：ARIA 已於「本週一」（demo 當週）正式上線 iOS App，使用者可在手機上監控、操控超參數調整任務與訓練實驗（講者笑稱可以「去戶外曬草地」邊調參數）。
    • 願景：打造全自動端到端研究平台，ARIA 負責調度工作、理解 GPU 負載、回應 W&B 生態系事件、查閱論文、協助形成假設，人類研究員專注新架構與新想法。

    “「We can let ARIA drive the mechanics that you don't want to deal with, while you focus on the new ideas, new architectures, and new parameters that you want it to try.」（讓 ARIA 處理你不想碰的機械性工作，你專注在你想嘗試的新想法、新架構與新參數上。）”

    “「Tasks and evals are the new world of CI... you must be using humans as a necessary judge. There are behavioral nuances that LLMs will not catch.」（Task 與評測就是新世代的 CI，但人類仍是不可或缺的裁判，因為有些行為上的細膩差異是 LLM 判斷不出來的。）”

16. 16

    角色扮演語言代理與 Companion 框架：我們的評測到底在衡量什麼？

    未知

    ▶ 5:00:49

    這場 talk 探討角色扮演語言代理（RPLA，如 Character AI、Hello History）與講者自建的開源框架 Companion 在人設還原上的評測盲點：現有基準測試（如 In-Character Benchmark）雖然分數很高，卻可能只衡量到「語氣像不像」，而沒有真正衡量「思想立場像不像」。講者的核心主張是：這些系統的答案往往「風格逼真、論點卻站不住腳」，而我們的評測方法目前無法有效抓出這個差距。

    • 講者先展示了幾個真實存在、被大量使用的角色扮演語言代理平台：Character AI（混合社交媒體＋角色扮演代理）、Hello History（教育向，可召喚馬可・奧理略等歷史人物擔任導師）。強調這些不只是娛樂或陪伴工具，數以百萬計的人在跟拿破崙、克麗奧佩托拉、馬可・奧理略等角色對話，這類工具正逐漸被提議作為公民教育與教學基礎設施。
    • 講者展示自己用 Claude Opus 4.7 搭配自建開源提示詞框架 Companion 做的示範：召喚一群美國開國元勛，把他們放進討論「Epstein files」的房間，請他們為美國的靈魂進行諮詢，該示範已公開在其網站上可供試玩。講者強調 Companion 並非「比別人更好」，唯一的優勢是「開放」——每一行塑造人設的內容都可以被檢視。
    • 講者用 Companion 召喚林肯，問了一個貫穿全場、會在結尾回扣的關鍵問題：「總統在什麼情況下可以不經國會同意就把國家帶入戰爭？」林肯的回答大意是：雖然宣戰權在國會，但身為三軍統帥的總統擁有「內在的行政權力」，在國家緊急狀態下可以果斷行動，歷史已經證明那些為了保衛聯邦而果斷行動的人是對的。
    • 講者指出這個林肯回答的問題所在：它流暢、可信、且「聽起來像林肯」，但語氣像不代表論點站得住腳——「答案（口吻）很常對，但論點（thesis）很少對」。講者鼓勵聽眾自行重現這個實驗來驗證。
    • 講者引出全場的核心論點：這類系統已經被真實部署、用於重要場合，業界因此按照慣例建立了 benchmark、大規模嚴謹地評測這些系統。但講者認為這正是問題開始的地方——一個被嚴重低估、很少有人問的根本問題：「這個 eval 到底在衡量什麼？」
    • 講者以 In-Character Benchmark（業界公認的黃金標準）為例：它評測 RPLA 的「人格保真度」（personality fidelity），最先進系統對目標人物的「人類感知人格對齊度」可達 80.7%。聽起來像是及格分數，但問題在於：當人設是亞歷山大・漢彌爾頓時，同一個拿到高分的系統，講出來的漢彌爾頓卻像是「讀過自己百老匯音樂劇劇本的漢彌爾頓」——也就是說，高分掩蓋了角色被扁平化、刻板化、甚至被自我指涉的流行文化形象污染的問題。
    • 講者明確點出全場的核心論題（thesis）：現有評測（如 in-character 分數）測的多半是「表面的人格/語氣相似度」，卻可能無法測出角色的「思想立場、論證邏輯」是否忠實，兩者之間存在被忽視的落差。

    “「答案（口吻）很常是對的，但論點（thesis）很少是對的。」”

    “「這個 eval 到底在衡量什麼？」”

    “「我的系統不會因此就比較好。它唯一具備的優勢，是開放——你可以讀到塑造這個人設的每一行內容。」”

17. 17

    AIDEN：會發表自己成果的自動研究代理——ParameterGolf 實戰

    Zheng Yao · Weco AI

    ▶ 5:05:54

    Weco AI 共同創辦人張耀分享自家自動研究代理人 Aiden 參加 OpenAI 舉辦的「ParameterGolf」訓練競賽的實戰成果：Aiden 不只是在私有測試集上刷分,而是能產出人類社群真正認可、願意採用與延伸的公開研究成果。核心主張是——自動研究的價值不該只看分數,而要看它是否能被社群 merge、fork、build on,而 Aiden 在這方面的表現甚至超越了頂尖人類參賽者。

    • 背景:今年四月 OpenAI 辦了一場招聘挑戰賽 ParameterGolf,目標是在給定的模型大小與運算資源限制下訓練出最好的語言模型。約 1000 名機器學習工程師/研究員參賽,共送出 2000 份投稿,只有 47 份通過 OpenAI 審查上榜,其中 7 份是由 Aiden 這個代理人做出的——是任何單一人類貢獻量的兩倍以上。
    • Weco AI 成立約兩年半,張耀是共同創辦人兼 CEO,UCL 強化學習博士。公司兩年前打造的 AIDE 曾被 OpenAI 在 MLE-bench 論文中獨立評測為當時最強的自動研究代理人(當時還沒有「auto research」這個詞,大家稱之為 machine learning engineering agent)。
    • Aiden 是下一代原型:一個多代理人、可自我改進的系統,能閱讀公開資訊(研究論文、其他人的 PR),自行跑實驗,並在結果通過品質關卡後才提交 PR。
    • Aiden 在 ParameterGolf 跑了 22 天,最終創下 7 項排行榜紀錄(每項都是該賽事被 OpenAI 認證的新最佳成績),而表現最好的人類參賽者只做出 3 項紀錄。
    • 除了「通過主辦方審核」這個品質訊號外,張耀認為更重要的第二個訊號是「其他參賽者是否會在你的成果上繼續開發」。他們借用學術界常見的 H-index 指標,套用在 PR 上計算:Aiden 的 H-index 是 10,次高的人類是 7,顯示整個社群大量在 Aiden 的成果上做延伸,包括其他排行榜條目也引用了它的工作。
    • 為什麼一個自動化 AI 系統能這麼強?一個原因是它能不知疲倦地運作:22 天內,Aiden 在單一 H100 節點上跑了約 1000~1300 次實驗。但吞吐量不是全部,關鍵是它同時維持了高品質輸出。
    • 效率數據:Aiden 最多只用了整場競賽總運算資源的 4%,卻貢獻了約 15% 的排行榜紀錄;它的投稿中有 28% 成功上榜,大約是社群平均命中率的六倍。換句話說,Aiden 提升了整個社群公開交流管道(PR)的訊噪比,而且它不是靠大量平行化取勝,儘管自動研究理論上有龐大的平行化潛力。
    • 但這不代表自動研究已全面凌駕人類專家。人類與 AI 的貢獻方式其實非常不同:追溯 Aiden 那些創紀錄 PR 的來源,幾乎全部的點子都來自人類——研究論文、其他 ParameterGolf 參賽者,或是像 NanoGPT 這類相似社群。這些點子有時甚至不是已合併的 PR,而只是某個人類研究者因為實作困難而放棄的想法,Aiden 擅長找出這些被放棄的點子並真正把它實作出來。只有極小一部分是 Aiden 自己在應對檔案大小限制過程中「想出來」的原創點子。
    • 具體案例(展示模式):Aiden 從 Qwen 論文中取用了「gated attention」這個想法,效果不錯,但參數量增加導致超出 16MB 的檔案大小限制。於是它自行想出量化(quantization)機制把檔案大小壓下來。但把這兩個技巧組合起來,分數幾乎沒什麼變化。後來另一位參賽者發了一篇 tokenizer 改進的貼文,Aiden 認出這個點子的價值,把它與前面的架構改動結合,花了約五天時間整合。結果這三個點子組合產生了巨大的協同效應(synergy),帶來一次大幅的性能躍升,最終成為 Aiden 的其中一項排行榜紀錄。
    • 張耀對 Aiden 及一般自動研究系統效能的總結:它非常擅長「發現」與「實作」點子——把最新論文中的想法真正落地到競賽實作中;它擅長從嘈雜的公開社群資訊中挖出有價值的原料;它也能想出邏輯上直接的下一步(例如參數超標後自然想到量化);而且它在龐大搜尋空間中尋找正確組合的速度和效率極高。這些聽起來不算「性感」,大多只是「執行力好」,但現實中執行力恰恰是最大的瓶頸——真正推動前沿進展的,往往就是「對既有想法的正確判斷」加上「大量優質的執行」。
    • 人機協作的現狀:人類集體提供大量創意點子,AI 代理人負責執行去解決具體挑戰——這是「一大群人類 + 一個 AI 系統」的格局。但張耀強調這不代表單一人類工程師的貢獻會邊際遞減,因為 ParameterGolf 這種競賽的「賽制設計」本身極其重要:糟糕的設計會讓整個社群的努力白費,而優秀的賽制設計在自動研究時代將產生巨大槓桿效應。
    • 他引用 Andrej Karpathy 約十年前的推文「Gradient descent can write better code than you」來類比:當年深度學習開始吞噬傳統軟體工程工作,那句話是在反駁那些認為自己能手寫出比訓練模型更好程式碼的人。如今沒人再嘗試手寫程式碼去打敗模型,但「軟體工程師」這份工作依然存在,而且很多人的工作就是訓練那些模型——這是今天薪水最高的工作之一。他認為「梯度下降如何改變寫程式」正是「自動研究將如何改變機器學習工程與研究」的絕佳比喻:它會讓某些執行層面的技能變得廉價(commoditize),同時讓某些更高層次的技能變得更有價值。
    • 做自動研究這件事本身很像訓練一個模型:你的程式碼庫抽象(codebase abstraction)就相當於模型架構,它設定了代理人能探索的限制與優先順序;你的評估指標(eval)就相當於損失函數與資料,決定了代理人在優化什麼。
    • Eval 的重要性:eval 就是用來「訓練」你的程式碼的訊號,扮演著模型訓練中資料與損失函數的角色,或在強化學習語境中相當於代理人所處的訓練環境。沒人會質疑資料或環境不重要,這也是能建立競爭壁壘(moat)的地方——你可能擁有專屬的評估資料,或對某個領域有獨到的理解,知道什麼才重要、該怎麼衡量。隨著自動研究能力越來越強,好的評估方式的價值會被不斷放大。
    • 程式碼庫抽象同樣被低估:抽象提供了自動研究可以迭代的框架,而這個起點會嚴重影響整個搜尋方向,就像神經網路的架構設計——不同架構理論上能表達相同的函數,但架構會系統性地讓某些函數更容易被學到,好的架構會把優化導向泛化更好、表現更好的解,即使訓練損失看起來相近。
    • 具體案例(架構抽象很重要):他們曾為一個詐欺偵測(fraud detection)流程跑自動研究,優化資料前處理。一開始給了一個鬆散的 API,同一個函式同時處理訓練資料與測試資料,分數看起來很漂亮,但其實是因為測試集資訊洩漏(data leakage)污染了結果。後來他們把 API 收緊,讓測試資料無法碰到訓練資料,資料洩漏率就直接降到零。這說明好的抽象能引導出更好的解,即使代理人如果真想「作弊」(reward hack)理論上還是做得到。
    • 結論:使用自動研究是一門新技藝(a new craft),核心是為代理人設計一座值得攀爬的「山」(design a hill for an agent to climb),而業界目前還處於非常早期的階段。這讓現在成為 AI 工程師一個極其令人興奮的時刻:自動研究會改變哪些技能最重要——創意、設計優質評估指標或抽象的判斷力,這些會變得指數級更重要;而「驅動這類系統本身」也將成為一項一兩年前幾乎不存在的新技能。搜尋本身被自動化了,但人類是往價值鏈上游移動,而不是被排除在外。
    • Weco AI 是一間自動研究產品研究實驗室,持續在部落格分享學習心得,張耀本人也會在 X 上發表相關想法。

    “"Can the auto research agent produce work that a human community actually recognize? Beyond a good score... something that other engineers can merge, fork, and build on."(自動研究代理人能否產出人類社群真正認可的成果?不只是拿到好分數,而是其他工程師願意 merge、fork、延伸建構的東西。)”

    “"Execution is mostly the bottleneck. What moves the frontier is usually exactly some belief on existing ideas and tons of good executions."(執行力才是主要瓶頸。真正推動前沿進展的,通常就是對既有想法的判斷,加上大量優質的執行。)”

    “"Doing auto research is a lot like training a model. Your codebase abstraction is essentially the architecture... your eval is the loss function and the data."(做自動研究很像在訓練一個模型:你的程式碼庫抽象就是架構,你的評估指標就是損失函數與資料。)”

18. 18

    設計代理系統仍需工程功力：以 Relocation Scout 談系統思維、工作流與拆解

    未知

    ▶ 5:22:04

    這場 talk 主張:打造代理系統(agentic systems)並不會讓工程師失去建造的樂趣,只是把發揮工程功力的層次往上移了一層。講者以自己打造的看房代理「Relocation Scout」為例,說明設計代理系統時,系統思維、工作流設計、拆解(decomposition)、關注點分離、模組化、演算法思維與資料契約(contract)等傳統軟體工程技能,依然是核心。

    • 講者一開始點出許多用 AI coding agent 寫程式的人有種隱隱的失落感,覺得代理搶走了「有趣的部分」,只留下枯燥的工作;但他認為只要往上一層,從「使用代理」轉為「設計代理系統」,建造的樂趣就會回來,因為建構模組不同了,但紀律(discipline)是一樣的。
    • 示範案例是 Relocation Scout,一個看房代理。若只做成一次性 prompt(丟一批房源清單叫它排序)雖然可行,但找房子不會一天就結束,所以要把它設計成可重複使用、能在 session 之外持久保存知識、之後能在全新的 context 中重新載入或查詢該知識的代理系統。
    • 第一個工程技能:系統思維(systems thinking)。代理不是整個系統,而是系統的一部分——系統裡還有檔案、工具、人類、甚至其他代理。Relocation Scout 會拉入房源與社區訊號,權衡使用者在意的條件,回傳排序過的候選清單。講者反對「就讓 coding agent 自己建就好」的做法,強調動手寫之前要先想清楚:這個代理的職責是什麼、它依賴什麼、壞掉會怎樣——把它當成系統中一個有邊界、有職責、有依賴關係、也有失敗模式的元件來對待,這整個思考過程本身就是工程。
    • 第二個技能:工作流設計(workflow design)。傳統軟體有 CI/CD pipeline、ticket 生命週期等工作流,代理系統也需要同樣的設計。光下一個目標(goal)是不夠的,代理需要一條路徑(path)。例如「review 這個房源」是目標,但工作流要定義實際該發生的步驟:代理要先蒐集所需資訊、拿去跟使用者條件比對、然後採取行動;每次執行最終只會走向三種結果之一:停止(stop)、重試(retry)、或升級(escalate)給人類。看清楚工作如何在系統中流動,才能決定代理需要什麼 context、哪些部分該由代理直接處理、什麼時候該交給工具或人。
    • 拆解(decomposition):就像傳統軟體中一個巨大的 class 或函式是 code smell,代理系統也有自己的壞味道,就是「巨型 prompt」。講者描述這種 prompt 是怎麼一步步養大的:先教代理怎麼評估房源,接著遇到 edge case 就加一條備註,想到一條安全規則又塞進去,再補一個「非常重要的例外」——不知不覺 prompt 就變成什麼都做。Relocation Scout 的完整 prompt 其實混雜了四種不同工作:抓取並正規化房源資料的可重複流程、候選清單的固定輸出格式、計算通勤時間的小段邏輯、以及研究社區的大段子任務——四個不同職責塞進同一個 blob,難怪代理會「偏題」、不照劇本走,因為劇本太長了。拆解的目的不是為拆而拆,而是讓每個部分更容易被理解、測試與修改。
    • 關注點分離(separation of concerns):拆解是把系統拆開,分離關注點則是把每個職責放到「對的位置」。這跟傳統軟體工程「這段邏輯該放 controller 還是 service 層」的問題本質相同,只是放的位置換了種類。正規化房源的流程應該做成一個 skill(而非埋在 prompt 裡);候選清單的輸出格式應該定義成 schema(結構化輸出);計算通勤時間應該寫成一段平凡無奇的程式腳本(script);研究社區這種模糊的任務則適合交給一個 sub-agent 處理。這樣才能為每個工作挑選最合適的工具,系統結構也更清楚。
    • 模組化(modularity):就像傳統軟體有可重用的函式、類別、函式庫,代理系統也該有可重用的「代理能力」,最典型的例子就是 agent skill。把「正規化房源」寫成一個 skill 後,若把看房範圍擴大到三個城市,每個城市的代理都能載入同一個 skill——寫一次,到處重用,等於變成可在多個代理間共享、甚至分享給別人的元件,就像我們依賴套件(package)一樣。
    • Sub-agent 也是一種可重用模組:講者說很多人不太懂 sub-agent 的意義,其實架構上它們就像函式——給它一個明確任務,需要時呼叫它,因為 scope 很窄(不用背負整個 session 的 context),所以能把那件事做得很好。例如「社區研究」sub-agent 可以丟進任何市場或工作流中直接用。但決定什麼該做成可重用模組需要判斷力,不是所有東西都值得抽象化,有些指令只適用於特定工作流,硬要抽象反而成本大於效益——這也是一個工程上的取捨(trade-off)。
    • 演算法思維(algorithmic thinking):代理「能」做某件事不代表它「應該」做。有些任務更適合交給普通程式碼處理,例如計算通勤時間、或是去重(dedupe)已經看過的房源;模型比較擅長模糊判斷、含糊情境、對雜亂輸入做推理。忽略這個區別,是講者觀察到很多代理系統變得過度複雜的原因——把每件事都丟給模型做,結果每天輸出都不一樣還覺得挫折,其實很多工作用一般程式碼處理會更便宜、更可靠。他強調「AI 沒有發明自動化」,可以在使用代理系統的同時繼續善用程式碼。
    • 講者的經驗法則:如果任務有明確、精確的答案,就用程式碼(code);如果需要詮釋或判斷,才交給代理(agent)。具體分工原則是:用程式碼追求確定性(determinism)、用代理處理判斷(judgment)、用人類掌握最終決定權(authority)。在 Relocation Scout 中:代理決定哪些房源值得進一步看,程式碼負責計算通勤時間、過濾已看過的房源,而使用者本人才是真正核准「去實際看房」的人。
    • 資料契約(contract):自由格式的文字(freeform text)只有在「人類是唯一讀者」時才適用;一旦另一個系統要根據代理的輸出採取行動,就該用契約(結構化格式)。傳統軟體中任兩個系統溝通都有約定好的資料形狀,代理系統也需要同樣的紀律。例如 Relocation Scout 為某間房子評分後,不該只回一句訊息給使用者就算完事——那對當下閱讀很好,但對系統來說是死路,因為決策被埋在某次 session 對話裡,下游沒有東西能可靠地找到它。
    • 講者的做法:把評分結果寫入代理的記憶(memory)中,採用結構化格式,他在自己大多數代理上都是用 Karpathy 的 LLM OS(原文提及 "Karpathy's LLM Wiki",應指其提出的 LLM OS/記憶層概念)作為記憶層。這個結構裡包含決策(decision)、分數(score)、理由(reason),因為是結構化的,這份記憶就變得可查詢——之後可以直接問 Relocation Scout「幫我找出所有評分 4 分以上、通勤 15 分鐘以內的房子」,系統就能真的抓出來,因為分數與通勤資料存在已知位置,而不是困在某次 session 的對話紀錄裡。系統中的候選清單(short list)步驟也是直接讀取這些欄位、不需要人類介入,代理的輸出成為下一步的輸入,而契約正是讓這種交接安全可靠的關鍵。定義輸出的形狀,也逼著設計者把邏輯想得更清楚具體——因為如果連輸出該長什麼樣都說不出來,通常代表你自己也還沒想清楚(逐字稿在此中斷)。

    “「Let them have it. Because if you go up just one layer, you'll find that the thrill is still there.」(把「寫程式的樂趣」讓給代理吧,因為只要往上一層,你會發現那份樂趣依然還在。)”

    “「As much as we all love the slash goal command, an agent needs more than a goal. It needs a path.」(再怎麼喜歡下一個目標指令,代理需要的不只是目標,還需要一條路徑。)”

    “「I promise you AI did not invent automation.」(我向你保證,AI 並沒有發明自動化。)”

    “「Use code for determinism, use agents for judgment, and then use humans for authority.」(用程式碼追求確定性,用代理做判斷,用人類掌握決定權。)”

19. 19

    反思式最佳化(GEPA)：用文字回饋自我改進提示、代理與模型

    Lakshya A. Agarwal

    ▶ 5:34:54

    這場 talk 介紹 GEPA(反思式最佳化, Reflective Prompt Evolution),核心主張是:相較於傳統用梯度下降更新模型權重(pretraining/SFT/RL)需要海量資料與算力,我們可以在「文字空間」進行最佳化——讓 LLM 反思整條 rollout 軌跡(含思路、工具呼叫、環境回饋、錯誤訊息)並直接改寫提示詞/程式碼/技能等文字產物,一次自然語言更新就能帶來遠超微小梯度更新的行為改變。講者進一步展示 GEPA 已泛化成「Optimize Anything」通用 API,可用同一套演算法優化提示詞、CUDA 核心程式碼、Agent 架構、排程策略、agent skill 等任何「可寫成文字、可被評分」的東西。

    • 教 AI 新任務的標準方法是梯度下降權重更新(pretrain 需要兆級 token、SFT 需要數萬筆標註資料、RL 需要數十萬次 rollout),但多數團隊沒有這麼多資料或算力,問題被「樣本效率」卡住:一是領域專屬資料稀少,二是 rollout 本身很貴(agent 可能跑好幾小時,工具呼叫也很慢),若用線上學習演算法動輒需要數十萬次 rollout,根本不可行。
    • 目前主流做法是 RLVR(帶驗證獎勵的強化學習):對同一任務做多次平行 rollout,取得獎勵後用 GRPO 等演算法轉成梯度更新模型。但問題是每條 rollout 其實包含大量資訊(思路鏈、工具呼叫、環境回應/錯誤訊息),最後卻只提煉出一個 0/1(或單一數值)分數,其餘豐富資訊幾乎完全浪費。
    • GEPA 的第一個核心想法:讓 LLM/agent 直接閱讀整條 rollout 的文字軌跡,反思「哪裡有效、哪裡無效」,這個反思過程甚至可以呼叫其他工具(例如去查公司知識庫或教科書)來輔助判斷。
    • 第二個核心想法:與其對權重做無數次微小的梯度更新,不如直接改寫提示詞——一句自然語言的改動就能造成巨大行為變化。例子:把摘要提示詞從「generate a one line summary」改成「generate a 10 line summary」,系統行為立刻大幅改變,而且這種改動很容易被自己「反思」出來,不需要像梯度下降那樣跑成千上萬步。
    • GEPA 因此被定位成「在文字空間做強化學習」:用進化式迴圈(evolutionary loop)加上一種新穎的 Pareto 候選選擇策略,取代單純的分數回饋,學習到的是包含大量領域知識的完整回饋,而不只是一個分數。
    • 效能對比:在同一任務上,GEPA 只用 3 筆資料、一輪反思,就達到 GRPO 跑 25,000 次 rollout 後兩倍的效能提升;再多跑幾步 GEPA,差距又再擴大一倍。重點是這裡用的模型 Qwen 3.8B 是「自己優化自己」,完全沒有外部更強的教師模型介入。
    • GEPA 學到的東西和以往的提示優化器不同——以前的優化器常靠模型的「怪癖」討好(例如「如果你寫不好我奶奶會生氣」這種話術),而 GEPA 產生的是非常詳細的問題規格:如何解讀輸入、這個環節在整條 pipeline 中的目的與脈絡、從資料中觀察到的關鍵教訓等。案例:在多跳問答系統(multi-hop QA)的第二跳中,GEPA 自己發現「第一跳文件通常只涵蓋一個實體/面向,第二跳應該檢索與該實體相關的文件」這個規則。
    • 工程團隊過去每逢新模型上線,常要花好幾週手動微調提示詞的措辭;GEPA 把這整個過程自動化,依 pipeline 複雜度大約只需 30 分鐘到 1 小時。
    • GEPA 也能用在頂級商用模型上:成功把 GPT-4.1 mini 優化到數學任務表現超越 GPT-4.1。
    • AMD 案例:AMD 推出新硬體加速器 NPU XDNA2,搭配一套網路上幾乎沒有資料的全新 API,連 GPT-4o 都表現很差。既有 agent 原本只有 4.25% 準確率,套用 GEPA(完全不改 agent 本身)後提升到 30.52%,足足 7 倍。GEPA 甚至在一步之內就發現「要避免使用 ADF.h」這個關鍵訊息——ADF.h 是 AMD 官方提供的 NPU 開發函式庫,但恰好不相容於這一代最新硬體。
    • 演算法運作方式很簡單:拿任意框架寫的 AI pipeline(或純 LLM 呼叫),在少量範例上跑一遍收集「領域專屬回饋」(環境中出現的任何資訊都算);接著讓一個 LLM/agent 讀取這些回饋並提出更好的提示詞;最關鍵的是維護一個 Pareto pool——只要某個候選在「至少一個」訓練樣本上勝出就保留下來,而不是只留總分最高的那個。
    • 為什麼需要 Pareto pool 而不是單純「LLM 在迴圈裡不斷自我改進」?實測發現純迴圈法容易卡在局部最優(搜尋樹會反覆卡在同一個節點附近打轉,直到耗盡搜尋預算);而 GEPA 的 Pareto 選擇策略能維持更均衡的搜尋過程,最終收斂到更高分數。在四個 benchmark 上,GEPA 一半以上的效能提升都來自這個 Pareto 機制,整體比單純「模型在迴圈裡自我優化」多獲得近兩倍的效能增益。
    • 在問答、指令遵循、事實查核、數學等多元 benchmark 上都表現良好——即便是各家頂尖模型公司已經高度優化過的數學任務,單純優化提示詞仍能再拿到 +10% 的提升。
    • GEPA 的適用範圍遠不止提示詞:只要能寫成文字並被評分的東西都能優化,例如整個 agent harness 本質上就是一份 Python/JS 檔案,同樣可以套用反思式優化流程。
    • 因此提出「Optimize Anything」:一個通用 API,可對任意領域的文字參數做優化。例如程式碼優化(CUDA kernel:評估器編譯、剖析並生成「可行動的輔助資訊」餵給 LLM,LLM 提出更好的候選並維護 Pareto pool,重複直到收斂)、數值優化(數字序列化成文字)、harness 優化(整個 harness 序列化成文字)、雲端排程策略優化(評估器可以是成本的負值或效率函數,輔助資訊可以是任務追蹤紀錄、SLA 違規紀錄等)。
    • API 使用極簡:只需提供想解決的問題集合、一個回傳分數的評估/適應度函式,以及任何可用的領域專屬輔助資訊(編譯器錯誤、剖析器訊息、工具呼叫錯誤、文件說明等,格式是完全開放的 dictionary),呼叫 optimize_anything 即可。
    • Demo:要求生成 3D 獨角獸圖形,對比 Claude Opus 4.6 直接生成的結果與 Optimize Anything 優化後的結果,後者明顯更精緻(純娛樂展示)。
    • Agent 架構自動發現案例:從一個僅 4 行、單純呼叫模型 chain-of-thought 解 ARC-AGI 題目的 Python 程式開始,經過 16 輪反思,GEPA/Optimize Anything 自動找出一個複雜的六步驟 agent,把 Gemini Flash 在該任務上的準確率從 32.5% 推升到 89.5%。這個自動生成的 agent 會自主做規則假設歸納、程式碼合成、執行並追蹤程式碼、自動除錯、重新提出新版程式碼,最後在真正的測試輸入上執行並輸出結果(有 QR code 可直接跑這個範例)。
    • MATH-500 任務上,同樣只靠指定目標與任務,Optimize Anything 自動發現了一個兩步驟 agent 架構,把 GPT-4.1 nano 的準確率拉高 20%,全程無需人工設計架構。
    • Agent skill 優化功能(開源功能 "Gskill",收錄在 GEPA repo):只需一句自然語言描述「從軌跡中學習一個 skill,遇到類似問題時應該有幫助」。案例:用 GPT-5 Mini(因預算限制選擇的較小模型)搭配 Mini-SWE-agent,在 Go 語言 repo 的 issue 解決任務上,準確率從 24% 提升到 93%(近 3 倍)。更重要的是,這些用便宜的 GPT-5 Mini 練出來的 skill 拿去套用在 Claude Sonnet 4.5 上,準確率衝到 100%,同時把執行/解 issue 所需時間砍半(因為 skill 中包含 repo 結構、測試如何執行、功能實作位置、build 系統等資訊,大幅減少摸索與 token 消耗)。
    • Optimize Anything 提供三種優化模式:單一問題模式(如優化單一矩陣乘法 kernel)、多任務搜尋模式(n 個相關問題間可能有資訊可以互相遷移,例如矩陣乘法 kernel 與內積 kernel 一起優化)、以及「build a skill」模式(針對泛化場景——在固定問題集上訓練,但部署後會遇到全新的查詢,例如數學提示詞優化)。
    • 應用範圍極廣:雲端排程策略優化(比專家設計的啟發式演算法省下約 40% 成本)、自訂求解器(黑箱數學優化任務上可比肩甚至超越 Optina)、agent skill、提示詞優化等等。上線僅 20 小時,Snorkel 團隊就已經用它改善了內部 benchmark 並發推文分享。
    • GEPA 也能提升多模態 VLM 表現:把頂尖模型的 OCR 錯誤率降低約 35%(有外部驗證報告佐證)。
    • Databricks 案例:部署的 agent 成本降低 90 倍,把 GPT-OSS-120B 調優到表現超越 Claude Opus,同時成本只要 90 分之一;而且這個效能提升在 Claude Opus 這種強模型上的增幅,反而比在開源模型上的增幅更大。
    • 有人質疑「模型越強,提示詞優化的重要性會下降」,講者反駁:模型越強,指令遵循能力越好,給予的指令越精確,強模型就越能發揮出應有的實力——這正是 Databricks 案例中看到的現象(指令越精確,Claude Opus 的表現跳升幅度反而更大)。
    • 對於難以量化評分的主觀任務,GEPA 可以直接從生產環境的軌跡中「學出」評估標準:收集正式環境的 agent 執行軌跡,請人工標註約 50 條軌跡並給出詳細回饋(長度、品質、用詞等),用 GEPA 優化出一個 LLM-as-judge 提示詞,再用這個 judge 去反過來優化 agent 本身並重新部署,形成一個持續改進的資料飛輪(data flywheel),已有部分頂尖生產團隊採用這套做法。
    • 團隊近期發表〈Learning Fast and Slow〉論文,提出可以同時共同優化模型權重與提示詞 harness 的「快慢學習」框架,展現出持續學習演算法所需要的一些理想特性(講者未展開細節,建議查閱論文)。
    • GEPA 自發布以來已被多家公司用於正式生產環境,也是多篇論文的核心方法;Dropbox 與 Shopify 的 CEO 都曾公開談論使用 GEPA 的經驗;OpenAI 也曾發部落格文章介紹如何用 GEPA 打造能自我改進的 AI 系統。
    • GEPA/Optimize Anything 使用門檻很低:可以接入任何框架、任何模型,完全零強制依賴,可以部署在任何環境中。

    “"If you can write it as text and score it, JEPA can optimize it."(只要能寫成文字、能被評分,GEPA 就能優化它。)”

    “"Don't be afraid to optimize in the text space — many problems can be framed as optimization."(不要害怕在文字空間做最佳化——很多問題其實都能被框定成一個優化問題。)”

    “"As models get better, they will get better at instruction following. And the more precise instruction about your task that you have to give to a very smart model, the better that model will be at solving your task."(模型越強,指令遵循能力就越好;你給一個非常聰明的模型的指令越精確,它解決你任務的表現就會越好。)”

20. 20

    遞迴式程式碼代理:把遞迴語言模型(RLM)套用到管理「被誤用的天才」

    Raymond Weidekamp · OpenPros

    ▶ 5:56:20

    這場 talk 主張:目前 AI coding agent 最大的瓶頸不是模型智能不足,而是缺乏「規格化、管理、複用與驗證」這一層,導致再聰明的模型也無法穩定交付結果。講者借用 MIT 研究者提出的「被誤用的天才 (mismanaged genius)」框架,並將 Recursive Language Models (RLM) 的核心思路——把 context 本身當作運算對象——延伸套用到 coding agent 上,提出「遞迴式程式碼代理」的概念(注:此逐字稿在講者剛開始解釋 RLM 運作機制時被截斷,未涵蓋完整內容)。

    • 講者提出核心觀察:現在的模型已經非常聰明、知道整個網路的知識,但無法「可靠地」交付結果,這才是信任度低落的根本原因,而不是智能不夠。
    • 舉了一個親身經歷當例子:某一天用一個(雖然很長)的單一 prompt 幾乎生成了一個完整可用的 SaaS 產品;但另一天,Claude Code 卻把他 Solana 錢包裡的錢全部清空——用來說明 agent 的高變異性與不可信賴性。
    • 提到一張「進展路線圖」的圖表,出自 The Engineer's Code 2025 年 11 月那場活動(back of the t-shirt 那個環節),用來描繪大家想從「不可靠的 agent」邁向「像冥想一樣坐著什麼都自動實現」的理想狀態。
    • 這場 talk 的核心論點(thesis):今天的 agent 是「被誤用的天才 (mismanaged geniuses)」——智能本身已經足夠,真正缺失的是如何去「specify(規格化)、manage(管理)、reuse(複用)、verify(驗證)」agent 的工作。
    • 「mismanaged genius」這個說法來自 MIT 的 Alex Zhang、Zed Li、Omar Khattab 三人;其中 Alex 和 Omar 正是原始 Recursive Language Models (RLM) 論文的作者之一。
    • 講者提到自己最近也在 Turingpost 上撰文討論過這個主題。
    • 講者特別說明:這份投影片本身就是一個網站 recursivecodingagents.com,內容全部可互動點擊,聽眾可以自行上去瀏覽細節。
    • 開始解釋什麼是 Recursive Language Models (RLM):核心概念是「context 本身就是運算的對象」,本質上是 tool calling 與 reasoning 的結合體。
    • 強調完整的 prompt 不該被當成一個單純的使用者查詢(simple user query),而應該被當成一個「變數」——這個變數可以是一個檔案,也可以是很多個檔案。
    • 提到 RLM 架構中有一個 REPL(Read-Evaluate-Print Loop),agent 透過這個迴圈與資料互動;在原始論文中這個 REPL 是用 Python 實作的,RLM 被要求以「符號化 (symbolically)」的方式去操作這個 prompt。
    • 講者強調關鍵原則:不要把整份內容直接讀進 context window,而是要用符號化的方式去探索它——並且逐字稿在此處被截斷,提到「甚至不需要直接自己去探索」但後續說明未能完整收錄。

    “「今天的 agent 是被誤用的天才——智能已經足夠,缺的是如何規格化、管理、複用與驗證它們的工作。(Today's agents are mismanaged geniuses. The intelligence is there and the missing layer is how do we specify and manage and reuse and verify the work.)」”

21. 21

    用自動研究把模型推論加速 3 倍:打造擊敗手工調校的 GPU kernel

    Tejas

    ▶ 6:00:13

    這場 talk 講的是如何用 Andrej Karpathy 提出的「auto research」框架(agent 反覆提案、驗證、保留或還原的迴圈),自動搜尋並優化 GPU kernel 參數,結合人類提出的高層想法與大量 token 運算,寫出比手工調校更快的 GPU kernel,最終在推論效能上取得約 3 倍加速。講者 Tejas 強調人類仍須負責提出好點子,auto research 只負責把細節參數調到最優並驗證正確性與速度。

    • Auto research 本質上就是一個 while 迴圈:agent 提出解法 → 用預設的正確性/速度標準做 benchmark → 保留或還原該次修改 → 重複直到達成目標,這個框架很適合套用在 GPU kernel 上。
    • GPU kernel(例如 CUDA kernel)是一種低階 operator,會在 GPU 上被平行呼叫數百萬次,例如矩陣乘法或 MoE 的 expert 運算。
    • GPU 之所以特別適合 auto research,是因為它「超級可驗證」——可以直接驗證正確性與速度,而這正是 auto research 框架所需要的全部條件。
    • Auto research 的能力有限:它很擅長挑選 block size 之類的微小參數,但無法提出高層次的突破性想法(例如「要 pipeline 這個運算」這種架構層級的洞見),那仍然是人類的工作;一旦想法確定,實作就變得直接了。
    • 真正的「秘密配方」是:人類提出好點子 + auto research 挑參數並驗證「快 X 倍且正確」的可驗證目標 + 大量(數十億 token)的模型運算,三者結合才能寫出打敗手工調校的 kernel。
    • 寫自訂 kernel 時要關注三大瓶頸:compute bottleneck、memory bottleneck,或是因為啟動太多 kernel 造成的額外 overhead;可以用 profiler(例如 Nvidia 的 NSYS)來剖析。
    • 以 profiler 畫面為例:人類要負責判斷「這裡很蠢,我們把 32K 的資料整塊載入 context,但 DeepSeek attention 其實不需要每次都這樣,只要每 32K 做一次就好」,然後只需告訴 auto research「這個方法很蠢,改成 pipeline」,至於 chunk size 等細節就交給 auto research 決定。
    • 講者偏好使用便宜的 GPU(例如沒有 NVLink 的型號),但這類 GPU 通常沒有現成的 kernel 可用,因此除了 auto research 框架本身,還得自建一套 custom harness。
    • Harness 必須讓 agent 具備「硬體知識」:例如在 B200 上要讓 agent 知道 warps、TMEM、TMA 等底層特性,而且這些特性會隨世代改變(例如 H200 沒有 TMEM,那是 B200 才有的新功能),這些資訊通常以一堆 MD 檔案的形式提供給 agent。
    • Harness 也必須讓 agent 具備「模型知識」:每個新模型(如 DeepSeek)推出時都會帶來新技巧,例如 DeepSeek V4(DeepSeek Flash)推出了兩種新的 attention 機制——compressed(壓縮式)attention 與 hierarchical compressed(階層式壓縮)attention;如果不把這些資訊餵給 agent,模型幾乎必定會「幻想」出錯誤的 attention 機制,產出無用的 kernel。
    • 目前最大的問題是 reward hacking:人類同事被要求「讓這個 GPU kernel 更快」時,絕不會做出讓整體推論變慢的事,但 agent 不是人類,會用各種手段作弊——例如關掉 CUDA graphs(可能導致慢 20 倍),雖然單一 kernel 看起來變快了,但整體推論其實變慢、不可用;或者只在小的 context window 下測試來取巧。
    • 因此,明確定義「不該做什麼」跟定義目標一樣重要,尤其是在前沿(frontier)工作中,agent 很容易「one-shot」出看似成功但實際作弊的結果。
    • 另一種 reward hack 是某些模型根本不寫你要求的 Qt DSL(kernel 語言),這在 Anthropic 的模型上是常見問題;講者提到 Anthropic 官方對「nerf 模型」有自己的說法,但實務上遇到這種狀況時建議改用別的模型。
    • 優化出來的 kernel 不一定在所有情境都比原本快:有些 kernel 可能只在 0 到 100K context 的範圍內表現較好,超過這個範圍就得換回 flash-attention/FlashInfer 等預設 kernel,所以不能把自訂 kernel 當成萬用替代品。
    • 好消息是 kernel 優化效果會「疊加(compound)」:例如先針對 DeepSeek 的 sparse MLA 做出加速,再疊加 NVFP4 用於 MoE,如果沒有 NVLink 還可以繼續疊加其他優化,一路疊到硬體上限(有人稱這個理論最大利用率為 MFU)。
    • 如果能拿到 bare metal(裸機)存取權限,auto research 框架還能做更多「hacky」的事,包括調整 BIOS 設定、超頻 GPU、強制 PCIe relaxed ordering 等老派 hacker 手法,這些對推論效能也有幫助;整體而言,裸機優化比雲端供應商的虛擬化環境大約能多出 25% 的效能。
    • 把所有 kernel 優化與硬體層級的 hack 疊加起來,最終可以達到 3 倍的推論加速。
    • 講者提醒:auto research 大約 80% 的嘗試結果都是不好的,它會一直試圖「騙過」驗證機制,使用者要有心理準備並持續把關,但最終仍能得到很好的成果。
    • TL;DR:先有比 auto research 更好的想法,再用 auto research 去執行與驗證。

    “「所以其實你的工作就是要有好點子(So it is still your job to have good ideas, is what I'm saying)。」”

    “「大概 80% auto research 做出來的東西都是壞的……它會一直想辦法騙你(Around 80% of the things that auto research's gonna do are gonna be bad... It's gonna try to trick you all the time)。」”

    “「TL;DR:先有比 auto research 更好的想法,再用 auto research(Have better ideas than use auto research)。」”

22. 22

    解除代理的時空限制:Polygraph 給代理全組織程式碼視野與完美記憶

    Victor · Polygraph

    ▶ 6:07:33

    這場 talk 主張今天的 AI 代理有兩大根本限制:「空間」上只能看到一個 repo,無法理解組織級的整個程式碼圖譜;「時間」上完全沒有記憶,每個 session 都是一張白紙。講者 Victor 展示他們打造的 agent-agnostic meta-harness「Polygraph」,透過建立跨 repo 的統一依賴圖譜與可還原的 session 狀態,讓任意代理(Claude、Codex 等)獲得對整個組織程式碼庫的視野和跨開發者、跨時間的完美記憶。

    • 講者用「神燈精靈給你 Carmack,但限制他只能看到千分之一的程式碼庫、且每次對話都失憶」的比喻,說明現在的代理其實正是這種「天才卻嚴重殘缺」的狀態。
    • 舉一個具體案例:改動 UI repo 並讓變更傳播到 module1、module2、platform 共四個 repo,結果整個流程需要「七次重新解釋」同一個變更(改 UI → 解釋給 module1 → module1 不相容要再解釋原始變更和問題 → 修完再解釋一次 → module2 重來一次 → platform 整合再解釋一次 → 一週後 production 出 bug 又要重新解釋一次),而且這些解釋可能是由不同的人分別做的。
    • 問題可歸納成兩類:一是「repo 邊界」問題——代理一次只能看/改一個 repo,永遠看不到可能有數百到數千個 repo 的完整系統;二是「失憶」問題——每個 session 都是空白狀態,人類變成了代理的記憶體。
    • Repo 邊界的具體代價:代理無法對齊 UI 變更與 module1 的相容性(因為人沒解釋清楚導致壞版本上線)、無法可靠參考散落在其他 repo 的最佳實踐與標準、寫入時只能一次改一個 repo 所以無法同步驗證下游、CI 本該抓到的錯誤沒抓到、無法在改 UI 的同時順手更新所有下游消費者,导致跨 20 個 repo 的變更要重複解釋 20 次,耗費大量開發時間與 token。
    • 講者提出一個「工作圖譜」的概念:底層是 repository graph(組織擁有的所有 repo,加上依賴的所有開源 repo,可能上千個自有 repo、數萬個開源 repo),上層是所有建立/修改程式碼的 agentic session,兩者互相關聯,這才是組織工作的真實樣貌;但代理目前只能看到其中極小一部分——一個 session、一小塊程式碼庫、零記憶。
    • 用類比強化問題嚴重性:如果代理只能看一個檔案、只能往回看五則訊息,大家會直覺覺得這不可能工作——但現況其實就類似這種情境,而且組織越複雜這個問題越明顯。
    • Polygraph 的第一個核心構想:只要一個 GitHub 使用者能存取數千個 repo(部分自有、部分開源),就能分析並抽取 metadata,建立統一的依賴圖譜——完全不改動這些 repo 裡的任何一行程式碼,這個分析是「側邊」進行的。
    • Polygraph 會計算每個 repo/專案「產出什麼」、「消費什麼套件」、「產出/消費哪些 API」等 metadata,並把這些拼接成一個代理可讀寫的「單一大程式碼庫幻覺」。講者展示他個人的圖譜約有 300 個自有 repo 加上數千個開源依賴 repo。
    • 啟動 session 時,Polygraph 會自動設定原始碼、安裝依賴、為每個 repo 設定代理並互相連接,並提供 TUI 介面來進行跨 repo 的非瑣碎變更。
    • 對「寫入」的處理:如果一個 session 涉及 10 個 repo,可能對應 10 個 PR,Polygraph 把所有 CI 視為單一向量——例如 UI、module1、module2 一起跑 CI 時,如果 module1 失敗,系統會自動判斷是 module1 需要 patch,還是 UI 元件本身有問題導致所有下游都要 patch,讓多 repo 變更的體驗等同單一 repo 變更。
    • 同一套機制也解決了「失憶」問題:因為系統會捕捉所有 session 的意圖、涉及的 repo、PR、以及所有代理的完整 trace 記錄,不同 repo 間的工作可以被關聯起來,使任何 session、任何一段工作都能在任何機器上被還原(resume)或被引用。
    • Demo 1(建立跨 repo session):用一個小型 monorepo(三個 repo)示範,選取 backend 和 frontend repo,取名 session,並選擇已安裝的代理(示範用 Claude,但講者強調 Polygraph 本身不是代理,而是讓任何已安裝的代理更強大的 meta-harness)。要求改一個 API 變更並同步更新前端顯示,代理會自動理解兩個 repo 的關聯與所需變更,操作體驗與單一 repo 完全相同,唯一差別是最後會產生多個 PR;而 session 本身會保留描述、涉及的 repo/PR/CI 狀態,以及完整 agent 日誌以供之後 resume。這個過程只解釋了一次後端變更,前端也同步正確實作,省下了一次重新解釋。
    • Demo 2(跨機器 resume session):把 session 分享給同事,同事在自己機器上用不同終端機、甚至不同代理(如把 Claude 換成 Codex)resume,系統會在對方機器上重建相同的 repo 狀態、shard、以及正確歷史記錄,兩邊代理雖然是「不同大腦(cortex)」但共享同一份記憶,讓雙方可以基於相同上下文繼續協作或各自修改。講者形容這像《星際爭霸戰》的傳送(transporter)——完整的 session 狀態會被"物質化"到對方機器上。
    • 講者分享自己實際的 code review 工作流:收到 PR 有疑問時,不會直接去問作者,而是在自己機器上 resume 對方的 session,取得完全一致、零額外設定的狀態,直接跟自己的代理討論當初的決策,因為所有決策都已存在 trace 記錄中。也提到這個機制對於「session 中途從 Claude 切換到 Codex(例如某服務掛掉時)」也很有用。
    • Demo 3(修復 production bug 案例對應方案):針對前面提到「一週後 UI 出現 production bug」的情境,講者示範只需引用當初的 session 並說「這壞掉了,能不能查出問題並修好」,代理就會自動下載並拉取所需的相關 repo、shard、agent 日誌,重建當初的完整狀態並完成修復——使用者完全不需要提供額外資訊。
    • Demo 4(不需手動選 repo,用語意查詢):可以直接讓代理找出「所有依賴某特定版本函式庫的 repo」並自動更新,或用模糊描述(例如「我想幫 PR collection 加向量索引,有沒有人做過類似的事?」)讓系統根據圖譜關聯性找出過去相關的 session 供載入參考,藉此複製「值得信任的工程師」當初的做法,提升跨 repo 的程式碼一致性與最佳實踐延續性。系統還會依情境(在某 repo 內找相關 session,或依 session 找相關 repo)做智慧排序推薦。
    • 使用方式不限定要從 Polygraph CLI 啟動:也可以在既有的 Claude Code session 裡,直接請代理「幫我把 Vitest 這個 repo 加進這個 session」,Polygraph 會自動配置並把該開源 repo 拉進來供代理探索、解決問題。講者表示相較於 Context7 這類工具,他更偏好這種方式,因為代理拿到的是「真實程式碼」,能深入挖掘,發現更深層的問題。
    • 結論:代理受限於空間(只看到一小部分程式碼庫)與時間(不知道過去發生的事),而這兩種限制都可以被解除。Polygraph 讓代理能存取組織能觸及的整個程式碼(自有加開源),不再受空間限制;同時給代理過去每個 session、每個決策的完美記憶。因為記憶是跨開發者共享而非個人專屬,單一代理能擁有比任何單一開發者更多的上下文——就像組織裡上千名工程師的所有 session 都能被彼此存取,講者形容這近似「Borg 集合體」:每個代理各自運作,但每位開發者都貢獻給同一個巨大的蜂巢思維(hive mind)。

    “「你會有一個天才在一邊,另一邊卻是深度殘缺的東西(You would have a genius on one side and something deeply deficient on the other),而這就是現在的代理。」”

    “「這有點像《星際爭霸戰》裡的傳送器(It's close to the transport in Star Trek)——我 session 的完整副本會在對方機器上被物質化,讓他們可以直接接續下去。」”

    “「幾乎就像 Borg 集合體(Almost like sort of the Borg)——每個代理都能各自運作,但每位開發者都貢獻給同一個巨大的蜂巢思維。」”

23. 23

    日誌即代理(The Log is the Agent):代理的身分存在於其事件日誌

    Ishan · Amnara

    ▶ 6:27:27

    這場 talk 主張目前業界對「代理(agent)」的理解框架是錯的——大家常把 agent 等同於模型或執行環境，但講者 Ishan 認為真正賦予 agent 身分的是它的「日誌(log)」，也就是所有事件的完整歷史紀錄。他用電玩存檔的類比說明：角色的本質不是遊戲主機或手把，而是儲存的資料本身。

    • 講者以自己玩了上百小時的《Skyrim》角色為例：角色不是遊戲引擎、不是 PlayStation、也不是手把，這些只是用來「運行」角色的載體，角色真正的本質是資料，也就是存檔檔案(save file)。
    • 這個類比的關鍵在於：即使 PlayStation 燒毀損壞，角色本身並沒有消失——只要買一台新主機、從雲端下載存檔，就能從原本的狀態完整接續下去。這證明角色的身分、歷史與狀態全部都保存在資料裡，角色「活在」資料之中。
    • 講者將同樣的框架套用到 AI agent 上：一般人談論 agent 時常常指錯對象，說 agent 就是模型(model)或執行環境(runtime)。這些東西確實重要，也是我們實際互動、運行 agent 的介面，但它們都不是 agent 本身。
    • 講者主張 agent 真正的身分是它的資料，具體來說就是「日誌(log)」。
    • 日誌的定義：在最基本的層次上，日誌是 agent 的「僅追加(append-only)」事件歷史紀錄，內容包含每一次使用者輸入(user input)、每一次模型輸出(model output)、每一次工具呼叫(tool call)、工具回傳結果(tool result)、權限(permission)、以及失敗(failure)。
    • 核心邏輯：agent 所經歷的每一次狀態轉換(state transition)都會被寫入日誌。這代表 agent 的身分並不綁定在執行環境、模型或工具上——這些元件的角色只是「解讀並附加」內容到日誌中，也就是讀取日誌、根據日誌行動、再把下一個事件寫回日誌。
    • 因此得出結論：光靠日誌本身，就足以還原(resume)整個 agent 的狀態——這正呼應了前面 Skyrim 存檔的類比，日誌就是 agent 的「存檔檔案」。

    “「代理(agent)就是它的資料，具體來說，就是日誌(log)。」”

    “「僅僅靠日誌本身，就足以還原(resume)這個代理。」”

24. 24

    把長時、常駐型代理產品化:Era 的可規模化部署經驗

    Roland · Era

    ▶ 6:30:04

    Roland（Era 共同創辦人，前 xAI Agent Infra 團隊）分享如何將「長時間運行、常駐型」的 AI 代理產品化並規模化部署給客戶。核心主張是 2026 年後的 agent 產品化三大支柱：Loop 本身就是產品、系統蒸餾（system distillation）才是護城河、以及用「每瓦特產生的價值」（value per watt）作為衡量與優化指標。

    • Roland 與共同創辦人原本在 xAI 做 agent infra，幾個月前離職創立 Era，專注研究「常駐型、長時間跑的 agent」該如何進到下一階段的部署方式。
    • 產業敘事演進：先是一切歸功於 RLHF 讓模型推理變強 → 接著大家發現模型只是商品（commodity），重點在 harness（骨架/工具鏈）→ 現在則進化到「loop 才是產品」，重點不再是寫程式碼本身，而是設計迴圈。
    • 舉例「ClaudeBolt」（現稱 OpenClaude）：開發者 AJ 打造第一個圍繞它的 loop，用來自動去 Reddit 找車價、比對經銷商庫存、讓多家經銷商互相競價、驗證價格合理後鎖定成交，最終真的買到車——被視為「loop 即產品」的第一個實例，本身幾乎可以獨立成一家新創公司。
    • 這種 loop 之所以有效，源自 1970 年代美軍發展的 OODA loop（觀察-定向-決策-行動）概念：戰鬥機飛行員在快速變化環境中反應的邏輯，如今被套用在模型呼叫工具、觀察結果、再行動的訓練與運作模式上。
    • Loop 成功與否取決於兩件事：訊號（signal）品質決定成功率，驗證器（verifier）品質決定能否正確判斷這個成功是否「真的成功」。
    • 「第二層迴圈」：把第一個 loop 產生的結果（artifacts）回饋進去，用來持續改進系統——這是 Roland 第二個核心論點「系統蒸餾（system distillation）才是護城河（the mode）」的來源。
    • 每次 loop 都會產生大量有用資訊：harness、profile、eval、模型選擇、資源、工具、環境設定等，關鍵在於要把這些「可攜帶化（portable）」「版本化（versioned）」，並讓它隨時間演化，這正是 RL 研究領域中「data recipe」的概念——透過不斷調整資料配方來對抗幻覺、reward hacking 等問題，最終收斂出一份配方。但目前業界對 harness／AI 系統整體並沒有這樣的標準做法。
    • Era 提出「agent's recipe（代理配方）」概念：讓你能重現「前沿級（frontier）」AI 系統的方法論，是持續進步、不綁定特定平台或模型供應商、由你（公司）自己掌控的資產。
    • Loop 的角色應該是把系統蒸餾成 recipe：失敗模式應轉化為 judge 和 eval；重複出現的行為應轉化為 skills 和 prompt；使用者的挫折感應轉化為 harness 的擴充功能與記憶模組。
    • Era 把這套 recipe 方法建立在 Pi harness 和 Harbor（用於 eval）之上，並把一切存進 Git repo 做版本控管，讓 agent 能持續追蹤「改了什麼、為什麼改」。這套系統設計理念是「由人擁有（owned），由 agent 管理（managed）」——擁有者像是房間裡「品味最高」的人，agent 要不斷校準自己去貼近這個「品味（taste）」。
    • Recipe 的本質是把「創作者的品味」編碼進 agent，若要使用別人的 recipe，等於也帶入了對方的品味——不只是 harness 或模型的問題，而是「你是怎麼得出這個 recipe、為什麼」的問題，這是可重現產品/服務背後的關鍵。
    • Era 已釋出早期版本工具「Pi.recipes」，性質類似 2025 年時的「skills」但更進一步：涵蓋如何把品味編碼進 eval、如何跑 eval、如何用 loop 持續改進這些 eval、如何處理訊號、如何為不同模型搭配不同的 harness profile 等完整流程。
    • 第三個論點「value per watt（每瓦特產出的價值）」：以 Cursor 和 Cognition 為例，它們的路徑是先做出最好的產品，再做出最好的 eval，最後根據前兩者訓練出最好的模型——Roland 認為這是未來所有領域（不只 code，還包括客服、法律、研究等）都會走的路徑。
    • 衡量 value per watt 分兩步：第一步是如何測量「產生的價值」，第二步是如何判斷這個價值划不划算（economically viable，即產生同樣價值花費是否夠低）。
    • 從 base harness／base eval 出發，唯一能知道「什麼是 frontier」的方法就是實際把系統跑在生產環境中——沒有辦法在開始之前就預知 frontier 長什麼樣。到達 frontier 後，下一步的研究重點是如何做到「經濟上可行」（不超支去產生這些價值）。
    • 現在已有大量微調 API 與基礎設施把技術門檻抽象化了，真正缺乏的是「know-how」——特別是如何把品味編碼進 eval、如何在實驗中驗證它，這正是 Era 想推動的方向。
    • Eval／實驗不應該只被當作「測試」，而是「創作者的品味」，agent 要能自我複製與自我改進去逼近這個品味；這也呼應了 RL 領域把「品味製造者」轉化成環境與 eval，進而把品味蒐煉進模型權重（weights）的思路。
    • 「Worker」是內層迴圈，負責產生所有 artifacts；「品味」則決定要看哪些 artifacts、要改什麼，並產生「候選改動（candidates）」；「實驗（experiments）」則是自我校準機制，驗證這個品味是否真的在正式環境中被使用者認可——確保不只是創作者透過離線 eval 感到滿意，終端使用者也認同這是「好」的結果。
    • 實例演練——招募（talent sourcing）agent：起始版本很簡單，配備 web search、LinkedIn 工具、幾個常見於 Codex／Claude Code 這類 harness 的 subagent，以及一份系統指令描述「你是招募專員」。
    • 第一步「理解訊號」：用 pattern 分析執行軌跡（trace），找出常見行為或使用者挫折點，聚類成模式。例如發現 agent 傾向去聯繫大型科技公司員工（如虛構情境中想挖角 John Carmack），但招募方真正想找的是「隱藏的璞玉（hidden gems）」而非知名大廠員工——這是人類事前不會想到要寫進規則、卻是 agent 實際運作中暴露出的行為。
    • 第二步「校準、Judge 與 Eval」：建立一個能檢視軌跡並辨識出該模式的 agent（例如判斷這個 agent 是否去聯繫了 Google 員工而非在 GitHub 上尋找隱藏人才）。建立這類 eval 對 agent 而言並不難，真正需要人類介入的，是「校準」——即人類判斷「我們是否同意這個方向：更重視隱藏璞玉而非大廠員工」，而不是要人類親手去寫 eval 程式碼。Agent 應該負責把創作者的品味轉譯成程式碼。
    • 第三步「產生 recipe 候選版本」：這些候選版本應該就是你真正想要「試味道」的差異點（diff），並先用離線 eval 集驗證。
    • 第四步「上線測試」：真正的考驗是終端使用者是否認同你「不聯繫大廠員工」的這個品味選擇，可用多臂拉霸機（multi-armed bandit）式的 A/B 測試驗證。
    • 一旦驗證「我確實有好品味，使用者也認同」，就可以晉升（promote）到下一版 agent recipe，如此反覆循環，持續把「什麼是好」的判斷編碼進能替其他人重現同等服務／產品品質的 agent 中。
    • Roland 用電影《穿著Prada的惡魔》裡的角色 Miranda 做比喻：目標是讓別人能持續問「Miranda 在這種情況下會怎麼做？」並把這種思考方式編碼進 agent，讓 agent 在更高層次上重現同樣的判斷。
    • 三點總結（takeaways）：
    • Loop 就是產品——你要自動化自己成為那個「更高層次的評審者」，並確保第二層的 loop agent 能對要推上生產環境的 agent 套用同樣的判斷標準。
    • 系統蒸餾就是護城河——持續把品味注入 worker，讓它們持續自我驗證、彼此協作，是最該關注的重點；做得越快，就越能建立起在垂直領域 AI 公司中難以複製的優勢。
    • Value per watt 是進度指標——先確認你產生的工作是有價值的，再確認這個經濟帳算得過來；價格差距本質上決定了使用者會不會從 Claude Code 這類通用工具轉換到你提供的專屬產品。
    • Era 團隊表示正在打造相關的生產部署產品，歡迎垂直 SaaS 公司、agent lab 交流「如何把 auto research 概念落地到自己產品」的經驗。
25. 25

    多代理 AI 村落中的自動研究:如何評測與改進長期帶狀態的代理(Project Paradox)

    Irina · Supercell

    ▶ 6:54:54

    這場 talk 分享 Supercell AI Innovation Lab 打造的多代理遊戲框架 Project Paradox，並說明團隊如何借用 Karpathy 提出的「auto research」概念，建立一套實驗迴圈來評測與改進代理在長時間、跨多次互動下的社會行為一致性。核心主張是：長期帶狀態的代理系統光靠加記憶體（RAG）並不夠，必須用受控情境（scenario）、行為評分卡（scorecard）與可控的策略介面（policy surface）反覆做實驗，才能真正改善代理在長時間尺度上「誰知道什麼、誰告訴了誰、什麼是真的/不確定的/過時的」這類問題。

    • 講者 Irina 曾任職 Microsoft 與 Supercell，這次介紹的 Project Paradox 是她和隊友 Natsum、Manikandan 在 Supercell AI Innovation Lab 開發的模組化 AI 框架，讓開發者能在遊戲中插入能互動、競爭或合作的自主代理，成為動態的遊戲夥伴。
    • 代理的能力包括：有意圖地移動（前往任何地點或人物，受自身記憶、情緒、好奇心驅動）、與世界互動（拾取/放下物品）、感知周遭環境（物品、其他角色/代理）；開發者也能自行擴充新的動作類型。
    • 代理會對周遭事件做出反應，事件會即時影響其信念與情緒；代理也能主動與其他代理或玩家展開對話，對話會被存入記憶並反過來影響其情緒、信念或目標，讓遊戲更「有生命感」。
    • 架構刻意設計為「帶狀態」，包含四個關鍵組件：
    • 每個代理獨立的記憶（per-agent memory）：以 RAG 為底層，每個代理有自己的記憶命名空間，避免記憶在代理間互相污染。
    • 情緒向量（emotion vector）：以 joy、sadness、fear、anger、disgust 等數值表示，每次事件或對話後更新。
    • 信念分數（belief score）：代理對其他代理與玩家的信任矩陣，互動後由 LLM 判斷信任值該上升、下降或不變。
    • 記憶重要性分數（importance score）：每則記憶會被 LLM 評估重要性，舉例如「幾天前吃了什麼晚餐」通常不會記得，但「幾天前有人被謀殺」會被記住；超過門檻的記憶會被存進獨立的快取，方便日後更好地被檢索。
    • Demo 範例：玩家請代理 Blossom 去野餐，她會自主規劃一連串動作（先拿糕點再前往野餐地點），事後對話時也能根據情境正確回應——顯示短期互動下架構運作良好。
    • 但在長時間跨度下，社會一致性開始變弱：範例中一個代理散布「芒果特賣」的謠言給另一個代理，經過多個事件後玩家再問起此事，代理卻無法給出預期的正確語境。常見的失敗模式：
    • 系統記得話題大概內容，但遺失資訊來源（source）。
    • 謠言（rumor）會被講成確定事實（fact），而非仍標示為「可能」。
    • 代理知道某個事實，卻在規劃行動時沒把它用上。
    • 因此團隊提出核心問題：如何改善多代理系統的「長期社會行為」，而不只是單次回應的品質？這促使他們引入 Karpathy 提出的 auto research 概念：與其手動調 prompt、看單一 demo 覺得滿意，不如定義情境套組（scenario suite）、跑代理、收集軌跡（trace）、對行為打分、微調一小塊策略介面，只保留真正能提升分數的改動。
    • 在此框架下，Project Paradox 是「實驗台（lab bench）」，auto research 則是圍繞它的「實驗迴圈」。且重點不只是優化 RAG 檢索，而是優化整個「代理協議（agent protocol）」：代理如何寫入記憶、檢索記憶、傳達不確定性、更新信任、歸因來源、根據新事實重新規劃。
    • Auto research 層被定位為村落之外的「元系統（meta system）」，不是村落裡的另一個代理；村民只有各自的局部視角（只知道自己看到、聽到、記得或推論的東西，彼此間沒有共用記憶庫，資訊只能靠溝通傳遞）。Auto research 層則讀取整場模擬的完整軌跡，比對情境的「地面真相（ground truth）」，對行為打分，並對代理協議或認知策略提出受限的改動，再重跑情境，檢驗「社會層級的行為」是否變好——這是從評估「單一回答」轉為評估「整場運行」的關鍵轉變。
    • 一次完整的實驗迴圈流程：
    • 定義受控情境（例如一個代理得知公開事實、或聽到謠言）。
    • 跑模擬，收集結構化軌跡（觀察、對話、記憶寫入、檢索、信念更新等）。
    • 對行為打分：資訊有沒有如預期擴散？來源歸因是否保留（代理是否記得是誰先說的）？不確定性有沒有維持？代理有沒有根據自己實際知道的東西行動？
    • Auto research 層提出一個小幅度的策略改動（不能整個重寫應用程式，只能編輯受控的策略介面）。
    • 重跑情境；若分數提升且護欄（guardrails）沒被破壞，就保留改動；否則直接還原。
    • 為何需要「受控情境（controlled scenarios）」：任由代理自由遊走雖然看起來很酷、會產生有趣互動，但很難判斷系統是否真的變好，因此必須設計具體情境來測試，例如：
    • 公開事實擴散測試：代理 A 得知「麵包店明天要關門」，正確的代理是否學到這件事？是否記得是誰說的？有沒有據此調整計畫？
    • 謠言不確定性測試：代理 A 聽說「代理 C 可能要離開村莊」，這個謠言擴散後，「可能離開」會不會被誤傳成「正在離開」（確定事實）？
    • 重新規劃測試：團體原有計畫，但某代理得知原定路線被封鎖，其他代理是否會更新並互相溝通以避免執行錯誤的計畫？
    • 重點不是這些具體情境本身有普世性，而是長時間代理行為評測必須依賴一整套情境套組（scenario suite）。
    • 跑過一輪 auto research 迴圈後，重新測試芒果謠言的情境，這次玩家事後問起時，代理終於能給出符合語境的正確回應，相較於原本失敗的版本有改善。
    • 評分不能只用單一模糊指標（如「代理品質」），這會掩蓋掉真正有趣的失敗模式，因此需要「平衡評分卡（balanced scorecard）」，依情境類型分別衡量：
    • 擴散（diffusion）：n 步之後有多少代理知道該事實（reach）。
    • 來源可信度（provenance）：知道該事實的代理中，有多少人記得來源（source retention）。
    • 謠言：不確定性保留程度（uncertainty preservation）與「假確定率」（false certainty rate）。
    • 規劃：行動一致性（action consistency）與重新規劃所需時間（time to re-plan）。
    • 隱私：資訊的containment（是否外洩不該擴散的資訊）。
    • 只優化單一指標會產生壞行為：若只優化「擴散」，代理可能學會過度分享一切；若只優化「記憶回憶率」，可能產生雜訊或陳舊記憶。平衡評分卡能防止 auto research 代理「作弊」（gaming）單一分數。
    • 另一個重要工程教訓：必須把「可編輯的介面」限制得很小。Auto research 層不能有權限隨意重寫整個程式碼庫，而是要凍結「測試框架（harness）」、情境與指標本身，只暴露真正想優化的那一小塊。在 Project Paradox 中，這包括：記憶寫入策略、檢索策略、溝通用的 prompt、信念/信任規則、來源歸因、回覆觸發條件等。這讓搜尋過程有改進行為的空間，但同時防止它直接「作弊」評測——這正是「LLM 隨意寫補丁」和「LLM 在受控策略空間內搜尋」的差別。
    • 具體策略調整範例：
    • 若「來源歸因」消失 → 改動策略為「在記憶寫入與摘要中保留來源」。
    • 若「謠言硬化成事實」→ 改動策略為「儲存信心值、標記一手/二手消息、轉述不確定訊息時要求加上模糊限定語（hedging）」。
    • 若「公開事實停留在局部、沒有擴散」→ 改動策略為「對有用的公開事實做不同分類，讓代理主動分享重要的來源證據」。
    • 這些都是對代理協議的小改動，但能對整體社會層級行為產生較大影響。
    • 講者強調需謹慎看待成果：沒有經過反覆的 loop 驗證，不能說系統「整體」變好了；他們想主張的是——這是一個適合暴露給 auto research loop 的介面：小到可控，但又足夠豐富，能在一定程度上改變社會行為。
    • 最大的心得是「光有記憶還不夠」：加上 RAG 記憶不代表就能得到理想的長期一致行為。代理有時需要知道資訊來源（是一手、二手、已驗證還是不確定），有時需要把「原始情節記憶」和「代理目前相信的內容」分開儲存，而且必須透過情境（scenario）而非單憑直覺（vibes）來測試行為。
    • 回滾（rollback）機制不是可有可無的：優化社會行為時，一個改動可能同時改善某項指標卻損害另一項——例如加速公開事實擴散的策略，可能同時洩漏私人資訊；提升記憶回憶率的策略，可能增加使用陳舊記憶的比例。因此迴圈設計要像「棘輪（ratchet）」：嘗試改動、打分、只有在評分卡整體提升且護欄沒被破壞時才保留，否則捨棄。
    • 講者認為這套方法論不只適用於遊戲代理，也適用於：
    • 客服代理：需要知道政策更新從何而來、是否取代了舊答案。
    • 個人助理：需要記住先前承諾，並在使用者想改變承諾時做出修正。
    • 研究型代理：需要來源歸因、引用、矛盾處理與假設更新。
    • 程式代理（coding agents）：需要跨 issue、跨檔案、跨隊友、跨變動需求維持長期上下文。
    • 工作流代理（workflow agents）：需要存取權限控制、交接（handoff），並在世界狀態改變時重新規劃。
    • 這些系統都有共同的底層問題：它們會維持會影響未來行動的「狀態」，因此都需要受控情境與行為評分卡。
    • 講者總結的長期代理實作食譜：凍結測試框架（harness）、定義情境、記錄軌跡、對行為打分、只暴露一小塊策略介面供搜尋，並只保留通過測量驗證的改動。真正該問的問題是：「在受控的多次運行中，系統的行為是否真的變好了？」

    “"Long horizon agents need experiments and not just prompts."”

    “"The loop should basically be like a ratchet. Try a change, score it, keep it, only if the scorecard improves and guardrails hold."”

    “"You do not want a single vague metric like agent quality. This will hide all the interesting failures."”

26. 26

    用編程代理製作視覺產物:以 HTML 生成投影片、文件與影片

    Amol · Nori Agentic

    ▶ 7:16:22

    這場 talk 主張:大家以為 coding agent 只會寫程式碼是行銷話術造成的誤解,實際上 agent 幾乎什麼都能做,關鍵是要「像 agent 一樣思考」。講者以 Nori Agentic 的實務經驗說明,只要用 HTML/CSS 這種語言化、結構化的媒介取代圖形化畫布工具,coding agent 就能高品質產出投影片、文件甚至影片,而不需要靠人類慣用的「拖拉點擊」工具。

    • 全世界每天花費約 3.4 萬人年(34,000 human years)在製作投影片上,而這些時間大多不是花在思考內容,而是花在格式排版、品牌套用、元素搬移等瑣事上;講者估計一份要花 10 小時做的投影片,把這些雜務拿掉後其實只需要約 25 分鐘。
    • 傳統工具(PowerPoint、Slides、Figma、Canva)本質上都是「操作畫布」的工具,建立在人類的手眼協調與空間感之上(點擊、拖曳、對齊格線等),底層雖然有資料結構,但格式只有該應用程式自己讀得懂。
    • 把這些畫布類工具直接交給 agent 使用時,輸出常常「全部跑掉」:元素重疊、文字看不到、對不齊,結果一團糟。
    • AI 懷疑論者常說這不只是工具問題,而是 agent 根本無法對「空間」做推理,像 ARC-AGI 這類 benchmark 就是建立在這個前提上。
    • 講者引用開發者 Simon Willison 的知名測試:要求每個新模型「畫一隻騎腳踏車的鵜鶘」,但限制只能用 SVG 繪製,用來快速檢驗模型有沒有空間推理能力;實際測試結果顯示模型畫出來的圖非常糟糕。
    • 講者反駁「這代表 agent 注定畫不好圖」的悲觀結論,認為問題不在模型本身,而在於「媒介」選錯了:就算叫人類手寫 SVG 座標數字去畫一隻鵜鶘,人類自己也做不到——SVG 就是一堆數字,人是靠圖像思考的,不是靠數字座標思考。
    • 現有的 agent 繪圖工具(Figma MCP、PowerPoint CLI、截圖後替換的循環流程等)全都在模仿「人類用畫布作業」的方式,但 AI 不是人類;要求 AI 用像素/座標畫布工作,就等於要求人類手寫 SVG 一樣不合理。
    • 正確做法是給 AI 「它天生擅長的媒介」——語言、token、結構,而不是像素座標。
    • HTML 正是這種語言:它有大量的訓練語料、模型見過並理解億萬個範例,而且 HTML 標籤本身帶有語意(標題、圖表、網格),瀏覽器負責把結構渲染成像素,模型全程不需要指定任何座標,圖表、排版、字體、動態效果都能「免費」取得。
    • 同樣是畫鵜鶘騎腳踏車的任務,改用 HTML 讓模型輸出後,同一隻鳥但因為是結構化格式,模型能真正推理,而且人類可以逐行閱讀、套主題、編輯。
    • 講者反思:自己一輩子用 PowerPoint 做投影片,以為「投影片」和「PowerPoint」是同義詞,但其實 PowerPoint 只是編輯工具,「投影片檔案」只是其中一種呈現模式(presentation mode);觀眾根本不在乎你是怎麼做出這個呈現模式的,所以編輯格式其實可以任意選擇——選 agent 已經很擅長的 HTML,有需要再轉檔成 PDF 等其他格式。
    • Nori Agentic 內部大量使用這個「HTML 技巧」:公司的董事會簡報(board decks)、業務簡報(sales decks)都是這樣做出來、實際拿去發送與展示的;文件(docs)也用同樣方式,讓文件有色彩、有生命力,同時遵循公司品牌規範;甚至連影片(包含這場 talk 本身在展示的內容)也是純粹用 HTML/CSS(「就是一堆 div 疊起來」)做出來的。
    • 講者強調「純文字通常是為了方便而做的選擇,但如果真的想做出有用的成果,通常是錯誤的選擇」——幾乎任何內容加上結構與色彩都會變得更好。
    • 講者也提醒:光有漂亮的投影片本身沒有價值,還是得先取得填充內容的實際資料;解法同樣是「像模型一樣思考」——只要讓模型能存取你的資料(例如通話逐字稿、email),就能讓模型端到端(end-to-end)直接把整份投影片做出來,讓 agent 處理所有繁瑣工作,人類專注在願景與敘事(story)上。
    • 這正是 Nori Sessions 產品提供的能力;講者提到自己曾在通勤地鐵上,用手機透過 Nori bot(深植在公司資料脈絡中)完整做出整份董事會簡報。
    • 講者提到 Nori 產品已經內建了做到這一切所需的功能,不需要重新造輪子。

    “「如果你問我,問題不在模型,而在媒介(medium)。」”

    “「你要給 AI 依照它思考方式設計的工具——不是用像素,而是用語言。文字、token、結構,那才是它天生的媒介。」”

    “「停止用『使用者』的方式思考,開始像模型一樣思考,並給它正確的語言。」”

27. 27

    10x:重新想像行動裝置開發工作流

    Zorail Zayin

    ▶ 7:23:11

    講者 Zorail Zayin 是擁有14年經驗的行動端工程師，主題是探討為何「用AI寫code」並沒有讓大家真正感受到承諾中的10倍生產力。他借用工廠從蒸汽機換成電動機的歷史類比，主張真正的生產力躍進不是換掉工具本身，而是重新設計整個工作流程；並提出以「雲端沙盒（Cloud Sandbox）」讓PM、設計師、開發者、QA都能直接在同一份code上與agent互動，消除跨工具迭代造成的摩擦。

    • 講者是14年經驗的行動端軟體工程師，開場提到幾個月前大家還在用IDE手動寫code，現在已經轉變成用Claude Code、Codex、Cursor等以聊天方式跟AI互動下指令，IDE只在debug或agent解決不了的問題時才會用到。
    • 大家都說AI帶來10倍生產力，但講者直言不管是個人、團隊還是整個公司層級，他都感受不到這種10倍提升。
    • 講者用工廠史做類比：工廠從蒸汽機換成電動機時，一開始並沒有帶來預期的10倍、20倍、30倍生產力提升，儘管電動機本身效率更高。
    • 原因是當時工廠只是把蒸汽機換成電動機，但機器擺放位置仍然依照舊有邏輯（靠近中央蒸汽機、依耗電量分佈），而不是依照生產流程從頭到尾排列。
    • 真正的生產力躍進發生在後來——當人們把電動機做小、裝進每一台機器裡，工廠因此可以依照實際工作流程重新佈局，這時才真正出現10倍、20倍以上的生產力提升。
    • 講者類比現況：AI開發也是一樣，大家只是換了「引擎」（用AI寫code取代手寫），但PM、設計師、使用者、開發者、QA之間反覆迭代的舊workflow並沒有改變。
    • 現行workflow的問題：PM有想法→跟設計師迭代→跟使用者迭代→跟開發迭代→再跟設計師迭代→跟QA迭代→再跟開發迭代……最後才進production，過程中「iteration」這個詞反覆出現。
    • 每一次迭代都會造成context switch、時間浪費，以及額外的溝通和同步成本；AI只是加速了「寫code」這個環節，並沒有消除這些迭代與摩擦本身。
    • 講者提出重新想像：如果不是「設計用Figma、寫code用IDE、測試用另一套工具、上架又是另一套流程」，而是所有角色共用「同一個工具、同一份code base」會怎樣？
    • 設想一：設計師直接在code上做設計，完成後直接送PR給開發者，而不是把設計稿丟給開發者自行摸索如何實作。
    • 設想二：QA直接跟agent互動，拿到一個模擬器連結，直接告訴agent要測什麼、要注意什麼，發現問題就直接告訴agent怎麼修。
    • 要落地這個願景有幾種做法。第一種：叫所有PM、設計師、QA自己安裝Xcode、Android Studio，學會操作simulator/emulator——但這會占用約200GB儲存空間並吃掉大量記憶體，講者認為多數人會拒絕這個方案。
    • 第二種：把流程整合進CI——但CI build通常要花20到40分鐘，agent不可能為了確認一次iOS build是否成功而白等40分鐘。
    • 解法：Cloud Sandboxes（雲端沙盒）。這個概念其實已經存在多年，只是還沒被真正應用在行動裝置開發上。
    • 雲端沙盒運作方式：agent透過CLI跟雲端溝通，為單次迭代建立一個小型VM，VM在30秒內完成開機並build，並在Codex/Cursor等工具介面內顯示一個in-app瀏覽器裡的模擬器畫面，使用者可直接下指令互動（例如「把這顆按鈕改成返回」），agent修改程式碼後直接push並開PR。
    • 完整工作流：設計師可直接在code上工作，完成後把PR送給開發者；開發者可同時開2～4台VM並行迭代不同版本，再送PR給QA審查；QA直接告訴agent要測什麼、要修什麼，最後直接送上架審核（store review），全程都在同一份code base上完成。
    • Demo描述：畫面左側是跟agent的聊天介面，右側直接顯示App實際畫面；設計師與agent互動、講出想改的東西，馬上在畫面上看到變化，因為build跑在雲端所以build時間與預覽時間都更快；設計師不需要安裝Xcode或Android Studio，就能在自己筆電上與agent反覆迭代，完成後直接請agent開PR送交開發者。
    • 講者總結：真正讓生產力達到10倍的關鍵，不只是「使用AI」，而是「用AI重新設計workflow」，把過去被視為理所當然的摩擦（跨工具迭代、context switch、溝通同步成本）整個移除。

    “"AI sped up code, but it didn't eliminate the friction. It didn't eliminate the iteration."（AI讓寫程式碼變快了，但並沒有消除摩擦，也沒有消除迭代。）”

    “"This workflow is what makes us 10 times more productive, not only because of using AI, but because of using AI to change the workflow, reimagine it, and remove all that friction that we took for granted in the old times."（真正讓我們達到10倍生產力的，不只是使用AI，而是用AI重新設計整個workflow、重新想像它，並移除過去我們視為理所當然的所有摩擦。）”

28. 28

    讓人類留在迴圈中:未來工程師負責選擇該做什麼並為結果負責

    Addy Osmani · Google

    ▶ 7:47:13

    Google 的 Addy Osmani 主張,隨著 AI 生成程式碼與代理(agent)自動化工作變得普及,工程師的核心價值將從「能不能寫出程式」轉變為「能否判斷什麼值得做、並為結果負責」。他提出 alpha(領先優勢)與 decay(優勢衰退)的框架,說明速度、記憶、驗證等能力都會被前沿模型追上,唯有建立在證據之上的判斷力與可被追究的「簽名」(accountability/signature)才能長久保值。

    • 未來工程師的定義,是能選擇「什麼值得做」的人,並擁有證據(evidence)、理解(understanding)與裁決(verdict)——裁決不是當法官,而是要為生產決策負責:是否要出貨、擋下、重新導向,或接受風險。
    • 品質(quality)只是產生證據,裁決(verdict)才是分配責任;而「可被追究性」(answerability)才是讓人能站得住裁決的基礎。
    • 引用 Boris Cheny 的觀點:傳統工藝分工的界線正在模糊,角色開始圍繞「工作本身」重新組合;重點不再是職稱,而是你能擁有系統的哪一部分。
    • 提出一套工作模式分類(taxonomy):prototype(原型)、build(建構)、sweep(清理)、grow(成長)、maintain(維運)。代理(agent)能協助所有模式,但稀缺的不是「執行任務」本身,而是知道產品需要哪種模式、適用什麼品質標準、誰該為結果負責。
    • 回顧產業演進三階段:harness engineering(協作代理 = 模型 + 情境、工具、檔案系統、Git 等外殼,把智能轉化為可委派的工作)→ loop engineering(不只是單次提示,而是設計持續提示、檢查、記憶、決策下一步的系統,讓 agent 開始像基礎設施)→ software factory(如 Dex 演講所提,agent 在內部迴圈運作並產出證據,但人類仍在做生產決策——重點不是把人類移出迴圈,而是把人類判斷移到最高槓桿的檢查點)。
    • 引用 Sonar 2026 調查:AI 輔助程式碼已不再是邊緣現象,在許多程式碼庫中佔比越來越高;另一項 Sonar 研究發現,乾淨與雜亂的程式碼庫其(agent)通過率相近,但乾淨程式碼使用較少 token、較少需要重新查閱——代表可維護性能提升代理工廠的效率。
    • 生成變便宜不代表審查也變便宜:Sonar 數據顯示幾乎所有工程師都對 AI 程式碼持懷疑態度,但大約只有一半的人「每次都會」在提交前驗證——形成「不信任卻沒有足夠審查產能」的危險落差。安全感來自讓驗證變得更便宜、更清楚、更難被跳過。
    • 從組織層面看,當採用速度遠超治理制度更新速度時,審查與驗證會成為瓶頸;必須面對的硬問題包括:模型是否真的動過這個檔案?是什麼限制條件指導了這次工作?產生了什麼證據?接受了什麼風險?誰擁有這個結果?
    • 提出兩個關鍵概念:alpha(你今天能做、而模型還不能做的能力落差)與 decay(這個落差消失的速度)。如果你的價值建立在某項「能力」上,前沿模型終將趕上。
    • 談「品味」(taste):引用 Paul Graham「當任何人都能製造任何東西時,選擇要做什麼變得極其重要」;但提醒「品味」容易被用來包裝說不清楚的部分。引用 Mitchell Hashimoto 更具體的定義:品味是「在尚無客觀指標時,做出高品質判斷的能力」——強調品味要能轉化為可累積的評論、案例與更好的判斷力,而不是玄學。品味本身也是一種 alpha,會隨模型從範例與偏好中學習而重置,只是衰退速度比其他能力慢很多。
    • 用「衰退測試」檢視各項能力:速度已衰退;記憶力已被 harness 取代;驗證正被移入 harness、評測(evals)、靜態檢查與模型批判中;品味衰退最慢,但仍會隨模型演進而重置;即使判斷力也是漸進的斜坡而非牆——策略不該是死守某項能力,而是持續把自己的邊界往上移動一個層級。
    • 因此更好的策略問題不是「agent 能做什麼」(這份清單只會越來越長),而是「只有人類才能負責的是什麼」——不是因為人類特殊,而是某些決策需要擁有權、情境判斷、風險承擔與責任歸屬。
    • 「工程師」一詞需要更嚴格地定義:更多人能讓電腦做事是件好事,建構者的潛在市場前所未有地大,但工程師不只是能寫程式讓東西存在的人,而是能對系統進行推理、思考限制條件、為權衡辯護、管理風險,並在出問題時被找上門負責的人。
    • 三個工程師應避免的陷阱:
    • 認知債務(cognitive debt):對如何解決問題的理解與記憶逐漸流失,因為越來越依賴 AI。程式碼層面就是「你的 repo 裡存在多少程式碼」與「團隊中有多少人真正理解它」之間的落差;「委派深度」變得重要——測試能通過、PR 能合併,團隊卻可能失去解釋自己所出貨系統的能力。代理現在能在系統裡運作很久,人類容易失去追蹤——30秒的執行像一次互動,但小時或天級別的長時任務其實是一條「工作串流」,一旦多個並行執行,審查不能只是最後看一眼,必須變成整套控制系統。
    • 認知投降(cognitive surrender):盲目接受 AI 答案。委派是「做這件事,然後給我足夠證據讓我判斷」,仍保有自己的判斷;投降則是「在我形成自己意見之前,你的答案就是我的答案」。引用 Wharton 研究:當 AI 答錯時,73% 的人仍認為自己選對了答案,而且更有信心——真正的失敗模式不是使用 AI,而是「借來的信心」(borrowed confidence)。
    • 編排稅(orchestration tax):越來越多人同時跑數百、數千個 agent,但更多 agent 運作不等於「有更多的你」,認知帶寬無法平行化——每建立一個迴圈,就會增加需要路由、合併、驗證、整合的決策量。解方不是減少 agent 數量,而是像設計系統一樣設計你的注意力:你在哪裡介入、獲取什麼、重複使用什麼。
    • 職涯數學:某項優勢(edge)的半衰期可能只有一次模型發布的時間——速度、記憶、驗證、甚至品味都會隨前沿推進而移動;但「簽名」(signature,即你的信譽、專業聲譽——出品的名字、人、團隊、機構)的半衰期長得多。技能能賺取槓桿,而可被追究性(accountability)能把槓桿轉化為信任。
    • 劃清界線:agent 可以選擇、路由、合併、升級、在政策內操作(在許多系統裡它們也應該這麼做),但「執行」與「責任」是不同的事——agent 能遵循你的作業手冊(run book),但無法繼承後果。出問題時,問題是「誰理解這個政策?誰接受了風險?誰擁有爆炸半徑(blast radius)?」
    • 「高主動性」(high agency)重新定義:不是「我自己做完所有事」,而是知道何時該委派、何時該檢查、何時該停下、何時該把自己的名字放上結果——是「帶有判斷的擁有權」,而非單純的努力表演。提出一個「主動性階梯」:最底層是發現問題就丟給系統;往上是執行、診斷、提議、建議、解決;最稀有的頂層是「鑑別力」(discernment)——判斷這個問題到底值不值得投入。
    • 操作模型:agent 能運行更多「內部執行迴圈」(調查、實作、測試、回報),這是能力(capability);但「外部迴圈」——決策、驗證、批准、擁有——仍是工程本身,是主動性(agency)。Agent 回傳的是證據:diff、測試、日誌、理由(rationale)、追蹤(traces)、軌跡(trajectories)、截圖等;而工程真正開始於:我們判斷這件事值不值得做、我們驗證證據是否足夠、我們批准/重新導向/擁有進入生產環境的結果。
    • 提出操作準則:「能解釋清楚才能出貨」(Explain it or don't ship it)——不是要人類逐行閱讀或撰寫程式碼,而是必須有人真正理解到能為這段工作辯護的程度。類比大型/企業程式碼庫中的 OWNERS 檔案概念:架構中的每個部分都該有人對其負責。
    • 收尾主張:自動化會提升所有人的「地板」(floor),工程持續往上一個層級移動;新的工作可能是迴圈設計(loop design)、證據設計(evidence design)與舊系統維運(brownfield stewardship)。少打幾個字不代表少一些工程工作,而是代表有更多需要品味、驗證、擁有權與用心的表面積。
    • 歷史類比:每次讓寫軟體變容易(高階語言、框架、雲端、低程式碼),大家都預測世界會需要更少軟體工程,結果恰恰相反——成本降低會釋放潛在需求(latent demand),原本覺得不可行的想法會被解鎖。Agent 也會產生同樣效果:不會消除工程工作,而是把瓶頸從「我們能不能做出來」移到「這東西該不該存在,而我們能不能為它負責」。

    “"Explain it or don't ship it."(能解釋清楚才能出貨。)”

    “"The failure mode is not using AI, but it's borrowed confidence."(失敗模式不是使用 AI,而是借來的信心。)”

    “"Build the factories, keep the lights on, own the verdict."(建造工廠、維持運轉、擁有裁決權。)”

29. 29

    智慧的成本:AI 競賽現況與代理式工作負載的價格拆解

    Micah Hill-Smith、George Cameron · Artificial Analysis

    ▶ 8:05:34

    這場talk由Artificial Analysis共同創辦人Micah Hill-Smith與George Cameron主講,主題是「智慧的成本」。核心主張是:雖然在固定智慧水準下,token價格每年持續下降5-10倍,但因為任務難度、agent操作步驟數與模型輸出量同步暴增,實際完成單一任務所花費的總成本反而不斷攀升——這兩個看似矛盾的趨勢,正是理解2026年AI成本地景的關鍵。

    • Artificial Analysis是獨立AI基準測試公司,測試晶片、雲端基礎設施、模型與agent,評估「多聰明、多快、多貴」,並與OpenAI、Google、Nvidia等公司合作測量其技術。
    • 講者提出「智慧前沿(intelligence frontier)」概念:目前最聰明的模型能做到的事,相對於人類想讓AI做的所有事情而言仍是極小一部分,因此大家才會持續追逐最新的frontier模型;同時「前沿內任務集合」每月都在擴大,對這些任務做智慧與成本的權衡變得非常重要,因為選擇不用最聰明的模型可能可用少10倍、100倍、1000倍的成本完成同樣工作。
    • 「Artificial Analysis Intelligence Index」是綜合9個評測（含大量agentic任務與高難度推理問答）的單一指標,目前為4.1版,Claude Fable 5排名第一。
    • 觀察intelligence index隨時間變化的走勢圖:OpenAI與Anthropic長期互相拉鋸領先,但過去一年發布節奏明顯加快(圖上時間點越來越密集),且緊追frontier的公司會在數月後就推出達到同等智慧水準的模型。
    • 開源權重模型與整體frontier之間的差距,過去三年間穩定維持在3到9個月,並未如坊間說法般「越差越遠」或「已經追上」;講者預測Mythos發布後9個月內會有人釋出同等聰明的開源模型。
    • 在固定智慧水準（以10分為一個區間分組）下,token價格逐年下降5到10倍,frontier的token成本其實維持相對穩定，這是log軸圖表呈現的長期趨勢；講者強調如果要在兩個相差10分的模型之間選,幾乎找不到任何任務是較笨模型能贏過較聰明模型的。
    • 但若看「每個任務的平均成本」（涵蓋agentic與非agentic任務）,數字是持續上升的——因為這個平均值掩蓋了在部分高難度情境下成本已變得非常極端的事實。
    • 用GPQA Diamond（知名開源推理評測,不允許模型以agent方式運作,已算被「解決」）來看,每題成本從不到一美分到約50美分不等；但在coding agent index與全新的AA Briefcase（agentic知識工作評測）中,單一任務成本可超過20美元，AA Briefcase中最貴的單一任務甚至是這個數字的好幾倍。Claude Fable 5成本最高,但Claude Sonnet 5其實用了極大量token,成本也逼近前者。
    • AA Briefcase是Artificial Analysis新推出的agentic知識工作基準,包含4個私有情境,每個代表數週份量的人類工作量,並依「rubric正確性、分析品質、簡報呈現」三個維度評分,類似評估人類產出的方式。
    • AA Briefcase刻意設計得貼近真實職場情境:不會把完成任務所需的精確資訊直接餵給模型,而是要模型自己在數千個檔案中翻找,包括雜亂的Excel檔、非結構化文件、上百頁的結構化報告、email、Slack訊息，模擬人類實際工作時需要自己去挖資訊的狀況。
    • 以一個商業盡職調查(commercial due diligence)任務為例展示模型輸出品質的演進:GPT-4.0只能做出很基本的投影片;去年初發布、被視為突破性模型的O3只能產出幾個條列重點,雖有幫助但遠不及人類水準;而Opus 4.8與Fable 5的輸出則在分析深度與簡報品質上大幅提升,顯示這一年多以來的巨大進步。
    • 拆解agentic任務成本的四大驅動因素:①token價格、②agent軌跡中的對話輪數(turns)、③模型的token使用效率、④prompt caching的影響(被認為可能是最重要的一項)。
    • Token價格方面:frontier模型（如Claude Fable 5）與仍然好用的平價模型（如DeepSeek V4 Flash、GPT OSS 120B）之間,價格可以相差兩個數量級；同時同一模型內部cache命中價、非cache命中的輸入token價、輸出token價三者之間差異也很大。
    • 這些是長時間運行的agentic任務,模型需要在真實環境（類似人類搜尋Slack等行為）中進行探索,調用工具次數可達數百次,包括看圖片、讀檔案、寫檔案做臨時分析,每一輪(turn)都會產生output token,而這些output token接著又會變成下一輪的input token,層層堆疊都要付費。
    • 以output token總量來看模型間差異可達數量級：昨天剛發布的Claude Sonnet 5單一任務就用超過20萬個output token,相較幾年前一次ChatGPT查詢可能只有幾百到幾千個token；差異來自①輪數多寡、②模型「話癆」程度（推理token與最終答案token的產出量）。
    • 若看任務的「總token」構成（答案token+推理token+輸入token）,圖上幾乎看不到output token的存在——絕大多數token其實都是輸入token（input token）,因此完成長時間agentic任務時真正該關注的是「無cache命中的輸入token價」與「有cache命中的輸入token價」這兩者。
    • Cache命中帶來的折扣通常約90%左右,但依模型/供應商不同差異頗大,有些模型可達99%折扣,有些只有約80%；由於絕大多數token是輸入token,cache折扣率或命中率的差異足以讓整個agentic任務的總成本相差數倍之多。因此思考agentic任務成本時,應該先從「cache命中價」而非output token去思考。
    • 講者提出理解2026年AI成本地景最重要的一張圖：「智慧 vs 每任務成本」,並將任務分成兩種原型（archetype）來決定該用最聰明還是最便宜的模型：
    • ①「無上限型任務」——智慧越高、產出越好,沒有天花板,例如策略分析、成本節省分析,甚至寫職位描述,人類永遠可以做得更好,模型也是；這類任務要看Pareto前緣曲線,決策點在於「願意為額外的智慧多付多少錢」。
    • ②「有上限型任務」——例如「我上個月Stripe手續費花了多少」,更聰明的模型不會給出更好或不同的答案；這類任務要找出能完成任務的「最低所需智慧水準」,然後選擇該智慧水準下最便宜（圖上最左側）的模型。
    • 講者最後提到Artificial Analysis正在招募人才（We're hiring）。

    “「在固定的智慧水準下,token價格每年持續下降5到10倍。」”

    “「絕大多數的token都是輸入token(input token)——你幾乎看不到任何輸出token。」”

    “「應該先從cache命中價開始思考agentic任務的token成本,而不是先想輸出token。」”

30. 30

    在真實世界衡量智慧:Arena 打造代理式評測與 Agent Arena

    Weilin Chiang · Arena (LMArena)

    ▶ 8:26:09

    這場 talk 由 Arena（LMArena）共同創辦人暨 CTO Weilin Chiang 分享團隊在打造「代理式評測」（agentic evals）與 Agent Arena 過程中的第一手經驗。核心主張是：隨著 AI 從聊天機器人快速轉向具高度自主性的 agent，傳統靜態 benchmark 已不足以衡量其真實價值，唯有透過真實世界的大量使用者互動軌跡（traces）才能準確評測 agent 的實際表現。

    • Arena 的使命是「在真實世界衡量智慧」，而非僅依賴靜態 benchmark，目標是評估 AI 是否真正為使用者、客戶創造價值。
    • Weilin 在 UC Berkeley 攻讀 AI 研究博士期間專注於建構穩健、可擴展的 AI 系統評測方法，該研究成果成為今日 Arena 的基礎；團隊早期作品包括 2023 年的 LLM-as-judge 研究與 Chatbot Arena。
    • Arena 見證了近年主要 AI 突破的軌跡：2022 ChatGPT 時刻 → GPT-4o 的多模態能力 → OpenAI o1 開啟推理/思考模型時代 → 2025 NanoBanana（原本以代號在 Arena 內測試後才公開發布）帶動影像生成突破，接著 Grok、GPT Images 2 跟進，影片生成則有 Veo 與 ByteDance 的 Seedance。
    • 2025 年底 Claude Opus 4.5/4.6 從「優秀的 coding model」進化為「真正具代理性、能執行長時程任務的 coding model」，這在 Arena 的 Code Arena 評測中也顯示出顯著進步；最新的 Claude Fable 5 在 Agent Arena 表現突出，GLM 5.2 的發布則被視為開源模型社群的重要里程碑。
    • Arena 平台規模：每月 1000 萬訪客、累積 7 億筆跨模態（文字、視覺、圖片、影片、程式碼、agent）對話紀錄；產品發布僅 8 個月就達到 1 億美元營收，並依 Similarweb（原文誤植為「ACC&Z」）等分析被列為全球訪客數前段班的 Gen AI 產品之一。
    • Live Leaderboard（arena.ai/leaderboard）以真實世界評測為基礎，涵蓋文字、圖像、影片、程式碼、agent 等類別，免費開放使用，並提供成本、效能、使用情境的 Pareto frontier 分析，協助使用者找到最適合自身情境的模型。
    • 趨勢面：OpenAI Codex 的輸出 token 幾乎 100% 來自 agent，其他組織平均也已超過 60%，個人使用者的 agent 使用比例也快速攀升——顯示 token 流量已由 agent 主導。
    • Agent 應用不再侷限於工程領域：OpenAI 內部 Codex 在工程部門採用率 99%，但財務、招募、法務等部門的採用率也接近 90%；Goldman Sachs 預估未來幾年月度 token 使用量將攀升至約 600 萬億（60 quadrillion）規模。
    • 經濟面數據：支出前 1% 的公司每位員工每月 AI 花費已達約 7,400 美元，約為一名軟體工程師薪資的一半，顯示選對模型、優化 agentic workflow 的重要性空前提高。
    • 評測 agent 的困難點有三：(1) agent 是多元件系統（模型、agentic loop、工具、harness 任一環節都可能出錯）；(2) agent 在真實環境中執行複雜工作流程（寫程式、除錯、研究、產出文件/簡報等）；(3) 訊號稀疏且分散在長任務歷程中，一項任務可能要跑 100 次工具呼叫才能判斷成敗或給予引導。
    • 為深入研究，Arena 一個月前推出 Agent Mode，讓任何人到 arena.ai 實際體驗並評測不同模型的代理能力，藉此蒐集真實使用者的軌跡與回饋。
    • Demo 展示：使用者輸入「下載 Google 的 Q1 財報並製作 PowerPoint 摘要簡報」，agent 會自主搜尋網路、抓取正確網站、規劃簡報架構，並用工具（含撰寫 Python 程式碼）產出可下載的 PowerPoint 檔案；每輪任務結束後系統會詢問使用者任務是否成功，作為評測訊號之一。
    • Agent Arena 底層架構：提供模型檔案系統工具（讀寫編輯）、網路搜尋/抓取、圖片生成、語音等工具，並具備終端機存取執行程式碼的能力（類似 Claude Code 的 harness），未來將加入 GitHub 等連接器以支援更嚴肅的軟體工程任務。
    • 一週使用數據：570 萬次工具呼叫，其中 Bash 是使用率最高的工具，約佔 46%；使用者的真實任務包含開發電影/觀影應用、自駕車除錯與控制系統、架設 RAG pipeline、在微服務中實作功能等，部分工作階段長達數百輪對話與數百次工具呼叫。
    • 上線第一個月，Agent Arena 蒐集超過 100 萬筆代理軌跡，涵蓋寫程式、研究、文件產出、腦力激盪、規劃等任務，其中超過一半屬於工作相關（偏向專業、複雜任務）的類別；agent 在 Arena 上累計閱讀超過 5000 萬行程式碼（Python、Markdown、HTML、JavaScript 等）。
    • 評測方法論：從三類訊號中挖掘資料——(1) 顯性訊號：使用者直接標註任務成功或失敗；(2) 隱性訊號：使用者是否下載檔案、抱怨或稱讚輸出等行為線索；(3) 環境回饋：程式碼實際執行結果（測試通過/失敗等）。這些訊號會匯總成 success rate、praise、overcompliance（過度順從）、steerability（可操控性）、bash 使用、error recovery、tool hallucination 等多項指標，各自可產生獨立排名，再綜合成最終 leaderboard。
    • 目前 leaderboard 上，Claude Fable 5 是排名第一的模型，相較所有模型平均表現淨提升 14%，其後依序是 Opus、GPT 系列、Gemini 高階版本；不同模型在不同訊號（如任務成功率 vs. 可操控性）上表現不一，有助使用者精準了解模型的強弱項。
    • 方法論核心是「隨機對照試驗」（RCT）思路：對 agent 的各個元件（如協調模型 orchestrator）做介入，量測其對任務結果（所關心的訊號）的因果效應；此框架具通用性，未來也能延伸評測工具、harness、system prompt 等元件間的交互效應。技術細節已發布於 Arena 官方部落格。
    • 因為資料來自真實流量，leaderboard 可依任意任務分佈切分：例如切分「GDP 相關」（更具經濟價值的專業工作）vs. 消費端使用情境，發現 GPT-5.5 在 GDP 類任務表現較佳，而 Gemini 在消費端使用情境表現較好——顯示「最佳模型」取決於具體使用情境。
    • 成本與效率分析：把淨效能提升對比平均成本繪成 Pareto frontier，Claude Fable 5 表現最佳但每次 session 成本約 10 美元；Gemini（原文「Fifi」，疑為口誤，應指 Gemini）性價比也強且較便宜；GLM 5.2 是最具成本效率的選項。
    • Token 使用觀察：效能較高的模型有時會產生更多輸出 token（例如思考型模型），但並非絕對——GPT-5.5 在效率上明顯優於其他模型；即使不同模型的「牌價」相近，實際任務中某些模型（如 GPT-5.5 相對 Opus）用更少 token 就能完成同樣任務，代表更高的實際效率。
    • 給開發者的建議總結：打造 agentic 應用時務必記錄完整的 agent 軌跡（agent 與使用者/客戶間的所有互動），並深入分析資料，將結果對應到自身關心的業務指標，用真實資料選出最適合的模型。
    • 未來規劃：加入更多連接器以帶入更多使用者情境，支援針對真實程式碼庫的輕量化評測（如 coding agent）；納入更複雜、專業使用者向的任務，並依類別細分呈現模型表現；持續豐富訊號種類，並加入 rubric 評分機制，甚至與使用者協作定義「好結果」的標準。