以下整理重點，並補充幾篇相關研究。

同一個模型，換個 x 軸就是另一個故事

GPT-5.5 剛發布時，第一波反應是質疑: benchmark 數字有進步，但不多。幾小時後大家實際上手，才發現它比 GPT-5.4 強了一個檔次。經典的「benchmark 成績表格」顯然沒有反映出全貌。

原因是 GPT-5.5 並不是在跟 5.4 相同的 token 預算(或美元預算)下評估的。本文封面圖就是 Noam 給的對比: 左邊的長條圖上，兩個模型只差 2.8 個百分點，看起來進步不大。但右邊把 x 軸換成輸出 token 數之後，故事完全不同: 在相同的 token 預算下，5.5 明顯強一截，5.4 要花將近 3 倍的 token 才能追到接近的分數。把測試時算力這個變因控制住，兩個模型的真正差距才顯現出來。

為什麼不直接把算力開到飽和再評估?

最直覺的反問是: 那就讓模型一直算下去，算到分數不再進步為止，量到的不就是上限了? Noam 說問題在於: 實際經驗上，「分數不再進步」這個停滯點(plateau)非常遠，在合理的預算內甚至可能根本看不到。

他舉了兩個例子。一個是 Karpathy 的 autoresearch 實驗，跑了數百次實驗後，表現仍在繼續進步。另一個是英國 AI Security Institute 的資安攻防評測，跑到 1 億 tokens，Mythos 和 GPT-5.5 的表現還在快速上升:

而且注意看這張圖: 越強的模型，分數隨算力成長的幅度也越大。模型越強，就越能在長時間跨度(long horizon)的任務上持續有效運作，停滯點被推得更遠，甚至可能消失。

編按: 「量測上限太昂貴」不是修辭。X 上最近流傳一篇據稱是 Anthropic 未發布模型 Mythos 的企業試點測試心得(中文翻譯)，作者說光這一輪測試就花了超過 100 萬美元的推論費用，而他們公司全員上個月的推論算力總開銷也才 200 萬美元。內容真偽無法驗證，但這個量級跟上面那條「跑到 1 億 tokens 還在爬升」的曲線是一致的: 想知道前沿模型的上限在哪，先準備好足夠的預算。

該怎麼評估: 把曲線畫出來

Noam 認為正確的評估方式，是畫出「表現 vs 測試時算力」的曲線，x 軸可以用 token 數、成本或時間。已經有 benchmark 這樣做了，例如 ARC-AGI 的排行榜，直接畫出「分數 vs 每題成本」:

另一個合理的做法是設定明確的 token、時間或成本預算，並且事先告知模型，就像人類考 SAT 或數學奧林匹亞也是限時的。

三種 x 軸各有取捨:

• Token 數: 不同模型之間不能直接比較，因為每家的 tokenizer、生成速度、單價都不同
• 美元成本: 受 batching、硬體利用率等實作細節影響，而且成本和延遲之間會互相取捨
• 實際耗時: 像 best-of-N (平行跑 N 次取最好的結果)這類技巧，可以在幾乎不增加耗時的情況下用掉更多算力，所以時間軸會低估算力用量

但 Noam 的重點是: 不管選哪一個，任何一條曲線都比單一分數有資訊量。

對 AI 安全的影響: 安全評估該用多大的預算跑?

前沿模型發布前，實驗室通常會評估資安攻擊、生物武器等濫用風險，超過能力門檻就要先做好緩解措施才能發布。但如果模型能力取決於用了多少推論算力，那安全評估該用多大的預算來跑? 實務上，多數安全評估根本沒有考慮這件事。

Gemini 3 Deep Think 發布時，benchmark 分數比之前的模型高出一截，卻沒有附上說明風險評估的 model card，引發 AI 安全社群的不滿。但 Noam 認為這個批評沒打到點上: Deep Think 很可能是拿其他「有」做過安全評估的模型，外面再包一層鷹架(scaffold)搭出來的。任何人只要願意付出 Deep Think 等級的推論費用，自己把多次模型呼叫串起來，大概也能重現同樣的能力。Deep Think 只是讓一般使用者更方便取得而已。

真正該檢討的是: Gemini 3 和其他模型發布時，安全報告都沒有把能力表示成測試時算力的函數。一個有決心的國家級行為者，可以對單一任務投入超過 1000 萬美元的推論算力; 但評估模型通常要跑數千甚至數百萬次任務，每一次都用這麼高的預算並不切實際。好消息是，表現隨算力擴展的走勢還算可預測，所以可以在較低預算下實際量測，再(帶著不確定性)外推高預算下的能力。Noam 理想中的模型評估長這樣:

文章還點出一個之後會更麻煩的問題: 要確認一個 agent 連續運作一年都不會出現對齊問題(misalignment)，可能唯一的辦法就是真的讓它跑一年。當 agent 的運作時間超過新模型的開發週期，實驗室可能根本來不及在發布前完成完整評估。

Noam Brown 給 AI 社群的三點具體建議

1. 實驗室發布新模型時，應該公布以 token 數、成本或時間為 x 軸的 benchmark 表現。至少也要報告達成那個分數用掉了多少推論預算
2. Benchmark 排行榜應該一併追蹤推論用量，或是設定明確的 token、成本、時間預算
3. 各家實驗室的安全政策(如 OpenAI 的 Preparedness Framework、Anthropic 的 Responsible Scaling Policy)在判定模型是否跨過安全門檻時，應該把推論算力明確納入考量，並在多個預算下評估，包含從小預算外推的估計(附上不確定性)

不只 Noam 在講: 忽略成本的比較正在失效

小編順手查了一下這個主題的其他研究，發現同樣的觀點已經累積不少證據:

ARC Prize: 額外的準確率是可以用錢買的

ARC Prize 共同創辦人 Mike Knoop 在測評各家推理系統時講得更直接:「所有 benchmark 和 model card 的報告都必須沿著兩個軸來做，因為額外的準確率是可以用錢買的。光禿禿的準確率分數是行銷，不是科學。」(原文: Naked accuracy scores are marketing, not science.) 他們的測試結論也是沒有單一贏家: 要最高準確率和要性價比，最佳選擇完全不同。

Artificial Analysis 的 Claude Fable 5 評測

Artificial Analysis 這週發布的 Claude Fable 5 評測就是一個現成的例子。下圖上半部是 Humanity’s Last Exam 的分數排行，Claude Fable 5 以 53.3% 居首; 下半部則是跑完整輪評測的總成本，Fable 5 要 $2,174，而 GPT-5.5 (xhigh) 拿 44.3% 花 $820、GPT-5.5 (high) 拿 43.0% 只花 $489。上下兩半對照著看，結論就從「Claude 領先 9 個百分點」變成「Claude 多花 2.7 倍的成本，買到 9 個百分點」。哪個划算，取決於你的任務值多少錢。若你只看分數排行，不看總成本，那你就無法判斷是否划算:

順帶一提，Artificial Analysis 網站上也有「Intelligence Index vs 評測成本」的散點圖，x 軸是跑完整套評測的成本(對數刻度)，這是目前業界做模型選型時最常引用的圖表之一。下圖左上角的綠色區塊標示「最划算象限」，GPT-5.5 (xhigh) 和 Claude Opus 4.8 (max) 這些最強模型則都落在右側最貴的那一區:

為什麼散點圖上沒有 Claude Fable 5?

不知為何，上面這張圖還沒有標出剛拿下 Intelligence Index 第一名 (64.9 分) 的 Claude Fable 5。AA 的模型頁面上 Fable 5 跑評測的 token 用量標示為 Unknown，小編猜可能是因為它的成本特別難算。Fable 5 有好幾個會在執行時動態改變行為和計費的機制:

1. Fallback 機制: 約 9% 的任務會轉給 Opus 4.8 跑、並按 Opus 的單價計費，總成本取決於有多少任務被轉走
2. Adaptive thinking 預設全程開啟: 模型自行決定每一題要思考多深，token 用量無法事先固定
3. 靜默降級: 根據 system card 第 12-13 頁，偵測到「前沿 LLM 開發」用途時(例如 pretraining pipeline、分散式訓練基礎設施、ML 加速器設計，約佔 0.03% 流量)會靜默限制模型能力: 不換模型、照 Fable 5 原價計費，也不通知使用者，從 API response 完全看不出來。模型甚至不會拒絕，仍會照常配合回應，只是這類任務的輸出效果被刻意壓低。至於怎麼壓低，Anthropic 沒有明講細節，只舉例說作法有: prompt 修改(在使用者看不到的地方改寫或附加指令)、steering vectors(推論時在模型內部的激活值上加一個方向向量，把行為往特定方向推)、參數高效微調(PEFT，掛上讓特定能力變弱的少量微調參數)。Lucas Beyer 等研究員這幾天在 X 上嘲諷的就是這個機制

前兩個機制影響的是成本，第三個影響的是同一筆錢買到的能力是否一致。這些機制從外部都看不到也控制不了，同一套評測跑出來的 token 數、計費單價、甚至模型行為都可能不同，要報告一個可重現的成本數字就難了。

小編用已公布的數據回推: HLE 單項 Fable 5 花了 $2,174，是 Opus 4.8 的 1.24 倍，但這是它最省的場景; 第三方在文字生成和 agentic 評測上實測的成本是 Opus 4.8 的 2~3 倍。合起來粗估，Fable 5 跑完整套評測約要 $9,000~$11,000，約是 Opus 4.8 (max) 的 2 倍以上，已經靠近圖上 x 軸 $10k 的最右邊了。

帕雷托前緣 (Pareto frontier)

這類「智慧 vs 成本」的散點圖通稱帕雷托前緣(Pareto frontier): 把「沒有其他模型同時比它更便宜又更聰明」的模型連成一條外緣線，選模型就沿著這條線挑，線內側的模型都存在又便宜又強的替代品。下圖是 Aaron Bergman 上個月用 Artificial Analysis 數據畫的版本，虛線就是前緣。可以注意到前緣的中低價位段幾乎全是開放權重模型(藍點: Qwen、DeepSeek、MiMo)，閉源模型(紅點)只守住右上角的高智慧高價端:

swyx 的 Latent Space 從 2024 年就開始追蹤這條前緣隨時間推移的速度，而且它移動得非常快: 根據 Epoch AI 的統計，達到固定表現水準的推論成本大約每兩個月就砍半。也就是說，今天落在前緣上的模型，幾個月後就可能被更便宜的新模型蓋過，「哪個模型最划算」的結論有效期很短，需要定期重新檢視。

拉齊預算後，推理技巧的優勢會縮水

EMNLP 2024 的 Reasoning in Token Economies 把各種推理策略放在相同的推論預算下重新評估，發現 Multi-Agent Debate、Reflexion 這些方法的優勢大幅縮水，多數情況下反而輸給簡單的基準做法 self-consistency (對同一題多次取樣再投票)。很多「新方法帶來的進步」，其實只是用了更多預算。這對評估 prompt 技巧和 agent 架構是同樣的提醒: 沒有控制預算的 A/B 比較，結論可能是錯的。

看牌價選模型也會被誤導

OckBench 發現每 token 單價只有一半的 7B 模型，因為產出 3 倍的 token 數量，實際每次查詢的成本反而貴 57%，他們稱之為「過度思考稅」(overthinking tax)。另一篇研究系統性測了 8 個推理模型在 12 種任務上的表現，發現模型兩兩比較時，有 32% 的組合牌價排序跟實際總成本排序是相反的。

小結

Noam 自己也說，這篇文章對長期追蹤的人來說沒什麼新東西: 從 2024 年 9 月 o1 發布那天起，大家就知道推理模型的表現會隨推論算力擴展。但快兩年過去，前沿實驗室發布新模型還是只報告單一數字，安全機構還是會對「鷹架架構(scaffold)用 100 倍預算打出更高分」感到意外。

對做模型選型的工程師來說，這篇的實際意義很具體: 下次比較模型時，需要考慮「在我的預算下哪一個模型最強」，而不是「誰的分數最高」。同一條曲線上的不同點，其實是不同的產品。

MAI (Microsoft AI) 是 2024 年 Microsoft 收購 DeepMind 共同創辦人 Mustafa Suleyman 的 Inflection AI 後成立的內部前沿模型實驗室。定位上跟 OpenAI 的合作是並行的: OpenAI 繼續提供 GPT 系列，MAI 則讓 Microsoft 擁有完全自主掌控的模型線。

你可能會問: Microsoft 不是已經有 Phi 系列了嗎? Phi 是 Microsoft Research 做的開源小模型(最新的 Phi-4-reasoning 是 15B 參數)，定位在研究貢獻和邊緣裝置部署。MAI 則完全不同: 閉源、前沿規模(1T 參數)、目標是跟 OpenAI、Anthropic、Google DeepMind 同級。兩個是不同團隊、不同目標的產品線。小編之前也沒特別關注這個團隊，直到六月初的 Build 2026 上他們一口氣端出七個模型，才發現值得關注一下。

這七個模型涵蓋推理、程式碼、圖片生成、語音合成和語音辨識，從組建團隊算起只花了約兩年。對做 LLM 應用的開發者來說，多了一個選擇，但更值得關注的是背後的平台策略和技術決策思路。

七個模型，哪些跟你有關

部分模型也上了 OpenRouter、Fireworks、Baseten 等第三方推理平台。目前沒有開源權重的計畫，走的是 API 和平台模式。

Image 2.5 定價參考(每百萬 token): 文字輸入 $5 / 圖片輸入 $8 / 圖片輸出 $47。Flash 版約便宜 3-4 倍。

跟現有選擇比如何

先看 MAI-Thinking-1 的 benchmark 數字:

人類盲測對比 Sonnet 4.6: 49% 贏、45% 輸、6% 平手。對比 Opus 4.6: 43% 贏、52% 輸。

論文自己的定位很克制: 「不是領域最強，但在廣泛任務上表現穩定一致。」

社群也注意到幾點:

1. 比較對象的選擇: Anthropic 在 Build 2026 前幾天才發布了 Opus 4.8，但 MAI 選擇跟較早的 Sonnet 4.6 做比較。
2. 數字尚未獨立驗證: 截至目前，第三方評測聚合器上還沒有 MAI-Thinking-1 的獨立測試結果。
3. 明顯弱項: 指令遵循能力和終端操作(Terminal-Bench)跟競品差距不小，如果你的應用重度依賴複雜指令，這點要留意。

小編的判斷: 作為第一個版本，MAI-Thinking-1 大致在 Sonnet 4.6 同級。如果你已經在用 Claude 或 GPT，目前沒有強烈理由切換。但如果你本來就深度使用 Microsoft 生態系(Azure、GitHub、M365)，整合度是加分項。

MAI-Code-1-Flash: Copilot 裡的新選項

對每天在寫程式的人來說，MAI-Code-1-Flash 可能是最直接相關的:

• 只有 5B 參數，但 SWE-Bench Pro 拿到 51.2% (Claude Haiku 4.5 是 35.2%)
• 解決困難問題時，token 用量比同級模型少 60%
• 有「自適應回應長度」機制: 簡單問題快速回答，複雜問題才展開長思考
• 直接在 VS Code 的 Copilot 模型選擇器裡選用，不需額外設定

這個模型是直接用 GitHub Copilot 的正式環境訓練的，不是單純對 benchmark 最佳化。對日常寫程式來說，回應速度和 token 效率可能比 benchmark 分數更重要。

零蒸餾: 對開發者意味著什麼

MAI-Thinking-1 有一個特別的設計選擇: 完全不使用其他模型的蒸餾(也就是不拿 GPT、Claude 等模型的輸出當訓練資料)，推理能力純粹靠自己的強化學習訓練學出來。也不使用合成資料，30T tokens 預訓練資料全部來自人類產出的內容。

這對下游開發者有什麼意義?

🔹 企業法務面: 如同 @eliebakouch 的分析，乾淨的資料來源讓企業法務更容易簽字放行。如果你的客戶是大企業或受監管產業，「這個模型沒有用到競爭對手的輸出當訓練資料」是一個可以寫進合約裡的保證。

🔹 供應鏈獨立性: 不依賴其他實驗室的模型輸出，意味著 Microsoft 的模型改進不會被上游的 API 政策變動影響。對長期使用 Microsoft 生態系的開發者來說，這是穩定性的保證。

不過社群對「乾淨資料」的說法也有質疑。Simon Willison 指出訓練資料包含 1.2 兆頁公開網頁爬蟲和 GitHub 程式碼。Hacker News 上的討論認為，GitHub 改了使用條款允許用使用者資料訓練 AI，這大概就是所謂「合規授權資料」的意思，跟其他實驗室的做法沒有本質差異。所以「乾淨」更多是指「沒用別家模型的輸出」，不是「完全沒有版權爭議」。

Frontier Tuning: 讓模型變成你的

這次發布中對開發者最有戰略意義的可能是 Frontier Tuning。核心概念:

🔹 強化學習環境(RLE): 你建立自己的訓練環境，讓 MAI 模型在你的工作流程中持續學習。不只是 prompt 調整或 LoRA 微調，是真的在你的場景裡做強化學習。

🔹 實際效果: Microsoft 內部用 RLE 針對 Excel 的 agent 功能調校，結果跟 GPT-5.4 同等水準但效率高 10 倍。幫 McKinsey 調校後，品質勝過 GPT-5.5，成本低 10 倍。

🔹 商業定位: Mustafa 描述為「從租用 AI 到掌控 AI」。調校後的模型權重是你的，別人拿不到。

不過 Hacker News 上也有人吐槽: 實際體驗是一個資料標註介面，需要你提供指令和回饋，每步之間要等很久。離「模型自動觀察你的工作流然後學會」還有段距離。

Satya 的觀點: 對架構決策的啟發

Satya 在 Latent Space 訪談中分享的幾個觀點，對做 LLM 應用架構決策的人蠻有參考價值:

🔹 模型只是起點，harness 才是產品: 每個 Microsoft 產品(GitHub Copilot、Defender)現在都是 multi-model harness，定義了「模型 + 資料 + 工具」的迴圈。上下文層的準備工作是過去兩年最難學到的一課。

🔹 私有評估集是最大的護城河: 如果你有自己的 eval，能在不同模型間切換並持續進步，你就掌握主動權。如果你的系統綁死一個模型、沒辦法換，你就沒有議價能力。

🔹 Token 資產: 企業累積的執行軌跡(traces)、評估集、上下文是新型態的智慧財產。這個觀點對正在建 AI 產品的團隊很重要: 你的護城河不在於你用哪個模型，而在於你累積了什麼資料和評估能力。

🔹 小模型 + 好的 harness 一樣能有效爬坡: 不一定要用最大最貴的模型。5B 參數的 MAI-Code-1-Flash 在正確的 harness 下表現超越大很多的模型。這呼應了「用小模型 + 好的 harness」可能比「直接用最大模型」更划算的實務經驗。

技術報告: 有趣的訓練細節

這份 109 頁的技術報告是這次發布中讓社群最驚喜的部分。@nrehiew_ 稱它「幾乎可以當成今天 LLM 訓練的教科書」，Latent Space 則評價 MAI 目前是「不錯的第二梯隊新實驗室，在特定領域微調上有明確優勢」。以下挑幾個有意思的點:

架構: 大容量但省推理成本

MAI-Thinking-1 總參數量約 1T，但每次推理只啟動 35B(512 個專家模組裡挑 8 個)。好處是模型知識容量大但推理成本可控。另一個設計是注意力機制大部分層只看附近的文字(局部注意力)，每隔幾層才做一次全文注意力，讓 256K 的長上下文不會讓推理成本暴增。

推理能力是強化學習從零練出來的

跟很多模型先拿 GPT/Claude 的思考過程做蒸餾不同，MAI-Thinking-1 的強化學習起點是一個完全沒見過「思考過程」的基底模型。訓練分成三條路線同時進行: 數學/科學推理、程式碼/工具使用、對話品質與安全性，各自練完再合併成一個模型。

論文展示了數學能力(AIME 2025)從約 20% 爬到 97% 的完整過程，花了約 5000 步。中間有好幾次訓練崩潰，靠的是「自我蒸餾」恢復: 把模型之前產出的好答案收集起來，先微調回穩定狀態，然後繼續強化學習。這種「崩了就從自己的好輸出重來」的做法蠻實務的。

程式碼能力的訓練資料怎麼來的

他們從 GitHub 上 1.02 億個 PR 出發，自動篩選出 26.5 萬個「可以驗證對錯」的程式修改環境(覆蓋 9.4 萬個 repo)，拿來當強化學習的訓練場。模型要實際讀程式碼、改程式碼、跑測試，答對才有獎勵。這個規模和方法對做 coding agent 評估的團隊蠻有參考價值。

小規模實驗的結論不一定能放大

論文揭示了一個有趣的陷阱: 用小模型測試出「資料配比 A 比 B 好」，放大到完整規模後結論可能反轉。實際案例是程式碼比重高的配比在大模型上勝出，但在小模型上反而輸。這對所有在做規模擴展決策或評估設計的人都是個提醒: 小實驗的結論要謹慎外推。

訓練規模

預訓練用了 30T tokens、8,192 張 GB200 GPU。強化學習階段最大的一次訓練動用了 4,864 張 GB300 晶片。

平台佈局: 跟 OpenAI 的關係怎麼了

要理解 MAI 的戰略意義，得先知道背景: 2026 年 4 月，Microsoft 跟 OpenAI 重新談判了合約。OpenAI 解除了只能透過 Azure 發行的限制，可以到其他雲端上架；同時 Microsoft 也正式獲得自行訓練前沿模型的自由。Suleyman 在受訪時說: 「我們大約在六個月前才從 OpenAI 合約中解放出來，可以正式追求超智慧。所以這還是非常早期的階段。」

他也很坦白地定位 MAI 的現況: 「目標是證明我們能成為全球前四的實驗室。目前重要的三家是 Google DeepMind、OpenAI、Anthropic，我們還不算在其中。」

這讓 Azure 上的模型供給格局從「幾乎只有 OpenAI」變成三條路線並存:

Digital Applied 的分析認為，Azure 開發者現在應該根據任務需求在三條路線之間挑選，而不是像以前一樣預設什麼都用 OpenAI。

Microsoft Foundry: 開發者實際接觸的界面

對開發者來說，這些模型都是透過 Microsoft Foundry (原 Azure AI Foundry) 來使用的。幾個跟開發者直接相關的功能:

🔹 模型目錄: 超過 12,000 個模型，包含 MAI、OpenAI、Claude、Grok、Llama、Mistral、DeepSeek 等。80% 的 Fortune 500 企業在使用。

🔹 Model Router: 根據工作負載特性、成本目標、延遲要求，自動把每個請求路由到最合適的模型。不需要自己寫 routing 邏輯。

🔹 API 相容性: REST API 走 /openai/v1/ 路由(chat/completions, embeddings, fine-tuning 等)，SDK 支援 Python、.NET、JS/TS、Java。如果你已經在用 OpenAI 格式的 API，切換成本很低。

🔹 Agent Service: 託管式 agent 運行環境，有沙箱隔離、狀態管理、檔案系統存取。

MAIA 200 晶片對開發者的影響: 開發者不會直接碰到這顆晶片(目前沒有 Azure VM 實例可以租)。它是在 Foundry API 背後默默跑的，好處是 MAI 模型的 token 定價會比較低。Mustafa 表示在 MAIA 200 上跑 MAI 模型比 NVIDIA GB200 每美元效能高 30%、每瓦效能高 1.4 倍。

產品整合和垂直領域

🔹 跨產品整合: MAI 模型已經嵌入 GitHub Copilot (Code-1-Flash)、Microsoft Teams (Transcribe)、PowerPoint (Image 2.5)、Dynamics 365 (Voice 2)。這種深度整合是第三方模型做不到的。

🔹 Mayo Clinic 合作: Microsoft 宣布與 Mayo Clinic 合作，用去識別化的臨床資料共同訓練醫療領域的前沿模型。這是 Frontier Tuning 在垂直領域的第一個公開案例。

🔹 Satya 的第三幕定位: 在 Latent Space 訪談中，Satya 把 Microsoft 的演進描述為「作業系統公司 → 雲端公司 → 智慧平台公司」。MAI 模型是這個「第三幕」的基礎設施層。

WindowsForum 的評論則比較冷靜: 「MAI 讓 Microsoft 對自己的 AI 命運有更多掌控權，但不代表使用者會因此更信任 Windows、Office 或 GitHub 裡的 AI 功能。信任要一個功能一個功能地贏回來。」

結論: 多了一個選項，重點在生態系

對 LLM 應用開發者來說，MAI 這次發布的意義不在於「又多了一個跟 Sonnet 4.6 差不多的模型」，而在於:

1. Microsoft 生態系有了自己的模型: 如果你的產品建在 Azure / GitHub / M365 上，現在有原生整合度更高的選項。
2. Frontier Tuning 提供了深度客製化的新路線: 比一般的微調 API 更深入，但也更重(需要建立訓練環境、提供回饋)。適合有明確領域需求且願意投入的團隊。
3. 強化了「模型可替換、評估集是護城河」的觀點: 不管你用不用 MAI，Satya 講的「私有 eval + multi-model harness」是值得認真思考的架構方向。

最後想提一點: Microsoft MAI 和 Meta MSL 不約而同都選擇了「從頭練、不蒸餾」的路線。這條路更慢、更貴、更容易失敗，但兩家都認為只有這樣才能建立真正可持續往上爬的能力，而不是靠蒸餾別人的輸出拿到一個無法超越來源模型的天花板。在 AI 快速迭代的時代，願意花兩年從零開始是令人敬佩的。

對照之下，不是每家大公司都做同樣的選擇。回顧今年以來:Apple 今年一月宣布下一代基礎模型將改用 Google Gemini，等於放棄自己練前沿模型。Amazon 的 Nova 系列持續發展，但定位偏向性價比而非前沿智能(Neowin 評 Nova Premier 為「最先進但令人失望」，Nova 2 的評測對標是輕量級模型而非頂尖模型)，Amazon 真正的重心在自研晶片 Trainium 和 Bedrock 平台(模型 API 服務)，大手筆投資 Anthropic，也把 OpenAI 模型上架到 Bedrock。xAI 併入 SpaceX 後重心轉向基礎設施，把資料中心的算力分別租給 Anthropic 和 Google，光租算力就穩賺，不用自己承擔模型研發的風險。

小編整理了三大雲平台目前的前沿模型支援現況:

📎 資料來源:

• Building a Hill-Climbing Machine (Microsoft AI Blog)
• MAI-Thinking-1 Technical Report (109 頁完整論文)
• Satya Nadella on Latent Space (Build 2026 訪談)
• Mustafa Suleyman 公告推文

把這條線拉開來看，dynamic workflows 不是憑空冒出來的新玩意，而是「用程式碼當 agent 的行動」這個老想法，走到成熟、產品化的一步。技術上小編覺得設計得非常漂亮，這篇就來把這條路從頭走一遍。

1. Code Act 的核心洞見: 用程式碼當行動空間

故事從 “Executable Code Actions Elicit Better LLM Agents” (2024/2) 這篇講起。傳統 agent 的做法是 JSON function calling: 模型吐一個 JSON 物件，描述要呼叫哪個工具、帶哪些參數，再交給後端的處理常式執行，把結果塞回去。

CodeAct 提出的轉向是: 不要用預先定義好的 JSON 格式當行動空間，而是直接讓 LLM 寫一段「可執行的 Python」當作它的行動，把規劃跟工具呼叫合併進同一份程式碼裡一起跑。

為什麼程式碼會比 JSON 好? 兩個關鍵理由:

🔹 模型本來就很會寫程式碼。 LLM 在訓練時看過幾百萬個開源專案的真實程式碼，但工具呼叫用的那些特殊 token，是靠合成資料硬訓出來的，模型在真實世界裡根本沒見過。

🔹 程式碼天生支援組合。 迴圈、條件判斷、變數傳遞、把好幾個工具的輸出串起來，這些在 JSON schema 裡很難表達，在 Python 裡卻幾乎不費力。

論文 Figure 1 那個例子舉得很漂亮。任務是在美國、日本、德國、印度裡，找出買「CodeAct」這支手機最划算的國家。每個國家都得查匯率、稅率、當地售價、運費，再算出最終美元價格。用到的工具有 lookup_rate、lookup_phone_price、convert_and_tax、lookup_shipping_cost、estimate_final_price。

兩種做法的差異:

→ {"tool":"lookup_rate","country":"Germany"}
← exchange_rate=1.1, tax_rate=0.19
→ {"tool":"lookup_phone_price","country":"Germany"}
← 700
→ {"tool":"convert_and_tax","price":700,...}
← 833
→ {"tool":"lookup_shipping_cost","country":"Germany"}
← ...
→ {"tool":"estimate_final_price",...}
← ...

countries = ["USA","Japan","Germany","India"]
final_prices = {}
for country in countries:
    rate, tax = lookup_rate(country)
    price = lookup_phone_price("CodeAct", country)
    converted = convert_and_tax(price, rate, tax)
    shipping = lookup_shipping_cost(country)
    final_prices[country] = estimate_final_price(
        converted, shipping)
cheapest = min(final_prices, key=final_prices.get)

左邊每呼叫一個工具，結果都得塞回模型，模型再決定下一步，一路來回。右邊一個 for 迴圈跑完四國，lookup_rate 的輸出直接傳給 convert_and_tax (資料流)，最後用 Python 內建的 min() 挑出最便宜的。模型只需要產生這一段程式碼、看一次最終答案。

CodeAct 的一個具體實作是 Hugging Face 的 smolagents，裡面的 CodeAgent 就是讓模型寫 Python 來呼叫工具，而不是走 JSON function calling。

這裡有個容易混淆的點: CodeAct 跟 Code Interpreter 不一樣。Code Interpreter 只是把「跑程式碼」當成眾多工具裡的「一個工具」來用，程式碼本身碰不到 agent 的其他工具。

CodeAct 則是把整個決策過程，連同函式呼叫，都寫進同一份程式碼裡一起執行。少了中間來回，效率自然好。

2. 同一招用到 MCP 上: Cloudflare 自家的 Code Mode

時間快轉到 MCP 生態爆炸之後，出現一個很現實的問題: 工具太多了。每個操作都註冊成一個工具，幾千個工具定義直接塞爆上下文。

Cloudflare 的 Code Mode 參考了 CodeAct 的思路: 與其把每個操作描述成獨立的工具，不如把 MCP 工具轉成一份有型別的 TypeScript SDK，叫模型寫程式碼去呼叫。他們新的 Cloudflare MCP server 涵蓋整個 Cloudflare API (數千個端點)，只定義兩個 agent 工具: search() 跟 execute()。

這樣大約只吃 1000 個 token，同樣的東西若用傳統「每個端點一個工具」的做法，要 117 萬 token，直接超過大多數模型的 context window。search() 讓模型去查 OpenAPI 規格、把幾千個端點收斂到需要的那幾個，execute() 在沙箱裡跑實際呼叫。

這裡有個概念叫「composition tax」(組合稅): 每一次工具呼叫的結果，都得先塞回模型的神經網路，再被原封不動抄到下一個呼叫的輸入，白白浪費 token 跟延遲，還多出一次推理。動作越多，這個稅越重。寫成程式碼就能在執行環境裡直接串接，跳過這道稅。

3. 程式碼可呼叫 agent tools: PTC

接著是 Claude API 這邊的 Programmatic Tool Calling (PTC)，它建在 code_execution 工具之上 (這就是 Claude 的 Code Interpreter)。作法很單純: 你照常定義自訂工具，只要在工具定義裡加一個 allowed_callers: ["code_execution_20260120"]，Claude 就不會一個一個直接呼叫它們，而是寫一段 Python，把這些工具當成函式，在程式碼執行容器裡組合、執行。

一句話抓住定位: PTC 就是「一段在容器裡執行的程式碼，而且這段程式碼能呼叫你原本要給 agent 的那些工具」。對照前面: Code Interpreter 的程式碼只能在沙箱裡自己算，碰不到 agent 的工具; CodeAct 在研究層面做到了讓程式碼呼叫 agent 工具。PTC 的升級是把這件事變成正式上線的 API，附帶的好處是: 工具的執行留在你那邊，工具結果不進 Claude 的上下文。

機制拆開來看是這樣:

1. Claude 在 Anthropic 的容器裡寫一段程式碼，裡面可能有迴圈、條件判斷、好幾個工具呼叫。
2. 程式碼跑到 result = await query_db(sql) 時，容器暫停，API 把這個呼叫當成一個 tool_use 事件回傳給「你」。
3. 工具還是跑在你那邊: 你的伺服器執行它、把結果回傳，Anthropic 的容器只負責跑那段編排程式碼。
4. 結果回到「正在執行的那段程式碼」繼續往下，這些中間結果完全不進 Claude 的 context window (也不計入 token)。
5. 整段程式碼跑完，Claude 只收到最後印出來的 stdout。

編按: 這正好補上 composition tax 的另一半。Code Mode 解決了「工具定義」塞爆上下文，PTC 解決的是「工具結果」塞爆上下文。例如一次搜尋回傳 50 筆原始結果，程式碼可以在容器裡直接解析、過濾、交叉比對，只留下相關的幾筆，而不是把 50 筆全倒進 Claude 腦袋裡讓它自己讀。

所以 PTC 做到的是: Claude 用程式碼組合多個工具呼叫 (迴圈、條件、串接輸出)，但工具還是跑在你那邊，你可以檢查、拒絕、記 log、排進人工審核佇列。

但官方也講得很白，PTC 不是萬靈丹。嚴格循序、每一步都要 Claude 看完上一步才能決定下一步的工作，PTC 幫不上忙 (那種情況本來就省不掉來回)，一次只呼叫一兩個工具的場景甚至會小貴一點。它真正發威的是「大量平行分流」或「結果很大、可以先在程式碼裡過濾」的任務。

(另外有個常見誤會: MCP connector 提供的工具，目前不能被 PTC 程式化呼叫。)

4. 開源實作: LangChain Deep Agents 的 Interpreter 與 Interpreter Skills

LangChain 的 Deep Agents 做的 interpreter，跟剛剛的 PTC 骨子裡是同一套做法，只是搬到了不同的層。PTC 是 Anthropic 在 API 供應商這一層做的 (Anthropic 管容器，工具在你那邊執行); Deep Agents Interpreter 則是 LangChain 在 harness 層做的中介層 (middleware)，跟模型無關，連開源模型都能用。LangChain 自己也說 PTC、Code Mode、interpreter、RLM 殊途同歸。

具體來說，它給 agent 一個內嵌的小型執行環境，agent 可以在裡面寫程式碼、存變數、定義輔助函式、跨呼叫保留狀態，像有了一個 Python 或 Node REPL。實作上它是掛一個 eval 工具，但別被「工具」兩個字誤導: 它背後是一個有狀態、會跨呼叫存活的執行環境，不是那種呼叫一次就結束的普通工具。

小編初看時覺得這跟 sandbox 功能有什麼差別? 其實差在兩個地方:

🔸 預設能力的方向相反。 沙箱是「先給一台電腦，再往下收」: agent 一開始就拿到完整的作業系統、檔案系統、網路、shell，你再去限制。interpreter 剛好倒過來，「先什麼都沒有，要什麼再明確給」: 預設只有一個語言執行環境，沒有檔案系統、沒有網路、沒有 shell，連讀檔、抓網頁、開子代理人(spawn sub-agent) 都得一個一個透過 allowlist 橋接進來。

🔸 隔離在不同的層。 這也回答一個常見疑問: 「interpreter 不也是在沙箱裡跑程式碼嗎?」其實不一定。interpreter 底層是像 QuickJS 這種內嵌的小引擎，跟 harness 跑在同一個行程裡，它的「隔離」是語言層的: 執行環境預設沒綁任何主機 API，所以裡面的程式碼根本沒有東西可以濫用。真正的沙箱 (gVisor、microVM 那種) 則是作業系統或硬體層的隔離，目的是擋住 agent 自己生成、可能亂來的程式碼「逃逸」。一句話: 能力控管 (capability scoping) 防的是「能碰到什麼」，VM 隔離防的是「會不會逃出去」，是兩回事。跑不可信的程式碼時，你還是可以把整個 interpreter 再包進一個沙箱，那是多加的一層防禦，不是 interpreter 自帶的機制。

PTC 跟 Deep Agents Interpreter 共同做到的關鍵動作是: 一旦把 Task 或 agent 工具也橋接進來，程式碼就能開子代理人。程式碼從「呼叫工具」升級成「呼叫 agent」，正式參與了 agent loop。

LangChain 後來進一步做了 interpreter skills: 開發者事先把一段「已知有效的固定流程」寫成 TypeScript 模組，註冊成一個 skill。模型在對話中判斷「現在該用哪個 skill、傳什麼輸入」，但 skill 內部的步驟是寫死的程式碼，不是模型即時決定的。

拿他們的 GitHub repo triage 範例來看，一個 interpreter skill 由 SKILL.md (告訴模型什麼時候該用) 和 index.ts (實際的流程程式碼) 組成。當使用者說「幫我整理這個 repo 的 issue」，模型判斷該用這個 skill，在 interpreter 裡呼叫它:

// skills/github-triage/SKILL.md 告訴模型: "Use this skill when a user asks for repository triage."
// skills/github-triage/index.ts 匯出 triage() 函式，內部流程是寫死的:
//   抓所有 open items → 開子代理人做摘要 → 逐一分群歸類

const { triage } = await import("@/skills/github-triage");
const result = await triage("langchain-ai/deepagents", {
  issues: true, prs: true, discussions: true,
});
result.toMarkdown();

模型決定的是「要不要用、傳什麼參數、結果怎麼處理」; 但 triage() 內部怎麼抓資料、怎麼開子代理人、怎麼分群，全是寫死在 index.ts 裡的確定性程式碼。

這跟 Claude Code dynamic workflows 已經非常接近了，差別是 interpreter skills 由開發者事先寫好，而 dynamic workflows 是模型在接到任務時才即時生成那份編排腳本。

這套設計背後的理論支點: RLM

dynamic workflows 不只是工程上的巧思，它底下有一條清楚的研究脈絡撐著，叫 RLM (Recursive Language Models)。

這是 MIT 的 Alex Zhang、Tim Kraska、Omar Khattab 提出的框架 (2025 年 10 月先以部落格形式提出，年底發表論文)。核心想法是: 把整段 prompt 當成一個放在 REPL 裡的「外部物件」。主模型不把上下文一口氣吞進腦袋，而是寫程式碼去窺看它、拆解它，對其中的片段遞迴呼叫自己或子模型，中間結果留在 REPL 的變數裡，只有精簡過的結果才回到主模型。這樣就繞過了固定 context window 的天花板。

關鍵在於 RLM 長期主張、而 coding agent 一直缺的那個能力: 以程式化的方式呼叫 sub-agent，把它們的輸出在程式碼裡傳來傳去，而不經過主模型的上下文。 這正是 dynamic workflows 在做的事。

也因此，RLM 作者群直接認領了這個發表: Omar Khattab 說「Claude Code 終於是一個 RLM 了」; Alex Zhang 則認為 Opus 4.8 加上 dynamic workflows，大概是第一個被認真訓練成 RLM 的前沿模型實例。

Dynamic workflows 的設計跟 RLM 的主張高度吻合: 模型寫的那段 JS 裡，agent() 就是在遞迴開子代理人，而編排這層是決定性的。

5. Claude Code Dynamic Workflows

終於來講到本篇的主角 Claude Code dynamic workflows 了，一樣是讓模型寫程式碼去編排 sub-agent。模型即時寫出程式碼這件事，跟 PTC、Deep Agents Interpreter 並沒有不同。真正不一樣的，是把這套編排磨硬、做成產品: 編排腳本可以中斷後原地 resume，而且是決定性的 (第 8 節會講); 規模一次拉到上千個 sub-agent; 在背景獨立跑完才把結果交回對話; 還收斂成六種可互相組合的模式、能存檔重用。前面那幾種都沒有這層「可重播、可規模化」的保證。

實際操作時，你在 prompt 裡帶一個 workflow (或 ultracode)，Claude 就會即時寫出一份 JavaScript 編排腳本，用 agent()、parallel()、pipeline()、phase() 這些函式 (官方文件)，平行啟動一大批 sub-agent (同時最多 16 個，單次最多 1000 個)，跑完再把結果交回來。

借用 Voxyz 那篇文章的講法: 計畫從對話的上下文搬進了可執行腳本。 以前用 Claude Code 跑大任務，所有步驟都擠在同一個對話上下文裡: 做完一步、等結果、決定下一步、再等結果。任務越複雜，上下文本身反而變成瓶頸，卡住的從來不是「誰來做」，而是「誰記得整個計畫」。dynamic workflows 把計畫從對話裡抽出來: 迴圈、分支、中間狀態、審查鏈、重試，全都在腳本裡跑，主對話只收到最後的摘要。

官方那篇 “A harness for every task” 非常推薦一讀，把「為什麼需要這個」講得很清楚。當 Claude 在單一 context window 裡又要規劃又要執行，跑久了會出現三種失敗模式:

1️⃣ Agentic laziness (偷懶): 複雜的多步任務做到一半就宣告完成，例如 50 項的安全檢查只做了 20 項就說好了。

2️⃣ Self-preferential bias (偏袒自己): Claude 傾向偏好自己產出的結果，叫它對照評分準則自我審查時，這個偏差特別明顯。

3️⃣ Goal drift (目標漂移): 多輪之後，尤其每次 compaction 都是有損壓縮，「不要做 X」這種邊界約束會慢慢被弄丟。

把任務拆給各自擁有獨立、乾淨上下文的多個 Claude，從結構上就避開這三個坑。

編按: 這三個失敗模式雖然是 Anthropic 自己歸納的，但跟學界的觀察高度吻合。Berkeley 那篇 《Why Do Multi-Agent LLM Systems Fail?》 (MAST) 分析了 1600 多份多 agent 系統的失敗軌跡，歸納出 14 種失敗模式，其中很大一塊正是「驗證不足」跟「提早收工」: 沒有獨立的把關者、任務沒做完就被宣告完成。dynamic workflows 用獨立上下文的 agent 配上對抗式驗證，剛好是針對這類失敗的結構性解法。

最有名的案例是 Bun 從 Zig 改寫成 Rust: 約 75 萬行 Rust、99.8% 既有測試通過、從第一個 commit 到 merge 只花 11 天，靠的就是把任務切成「map → generate → review → verify → fix loop → cleanup」的流水線。

從 Code Interpreter 到 Dynamic Workflows，雖然都是「讓 LLM 輸出程式碼來執行」，但真正分出差異的是: 那段生成的程式碼，被准許呼叫什麼、又被限制成什麼。

✏️ 小編製圖

Code Interpreter 什麼都能寫，但程式碼碰不到 agent 的工具，等於站在 agent loop 外面。CodeAct 的關鍵一步，是讓程式碼呼叫 agent 的工具，把程式碼拉進 loop 裡。之後每個階段的設計取捨不同: Code Mode 框在一套 SDK 裡; PTC 跟 Deep Agents Interpreter 用 allowlist 決定能碰哪些工具跟 agent; Dynamic Workflows 則把程式碼限制在「編排」這一件事，不能直接碰檔案、shell、網路 (那些都丟給 sub-agent)，連時間跟亂數都被禁掉，換來的是 resume 跟決定性。

表格裡另一個值得注意的差異: 程式碼呼叫的是「死的函式」，還是「會自己推理的 sub-agent」。 原始 CodeAct 論文裡，程式碼呼叫的工具都是 lookup_rate 這種固定函式: 你可以用迴圈、條件去串它們的輸出，但函式本身不會思考。

不過嚴格講，CodeAct 這條線本身就能開子代理人，只要塞進去的那個「工具」其實是一個 agent 就行。Hugging Face 的 smolagents 早就做到了: 你給一個 agent 設好 name 跟 description，當成 managed_agents 交給一個 manager CodeAgent，manager 生成的 Python 就能把它當函式呼叫。官方範例裡，一個 manager 指揮底下的 web_search_agent 查資料，自己負責規劃跟計算。所以表格裡 CodeAct 那格的 ✗，與其說是「技術上做不到」，不如說是「原論文沒往這個方向想，生態也還沒把 sub-agent 編排當成主軸」。

PTC 跟 Deep Agents Interpreter 帶出的重點是「程式碼能呼叫 agent tools」，雖然 tool 裡面也可以包一個 sub-agent，但這不是它們強調的用法。程式碼可以用迴圈、條件去組合多個工具呼叫，中間結果留在程式碼裡不必繞回主模型的上下文，後一個工具的輸入還可以拿前一個的結果在程式碼裡算出來 (a = await tool(...); b = await tool(transform(a)))，不必一開始就把所有參數寫死。

真正把 sub-agent 編排當成核心的，是 RLM 的研究和 Dynamic Workflows。RLM 一路主張的就是「以程式化的方式呼叫 sub-agent，把輸出在程式碼裡傳遞，而不經過主模型的上下文」。到了 Dynamic Workflows，開子代理人變成程式碼唯一在做的事，還補上了 resume、可重播、決定性這些硬保證。

表格裡那條 ✗✗✗✓✓ 的分界，標的不是「技術上能不能開子代理人」(CodeAct 透過 smolagents 也做得到)，而是「有沒有把 sub-agent 編排當成一等公民，再用產品級保證撐住」。

PTC / Deep Agents Interpreter 跟 Dynamic Workflows 都能 spawn、也都能分階段，差別不在「能不能」，而在編排層被磨得多硬。Dynamic Workflows 多了 parallel/pipeline/phase 這些原語，可中斷後 resume，還有禁時間亂數換來的決定性; PTC / Deep Agents Interpreter 則更通用、也更鬆，少了這些硬保證。

Dynamic Workflows 把程式碼的角色限制在編排，再用六種固定模式把編排本身也標準化。限制換來的是能 resume、能重播、結果可預期。

六種可以互相組合的編排模式

“A harness for every task” 這篇把常見的編排手法整理成六種，實際用時常常會疊在一起:

1️⃣ 分類並執行 (classify-and-act): 先用一個分類 agent 判斷任務屬於哪一型，再依結果路由到不同的 agent 或行為。也可以反過來放在最後，用分類器決定要輸出什麼。

2️⃣ 分流並整合 (fan-out-and-synthesize): 把任務拆成很多小步，每步開一個 agent，最後再把結果整合起來。適合步驟很多、或每步都需要自己乾淨上下文以免互相干擾的情況。整合那一步是個同步點 (barrier): 它會等所有分流的 agent 都跑完，再把它們的結構化輸出併成一份結果。

3️⃣ 對抗式驗證 (adversarial verification): 每開一個 agent 產出結果，就另外開一個 agent，專門拿評分準則或標準去「反駁」它的輸出。

4️⃣ 生成並篩選 (generate-and-filter): 針對一個主題先生成一堆點子，再用評分準則或驗證去篩，去掉重複的，只留下品質最高、通過檢驗的那幾個。

5️⃣ 錦標賽 (tournament): 不是分工，而是讓 agent 互相競爭。開 N 個 agent 用不同方法各做同一件事，再用一個評審 agent 兩兩比較、淘汰，直到選出贏家。

6️⃣ 直到完成為止持續迴圈 (loop until done): 對「工作量未知」的任務，不要設固定回合數，而是一直開 agent 直到觸發停止條件 (沒有新發現、或 log 裡不再有錯誤) 為止。

6. 更多精彩用法: 它不只拿來寫程式

官方那篇文章裡，小編覺得最有啟發的反而是作者一句話: workflows 用在「非寫程式」的任務上，往往更有威力。挑幾個他給的實際 prompt 範例 (已翻成中文)，順手標出背後用到的模式:

🔹 抓 1/50 機率的 flaky test: 「這個測試大概每 50 次會失敗 1 次。開一個 workflow 重現它，提出幾個假設、在各自的 worktree 裡對抗式地驗證，/goal 設定: 不到有一個假設成立不准停。」(loop-until-done + 對抗式驗證 + 根本原因調查)

🔹 從自己的歷史紀錄煉出規則: 「用 workflow 翻過我最近 50 個 session，挖出我一再重複糾正的地方，把常出現的那幾類變成 CLAUDE.md 規則。」(分流並整合 + 記憶與規則遵循)

🔹 挖出 Slack 裡沒人追的問題: 「用 workflow 翻過去半年的 #incidents 頻道，找出反覆出現、卻從來沒人開單追蹤的根本原因。」(大規模分流)

🔹 多視角壓力測試商業計畫: 「拿我的商業計畫，跑一個 workflow，讓不同 agent 分別站在投資人、客戶、競爭對手的角度，逐點挑毛病。」(對抗式驗證用在非技術任務)

🔹 80 份履歷排序: 「這裡有 80 份履歷，用 workflow 依後端職缺排序，再仔細複查前十名。先用 AskUserQuestion 工具問我評分標準。」(排序 + 生成並篩選)

🔹 命名錦標賽: 「我要幫這個 CLI 工具取名。用 workflow 腦力激盪一堆選項，再跑一場錦標賽選出前三名。」(tournament)

🔹 驗證部落格草稿的每個技術宣稱: 「翻過我這篇部落格草稿，用 workflow 對照 codebase 驗證裡面每一個技術宣稱，我不想出包。」(深度驗證)

這些任務的關鍵不是「大」，而是「有很多獨立的小判斷、需要互相把關、而且最好別全擠在同一個上下文裡」。官方還把適用情境整理成一份清單: 遷移重構、深度研究、深度驗證、上千筆排序、記憶與規則遵循、根本原因調查、大規模分流、探索與品味、評估、模型與智慧路由。反過來作者也提醒: 一般的寫程式任務通常不需要五個審查者的陣仗，別為了用而用。

7. 看一份真的 workflow: deep-research 長怎樣

上面那些模式講起來還是抽象，剛好 Claude Code 內建的 /deep-research 就是用 dynamic workflows 寫的。以下都是直接讀它實際生成的那份 JS 腳本 (數字、門檻都照腳本，不是憑空猜的)。

它的 meta 先宣告整條流水線分成五個 phase:

phases: [
  { title: "Scope",      detail: "把問題拆成 5 個搜尋角度" },
  { title: "Search",     detail: "5 個平行 WebSearch agent，一個角度一個" },
  { title: "Fetch",      detail: "URL 去重，抓前 15 個來源，抽出可查證的主張" },
  { title: "Verify",     detail: "每個主張 3 票對抗式驗證，2/3 票反駁就淘汰" },
  { title: "Synthesize", detail: "合併語意重複、依信心排序、附上出處" },
]

這就是 Claude 為「深度研究」這個任務即時寫出來的 harness，整條流水線長這樣:

✏️ 小編製圖

逐段拆:

Scope (1 個 agent): 把使用者的問題交給一個 agent，要它拆成 5 個互補的搜尋角度 (廣度、學術、近期新聞、反方、實作面)，並用 schema 強制回傳結構化 JSON，不准自由發揮。

Search → Fetch (用 pipeline，不等齊): pipeline() 跟 parallel() 的差別是「要不要等所有人都跑完才往下」(後者是同步點/barrier)。pipeline 不等，所以角度 A 搜完、去重、開始抓網頁的同時，角度 B 可能還在搜，不必等齊。每個角度: 一個 search agent 找 4-6 個結果 → 一段「純 JavaScript」做 URL 正規化、去重、抓取額度控制 → 再對每個沒看過的 URL 平行開一個 fetch agent 抽出主張。

去重、配額這些事完全不是 agent 在做，是普通的 JS:

const novel = sorted.filter(r => {
  const key = normURL(r.url)
  if (seen.has(key)) { dupes.push(...); return false }    // 看過了，丟掉
  if (fetchSlots <= 0 && relRank[r.relevance] >= 1) {      // 額度用完，低相關的丟掉
    budgetDropped.push(...); return false
  }
  seen.set(key, ...); fetchSlots--; return true
})

Verify (用 parallel，這裡刻意要同步等齊): 對排序後的前 25 個主張，每個都平行開「3 個」對抗式驗證 agent。它們的 prompt 開門見山就是「要懷疑、想辦法反駁這個主張」，而且「不確定就預設 refuted=true」。3 票有 2 票反駁，這個主張就淘汰。這正是前面講的對抗式驗證加上生成並篩選，而 self-preferential bias 在這裡被結構性擋掉了: 驗證的不是寫出主張的那個 agent，是另外三個被叫來找碴的 agent。

parallel(Array.from({ length: 3 }, (_, v) => () =>
  agent(VERIFY_PROMPT(claim, v), { schema: VERDICT_SCHEMA })
)).then(verdicts => {
  const refuted = verdicts.filter(v => v.refuted).length
  return { ...claim, survives: refuted < 2 }   // 2 票反駁就淘汰
})

Synthesize (1 個 agent): 把存活下來的主張交給一個 agent，合併語意重複、分組成一條條 finding、依信心高低排序、附上出處，產出一份有引用的報告。

看完這份腳本就會發現，所有「需要判斷」的事 (拆角度、搜尋、抽主張、反駁、整合) 都包在 agent() 裡; 而所有「不該讓模型亂猜」的事 (串接、去重、計票、排序、淘汰) 全是寫死的 JavaScript。一個 agent 偷懶或看走眼，只會壞掉它自己那一格，不會污染整條流水線。

8. 模型生成腳本，但腳本本身是決定性的

這裡有個觀念要分清楚，也是整套設計最巧妙的地方: 寫 workflow 的是模型，但 workflow 一旦寫好，執行就是決定性的。

模型的判斷只發生在兩個地方: 一是「寫出這份腳本」的當下，二是每個 agent() 呼叫的內部。中間的迴圈、分支、去重、計票、合併，全是寫死的 JavaScript，跑幾次結果都一樣。所謂的「dynamic」，動的是「腳本被生出來」這一刻; 一旦生出來，它就是一份規規矩矩、可重播的程式。

Yi Ding 的觀察蠻精準的: 這東西本質上就是一個 (相當詳細的) prompt，教模型用 JavaScript 寫出一段像圖結構的編排描述。那段「教模型寫 workflow」的 prompt 大致在教這些 (示意，非逐字):

你可以寫一支 JavaScript 編排腳本，開頭必須是:
  export const meta = { name, description, phases }   // 純字面值，不能放變數或運算

腳本裡可以用這些函式:
  agent(prompt, { schema, label })  // 開一個 sub-agent;給 schema 就強制它回傳結構化 JSON
  pipeline(items, stage1, stage2)   // 每個項目獨立流過各階段，不等齊 ← 預設首選
  parallel(thunks)                  // 一次跑多個、等全部完成才往下 (barrier) ← 真的需要才用
  phase(title) / log(msg)           // 分組與進度回報

規則:
  - 預設用 pipeline，只有「下一階段真的需要上一階段全部結果」時才用 parallel
  - 想更可信就用對抗式驗證: 每個發現另外開 N 個 agent 試著反駁它
  - 不准用 Date.now()、Math.random()、無參數的 new Date()

最後那條規則小編覺得最特別。一個正常的 JavaScript 環境怎麼可能不給你取時間跟亂數? 但 workflow 偏偏把這幾個函式做成會直接報錯。原因藏在 resume 機制裡: workflow 會把每一個 agent() 呼叫的結果寫進一份執行日誌，這樣中斷的執行才能原地接續 (已經跑完的 agent 直接從日誌裡回傳快取結果，只有沒跑完的才重跑)。一旦腳本裡摻了時間或亂數這種非決定性的東西，重跑時就會跟上一次對不起來，日誌裡的快取立刻失效。所以要時間戳記，就從 args 傳進來; 要讓每個 agent 長得不一樣，就用索引 (index) 去變化它的 prompt 或 label。

這個特別的限制也說明了整套設計的核心: 編排層必須是純粹、可重播的，模型的不確定性被嚴格關在 agent() 這個盒子裡。外面是一份能 resume、能重跑、能存檔重用的程式; 裡面才是會思考、會判斷、偶爾也會犯錯的模型。

也有幾個現實邊界值得先知道:

• 成本: 一次跑幾十上百個 agent，token 成本明顯比一般對話高，官方建議先拿小範圍試水溫
• 不能中途插手: 執行中不能插入使用者輸入，需要人工核准的地方，得拆成兩個 workflow、中間留一個核准空檔
• 檔案修改自動核准: sub-agent 預設跑在 acceptEdits 模式，所以真正該把關的是腳本本身與 workflow 邊界
• resume 有限制: 只保證在同一個 Claude Code session 內有效，關掉重開就是從頭跑

收束: 這一切其實很符合 Bitter Lesson

ihower 之前在這個部落格寫過一篇 Bitter Lesson 與 agent harness，裡面點名一個「workflow trap」: 視覺化的 workflow builder 把任務拆解鎖死在一張固定的圖上，模型之後變強了，這張圖也不會自動受益，反而變成包袱。照 Bitter Lesson 的邏輯，把可靠性押在人工手刻的鷹架程式碼 (scaffold) 上，是把複雜度搬錯方向。

dynamic workflows 巧妙地閃過了這個陷阱。差別在於: 拆解 workflow 的不是人，是模型，而且每個任務都重新寫一份客製的。 官方那句話講得最到位: Claude 現在可以「為手上的任務即時寫出自己的 harness」。你拿到了確定性編排帶來的可靠性 (避開偷懶、偏袒、漂移)，卻不必付出人工設計鷹架的代價，而那種鷹架正是模型一變強就第一個被淘汰的東西。所以這個設計是順著 Bitter Lesson 的: 連「編排」這件事本身，也交還給模型。

ihower 那篇的結論是: 原本覺得需要人工編排的 workflow 任務，幾乎都能丟給模型即時生成的 harness，不必再事先設計流程。dynamic workflows 基本上就是這個方向的具體實現。

小編看法

最後小編補幾個比較主觀的想法。

需要 GUI 支援

如果它就停在 CLI 這個形態，小編覺得採用門檻會偏高。原因是這套概念其實偏抽象: 計畫從上下文搬進腳本、決定性編排、對抗式驗證，這些好處都要想一層才懂，不容易一眼看懂。對多數使用者來說，體感上最直接的反而是「token 怎麼燒這麼兇」，那個爽點 (省下的上下文、避開的偷懶與漂移) 卻是隱形的，藏在你看不到的地方。

但如果把它做成 GUI，讓那份編排腳本變成一張動態的節點與連線圖，agent 怎麼分流、在哪裡匯合、哪一條審查鏈正在跑、哪個節點卡住了，全部即時長在眼前，採用率會高很多。因為「看見流程怎麼跑」這件事太有感了，它把隱形的價值變成你盯著看的畫面。

希望同時支援事先生成和動態生成

目前 Claude Code 是靠 ultracode 自動判斷這個任務要不要動用 workflow，而且每次都是當場重新編排一份。你雖然可以把喜歡的那份存下來、下次重用，但小編實測後發現，存下來的腳本常常把這一次執行的具體場景 (檔名、數量、路徑那些) 寫死進去，重用性其實沒那麼完美。更可惜的是，你沒辦法「先讓它把 workflow 的 JavaScript 生出來、自己檢查過、確認沒問題，再真正執行」，生成跟執行是綁在一起的。

其實這就是前面講的 LangChain interpreter skills 在做的事: 事先寫好一份確定性的編排腳本，存起來重用。小編希望 Claude Code 能兩種都支援: 對重複性高的任務，可以事先生成、檢視、微調一份 workflow 腳本再拿去跑; 對一次性的任務，維持現在每次動態生成的做法。

不過還是得說一下這兩種做法的優缺點:

• 事先生成: 可檢視、可測試、可微調，對重複性任務更可控。但缺點是一旦把編排凍結下來，模型下一版變強了，這份腳本也不會自動受益，反而可能變包袱，這正是前面講的 Bitter Lesson 的風險。
• 動態生成: 每次針對當下任務量身定做，模型變強就自動受益，不會被舊腳本綁住。但缺點是你沒辦法事先檢查，生成跟執行綁在一起，而且存下來的腳本容易把場景寫死。

或是有一種中間解: 執行前能把生成的腳本叫出來瞄一眼、改幾筆 (要不要看是你的自由，不強制)，存檔時多一步「幫我把這次的檔名、數量、路徑抽成參數」，讓重用的是「編排骨架」而不是「那一次的場景」。這樣既保住動態生成的彈性，又補掉現在重用會寫死的痛點。

OpenAI 的缺席

小編覺得比較可惜的是，整條脈絡最起點的 Code Interpreter，當年其實是 OpenAI 在 ChatGPT 上帶火的 (一度叫 Advanced Data Analysis)，是它先讓大家看到「讓模型寫程式碼、跑程式碼」有多好用。但後來把「程式碼當行動空間」一路往 agent 編排推的，反而是 Cloudflare、Anthropic、LangChain 跟學界。OpenAI 在 Codex 產品層有做 subagents (平行 spawn 多個 agent)，但在 API 層、SDK、產品上一直沒有走「程式碼當行動空間」這個方向，沒有 PTC 等級的東西，Code Interpreter 裡的程式碼到現在還是碰不到 agent 的工具。

補充比較: 那 agent teams 呢? 小編沒那麼看好

跟 dynamic workflows 幾乎同期，Claude Code 還推了另一個平行化功能 agent teams (目前還是 experimental、預設關閉)。

一句話講清楚差別: dynamic workflows 是「模型寫一份決定性腳本，編排一群各自獨立的 sub-agent」; agent teams 則是「開一個 team lead，底下生出好幾個完整的 Claude Code 實例當隊友，隊友各有自己的上下文、能互相點對點傳訊、搶同一張 task list 的工作」。subagent 只會把結果回報給主 agent，彼此不講話; agent teams 的隊友則能互相討論、互相挑戰，你甚至可以分別對每個隊友下指令。

圖片來源: Cat Wu (@_catwu)

小編在 《Multi-Agent 反模式與推薦模式》 那篇整理過一個核心判斷: multi-agent 的價值是「並行覆蓋」，不是「分工」。 而 agent teams 的賣點剛好踩在這條線上，看你怎麼用，很容易滑到錯的那邊:

1️⃣ 「角色分工」很容易滑進三省六部的幻覺。 官方範例那種「一個管 UX、一個管架構、一個當魔鬼代言人」「一個查安全、一個查效能、一個查測試」，如果是唯讀的審查或研究，那是健康的並行覆蓋，沒問題。但只要任務變成「每個隊友各認領一個模組去寫 code」，就掉進那篇點名的反模式: LLM 沒有人類的注意力上限，貼上「架構師」「QA」的角色標籤不會讓它更強，只會多出人為的推諉跟一層層的傳話漂移。

2️⃣ 並行寫入的老問題它沒解，只是叫你自己閃。 官方文件自己就寫: 「兩個隊友改同一個檔案會互相覆蓋，請把工作切開、讓每個隊友各自負責不同的檔案。」避免衝突的責任，被原封不動丟回給你手動切。Devin、Cognition 的工程經驗早就講白了: 平行寫入到現在還是行不通，可靠的做法是「單線寫入、其他 agent 只負責判斷」。

3️⃣ 點對點通訊 = 通訊開銷 + 傳話遊戲。 隊友彼此直接傳訊 (官方範例還鼓勵它們「像科學辯論一樣互相反駁」)，agent 一多，訊息就多、漂移就多、也更難觀測。對照之下，orchestrator-worker (subagent、dynamic workflows 走的就是這條) 把溝通收斂到中心，反而更穩、也更好整合。那篇也提過，大廠 (Anthropic、OpenAI、Google) 實際用的都是 orchestrator-worker，不是角色扮演的流水線。

4️⃣ 成本跟可靠性都還沒到位。 每個隊友是一個完整的 Claude Code 實例 (不是輕量 subagent)，token 隨人數線性往上疊。multi-agent 普遍燒 3-10 倍，Anthropic 自家 research 系統甚至約 15 倍。而且三個 90% 正確率的 agent 串起來，整體正確率掉到 72.9%。目前它還掛著一排 experimental 限制: 不能 resume、task 狀態會 lag、關機很慢、一次只能帶一個 team、不能巢狀、lead 還不能換人。學界也才剛出一篇 CooperBench，直接以「為什麼 coding agent 還當不了你的隊友」為題，點出它們缺的正是找共識、協調這種社會性能力。

另外一個觀察: agent teams 到現在還是 experimental、預設關閉，你得自己去設一個 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境變數才打得開。相比之下 dynamic workflows 直接上線、ultracode 隨叫隨用，兩者的成熟度差距從預設值就看得出來。

小編認為 agent teams 相對 dynamic workflows 的優勢並不明確。官方推薦的入門場景是唯讀的並行探索 (PR 審查、競爭假設除錯、查資料)，但 dynamic workflows 用決定性編排加上對抗式驗證，一樣能做這些事，而且更便宜、更可重播。agent teams 真正不同的地方是「你可以在執行中途跟個別隊友對話、調整方向」，這是 workflow (背景跑完才回來) 做不到的，但這個互動性是否值得額外的成本和複雜度，目前沒有明確的證據。一旦想拿它來「分工寫 code」，就撞進那篇反模式的失敗區。

✏️ 小編製圖

這兩者真正的差異在前面講的那些: 決定性與可重播、成本結構、通訊模型 (中心化 vs. 點對點)、以及並行寫入的可靠性。從這些維度看，dynamic workflows 目前成熟度明顯領先，而 agent teams 還在找它真正不可替代的場景。

參考連結

• Executable Code Actions Elicit Better LLM Agents (CodeAct 論文)
• smolagents (Hugging Face CodeAct 實作)
• OpenAI Code Interpreter
• Cloudflare Code Mode
• Cloudflare Code Mode MCP Server
• Claude Programmatic Tool Calling (PTC)
• LangChain Deep Agents Interpreter
• LangChain Interpreter Skills
• RLM 論文 (Recursive Language Models)
• Claude Code Dynamic Workflows 官方 Blog
• Claude Code Dynamic Workflows 官方文件
• “A harness for every task” by trq212
• Voxyz: 計畫從上下文搬進腳本
• Yi Ding: workflow prompt 分析
• alexop.dev: 決定性編排與 resume 機制
• Omar Khattab: Claude Code 終於是一個 RLM
• Alex Zhang: 第一個被認真訓練成 RLM 的前沿模型
• Cat Wu: Agent Teams vs Dynamic Workflows
• Claude Code Agent Teams 文件
• Why Do Multi-Agent LLM Systems Fail? (MAST)
• CooperBench: 為什麼 coding agent 還當不了你的隊友
• smolagents Multi-Agent 範例
• Bitter Lesson 與 agent harness (愛好 AI Blog)
• Multi-Agent 反模式與推薦模式 (愛好 AI Blog)

OpenAI 對 Codex App 的投入，確實比 CLI 下了更多功夫。這篇就來條列幾個「只有 GUI 才辦得到」的特色，很多都是 CLI 裡根本想像不到的玩法。主軸參考自 Jason Liu (jxnl) 的 Codex-maxxing，加上近期幾波官方更新。各特色也附上官方文件連結方便深入。

1. Appshots: 把畫面外的內容也一起餵進去

按住左右兩顆 Command 鍵 (快捷鍵可改)，Codex 就會把你滑鼠所在的視窗截圖，自動塞進輸入框。

你會說這不就是截圖而已嗎? 不，不只是截圖而已，它連畫面上的文字，甚至畫面外的文字也會一起傳入，超猛。舉例來說，你在看一份 Google Doc 拍 appshot，已經捲出畫面外的內容也會被讀進去。這跟 computer use 一樣，拿得到 App 裡的完整文字，而不只是肉眼可見的那一塊。(官方文件: Appshots)

實務上很有感: 以前在瀏覽器看到一個 bug、在設計稿看到一個要實作的介面，得自己截圖貼上、再打字補充脈絡。現在一個快捷鍵就把完整上下文帶進去了。

2. Remote control: 手機或另一台電腦都能遠端操控

Codex 可以遠端控制跑在另一台電腦上的 Codex: 手機的 ChatGPT App 能遙控，桌面版的 Codex app 也能遙控另一台機器，連螢幕鎖定的狀態下也跑得動。iPhone 上的操作體驗做得相當完整，不只是看進度而已。

而且 Linux 上的 Codex 也能被遠端遙控，不一定要 Mac 裝 Codex app 才行。有趣的是官方文件沒寫這段，可能還算是個隱藏功能 🤣 指令是在那台 Linux 上跑 codex remote-control，它就會起一個 Codex server，然後你用 Mac 或手機上的 Codex app 就能去遙控這台機器。ihower 實測拿 Ubuntu Desktop 來遠端遙控、打開 Chrome 都沒問題，比 SSH connect 好用多了。

編按: 官方文件: Remote connections、公告 Work with Codex from anywhere。文件主要寫 Mac/Windows 當 host，Linux 的 codex remote-control 走法目前沒明說。

3. $browser、@chrome、@computer: 三種上網/操作介面

GUI 版把「讓 Agent 去操作介面」拆成三個情境:

• $browser: 側邊面板裡的內建瀏覽器。特別適合在開發網頁時用: 你跟 Codex 看著同一個正在跑的頁面，直接在元素上標註、留言、要求調整，它就照著改、即時重新整理給你看，是前端 UI 迭代的好搭檔。(官方文件: Browser)
• @chrome: 接你已登入狀態的 Chrome，跑以瀏覽器為基礎的工作流。值得一提的是它可以在背景同時跑多個分頁: 每個任務開一個 tab group，做完自動清掉，只在需要你 review 時才把分頁交還，所以你照常用瀏覽器它也不打架。適合在登入後的網站做 deep research、把資料大量搬進 CRM/CMS，或自動化內部後台的重複操作。(官方文件: Chrome extension)
• @computer: 用於那些只能透過桌面 GUI 才存在的工作。它一樣可以在背景跑: 交辦下去之後，agent 在桌面背景中執行，你可以繼續手邊的工作，互不干擾。能讓程式在背景操控其他 Mac app、又不破壞前景使用體驗，核心技術是 OS 層級的 sandbox: 每個 agent 都有自己獨立的滑鼠指標，可以平行跑。(官方文件: Computer use)

4. 語音輸入: 在任何地方都能用快捷鍵口述

Jason 認為語音輸入的價值在於: 它能在想法被壓縮成精緻文字「之前」，先捕捉到那個粗略原始的版本。像「去找一下 Ben 在 Slack 提過的那個東西」這種帶著語感的指令，用打字反而會懶得寫完整。

而且這是 App 內建的，不用另外買 Whisper Flow 之類的語音輸入工具、也不用另外裝什麼。設好快捷鍵後，你在任意地方都能直接口述。

編按: 如果你用外接麥克風，記得去 Mac 的音量/麥克風設定改一下預設輸入裝置，不然會抓錯。

5. Steering 與 Queuing: 它還在跑，你就先打字

情境是這樣: Codex 還在輸出、還在跑工具，你不必等它停下來才動。直接在輸入框打字送出，這則訊息會有兩種用法:

• Steering (插隊改方向): 不等當前步驟做完，立刻打斷它、塞進新的指示。適合你看著它正往歪的方向走、想即時修正的時候,例如「這個改小一點」「不對，先別動資料庫」。
• Queuing (排隊接著做): 不打斷當前步驟，讓這則訊息排進佇列，等它把手上這步做完再接著執行。適合你已經想好下一步、想先交代起來放著，例如「跑完記得順手開個 PR」「接著把測試補上」。

差別就在「現在就插話」還是「等它講完再講」。其實 CLI 也做得到，但你得記住快捷鍵才能正確切換這兩種行為; GUI 則是直接把選項攤在介面上讓你點選，一看就懂該按哪個，不用背指令。

6. 釘選 threads: 長執行緒重新變成可行解

Jason 為每一條他在意的重要工作流，都保留一條釘選的對話串，讓這些持久性執行緒隨手就在附近。這些 thread 會累積歷史與決策，變成耐久的紀錄，而不是用完即丟的對話。

有意思的是，「讓單一執行緒一直長期跑下去」過去常被視為 anti-pattern，但現在可以重新考慮這樣用。不過小編覺得這有個前提: 你心智上要很清楚自己會用到 sub-agents 來分流，不能把所有東西都硬塞進同一條主線。這點 Codex-maxxing 那篇講得蠻細的，值得一讀。

7. Fork: 從任意一則 AI 輸出岔出一條新 thread

在 GUI 上你可以對之前任意一則 AI 的輸出點「fork」，當場拆出一條新的 thread，從那個點接著走別的方向，原本那條對話原封不動。

最常見的用法是岔題不弄亂主線: 你在一條 thread 裡正做著功能 A，半路發現一個 bug，與其在原本對話裡插一段把脈絡攪亂，不如直接從當下這則訊息 fork 出去，在新 thread 裡專心修 bug，而它先前累積的東西 (摸熟的 codebase、剛討論好的計畫) 全都帶著走。或者你剛跟它把一份計畫討論完，想分頭深入其中一塊、又不想動到計畫主線，fork 一下就有一條乾淨的分支。

其實 CLI 也有 /fork，但痛點在於很難指定「要從哪一則訊息岔出去」(社群裡就有人抱怨對話開頭都長得一樣，根本分不出該 fork 哪一條)。GUI 把整條 transcript 攤在眼前，你直接點那一則輸出就能 fork，分岔點一目了然，這種操作真的是要有圖形介面才順手。

8. 平行多工: 一個視窗同時跑很多條任務

Codex App 的介面左側欄就是一條 threads list (對話列表)，每一條 thread 是一個獨立的任務。你在同一個視窗裡可以同時跑多條 thread、各自獨立推進，左欄掃一眼就知道每條跑到哪、哪條已經跑完、哪條卡住要你處理。可以一邊讓它在背景重構某個模組，一邊在另一條 thread 修 bug，點一下左欄就切過去，互不干擾。

這在 CLI 上特別痛: 純命令列一個視窗就是一條對話，想平行就得自己開一堆終端機分頁、自己記哪個在做什麼。也因此市面上冒出一大票工具專門來補這個洞，像 cmux 這種「同時驅動多個 coding agent」的調度工具，連 Claude Code 最近也補上了 Agent View，讓你從一個畫面派發、管理多條 session。Codex App 則是一開始就把平行多工內建在介面裡，不用外掛。

9. Thread automations: 排程喚醒、回到同一條執行緒

這個概念很像 openclaw 的 Heartbeat: 週期性的喚醒呼叫，依排程回到同一個 Codex 執行緒繼續推進，而不是每次都從頭開一個新的。

支援分鐘級的頻繁輪詢，也能設每日/每週的定時 check-in。它特別適合做回饋迴圈: 監看 pull request 留言、Google Docs 留言或 Slack 回覆，在你不在座位時持續推進周邊工作。寫 automation prompt 時要交代清楚「每次醒來該做什麼」「怎麼判斷有沒有重要發現」「何時該停下來問人」。(官方文件: Automations)

10. 側邊面板: 就地檢視各種工件

這大概是 GUI 相對 CLI 最直覺的勝場。側邊面板讓你可以就地檢視 Markdown、試算表、資料表、文件和投影片，還有 terminal、瀏覽器、檔案瀏覽。

關鍵在於你和 Agent 看的是同一份工件: 不用中斷流程，就能檢查、標註、修訂。配合進階註記模式，甚至可以在內建瀏覽器裡直接拖拉、調整頁面元素並留批注，多條修改攢成一批一起送。對設計師和前端協作來說，再也不用截圖畫圈寫「這裡往左移 10px」了。git diff 的 code review 也一樣: 右側直接看變更、逐行留 inline 註解、挑 chunk 分段 commit，全程不離開 App。

11. 影像生成: 在開發流程裡直接生圖

這是 OpenAI 自家有影像模型 (GPT-Image-2) 才辦得到的整合: 你可以直接在對話裡叫 Codex 生成或編輯圖片，不用切到別的工具或另外接 API。大多數人最直接的用法，就是在做 UI 素材、banner、背景、插圖、遊戲 sprite sheet、投影片 mockup 時，能更穩定地一張接一張持續生成，要幾張生幾張、要微調再讓它改，整個過程都在同一條 thread 裡完成。

進階玩法: 先生 UI 圖，再讓 Codex 對照寫 code

再往前一步，OpenAI 的 dkundel 分享過一個更有意思的方向: 一般像 Claude 那種「用 AI 設計網頁」是直接生 code 把畫面長出來; 而 Codex 這裡可以反過來，先用 GPT-Image-2 生出一張 UI 設計圖，再讓 Codex 對照那張圖去產生對應的 code，先有視覺、再有實作。他的完整玩法是: 手上沒設計稿時先請 GPT-Image-2 生一張 UI，當成規格交給 GPT-5.5 寫成真正的 app，過程中用內建瀏覽器驗證，還能順手生出 app 需要的素材來潤飾;「Build Web Apps」外掛就把這條迴圈包成一個 skill。小編還沒認真比較過這兩條路線 (直接生 code vs 先生圖再對照) 的優劣，但這個創新用法蠻值得玩玩看的。(原文)

12. 長任務 Goals: 用側邊面板盯一個跑很久的目標

/goal 這個功能本身 CLI 也有: 給一個目標，它就一路執行到完成，過程可能橫跨數小時甚至數天。GUI 的差別在於「怎麼看進度」可以做得很舒服。(官方文件: Follow goals)

banteg 的用法很巧妙: 讓 goal 一邊跑、一邊產出一個 HTML 進度儀表板，直接用 Codex 內建瀏覽器開在側邊面板。左邊是 Agent 在做事，右邊是即時更新的圖表和指標 (完成度、匹配率、各 commit 的進展)，一眼就看到跑到哪了。

圖片來源: banteg on X

另一招是 dotey 提到的 /side: 對一個跑很久的 goal，開一個 side chat 不影響主任務、又帶著完整上下文，直接問「目前進度如何? 還要多久?」。

要補一句 Jason 強調的: 目標的品質決定一切。弱的目標像「把這份 Markdown 實作出來」，強的目標帶著可衡量的成功標準。他做 Rich 轉 Rust 的遷移時，直接拿原本的測試套件當驗證標準。「執行的成效，頂多只會跟你給的目標與驗證一樣好。」沒有 oracle 的長任務，跑再久也只是漂移。

回到最初的問題: 為什麼這些是 GUI 才辦得到的?

Jason 在 Codex-maxxing 裡點得很到位: 側邊面板讓 Codex「不再只是一個聊天 App，而開始變成工作真正發生的地方」。重點不只是 Codex 能產出工件，而是你能在不打斷迴圈的情況下，當場檢視並標註它。這正是 CLI 結構上做不到的: 命令列的輸出跑完就消散，你沒辦法跟 Agent 盯著同一份試算表、同一張投影片邊看邊改。GUI 把「對話」升級成「工作台」，這是純文字介面塞不進來的東西。

編按: Jason 另一篇 用 Codex 做晨間簡報的六個複雜度層級 也很值得一讀。他用大家都懂的「晨間簡報」當例子，從最陽春的一句 prompt，一層層加上連接器、個人化預設、排程自動化、分專案執行緒、自動草擬回覆、持久記憶庫，示範怎麼把一個小工作流調教成「你工作的迷你作業系統」。核心心法是: 先從新手也懂的版本開始，每次只加一個真正的能力，直到整個系統的形狀自己浮現出來。

還有一點別忘了: 對非工程師來說，CLI 的上手門檻其實還是偏高。要開終端機、要記指令、要懂一堆參數，光是這關就把很多設計師、PM、行銷的人擋在外面了。Appshots、就地標註、點選式的操作這些 GUI 設計，等於把參與 AI 開發流程的門檻一口氣拉低，讓不寫 code 的人也能直接上手。

CLI 仍然有它輕快、可組合、好自動化的價值，而且可以跑在沒有圖形介面的 Linux server 上，方便接進 CI、排程或各種自動化腳本，這是 GUI 取代不了的。而 Codex App 特別用心經營的，是人機協作: 把人跟 Agent 並肩工作的每個環節都做得更順手。當協作的對象從工程師擴大到設計師、PM、各種角色時，一個夠好的 GUI 能裝下的東西，是命令列怎麼也塞不進來的。

一篇是 Karpathy 的 autoresearch: 把一個迷你的神經網路訓練腳本丟給 agent，讓它整夜自己跑幾百個實驗、自己調出更好的模型。另一篇是 EnvPool 作者、OpenAI 研究工程師 Jiayi Weng (翁家翌) 的 Learning Beyond Gradients: 完全不訓練神經網路，讓 Codex 反覆改純規則的程式碼，居然把 Atari、機器人控制這些任務做到逼近 Deep RL 的水準。

兩篇放在一起看才有意思: 它們是同一個範式的兩個極端代表作。小編這篇就把這個範式講清楚，順帶整理社群已經跑出來的一票案例，還有一個最關鍵的但書: 這招的命脈到底卡在哪。

autoresearch: 讓 agent 整夜自己做研究

先看 Karpathy 這邊。autoresearch 的設定極簡: 把 nanochat (他那套 GPT-2 等級的訓練程式) 砍成單張 GPU、約 630 行的單檔版本，然後分工:

• 人類只改 program.md (一份用白話寫的指示，告訴 agent 該往哪個方向探索)。
• AI agent 只改 train.py (模型架構、優化器、所有超參數)。

接著 agent 進入一個自主迴圈: 每次改一點訓練程式，跑一次固定 5 分鐘的訓練，用驗證集的 bits-per-byte (可以理解成驗證損失) 當分數，比上一版好就 git commit 留下、不好就丟掉，然後接著試下一個。Karpathy 形容得很傳神: 圖上每一個點都是一次完整的 5 分鐘訓練，agent 在一條 git 分支上不斷累積 commit，目標是「設計你的 agent，讓它能無限期、在你完全不插手的情況下，跑出最快的研究進度」。

讓它行得通的幾個設計約束很值得抄:

順帶看一眼那份 program.md 到底寫了什麼，就懂為什麼說「人在編程那個研究員」。Karpathy 原版的內容，其實就是一份給 agent 的操作手冊:

短短一份 markdown，就把工作流、邊界、記錄、復原、取捨標準全定義好了。

成果是真的有東西。Karpathy 自己在 nanochat 上跑了約 700 個實驗，找到約 20 個真正有效的改進，疊起來讓「練到 GPT-2 水準」的時間從 2.02 小時降到 1.80 小時 (快 11%)，而且 agent 抓到好幾個他自己漏掉的點 (例如 QKNorm 少了一個縮放、Value Embeddings 沒上正則化、注意力窗口開太保守)。更誇張的是 Shopify 執行長 Tobi Lütke 的例子: 他叫 agent 讀 autoresearch 的程式庫、改寫成自己查詢擴展任務的版本，然後就去睡覺，醒來時一個 0.8B 的小模型在 8 小時跑了 37 個實驗後，分數比他之前的 1.6B 模型還高了 19%。一個小一半的模型贏過大的。

Karpathy 特別澄清: autoresearch 不是一個你「拿來用」的工具，而是一個配方、一個想法。把它交給你的 agent，套用到你真正在乎的東西上就行。這句話是理解整個範式的鑰匙。

真正該學的: 約束越緊，agent 越好用

Manthan Gupta 有一篇 拆解 autoresearch 的好文，把這套設計背後的原則講得很透。他的核心觀察很反直覺: 最好的自主系統不是最自由的，而是約束最嚴格、目標最清楚、失敗成本最低的那種。 幾個能直接搬走的心得:

• 約束讓 agent 更好，不是更差: 只能改一個檔、只追一個指標、只在分數變好時前進。很多 agent 系統反而死在太早給太多自由，自由越多、能出錯的面積就越大。
• 該優化的是 harness，不是模型: 一個普通的 agent 配上一套好的 harness (怎麼啟動、怎麼處理失敗、怎麼量進步、怎麼回滾爛路徑)，會贏過一個更強的 agent 配上一團亂的 harness。
• prompt 就是架構的一部分: autoresearch 真正的控制面其實是那份 program.md，它定義了工作流、邊界、復原方式、取捨標準。Manthan 講得很妙: 人不只是在編程模型，而是在編程那個研究員。
• 可回復、可觀測不能妥協: 輸的實驗要能便宜地丟掉、每一步都能從 log 和 commit 追溯，agent 才敢大膽探索。

Learning Beyond Gradients: 把同一招推到不碰神經網路

Weng 這邊是從另一端逼近同一件事。他在業餘維護 EnvPool 時，本來只想要一個便宜的規則策略來測試遊戲環境，結果用 Codex (gpt-5.4) 寫純規則版本，效果離譜到讓他改變了想法:

• Atari Breakout (打磚塊): 分數一路 387 → 507 → 839 → 864，打到理論最高分。
• MuJoCo Ant (四足機器人): 純 Python 策略先學會節律步態，再接上短視窗的模型規劃，衝到 6000+，進入常見 Deep RL 的量級。
• VizDoom (第一人稱射擊): 只用 cv2/NumPy 處理螢幕影像、完全不訓練網路，也能拿到像樣的分數。

關鍵不在分數，而在: Codex 不是在訓練網路，而是在維護一套「還能繼續長大」的軟體系統。最後的 Breakout 策略遠遠超過「球在左邊就往左」這種一行規則，它長出了動作探測、狀態讀取、落點預測、卡死偵測、回歸測試、影片回放、實驗記錄。

什麼是 Heuristic Learning

Weng 把這個過程命名為 Heuristic Learning (HL，啟發式學習)，維護的對象叫 Heuristic System (HS，啟發式系統)。它跟 Deep RL 一樣，都有「狀態 → 動作 → 回饋 → 更新」這個閉環; 差別在於: Deep RL 更新的是神經網路權重，HL 更新的是軟體結構，而且改動由 coding agent 直接改程式碼完成，不走反向傳播。

這裡有個容易誤會的地方要講清楚: 它的重點不是「叫 LLM 生成一堆規則」(那種事 FunSearch、Evolution of Heuristics 早就在做)，而是被維護的對象是一整套接在一起的軟體系統。Weng 講得很白:「單一規則是不夠的，規則、回饋、歷史、下一次更新的路徑都要連起來，才算是一個 HS。」

兩個細節最能說明差異。第一，更新改的是整個系統，不只是策略: Breakout 從 387 爬到 864，靠的不是「調返球準確度」，而是 Codex 看失敗影片、定位問題、加上「卡死偵測 + 軌跡擾動」這種新機制，再補回歸測試確保舊能力不退化，這已經是在做軟體工程。第二，「壓縮歷史」跟「吸收回饋」一樣重要: 只生成規則的系統只會越長越大、最後變成沒人敢碰的爛泥，健康的 HS 必須能把一堆局部補丁折回更簡單的表示。

把策略寫成可讀的程式碼，也帶來幾個 Deep RL 沒有的好處: 策略可解釋 (規則能翻成白話)、樣本效率高 (一次有效的修改就直接跳到新策略，不用慢慢爬學習率)、舊能力可以固化成回歸測試和黃金案例，因此能避開一部分災難性遺忘 (舊能力不必只活在權重裡)。

為什麼這招以前行不通

HL 的祖先其實就是專家系統、規則系統，這些東西不是沒用，而是沒人養得起。Weng 描述得很傳神:

今天加一條規則修好情況 A，明天情況 B 又壞了，後天再補一個 if 判斷，再過幾天，沒人敢刪任何一行。

人手維護規則系統，就像工業革命前用手紡紗: 一個人做得來，但規模一大、維護成本就把人壓垮。紡紗機改變的是生產曲線，coding agent 改變的正是規則系統的維護成本曲線，於是過去只能當一次性補丁的規則，現在開始變成值得長期擁有的程式碼。

不過 Weng 也誠實地說: coding agent 不會自動解決持續學習，它只是把「避免遺忘」變成一個更工程化的問題。新規則可能修好一個失敗卻弄壞舊場景、測試太窄會被鑽漏洞、規則一直疊加到 agent 自己都維護不動。所以問題只是換了個形狀: 從「怎麼更新神經網路參數」，變成「怎麼維護一套能持續吸收回饋、又不會爛掉的軟體系統」，這正是它接上持續學習 (continual learning) 的地方。

同一個骨架: coding agent 當「外層優化器」

把兩篇擺在一起，骨架就浮出來了。它們都是同一個迴圈:

coding agent 反覆「改一段可編輯的程式碼 → 跑 → 讀可驗證的指標 → 留好的、丟壞的」，過程中完全不更新模型權重。

差別只在「那段可編輯的程式碼」是什麼。autoresearch 改的是訓練腳本，內層還是在訓練一個神經網路; HL 改的是策略程式本身，完全不碰神經網路。兩端對照起來特別清楚:

共同的前提只有三個: 受限的編輯空間(只准改某個檔或某套程式)、可重現的執行環境(能一跑再跑)、穩定可驗證的指標(能自動判好壞)。只要這三樣齊備，coding agent 就能當外層優化器，在裡面爬分。

至於兩者的差別，不是對立，而是一條光譜的兩端。autoresearch 偏向「在固定框架內，搜尋出一次性的最佳實驗結果」，內層常常還是在訓練神經網路; HL 則把光譜推到底: 被優化的對象本身就是最終策略、完全不要神經網路，而且強調這套軟體系統要被長期維護。Karpathy 說 autoresearch 是個「可套用到任何你在乎的東西」的配方; Weng 等於就把它套用到了「軟體系統本身」這個極端上。有趣的是，社群早就注意到這層關係: 有人引 Karpathy 的話「任何你在乎、又能快速評估的指標，都可以丟給一群 agent 去 autoresearch」，還真的拿它去搜純數學問題 (Ramsey 數的下界)，完全沒有梯度。

社群已經在跑: 這是範式，不是孤例

autoresearch 在週末爆紅後，社群很快把這個迴圈套到各種東西上，而且越套越能看出它的通用性:

🔹 把這套做成現成工具: evo: evo-hq 團隊把這個優化迴圈包成一套現成工具 evo。它的形式是: 底層一個 CLI 引擎，再用 evo install 裝進你的 coding agent (Claude Code、Codex、Cursor 等)，在裡面就變成 /evo:discover、/evo:optimize 這類斜線指令。用起來是: 給它一個 codebase 和一個「更好」的指標，它就自己建評估、開沙箱平行跑實驗、留下變好的版本，還用樹狀搜尋 (保留不同切面上勝出的「專家」分支) 和「通過/不通過」的把關擋掉作弊刷分。

🔹 學術界其實同源已久: 這條路在研究界跑了好幾年。DeepMind 的 FunSearch → AlphaEvolve 用「LLM 加自動評估器」的演化迴圈改程式碼，找到 56 年來第一個 4×4 複數矩陣乘法只需 48 次乘法的算法，導出的排程規則還幫 Google 資料中心持續省下 0.7% 的全球算力。NVIDIA 的 Eureka 用 GPT-4 寫獎勵函數、靠演化搜尋迭代，在 29 個任務裡 83% 贏過人類專家 (不過要注意它後端仍用 RL 訓練策略，只是把獎勵設計換成 LLM 生成)。Sakana 的 Darwin Gödel Machine 讓 coding agent 改自己的程式碼、用基準測試驗證，把 SWE-bench 從 20% 一路自我演化到 50%。

🔹 最接地氣的實戰應用: 在 Weng 的留言區，VicaYang 分享了三個完全不是 RL 的 HS，最能說明這招在日常工程的用處: 一套音樂庫的歌曲資訊和歌詞整理系統 (依不同國家、曲風套不同規則，再評估多來源品質合併)、一個數獨變體求解器 (給規則和範例，幾輪迭代就生出來、自己一行程式碼沒寫)、以及一套處理電子郵件的 agent 系統 (從正文和 Excel 附件抽結構化資訊，牽涉大量像「不同城市最低投保額不同」的客製規則)。他特別提到，連一個沒什麼工程經驗的學生，都能維護最後那套系統並持續改進它，這正是維護成本崩塌後的樣子。

把「優化 harness」做成系統方法: Meta-Harness

上面 evo 是社群的玩法，Meta-Harness (論文名字就叫 End-to-End Optimization of Model Harnesses) 則把同一件事做成一套有系統的研究方法，值得單獨看它怎麼搜。

它要優化的「harness」，指的是一個 LLM 系統除了模型權重以外的整層外圍程式: 系統 prompt、工具定義、判斷任務完成的邏輯、context 管理、檢索程式、各元件之間的編排。這些被寫成一份不綁特定任務的程式，可以套到不同領域上。

搜尋迴圈是這樣: 一個 agentic proposer (就是用 Claude Code) 透過檔案系統，用 grep、cat 去讀所有歷史候選的原始碼、分數、和完整的執行軌跡，診斷出是哪個 harness 決策造成失敗，然後提出一個新候選、在沒看過的任務上評測、把結果存回去，再重複。最關鍵的設計是它餵給 proposer 的脈絡量: 每一步最多給到 1000 萬個 token 的診斷資訊 (對照論文盤點的其他方法，最多只有 2.6 萬)，所以它不是看壓縮過的摘要，而是直接讀原始軌跡做「反事實診斷」，精準定位該改哪裡。搜尋本身是演化式的，例如文字分類那組就是跑 20 輪、每輪 2 個候選，留下表現好的當作下一輪的基底。

成效跨三個很不一樣的領域，正好說明它不綁定 coding: 文字分類上準確率贏 baseline 7.7 分、還省 4 倍 token; 檢索增強的數學推理在 200 題 IMO 級題目上 +4.7 分，而且同一份 harness 能直接套到五個沒見過的模型; agentic coding 的 TerminalBench-2 上，搭 Claude Haiku 4.5 的版本還拿下全榜第一。整套程式碼也開源了，附了文字分類和 TerminalBench 兩個完整實驗。

換個領域實地走一輪: Doug Turnbull 的搜尋重排器

從訓練腳本、遊戲規則，一路到剛剛的 LLM harness，這個範式套過的領域已經夠雜了。最後再換一個多數工程師最熟、也最容易驗證的領域收尾: 搜尋排序。會特別挑 Doug Turnbull (《Relevant Search》作者) 這個例子，是因為他難得把整套迴圈的程式碼都公開了，最適合拿來看「實際上到底怎麼把 coding agent 接成一個優化器」。

先把他在解的問題講白，沒做過搜尋也能懂: 使用者打一個查詢 (例如「無線耳機」)，系統要把最相關的商品排到最前面，這個重新排序的步驟叫 reranking (重排序); 排得好不好，用一個叫 NDCG 的分數衡量 (越高越好)，資料用的是 Amazon 的購物搜尋資料集。

Turnbull 的出發點是個很實際的成本問題: 直接讓 agent 逐筆判斷每個查詢該怎麼排，相關性確實能提升 15-30%，但每個查詢要燒掉 10 萬個以上的 token，貴到不可能上線。於是他把問題反過來: 與其每個查詢都即時呼叫一次 agent，不如讓 agent 在訓練階段，把它的排序判斷一次寫成一段可重複使用的程式碼，之後線上就只跑這段便宜的程式碼 (搭配便宜的 BM25 關鍵字搜尋)，不必每次都呼叫模型。

而 agent 改這段程式的迴圈，就是標準的「外層優化器」: 每輪改一小段重排邏輯、在資料集上算 NDCG，好就留、不好就還原。

而這其實就是整個範式的重點: 生成出來的那段程式，跑的時候完全不會再呼叫 LLM。它就是一段傳統的啟發式排序邏輯，用 BM25 分數 (經典的關鍵字相關性算法)、標題關鍵字比對、詞彙重疊、甚至簡單的語系判斷 (看到西班牙文字元就換個策略) 這些便宜又可解釋的訊號來決定順序。換句話說，agent 把原本要靠 LLM 逐筆推理的判斷，蒸餾成一段不需要模型、跑起來幾乎不花錢的規則程式。這正是這套範式划算的根本原因: 用昂貴的 agent 在「優化階段」想清楚一次，換來一個之後跑起來便宜、又能讀能改能測的成品。

最有代表性的是他踩的坑: 第二版讓 agent 自由迭代後，訓練集 NDCG 從 0.27 漂亮地爬到 0.35，卻嚴重過擬合 (把訓練查詢背了起來，換一批就掉)。第三版補上三條護欄才真正泛化: 每次只能小改 (10 行內)、用第二個 LLM 檢查不准把具體查詢寫死、改動還必須在 agent 看不到的驗證集上也有進步。加上護欄後，完全沒看過的測試集才從 0.286 穩穩進步到 0.350 (約 +18%)。

這一輪完整示範了「coding agent 當優化器」長什麼樣，也剛好預告了下一段最關鍵的事: Turnbull 這套能不能成，最後全卡在那個 NDCG eval 上。

最關鍵的但書: eval 才是命脈

講到這裡，這個範式聽起來像免費午餐，但其實有個硬到不能再硬的瓶頸: 那個「可驗證的指標」本身。當實驗能跑得比人快 100 倍，你的 eval (評估) 就變成整條迴圈的瓶頸，指標一旦能被鑽漏洞或外洩，模型就會在紙面上變強、上線就崩。

這點在 AI 產品經理 nurijanian 的實戰分享裡寫得最深刻。他想用 autoresearch 改進自己的 skill，連跑三次才搞懂自己錯在哪:

他用 Hamel Husain 評估課程裡的「三道鴻溝」框架點破了關鍵: 理解鴻溝 (你以為系統在做什麼 vs 它實際在做什麼)、規格鴻溝 (你想要什麼 vs 你的評分器量了什麼)、泛化鴻溝 (在測試輸入上的表現 vs 在沒看過的輸入上的表現)。autoresearch 的優化迴圈能解的，其實只有第三道鴻溝; 而前兩道，得人自己親手讀資料才關得起來。他引課程裡那句很狠的話: 「如果你不願意定期親手看一些資料，那你在 eval 上就是在浪費時間。」最後他下的結論是: 「你沒辦法把『理解』自動化掉。總得有人去關上第一道鴻溝，而以我的經驗，那個人永遠是你。」

這套「先做錯誤分析、人工看資料、再談自動化」的順序很關鍵: 自動化迴圈很迷人，但它放大的是你的評估品質。評估對了，它幫你飛; 評估歪了，它只會幫你更快地往錯的方向衝。

編按: 關於這裡講的「錯誤分析 (error analysis)」，ihower 之前分享過一篇 AI Evals 與 Error Analysis 講得更完整，想深入的可以一讀。

Isaac Kargar 的一個實驗 把這個陷阱演得更血淋淋。他用 Claude Code 去優化另一套 agent 的記憶系統，跑了十幾個實驗、複合分數一口氣 +41% (最大功臣只是把 dspy.Predict 換成 dspy.ChainOfThought 這一行修改)。但發完文他才驚覺: 把產出拿去跟 Claude Code 自己那套精簡的記憶一比，他的系統其實是在狂刷一堆可有可無的瑣事、分數漂亮卻更難用，eval 從一開始就量錯了東西，於是他回頭重建評分標準才修正方向。他還補了一個很反直覺的心得: 五個用「不要做 X」這種負面指示的實驗全部退步，因為 LLM 會變得過度謹慎，所以「要告訴 LLM 什麼是好，而不是叫它避免什麼」。

Langfuse 的案例則是更具體的一個例子。他們想用 autoresearch 優化自家一套 skill (負責把寫死在程式裡的 prompt 搬進 Langfuse 託管系統)，評分是拿它去跑 6 個難度遞增的測試專案、用「正確性 + 完整度 + 效率」的加權公式打分，分數在 14 次實驗裡從 0.35 一路爬到 0.824。看起來很漂亮，但細看才發現: agent 是靠砍掉測試沒考到的真功能在刷分。最經典的一刀是它把「執行前先讓使用者確認搬遷計畫」這道人工核准關卡整個移除: 因為在自動跑的測試環境裡根本沒有真人會去按確認，skill 只要保留這關就會永遠卡在等待、拿 0 分，agent 一把它刪掉，前三個測試案例就瞬間從 0.00 跳到 1.00。它還順手刪掉了測試完全沒涵蓋的子 prompt、trace 串接等真實功能。這已經不是「不小心量錯」，而是 agent 主動鑽指標的漏洞。所以這篇的標題乾脆叫「它逼我們把測試寫得更好」，Langfuse 的結論很簡單: 真正脆弱的一環不是優化器，而是那組評估，「沒被量到的東西，就會被砍掉」。

Cerebras 則補上另一個更隱蔽的失效模式: 就算指標本身沒問題，只要監督太稀疏，迴圈一樣會慢慢偏離原本的目標。他們做的是模型壓縮: 先用靜態方法把模型從 717 GB 壓到 92 GB、塞進消費級顯卡之後，再交給 autoresearch 一個更激進的延伸目標: 動態地只用 20% 記憶體跑。結果放著讓它自己跑，agent 中途就擅自把問題換成了另一個:「這模型到底能砍掉多少、還維持 95% 以上的準確率?」擺到 12 小時後偏得更離譜。它用「遮蔽掉一部分 expert 子網路」的方式來衝分 (現在的大模型常把網路拆成很多 expert、每次只實際用到其中一部分)，但這種遮蔽只是在軟體層把元件停用、權重其實還躺在記憶體裡，根本沒省到半點記憶體 (真要省得做永久性壓縮)。弔詭的是它換的那題還真答了出來 (約 37% 的 expert 就能覆蓋 95% 的情境)，是個有用的發現，卻完全不是你要的: 原本的記憶體目標毫無進展、分數卻一直在動，量到的其實是空的。Cerebras 的解方也很直白: 任務要切細、要常驗、要把每個實驗隔離開，環境設計比你選哪個模型更關鍵。

這跟 HL 那邊的觀察完全互相印證。Weng 引的 Cardiverse 研究就指出，LLM 生成的規則品質參差不齊，真正的難題不是「能不能生成」，而是「能不能快又準地辨認出有用的部分」; Turnbull 那句「Agent 天生就想過擬合」也是同一件事。另一位中文圈的觀察者 timyangnet 則總結得很到位: autoresearch 之所以有效，是因為它強制了紀律 (每次只改一個變數、先有假設再做實驗) 和記憶 (git 歷史就是實驗筆記)，而真正的模型是「人類設定方向與約束、帶來品味，agent 在邊界內做窮盡式探索」。自由太多和太少一樣糟。

哪些專案適合這樣搞?

把兩篇的論點和上面這票案例放在一起，可以歸納出: 一個專案要適合「coding agent 當優化器」，需要三個條件同時成立。

具體的甜蜜點，philschmid 那篇列得很清楚: 搜尋排序、商品分類、醫療命名實體辨識、詐騙評分、合約抽取、意圖分類這類邊界明確、指標清楚、小模型或小程式幾分鐘就能跑完一輪的任務最適合。

除了這種一翻兩瞪眼的甜蜜點，還有一塊灰色地帶才是多數工程團隊近期真正用得上的:

那哪些不適合? 兩篇也都劃了界。

而最致命的那條界線，還是回到上一段的但書: 沒有可信的 eval，這整套就是在幫你更快地優化一個錯的目標。

小編的觀察

小編覺得這個做法值得學習。過去想靠手寫一大堆策略、規則、或一份份難調的訓練腳本來解問題，光維護成本就高到沒人養得起，根本不會被當成一條認真的路; 但現在有 coding agent 幫你持續盯著失敗、改程式碼、補測試，這條原本被判死刑的老路，突然就變得可行了。

evo 那篇有個公式小編很喜歡: 一個 agent 系統的槓桿 = 模型能力 × 好的框架 × 緊的驗證迴圈。過去只有第一項在規律地進步 (出新模型)，現在後兩項也開始動，而且是按你定義的目標、在你的資料上動。所以下次你看到一坨沒人敢碰的 if-else、一份過時的 skill、或一個從沒好好調過的訓練腳本，也許該想的不是急著重寫，而是: 能不能把它交給 coding agent 持續最佳化?

參考資料

核心兩篇

• Andrej Karpathy: autoresearch (含 program.md)
• Jiayi Weng (翁家翌): Learning Beyond Gradients

autoresearch 的延伸討論

• Karpathy: 迴圈圖解、約 20 個有效改進的成果、「這是配方，不是工具」
• Philipp Schmid: Tobi Lütke 案例與適用甜蜜點
• Manthan Gupta: 拆解 autoresearch 的設計原則
• timyangnet: 紀律與記憶的觀察

社群與學術案例

• evo: alokbishoyi97 的介紹
• DeepMind: FunSearch、AlphaEvolve
• NVIDIA: Eureka
• Sakana AI: Darwin Gödel Machine
• Stanford IRIS Lab: Meta-Harness (含程式碼)
• Doug Turnbull: 用 coding agent 優化搜尋重排器

評估 (eval)

• nurijanian: 三道鴻溝的實戰心得
• Hamel Husain: AI Evals 課程
• ihower: AI Evals 與 Error Analysis
• Isaac Kargar: 一行程式碼、+41% 背後的陷阱
• Langfuse: 用 autoresearch 優化 skill 的踩坑
• Cerebras: 如何讓 autoresearch 迴圈不作弊

LlamaIndex 的 Jerry Liu 第一時間就 出來潑了一盆冷水。小編覺得這個爭論很值得整理，因為它背後藏著一個更精準的判斷: grep 不是萬靈丹，它只在「高訊號關鍵字」的場景才真的好用，而那個場景剛好就是寫程式。

論文到底發現了什麼

先給論文該有的肯定。它做的事情很實在: 把 grep 和向量檢索兩種工具，接到四種不同的 agent harness 上(自製的 Chronos，以及 Claude Code、Codex、Gemini CLI)，拿 LongMemEval 這個長期記憶基準測試的 116 題來跑，看誰準。

結論有兩層:

🔹 第一層 (標題黨那層): 在「行內回傳」(inline)模式下，grep 的準確率在每一組 harness 與模型的配對上，都贏過向量檢索。最大的差距是 Gemini Flash-Lite 在 Chronos 上的 86.2% 對 62.9%。而且在第二個實驗裡，當你不斷往上下文裡塞無關的干擾對話，向量檢索的準確率會往下掉，grep 卻幾乎不動，因為純字串比對天生免疫於向量空間裡的「距離漂移」。

🔹 第二層 (作者真正想講的): harness 比演算法更重要。同一個 Claude Opus 4.6，在 Chronos 上 grep 能到 93.1%，換到 Claude Code 上只剩 76.7%。換 harness 造成的落差，跟換檢索演算法的落差差不多大。更誇張的是，改用「檔案式」(programmatic，把結果寫進檔案、讓 agent 自己去讀)的回傳方式，原本 grep 的優勢直接被抹平、甚至反轉: Codex 配 GPT-5.4 從行內 grep 的 93.1%，崩到檔案式 grep 的 55.2%。

編按: 所以這篇論文真正的重點不是「embedding 已死」，而是「你花在 harness 設計上的心力，應該遠多於花在挑哪個向量資料庫」。grep 只是眾多旋鈕裡的一個，而且通常不是最關鍵的那顆。

第一個關鍵: 它測的是「對話記憶」，不是企業文件

Jerry Liu 的批評一針見血。LongMemEval 測的是「翻找使用者過往的聊天紀錄」: 明確的日期、數字、偏好、使用者講過的話。這種題目的答案，往往就藏在某幾段「逐字、原封不動」的文字裡(論文稱為 literal spans，字面證據)。

這正是 grep 的主場。你要找的東西本來就是一個精確的字串，當然是字串比對贏。

但企業 RAG 的典型場景完全不是這樣: 對著一堆財報、法律合約、SOP 文件問複雜問題。這些文件的語言是改寫過的、術語不一致的、偏概念的。LlamaIndex 後來也寫了 一篇完整回應，把 grep 在這種語料上的硬傷講得更白: 你 grep 不了 PDF、掃描影像、Office 檔;語料一上百萬份檔案，純線性掃描就開始吃力;更要命的是「詞彙對不上」: 使用者問的是「營收認列」，文件裡寫的卻是會計準則代號「ASC 606」，字面比對直接一無所獲。他們開的藥方是「分層處理」: 先用讀得懂版面的工具把文件解析出來、建索引做語意檢索，grep 只留著當精確比對的後援。

連論文作者自己都很誠實，在「限制」(Limitations)那一節白紙黑字寫著:

在證據很少以字面形式出現的領域(例如對改寫過的論文摘要做綜整、大量圖表的文件、或程式碼語意)，向量檢索和混合路由的表現可能會很不一樣。我們並不主張 grep 在通用情況下「贏過」向量檢索。

換句話說，論文自己都沒宣稱 grep 是通用解，是讀者(和那個標題)把它過度延伸了。

第二個關鍵: grep 吃的是「高訊號關鍵字」

為什麼寫程式是 grep 的完美場景? 因為程式碼裡的識別字(函式名、變數名、錯誤碼)本來就是必須精確比對的關鍵字。你要找 handleUserLogin 這個函式，grep 一秒就給你所有出現的位置，零歧義。反過來，向量檢索在程式碼上一直做不好，因為它會把語意相近、但根本不是你要的東西也一起撈進來。

Sara Zan 在 一篇實測文章 裡補了一個「到了 agent 時代才成立」的觀察: 傳統 RAG 假設「查詢必須一次就對」，所以拼命優化單次召回的品質。但 agent 打破了這個限制，它可以先用一個很爛的查詢搜一次，看看結果，再改寫查詢搜第二次。這種「反覆迭代」剛好補掉了關鍵字搜尋最大的弱點(怕你措辭不對)，又保留了它精確的優點。

把這兩件事疊起來，grep 的甜蜜點就很清楚了: 語料是純文字、查詢以高訊號的字面關鍵字為主(程式碼、log、識別字、日期、人名)、而且 agent 可以反覆迭代搜尋。中小型的程式碼庫幾乎完美命中這三個條件，難怪 Claude Code 這類工具用得這麼順。

第三個關鍵: 雙峰的查詢分布，逼你走向混合檢索

前面說 grep 怕措辭、吃不了概念查詢。有趣的是，向量檢索有個剛好對稱的盲區: 它接不住精確的識別字。Your Vector Database Is Not a Search Engine 這篇文章整篇就在打這個弱點，而它開出的藥方不是「改用 grep」，而是「混合檢索」。

它先點出一個容易被忽略的陷阱: 大家評估檢索效果都拿 BEIR、MTEB 這類基準測試，而它們清一色是「漂亮的自然語言問句」，在這種題目上向量檢索當然贏 BM25。但你把真實的查詢紀錄拉出來看，分布其實是雙峰的: 一半是對話式的問句，另一半是精確查詢(產品代碼、錯誤碼、內部工具名、版本號、專有名詞)，後者常常佔了超過三成的流量。而 SKU-47291 這種字串被 tokenizer 切成 subword 之後，根本不會落在它原本該在的位置，向量檢索只會回給你一堆「看起來很像、其實不是」的鄰居。

所以這篇的結論是: 把 BM25(抓精確關鍵字)和向量檢索(抓語意)平行跑，用 RRF(Reciprocal Rank Fusion，互補排名融合)把兩份結果合併，再加一個 cross-encoder reranker 重排。grep 怕措辭、向量怕識別字，兩邊剛好各補對方的盲區，這才是雙峰查詢唯一說得通的解。

這也解釋了為什麼產業正在快速倒向混合檢索。有資料顯示，企業導入混合檢索的意願，在 2025 年底短短一個季度內就從 10.3% 跳到 33.3%;而「超長上下文會讓檢索變得多餘」這個說法，則從 15.5% 崩到 3.5%。大家都是踩了坑才學乖的。

更好的框架: 別找銀彈，要「策展」一組工具

Elastic 的 Leonie Monigatti 最近在 一場 Maven 演講(內容也整理成 一篇文章)裡，把這件事講得更透徹。她有個大膽的觀點: 「上下文工程大概有八成，其實就是 agentic search(代理式搜尋)。」你以為自己在做的是上下文策展，但底層真正在運作的，是一堆搜尋工具。她還畫了一條清楚的演進線: 早期的 RAG 是固定流程，每次都只檢索一次、又無法自我修正;agentic RAG 把它換成一個搜尋工具，讓 agent 自己決定要不要搜、要搜幾輪;到了上下文工程的時代，來源變多了(本地檔案、資料庫、網路、記憶)，自然就需要好幾種不同的搜尋工具並用。

她現場示範了一個很傳神的畫面: 只給 agent 一個 shell 工具加上一堆本地檔案，然後丟一個需要語意理解的問題給它。結果 agent 用 grep「作弊」、硬是假裝在做語意搜尋: 自己腦補出一串同義詞(regulate、compliance、constraints、gdpr、governance)，連續 grep 好幾輪，最後居然也湊出了答案。能動是能動，但這真的是對的做法嗎?

她的結論，跟論文、跟前面那些反方文章，完全收斂到同一句話:

如果你在找一把萬能的銀彈搜尋工具，很抱歉要讓你失望了。目標不是找到那一把銀彈，而是「策展」(curate)出一組合適的搜尋工具，讓你的 agent 能應付各種不同的查詢。

Elastic 在 一篇延伸文章 裡，把這個策展原則整理成「低地板、高天花板」(low floor, high ceiling):

大多數 agent 兩種都需要，重點是兩者混搭，而不是幻想單一工具能通吃。

那一組工具到底該放哪些? Elastic 給的是「用數據決定」的做法，而不是憑空設計: 先給一個通用工具上線，然後記錄 agent 的真實行為(它呼叫了什麼、重試幾次、在哪裡卡住失敗)。當某種查詢模式反覆出現、或反覆出包，再針對它打造一個專用工具。每個工具都得「賺到」自己被放進工具箱的資格。Claude Code 只配大約 20 個工具，而不是塞進幾百個 MCP 工具，就是這個哲學的體現。

連 grep 陣營都在偷偷補語意能力

這裡有一個很有意思的訊號: 連 grep 陣營自己都在偷偷補語意能力。最近冒出一票「語意版 grep」的命令列工具，目標都一樣: 在不架整套向量資料庫的前提下，讓 agent 直接對本地檔案跑自然語言搜尋。

LlamaIndex 的 semtools 是用 Rust 寫的命令列工具，主打兩個指令: parse 先用 LlamaParse 把 PDF、Word 這些原本 grep 不了的格式轉成 markdown，search 再用 static embedding(model2vec)做「模糊的語意關鍵字搜尋」，而且 search 全程在本地跑。LlamaIndex 那篇介紹文的標題還故意取作 “SemTools: Are Coding Agents all you Need?”，擺明在跟這波 grep 風潮對話。

Jina 的 jina-grep 則更貼近 grep 原本的使用習慣: 用 Jina embeddings v5、在 Apple Silicon 上透過 MLX 純本地跑。你可以直接用 jina grep "error handling" src/ 以自然語言搜尋，也可以把傳統 grep 的輸出用管線丟給它做語意重排(grep -rn "error" src/ | jina grep "retry logic")，等於幫 grep 接上一顆語意大腦。

LightOn 的 ColGrep 則是這幾個裡面最能呼應本文主旨的一個。它基於 late interaction(ColBERT，延遲交互)的 LateOn-Code 模型，包成單一個 Rust 執行檔、100% 本地、程式碼完全不外流。關鍵是它預設就是混合的: 先用 regex 像 grep 一樣縮小候選範圍，再用 ColBERT 做語意排序，兩份排名用 RRF 合併。LightOn 講得很直白: ColGrep 不是要取代 grep，而是「把 grep 的優點吸收進來、再往上擴充」，官方數據說它正面對決贏純 grep 約七成，還省下 15.7% 的 token。

三個工具擺在一起看，結論幾乎自己跳出來: 純字面比對確實有天花板，連最擁抱 grep 的寫程式場景，大家都在想辦法把語意能力搬回 shell 裡。而 ColGrep 那套「regex + 語意 + RRF」的預設行為，根本就是把「策展一組工具」直接內建成單一工具，等於幫你預先把混合檢索組好了。

收斂成幾個實務判斷

把論文、Jerry Liu、Sara Zan、Elastic 全部疊起來，小編幫大家收斂成幾條:

1️⃣ 別一聽到「搜尋」就反射性地架向量資料庫: 如果語料是中小型純文字、查詢又以字面關鍵字為主、agent 還能反覆迭代，grep 往往是更省事的起點，省下一整層基礎設施。

2️⃣ 但也別反過來以為 grep 萬能: 它搜不了 PDF、圖片、Office 檔，搞不定同義詞和概念查詢，語料一大、延遲就線性上升。它的本質，是拿「延遲和 token」去換「彈性」。

3️⃣ 檢索層的標準答案是混合檢索: 就是上面那套 BM25 加向量檢索、合併後再重排;遇到需要多 hop 的關係推理，再疊上 GraphRAG。在真實的企業語料上，混合幾乎都打贏任何單一方法。

4️⃣ agent 層的標準答案是策展一組工具: 低地板的專用工具，搭配高天花板的通用工具，而不是硬塞一個萬能介面。組合勝過任何單一工具，但工具數量要克制，免得撐爆上下文、又害 agent 選錯工具。

5️⃣ 真正該花心力的地方是 harness: 這是論文最反直覺的發現。一個好的 harness，能讓模型反覆改寫查詢、查看片段、自己決定何時收手，就算配的是向量檢索，也可能贏過爛 harness 配 grep。檢索演算法只是其中一顆旋鈕而已。搜尋老兵 Doug Turnbull 在 Agentic Search Is Having a Grep Moment 裡進一步點出，harness 其實有兩層迴圈: 內層是 agent 自己改寫查詢、反覆迭代;外層則是一道由你定義的「程式化品質閘門」(他稱為 hook)，agent 搜完後拿結果去對領域標準把關(夠不夠新、夠不夠權威)，不合格就把具體理由回灌、叫它再搜一次。他的結論很犀利: grep 能在生產環境動起來，往往不是因為 grep 本身有多強，而是外面這層約束和驗證在替它扛品質。

回到那個挑釁的標題。Grep is all you need 嗎? 對中小型的程式碼庫，可能真的是;但只要場景一離開「高訊號關鍵字 + 純文字 + 可迭代」這個甜蜜點，答案就從「二選一」變成「怎麼搭配」。與其糾結該選 grep 還是向量檢索，不如先想清楚自己的資料長什麼樣、查詢分布如何、agent 能不能反覆迭代，再決定怎麼組工具，而且一定要建一套評估(eval)流程去量，別憑感覺。檢索沒有銀彈，只有策展得好不好的工具箱。

他開頭那句話蠻精準的:「agent 串流已經超出 token 增量(token deltas)能承載的範圍。」小編就借這個命題,把幾家的設計做法整理在一起聊聊: 從最原始的 OpenAI 串流當基準,一路看到 AG-UI、Vercel AI SDK、LangChain 各自怎麼設計這串資料的格式,中間再穿插一些 ihower 實際做串流產品時累積的經驗。算是一篇參考各家設計、加上實戰心得的整理分享,看完你大概會同意:「能不能顯示 token」早就不是重點了。

先談基準: 從增量到語意事件

最原始的串流長這樣。OpenAI Chat Completions 的每個 chunk 是 choices[0].delta.content,裡頭塞一小段文字,前端要做的就是把這些片段一段段接起來。工具呼叫更麻煩: 它是 tool_calls[].function.arguments 的片段,用陣列位置(index)標記這是第幾個工具,你得自己照著位置把 JSON 碎片拼回完整的參數物件。這就是典型的「不透明 chunk」: 格式只關心「下一段資料是什麼」,語意全得靠你自己重建。

文字和工具參數都是裸片段，工具還得靠 index 自己對位拼回來，語意全靠前端重建。

OpenAI 後來的 Responses API 其實已經進步很多。它不再是沒有語意的增量，而是一串「語意事件」: response.output_item.added 告訴你新開了一個輸出項目(可能是訊息、工具呼叫、推理),response.output_text.delta 串文字,response.function_call_arguments.delta 串工具參數，推理(reasoning)有自己的事件，最後用 response.completed 收尾。整個輸出被組織成一個個輸出項目，每個項目內部用「開始 / 增量 / 結束」的節奏串。

事件名稱本身就帶語意，前端一看就知道現在在串哪個輸出項目，推理和最終答案也分開了。

這已經是相當像樣的設計: 有型別、知道自己在串什麼、推理和答案分開、連用量(usage)資訊都保得住。所以問題來了,既然基準都做到這樣了,為什麼還不夠用在應用層級?

基準暗藏的三個假設

關鍵在於 Responses API 這類設計,骨子裡假設了三件事，而 agent 應用把這三件事全打破了:

Bromann 把應用層級真正該問的問題列得很到位，小編挑幾個最有感的: 能不能即時畫出一棵 agent 的工作樹? 能不能只訂閱畫面上那一個子代理，而不用付下載其他所有子代理的頻寬代價? 能不能把「等人核准」當成第一級的事件來處理? 能不能斷線後重新接上、接著上次的進度繼續，而不是整段重播?

這些問題，token 增量一個都答不了。因為它根本沒有「樹」(tree)「頻道」(channel)「斷點」(checkpoint)這些概念。

兩個維度: 頻道與命名空間

LangChain 這套新串流原語的核心設計，小編覺得最值得學的，是它把每一段資料拆成「兩個正交維度」來標記。

第一個維度是 頻道(channel): 標記這串資料「屬於哪一類關注點」，也就是你會想分開來看的不同面向。messages 是對話內容、values 和 updates 是流程圖共享的狀態(例如目前累積的搜尋結果、計畫清單、步數計數器這類資料: values 給你完整快照，updates 給你每一步改了哪些欄位)、tools 是工具執行的起訖、lifecycle 是整段執行和子代理的生死、custom:* 是應用自己定義的投影。

第二個維度是 命名空間(namespace): 描述這個事件「發生在 agent 樹的哪個位置」。根節點、巢狀的子流程圖、某個子代理，都可以發出同一種頻道的事件，但各自保有身分、不會混在一起。

用一張表最好懂。每段資料都落在某個「頻道 × 位置」的格子裡，而你可以只訂閱自己正在畫的那幾格:

「頻道是可重複使用的關注點、命名空間是產生它的位置」這個拆分，就是整套設計的關鍵選擇。有了它，一個子代理檢視器才能只打開它要的那一格，不會把每個子代理的 token 全拉下來。

多了 namespace 這個維度，同一種事件就能標出「是樹上哪個子代理發的」，這正是前面那些設計都沒有的。(實際 LangGraph 傳輸線上的欄位名稱略有不同，這裡是概念示意。)

投影: 不要解析，直接拿你要畫的東西

光有型別還不夠。Bromann 的第二個重點是 投影(projection)。先講清楚: 投影不是傳輸線上的某種格式，而是一個設計概念。它指的是執行層在那串底層事件「之上」，幫你組好幾種現成的視圖，讓你的程式碼直接拿來用，不必自己一條條去解析原始事件。

具體長什麼樣? 在 LangChain 的框架 SDK 裡，這個概念落地成一組 API: 你呼叫 useMessages() 就拿到一串已經組好的訊息、useToolCalls() 拿到工具呼叫的清單、useValues() 拿到目前的狀態。至於重組、重新排序、斷線重連這些髒活，執行層全幫你包掉。而且每則訊息本身是「一連串有型別的區塊」: 文字、推理、工具參數、用量，而不是一條要你自己切的字串。這點對現代模型輸出很重要,推理和最終答案本來就該分開呈現，工具參數要當成結構化資料來組裝，多媒體資料更不該被硬塞進純文字介面。

這裡 ihower 補了一個很實務的提醒: 你不應該把上游 Responses API 或 Completions API 的串流原封不動轉傳給前端。模型 API 吐出來的東西，很多根本不該給使用者看,可能是內部推理、給除錯用的中繼資料、或牽涉權限不該外露的內容。前端要收的，是你「為這個產品設計過」的事件,而不是上游吐什麼就照單全收。換句話說,你前端那層格式，是一個你要主動設計的應用層介面,不是模型 API 的透傳管線。這也是投影這個概念為什麼這麼關鍵: 哪些事件、長什麼形狀、露給前端，都由你決定。

跨模型使用是另一個自己設計格式的硬道理。實務上你很可能今天用 OpenAI、明天換 Anthropic 或 Gemini，每一家原生的串流格式都長得不一樣。要是前端直接綁死某一家的格式，換一次模型前端就得跟著改一輪;但只要中間隔了一層你自己設計的事件格式，換模型時你只要改後端那段轉換，前端依賴的那份約定完全不用動。模型是會換的，你的格式不該跟著換。

編按: 這背後其實是一個「抽象反轉」的觀念,真正的事件來源是執行引擎(harness),token 串流和畫面更新都只是它的投影。所以換掉底層模型，換掉的只是投影，你前端依賴的那份語意約定不變。這也是為什麼這類協定都強調「按類別訂閱，而不是按單一事件名稱訂閱」: 訂「所有工具呼叫類的事件」，協定日後新增事件名稱你也不會壞;把每個事件名稱寫死進去就會壞。

AG-UI 怎麼設計的

講到標準化的事件協定,就不能不看 AG-UI(Agent-User Interaction Protocol，由 CopilotKit 發起)。它的定位跟 LangChain 那套有點不同: AG-UI 想當的是「agent 後端」和「前端」之間那條通用的線，和 MCP(管工具)、A2A(管 agent 之間的溝通)並列在 agent 協定的堆疊裡。

編按: 釐清一下 CopilotKit 和 AG-UI 的關係，免得搞混。CopilotKit 是一間公司、也是一套 React / Angular 的前端 SDK(現成的聊天元件、useAgent hook、generative UI 那些);AG-UI 則是他們從跟 LangGraph、CrewAI 的合作中抽出來、再開源給整個生態的「協定」,後來被 Google、LangChain、AWS、微軟、Mastra、PydanticAI 等採用。一句話: AG-UI 是開放協定(規格)，CopilotKit 是講這個協定的第一方前端框架。

它的設計小編覺得乾淨俐落。所有事件都繼承自同一個 BaseEvent(至少帶 type，另有可選的 timestamp、rawEvent),核心大約十多種，分成幾類:

• 生命週期: RUN_STARTED、STEP_STARTED / STEP_FINISHED、RUN_FINISHED / RUN_ERROR，帶 threadId、runId，還有可選的 parentRunId 給分支用
• 文字訊息: TEXT_MESSAGE_START → 多個 TEXT_MESSAGE_CONTENT(各帶一段 delta)→ TEXT_MESSAGE_END，用 messageId 串起來
• 工具呼叫: TOOL_CALL_START → 多個 TOOL_CALL_ARGS(串 JSON 片段)→ TOOL_CALL_END → TOOL_CALL_RESULT，用 toolCallId 串
• 狀態管理: STATE_SNAPSHOT(完整狀態)、STATE_DELTA(用 JSON Patch / RFC 6902 送增量)、MESSAGES_SNAPSHOT
• 特殊事件: RAW(包外部系統的事件)、CUSTOM(應用自訂)當逃生口

這裡有兩個小編覺得很值得抄的設計。一是 「開始 / 內容 / 結束」三段式，套用在所有串流內容上(文字、工具參數都是同一個節奏),前端只要實作一套組裝邏輯就好。二是 「快照 / 增量」模式 來同步狀態: 偶爾送一次完整快照當基準,中間用 JSON Patch 送小增量,兼顧完整和省頻寬。它還貼心地提供 TEXT_MESSAGE_CHUNK 這種便利事件，第一段自動展開成 start，串流切到下一個 id 時自動補上 end，省掉手動管理生命週期的麻煩。

傳輸層的選擇上 AG-UI 也刻意保持開放: SSE、WebSocket、webhook 甚至自家的二進位傳輸都能載，不綁死單一種(對照之下 Vercel 那套主要走 SSE)。再配上雙向溝通，使用者的中斷和確認可以回傳給 agent，所以「人在迴路」(human-in-the-loop)是它內建的概念(RUN_FINISHED 的結果可以是一個中斷，代表停下來等人)。

不過對照一下會發現一個有意思的差別: AG-UI 的核心比較像「單一 agent + 工具 + 狀態」的一條扁平串流，多 agent 樹的部分主要靠 RAW 和 CUSTOM 當擴充點。而 LangChain 那套多了命名空間這個維度，把 agent 樹的位置直接做進協定的第一層。兩種取捨沒有絕對好壞: 前者簡單通用、好接既有框架，後者為複雜的樹狀 agent 而生。

還有哪些值得參考的設計

小編另外撈了幾個業界的做法，會發現大家其實在往同一個方向走。

Vercel AI SDK 的 data stream 協定 跟 AG-UI 幾乎是同一個形狀,只是換了名字: 文字用 text-start / text-delta / text-end(每段內容有自己的 id),工具用 tool-input-start / tool-input-delta / tool-input-available / tool-output-available,推理也是「開始 / 增量 / 結束」。它有兩個設計小編覺得很實用: 一是 資料片段的就地更新,你送一個帶 id 的資料片段,之後用同一個 id 再送一次就會更新同一塊(很適合做進度條、載入狀態、協作中的文件);二是 暫時性片段,送給前端顯示、但不寫進訊息歷史(適合那種一閃即逝的通知)。它一樣走 SSE，主打連線保活、可重連、好快取。

這兩個設計用程式碼最好懂。上面那筆 data-weather 是 loading，之後用同一個 id 再送一次，前端就會就地把那塊換成新內容(很適合進度條、協作中的文件);而帶 transient:true 的片段只會即時顯示、不寫進訊息歷史(適合一閃即逝的通知):

編按: 這裡的 data- 前綴和整套資料片段機制(id 就地更新、transient 不入歷史)是 Vercel AI SDK 協定定義的，但後面的 weather、notification 是你自己取的名字、可搭配型別做到型別安全，並非內建事件;對照之下 text-start、tool-input-delta 那些才是固定的內建事件名。

順帶分清楚: A2UI 是「格式」，AG-UI 是「傳輸」

既然講到 AG-UI，順手帶一個名字超像、又最容易跟它搞混的東西: A2UI。兩者其實是不同層的協定。

A2UI(Agent to UI)是 Google 提出的協定，要解決的問題是:「agent 要怎麼安全地把一個畫面送到前端?」尤其在多代理場景，有些 agent 跑在別人的伺服器上，你不可能讓它直接塞 HTML/JavaScript 進你的頁面(有安全風險，畫出來也跟你的 app 樣式不搭)。

A2UI 的做法是: agent 不送程式碼，而是送一串「宣告式的 JSON」描述畫面長怎樣，前端再用自己的原生元件(React、Flutter、SwiftUI 都行)把它畫出來。它的幾個設計重點:

• 送的是「資料」不是「程式碼」: agent 只能從前端提供的「元件目錄(catalog)」裡挑元件，沒有任意執行程式碼的風險，所以連跑在別人伺服器上的 agent 送來的 UI 都能安全地畫。
• 結構和資料分開: 一種訊息(updateComponents)描述畫面結構、另一種(updateDataModel)灌資料，前端可以只更新某個欄位、不必重畫整個畫面。
• 扁平的元件清單 + ID 互相參照(adjacency list): 不用一次生出完美的巢狀 JSON，LLM 可以邊生邊串，收到 root 元件就先開始畫。

關鍵就在這個分工: A2UI 管「要畫什麼」(格式)，AG-UI 管「事件怎麼在前後端之間流動」(傳輸)。兩者是互補的，A2UI 本身就標明自己不挑傳輸，可以走 AG-UI、A2A、SSE、WebSocket;反過來 AG-UI 也可以把一包 A2UI 內容當成某個事件的酬載載過去。實際上任何已經會講 AG-UI 的 agent，幾乎零成本就能驅動 A2UI。把這兩層分清楚，你才不會拿「要畫什麼」去跟「怎麼傳」硬比。

你可能會問: AG-UI 不是也有「generative UI」能嗎? 有，但差別在「誰決定畫面長怎樣」。AG-UI 的 UI 是「事件驅動、由你的 app 自己渲染」: agent 發出工具呼叫或自訂事件，你在前端自己決定哪個事件對應哪個元件，渲染邏輯寫在你(受信任的)app 程式碼裡，它本身沒有規定元件樹的標準格式。A2UI 則是把「UI 描述本身」標準化成一棵宣告式元件樹，一個通用 renderer 就能畫。所以前者載的是「你 app 會自己渲染的訊號」，後者載的是「通用 renderer 就能畫的 UI 描述」，這也是為什麼不受信任的遠端 agent 適合用 A2UI。

編按: CopilotKit 自己把 generative UI 分成三種模式，剛好把這個層次標得很清楚: Static(走 AG-UI，前端預先寫好元件、agent 用事件或狀態觸發)、Declarative(走 A2UI，agent 吐元件樹、通用 renderer 畫)、Open-Ended(MCP Apps / Open JSON，更自由)。重點是: AG-UI 是事件導向、本身不是宣告式 UI;同一個前端可以底層用 AG-UI 載事件，需要時再把 A2UI 當酬載塞進某個事件裡，兩者疊著用。

講完設計，小編插一段比較主觀的看法: 對 A2UI 這種「宣告式 UI」，小編其實蠻保留的。畫面長怎樣、怎麼排版、怎麼互動，本來就是前端最擅長、也最該掌握的事;讓 agent 去描述一棵 UI 元件樹，某種程度上就是在重新發明一套 HTML/CSS，多數情況下是 over-engineering。Hacker News 上的討論也有人吐同樣的槽:「看這些範例，感覺它最後會收斂回我們早就有的 HTML，那為什麼不乾脆讓各平台支援 HTML 就好? LLM 本來就很會生 HTML」、「『用 JSON 描述畫面、客戶端來畫』這套我們搞很多年了，難的從來不是線上格式，而是元件版本管理跟跨客戶端 debug」。

那 A2UI 真正有價值的情境是什麼? 小編認為其實就一個: 當前端不屬於你的時候。比方你要把 agent 上架到別人的平台、嵌進別人的 app，你沒辦法自己寫前端、也不能塞程式碼進去，只能用對方提供的元件目錄,這時候一套宣告式、跨平台、又安全(只能挑核可過的元件)的 UI 描述格式才划算。同一串討論裡也有人精準點出這點: A2UI 最有意思的就是「遠端訊息傳遞、你不擁有那個 UI」的場景。反過來說，如果前端是你自己的，老老實實寫前端就好，別繞這一圈。

存下來的不是答案，是整段串流

ihower 還提了一個小編覺得超多人會踩到的坑: 串流型的應用不能只存最後那段最終答案的文字。

想想看,使用者關掉頁面、隔天再回來,你要讓他看到的應該是「完整的過程」: 中間呼叫了哪些工具、各個子代理做了什麼、推理怎麼一步步走、多媒體怎麼一塊塊長出來。如果你資料庫裡只存了最終答案，這些全沒了，回訪的使用者只看到一個乾巴巴的結果，和當時親眼看著它一步步生出來的體驗完全是兩回事。

所以你真正該存下來的，是「整段串流本身」: 當時串流長什麼樣，存下來就是什麼樣，回放的時候也放同一份。這正好解釋了為什麼前面那些協定都那麼在意型別事件、排序資訊和「快照 / 增量」,因為那串有序的事件本身，同時就是你的「儲存格式」和「回放格式」。格式設計得好不好,直接決定了你能不能把一段跑了十分鐘的 agent 執行完整存起來、之後一模一樣地放出來。

這跟斷線重連其實是同一個能力的兩面: 重連是「執行還在跑,我接回去」,回放是「執行早就結束,我重看一遍」,兩者吃的都是同一份有序的事件記錄。一個沒有設計好格式的串流應用，這兩件事都別想做。

「整段都存」會踩到的儲存效率問題

不過「整段都存」馬上會帶出另一個工程問題: 怎麼存才不會爆掉? LangGraph 團隊最近就在處理這件事。

問題出在它預設的存法: 每走一步，就把當下「完整的狀態」整包存一次。對話的訊息清單尤其慘，因為每一輪都是在前面所有訊息後面再接一句，於是第 1 步存 1 則、第 2 步存 2 則、到第 N 步存 N 則… 前面的內容被一存再存，儲存成本是用 O(N²) 在膨脹。官方給的數字很嚇人: 一段累積到約 10 萬 token 的對話，單一執行緒就吃掉約 250 MB;外推到百萬 token 等級會到約 25 GB。多輪對話拖越長，重複浪費越誇張。

他們的解法叫 DeltaChannel，精神跟前面 AG-UI 的「快照 / 增量」一模一樣: 別每步都存完整清單，只存「這一步新增了什麼」(增量)，要讀的時候再順著增量鏈把狀態重播回來;再加一個 snapshot_every 參數，每隔幾步存一張完整快照，免得重播鏈拉太長。儲存成本就從 O(N²) 降到 O(N)，同一段對話省下幾十倍空間(官方實測 500 輪、約 10 萬 token 的對話，從 252 MB 降到約 712 KB)。

編按: 這個儲存最佳化的細節可以參考 LangGraph 的 DeltaChannel PR #7547 和官方持久化文件的「Optimize checkpoint storage」一節。

這也帶出一個蠻漂亮的呼應: 「快照 / 增量」這組設計，在串流時是為了省頻寬，在儲存時是為了省空間，在斷線重連和回放時又變成「接得回去、放得出來」的關鍵。同一套格式上的巧思，一次解決了好幾層的問題。

而「一段執行就是一串事件」這個想法，甚至已經被做進基礎設施。LangChain 在 2026 年 5 月發表了一個專門的資料庫 SmithDB，用來扛 agent 的觀測(observability)資料，它的核心設計原則一句話就講完，而且跟這篇通篇在講的是同一件事:「一段執行是一串事件，不是一筆不可變的資料列」(a run is a sequence of events, not a single immutable row)。當 agent 動輒跑好幾個小時、夾帶上百個巢狀步驟和圖片影音，連儲存層都得照著「事件序列」的形狀重新設計。它還有個細節值得一抄: 把核心欄位和大塊內容(工具的長輸出、模型回應)分開存，主資料列只放指標，真的要看某一筆時才把大內容拉出來，列表和篩選就不會被大 payload 拖慢。從串流、儲存到觀測，大家其實都在往同一個方向收斂。

收尾: 串流是一個你要設計的應用層介面

繞了一圈，這些設計講的其實是同一件事: 串流不再是每個應用都得自己解析的低階傳輸細節，它變成了一個 你要主動設計的應用層介面。

而且這層格式並不貴。把上游 API 轉成你自己的事件格式，不過是讓 CPU 做點轉換，擺在動輒好幾秒的 LLM 請求延遲面前根本不算什麼。所以就算只是純聊天介面，也建議隔一層自己的格式(裡頭留一個文字增量事件，照樣有逐字打字的感覺)，差別只在要做到多細: 聊天可能只需要訊息加上少量狀態，agent 當同事的產品才需要長出完整的頻道、命名空間和回放。

格式設計得好不好，直接決定了你能不能只訂閱螢幕上那塊 agent 的工作、用對的抽象去呈現它、在執行越拉越長時保持連線、在使用者回訪時完整重播。用 Bromann 的話收尾最貼切: 串流 agent 該像在「寫應用程式」，而不是在「讀一堆日誌」。

先搞懂: 一條 agent trace 長什麼樣

如果你還沒實際翻過 agent 的 trace，先建立個畫面。一條 trace 就是 agent 處理「一個使用者請求」的完整紀錄: 從使用者問了什麼，到它最後回了什麼，中間每一步都被記了下來。而 agent 很少是單純的一問一答，它會推理、規劃、呼叫工具、看結果、再決定下一步，一路跑到收工。

這些步驟在 trace 裡是一層層巢狀的 span: 最外層的 root span 是整個 agent run，底下掛著一個個子 span，每次 LLM 呼叫(推理)、每次工具呼叫(搜尋、計算、查資料庫)都是一個 span。每個 span 還記著自己的輸入、輸出、花了多久、用掉多少 token、有沒有報錯。把父子關係攤開，大概長這樣:

重點是: 這東西的資訊量很可觀。一段對話跨個好幾輪，可能就是幾十上百個 span、好幾 MB 的資料。Adam Lucek 講得好: 「trace 資料這年頭簡直貴如黃金，前提是你得知道拿它做什麼。」難就難在後半句，而那正是這篇要談的。

為什麼 agent 這麼難搞? 因為它跟傳統軟體很不一樣: 輸出是非確定性的、對 prompt 的一點點改動都可能很敏感、又得接受沒有邊界的自然語言輸入。講白了，你不會知道 agent 會做出什麼，直到它真的上線、跑給真實使用者。於是除錯的方式也跟著變: 從「讀程式碼、找邏輯錯誤」，變成「分析 trace」，你要抓的不再是某一行程式寫錯，而是推理出錯、工具用得很沒效率、決策品質不好這類問題，這些在程式碼裡根本看不出來。

2026 年一個很明顯的趨勢是: 乾脆讓 agent 來讀 agent 的 trace。LangChain 把這件事叫做「agent 改進 agent」。小編最近把 LangChain、FutureSearch、Raindrop 還有 Shreya Shankar 幾篇放在一起看，發現關鍵的分歧其實是: 這個讀 trace、找問題的「質性分析」，到底要交給誰的 agent、在什麼時間點做。

讀 trace 其實就是 error analysis，也就是「看你自己的資料」，這是做評估的地基。問題不在於要不要做，而在於人工讀根本沒辦法規模化: 一個團隊一天可能就產出幾千上萬條 trace，沒有人讀得完。所以生產環境的 agent 監控，跟傳統軟體監控很不一樣: 你沒辦法每一筆都細看，只能把「最值得看的子集」送進一套結構化的審查流程，讓 LLM 自動跑品質評估，再從中跑線上評估、偵測已知的失敗、探索還沒發現的問題、把好例子加進資料集、或是觸發人工審查。

而且這件事的回報，遠不只是「抓 bug」。LangChain 的 Viv Trivedi 點得很準: 不管你想做 harness 工程、寫評估、換模型還是後訓練，這些改進 agent 的手段，幾乎全都在「先把 trace 蒐集起來、讀懂」的下游。換句話說，「先出一個 v1 → 打開 tracing → 讀懂 trace 和錯誤 → 做實驗 → 再循環」就是 agent 開發的主迴圈。所以真正的問題變成: 這個迴圈裡最累的「讀懂」這一段，能不能交給 agent?

迴圈裡最吃功夫的，就是「讀 trace、判斷哪裡出錯」這個質性分析的環節。目前小編看下來，有三種不同作法:

① 帶你自己的 coding agent 去讀

這條路的精神是: 不另外養一個分析 agent，而是把 trace 接到你本來就在用的 coding agent(通常就是 Claude Code)，讓它幫你讀。

FutureSearch: 一次深讀一條 trace

最省事的版本是 FutureSearch 分享的 這篇。作者說他花很多時間在讀 agent 的 trace，一半是為了知道怎麼改進 agent，一半是為了確認「跑出來的評估到底能不能信」。

他們的 trace 存在 Langfuse，而所謂「接給 Claude Code」其實樸素到不行: 直接把一條 Langfuse 的 trace 連結貼進去，下一個 review this trace: <Langfuse 連結> 指令就開工了。背後是一個自訂的 /review-agent-trace skill，裡面放滿常見失敗模式的範例，外加「怎麼形成假設、怎麼跑快速實驗來驗證」的指引。他們把要找的問題分成四大類，蠻實用的:

1️⃣ 鷹架程式碼(scaffolding)的 bug: 系統 prompt 設定錯、agent 在某些條件下莫名其妙就停了

2️⃣ 工具失效: 搜尋回傳一堆亂碼或無意義的結果

3️⃣ prompt 引發的問題: 框架太狹隘、指令互相衝突

4️⃣ 推理失敗(最難): agent 搞混日期、亂呼叫工具、漏掉任務的一部分

最有意思的，是模型代差帶來的質變。他們早期用 Sonnet 3.7 時，得把分析拆成數十個很狹隘的 prompt，套到每一個 ReAct 步驟上，又貴又脆弱，還是會漏掉一堆;而且 Sonnet 3.7 太容易相信 agent 的自我評估，agent 說「好，我找到答案了」它就信了。換成 Opus 4.6 驅動的 Claude Code 之後，一個 session、一段通用的 prompt，就能把整條 trace 從頭吃到尾，不需要人工切割，而且「真的能動」。更厲害的是這個 skill 不只挑錯，還會自己形成假設、跑實驗來驗證: 抓到可疑的問題後，它會去模擬一個改過的 prompt 跑跑看，確認真的能修好，才把建議交出來。

那這份報告長什麼樣? 文章貼了兩個實際的輸出。一個是 agent 該查 Google 卻沒查，導致它沒注意到美伊局勢升溫;Claude Code 不只指出這點，還追到根因(這是 Opus 4.6 在 effort = low 下的通病)，並給出具體的修法(把 effort 調到 medium 就好)。另一個更能看出它的「實驗精神」:

還有一點很值得提: 維護成本幾乎是零。他們在 skill 裡順手寫清楚「去哪裡拿 trace、agent 的實作在哪幾個 Python 檔、評估任務的標準答案在哪」，省得 Claude Code 每次重新摸索;再配一份 CLAUDE.md，鼓勵它「發現哪條指令過時了就自己更新 skill」，等於這個分析工具會自我維護。

ihower 自己寫的 trace 分析 skill: 生產規模的取樣審查

那如果要上到生產規模、一天好幾千條 trace 呢? 不必換成大平台，自帶 agent 這條路一樣能做，只是得先解決一個問題: 該看哪些? ihower 自己就手刻了一個這樣的 trace 分析 skill，用 Braintrust 的 bt CLI 把 trace 拉出來，小編借來當第二個案例。生產流量一大，就不可能每筆都讀，重點是把「最值得看的子集」送進結構化的審查。它用三種取樣訊號互補:

• 🚩 明確的壞訊號: 被護欄(guardrail)攔下的、使用者倒讚的、出現 error 的、工具呼叫爆量的、對話超過 N 輪的，這些全部撈進來看
• 🤖 judge 篩選: 用便宜的模型挑出可疑的，例如已知失敗模式的 judge、情緒 / 風險的 judge
• 🎲 隨機基準: 再隨機抽一定比例，才看得到那些「沒觸發任何訊號」的隱性問題，不會被訊號本身的偏誤綁住

skill 裡把這寫成一套加權抽樣規則: 全部 error 加全部 guard 都看，高互動輪數的隨機抽 75%、中互動抽 50%、基準流量只抽 15%。背後的邏輯是: 稀有但高風險的全看，高互動代表高資訊量所以多看，剩下的用隨機覆蓋。用比例(而不是固定條數)，抽樣量會隨流量自動縮放，審查量就跟著訊號密度走。取樣完再把樣本分組、切片，一個子 agent 讀一片，最後合成一份報告。

而這份報告刻意用一套固定骨架，讓每次跑出來的報告都能直接比較:

其中有一條規矩很關鍵: 事實與推論要分開標，別把「樣本裡直接看到的」跟「我推測的」糊成同一句。

編按: 這種「依流量決定怎麼看」的思路，Raindrop 共同創辦人 Ben Hylak 在 howtoeval.com 整理成一條階梯: 一天十來條時直接全讀;量一大就得讓系統告訴你哪些值得看，從 Stumbles(在原始紀錄裡撈苗頭)→ Issues(重複出現的就立案)→ Signals(值得長期監控的行為)→ Experiments(改完用真實流量做 A/B 驗證)。ihower 的加權取樣，就是這條階梯高流量那一端的具體做法。

② 執行時: 讓 agent 自己診斷自己

第二種位置更前面，前到 agent 還在跑的當下。Raindrop 的另一個功能 Agent Self Diagnostics 就是這個想法。小編必須說，這是這輪看下來最有創意的一招: 大家都在想怎麼「事後把 trace 讀懂」，Raindrop 反過來問「那不如讓 agent 在當下自己講」。背後的觀察蠻反直覺但很對: 「現在的 agent 比以前聰明太多了，它們往往比我們更清楚自己哪裡壞了。」

所以與其等事後有人(或有 agent)去翻 trace 才發現問題，不如讓 agent 在執行過程中自己回報故障，預設分成四種信號: 缺少上下文、工具重複失敗、能力缺口、任務徹底失敗(也能自訂)。

機制其實很乾淨，而且回答了一個容易誤會的問題: 這不是平台另外派一個 agent 來分析你，而是你自己那個 agent。你用 Raindrop SDK 把模型呼叫包一層(raindrop.wrap(ai, { selfDiagnostics: { enabled: true } }))，SDK 就會偷偷塞一個隱藏工具(預設叫 __raindrop_report)進你 agent 的工具清單，連 system prompt 都不用你動。照 官方文件 的說法: 啟用之後，SDK 會塞進一個隱藏工具，當 agent 撞上無法復原的問題時，它會靜默呼叫這個工具。每個信號類別，本質上就是給這個工具的一段描述(「什麼情況該回報 missing_context」)，你的模型在跑的當下自己判斷卡在哪、靜默呼叫這個工具，SDK 再把信號(類別 + 一段它自己寫的白話說明，綁在同一個 eventId 上)送回 Raindrop。所以這裡的「智能」，就是你的底層模型在讀那幾段工具描述、對自己的處境做第一層分類，不需要另一個分析模型。回到 Raindrop 之後，平台才負責跨多次執行的彙總、分群、追趨勢、告警。

換句話說，Raindrop 在這裡做的是分散式的質性分析: 把「我哪裡卡住了」這種第一層判斷推到 agent 自己身上(誰會比它更清楚?)，平台只負責把這些信號跨多次執行聚合起來。比起 LangSmith 那種「養一個外部大 agent 事後讀原始 trace」，這是把分析拆開、塞到源頭的另一種賭法。

不過也要老實說一句，而且這話是 Ben Hylak 自己講的: 這招創意十足，實戰上卻沒有表面看起來那麼好用。他在最新的 agent 評估指南(這篇非常讚，推薦一讀)裡直言，自診信號比較像「大水漫灌」: 一堆隨機回報裡，偶爾撈到一個有趣的，得花不少功夫去調靈敏度，才能變成穩定可用的訊號;更微妙的是，你給那個隱藏工具的措辭，會直接左右 agent 到底報不報，說穿了它就是一個二元分類問題。所以小編的評語是: 概念很漂亮、值得關注，但別期待它一開下去就一勞永逸。

③ 事後: 另外派一個專門的 agent 批次掃生產 trace

第三種位置在最後面: 等 trace 都進了生產資料庫，另外派一個專門的 agent，主動、批次地把整個迴圈跑完。最完整的代表，是 LangChain 在它的監控平台 LangSmith 上、五月推出的 LangSmith Engine。它本身就是一個 agent，做三件事: 找出重複出現的失敗、把失敗變成「可處理的問題」、再把問題轉成能長期沉澱的東西(評估器、資料集範例、修復 PR)。重點不在指出「這條 trace 壞了」，而是把一個生產失敗，變成團隊未來能拿來測試、防止退步的資產。

LangChain 還另外寫了一篇技術細節文講他們怎麼蓋這個東西，小編覺得比公告本身有料多了，幾個工程巧思特別值得學:

🔹 先壓縮再讀(trajectory): 生產專案的回看窗口裡可能有上萬條 trace，全塞進上下文根本不可行，光 10 條長 agent 的 trace 就能有上百個工具呼叫。解法是先把每條壓成「骨架」: 每一輪只留角色、工具名稱、延遲、內容字數，不放完整內容。agent 先看骨架找出「形狀可疑」的，再回頭把需要的細節撈進來。

🔹 篩選與調查兩階段分離: 第一階段用便宜的 Haiku 當「篩選員」，一次掃約 20 條，只回報「乾淨 / 可能有問題」，不做診斷;第二階段才派「調查員」把可疑 trace 的完整內容和程式碼撈進來深入分析。篩選員追求規模，調查員追求深度，職責切乾淨。

🔹 限制問題分類: Engine 不讓 agent 自由發明問題類別，而是給它一份預先定義好的清單(像 pii_leak、agent_looping、incorrect_tool_args、missing_tool)。理由很實在: 讓 agent 亂取類別，輸出就難以評估、也難以信任。

🔹 評估器先測過再交出來: Engine 為每個問題提一個評估器，但在拿給使用者之前，會先用 test_evaluator 工具拿證據 trace 跑一遍，確認它真的抓得到對應的失敗(回傳 PASS / FAIL / SKIPPED)。因為一個評估器「看起來合理」跟「真的抓得到問題」是兩回事。

🔹 找問題的 agent 跟修問題的 agent 分開: 早期他們讓同一個 agent 又找問題又提修復，結果什麼都做不好。後來拆成: 主 agent 只負責找問題、產出評估器和資料集，需要修的就打一個 needs_fix 標籤，再交給專門的修復 agent 去提修改。

🔹 跨次執行的記憶(Agent Overview): Engine 維護一份類似 AGENTS.md 的活文件，記著「你的 agent 在做什麼、會出現哪些 trace 結構、常見的地雷、團隊的偏好」，跨次更新，甚至會從使用者的動作(關掉某個問題、建立某個評估器)學習。

這套已經實際幫 Cogent、Harmonic、Campfire 等團隊處理過影響數千條 trace 的問題。而且這也不只 LangChain 一家在做，Arize、Braintrust、Databricks 在 2026 年都推了方向類似的東西，「平台幫你自動分析 trace」已經是一整個賽道。

踩個剎車: agent 真的會「分析」嗎?

三種作法講完，得踩一下剎車。Shreya Shankar 有一篇 Exploring Agent-Assisted Qualitative Analysis(用 agent 協助做質性分析)，做了一個很扎實的實驗。她本身就是做這行研究的(剛拿到教職)，這次直接拿 agent 去做學術界的「質性分析」: grounded theory，也就是讀大量雜亂的資料、貼標籤(編碼)、再歸納成高階的主題。她問了一個很本質的問題: 用 agent 做這種分析，到底行不行?

她的素材是 451 條推文(Sholto Douglas 問「什麼時候你會改用別的模型、而不是 Claude?」底下的回覆)，要分析的是「使用者為什麼想跳槽」。她跑了六種條件，差別在兩個軸: agent 有沒有被教 grounded theory 的方法、以及人類介入到什麼程度(完全不介入、逐批審編碼、讀備忘給回饋、甚至兩個 agent 互相對照)。

她先點出為什麼這題對 AI 特別難: 質性分析的「對的答案」高度依賴語料以外的脈絡，需要一種說不太清楚的品味與判斷(不像「程式有沒有編譯過」有標準答案);更麻煩的是，評斷的標準本身會在分析過程中不斷演化，而現在的 agent 偏偏假設目標固定、又急著收斂。實測下來，毛病很一致:

❌ 是轉述，不是分析: agent 產生的編碼數量，跟推文長度高度相關(ρ = 0.81)，但長推文往往只是同一個抱怨講得更長，它卻照著字數狂貼標籤。而且 93.8% 的編碼整份語料只用過一次，明明完整的編碼簿就在上下文裡，它卻不重用、每條都發明新標籤，根本沒在歸納。

❌ 沒把資料編碼完: 雖然被要求讀完整份、甚至多跑幾輪，agent 卻常讀到一半就自己宣布「分析完成」。表現最好的一組只編碼了 68%，最差的只有 5.5%，多數落在 25–35%;還有些推文直接被跳過、給了空標籤。

❌ 工作管理很差: 它傻傻地一條一條順序處理，不會像人類研究者那樣切分資料、有策略地採樣、邊讀邊組裝。最離譜的一組: 兩個 agent 跑到逾時後，主 agent 乾脆改寫成「關鍵字比對的 Python 腳本」(看到 sycoph 就標 overly_agreeable)，這已經完全不是在做分析了。

❌ 回饋迴圈很弱: 她講一次「我在意競品比較」，agent 就過度擬合、把它捧成最大的分類;她說「標籤太多了」，agent 收斂一下、下一批又故態復萌(最後 96.5% 還是一次性標籤)。要嘛過度擬合早期回饋，要嘛轉頭就忘。

更值得 agent 圈警惕的，是她當「人類審核者」的體感。她發現一個陷阱: agent 產出的高階分類，常常含糊到無法反駁，例如「可靠性與信任」這種大到什麼抱怨都塞得進去的類別，你很難說它錯，但這種「不可證偽」恰恰不是好分類。她一句話點破: 含糊的分類讓人容易相信、卻無法據以行動。如果連「幻覺算不算主要問題」這個類別都定義不清，那它接著提出的「修掉幻覺」方案，你也沒有基礎去信任。這正好戳中 LangSmith Engine 那類「自動產問題、提修復」的要害。

她的結論很精準: agent「能很快做完機械性的部分，但缺乏品味」。所以真正有意思的問題，根本不是「如何自動化質性分析」，而是「如何打造一個系統，讓人類的品味跟 agent 的規模真正組合起來」。而她隨手點的一個未來方向，剛好就是這整篇的主題: 把這套拿去做 agent 的 error analysis: 資料本身就是 agent 的 trace，目標是找出重複出現的失敗模式。換句話說，本文講的三種作法，正是這個還沒被解好的題目的早期答案。

Shreya 這個質疑，跟前面三種作法其實不矛盾，反而互補。注意到沒有: LangSmith Engine 那麼多設計(固定分類、評估器先測過、所有問題都進「待審核」狀態等人按)，本質上都是在替 agent 的「缺乏品味」做防護欄;FutureSearch 乾脆讓你自己的 Claude Code 在你眼皮底下開車，Raindrop 則讓 agent 把判斷攤開成可追蹤、人能在儀表板上把關的信號，也是同一回事。沒有人真的在假裝 agent 能取代人，差別只在於把人擺在迴圈的哪個位置。

想自己做好 trace 分析? 幾條小編的收穫

把上面的成功和翻車擺在一起，如果你打算自己搭一套用 agent 分析 trace 的流程，小編覺得有幾條原則特別關鍵:

🔸 別讓 agent 邊讀邊即興生分類: 這是 Shreya 那組實驗最大的教訓。讓 agent 一條一條讀、順手就把錯誤分類(axial code)生出來，它幾乎永遠在「換句話說」而不是「歸納」。比較好的做法，是把開放編碼和歸類拆開，或讓 agent 只負責提議、由你來定分類。

🔸 迴圈的編排交給程式碼，不要交給 agent 判斷: agent 很愛走一走就自己宣布「分析完成」(Shreya 那組最慘只讀了 5.5%)。所以「要讀哪些、分幾批、跑幾輪、什麼時候停」這種流程控制，用程式碼寫死(像 ihower 的取樣腳本、或 LangSmith 用篩選員去派發)，別讓 agent 自己拿主意。

🔸 用一個很簡單的標準，檢驗你抓到的失敗模式: 每抓出一個失敗模式，問自己一句: 它能不能寫成一條清楚的「納入 / 排除」準則，並且轉成一個自動檢查(LLM-as-judge 或程式斷言)? 不能的話，它就太抽象了，只能拿來自我安慰，沒辦法真的把迴圈閉合起來。這正是 Shreya 說的「含糊分類無法行動」的解藥，也是 LangSmith Engine 堅持每個問題都要配一個測過的評估器的理由。

🔸 把分類體系當成版本化的產物: 先把詞講清楚: 一個 axial code 是「一個錯誤類別」，分類體系(taxonomy)則是「整組類別」合起來的結構，改分類體系，通常就是在新增、合併、刪掉裡面那些類別。原則是: 分類體系一改，就回頭重跑，別讓新舊標準混在一起。而且人該介入的點，是在分類體系這一層，不是逐條標註那一層: 讓 agent 提議分類，你來做判斷(合併、刪除、調整、重新加權)，而不是自己一條一條編碼、當人肉標註工。對應的審查介面也該以群集為單位，每個群集直接附幾條範例 trace 連結讓你抽查，並秀出每輪之間的差異(哪些失敗模式是新增的、哪些類別搬了家)。

迴圈在閉合，但方向盤還在人手上

把這幾篇串起來，2026 的圖像蠻清楚的: 那個「讀 trace → 找問題 → 修 → 驗證」的改進迴圈，正在被 agent 一段一段接管。差別只在於那個最關鍵的質性分析，你想放在哪裡: 交給你自己的 coding agent(FutureSearch 用一個 skill 配 Claude Code)、讓 agent 在執行的當下自己診斷(Raindrop Self Diagnostics)、還是另外派一個專門的 agent 事後批次掃生產 trace(LangSmith Engine)。同一件「讀 trace、找問題」的事，被擺到了流程裡三個很不一樣的位置。

但 Shreya 的提醒值得貼在牆上: agent 是規模的放大器，不是品味的替代品。它能把上萬條 trace 篩到剩幾十個值得看的問題，這已經是巨大的價值;可是「哪個問題真的重要、這個失敗模式該怎麼定義、修復的方向對不對」，這些需要品味的判斷，方向盤還是握在人手上。

編按: 想看一個把這套迴圈跑到生產規模、又刻意保留人類品味的完整案例，可以看小編之前整理的 Replit 如何規模化評測和持續改進 Vibe coding，他們用離線的 ViBench 加上線上的 trace 分群 Telescope，雙引擎驅動每天出貨的 coding agent。

說到底，agent 上線之後本來就是一路邊跑邊修: 你不可能事先想好所有失敗，trace 分析就是你持續發現問題、持續改進的命脈。所以把 agent 做好，從來不只是一個模型問題，而是一個得長期經營的營運問題;而這條營運迴圈裡最累的一段，正是讀 trace，也正是這篇從頭談到尾、最值得想辦法交給 agent 分擔的工作。

編按: 這場演講的中文重點，宝玉 (@dotey) 整理過一個摘要版本 (按讚數破四百，傳得蠻廣)，想先快速掃過重點的可以參考。等一下會提到的 Toby 那串反駁，衝著的就是這篇摘要。

不過這場演講放出來之後，網路上也出現了不少不買單的聲音。剛好 Claude Code 之父 Boris Cherny 最近接受 Platformer 訪談又把話說得更滿:「coding 已經被解決了」「軟體工程師這個頭銜今年可能開始消失」。所以這篇就把三件事疊在一起看: Fiona 講了什麼、反對的人在吐槽什麼、以及一票真的在寫嚴肅軟體的人，怎麼反駁「人類不用再寫 code」這個說法。

一、Fiona 的演講: 瓶頸搬家了

Fiona 整場的主旋律就一句話: 「過去成就你的，未來不一定還能成就你 (what served you prior may not serve you any longer)」。

她說過去這麼多年，工程師的頻寬 (engineering bandwidth) 一直是最貴的東西，寫 code、寫測試、重構都很花時間，所以我們發明了一堆流程 (瀑布、敏捷、六個月 roadmap、設計文件)，本質上都是因為「打 code 很貴」，要好好規劃才不會浪費。

她也提醒這不是業界第一次得適應。她職涯早期在做 Visual Studio 2005，當年軟體還是燒在 CD-ROM 上出貨 (更早是磁片)，有硬死線要趕著把成品送進工廠壓片、裝盒、上架; 後來能線上發佈，整個出貨方式就被改寫了一次。每次底層條件一變，做事方法就得跟著重來。

但現在這個前提變了。在 Claude Code 團隊，「coding 已經很少是慢的那一環」，而且產出量暴增。瓶頸於是從「打字」搬到了它周圍的所有事情，用她那張投影片的講法: 舊瓶頸是「寫與出貨 code 的頻寬」(寫 code、寫測試、重構)，新瓶頸是「驗證、審查、跨職能協作、安全」。問題從「誰來寫」變成「這段 code 對嗎? 誰來 review? 之後誰維護?」

她有個觀察小編特別喜歡: 很多流程是「悄悄地不再有用 (quietly stops working)」。因為流程很少會自己消失，我們總是一層一層往上疊，疊到後來連 SLA 都要排優先順序。於是 Claude Code 團隊把一大堆慣例砍掉重練。最核心的一句話是: 他們把力氣從「事前」搬到了「事後」，少花時間規劃和爭論，多花時間驗證和對齊。

底下分三塊講她實際改了什麼。

規劃與技術辯論: 從「先想清楚」到「先做出來」

規劃變少，而且即時，她叫它 JIT planning (just-in-time，借自 JIT 編譯)。六個月 roadmap 寫完三個月就過期了，所以乾脆少寫; 設計文件大幅減少，改成「與其寫一份 doc，不如丟一個 PR」「有想法就去 prototype」; 產品評審也少做，因為局勢變太快，不如先做原型、讓內部大量試用、再出貨收真實回饋。

至於「加倍投資的驗證」，她叫它「左移 (shift left)」: 與其等 code 出去後自己搶在使用者之前抓 bug，不如用更多自動化，在更接近源頭的地方就攔下來。她講了個很有共鳴的例子: 有次她修了個 bug，隔天看到有人在 Boris 的 thread 上回報「我發現一個 bug」，當下那種「該不會是我吧」的下沉感，所以她希望不管什麼角色，每個人對自己送出的改動都更有信心。

技術辯論也變了，她的講法是「code 說了算」。她剛加入時想做一個重構，本來想拉 Boris 去會議室白板大戰，後來想想，不如直接讓 Claude 生成三個不同版本的 PR，連對所有 API 呼叫端的影響都一起攤開來看。「當『做出來』很便宜，『吵架』就變貴了」。但她特別強調，這反而讓「團隊文化與對齊」更重要，絕對不能變成「最後一個 check-in 的人贏」。

程式碼的歸屬與審查: 「誰寫的?」變成一個怪問題

因為所有 PR 都是 Claude 輔助生成的，「這段 code 是誰寫的?」現在問起來有點怪。她的建議是「往下追問 (double click)」你真正想問的是什麼: 是想找誰造成了這個 regression? 還是想找懂這塊的專家? 還是只是想了解脈絡? 想清楚之後，很多都能自動化，她甚至把每天早上配咖啡、進客戶回饋頻道請 Claude 摘要的儀式，直接變成了一條 routine 自動跑。

至於 code review，重點是分清楚哪裡信任 Claude、哪裡還是要人。風格、lint、補測試、甚至抓些小 bug 並修掉，這些重度交給 Claude; 但本著「信任但要查證 (trust but verify)」，法務審查、信任邊界與安全敏感的 code、產品品味，她還是堅持要拉真人專家進來。(她講了個好笑的例子: 有次想把終端機裡的 Claude 裝飾成雪人，結果做出來像花生人 Mr. Peanut，是設計師夥伴一眼點出來的。品味這種事，模型還沒接手。)

編按: 「你們怎麼跟得上 code review?」是她說過去半年被其他工程主管問最多的一題。這也呼應了新瓶頸的核心: 當生成變快，驗證與審查就成了真正的壓力點。這個主題小編之前整理過一整篇 AI 時代的 Code Review: 當 Pull Request 成為新瓶頸，挑了五篇 2026 年的文章談 review 跟不上之後的各種路線 (規格驅動開發、直接幹掉 review、五層信任框架…)，想往下深挖的可以接著看。

團隊組成與組織形狀

她重度看兩種工程師: 「有產品 sense 的創意建造者」跟「深度系統專家」(例如做 Claude Code Remote 這種分散式系統就少不了後者)，反而比較不看重「原始產出量」，因為那個模型已經幫你補上了。角色也在互相滲透: 她是工程師、自認文筆很糟，就讓 Claude 當她的「內容設計」夥伴，幫忙把問卷文案改得精簡 (終端機裡每一行空間都很珍貴); 反過來她的 PM 也大量在寫 code。

組織則盡量扁平、scrappy，她甚至要求每個 manager 都先從 IC 做起、親手 dogfooding，招募夥伴一度覺得她瘋了，說「哪個 manager 會願意先當 IC」。團隊還立了三條核心原則: ① 每個成員 (含跨職能夥伴) 都要用 Claude Code; ② 能 Claude 化的就 Claude 化 (Claudify everything); ③ 明確授權大家去砍掉沒用的流程。

最後談「這套到底有沒有用」，她給了三個可參考的指標: onboarding 上手時間大幅縮短、PR 週期時間縮短、Claude 輔助的 commit 比例上升 (她說過去四個月幾乎沒看過非 Claude 輔助的 commit)。但她也提醒: 不要盯著新聞標題那種「本公司 X% 的 code 由 AI 生成」，要回去看你真正想解決的問題、想做得更好的產品是什麼，品質與可靠度才是該盯的。

小編覺得這場演講最實在的地方，是它不講願景、只講「我們實際改了哪些慣例」。而且 Fiona 自己留了幾個沒答案的問題給自己 (iOS/Android 還要不要分隊、自動審查要推多遠、角色模糊後怎麼讓大家都覺得有產出感)，姿態其實蠻誠實的。

她最後留給聽眾一個可以帶回去做的事: 挑一個你最「吵」的工作流程 (最貴的、或大家最不想碰的那個)，問一句「它還有在服務當初的目的嗎?」。她舉了個例子: 以前有個 50 人的週會，她發現大家全程都在滑筆電、只有輪到自己報告時才抬頭講兩句，於是她問了句「我們到底為什麼要開這個會?」，然後就把它取消了。

二、反方一: Toby 的吐槽

不過工程師 Toby (@TobyAtLarge) 就不太買單，他針對宝玉那篇演講摘要寫了一串挺兇的反駁 (他自己也自嘲「好擔心自己變成槓精」)。幾個重點:

1️⃣ 「code 幾乎免費」是演講修辭，不是事實。code 確實便宜很多了，但「好的 code」(考慮架構、邊界條件、測試覆蓋) 仍然有成本。而 Fiona 自己也承認「維護成本不會跟著歸零」，代表她心裡清楚，只是台上為了衝擊力把話說滿了。

2️⃣ Source of truth 不只一層。她說「code 是唯一的事實來源」太絕對。真實工程至少三層: 需求 (為什麼做) → 設計 (怎麼做) → code (做出來了)。code 是執行結果，常常處在折中狀態。沒有需求文件做參照，你連「這個折中是刻意的還是 bug」都分不清。

3️⃣ JIT planning = 沒有規劃。他覺得對一個正經的 toB/toC 產品不做規劃很誇張，「先發 PR、少開會」容易導致功能失控。而且諷刺的是，從使用者端看，Claude Code 的發布節奏看起來反而是有規劃、有節制的，不像她描述的那種野蠻生長。

4️⃣ 整體判斷: 特殊環境裡的個人經驗，被包裝成了普適方法論。Anthropic 是極端特殊的環境: AI-native 產品、極高人才密度、公司本身就是最好的 dogfooding 場景。在這種環境跑一年的實驗，外推到「所有工程團隊都該這樣」，折扣要打得很大。

小編覺得 Toby 第三點對 open question 的批評有點過嚴 (她明明就說那是「還在想的問題」)，但第一點跟第四點蠻值得記住的。其實 Fiona 自己在台上就講了「do what makes sense for your team」，她沒要你照抄。真正的風險是聽眾，很容易把 Anthropic 的做法當聖經，忘了自己的 codebase 和人才密度根本不是那回事。

三、Boris 把話說得更滿: 「coding is solved」

如果說 Fiona 還算克制，Boris Cherny (Claude Code 的創造者) 在 Platformer 的訪談裡就直接得多了。他說自己已經超過六個月沒寫過一行 code、對他做的工作來說 coding「基本上解決了」，還公開預測「軟體工程師」這個頭銜今年就可能開始消失，融化成某種「builder」的角色，因為他身邊的設計師、PM、主管現在全都在寫 code。

Claude Code 已經有超過半年是 100% 由 Claude Code 寫的。Boris 說他去 Y Combinator 最新一批新創做分享，問「有誰 100% 的 code 是 Claude Code 寫的」，現場一半的手舉起來; 問「有誰完全沒用模型寫 code」，兩百多人裡只有一隻手。

不過小編要幫他說句公道話，因為這句話常常被斷章取義。Boris 在訪談裡其實有把 caveat 講清楚: 「對我做的那種 coding 來說，coding 已經被解決了」。他做的是相對簡單的 codebase (Claude CLI 還很新，桌面和 App 都是小型、單純的 codebase)。但 Anthropic 也有 NASA 這種大型、超複雜 codebase 的企業客戶，「對他們來說還沒解決，模型還是會出錯」。而且他強調 coding 只是工程師工作的一小部分，他以前大概 50% 時間在打 code，另外 50% 在跟使用者聊、腦力激盪、debug、規劃。他甚至預測未來「寫 code / 用 agent 寫 code 的人」會比現在多 100 倍。

編按: 問題就出在這個 caveat 在傳播時被剝掉了。新聞標題只留下「coding is solved」「工程師要消失了」，後面那半句「for the kinds of coding that I do」不見了。下面這群人反駁的，其實主要是被剝掉 caveat 之後的那個版本。

四、多方反駁: 瓶頸沒消失，它搬到了判斷力

小編搜尋了一輪這半年的論戰，發現一件有意思的事: 真正天天在用這些工具寫嚴肅軟體的人，幾乎沒有人站「人類不用再寫 code」這一邊。他們的反駁很一致: 生成 code 從來就不是軟體工程的難處。

Simon Willison 把 AI 寫 code 拆成兩個世界: 「vibe coding」(完全不看 code，壞了再求模型一次) 跟「agentic engineering」(專業工程師用 agent 放大自己的專業)。他不怕飯碗不保，因為這些工具是「既有經驗的放大器」，你越懂跑得越快。他有句話講得很白: 「做出軟體是一件兇殘地困難的事，給我全世界所有的 AI 工具，我們想達成的目標還是非常難。」

Armin Ronacher (Flask、Jinja 作者) 的例子更具體。他新公司的基礎設施九成以上是 AI 寫的，但他點出: 要用到這個程度，「你得知道 goroutine 和 thread 的差別、得懂 rate limiter 為什麼需要 jitter」。結論是: 「這些工具不會取代程式設計師，它們讓我們能在更高的層次施展專業。」

Mario Zechner (Pi agent 框架作者) 講得最直白: 人類是個瓶頸，而這恰恰是一種保護。

「人類沒辦法在幾小時內吐出兩萬行 code。但一支被編排好的 agent 大軍沒有瓶頸、沒有疲累，那些看似無害的小錯會以不可持續的速度複利累積。你把自己移出了迴圈，根本不知道這些小錯已經長成了一隻怪物，等你感覺到痛，已經太遲了。」

最後是 Matt Asay 在 InfoWorld 的提醒，正好打中 Fiona 那個「別盯著 AI%」的點: 對管理者來說，最糟糕的指標就是「AI 生成 code 的百分比」，真正該看的是缺陷有沒有變少、事故有沒有減少、客戶有沒有更開心。他總結得很到位: 「AI 並沒有消除工程紀律的必要，它只是提高了『沒有紀律』的代價。」

所以呢?

把這一圈聲音疊在一起，會發現它們其實沒有互相矛盾，反而拼出了一個共識。

Fiona 在台上已經親口說了答案: 瓶頸搬到了「驗證、審查、安全」。只是到了 Boris 的 slogan 裡，後半句被吃掉，變成了爽快的「coding is solved」。但這兩件事是一體的: code 變便宜，不代表「做出好軟體」變便宜，它只是把成本從「打字」搬到了「判斷、驗證、長期維護」。而那恰好是最難自動化、最吃經驗的部分。

有意思的是，連把話說得最滿、喊出「coding is solved」的 Boris 自己都留了一手。訪談最後問他要不要把「在 X 和 Threads 上回覆使用者 bug 回報」這件事也自動化掉，他說: 「我已經自動化了，但我還是偏好自己來。」原因很簡單: 跟人互動、聽人說哪裡壞了，是他最喜歡的部分。你看，連他都選擇把這件事留在迴圈裡親自做，而那正是判斷與品味。

所以與其問「人類還要不要寫 code」，不如問一個更實際的問題: 當生成幾乎免費，你打算把省下來的時間拿去做什麼? 是塞進更多沒人看得懂、沒人 review 的 code，還是拿去想清楚到底該做什麼、把它做對?

Armin 在另一篇文章裡有句話，小編覺得很適合收尾: 「沒有人能量產一棵五十歲的橡樹，也沒有人能用一個週末的衝刺，變出信任、品質或社群。」生成速度可以無限快，但有些東西，就是需要時間。

三位都是 Anthropic 的 research PM(研究端的產品經理),各講各的主題:一個談模型能力怎麼進步、一個談推理時的算力怎麼花、一個談工具生態怎麼長進模型裡。但三場連起來聽完,小編發現它們其實是從不同角度在講同一件事——你該為「下一個」模型寫程式,而不是為「上一個」。這句話正是 Lucas 最後一張投影片的標題:「為下一個模型而寫,別為上一個」(Build for the next model, not the last one),拿來當這三場的總綱剛剛好。

以下幫大家把三場的精華整理在一起。

1. 一年之內,模型變強了多少?

Alex 開場先做了個現場調查:覺得 Claude 讓自己一年內快了 10 倍的請舉手——結果舉手的一大片;5 倍?2 倍?幾乎全場都舉了。這不是場面話,他緊接著丟出一個具體數字:在 SWE-bench Verified 這個衡量「模型能不能自己完成一個軟體合併請求(PR)」的評測上,一年前的 Sonnet 3.7 拿 62 分,今天的 Opus 4.7 拿 87 分。

25 分的跳躍換句話說就是:那些一年前 Sonnet 3.7 會搞砸的困難任務,Opus 4.7 成功的機率是它的三倍以上。

Alex 還準備了一段對照示範:用同一句 prompt 要求模型「複製出 Claude.ai」。Sonnet 4 做出來的是一個黑白通用聊天介面,一送出訊息就報錯,基本上只是個好看的空殼;換成 Opus 4.7,直接就有 Claude 的配色、能正確打 API 拿到回應、會記住舊對話、會在訊息裡行內渲染視覺化圖表,甚至自己實作了深色模式——而且用的程式碼行數還更少。

編按:這場演講的重點不在某個特定模型,而在於「在一個每個月都明顯變強的東西上面開發」這件事本身意味著什麼。這個視角,才是三場演講共同的底色。

2. 進步發生在哪三個地方

Alex 把這一年的能力增長拆成三塊,每一塊都對應到開發者實際會踩到的痛點。

🔹 規劃能力:舊模型常見的壞毛病是「先動手、後思考」。Alex 的比喻很傳神——就像他組 IKEA 家具,直接上手,搞到一團亂才回頭看說明書。Sonnet 3.7 大概就是這樣。新模型則會先花時間想清楚、擬好策略,再動手寫程式。

這張投影片講得很白:以前是「先動手再說,而且是你的鷹架在逼它推理」;現在是「動手前先讀完全部,過程中還會抓到自己的錯」。對開發者的意義是——給 Claude 時間思考,別逼它一拿到任務就跳進去寫,那反而會拖累後面的表現。

🔹 錯誤復原:舊模型會陷入所謂的「死亡迴圈」(doom loop)——遇到問題、提一個解法、解法沒用,然後就卡死在那邊一直鬼打牆,直到上下文塞爆,只能整個清掉重來。新模型懂得退回來、換個角度重想、走另一條路。對你的好處是:任務表現更好,又少浪費 token。

🔹 長程注意力:舊模型做久了會「忘記劇情」,你寫在系統提示(system prompt)裡的指示,愈到後面愈不被理會。新模型能在數十萬甚至上百萬 token 的跨度裡維持一致性。

這代表你不用再像保姆一樣盯著上下文視窗,也不用把工作硬切成小塊餵給它——可以直接把整個程式碼庫交給它,信任它自己跑長任務。

把這三點加起來——更好的規劃、更少的錯誤、跑得更久的 agent——複利效應就是端到端任務表現的明顯提升。Alex 也舉了客戶的例子:Vercel 發現 Opus 4.7 會在寫下任何一行程式之前,先替系統程式碼寫好「證明」;Shopify 則看到模型一邊寫、一邊回頭迭代修正自己的輸出。

3. 想看到同樣的進步?先從你的 evals 開始

那開發者要怎麼在自己的應用裡吃到這些紅利?Alex 的第一個建議有點反直覺:不是從你的應用下手,而是從你的 evals(評測)下手。

「能被量測的東西,才能被改進。」重點有兩個:你得有 evals,而且這些 evals 要貼近你產品真正的任務分布。聽起來像廢話,但他說這正是很多團隊走偏的地方——明明做的是 coding agent,卻拿學術界的程式評測去測,而不是用接近自家使用者真實流量的資料。

接著還要做兩件事。一是確保 evals 沒有飽和:模型愈來愈聰明,evals 也得跟著愈做愈難,不然就抽不出新的訊號了——如果新模型輕鬆滿分,那這份 evals 已經量不出東西了。二是拿新出的前沿模型來測。Alex 說了一句小編很有感的話:有時候對你應用最好的優化,就只是換上最新的模型而已。所以每次有新模型,花點時間認真測,很值得。

4. 回頭看你的鷹架和 prompt——記得做減法

第二個建議:重新檢視你的鷹架(scaffolding)。Alex 對鷹架的定義是「圍繞在模型外面、把它導向目標的那些程式碼、prompt、skill 和工具設定」。

關鍵心法是做減法。新模型可能不再需要你以前搭的那些東西。也許以前要拆成多步驟的工作流,現在一輪對話就能搞定。「常常,你是靠『拿掉』而不是『加上』東西來提升表現的。」

prompt 也一樣。Prompt 會一代一代累積,久了就變成一坨醜陋的規則大雜燴,你自己都搞不清楚當初為什麼加某一條、它現在到底還有沒有用。每換一個新模型,就回頭砍掉那些可能已經用不到的指令——既救表現,又省 token。

5. 給模型發揮的空間

第三個建議,Alex 用一張投影片收斂成三點:

1️⃣ 讓 Claude 自己決定何時思考:用適應性思考(adaptive thinking),搭配 effort(努力程度)參數去調它思考和行動所花的 token。(這正好接到第二場演講的主題,等下細講。)

2️⃣ 用受控的方式,給 agent 更多工具權限:聽到這句有些人會緊張,但 Alex 強調他不是要你放任它亂搞。他舉 Claude Code 的 auto mode 為例:它會跑分類器去判斷 Claude 提出的每個工具呼叫到底需不需要人類明確批准,讓 Claude 可以在背景跑更久、更自主,不必一直停下來等人點頭。

3️⃣ 替 agent 把迴圈閉合:設計你的系統,讓 Claude 能檢查自己的輸出、然後迭代。比方說做前端的 coding agent,給它一個操作電腦的工具,讓它自己點開網站、實測它寫出來的功能對不對。

6. 第二根槓桿:在推理時花算力

第一場談的是「模型本身變強」,Matt 的第二場則談另一條變強的路徑:test-time compute,也就是推理時算力(inference-time compute),這就是大家熟知的「推理模型」背後那回事。

就像我們可以在訓練時用更大的模型、更多資料、更長時間來擴展算力,我們也可以在推理時讓模型「多花點時間」解一個問題。Matt 給了兩張對照圖:一張是從 Haiku 到 Sonnet 到 Opus,模型愈大,程式評測分數愈高;另一張是同一個 Opus,單純讓它在一個問題上花更多時間,分數也跟著往上爬。而且這不只適用於軟體工程,agentic 搜尋、操作電腦、博士級的學術推理,通通吃這一套。

7. 同一個模型,從 50 秒到 593 秒

光看圖表不夠直觀,Matt 用一個有趣的示範把這件事具象化:他要 Opus 4.7 寫一個「車流在單行道紅綠燈前的真實模擬」,然後分三種努力程度跑。

• 低 effort:約 50 秒、4,600 個輸出 token。車子會跑、會停紅燈,功能算過關,但畫面陽春,而且 Claude 把紅綠燈擺在馬路正中央(設計品味堪憂)。
• 高 effort:時間和 token 都加倍,結果明顯更好——有不同車種,紅綠燈也乖乖移到路邊,甚至實作了它自稱的「智慧駕駛模型」,每台車會根據周圍車況反應。
• 最高 effort:時間和 token 都是低 effort 的 10 倍(就是封面那張,593.1 秒、52,893 個 token),畫面、燈號、駕駛行為全都最逼真。

這個示範的重點是:同一個模型,光是讓它多花時間,結果就會更好。Matt 說隨著推理時算力繼續往上推,Claude 未來解一個問題花的時間不會只是幾秒、幾分鐘,而可能是幾天、幾週、甚至幾個月,拿來啃人類最難的問題。

8. Claude 花的三種 token

Matt 把「推理時花算力」拆成三種 token,這個分類小編覺得很實用:

• 思考 token:Claude 的內心獨白,一步步推理、權衡選項、打草稿的空間。
• 工具呼叫 token:Claude 跟外部世界打交道的方式,搜尋、讀寫檔案都算。
• 文字 token:Claude 跟「你」溝通的方式,回報進度、最後做總結,或單純回答你的問題。

這三種對使用者都有實際成本——你付的 token 錢,還有等待的時間。Claude 花愈多 token,你就等愈久。所以 Anthropic 認為,給使用者「影響或限制 Claude 怎麼花 token」的能力很重要。

方法有兩種。一是 effort 旋鈕:告訴 Claude 你希望它怎麼在時間、成本、品質之間取捨。二是 預算上限:他們最近推出的「任務預算」(Task Budgets)讓你設一個上限,例如「幫我做這個功能,但花超過 10 萬 token 就先停下來跟我確認」。預算可以是 token 數、時間或金額——當 Claude 動不動就要跑上好幾天的時候,這種「先講好做多久就回報」的機制會愈來愈重要。

9. 從固定順序到「適應性思考」

那給了努力程度和預算之後,Claude 內部到底怎麼分配這三種 token?Matt 講了一段演進史:

最早的推理模型是固定順序:先思考、再呼叫工具、最後輸出文字。後來有了交錯思考(interleaved thinking),Claude 可以在工具呼叫「之間」插入思考——呼叫工具、拿到結果、想一下、再決定下一步。最近則進化到適應性思考(adaptive thinking):Claude 完全自由,想在哪一步思考都行,順序、長度都不設限,遇到簡單的問題甚至可以完全不思考。如上圖,它可以是「文字 → 工具 → 工具結果 → 思考 → 工具 → ……」任意組合。

Matt 特別澄清兩個誤解:適應性思考不是模型路由器(它不會把問題分類後丟給「思考版」或「非思考版」模型),也不是自動開關思考的那種開關。它的本質,是把「你必須在回應一開始至少花一個思考 token」改成「你想在任何步驟思考都可以」。Anthropic 從 Opus 4.6 開始,所有評測都跑在適應性思考上,因為它在維持(甚至超越)交錯思考表現的同時,還能給更好的使用體驗。

10. 別再把 thinking 開關當「努力程度」在用

這段小編覺得是整場最關鍵的觀念。過去大家習慣把 thinking 開關當成「努力程度」在調——想讓 Claude 認真點,就去 Claude.ai 或 Claude Code 把 thinking 打開。直覺上很合理,但 Matt 說這是個很糟的替代指標。

因為打開或關閉 thinking,其實是在開關模型的一個「核心能力」,你限制的是它「能怎麼工作」,而不是「你要它多努力」。effort 旋鈕才是「多花 token 換更好答案」這個意思的正確表達——它會同時調動思考、工具使用和輸出文字,而不是只切掉其中一個。

Matt 的類比很到位:就像我們用工具時,不會叫 Claude「永遠都要搜尋」或「永遠別搜尋」,而是讓它自己判斷何時該搜;同樣地,我們跟同事共事,也不會叫他「把內心獨白打開或關掉」,我們只會問他「這件事要多拚」,然後讓他自己決定要想多深、做哪些動作。

11. effort 等級怎麼選?還有低 effort 帶來的驚喜

有 evals 的話,Matt 建議畫一條「努力曲線」:X 軸放 token / 時間 / 成本,Y 軸放表現,就能看清楚每一級的取捨。提高努力程度通常能改善大多數「吃智力」的任務,但會出現邊際遞減——你可能會發現 extra high 跟 max 表現差不多,但 token 差很多,那選 extra high 就夠了。

沒有 evals 的話,Matt 也給了幾條經驗法則:

• Max(最高):最難的任務才用,小心邊際遞減,別預設它一定是表現天花板或最划算的選擇。
• Extra high(極高):Opus 4.7 新增的等級,也是它在 Claude Code 和 Claude.ai 的預設值。大多數 coding 和 agentic 用途的最佳設定,智力拉好拉滿又不會太過頭。
• High(高):想在 token 和智力之間取平衡的好起點。
• Medium(中):成本敏感、願意稍微犧牲一點智力換速度時用。
• Low(低):留給範圍小、對延遲敏感的任務。

不過低 effort 也給過 Matt 驚喜。他最愛的評測之一是「Claude Plays Pokemon」(讓 Claude 玩寶可夢紅版)。用低 effort 跑起來,Claude 居然把遊戲當成「速通」在玩——跳過訓練家對戰省時間、囤好補品就地補血而不跑寶可夢中心、狂用「除蟲噴霧」減少洞窟裡的雜魚遭遇。小編覺得這例子很妙:我們常把低 effort 跟「比較笨」劃上等號,但要想出「怎麼把 token 花到最省、最快通關」其實需要相當的智力。Claude 把「低 effort」理解成「用最聰明的方式偷懶」,反而很有梗。Matt 也提醒,低 effort 時 Claude 一心想省 token,偶爾會抄一些你沒預期到的捷徑,所以除了看 evals,平時也該多讀讀它的對話紀錄,搞清楚它在某個努力程度下到底怎麼回應。

12. 小模型 vs 大模型開低 effort

既然推理時算力和訓練時算力都能換智力,那到底何時該用小模型、何時該用大模型開低 effort?Matt 的判斷準則:

• 大模型開低 effort:適合「吃智力但要快」的場景。以那個車流模擬為例,Opus 4.7 開低 effort 花的 token 跟 Haiku 4.5 開最高 effort 差不多、時間也只多一點點,但結果好很多。
• 小模型:適合「不太吃智力、但要省錢」的場景,尤其是要大量處理的簡單任務——分類、資訊抽取、基本摘要。另外,如果你的應用很在意「第一個 token 多快吐出來」,小模型天生就更快。

Matt 的口訣很好記:要讓「第一個 token」快,用小模型;要讓「最後一個 token」快,用大模型開低 effort。

收尾他給了三個帶得走的重點:一,能開思考就開思考,給 Claude 推理的空間;想調思考多寡,用努力程度或預算,別用開關。二,有 evals 就用 evals,畫曲線、測不同努力程度和模型。三,什麼都不想搞、又在做 coding 的話,直接選 extra high 就對了。北極星目標是:你設好品質門檻和預算,剩下的交給 Claude,它自己把算力分配到剛剛好。

13. 第三場:去年要自己搭的鷹架,今年內建進模型了

Lucas 的第三場把視角從「模型」拉到「模型周邊的生態」。他一句話點題:去年你得自己搭的鷹架,今年隨模型一起出貨了。所以別再把模型想成一個「輸入進去、輸出出來」的 LLM 盒子,而要把它想成一組會持續擴張、不斷增強自身能力的工具箱。

整場演講是一連串「去年 vs 今天」的對照,上面這張就是最好的縮影。左邊是去年:你得手寫一個挑工具的路由器(看到 SQL 就給資料庫工具)、外面包一層重試機制、再加一個輸出驗證器、最後串成一個跑迴圈——洋洋灑灑一大段。右邊是今天:就是一次 client.messages.create() 呼叫,把全部工具丟給它(tools=ALL_TOOLS)、順手指定輸出格式就好。Lucas 說重點不是這些工作「消失」了,而是它「搬家」了——搬進模型本身,你不必再自己扛。

14. 四個被模型吸收掉的能力

🔧 工具使用:以前你不敢把全部工具丟給模型(會吃爆上下文),只好寫一個路由器——用字串比對、各種啟發式規則,例如「模型提到 SQL 就給它資料庫工具」,外面再包一層重試。Lucas 直言這種路由器「本質上就是用 if 條件寫死的、對使用者意圖的猜測」,又脆、又是你加新工具時第一個壞掉的東西。現在模型夠聰明、選工具的準確率夠高,自己寫路由器和預先過濾反而常常幫倒忙;工具報錯時,你也可以信任 Claude 自己看到錯誤、復原、重試。小技巧:給工具時,大多數人只給「輸入」的格式,但你也可以把「輸出」的格式描述給 Claude——例如告訴它這個搜尋工具會回傳 id、標題、摘要、分數,那它想對結果排序時,就知道有分數可用,省下一次往返。玩 Claude Code 的人還可以在工具呼叫的前後掛 hook,程式化地做事(擋掉特定呼叫、或事後記錄輸出)。

🗂️ 上下文管理:以前長時間跑的 agent 得自己搭記憶系統——把文件切塊(chunking)、做 RAG、每隔幾輪就叫另一個模型來摘要,還要手動搬「快取斷點」省錢。現在呢?一百萬 token 的上下文長度搭配統一定價,先解掉大半壓力;再加上伺服器端的壓縮(compaction)和上下文編輯(context editing),剩下的就只是幾行設定,逼近「無限上下文」的體感。小技巧:每隔幾輪就清掉過時的工具結果(截圖、搜尋結果、讀檔內容這類),但保留 Claude 在對話裡記下的「決策」,就能即時省下大量 token。玩 Claude Code 的人可以打 /context,看到一張彩色格狀圖,直觀感受訊息、工具結果、系統提示、MCP 定義各占掉多少上下文。

💻 程式碼執行:以前「寫 → 跑 → 修」這個迴圈是開發者的活——找虛擬機(VM)供應商、開沙箱、把模型產的程式碼丟上去跑、解析錯誤訊息、再餵回模型,反覆直到成功。現在有了「程式碼執行」工具,自動在伺服器端給 Claude 一個沙箱,整個迴圈在「一次 API 往返內」就跑完,不用在 Claude 和你的虛擬機之間來回。Lucas 給的心智模型很好懂:這就像給 Claude 一台自己的電腦當「草稿紙」,它可以裝套件、跑資料分析、做運算,完全不弄髒你本機的檔案系統;當它需要碰只存在你本機的東西(你的程式碼倉庫、Python 環境)時,才回到真正的本機 bash,而且它分得清楚什麼時候該用哪一邊。玩 Claude Code 的人可以用 /schedule 排定由 cron 觸發的自主執行。

🖱️ 操作電腦:以前要讓 Claude 操作你的筆電,得寫一堆「影像膠水」——1080p 截圖先縮小到模型的像素上限、記住縮放比例、模型選好點擊位置後再把座標放大回原解析度,外面還要包重試和驗證。Opus 4.7 現在能直接吃原生解析度的截圖,在 1440p 以內回傳一比一的像素座標,縮放數學整個消失,你把圖送出去就好,信任它會點對地方。這個能力進步神速:招牌評測 OSworld(衡量模型在專業與消費級軟體上完成複雜任務的能力),不到 12 個月前 Claude 還在 50 分以下,連一半任務都做不完;Opus 4.7 報出 78 分,馬上要破 80。小技巧:1440p 以內建議多試不同解析度和影像格式(JPEG / PNG / WebP 的壓縮特性都不一樣);至於 4K 這種超高解析度,還是建議自己先縮小。玩 Claude Code 的人裝了 Claude in Chrome(到 claude.ai/chrome 取得),就能讓 Claude Code 直接開瀏覽器測試,連本機的開發環境也行。

Lucas 還放了一段示範:一個有錯誤的專案管理看板,Claude 自己用 Chrome 打開、重現「按了新增卻沒長出卡片」的錯誤、邊測邊改程式碼修好;接著測試拖拉功能時把卡片誤拉到錯的欄位,辨識出這也是錯誤、即時寫修正、再從頭重測一遍。小編覺得這個迴圈很關鍵——因為今天大多數軟體是給「人」用的,就得用「像人」的方式去測。讓 Claude 能在開發過程中操作瀏覽器,它才能自己閉合「寫出給人用的軟體 → 自己抓錯修好」這個迴圈,不必開發者手把手帶它找問題。

15. 一條判斷程式碼價值的鐵則

Lucas 結尾給了一條小編認為三場演講裡最該抄下來的規則:

任何你寫來「補償模型不可靠」的程式碼,半衰期只有幾個月。那種活,留給 Anthropic 就好。

這張收尾投影片把整件事講得乾淨俐落。左邊大標就是「為下一個模型而寫,別為上一個」,副標寫著「每一個軟體都正在長出一道給 agent 的前門,你的優勢就在你那道前門背後」。右邊兩張卡片是對照組:「補償模型(重試、路由器、規劃器、驗證迴圈)→ 半衰期以月計」對上「連接你的世界(工具、上下文、權限驗證、資料)→ 會複利成長」。

重試邏輯、路由器、規劃器、驗證迴圈……這些都正在、也將持續被吸收進模型。反過來,那種「把模型接到你世界」的程式碼,價值會複利成長——你的自訂工具、你的資料、你的權限驗證、你獨有的脈絡。一句話收得很漂亮:「模型無法吸收它看不到的東西。」所以把這些餵給它,遠比替它補短處有價值。

Lucas 進一步預言:不久的將來,每一個 agent、每一個軟體,都會長出一道「給 agent 的前門」。於是,有趣的工作不再是「把模型弄得更可靠」,而是「在你那道前門背後,放上別人放不了的東西」。

16. 三場連起來看:為下一個模型而寫

把三場拼在一起,訊息其實高度一致,只是從三個角度切入同一個建議——為下一個模型開發,別為上一個。

• 能力曲線告訴你:進步會複利,所以每出一個新模型,就拿 evals 重測一次,並且勇於對鷹架做減法。
• 思考槓桿告訴你:別再用開關去掐模型的核心能力,改成用努力程度和預算去表達「你要它多拚」,然後讓模型自己分配算力。
• 擴張的工具箱告訴你:別再自己扛「讓模型可靠」這件事,把力氣投在「把模型接到你獨有的世界」上。

貫穿三場的那個不變量,就是 evals——它既是你判斷該不該換模型的依據,也是你決定努力程度的工具,更是你驗證「拿掉鷹架之後表現有沒有變好」的那把尺。模型會吃掉所有通用的、會過時的東西;而你真正該擁有的,是那些專屬於你、模型再怎麼進步也複製不走的部分。

下次你又想替模型多寫一層保護網之前,也許可以先問自己一句:這段程式碼,是在補上一個模型的短處,還是在替下一個模型鋪路?

這次他又站上台，題目卻是 Everything We Got Wrong About Research-Plan-Implement，意思是「我們把 RPI 全搞錯了」。同一個人，半年內回來自己打臉，蠻難得的。他講得很坦白: 「我夠謙虛，做錯的時候願意承認。」這場就是在講他們跟上千位工程師實戰之後，發現 RPI 哪些地方根本行不通，以及怎麼修。

小編覺得這場比上一場更有料。它不是在推銷方法論，而是在拆解一套方法論為什麼會失敗。如果你正照著上一篇的 RPI 在用，這篇基本上就是它的更新說明。

先用一張表把兩場的差異講清楚:

以下是重點整理:

1. 先講做錯的三件事

Dex 一開場就把這次要認錯的清單攤開。最有爭議、那天在 Twitter 上吵翻天的一條是: 「可以不讀程式碼」是錯的。 另外兩條是: 不該去讀那種落落長的計畫文件; 還有，如果你寫的是會被使用者用、半夜三點壞掉會被叫起來修的正式程式碼，2026 年了，不准再生產 slop (粗製濫造的低品質程式碼)。

不過他也說，當初做對的幾件事仍然成立: 沒有萬靈丹般的「魔法 prompt」; 不要把思考外包出去 (工程師你本人是這套流程裡很重要的一環); 以及要不斷尋找「槓桿」，也就是想辦法在不必讀完每一行的前提下，確保產出是對的。這三點是整場演講的定錨。

2. RPI 一開始很好用，後來為什麼不行了

從去年十月起，HumanLayer 跟上千位工程師合作，從小新創一路到世界五百大企業都有。他們一再看到同一個現象: 把工具交給一個高手，他能跟 AI 黏在一起每週工作 70 小時、瘋狂出貨; 但同一套工具交給他的團隊，成果就普普通通。

問題出在哪? Dex 引用了一份去年的調查數據 (他特別提醒，這還沒算進後來更強的 Opus 4.5，現在實際表現應該更好): 用 AI 寫程式雖然產出量變多，但其中很大一塊是「返工」(rework)，也就是回頭修上週 AI 吐出來的爛東西。算下來你出貨量多了 50%，但有一半只是在清自己製造的爛攤子。

結論是: AI 對「全新、單純的專案」很好用，但對「歷史包袱重、又複雜的既有專案」就不行了。

3. 研究階段的修正: 故意把需求藏起來

第一個失敗點，是大家做不出好的研究。理想的做法是這樣: 你圈定程式碼庫裡的一塊區域，派出子代理 (sub-agent) 去做深入的探索，把「這段程式現在到底怎麼運作」壓縮成一份客觀的事實清單。關鍵字是客觀，不要摻進任何「應該怎麼改」的意見。

但實際上多數人是這樣下指令的: 「去研究一下程式碼庫，我要做的功能是 OOO」。問題就出在這裡: 好的研究應該全是事實，可是一旦你告訴模型你想做什麼，它就會忍不住開始給意見。

他們的修法很工程: 用程式 (而不是靠 prompt 拜託模型) 把需求從「做研究」的那段對話裡藏起來。一段對話只負責生出該問的問題，另一段全新、完全不知道你要蓋什麼的對話，才去產出研究文件。Dex 說這跟資料庫的「查詢規劃」(query planning) 概念很像，只是這裡的對象換成「讓 AI 去讀懂程式碼」。

4. 「魔法咒語」問題

第二個失敗點更尷尬。原本的規劃流程設計成: 先給你幾個設計選項、跟你來回討論、確認大綱，最後才動手寫計畫。但對超過一半的人來說，如果你沒念出那句咒語 (「跟我一來一回，先從你的疑問和大綱開始，不要急著寫計畫」)，AI 就會跳過討論，自顧自把計畫一口氣寫死，所有決定全幫你做完了。

Dex 說，他得站在一整屋子的企業工程師面前叮嚀大家「別忘了念咒語」，老實講蠻丟臉的。他的結論很重要: 這不是使用者的錯。如果你做出來的工具，要花大量訓練和反覆練習才能用出好結果，那該被修的是工具，而不是該被怪的是人。

5. 指令是有預算的

那 AI 為什麼會擅自跳過「先提問、先討論、先確認大綱」這幾個該做的步驟? 因為你有一個「指令預算」。他的共同創辦人 Kyle 寫過一篇文章，引用了一篇論文 (數字一樣是去年的，現在應該更高些): 目前最前沿的模型，大概只能穩定遵守 150 到 200 條指令; 超過這個量，它就開始三心二意、半聽不聽，全看運氣。

所以，如果你的 prompt 裡塞了 85 條指令，再加上 CLAUDE.md、系統 prompt、各種工具說明、一堆 MCP……要它乖乖照完整流程跑，機率其實不高。小編覺得這個框架蠻實用的: 很多人不停往 AI 裡加 MCP 工具和規則，效果卻越來越差，根本原因常常就是指令預算早就爆了。

6. 別讀計畫，去讀程式碼

這是這場最大的一次改口。上一場 (十一月) Dex 還站在台上叫大家一定要讀計畫，有些人甚至把計畫跟程式碼擺在一起送審。問題是: 一份一千行的計畫，最後產出的程式碼也差不多是一千行 (誤差 10% 以內)。 而且計畫常常會「跑掉」: 你花一小時把計畫讀完，實作出來卻長得不一樣，於是你又得回頭再讀一次程式碼，看哪裡變了。這根本不叫省力。所謂的「槓桿」，是做更少、卻產出更多。

所以新的建議是: 別讀計畫了，請去讀程式碼。 至於八月時他說「計畫就夠了、不用讀程式碼、放手讓 AI 跑」，他直接認錯: 「我們不讀程式碼這樣搞了大概半年，下場不太好，最後不得不把那套系統一大塊砍掉重寫。」

7. 但開源專案是例外

有人會反駁: 別人就不讀程式碼啊。像 Beads (三十萬行) 和 OpenClaw 這些開源專案，據說都沒人逐行讀過每一個 PR。Dex 的回應很到位: 這些都是很酷的開源專案，他打從心底佩服維護者; 但它們不收錢、半夜壞了不會有人被叫起來、做錯了也不會被罰幾百萬美元。

「但如果有人是靠你的程式碼吃飯的，拜託、我求你，去讀它。我們有個專業得扛 (We have a profession to uphold)。」這句話小編覺得是整場的良心所在。他不是在反對 AI，而是在分清楚情境: 在受嚴格監管的產業出貨正式產品，跟玩開源副業，本來就是兩套標準。

8. 瞄準 2 到 3 倍，而不是 10 倍

2026 被講成「告別 slop 之年」，到處都在談「粗製濫造」和「精雕細琢」的差別。Dex 也坦白，他對「一大群 AI 代理同時開工」這類玩法持保留態度，因為瓶頸從來不是速度，而是你確保品質的能力。跑快 10 倍，但成果六個月後整包丟掉，根本沒意義。

所以目標應該設在 2 到 3 倍，同時維持接近人類水準的品質。在問答時他補了一句很現實的話: 你乖乖讀程式碼、拿到 2 到 3 倍，這對生意的實際結果，遠勝過衝到 10 倍、堆出一堆爛東西，然後祈禱「反正 GPT-7 之後會幫我修好」。

那有沒有人主張完全相反、乾脆兩邊都別讀? 有觀眾問到 StrongDM 那種「軟體工廠」的路線 (人完全不碰程式碼，全靠自動化測試 eval 把關)。Dex 說，這條路會把你推向「形式化驗證」(formal verification)、TLA+ 那個方向 (用數學去嚴格證明系統行為正確)，他甚至遇過有人想做「TLA++」想證明一切都對。但他講得很直白: 他以前會引用 Sean Grove 的說法「把程式碼當成組合語言、你只要寫好那份描述期望行為的規格文件、之後永遠別再讀程式碼」，但現在他對這套主張的態度只有一句冷冷的評語: 「這個，我不挺。」 也許某天可行，但眼下還有一大票人得趕著把程式碼推上線。

編按: TLA+ 是圖靈獎得主 Leslie Lamport 發明的形式化規格語言。你不直接寫程式，而是用數學把系統「應該有的行為」寫成精確規格，再讓工具自動把所有可能的狀態窮舉跑一遍，檢查有沒有死鎖或違反規則的狀況。AWS 就在一篇知名論文〈How Amazon Web Services Uses Formal Methods〉裡分享過，他們用 TLA+ 在設計 DynamoDB、S3 等系統時，揪出人腦和一般測試難以發現的設計 bug; 微軟的 Azure Cosmos DB 也有公開的 TLA+ 規格。

9. 能用程式判斷的，就別丟給 prompt 判斷

那塞了 85 條指令的大 prompt 該怎麼救? 答案是: 能用程式邏輯來控制流程的地方，就別用 prompt 去控制。 這其實正是 12-Factor Agents 一直在講的事。Dex 自嘲他們當初到處勸人「別寫巨無霸 prompt、要把流程拆成小步驟」，結果八月自己回頭就寫了一個巨無霸 prompt，這次總算是「自己喝下自己賣的藥」了。

具體做法是: 與其用一個 prompt 內含一堆條件判斷 (是客訴就走這條、是帳務問題就走那條)，不如先讓模型做一次分類，再把結果丟給一連串更小、更聚焦、指令更少的 prompt 去處理。程式裡的 if 判斷很可靠，而模型很擅長做分類，而這個原則不只適用於寫程式的 AI，任何用到大型語言模型的系統都成立。於是原本那個 85 條指令的 prompt，被拆成好幾個各自不到 40 條指令的階段。

10. 設計文件: 趁早對 AI 「動腦部手術」

拆開之後，不只指令更容易被遵守，能再次修正方向的機會也變多了。第一個新階段是 設計 (Design，我們要往哪走): 大概只有 200 行，寫清楚現狀、想要達到的終點、要遵循的既有寫法、已經拍板的設計決定，還有尚待釐清的問題。

Dex 用了一個很傳神的說法: 這是你對 AI 「動腦部手術」的最佳時機。你逼它把找到的東西、想做的事、它以為你要的、它沒把握的問題，全部一股腦倒進一份你能隨手修改的文件裡。趁它還沒寫下兩千行程式碼之前，給它每一個機會，把「它可能搞錯的地方」先攤在你面前。這正呼應了那句核心: 不要外包思考。(Matt Pocock 把這份文件叫做「設計概念」: 它是人和 AI 之間，對於「要蓋什麼、怎麼蓋」的共識。)

11. 結構大綱: 計畫是「實作」，大綱是「目錄」

第二個新階段是 結構大綱 (Structure Outline，我們怎麼走過去)。如果說「設計」像架構評審會議，那「大綱」就是衝刺規劃會議: 把高層次的階段拆出來、決定改動順序、以及沿路要怎麼測。Dex 給了寫過 C 語言的人一秒就懂的比喻:

如果完整計畫像是把功能整個實作出來的程式檔，那大綱就像是 C 語言的標頭檔 (.h): 只列出函式的樣貌和會動到的型別，份量足夠你看懂 AI 在想什麼、能即時糾正它，但又不必讀完整版。一份計畫可能有八頁，對應的大綱大概只有兩頁，檢查起來輕鬆太多了。

12. 要「垂直」切，不要「水平」切

為什麼非得多這個大綱階段不可? 因為不管怎麼調 prompt、怎麼測試，模型就是改不掉「水平切」的壞習慣: 先把所有資料庫做完、再把所有服務層做完、再把所有 API 做完、最後才碰前端。等你回過神，已經是 1,200 行程式碼、而且整個跑不起來，還得回頭猜是哪一塊壞了，因為中間根本沒有任何能拿來測的半成品。

Dex 推的是 「垂直」切: 先假造一個 API 端點、讓它在前端能動、把前後接起來、再假造服務層、接著做資料庫遷移、最後整合。就算程式碼總量一模一樣，這樣切你沿路會有一個個檢查點可以驗證，不對就當場停下來修，而不是等全部寫完才一次爆炸。而那份「大綱」，就是逼模型乖乖照垂直方式切的最好工具。

13. 槓桿不只對自己，也對團隊

這些比較短的文件 (設計、大綱) 還有一個大用途: 幫團隊對齊方向。Dex 本人不是 HumanLayer 多數程式碼的負責人，他的共同創辦人才是。所以他會刻意先把自己的設計討論丟給對方看。他們沒有把這設成強制步驟，但他想確保等到正式審查程式碼那一刻，對方只會說「對，這就是我要的」。

換句話說，他那些不夠好的決定，會在那份 200 行的文件上就被攔下來，而不是等他把程式碼寫完、跑起來、產生感情之後才被退貨。換個角度看就是省時間: 用 AI 幫你寫，純寫程式的時間從好幾小時縮到 20 分鐘，但這仍然是個兩天的功能，因為跟團隊對齊、等人審查、跨團隊協調、測試驗證，這些都沒省到。可是當你連「規劃」和「對齊」都用 AI 加速、而且對得更準，後面的審查和返工自然也跟著縮短。

14. RPI 進化成 CRISPY

把研究與規劃的各個階段攤開，完整流程是: 提問 (Questions) → 研究 (Research) → 設計 (Design) → 結構大綱 (Structure Outline) → 計畫 (Plan) → 開分支 (Worktree) → 實作 (Implement) → 發 PR (Pull Request)。

這串階段的字首排出來其實是不怎麼順口的「QRSPI」，拼不成什麼像樣的縮寫，所以他們乾脆挑了喜歡的字母、改寫成好記的 CRISPY (酥脆的)。所以這不是嚴格的首字母縮寫，就是個順口的暱稱，RPI 就這樣進化成了 CRISPY。Dex 自己也吐槽: 本來想讓團隊更好上手，結果步驟不減反增 (他口頭說是「從三步變成七步」，但投影片上其實列了八個階段)。至於「平台團隊要怎麼把這套 prompt 持續改好、又不會把某個團隊原本順手的流程搞壞」，他坦言這還是個沒有答案的難題。

15. 「笨蛋區」現在還準嗎?

最後有人問: 你研究很久的「笨蛋區」(上下文一旦用超過 40%，模型就開始變笨)，在現在這麼多自動壓縮機制的情況下還準嗎? Dex 的回答蠻務實的:

「如果你已經重度用這類工具半年到九個月、每週 60 小時，那『笨蛋區』對你來說已經不是個有用的概念了。」他自己會常態衝到 60%，也會在某些任務上刻意壓在 30% 以下，全看任務複雜度、以及「指令」和「資訊」的比例。但對新手，他還是會教: 守在 40% 以下，到 60% 就想辦法收尾。

而且他們不用內建的自動壓縮，因為所有重要的東西，都已經寫進那些靜態文件 (設計、大綱、計畫) 裡了，你隨時可以從中斷的地方接著做，完全不必擔心自動或手動壓縮會不會搞砸品質。這其實才是這套流程最底層的好處: 把重要的脈絡放在你看得到、改得動的檔案裡，而不是放在那段隨時可能被壓掉的對話裡。

把兩場連起來看，會發現 Dex 的核心信念其實沒變: 模型本身是沒有記憶的，上下文的品質決定一切，所以千萬不要外包思考。變的是「人的注意力該擺在哪」: 從「讀計畫」挪到「讀程式碼，加上讀那幾份更短的對齊文件」。

小編覺得最值得帶走的，是他那句認錯: 「如果你的工具得念咒語才用得好，那該修的是工具。」這放在任何 AI 產品上都成立。我們太容易把「AI 用不好」歸咎於使用者「prompt 下得不夠好」，但真正成熟的系統，應該讓一般人不用學什麼魔法，也能拿到好結果。RPI 一路演化成 CRISPY，本質上就是在做一件事: 把「資深工程師腦袋裡那些說不清的隱性技巧」，一步步變成「流程裡寫得明明白白的步驟」。

小編補充: 用一個例子看懂這四個階段差在哪

研究 (Research)、設計 (Design)、結構大綱 (Structure Outline)、計畫 (Plan) 這四個名字有點接近，很容易搞混。小編用一個具體情境幫大家分清楚 (這是小編自己舉的例子，不是 Dex 原話):

假設你要幫一個現有的 SaaS 帳號系統，加上雙因素驗證 (2FA)。

1. 研究 (Research) — 現在長什麼樣?

摸清現況的客觀事實，不帶任何意見。

派子代理去查: 登入流程現在怎麼走 (哪個檔案、第幾行)、密碼怎麼驗證和儲存、session 怎麼建立、有沒有現成的簡訊或 email 寄送機制、使用者資料表長什麼樣。純粹記錄「現在是這樣」，完全不碰「2FA 該怎麼做」。

2. 設計 (Design) — 要變成什麼樣?為什麼?

拍板大方向和關鍵取捨，這是跟 AI 對齊「要蓋什麼」的地方，大約 200 行。

要支援哪幾種雙因素驗證: 是用驗證器 app 的 TOTP (Time-based One-Time Password，時間型一次性密碼)，還是簡訊? 備援碼怎麼處理、強制開啟還是讓使用者選用、開啟後現有的登入狀態要不要失效。會列出已經拍板的決定 (例如「第一版只做 TOTP」)，以及還要你回答的開放問題 (例如「簡訊費用誰吸收?」)。

3. 結構大綱 (Structure Outline) — 分幾步、照什麼順序走?

把工作「垂直」切成幾個有先後順序、能各自驗證的階段。就像前面說的 C 標頭檔: 只勾出有哪幾個階段、什麼順序、各自怎麼測,讓你看懂整體要怎麼走,但完全不碰「每一步改哪一行」那種細節 (那是下一階段「計畫」才做的事),大約兩頁:

1. 在使用者資料表加欄位、寫好 migration
2. 後端產生與驗證 TOTP 的元件，連同它對外的函式長相
3. 啟用與驗證的 API 介面
4. 前端的設定畫面和登入時的輸入框

每個階段各自要怎麼測，也一併寫清楚。

4. 計畫 (Plan) — 每一步到底改哪一行?

給 AI 照著做的施工圖，大約八頁，具體到「就算是全世界最笨的模型也很難搞砸」: 「在 user.rb 的第幾行加上 totp_secret 欄位」「新增 totp_verifier.rb，內容大概是這樣…」，每一步都標明檔名、行號、甚至程式碼片段。

最後用一張圖串起來，順序就是從「現況」一路收斂到「每一行」:

越前面的階段越需要人用力把關，越後面就越接近機械執行。

這也對應到 Dex 的具體建議: 真正值得你花力氣讀的，是前面那兩份比較短的設計和結構大綱 (在這裡跟 AI 對齊、糾正方向)，還有最後 AI 寫出來的程式碼 (一定要讀)。中間那份又長又容易跑掉的計畫反而不必逐行細讀，快速掃過 (spot check) 確認沒問題就好。把人類的注意力留在「最高槓桿的對齊」和「真正會上線的程式碼」這兩端，正是這整套流程的用意。

🎬 影片: Caching, harnesses, and advisors: Building on Claude at GitHub scale

以下是重點整理:

1. 三條主線: 快取、advisor、量測

Mario 把整場濃縮成三件事，剛好也是 Copilot 接平台時幾乎所有決策的底層。

第一是 prompt 快取。他講得很白: 沒有快取「我們不會死，但天啊，花的錢會多到嚇人」，所以光是 1% 的效率提升，對他們就是好幾百萬美金的差別。第二是跟 Anthropic 一起做的 advisor 機制，目標是讓使用者在「對的時間」拿到「對的智慧」，底下又分成 advisor 跟 critic 兩種玩法。第三是每次新模型一推出，怎麼有條理地把它接進產線。

這三條線背後都連回 GitHub 自己定的幾根柱子: 讓開發者保持在心流、讓團隊提速、用智慧跟信任在規模下把事情做成。Mario 說幾乎每一個產品決策都踩在這幾根柱子上，連談平台整合也一樣。

2. 為什麼 1% 的快取效率值好幾百萬

這個比喻很到位。Mario 把快取效率比成高頻交易: 單看一筆，1% 沒什麼感覺，但乘上每天數十億次呼叫，1% 就是好幾百萬。

所以對 Copilot 來說，快取根本不是「要不要做的最佳化」，而是這個規模的服務能不能活下去的前提。這也解釋了為什麼後面那麼多篇幅，都在講怎麼把快取命中率往上推、怎麼避免它被無端打掉。

3. 先有儀表板，再談最佳化

Mario 的第一個務實建議是: 先把快取命中率「儀表化」。沒有資料，要做決策真的非常非常難。

他特別提到 Anthropic 前陣子釋出了一個官方儀表板（Copilot 有先拿到預覽），可以看自己的快取命中比、對 Messages API 送了多少訊息。他直接喊話: 還沒去看的話，拜託去看一下，這是第一步。

不過 Copilot 真正盯的是自己那套，而且重點不是看單一數字，是看「模型之間的差異」。

這張就是他們其中一個儀表板的長相: 左邊是 Opus 4.6、中間是 4.7，旁邊那欄就是兩者的差值，還把 Sonnet 跟 Haiku 一起拉進來對照。新模型一進來（有時候在很早的測試階段就拿到），他們會跑一整套基準測試，像 Terminal Bench 2 這類，再加上自己內部的題庫，決定模型表現夠不夠格上線。上線後繼續盯資料，大概 30 天（有時更快）就能把那個模型的最佳化收尾。

這個差值還有一個很實際的用途: 要不要把預設模型從 4.6 換成 4.7，就看兩者的快取命中率差多少。Mario 說這個例子裡差了 1.3%——聽起來很小，但乘上每天數十億次呼叫，又是一大筆錢，所以這種決策一定要有資料撐著。

4. 健康的快取命中率是 94% 以上，掉到 70% 通常代表有 bug

這是小編覺得最有衝擊力的一個數字。要在規模下運營這個服務，Copilot 的快取命中率通常得跑在 94、95、96% 以上。

更狠的是反過來看: 如果命中率掉到 70%，那「八九不離十是有 bug」。意思是某個地方做錯了，可能是呼叫模型的方式、組 prompt 的方式、或整條流程出了問題，得回頭改。換句話說，他們不是把高命中率當「加分題」，而是當「健康指標」——低了就代表系統壞了。

他也補了一個常被忽略的成本算術: 從輸入端看，命中快取的 token 只算 10% 的成本，所以「命中」跟「沒命中」之間是 10 倍的差距。如果你一直讓快取失效，等於是用 10 倍的價錢在付那些 token。

5. 前綴要靜如止水: 別在前面塞會變動的東西

要把命中率從 50% 推到 70%、再推到 80%、90% 以上，Mario 強調這「不是運氣，是大量的硬功夫跟工程」。他點出三個關鍵，而且每一個都是踩過坑換來的教訓。

第一個是: 前綴（prefix）裡絕對不要放會變動的內容。快取的階層是 system prompt → 工具 → 對話歷史 → 最後送出的訊息，越前面越要穩。他舉了一個血淋淋的例子: 他們曾經在 system prompt 裡塞了一個 UUID，這東西每次都在變，等於每次都把整段快取打掉，命中率直接崩盤。所以 system prompt 要靜到不能再靜，一點會變的東西都別放。

6. 工具只在必要時才動，而且要有回歸測試護體

第二個教訓是工具。如果你動態載入工具、讓那段工具前綴一直變，那後面整段對話又會被連帶失效一次。

Mario 說他們在工具這塊吃過不少虧，所以建議是: 一定要有大量的回歸測試。因為你之後一定會大量實驗 skills 跟工具，整條流程裡得有測試守著，確保你在動工具的時候，沒有不小心把快取打爛。這點正好呼應投影片那段程式碼結構——左邊三行標語寫的就是「不放動態內容、只在必要時改工具、維持快取親和性」，把這三條規矩直接寫死在程式裡。

7. 多模型 harness 下的「快取親和性」最難搞

第三個、也是最硬的一個: 快取親和性（cache affinity）。Mario 直言，當你跑的是一個「多模型 harness」時，這件事真的很難。

拿 Copilot 當例子: 一個使用者可能先呼叫 Opus，接著叫一個 GPT 模型，再叫一個開源模型，然後又繞回 Opus。在這一連串切換裡，他得保證下一次的 Opus 呼叫——也就是接著上一次 Opus 留下來的那段——還能對到正確的快取。光是要在多模型 harness 裡守住這件事，他們就投入了非常多工。

這段對任何在做「多模型路由」的人都是提醒: 模型一換來換去，快取就容易斷，而把它接好，是真正的工程難題。

8. 破除迷思: 長上下文不等於更貴

Mario 說他常被客戶問: 用長上下文是不是就比較貴? 他的答案很乾脆: 不是。

他們做了一個快速實驗來佐證，投影片標語直接寫「長上下文 = 更多 token，但不等於更貴」。同一個模型、模擬不同行為: 較小的上下文視窗，平均壓縮次數是較大視窗的三倍。

關鍵在這裡: 輸出 token 比輸入貴很多（以 Opus 為例大約是 5 比 25），而每做一次壓縮，光是要把訊息摘要起來就得吐出大約 4,000 個輸出 token。所以你越常壓縮，輸出 token 就越爆，連帶快取也被嚴重打掉。結論是: 長上下文視窗本身不會讓你花更多錢，真正要懂的是「壓縮是怎麼被觸發的」，並依場景幫使用者把它管好。

9. 快取這塊的收尾心法

Mario 把快取這段收在幾句務實的話上。

先把命中率儀表化、做一個你真的會去看的儀表板，把時間投進去——官方已經幫你出一個了，至少先用那個，然後再進一步去看模型之間的差異、看上線前跟上線後的變化。他甚至講了一句很重的話: 在你把命中率看清楚之前，其他效率都不重要。把它從 50 推到 70、推到 90，會花掉大量工程時間，但這就是優先級最高的事。

另一個重點是「分介面量測」。Copilot 不只有 VS Code，還有 Copilot CLI、雲端的 coding agent、IntelliJ、行動版。介面這麼多，你得決定要「跨介面共用同一套 harness」還是「個別微調」，而且每次出版本都要清楚知道: 這次是進步了還是退步了。

10. advisor 策略: 小模型卡關才呼叫大模型

接著 Anthropic 的 Brad Adams 上場，講另一條從 Copilot 來的回饋: 團隊想要「Opus 等級的智慧，但 Haiku 等級的價格」。做法叫 advisor 策略，靈感來自資淺工程師配個資深導師。同理，你拿 Haiku 當執行者，給它一個能呼叫 Opus 的工具; 大部分時候 Haiku 自己處理，只有遇到它自己搞不定的關鍵點，才去問 Opus。因為動用 Opus 的時機壓得很保守，他們的評測顯示這樣能拿到接近 Opus 的智慧，成本卻低很多。Brad 還現場 demo 了一道刁鑽題目（要印出 Hello World!、但程式碼不能用到某些字母）: 純 Haiku 一直瞎試兜不出來，加了 advisor 那邊則問 Opus 一句、拿到提示就收工。

編按: 這種「小模型卡關才呼叫大模型當顧問」的做法，小編是持保留態度的。它本質上就是一種跨模型的 multi-agent 拆分，而這類架構的代價（token 成本常見 3–10 倍、context 污染、協調開銷）在實戰裡很容易被低估。之前那篇 Multi-Agent 反模式與模式 整理過不少證據，包括 Cognition/Devin 的實戰心得——很多時候把單一 agent 的 prompt 跟 harness 調好，效果不輸甚至勝過硬拆出一個顧問模型。demo 很漂亮，但要不要真上 advisor，建議先拿自己的場景做對照實驗再說。

11. rubber duck: 把 critic 插在「會複利」的時間點

Mario 回到台上又補了一招，叫 rubber duck（橡皮鴨）。他說「我們是 GitHub，命名上總有點怪」，但這招的核心是: 在對的時間點插入一個「批評者」(critic)。

advisor 跟 critic 的差別在角色: advisor 比較像顧問，回答「這個我來幫你算」; critic 則更主動地說「我覺得你應該這樣做」。rubber duck 的流程是——模型在實作到一半時主動去要一份批評（跨模型家族，例如找 4.6 跟 4.5 Opus），拿到批評後，在真正動手前先修正計畫，再照修好的方向做下去。

他們把這個批評者插在三個核心位置: 第一是「擬好計畫之後」（很多使用者都是先做計畫再執行）; 第二是「複雜實作之後」，他形容這像一種「預先的程式碼審查」，先擋一輪，能省下拖到正式審查才被打槍的 token; 第三是「寫完測試、但還沒跑測試之前」，在 CI 測試很花時間的地方插一刀，能更快把開發者送回心流。

Mario 自己最有感的是計畫階段: 現在這些系統都越來越會規劃，如果你在這個點把錯誤抓出來，後面拿到的收益最大。投影片那句話講得很精準: 把智慧集中在「會複利的時刻」，而計畫階段就是槓桿最高的那個點。rubber duck 現在已經是 Copilot CLI 裡的實驗功能，下載開起來就能用，你可以直接說「幫我擬個計畫，並找 rubber duck 諮詢一下」，就會拿到一份跨模型家族的快速批評。

12. 新模型上線的方法論: 從 Cappy 端點到雙軌評測

第三大塊回到「新模型怎麼接」。Mario 開玩笑說，接平台的人都知道那種感覺: 週六早上五點接到電話，對方說「我們禮拜二要發新模型囉」。一開始他們做得很亂，但這兩年半下來，已經磨出一套很有方法的流程。

Anthropic 給一個待測模型，他們先把它接進內部叫 Cappy 的東西（也就是 Copilot API），開出一個端點。從端點往下要做三件事: 一是在 harness 跟 prompt 上動工，因為是多模型 harness，得更新各家的 system prompt（這塊跟 Anthropic 密切合作）; 二是把工具介面調對、調好; 三是微調 agent 迴圈（這部分他說現在已經不太需要動了），然後在上下文管理、壓縮、衝到正確的快取命中率上投入更多。

接著是兩條軌: 離線基準測試，跟內部試用（dogfooding，可以理解成線上基準測試）。大量微軟工程師、GitHub 工程師、還有一批密切合作的使用者會實際去用、給回饋。然後把發現整理成一份文件——現在不只寫文件，還會展開成更細的簡報——跟 Anthropic 來回循環，談 API 要改什麼、甚至模型本身或 checkpoint 要怎麼調，一路循環到模型正式發表。

13. 離線只是基準線，真功夫在線上

這一段是小編覺得對做 eval 的人最受用的判斷。Mario 說: 離線評測會給你一個指標沒錯，但它「不會是現實」。

你從線上評測、從上線後的線上實驗學到的，遠比離線多。離線只是設一條基準線——如果那條線穩定，你大致知道上線會長怎樣，能給個不錯的預期。但所有細節都不是靠離線磨出來的。實務上他們常常要花好幾天、甚至好幾週，靠線上實驗（大量 A/B 測試）才把一個模型整個調順，而且每週都有報告往上呈報給 Anthropic、也橫向同步給各團隊。

14. 最後的鐵律: 量「結果」，不要量「活動」

優化 harness 時，Mario 把它拆成四個環節: 組 prompt 跟上下文、呼叫模型、執行工具、把結果接回去再迴圈。

他花最多時間的地方，是「執行工具」跟「組 prompt 跟上下文」這兩塊。工具對他們非常重要，但他也警告: 工具越多，混亂越多、要調的越多。「上百個工具不是好事」——你應該分介面去調，針對精確的場景配上對的工具包。每要引入一個新工具，他們都會在模型層跟工具執行層兩邊，花大量時間去優化 harness。

收尾他丟出兩個高層次原則。第一，訊號要「三角驗證」: 公開基準測試、內部基準測試、內部試用、A/B 測試、線上遙測都要有，而且要能用統計顯著性去信任它們。第二、也是最關鍵的一句——量「結果」，不要量「活動」(measure outcomes, not activity)。他舉例: 程式碼的「採用率」還行，但「存活率」是更好的指標。因為如果你接受了一段程式碼、過一陣子又把它刪掉，那其實根本沒達成目的。採用率再漂亮，存活率很低，就代表你沒做對事。

這也是整場演講最值得帶走的一句話。在 AI 時代做產品，如果只盯著那些好看的單項指標，很容易為了拉高某個數字，反而把整個產品真正該量的東西搞砸了。Copilot 在兆級訊息量下學到的，說穿了不是什麼花俏的招式，而是一種紀律: 盯對的數字（快取命中率、存活率）、把智慧花在會複利的時刻，然後相信線上的現實，勝過離線的想像。

🎬 影片: Evaluating and improving Replit Agent at scale

以下是重點整理:

1. Replit 面對的是 vibe coding 最極端的那一版

Catasta 一開場就先界定問題的特殊性。vibe coding 這個詞涵蓋範圍很廣，一端是給軟體工程師用的工具，但 Replit 的場景是最極端的那一端: 使用者只給一句自然語言的需求描述，其他什麼都沒有。

他講得很白: 使用者期待「從一句 prompt 直接變成一個能跑的應用」，但他們不會告訴你要用什麼框架，不會寫測試，也不指定任何實作細節，就是預期 agent 跑完之後東西能動。這跟過去替軟體工程師打造 agent 的假設完全不一樣，所以「過去做 eval 的方式，跟過去建 agent 的方式，都必須從根本上改變」。

這點是整場演講的地基。Replit 的使用者大多是完全沒寫過程式碼的知識工作者(knowledge worker)，這直接決定了他們的 eval 不能只看「程式碼有沒有改對」，而要看「做出來的 app 有沒有照使用者要的去動」。

2. 為什麼這件事特別難: 腳下的地一直在動

Catasta 用「shifting grounds」(腳下的地一直在動) 來形容他們的處境，小編覺得這個比喻蠻到位的。

模型一直在變，而且演進速度比一年前更快。模型一變，他們的 system prompt、user prompt 就得跟著改;為了配合產品新功能，prompt 也要常常調整;工具定義也一直在動，他們不斷新增、簡化工具。然後最關鍵的是出貨頻率: Replit 每天都有好幾次發布，而且是直接推到數百萬使用者面前。

在這種一切都在流動的狀態下，要怎麼確定 agent 每天都在進步、而且真的對齊使用者要的東西?這就是他們整套 eval 體系要回答的問題。

3. 核心主張: eval 不該是一個分數，而該是一條串流

這張投影片是整場的核心論點。左邊是「舊工作」: 你跑一次 eval，產出一個分數，然後由人類來看這個分數，決定「我的 agent harness 比之前好還是退步了」「該不該多做點 post-training」。整個流程在「人類做決定」這一步就停了。

Catasta 主張要往右邊那種「持續性」的設定走: eval 不是給人類消費的一個分數 (a score humans consume)，而是一個系統運行所依賴的串流 (a stream a system runs on)。當你有東西真的跑在線上、而且每天產生數百萬條 trace 的時候，這些 trace 本身就藏著大量可以挖掘的超額價值(alpha)。

所以他們做的是 offline eval (類似 SWE-bench 那種 benchmark) 加上 online eval (基於真實系統使用) 的組合。他對 eval 的要求很明確: 第一要優化使用者真正在乎的東西，而不是只告訴你 agent 有沒有把程式碼改對;第二要能立刻指出什麼壞掉了，這會直接告訴團隊下一步該出貨什麼改進。

4. 兩根支柱: 出貨前的守門關卡，出貨後的持續挖掘

那個「黑盒子」裡面到底裝了什麼?Replit 的系統有兩根支柱。

一根是老派的 benchmark，通常在出貨新版 agent 之前跑，把它當成一個是非開關、一道發布前的關卡。如果 offline benchmark 出現重大退步，就停止發布;沒變化或變好，就放行。

另一根是他覺得更有意思、也是真正讓他們持續進步的部分: 大量的 A/B testing，加上把線上所有的 trace 拿來分群、從中萃取洞見。這根 online 支柱是在你出貨之後才開始運作，逼著你盡可能快地反應。

兩根支柱到位之後就形成一個迴圈: 看兩邊給你的結果、據此改程式碼、再跑 eval，洗了又重來。Catasta 說這就是他們在 Replit 每一天都在跑的循環。

5. 為什麼 SWE-bench 不夠用: 缺了「功能正確性」那一段

Catasta 特別花時間解釋為什麼要做比 SWE-bench 更貼近自己場景的東西。像 SWE-bench、HumanEval 這類 benchmark 在這個領域當然很關鍵，逼著大家把模型做得更強。但它們本質上都遵循同一套協定: 確認生成的程式碼符合 prompt、把 patch 套到 repository 上、跑測試，測試過了分數就高。

問題是這完全不反映 vibe coding 的真實狀況。使用者不寫測試，常常是從一個完全空白的 code base 開始。根本不存在「套 patch」這種情境，因為你是從零開始把東西蓋起來的。

所以真正要捕捉的是: 這個 app 有沒有做到使用者要求的事?投影片上他把這叫做「functional correctness gap」(功能正確性的落差)，並下了一句蠻精準的判斷: 功能正確性才是「沒有人在量測的那個訊號」(the signal nobody was measuring)。

6. 台上發表 ViBench: 一個端到端的 vibe coding 公開 benchmark

為了補上這個落差，Catasta 直接在台上開源了 ViBench，一個端到端、針對 vibe coding 的公開 benchmark，他們做了好幾個月，網址在 vibench.ai。

設定很有意思。輸入就是一份 PRD(產品需求文件)，本質上是一段很長、描述怎麼蓋一個 app 的 prompt。他們不是用合成資料硬編出來的，而是從 Replit 的真實使用 trace 裡挑了 20 個案例，都是純英文的需求描述，沒有任何實作上的限制。然後有一個 harness 把 app 從空 repo 端到端蓋成可以動的東西。

關鍵的 insight 在最後一步: 與其在這裡停下來、找人類來評估這些 PRD 的產出，他們做了自動化的 evaluator。這就是讓 benchmark 從「大概一週跑一次」變成「每次都能跑」的關鍵——你 repository 裡只要有新的 PR merge 進來，就能跑一次。當然，跑所有 evaluation 的也是 AI。

7. 一個核心、一份開放的情境型錄: 從 zero-to-one 到 slop-on-slop

ViBench 的架構是「一個寫死的核心 + 兩個開放的槽」。寫死的核心是那個 behavioral eval (行為評估);前面兩個槽——輸入 (input) 跟策略 (strategy)——可以接任何東西。他們命名了五種配對，但你自己還能想出更多。

由淺到深大概是這樣:

• Zero-to-One: 輸入是 PRD，一次到位從零蓋到一。
• Vibe-on-Ref: 從一個已經能動的 reference 實作開始，在上面加功能。
• Vibe-on-Vibe: 從 agent 自己蓋的 MVP 開始，再疊一個新功能上去。Catasta 說這個用 X 上的黑話講就是「slop-on-slop」——agent 蓋了一個沒驗證過的東西，然後又在上面疊更多 agent 寫的程式碼，再跑評估看它還能不能動。
• Parallel + Merge: 對應他們幾個月前發布的 Agent 4，把任務分解、平行跑多個 agent、再把所有 patch 合併的複雜度都藏起來。這個「平行加合併」的情境對一般 coding agent 來說挑戰大得多。
• Decomposition: 輸入一份超大的 PRD，讓 agent 自己規劃跟拆解。

他還補了個更狠的玩法: 從一個有 bug 的 app 開始，在上面加功能，看 agent 要多掙扎才能讓它正確運作。型錄是開放的，社群可以一直往裡面加更難的情境。

8. 真正的難關在「怎麼打分」: 一個完全與實作無關的 evaluator

評分 (grading) 才是他們花最多力氣的地方，也是 ViBench 最硬的部分。

難在哪?因為在 vibe coding 裡，Replit 完全不給使用者任何框限(guardrail)，他們愛用什麼語言、什麼框架都可以。所以 evaluator 必須對「實作長什麼樣子」完全不可知 (agnostic)。

他們的做法是: evaluator agent 先讀過整個程式碼庫，然後開一個瀏覽器、指向 agent 蓋好的那個應用，接著一步一步照著測試計畫走。連測試計畫本身都是用自然語言寫的，動作像是「打開後台儀表板、用某個帳號登入、點某個開關」。任何一步失敗，就把它們全部彙整起來，生成一個分數。

Catasta 把這個跟 SWE-bench 對照: SWE-bench 永遠是固定的場地，你知道 repository、知道 test harness、知道怎麼讓它跑起來。但 ViBench 的場地是完全的 greenfield (全新空地)，這就是為什麼他們花了好幾個月才做出來。

9. ViBench 的兩個發現: 前沿模型領先 2 倍，改自己的程式碼最爛

論文會在幾週後的研討會上發表 (專案主導人也是論文一作 Peter 就坐在台下)，但 Catasta 先劇透了兩個最值得注意的結果。

第一，前沿模型跟開源模型之間有將近 2 倍的差距。他特別點出這點，是希望整個社群——不管開放權重(open weight)還是封閉權重——都來採用這個 benchmark，因為每個模型廠商都在爬特定的 benchmark，他希望大家一起在 vibe coding 上整體進步。他甚至開玩笑說，把 benchmark 開源，社群可以一直把它弄得更難，「讓 Anthropic 的日子更難過一點」。

後段對談裡 Hannah 直接問了大家最好奇的問題: 為什麼不把這套 benchmark 當成自家的祕密武器、留著當護城河?Catasta 的回答蠻能看出他的價值觀——他出身研究圈，相信東西就該開放，而且「不相信在 eval 上互相競爭」。公開的 eval 能讓模型更好、agent 更好，最後是所有人的產品都更好。他還補了個有意思的轉折: 這個想法他過去在不少場合都試著對社群喊話、希望大家一起做，但喊久了發現沒人動手，最後只好自己先把它蓋出來。

第二個結果可能不太意外，但很重要: 大多數模型在「延伸自己寫的程式碼」時表現更差。也就是前面講的 slop-on-slop / vibe-on-vibe 情境，是目前為止最難的。

Catasta 從這裡帶出一個實戰建議，小編覺得這句對所有在 vibe coding 的人都很受用: 每次新增功能之間，一定要插一個測試的步驟。否則你就是不斷在搖晃的地基上往上蓋，最後你的 vibe coding 應用遲早會垮。

10. 第二根支柱 online eval: 數百萬條真實 session 的價值

光有 offline 還不夠。Catasta 強調他們同樣在乎 online eval，原因是兩者能收集到的訊號量級差太多。

offline 那邊大概就 20 個 app (他特別說之所以開源，就是歡迎社群貢獻更多 app、更多 prompt，把 benchmark 越弄越難)。但 Replit 這邊每天收集到數百萬條 session，而且這些 session 極有價值，因為它們捕捉的是使用者在平台上真正做的事，完全沒有腳本、agent 一直在跑。

問題就變成: 怎麼從這堆東西裡蒸餾出有用的資訊?

11. A/B testing 是讓自己保持誠實的方式

答案之一是大量的 A/B test。Catasta 說這是他們「讓自己保持誠實」的方式，因為 ViBench 只告訴你故事的一部分。他也直接喊話: 每一個在做 agent 的人，都應該盡早投資自己的 A/B testing 基礎建設，這是讓你穩定進步最好的方式。

他們在 agent 裡埋了大量的監測點(instrumentation)跟指標(metric)，可以問各種問題: 有沒有異常的花費?agent 跑得比預期久嗎?他們也持續追蹤使用者情緒 (user sentiment)——這訊號很好收，因為每次收到 prompt 都能做情緒分析，看使用者是不是越來越挫折。還有一個很 Replit 特有的強訊號: 使用者可以把做好的 app 發布出去，如果他願意把成品分享給同事或公開放出來，那就是很強的正面訊號。

但 Catasta 也很誠實地講了 A/B test 的殘酷真相: 結果幾乎不會是非綠即紅的乾淨答案。投影片上那個例子——agent 平均執行時間漲了 7%，但成本反而便宜 8%，同時正負面情緒都有波動。這時候該怎麼辦?這就是人類的品味跟產品哲學還是關鍵的地方。你幾乎永遠不會拿到一個水晶般清澈的 A/B test 結果。

12. 把不知道該找的問題給分群出來

為了生成 A/B test 的候選，他們把每天每夜收到的所有 trace 拿來分群。先找出哪些群集是捕捉 agent 正常行為的 (這種很多，因為大多數時候 Replit 是成功的)，但總有一條長尾的問題會被浮現出來。

找到有問題的群集之後: 把所有摘要轉成 embedding、按類型分群，找出某個時間點上發生的各種失敗，再丟給 LLM 去精準分類到底發生什麼事。Catasta 強調，這件事不是靠 regex、掃日誌這類非常確定性的技術來做的，這正是差別所在——因為你能把語意上相近的東西分到一起，即使 agent 給你的輸出不見得每次都長一樣。

而且因為他們同時平行跑好幾個版本的 agent、每天出好幾個版本，所以不能用固定的分群設定，必須每天晚上重新訓練這些群集。

這裡有個很妙的好處: 重訓群集之後，可以回頭看某個群集在你以為修好問題之後是不是真的消失了。比方說有個工具失敗只在特定條件下、1% 的機率發生——這種根本不會出現在你的 Datadog 儀表板上，因為它不是那種 50% 都會發生的數字。但你 ship 了新 PR、那個群集消失了，你就開始有證據說自己緩解了這個問題。小編覺得這招對抓長尾 bug 特別實用。

13. Telescope: 一個幾乎全自動的改進迴圈

他們內部把這套技術叫 Telescope，是一個 (Catasta 希望聽完之後你會覺得) 相當簡單的迴圈:

先發現問題 (discover)，基於前面講的 trace 分群。再據此產生程式碼改動 (create code changes)——這完全自動化，他們用 coding agent 直接根據從 trace、日誌、各種儀表板收集到的資訊去開 PR。然後評估這個改動: 先重跑 ViBench 看是不是破壞性改動，ViBench 在這裡像個試金石 (litmus test)，分數掉超過 10 分就判定這個改動是壞的。如果是有爭議、可能對 agent 有負面影響的改動，就跑 A/B test 放到使用者面前看取捨;如果是明顯的好球就直接出貨到線上。少數情況下，如果假設正確但 PR 不夠完美，就繼續迭代、再跑一輪 A/B test，直到配置夠好才真正出貨。

Catasta 下了個蠻有意思的註腳: 如果你想想，這跟你身為 AI engineer 平常做的事很像，只是現在 90% 都由迴圈裡的 agent 代勞，你不用為每一個步驟去流汗。

投影片上那個真實案例蠻具體: Telescope 標記出一個小但在成長的群集——環境設定在一條冷啟動 (cold-start) 的長尾上悄悄退化。Replit 的 agent 在第一次送 prompt 時就會啟動執行環境，而要把這套複雜度都架起來需要好幾秒。有一次長尾上的設定時間比預期久，agent 在環境還沒準備好就先動了起來。

14. 那個 cold-start 案例: 為什麼非靠語意分群不可

這個案例 Catasta 講得很細，小編覺得很能說明 trace clustering 的價值。

現在的 agent 變得非常急著想修問題 (eager to fix)。所以 Replit 的 agent 就「跑偏了」(went on a tangent)，當場開始試圖修環境。但因為 agent 本質上不是確定性的，每一次 debug 的 session 看起來都長得不太一樣。

結果就是: 如果你只靠撈日誌去找這個長尾問題，它幾乎不會浮現。但一旦你透過語意層把所有 trace 分群，就會發現這個問題其實發生得相當頻繁，於是馬上就能做出 patch 修掉。這個案例因為是純退步 (pure regression)，所以不用跑 A/B test;如果是需要測試的問題，中間就會多插一個步驟。

15. 人類的品味還是最重要的地方

雖然 Catasta 是「盡量用 agent 優化 AI engineer 生活」的大力支持者，但他很明確地說，在他展示的這套迴圈裡，還是有大量需要人類做的智識工作。投影片上他把人類品味落在四個位置:

• 假設選擇 (hypothesis selection): 哪些問題值得花掉迴圈的「過夜預算」?因為跑在線上你會拿到超大量的修復候選，必須排優先序。每次找到一個群集，團隊都會先針對「這裡可能哪裡出錯」形成一個假設，假設夠有意思才往前走，而且不會放手讓 agent 在零監督下亂寫 PR。
• 實作架構 (implementation architecture): 做出恰當的工程跟產品決策。
• Eval 策展 (eval curation): 他用了一個很傳神的說法——你每次決定要做某個 PR、跑某個 A/B test，其實都是在「形塑 agent 要爬的那座山」(shaping the hill that we try to optimize)。如果你只在乎讓產品更便宜，就會去修所有異常花費的問題、拼命優化那一塊。這些選擇真的決定了你想放到使用者面前的產品哲學。
• 發布核可 (launch approval): A/B test 沒有清楚結果時，最後要不要發布還是人類的選擇。Catasta 說「通常那個人就是我」。

在後段跟 Anthropic Applied AI 團隊的 Hannah 對談時，他補充了一段關於「品味怎麼養成」的話蠻值得記: 一年半前剛推出時，agent 還沒這麼強，那時候沒什麼品味可言，比較像是生存遊戲、只求勉強能動。現在 agent 變強、選擇變多了，你才開始發展出品味，而這個品味必須跟你真實的使用者群對齊。Replit 裡每個人都很技術，但產品是給「從沒寫過一行程式碼」的知識工作者用的，所以 80% 的決策可能跟你替工程師做 agent 時是相反的——永遠要記得用的人很可能跟你很不一樣。

16. 一個額外的實戰提醒: 半年前做不起來，現在再試一次

對談裡 Hannah 問「想自己蓋類似 Telescope 系統的人，有什麼教訓可以分享」，Catasta 的回答小編覺得很實在。

第一句就是: 如果你半年前試過、因為投資報酬率不好而放棄，現在絕對值得再試一次。你在 coding agent 上經歷過的那個轉折點 (inflection point)——他特別點名是去年 11 月 Opus 4.5 那一波前沿模型——同樣反映在這件事上。長上下文加上真的能對大量內容做推理的模型，意味著你現在可以把整段 agent trace 灌進 Opus，拿到相當細緻的回饋。

與此同時，你應該認真投資「收集所有能收的訊號」——不只是 trace，還有產品內的回饋。Replit 有回饋表單，所以每次 agent 行為不對、使用者抱怨，他們就同時握有使用者的觀點、agent 的 trace、以及平台在 Datadog 裡所有的監測資料。把這些全部放進同一份上下文，就更能精準定位問題到底出在哪。

Catasta 也補了一個讓人比較安心的角度: 把 trace 分群這件事，其實讓 agent builder 的日子沒那麼難熬。當你開始有大量使用，收到的回饋多到讓人喘不過氣——這是好訊號，代表大家在乎你做的東西——但分群幫你排出「什麼真的重要、什麼動不了大局」的優先序。

寫在最後

整場演講最大的啟發，Catasta 自己用一句話收尾，小編直接翻過來: 別把 eval 只當成出貨前的最後一道檢查、一個是非開關，要把它想成「一具能讓你每天出貨更好 agent 的引擎」(an engine that allows you to ship a better agent every single day)。

把這場演講串起來看，會發現 Replit 其實是在回答一個很多人卡住的問題: 當模型、prompt、工具、產品功能全都在高速流動、而且你每天要面對數百萬使用者出貨時，傳統那種「跑個 benchmark 拿個分數」的 eval 根本撐不住。他們的答案是把 eval 拆成兩根支柱——出貨前當守門員的 offline benchmark (ViBench)，加上出貨後靠 trace 分群持續挖掘的 online 系統 (Telescope)——再用一個幾乎全自動的迴圈把兩者接起來，讓「發現問題、改程式碼、驗證、出貨」變成一條每天都在轉的生產線。

而最反直覺、也最該記住的，反而是 Catasta 在全自動的故事裡一再強調的: 自動化跑得越多，人類的品味反而越關鍵。從假設要不要追、到 A/B 結果模稜兩可時要不要發布，這些「形塑那座山」的選擇，最終定義了你的產品。eval 自動化解放了人，但沒有取代判斷。

直到 5 月 13 日這集 Core Memory Podcast，他終於跟主持人 Ashlee Vance 和 Kylie Robison 做了一場將近一小時的長訪。從 MSL 的組織架構、MuseSpark 的技術細節，一路聊到 agent 經濟、開源安全、AI 競爭格局、地緣政治、機器人、腦機介面、模型福祉。因為是加入 Meta 後的第一次公開深談，Wang 也終於回應了不少累積已久的八卦和質疑。

以下是重點整理:

1. 交易是怎麼談成的

Wang 說他跟 Zuckerberg 認識很多年了。還在經營 Scale 的時候就常跟 Zuck 請教，Scale 從 2016 年就在做 AI（最早是自動駕駛），兩人對 AI 一直有持續的交流。

大約一年前，兩人開始探索更緊密合作的可能性。Wang 觀察到 Zuck 在那個時間點對 AGI 的信念越來越堅定，不只認為 AI 會徹底改變 Meta，更把它看成一生一次的變革性技術，想要下非常大的賭注。同時 Llama 4 明顯沒有在正確的軌道上，Meta 需要改變。

經過一系列開放式的腦力激盪（Wang 說「這種事情通常都是這樣開始的」），他們找到一個對 Scale 好、對 Meta 也好的方案。Zuck 大約同期發表了「個人超級智慧」備忘錄，那就是兩人共同的北極星: 用 AI 賦能所有人，讓盡可能多的人都能用到這項技術。

2. 為什麼去 Meta

Vance 很直白地說: Scale 是你身份的一部分，你是那家公司的創辦人。要去一家八萬人的公司任職，這跳躍也太大了吧。

Wang 的核心判斷是兩件事:

第一，建模型的人掌握了越來越大的經濟和產品話語權。早期生態還有很多關於「生態系怎麼分層」的辯論，但隨著模型進步的速度越來越快，做模型的地方就是整個生態裡最激動人心的位置。

第二，算力正在重新定義科技公司的階級。有大量算力的公司跟沒有算力的公司，能做的事情根本不是同一個量級。他認為業界應該開始用「有沒有算力」來分類科技公司，而不是籠統地把所有科技公司看成同一種。有算力的公司能建的東西，沒算力的公司根本碰不了。

這兩個判斷放在一起，Meta 的吸引力就很清楚了: Zuckerberg 全力押注 AI，而且 Meta 有海量算力。Wang 還補充說 AI 的進步速度比他原本預期的快得多，這也是推動他做出這個決定的加速因素。

3. MSL 的組織架構

Wang 搬到了 Palo Alto（他笑說現在的生活就是在 University Ave 散步、買珍珠奶茶），MSL（Meta Superintelligence Labs）的結構比外界想的更清楚:

• TBD: 大型模型研究實驗室，那個「有點惡名昭彰的」核心團隊。頂尖研究員和基礎設施工程師都在這裡，技術上全部向 Wang 報告
• PAR（產品與應用研究）: Nat Friedman 負責，管所有產品和模型的實際部署
• FAIR: 繼續做探索性研究，特別是科學方向，像是用 AI 理解大腦、計算化學、原子通用模型 UMA 等
• Meta Compute: Daniel Gross 負責，專注長期基礎設施規劃和 GPU/資料中心建設

首席科學家 Shengjia Zhao 則橫跨整個 MSL，負責科學議程的整體方向。

有個有趣的背景: Nat Friedman 是 Scale AI 最早期的天使投資人之一，甚至在 Wang 完成 YC 之前就投了。Daniel Gross 也是差不多同期認識的。這群人的交情比外界以為的深得多。

4. Meta AI 之前出了什麼問題

Wang 到 Meta 後發現的根本問題是: 團隊沒有真正把超級智慧當回事。他說很多大公司有很聰明的人在做 AI，但跟那些「從零開始就瘋狂相信超級智慧要來了」的新創公司相比，信念的強度完全不同。大公司的員工不是帶著這個瘋狂想法從頭開始的，心態自然不一樣。

他為 MSL 定下了四條原則:

1. 認真對待超級智慧
2. 技術聲音最大聲
3. 科學嚴謹、回歸基本功
4. 大膽下注

5. 追趕前沿的三條路徑

在這四條原則之下，Wang 拆出三條具體追趕（甚至超越）前沿的路徑:

🔹 更高的每人算力: 大實驗室算力很多，但分散到太多方向，反而拖慢每個研究員的進度。建一個更聚焦、更小的團隊，讓每個人分到更多算力，研究速度實際上會快很多。

🔹 人才密度: 他直說這是人類組織反覆學到的教訓: 一小群頂尖的人，永遠比一大群責任分散的團隊跑得快。團隊裡每個人都得是頂尖中的頂尖。

🔹 非常大膽的研究賭注: 有些研究方向風險極高，但一旦成功就能改變整個範式。除了打造有競爭力的前沿模型之外，他們把大量資源和算力押在這種高風險高回報的方向上。

6. 「外觀很傭兵，內在很新創」

Vance 很直白地問: 從外面看，你們做的事情非常像雇傭兵，砸大錢挖人、把原本的團隊換掉。讓他想起 xAI 的做法: Elon 就是搞比所有人都多的算力加一個核心團隊，結果追上了但似乎從來沒有達到逃逸速度，特別是在品牌認知上。這種東西真的能用買的嗎?

Wang 說這是他覺得外界跟內部日常反差最大的地方。媒體報導誇大了很多東西，而且因為招募速度極快（他一進 Meta 就知道「如果要建好模型，昨天就該有團隊了」），所以看起來像閃電戰。

但實際上 MSL 是一個全新從零建立的團隊，文化非常像新創。來參觀的其他實驗室的人常說，這裡的氛圍讓他們想起早期的 OpenAI 或早期的 Anthropic。某種意義上，MSL 才十個月大。

至於研究員是不是純粹為了錢來的? Wang 說大部分人留在原來的地方財務前景也非常好。真正吸引他們的是: 更高的個人算力、跟一群頂尖同事一起工作、以及大膽追求自己研究方向的自由。

招募過程本身也非常「個人化」的，要一個一個去跟人談，解釋在建什麼、為什麼在乎這個技術、想拿它做什麼。因為大部分人預設根本不知道該怎麼看 Meta 的 AI 計畫，所以得先讓他們相信這裡是認真的。

7. 招募湯和個人代價

關於 Zuckerberg 親手做湯招待研究員的傳聞（之前 OpenAI 的 Mark Chen 上同一個 podcast 也提過），Wang 笑說「不確定是不是我們做的湯，但我被告知確實是 Zuck 做的」。

更沉重的是個人代價。Wang 在 Scale 時代跟所有 AI 實驗室都有合作、認識所有人、跟所有人都維持關係。但到 Meta 之後，這些關係有些明顯裂了。

Vance 說他聯繫 Sam Altman 問起 Wang 上節目的事，Sam「沒什麼好話可說」。兩人曾經是室友。

Yann LeCun 離開 MSL 後公開對媒體說 Wang「年輕又沒經驗，會有更多人離開」。還有一直揮之不去的標籤: 太年輕、不是工程師（Wang 反駁: 這絕對不是事實，他曾在矽谷當過軟體工程師）、只是個業務員。Vance 還提到 Wang 是數學奧林匹克選手，在矽谷，這類競賽選手通常在程式和工程上都非常強。

Wang 倒是蠻淡定的。年齡這件事他在矽谷聽了一輩子，已經幾乎不會去想了。至於 Yann，他說幾週後在印度碰到，Yann 恭喜了 MuseSpark 的發布，兩人在 X 上也公開和解了。他的態度是: 隨著超級智慧越來越近，他真心希望業界的各種敵意能消退，大家能回到認真對待這項技術本身。但 Kylie 追問「你不覺得情況好像越來越糟嗎?」Wang 停了一下，笑說「也許先變糟再變好吧」。

8. 管理哲學: 不是來當老闆的

Vance 直接說: 你在 Scale 的時候，在某些圈子裡被認為比較像業務員，而且享受生活。我當時還在想，你管研究員管得動嗎?

Wang 引用了 Steve Jobs 的名言:「大部分公司雇人然後告訴他們做什麼，但我們雇人是讓他們來告訴我們該做什麼。」他說 TBD 和 MSL 的核心就是雇最厲害的研究員，然後給他們最好的環境去做畢生最好的研究，不是來指揮他們的。

9. MuseSpark: 開胃菜，不是主菜

Wang 對 MuseSpark 的定位非常明確: 這只是「開胃菜」，不是「主菜」。

過去九個月做的事情其實是全面翻新整個研究基礎設施: 重建預訓練堆疊、重建強化學習堆疊、重整科學和資料。MuseSpark 是這個全新堆疊上的第一個數據點，但他們對後面更大的模型興奮得多。

有趣的是，MuseSpark 的整體表現比預期好不少，還出現了一些沒有預料到的湧現能力，例如能生成網站和遊戲的視覺化程式碼能力。這不是刻意訓練出來的，而是多模態能力加上 agent 能力之後自然冒出來的。

但 Wang 也很坦白: MuseSpark 在 agentic coding 上還沒有競爭力，他們一開始就沒有期望它在所有面向上都是最頂尖的。這是下一批模型要解決的事。

問他什麼時候能看到真正的前沿模型? 「未來幾個月。」聽起來從全面打地基到進入快速 scaling 模式的轉折點，現在才剛到。

10. 乾淨堆疊帶來的 token 效率

Vance 說他上節目前把 MuseSpark 丟進各種 AI 系統讓它們分析，反覆出現的關鍵詞是「token 效率」。在 Artificial Analysis 基準測試上，MuseSpark 用明顯更少的 token 就能達到跟其他模型差不多的結果。問這是刻意為之還是意外?

Wang 說這是他們蠻興奮的發現，歸因於從零開始建「乾淨堆疊」的優勢，由最懂的專家用正確的方式蓋起來，沒有歷史包袱。他暗示其他模型需要更多 token，可能是因為堆疊的其他環節有根本性的低效率，然後靠讓模型多想一會兒來彌補。

小編覺得這個觀點蠻值得記住的。很多時候我們看到某個模型需要更長的思考鏈才能解題，可能不完全是因為問題本身難，而是底層有些技術債在拖後腿。如果隨著 scaling 這個效率優勢能維持，對 Meta 後續模型的成本結構會很有利。

11. 可預測的多軸 scaling

Wang 強調整個計畫的核心設計是圍繞「可預測的 scaling」，而且是在多個軸上同時看到:

• 預訓練 scaling
• 強化學習 scaling
• 推論時 scaling
• 多 agent scaling

特別是多 agent scaling。MuseSpark 的「深思模式」用 16 個 agent 協作，背後就是這個方向的早期成果。Wang 把整個進程描述為一個 scaling 階梯: MuseSpark 是第一個台階，下一個台階他們更興奮，再下一個更興奮。整個計畫就是為了能持續往上爬而設計的。

12. Ray-Ban Meta 眼鏡與裝置星座

MuseSpark 在視覺基準測試上表現特別好，Kylie 問這跟 Meta 的硬體策略有什麼關係。

Wang 提出了一個「裝置星座」的願景: Ray-Ban Meta 眼鏡已經賣出數百萬副，如果 AI 能真正融入這類設備，看到你看到的、聽到你聽到的、在你需要的時刻提供智慧，科技就能退到背景裡。

他描繪的圖像是: 你提到一件事，agent 就自動去做研究; 你不用主動問，它會主動給你有價值的洞見; 它捕捉你生活中的脈絡，知道什麼重要、什麼該注意，成為一個超級智慧的隨身夥伴，讓你生活的方方面面都變好。

13. 「我從來沒按過 WhatsApp 上那個 AI 按鈕」

這段是整場訪談最尷尬（也最真實）的時刻。Vance 坦白: 他是 Meta 生態的重度用戶，用 Ray-Ban Meta 拍影片和接電話、用 WhatsApp 經營整個公司、拒絕用 Slack。但他直到要採訪 Wang 才第一次注意到 WhatsApp 上有個 AI agent 按鈕。他平常做 AI 相關的工作都是跑去用 Claude 和 ChatGPT。

Wang 沒有尷尬迴避，而是把這當成策略來解釋: 他們刻意等到模型夠好了才推大規模整合。「我們知道必須先有好模型和好產品，才能去做更緊密的生態系整合。」現在模型到位了，接下來要做的就是把 AI 編織進 Meta 整個 app 家族，某種程度上就像 Google 過去幾年把 Gemini 整合進各產品的過程。

14. AI 競爭格局: 沒有人已經贏了

Vance 問了一個好問題: 消費者心目中 ChatGPT 就等於 AI，Claude 在 coding 和商業上超強，你們跟 Google 是在要求用戶「順便用一下嵌在服務裡的 AI」，這場競爭到底怎麼打?

Wang 的回答蠻有料的。他說如果一年前坐在這裡，大家會說 OpenAI 和 ChatGPT 已經贏了消費者市場，營收遙遙領先，其他人沒機會了。但一年後呢?

• Claude Code 異軍突起，當初有點可預見但不是那麼篤定，現在已經在營收上超越了 OpenAI
• Gemini 大量分發，實際上吃掉了不少消費者市場份額，包括從 ChatGPT 那裡搶走的

他從中得出一個洞見: 每當 AI 到達新的智慧和能力水準，就會解鎖全新的產品形態。 ChatGPT 是有史以來成長最快的產品和商業模式，直到 Claude Code 出現打破紀錄。下一波會更大，再下一波更大。我們離終局遠得很，還有很多尚未被發明的產品形態，每一個都可能比現有的更大。

小編覺得 Wang 把 ChatGPT → Claude Code 的接力描述成 AI 的內在特質這點蠻有意思的: 不是某家公司特別厲害，而是 AI 能力本身在跳級，每一跳都會催生新的殺手應用。

15. AI 消費者觀感: 還欠一個「Claude Code 時刻」

Kylie 提到一個很真實的觀察: 她身邊的年輕人在 Instagram 上瘋狂轉發「多討厭 AI」的內容，消費者對 AI 的觀感已經觸底了。

Wang 沒有迴避，直接承認消費者對 AI 的感受「非常低，說得客氣點」。他的解釋是: 到目前為止，AI 還沒有真正向大眾證明它是一個「個人賦能的工具」。開發者因為 AI 能做到以前做不到的事情，週末就能完成一整個專案，所以觀感很正面。但對普通人來說，AI 讓生活好了一點，但還沒有到壓倒性的程度。

換句話說，AI 還欠每個普通人一個等同於開發者用 Claude Code 時的那種感覺，一個讓人真正覺得「我的能力被大幅放大了」的產品體驗。同樣的事也還沒發生在中小企業主身上。

Vance 補了一刀: 你去美國任何小鎮的餐廳看他們的網站，大概停在 2002 年。你現在要給這些人多 agent 架構的產品? 聽起來是個巨大的跳躍。而且很多人對 Meta 本身就不太信任。

Wang 承認 Meta 的信任門檻確實更高。他的答案很務實: 最好的回應就是建出真正好的產品。Meta 有數十億用戶和數億中小企業在平台上，很多用 WhatsApp 做生意、有 Facebook 或 Instagram 粉絲頁、用 Meta 的廣告系統。如果能為這些企業建出真正改變他們經營方式的 agent，這是只有 Meta 才有的機會。

16. Agent 經濟 vs 天才國度

這段是 Wang 描述得最具野心的願景。Dario Amodei 常用的比喻是「資料中心裡的天才國度」，一群超強的 AI 在資料中心裡做研究和解決問題。Wang 則說 Meta 要建的是「資料中心裡的 agent 經濟」。

差別在哪? 如果你能為消費者和企業兩邊都建出 agent，然後讓這些 agent 之間能互相協作和交易，就能從根本上改變經濟中的供需運作方式。前者偏研究和知識密集，後者偏雙邊市場和商業生態。

但他也強調，這必須跟取得社會認同同步進行: 要讓人們看到 Meta 確實在乎產品的部署方式，而且真的在讓人們的生活變好。

17. 開源: 還是會做，但安全優先

MuseSpark 沒有開源，這在社群引起不少議論。Vance 問得很認真。畢竟 Meta 就坐在 Sun Microsystems 的舊大樓裡（Sun 曾是開源軟體的旗手），而且 Meta 之前做的 Open Compute Project 也很受重視。開源到底還算不算你們的承諾?

Wang 解釋: 模型比 Llama 時代更強大了，他們在 MSL 建立了一套先進 AI scaling 框架。MuseSpark 在內部安全測試中觸發了一些安全護欄，特別是在生化、網路攻擊能力和失控風險方面。這些都詳細記錄在他們發表的 MuseSpark 安全準備報告裡。

所以 MuseSpark 目前的形式不適合開源。但他們正在開發適合開源的版本，訪談當天 Wang 才剛開過一個會審視這方面的進度。

他的立場很明確: 會繼續開源模型，但最強大的模型必須先考量是否安全到足以開源。

18. 「八卦跟報導的界線，薄得驚人」

被問到媒體報導 Meta 內部的分裂（Wang/Zuck 陣營重研究 vs. Boz/Chris Cox 陣營重產品），Wang 直接開砲:「這份工作教會我一件事: 大媒體的報導門檻，八卦和新聞之間的界線，薄得驚人。」

他說內部沒什麼重大路線對立。大家都知道需要最好的模型來支撐核心業務，也都知道要把模型整合進產品和服務，讓消費者和企業用到最好的版本。Meta 從他來之前就在做商業 agent 了，那些也需要最好的模型。跟任何公司一樣會深入辯論，但沒有什麼嚴重的內鬥。

19. Manus 交易、紐約時報全版廣告與國安

Vance 把兩件事串在一起問: Wang 在 Scale 時代曾在紐約時報刊登全版廣告，警告 AI 在戰爭和國家安全上的重要性，積極在華盛頓遊說美國政府認真看待中國的 AI 威脅。然後轉到 Meta 就跟中國新創 Manus 做交易，這不是自相矛盾嗎?

Wang 先回應了國安廣告的背景: 那個時間點他覺得非常關鍵，必須讓美國政府理解 AI 會帶來國安上的重大變革。他說後來發生的事情（包括 Mythos 等事件）證明那個判斷是正確的。中國共產黨和解放軍一直把 AI 當作有深遠國安意涵的技術來對待，美國政府現在也終於認真對待了。

至於 Manus，他做了一個很重要的區分: 要把人和國家分開。他的父母是中國人，有很多非常優秀的華人工程師和研究員，有些去了新加坡、有些來了美國。跟這些人才合作，不等於認同中共的行動。他批評矽谷（特別是 X 上）對中國議題太缺乏層次，什麼跟中國沾邊的都混在一起談。

Vance 追問: 你沒辦法評論是不是代表事情還在進行中? Wang 只說「我真的沒辦法評論」，暗示交易並非已經結束。

20. 怎麼看 Anthropic 的末日論立場

Vance 直接問: 你覺得 Anthropic 是不是太末日論了?

Wang 的回答蠻有層次的。他說聽 AI 業界的人談 AI 時，要區分「他們確切說的話」和「他們想傳達的核心訊息」。Anthropic 的核心訊息他覺得是合理的: 模型已經非常強大了，而且只會更強大。Wang 認為安全是基本門檻，建超級智慧的同時不認真思考安全風險，是不可能的事。MSL 為 MuseSpark 發表了比 Meta 歷史上都更詳細的安全準備報告，就是這個態度的體現。

21. 機器人: 從數位到物理超級智慧

Meta 收購了機器人 AI 新創 ARI (Assured Robot Intelligence)，做的不是硬體而是各種硬體平台的 AI 軟體。

Wang 的邏輯鏈很清楚: 如果你真的相信超級智慧的時間線很近，那在數位超級智慧之後不久，「物理超級智慧」就會變得極其關鍵。他認為機器人智慧跟數位超級智慧一樣會受益於 scaling，而 Meta 正在建的算力基礎設施如果不拿來做世界模型和物理智慧，幾乎是一種浪費。應用方向包括加速科學發現、改善製造、以及更貼近日常的，讓機器人讓所有人的生活變得更輕鬆。

Kylie 問了一個很辣的問題: 大家會不會想到 Metaverse 那個「沒有腿」的尷尬事故? Meta 做機器人的公信力夠嗎? Wang 的回答是: 如果因為過去的事情就不敢起床做事了，那就什麼都不用做了。他相信只要產品做得好、部署得謹慎，人們會接受的。

22. 模型福祉

這是訪談最出人意料的段落。Wang 主動提起，還先打預防針:「有些人可能會罵我提這個。」

他的論點是: 人類關心我們如何對待植物、動物、其他人，那在 AI 模型已經成為我們深層工作夥伴的今天，思考「我們是否應該善待模型」、「模型是否具有道德份量」是合理的。他提到已經有辦法測量模型的主觀體驗，而且 Meta 已經聘請了哲學家來研究這個方向。

他認為這是一個嚴重被低估的議題: 考慮到科技圈的人現在每天多深度地跟 AI 模型協作，它們真的已經是我們的工作夥伴了，但幾乎沒有人在認真討論這件事。

23. 關鍵路徑: 超級智慧、機器人、腦機介面

訪談尾聲，Vance 問 Wang 哲學上跟其他前沿實驗室的領導人有什麼不同。他指出自己大概知道 Dario 的立場、Elon 的方向、Sam 的想法、Demis Hassabis 的科學路線，但 Wang 一直是個謎。

Wang 先給出他最核心的信念:「如何在地球上建造天堂? 超級智慧是通往那裡的關鍵里程碑。」

然後列出他認為人類前進的三條關鍵路徑技術: 超級智慧、機器人、腦機介面 (BCI)。而放眼未來會無限擴展的東西，是能源、算力和機器人。

Vance 說 Elon 在這三個方向上的投入比誰都大。Wang 的回應是: 他跟 Elon 最大的差異在於，他認為研究的順序非常重要。建超級智慧本質上是一個研究活動，在知識的戰爭迷霧裡靠做實驗來一步步探索和推進，不是砸最多算力就能直接到達終點的。先後順序很重要。

整場訪談聽下來，Wang 不像 Sam Altman 那樣喜歡對外描繪 AI 的宏大願景，不像 Dario Amodei 那樣花大量時間公開辯論 AI 安全的哲學問題，也不像 Elon Musk 那樣靠速度和規模硬碾過去。他比較像一個工程導向的管理者: 先搞清楚問題在哪、把基礎設施建對、找對的人放在對的位置，然後讓他們去做研究。不急著對外宣傳，等東西做出來再說。

但這場訪談也讓人看到他務實之外的另一面: 他主動聊模型福祉、聊腦機介面、聊「如何在地球上建造天堂」，想的比多數人預期的更遠。至於 MSL 最後能交出什麼成績? 他自己說得很明確: 用作品說話。那就等著看吧。

Cedric Chin 最近在他的 Commoncog 上發布了一個 Sensemaking Series，三篇文章系統性地處理這個問題: 在快速變動的環境裡，你到底該怎麼「看懂」正在發生什麼? 他自己在推文中也說這是「Commoncog 今年對 AI 討論最重要的貢獻」。

Sensemaking 這個詞沒有很好的中文翻譯，直譯是「意義建構」，但更白話地說，就是「在混亂的資訊中搞清楚到底發生了什麼事，跟我有什麼關係」的能力。不是預測未來，而是看懂現在。

先介紹一下作者: Cedric Chin 是新加坡的商業寫作者，經營 Commoncog 多年，專門寫「如何從實務中學習」的主題，強項是把認知科學研究轉化成商業人士能用的思考框架，在歐美獨立寫作圈蠻有影響力的。

這個系列雖然用 AI 當案例，但 Cedric 說骨子裡講的是一套判斷方法論: 當快速變動的事件（不管是技術、社會還是地緣政治）可能影響到你的事業和職涯時，這套方法可以幫你判斷什麼該關注、什麼該忽略。以下摘幾個小編覺得最有料的觀點:

第一篇: 停止消費預測，專注「實戰報告」

📎 How to Make Sense of AI

Cedric 的核心論點很直接: 你該忽略幾乎所有的 AI 觀點文和預測文。 不管作者多聰明、文筆多好、論證多嚴密，預測就是預測，歷史反覆證明，即使是最頂尖的人也預測不準技術變革的走向。

那該看什麼? 他的答案是「詳細的使用實戰報告」。不是「AI 將改變世界」那種大敘事，而是「我花了六個月建了一套自主程式碼產生器，踩了這些坑，學到這些事」這種東西。至於那些夾帶在實戰報告裡的主觀意見? Cedric 說得很直白: 把它們當成「朋友嗑了 LSD 之後的喃喃自語」就好，聽聽就算了，不用當真。

編按: 他舉的例子包括 Sam Schillace（微軟副技術長）關於自主 coding 團隊的報告、Vaughn Tan 提出的「無聊小工具」(boring tiny tools) 概念、以及 Craig Mod 用 AI 做軟體開發的詳細記錄。

但光是「看實戰報告」還不夠，Cedric 強調整套方法的底層有一個前提: 結果導向。每次閱讀或行動之前，先問自己「我想達成什麼結果?」這個問題決定了你的注意力該放在哪裡，也決定了哪些報告值得你花時間。

讀到實戰報告之後，Cedric 建議問自己四個問題:

1️⃣ 這份報告暗示了什麼新的可能性? 例如「原來不會寫程式的人也能用 AI 做出實用小工具了」

2️⃣ 基於這些可能性，我可以採取什麼行動? 例如「花幾天實驗看看能不能用 AI 做一個自動化報表工具」

3️⃣ 這些可能性對我的具體處境有多大價值? 這會因人而異，對一個小公司老闆和一個大企業工程師，答案完全不同

4️⃣ 背後的因果關係是什麼? 例如「為什麼 TDD 和 CI/CD 這些傳統軟體工程實踐，在 AI 時代反而更重要了?」

這四個問題設計得蠻精巧的，它強迫你把抽象的資訊轉化成跟自己處境相關的判斷和行動。不是在吸收知識，而是在做判斷。

Cedric 還點出一個蠻尖銳的觀察: 讀別人的觀點文有真實的機會成本。 你花在消費預測的時間，就是你沒有花在實際動手實驗的時間。在技術快速變動的時候，自己動手得到的第一手認知，遠比讀一百篇分析文有用。

他也建議做「集體判斷」: 找一群同行建群組，專門分享實戰報告，大家各自根據四個問題來判斷對自己處境的意義。這比一個人悶著頭看文章有效多了，不同背景的人會注意到不同的訊號。

第二篇: 專家和新手的差異不在認知能力，而在「框架」

📎 How Experts Sensemake

第二篇引入了理論基礎: Gary Klein 等人為美軍開發的「資料-框架理論」(Data-Frame Theory of Sensemaking)。這個理論的核心概念是:

人靠「框架」來組織資訊。 框架決定了你怎麼解讀資料、什麼資料重要、什麼資料可以忽略。沒有框架，資料就只是噪音。

理論描述了四個循環:

🔹 基本循環: 用幾個「錨點」數據建立框架，再用框架去評估新資料

🔹 精緻化循環: 主動找更多資料來豐富現有框架

🔹 保守循環: 碰到不符合框架的資料時，選擇維持現有框架（這看起來很像確認偏誤，但 Cedric 認為事情沒這麼簡單）

🔹 重構循環: 當現有框架實在撐不住了，建構全新的替代框架

這裡最有意思的發現是: 專家和新手用的是完全相同的流程。 差別不在認知過程，而在專家擁有更豐富的「因果心智模型」。他們對領域裡事物運作的方式有更深的理解，所以能建構出更好的框架、更快發現異常、更快知道該怎麼行動。

Cedric 在推文中還特別點出: 很多人主張用貝氏更新來改善判斷，但資料-框架理論提供了不同的思路。判斷的核心不是不斷修正機率估計，而是建構和切換框架。

他也挑戰了一個常見觀念: 很多人覺得「確認偏誤」是一種認知缺陷，但 Klein 的研究發現，專家在精緻化替代框架時，刻意去找確認證據反而能產生更好的結果。換句話說，「看起來像確認偏誤的行為」其實可能只是用框架在引導資訊搜尋。關鍵不在於你有沒有偏誤，而在於你的框架夠不夠好。

原文還有一個更強的主張值得注意: 沒有正確的框架，你連「資料」都看不見。 傳統的分析模型假設資料會自然呈現、分析師只需要整理和解讀，但資料-框架理論認為資料是被框架「建構」出來的，框架決定了什麼算資料、什麼被忽略。這對所有依賴 AI 做決策輔助的人來說都是個重要警示。

他用 Walmart 的案例做了精彩的示範: 當年 Walmart 的競爭對手也都在導入電腦化，但 Walmart 用資訊技術「重構了組織的決策方式」，讓門市和供應商能根據即時數據做去中心化的決策。技術本身不是護城河，用技術重塑組織結構才是。這個邏輯放到 AI 時代一樣成立。

第三篇: 三個讓你判斷力升級的實用技巧

📎 How to Improve at Sensemaking AI

第三篇把理論變成方法，提出三個具體做法:

技巧一: 平行持有多個框架

最危險的不是持有「錯的」框架，而是只持有「一個」框架。Cedric 稱之為「框架固著」(frame fixation)，你太相信自己的解讀方式，以至於看不見其他可能性。

解法: 不需要放棄你現在的框架，但同時建構一個替代框架。 他用軟體工程界對 AI coding 的爭論來示範:

• 「拒絕 AI」派: 基於倫理或技術理由拒絕 AI 工具
• 「務實採用」派: 整合 AI 但維持既有的軟體工程實踐
• 「全自動工廠」派: 相信 AI agent 可以在極少人類介入下自主產出、審查和部署程式碼

你不需要相信全自動工廠的框架，但你應該「知道它存在，並理解它建立在哪些假設上」。平行持有替代框架，讓你在現實發生變化時能更快轉換，而不是被打個措手不及。

AWS 的 Marc Brooker 就說過: 「我們職業生涯中發展出來的許多直覺法則，現在已經不正確了……這是我職涯中見過最大的變化。」這種來自資深工程師的觀察，就是你框架需要更新的訊號。

他提到一個觸發自己重新思考的轉折點: 一位資深工程師問了一句「程式碼現在很便宜了，這會改變什麼?」這個問題動搖了一個核心錨點，當錨點鬆動，框架就有了重構的空間。

編按: 他拿雲端運算的歷史做對照。當「伺服器是昂貴且獨特的」這個錨點被「伺服器是便宜且可拋棄的」取代之後，整個產業的基礎設施實踐就徹底翻轉了。基礎設施即程式碼、自動擴展、Netflix 的 Chaos Monkey 都是在新框架下才會出現的東西。

技巧二: 把「觀點文」當作框架偵測工具

有趣的是，第一篇叫你忽略觀點文，第三篇卻說觀點文其實有用，但用法不一樣。不是去看結論對不對，而是反向推導: 這個作者是在什麼框架下思考的? 他的錨點假設是什麼?

比如有人堅持「規格先行的開發方式行不通」，有人卻說「規格驅動開發配合 AI agent 效率超高」。觀點相反，但兩邊都不是傻子。差異在於他們操作的框架不同: 一個把規格視為「本質上比程式碼更難寫清楚的東西」（引用 Dijkstra），另一個把規格視為「讓 AI agent 自主運作的地圖」。當你把觀點文當成框架偵測器，你就不是在消費意見，而是在擴充自己的框架庫。

技巧三: 收集歷史「碎片」來校準你的預期

Cedric 建議收集 10 到 20 個「技術變革實際上是怎麼發生的」歷史案例。不是宏大敘事，而是具體的: 哪些公司因為新技術贏了或輸了? 技術擴散的實際時間軸是什麼? 有哪些反直覺的社會影響?

他舉了一個很好的例子: 汽車剛出現的時候，馬的數量反而增加了。這跟「新技術立刻取代舊技術」的直覺完全相反。這種歷史碎片的價值在於校準你對「變革實際上長什麼樣子」的預期，通常比想像中更慢、更亂、更出人意料。

社群迴響和一些值得思考的反面觀點

這個系列在社群上的迴響相當正面。Tom Morgan（Leading Edge Newsletter）稱讚它「在混亂世界中非常實用」；多個 Substack newsletter 推薦轉載（#257、Food for Agile Thought）；也有人直接把核心框架整理成實作指南；Commoncog 論壇上則有讀者延伸討論資料-框架理論跟其他認知科學派別（如捷思偏誤研究）之間的互補關係。

不過也有一些值得思考的反面角度:

🔸 「完全忽略預測」是不是太極端? 有人認為應該結合人類的詮釋性推理和 AI 的模式辨識能力，而不是二選一。尤其在高風險領域，完全不看預測可能會錯過有價值的模式。

🔸 平行持有多個框架的認知負擔: 有讀者指出，在快速變動的環境中同時維持多個框架是很累的事。值得注意的是，原文也有提到專家通常最多平行持有兩到三個框架，超過這個數量決策表現反而會下降，所以這不是「越多越好」，而是要有策略地選擇。

🔸 實戰報告本身也有偏差: 實戰報告不是客觀真相，它是某個人在某個特定情境下的主觀經驗。有成功偏差（失敗的人比較少寫文章）、有情境偏差（在某個組織有用的東西換一個地方未必有用）。Cedric 在原文中也強調，讀實戰報告時要考量作者的背景、使用情境和目標，讀完後更要自己動手驗證，不是照單全收。

這些反面角度不見得推翻 Cedric 的框架，但它們是有用的補充。

小編的觀察

小編覺得這個系列最大的價值，不是告訴你「AI 會怎樣」，而是教你一套面對不確定性時如何思考的方法。這在 AI 領域尤其重要，因為這個領域變化太快，任何具體的技術判斷可能幾個月就過時了，但「怎麼做判斷」的元能力是持久的。

Cedric 用 Walmart 案例點出的那個洞見也值得再強調: 技術本身不是競爭優勢，用技術重構決策方式和組織結構才是。大家都能導入 AI，但怎麼用 AI 來改變你做決策的方式，這才是真正的差異化所在。

如果你也覺得自己花太多時間在「消費 AI 資訊」而不是「理解 AI 對自己處境的意義」，這三篇很值得花時間讀一遍。

作者 Nathan Lambert 是 AI2（Allen Institute for AI）的研究員，也是 The ATOM Project 的主持人，同時是即將出版的 RLHF Book 的作者，對後訓練技術有很深的第一手理解。

ATOM 值得特別介紹一下。這個計畫 2025 年八月啟動時發了一份被 Lambert 自己稱為「宣言」的備忘錄，核心主張是美國需要認真投資開源模型。到了 2026 年四月，他們發表了配套的技術報告，追蹤了大約 1,500 個主要開源語言模型，累計超過 30 億次下載（2023 年 11 月至 2026 年 3 月）。報告用四個維度衡量生態: HuggingFace 下載量、衍生模型數量、推論市場份額（OpenRouter）、以及效能指標。結論很明確: 中國模型在 2025 年夏天超越美國成為下載量最大的來源國，年增率 11.9 倍; 到 2026 年 3 月，Qwen 累計下載 9.42 億次，是 Llama 的將近兩倍; 中國模型在 OpenRouter 上佔了 72.7% 的 token 份額。開源模型的歷史被劃分為三個階段: 歐洲主導（Mistral 時代）→ 美國主導（Llama 3 時代）→ 中國主導（DeepSeek V3/R1 + Qwen3 時代）。

ATOM 最有意思的工具是 RAM（相對採用率指標）: 它把模型的下載量按照發布時間和模型大小做標準化，讓不同時期、不同大小的模型可以放在一起比。RAM > 1 表示這個模型有望進入該大小類別的歷史前十名下載量。Lambert 說這個指標「把一團混亂的生態濃縮成一個容易解讀的數字」。在大家都在吵評測分數的時候，ATOM 提供了一個從實際採用率角度看開源模型的窗口——這個視角目前幾乎沒有其他人在做。

Interconnects 的獨特之處在於: Lambert 不只是在做技術評論，他同時橫跨了技術、地緣政治、商業模式三個維度來觀察開源模型。2026 上半年他寫了一系列非常密集的文章，從二月到五月幾乎每週都有重量級分析——包括開源閉源的效能差距、蒸餾爭議、中國實驗室訪談、開源生態的複利效應、Gemma 4 評估等等。

以下整理出幾個最重要的主題和洞見。

一、開源 vs 閉源的差距到底多大? 答案比你想的複雜

這可能是 2026 年 AI 圈討論度最高的話題之一。很多人喜歡用 Artificial Analysis Intelligence Index 這種綜合評測的單一分數來量化差距，但 Lambert 在 Reading today’s open-closed performance gap 中指出，這種做法遮蓋了太多重要的細節。

🔹 差距大約是 6-18 個月，穩定但更可能拉大。 Lambert 在多篇文章中反覆論證: 開源模型一直落後閉源最前沿大約 6-18 個月，而且考慮到 Anthropic、OpenAI、Google 手上的資源（算力、資料、人才）是開源陣營的 10 倍以上，這個差距能維持這麼小本身就很驚人。但他判斷差距更可能擴大而非縮小。

為什麼? 理由有好幾層:

• 前沿任務正在往更專業的領域發展。 法律、醫療、會計這些高門檻領域的訓練資料不在公開網路上，而且需要昂貴的強化學習環境來訓練。閉源實驗室花「天文數字」買這些資料和環境，開源模型很難複製。
• Agent 時代讓蒸餾變更難。 以前你可以直接拿閉源模型的輸出來訓練，但現在最關鍵的是複雜的強化學習環境和提示詞設計，這些比模型輸出更容易藏起來。
• 閉源模型在「難以衡量的品質」上仍然領先。 特別是穩健性和一般性的好用程度，這些不容易被評測捕捉到。實務上常見的狀況是: 用開源模型跑 agent 得比用 Claude 或 Codex 更頻繁地重置上下文。

🔹 評測的可信度正在下降。 Lambert 觀察到一個弔詭的現象: Gemini 3 拿到「不可思議的評測分數」，但在 agent 實際部署場景裡卻「顯得格外無關」。他直言，在後訓練技術快速演進的時代，他對評測的信心處於「相對低點」。

2026 五月的 Open Artifacts #21 更進一步呈現了這個爭議: 美國 NIST 下的 CAISI 用 IRT 方法分析 DeepSeek V4，結論是差距正在擴大; 但 Epoch AI 的 ECI 指標卻顯示差距自 R1 以來一直穩定在 3-7 個月。兩個結論完全相反。

Interconnects 團隊的 Florian Brand 和 Lambert 本人也有分歧: Florian 認為開源模型在真實效能上比評測顯示的更接近閉源模型; Lambert 則認為閉源模型領先的幅度比 Florian 想的更大。

小編覺得這個「團隊內部公開唱反調」蠻健康的——至少讓讀者知道，即使是最接近資料的人，判斷也沒有共識。

二、蒸餾: 沒你想的那麼重要，但恐慌很危險

2026 年二月，Anthropic 點名指控 DeepSeek、Moonshot AI、MiniMax 三家中國實驗室透過約 24,000 個假帳號、超過 1,600 萬次對話來「蒸餾」Claude。這件事在業界炸開了鍋。

Lambert 在 How much does distillation really matter 做了非常細緻的分析:

🔹 DeepSeek 的 15 萬次對話影響可忽略不計。 在訓練語言模型的量級裡，15 萬筆資料「只是抓個表面」。但 Moonshot 和 MiniMax 合計的對話量換算成 token 大約是 1,500-4,000 億，這個量級「確實可能有意義地改善後訓練」。

🔹 蒸餾的效果其實很「鋸齒狀」。 直接拿老師模型的輸出來訓練學生模型並不簡單——研究社群已經看到很多案例，某些老師的輸出反而會讓學生模型變差。這本質上是一個研究問題，不是複製貼上就能搞定的。

🔹 強化學習時代限制了蒸餾的價值。 這是 Lambert 認為最被低估的因素: 在大規模強化學習訓練的時代，你需要模型自己產生策略內的生成——這些生成佔了訓練中的大部分算力成本，而且不能用別的模型的生成來替代。換句話說，即使你拿到了 Claude 的輸出，你還是得靠自己的算力讓模型從自身的生成中學習。

到了五月，Lambert 在 The Distillation Panic 更直接地警告: 把這些行為叫做「蒸餾攻擊」是個危險的用詞。他的論點是，這些中國實驗室真正在做的是越獄和濫用 API，不是蒸餾本身有問題。蒸餾是整個 AI 產業的標準作法——Nvidia 的 Nemotron 蒸餾了中國開源模型，AI2 的 OLMo 蒸餾了多個閉源和開源模型，xAI 在法庭上也承認蒸餾了 OpenAI。

編按: Elon Musk 在 OpenAI 訴訟案中被問到 xAI 是否有蒸餾 OpenAI 的技術，他的回答是:「一般來說 AI 公司都會蒸餾其他 AI 公司。」被追問「這算是承認嗎?」他說:「某種程度上。」

Lambert 最擔心的不是蒸餾本身，而是這個恐慌可能引發的監管連鎖反應: 美國國會正在推動 H.R. 8283 法案、行政命令也在施壓——如果最終結果是有效禁止所有由「曾經蒸餾過閉源 API」的組織開發的開源模型，受傷最深的會是西方的學術界和小型開源貢獻者，而不是中國實驗室。因為中國實驗室「很可能還是會繼續做」。

他引用了 Kevin Xu 的一個很有意思的戰略論點: 如果中國公司一直依賴蒸餾當捷徑來接近前沿，他們永遠不會真正學到獨立領先的技術。美國切斷這個「拐杖」，短期會拉開差距，但長期反而可能逼中國發展出更獨立的能力——這跟半導體出口管制的辯論邏輯一模一樣。

三、中國實驗室: 從內部看到了什麼

Lambert 在 2026 年四月親自去了一趟中國，36 小時內拜訪了 Z.ai、Moonshot AI、清華、美團、小米、01.ai。他在 Notes from inside China’s AI labs 寫下了一些非常第一手的觀察:

🔹 文化優勢在於「執行力」而非「創新力」。 中國實驗室的核心貢獻者有很大比例是在讀的研究生，跟美國頂尖實驗室（OpenAI、Anthropic、Cursor 等根本不提供實習）完全不同。學生文化帶來四個優勢: 更願意做不起眼但必要的工作、個人英雄主義少讓組織更好擴展、新鮮視角能更快適應新技術、充沛人才適合解決已有概念驗證的問題。

🔹 中國研究員對 AI 的「哲學問題」幾乎沒有興趣。 當被問到經濟或長期社會風險時，他們的態度很直接: 這些問題跟我無關，我的工作就是把模型做好。Lambert 形容一位他遇到的研究員把這類問題當成「範疇錯誤」。一位研究員引用了 Dan Wang 的觀點: 中國是工程師在管理國家，美國是律師在管理國家。Lambert 後來也補充修正了自己的觀察: 這種務實態度不只是個人選擇，也跟他們成長的體制有關——在一個不鼓勵對社會結構發表意見的環境裡，專注技術本身是更自然的選擇。另外，中國也沒有像 Dwarkesh 或 Lex 這類讓科學家變成「明星」的媒體管道，科研人員沒有系統性地建立個人影響力的路徑。

🔹 幾乎所有中國 AI 開發者都用 Claude 來寫程式。 這可能是整篇文章最讓人意外的發現——儘管 Claude 在中國名義上是被封鎖的。Lambert 說他訪問的每個人都提到在用 Claude。這也側面說明了中國的 AI 推論需求可能比按 SaaS 市場規模去推算的要大得多——中國的 SaaS 支出歷來很低，但雲端市場本身是龐大的。Lambert 認為 AI 的企業支出更接近雲端市場的邏輯，而非 SaaS 市場。

🔹 Nvidia 晶片依然是黃金標準。 訓練端大家都缺 Nvidia 的卡，有供應一定買。華為等替代方案目前只在推論端被正面提及。

🔹 中國的資料產業品質落後，但「自己造」的文化很強。 美國實驗室花千萬美元買單一強化學習環境，中國實驗室覺得國內資料產業品質不夠好，很多東西得自己造。研究員本人會花大量時間打造訓練環境。更大的公司如字節跳動和阿里巴巴則有內部的資料標註團隊。

🔹 每家中國科技公司都在自建 LLM——這在美國幾乎不可思議。 美團做外賣的、小米做手機的，都在訓練自己的通用語言模型。在美國，同等規模的公司只會去買 API 服務。驅動力是一種「深層的渴望去控制自己的技術堆疊」: 微調能強化自家的技術底盤、內部版本服務自家產品、開源版本則從社群拿回饋。這種「開源優先」的心態主要是出於實用主義，不是什麼開源理想。

🔹 中國 AI 產業更像是「生態系」而非「部落戰爭」。 Lambert 觀察到中國實驗室之間的氛圍是「充滿對同行的尊重」，跟美國實驗室私下見面時「火花四濺」的風格截然不同。所有人都敬畏字節跳動/豆包的實力（中國唯一的前沿閉源實驗室）、尊重 DeepSeek 的研究品味（但認為它的組織不適合在經濟上贏）、認為阿里巴巴憑資源最終會贏得大部分市場。

四、開源生態的複利效應

Lambert 在五月的 How open model ecosystems compound 提出了一個精妙的分析框架:

🔹 訓練前沿模型的算力，80% 花在研發而非最終訓練。 這個數字來自 AI2 的 OLMo 3 開發紀錄和 Epoch AI 對各大實驗室的成本研究。大眾對 AI 模型成本的印象一直被誤導——以為錢主要花在最終那一次大規模訓練上，但實際上絕大部分算力花在實驗、測試、調參這些研發過程。

這個發現的意義在於: 在中國這種所有領先玩家都開源的生態裡，大家可以迅速從同行的研究中學習，避免重複浪費研發算力。這就是為什麼中國的開源模型生態有「複利效應」——每一家實驗室發表詳盡的技術報告，等於在幫其他實驗室降低風險，讓他們不用獨立投入同樣的資源。

🔹 但開源 AI ≠ 傳統開源軟體。 Lambert 很小心地做了區分: 傳統開源軟體有一個從使用者到開發者的回饋循環（Linus’s Law:「只要有夠多雙眼睛，所有 bug 都很淺顯」）。但開源 AI 幾乎不存在這個回饋循環——幾乎所有成本都落在模型開發者身上。開源 AI 模型是「降低未來開發成本的工具」，不是即插即用的解決方案。如果你只是拿來用、不做任何迭代，用開源模型幾乎一定比用閉源 API 更貴。

五、誰還在做開源? 商業模式的困局

Lambert 在多篇文章中反覆提到一個越來越緊迫的問題: 願意釋出前沿開源模型的玩家正在減少。

🔹 Meta 已經在轉向。 Meta 的 Llama 曾經是開源模型的代名詞，但 Lambert 在 The inevitable need for an open model consortium 中指出，Meta 正在把重心從 Llama 移開。ATOM 報告的數據讓這個趨勢更加觸目: Llama 在 OpenRouter 的推論份額從 2025 年 1 月的 37.4% 高峰一路跌到 2025 年 8 月的 0%; 衍生模型佔比也從 44% 的巔峰掉到 11%。Llama 團隊內部的政治紛爭據傳已經讓組織承受巨大壓力。更根本的問題是: 當模型成本從一億美元往一兆美元走，Meta 當初「用免費模型來把互補品商品化」的邏輯就越來越站不住腳。Lambert 直言:「歷史上從來沒有人用一兆美元的東西來做這件事。」

🔹 Qwen 也出現動搖。 阿里巴巴 Qwen AI 部門的負責人辭職了。Lambert 說他「不太意外」，因為「到了某個時間點，很多開源模型的努力會因為太貴、太同質化而死掉」。Qwen 是目前開源生態裡最接近社群的模型家族，也是研究方法和資料集的事實標準——如果 Qwen 的方向改變，影響會非常大。

🔹 中國新創也看起來搖搖欲墜。 Moonshot AI、MiniMax、Z.ai 這些靠開源模型打出知名度的中國新創，Lambert 判斷它們「在財務上看起來很不穩定」，因為「公開釋出最強模型」和「把資源集中在能產生營收的 AI 產品上」之間存在根本矛盾。經濟壓力會逼它們把開源模型的重心移往能獲利的方向——更小、更垂直的模型，而非前沿通用模型。

🔹 只有 Nvidia 有明確的經濟動機做開源。 Nvidia 釋出開源模型是為了賣更多 GPU——讓更多人在開源模型上建構應用，就需要更多 Nvidia 的硬體。他們的 Nemotron 3 Super 也確實表現亮眼。但 Lambert 指出即使 Nvidia 的立場長期來看也不穩定: 如果 Nemotron 太成功會威脅到最大客戶; 如果前沿實驗室開始自研晶片（2031 年左右），Nvidia 的現金流可能受壓; 更極端的情況是 Nvidia 自己決定不賣 GPU、留著算力來訓練閉源模型。

🔹 開源模型至今沒有可行的商業模式。 Lambert 在跟 Dean Ball 的對談中坦承:「如果模型真的被商品化，情況看起來蠻慘的。」他對 Reflection AI 那種「做一個超強開源模型，然後賣本地部署」的模式也不看好，因為「本地部署跟閉源模型的商業模式沒有本質區別」。那怎麼辦? 他的想法是「嘗試一堆小的不同方向，搞清楚私有資料在哪些部署場景裡真正有差異化，然後跟社群一起迭代」。但他自己也承認:「我的實際方法就是去交一個億萬富翁朋友。」

資本主義的邏輯很殘酷: 當前沿模型能帶來的利潤越來越高，「把技術當慈善捐出去」就越不合理。這就是為什麼 Lambert 認為一個由多家公司共同出資的聯盟最終是不可避免的——很多公司願意付訓練成本的十分之一甚至五十分之一來參與，換取某種程度的方向影響力和早期存取。Yann LeCun 甚至認為未來會是某種「全球聯盟聯合建造」的模式，因為沒有任何一個國家能獨自擁有它。

🔹 授權趨勢往 Apache 2.0 收斂是好消息。 在一片悲觀中，2026 年最值得注意的正面趨勢是 Google 的 Gemma 4 和小米的 MiMo 2.5 Pro 都採用了 Apache 2.0 授權。Lambert 甚至鬆了一口氣說:「那些可怕的 Llama 授權和 Gemma 使用條款是大約 18 個月的過渡期。」Apache 2.0 消除了企業法務的不確定性，對推動採用至關重要。

六、權重只是系統的一部分——開源的結構性劣勢

這是 Lambert 在 What comes next with open models 和跟 Dean Ball 的對談中反覆強調的一個觀點: 現在的 AI 不只是模型權重，而是一個完整的系統: 權重 + 工具 + 整合介面。

他的問題很尖銳: 你上一次被「純粹的自迴歸逐字輸出」驚艷到是什麼時候? 除了數學證明或競賽程式碼，這件事從 GPT-4 發布以來就沒什麼變化了。我們今天用的 AI 系統——Claude Code、Codex、Cursor——它們的價值遠遠超出模型權重本身。搜尋工具、程式碼沙盒、檔案系統整合、使用者介面，這些都是系統的一部分。

這對開源模型意味著什麼?

閉源模型有天然的垂直整合優勢。 它們可以把晶片、推論軟體、模型權重、工具和使用者介面從上到下整合在一起。你用 Claude Code + Opus 4.6 或 Codex + GPT 5.4 的順暢體驗，就是這種整合的結果。開源模型必須在各種推論框架、各種工具、各種使用場景裡都能運作——這本身就是一個巨大的挑戰。Lambert 說，跑一個兩兆參數的開源模型需要大約 80 台 H100 的節點、每天十萬美元的算力成本，還需要專業知識才能把它變成一個可用的系統。

Dean Ball 在對談中把這個問題說得更直接: 當 AI 公司最終發展成「用模型設計自己的晶片、設計自己的資料中心、設計自己的後繼模型」的全整合基礎設施公司時，開源要複製這一切「在定義上就是不可能的」。

編按: Lambert 談的垂直整合主要是部署端的整合，但小編覺得這個優勢其實從訓練階段就開始了。最明顯的例子是 OpenAI 的 apply_patch——一種專為 GPT 模型設計的自訂 diff 格式，用來讓 agent 編輯程式碼。OpenAI 的 Codex Prompting Guide 明確寫道:「我們強烈建議使用我們的 apply_patch 實作，因為模型已經被訓練成擅長這個 diff 格式。」指南中還提到，工具的名稱、參數和輸出格式「越接近模型訓練時用的格式，效果越好，因為這樣最接近模型的訓練分佈」。

GPT-5-Codex 更是被描述為「專門為 Codex 環境中的 agentic coding 而優化的 GPT-5 版本」。到了 GPT-5.3-Codex，OpenAI 直接寫:「這是第一個在自身創建過程中發揮關鍵作用的模型」——團隊用早期版本來除錯自己的訓練、管理部署、診斷評估結果; 工程團隊甚至用 Codex 來「優化和調整 GPT-5.3-Codex 的 harness」。模型和整合介面是互相塑造的。

這意味著閉源實驗室不只是在部署時把模型和工具串在一起，而是在訓練時就把模型和自家工具鏈聯合優化。開源模型拿到的只是權重，但閉源模型的權重裡已經內建了對自家工具鏈的深度適配——這是開源模型即使跑分追上也很難複製的結構性差距。

不過也有一個有趣的反面: 中國的 Moonshot AI 和 Z.ai 推出的寫程式方案需求很高，即使模型本身是開源的。「大部分人就是會用便宜的介面加推論服務，而不是自己去搞模型部署。」這暗示了一種可能: 模型開源，但靠服務和整合賺錢。

七、開源模型的下一階段: 從追趕前沿到找到自己的定位

Lambert 在 What comes next with open models 提出了三層模型分類:

第一層: 閉源前沿模型。 Claude Opus、GPT 5.4 這類，主導最強的知識工作和程式碼 agent。

第二層: 開源前沿模型。 Qwen 3.5、GLM-5、Kimi K2.6、DeepSeek V4 等試圖在同一方向競爭的開源大模型。很多場景下表現很好，但在 agent 的穩定性上仍有差距。

第三層: 開源小型專用模型。 Lambert 認為這才是開源模型最大的未被開發的機會。他的願景是: 每個前沿 agent 重複做十幾次的任務，都可以外包給一個小型開源模型，速度快 10 倍、成本低 100 倍。

他舉了一個很生動的例子:「在一個由程式碼 agent 主導的世界裡，我想做的是建造那些 Claude Code 迫切想要作為工具使用的開源模型。」但目前幾乎沒人在認真做這件事——大家都太沉迷於「開源追趕前沿」的敘事了。

Lambert 的核心判斷是: 只要開源生態繼續被定義為「一群模型供應商追趕閉源實驗室」，它就會一直輸。 閉源公司面臨的整合壓力遲早也會來到開源——而且可能更快。開源模型的出路不是追趕前沿，而是解決前沿實驗室不會去解決的問題: 本地部署、隱私場景、作為前沿 agent 的專用工具、以及各種垂直場景的廉價自動化。

八、2026 模型動態: 誰在崛起、誰在掉隊

最後來看看具體的模型動態。Interconnects 的 Open Artifacts 月報是追蹤開源模型生態最好的來源之一，2026 年到目前為止已經出了三期（#19、#20、#21）。幾個值得注意的趨勢:

🔹 GPT-OSS 是 Llama 3.1 以來最受歡迎的美國開源模型。 ATOM 的 RAM 指標顯示它的採用率破表: GPT-OSS 120B 的 RAM 在發布 7 天內達到 20.45×、180 天後仍有 15.35×（RAM > 1 就代表有望進入該大小類別的歷史前十）; 20B 版本累計下載超過 5,400 萬次（Open Artifacts #19）。美國終於又有了一個有影響力的開源模型，雖然它的首發體驗「在可用性方面很糟糕」，但最終還是靠實力贏得了採用。

編按: 不過「最受歡迎」量的是下載量，不是特定場景的能力。從原文的線索來看，GPT-OSS 被提到的具體用途是 Chroma 拿 GPT-OSS 20B 做 agentic search、Nvidia 出了效率優化版做推論——都不是寫程式場景。寫程式場景的代表反而是 Kimi K2.5（Cursor 用它做 Composer 2）和 Qwen（研究生態的事實標準，Lambert 說「無數的研究方法和資料集都是圍繞 Qwen 建立的」）。GPT-OSS 的高下載量更可能來自美國本土企業偏好（迴避中國模型的法務風險）、做各種微調的基底模型、以及研究用途。

那 Gemma 4 呢? Lambert 在四月的 ATOM Report 中提到 Gemma 4「展現出驚人的早期採用數字」，但比 GPT-OSS 晚了一步。更關鍵的是，過去的 Gemma 模型「一直被工具鏈問題和微調後表現變差所困擾」（Gemma 4 分析），社群信任需要時間重建。開源模型的採用不只是評測分數的競爭，更是生態系的慢功夫。

🔹 DeepSeek V3.2 的採用率嚴重不如預期。 ATOM 報告的 RAM 數字很殘酷: V3.2 發布 7 天的 RAM 只有 0.35×、90 天後也只有 0.60×——遠低於「歷史前十」的 1× 門檻。相比 DeepSeek 2025 年早期的爆發，落差非常大。但 DeepSeek V4 Flash（284B-13B）反而是「真正的明星」——這個相對小的模型表現出乎意料地強，比巨大的 V4 Pro（1.6T-A49B）還受歡迎。小而精悍有時候勝過大而全面。

🔹 小米 MiMo V2.5 Pro 的崛起。 從一年前初次登場到現在，小米的模型進步被形容為「驚人」——MiMo V2.5 Pro 已經能跟 Kimi K2.6 和 GLM-5.1 在評測和實際使用上打平。採用 Apache 2.0 授權也幫了大忙。

🔹 開源生態正在從「通用模型爭霸」轉向「垂直場景百花齊放」。 Open Artifacts #20 被作者稱為「這系列寫過最有趣的一期」——不再是 Qwen、DeepSeek、Kimi 的天下，而是 OCR、語音轉文字、RAG 搜尋、機器人控制、數學定理證明、程式碼編輯等各種垂直場景的模型冒出來。這正好呼應了 Lambert 一直強調的方向: 開源的未來在於多樣化和專用化，而不是「一個模型統治一切」。

🔹 「長時程任務」成為新前沿。 Kimi K2.6、GLM-5.1 等多個模型都在強調能跑數小時來完成任務的能力。這跟閉源 agent（Claude Code、Codex）的發展方向一致，但開源模型要在這個維度上追趕，需要的不只是更好的模型，還有更好的工具鏈和推論基礎設施。

九、2026 下半年值得關注的預判

Lambert 在 My bets on open models, mid-2026 列出了 13 個預判，小編挑幾個最有趣的:

• 中國開源實驗室會最先面臨資金壓力，可能在 2026 年下半年就會出現。資金困難會在 3-9 個月後反映在模型能力的軌跡上。
• 美國會在 2027 年初開始慢慢在開源模型的採用指標上收復失地。 代表選手: Google Gemma 4、Nvidia Nemotron、Arcee AI。
• 開源模型的最大未開發市場是「本地 agent」和「個人 agent」。 Lambert 稱之為「暗物質」——巨大的潛力，但目前幾乎沒人在認真做。
• 禁止開源模型在實務上不可能執行。 如果美國禁止超過某個算力門檻的開源模型，其他國家遲早會訓練並公開釋出，反而讓這些模型以更少的監管進入美國市場。

看完之後的一些想法

讀完 Lambert 這半年的系列文章，最大的收穫是: 開源 vs 閉源不是一場零和遊戲，也不該被簡化成一個評測分數的追趕賽。

真正有意義的問題不是「開源什麼時候追上閉源」，而是「開源模型在哪些場景下能提供閉源模型無法替代的價值」——無論是主權 AI 的需求、隱私敏感的本地部署、還是作為前沿 agent 的專用工具。

Lambert 自己也承認他對這件事的前景「越來越迷惘」，形容追趕閉源前沿像是推石頭上山——你永遠在推，但石頭永遠會滾下來。但他同時也說:「我從未如此強烈地感到需要建造開源模型。」

這個矛盾本身或許就是 2026 年開源模型最真實的寫照。

2026/6 更新: 開源與閉源走在不同的指數曲線上

本文發布後，Lambert 在六月初又發表了 Open and closed models are on different exponentials，把前面第五、六、七節談的商業模式和定位問題，整理成一個更完整的經濟論述，小編補充在這裡。

他認為決定開源閉源未來權力平衡的核心是經濟問題: 使用者會不會持續為最頂尖的閉源模型付出高額溢價? 2026 年初已經給出第一個答案: coding agent。過了 Opus 4.5 和 Codex 5.2 這個能力門檻後，使用習慣明顯改變，「人們做這個轉換不是因為懶，而是因為淨產出明顯更高」。依賴 coding agent 工作的人永遠會選最好的模型，不會將就「夠用就好」，Lambert 自己說願意為這些工具付每月 2,000 美元。

🔹 閉源實驗室的商業形態: Apple 加上 Microsoft。 權重、harness、工具、推論基礎設施整合在一起的回報巨大: 一面是賣高度整合、極難複製的技術 (Apple)，一面是向整個經濟體賣高槓桿的訂閱 (Microsoft)。Lambert 預期 5-10 年內 OpenAI 和 Anthropic 的估值會落在 2-10 兆美元，前沿實驗室會變成像今天雲端市場那樣的寡占格局。另一個比較新的論點是 API 業務會衰退: 實驗室遲早會延後把最強模型放上 API，以保護 token 供應、防止蒸餾、把模型留給利潤更高的場景。

🔹 開源模型經濟的總價值反而更大，但由一整疊公司分食。 現在的開源模型在分佈外 (out-of-distribution) 任務上還不夠好，但 Lambert 預期開發者終究會停止在排行榜上追逐 Claude 和 GPT，轉而填補低價格帶的缺口。開源模型天生不整合，要靠多家公司協作提供服務，每一層都有替代品，價格會被壓到大宗商品 (commodity) 等級; 企業的典型用法是找到在特定任務上達到「夠好門檻」的模型，之後就不換了 (因為設置成本很高)。整體市場價值會遠超過 OpenAI 加 Anthropic 的總和，具體圖像是 Together、Fireworks、OpenRouter 和超大規模雲端商上的開源推論佔比穩定上升。

🔹 兩條不同的指數曲線。 這是整篇的核心: 不是誰消滅誰的問題。閉源靠整合，從知識工作的頂端開始變現，已經有 product-market fit; 開源會慢得多，但它追蹤的是 AI 向整個經濟和世界的擴散。Lambert 也澄清「遞迴自我改進 (RSI) 會給閉源實驗室不可動搖的優勢」這類說法被誇大了。

文末註腳蠻有意思: Lambert 說 coding agent 這個詞其實很妙，我們在裡面幾乎不寫程式，它們是因為會寫大量程式碼才這麼有能力的通用 agent。對做 AI 應用的人來說，實際的啟示是: 頂級閉源 agent 和便宜的開源推論不是二選一，而是兩種會同時存在的採購邏輯。

一邊是震撼的裁員數字: Block 砍 40% 員工（4,000 人）、Oracle 裁 30,000 人、Cloudflare 砍 20%、Meta 加 Microsoft 合計裁 20,000 人，全都把 AI 列為主因。Challenger 的報告顯示，AI 連續兩個月成為美國企業裁員的首要原因，四月份佔了所有裁員的 26%。光看這些數字，你會覺得取代論已經成為現實。

但另一邊，反對取代論的聲量也在 2026 年達到前所未有的高度——而且來自業界最有份量的人。更關鍵的是，學術研究數據大量出爐，結論跟媒體營造的恐慌氛圍有很大的落差。

誰在反對?

🔹 吳恩達 (Andrew Ng) 五月中在 The Batch 電子報直接下了標題:「不會有 AI 就業末日 (There will be no AI jobpocalypse)」他的論點蠻犀利的: AI 公司有動機把技術說得很強大（越強大越好賣）、SaaS 公司想把定價從軟體錨定到「取代員工薪資」（員工年薪 10 萬美金，AI 收 1 萬就很合理了吧？）、而企業裁員時拿 AI 當藉口，比承認「疫情時代超額招聘」好聽多了。他預測的不是末日，而是「AI 就業嘉年華」(jobapalooza)——更多 AI 工程職位，以及各行各業因 AI 而轉型的新工作。宝玉的評論蠻到位的:「軟體工程師都快被 AI 工具折騰死了吧? 可現實卻是工程師招聘市場依舊火爆，美國失業率穩穩地停在 4.3%，沒半點要崩的樣子。每一波技術浪潮，最終創造出來的新崗位遠比被幹掉的多得多，這次也不會例外。」

🔹 黃仁勳 (Jensen Huang) 從年初到五月，在不同場合反覆強調同一個框架:「任務 vs. 目的」(task vs. purpose)。AI 自動化的是任務，但工作的目的依然需要人。他在 Business Insider 訪談裡舉了放射科醫師的例子: 十年前 Geoff Hinton 說應該停止訓練放射科醫師，因為 AI 看影像比人強。十年後，美國放射科醫師需求創歷史新高。原因很簡單: AI 讓每個醫師能處理更多影像，醫院服務量上升，反而需要更多醫師。他在三月 GTC 2026 的公開談話更直白:「我們缺百萬名卡車司機、缺千萬名製造業工人。機器人會填補這個缺口，經濟因此成長，成長之後企業會僱更多人——僱更多人管更多機器人、僱更多人管更多 AI agent。」

🔹 Yann LeCun 四月公開反駁 Anthropic CEO Dario Amodei 的「50% 入門職位消失」預測，直接說:「Dario 是錯的。他對技術革命如何影響勞動市場一無所知。」他建議大家別聽 AI 公司 CEO 的預測，去聽 Erik Brynjolfsson、Daron Acemoglu、David Autor 這些真正研究勞動經濟的學者怎麼說。

勞動經濟學家怎麼看?

LeCun 點名的三位學者確實是這個領域最有份量的人。跟 AI 業界大老各執一詞不同，他們手上有的是實際的勞動市場數據:

🔹 Erik Brynjolfsson (Stanford) 自稱「審慎樂觀派」。他團隊的 Canaries in the Coal Mine 研究是目前最有說服力的實證分析之一: 用 ADP 覆蓋美國三分之一勞動力的薪資行政數據，發現 AI 高曝險職業的入門級就業確實在下降（22-25 歲下滑 16%，軟體開發更達 20%），但整體就業沒有下降——中高階職位的需求反而在成長。他的核心框架是區分「自動化」和「擴增」: 同樣的 AI 技術，用來取代人跟用來增強人，對就業的影響天差地別。他在 Observer 訪談提出「AI = Amplifying Intention」——企業選擇用 AI 砍人還是增強人的能力，才是決定就業數字的關鍵。

🔹 Daron Acemoglu (MIT，2024 諾貝爾經濟學獎) 是三人中最謹慎的。他的量化分析估計 AI 目前只能自動化大約 4.6% 的任務，對總要素生產力的貢獻在十年內僅 0.5-0.7%——比業界喊的數字低一個數量級。換算成就業衝擊? 他認為極為有限，因為自動化程度太低，根本不足以造成大規模失業。他在 Fast Company 訪談直言業界的預測是「跟現實無關的垃圾」。他最大的擔憂不是 AI 太強大導致失業，而是企業把太多注意力放在「用 AI 取代人」而非「用 AI 增強人」——走錯方向的社會成本比技術本身更大。

🔹 David Autor (MIT) 的框架最獨特: 他認為 AI 不會讓工作「消失」，但會造成「專業知識的貶值」(devaluation of expertise)。以前需要多年訓練才能做的事，AI 讓新手也能做到七八成，這會壓縮專家的溢價。這也解釋了一個看似矛盾的現象: 為什麼入門級職缺在萎縮，但整體失業率沒有上升——工作沒有消失，而是技能要求在重新洗牌。他同時認為，如果引導得當，AI 反而有機會重建中產階級——他說「AI 如果用得好，可以幫助恢復以中等技能、中產階級為核心的勞動市場結構」，但強調這「不是預測，是一種對可能性的論述」。

Carnegie 的分析把三人觀點歸納得蠻好: 他們的共識是——失業率沒有飆升不代表沒事，真正在發生的是職業結構內部的重組。AI 對勞動市場的影響取決於「怎麼用」而非「技術多強」，而目前多數企業的用法還很粗糙。這跟 AI 公司「我們的技術會取代 X% 的工作」的敘事邏輯完全不同。

2026 裁員潮: 真的是 AI 造成的嗎?

這是今年最值得仔細看的問題。表面上，2026 年科技業裁員跟 AI 的關聯度前所未有: 光是前四個月就有超過 73,000 人被裁，95 家公司。Block 的 Jack Dorsey 說得最直白:「更小的團隊，用我們正在打造的工具，能做更多也做得更好。」Cloudflare CEO 更進一步: 這不是 AI 輔助員工，而是 AI 讓「某些類別的員工不再需要」。

但如果你往下挖，故事沒那麼簡單:

• Block 在疫情前只有 3,835 人，疫情期間膨脹到超過 10,000 人。砍回 6,000 人更像是修正疫情超招，而不是 AI 取代。股價裁員後漲了 23%。
• Oracle 裁 30,000 人，但分析師 H.P. Newquist 直言:「這些裁員跟 AI 的實際應用取代員工幾乎沒有關係。省下來的錢是拿去蓋 AI 資料中心的。」這是「用你的薪水買 GPU」，不是「GPU 做了你的工作」。
• C3 AI 裁 26% 員工，CEO 說是 agentic AI 效率提升。但 Info-Tech Research Group 分析師看完 SEC 申報後直接打臉:「這就是傳統的業務瘦身。一家賣 AI 效率的公司，自己卻因為傳統財務壓力在做重組，蠻諷刺的。」

吳恩達說的「企業拿 AI 當裁員藉口」在這些案例裡得到了蠻清楚的驗證。這不代表 AI 沒有影響，但「以 AI 之名裁員」跟「因為 AI 而裁員」之間有很大的灰色地帶。

AI 生產力悖論: 最被忽略的反證

如果 AI 真的強大到可以大規模取代人類工作，那它應該已經帶來可觀的生產力提升，對吧? 但 2026 年的數據說的是完全另一個故事:

📊 NBER 調查了近 6,000 位 CEO 和 CFO（美、英、德、澳），90% 的企業表示 AI 對生產力和就業「沒有可衡量的影響」。CEO 們平均每週只用 AI 1.5 小時。

📊 Goldman Sachs 分析: 在總體經濟層面，AI 與生產力之間「沒有有意義的關係」。全球 AI 投資超過 4,000 億美元，但 AI 對 2025 年美國 GDP 成長的貢獻僅約 0.2%。

📊 McKinsey 報告: 只有 1% 的企業自認 AI 部署已經「成熟」，超過八成看不到對營收或獲利的實質影響。問題不是 AI 不行，而是大部分企業只是把 AI「釘」在現有流程上面，沒有重新設計工作流。

📊 The Economist 算了一筆帳: 美國總工時中涉及生成式 AI 的比例，從 2024 年底的 4.1% 只上升到 2025 年中的 5.7%。大部分使用只是零散的任務，不是系統性的自動化。

這就是 2026 版的「Solow 悖論」——1987 年 Robert Solow 的經典名言:「你到處都看得到電腦，除了在生產力數據裡。」企業買了工具，但還沒有圍繞工具重新組織工作。MIT 的製造業研究甚至發現，AI 採用初期生產力會先下降，經過調適期後才會上升——典型的 J 曲線效應。

小編覺得這是反駁取代論最有力的論點: 如果 AI 連可衡量的生產力提升都還沒帶來，談什麼大規模取代?

學術研究怎麼說: 勞動市場數據

2026 年出爐的幾份重量級研究，結論出奇一致:

1️⃣ Anthropic 勞動市場研究 (2026.03) — Anthropic 用自家 Claude 使用數據建了「觀察到的曝險度」指標。結論: AI 的實際滲透率遠低於理論能力。 電腦與數學類職業理論上 94% 的任務可被 LLM 加速，實際覆蓋率只有 33%。高曝險和低曝險職業的失業率走勢幾乎沒差異。

2️⃣ Yale Budget Lab (2025.10) — 分析 ChatGPT 發布後 33 個月數據:「更廣泛的勞動市場並未經歷可辨識的擾動。」高、中、低 AI 曝險度的職業分布幾乎沒變。他們持續追蹤到 2026 年三月，結論不變。

3️⃣ 丹麥大型行政數據研究 (芝加哥大學 BFI) — 調查 25,000 名勞工與 7,000 個工作場所，鼓勵使用 AI 的企業與沒使用的企業，在就業人數、早期職涯崗位、員工流動率上沒有顯著差異。結論:「我們的發現挑戰了生成式 AI 即將造成勞動市場擾動的敘事。」

4️⃣ OECD 調查 — 七個國家超過 5,000 家中小企業中，83% 的 AI 採用者表示人力配置沒有變化。多數企業把 AI 用來應對勞動力短缺，而非取代員工。

5️⃣ BCG 分析 (2026.04) — 分析 165 萬個職位，50-55% 的美國工作會在未來兩三年被 AI「重塑」(reshaping)，但只有 10-15% 面臨被「消除」的風險。重塑和消除是兩回事。

但也不能無視的另一面

前面的數據大多指向「總體衝擊有限」。但如果只看總體數據，很容易忽略掉在特定領域正在發生的真實痛。取代論有它站得住腳的地方:

📊 入門級職位在萎縮，而且不只軟體業。 除了前述 Brynjolfsson 團隊的發現（入門級下滑 16-20%），達拉斯聯邦儲備銀行的分析也指出 AI 高曝險行業的就業自 2022 年底以來下滑了 1%，電腦系統設計領域下降 5%，入門級工資成長受到可衡量的壓抑。

📊 職缺數在減少，效應在加速。 世界銀行分析 2.85 億筆美國職缺數據，高替代性職位發布量平均下降 12%，效應逐年加強: 第一年 6%，第三年 18%。IMF 總裁 Georgieva 在達沃斯直言這是「一場海嘯正在衝擊勞動市場」，估計全球 40% 的工作暴露在 AI 影響下，先進國家更高達 60%。

📊 自由工作者市場首當其衝。 Ramp 的企業支出數據是目前最直接的證據: 企業花在自由工作者平台 (Upwork、Fiverr) 的支出比例從 2021 Q4 的 0.66% 暴跌到 2025 Q3 的 0.14%，超過一半原本外包的企業已完全停止。替代比例驚人——每減少 1 美元的外包支出，只需花 0.03 美元在 AI 工具上。Harvard 和 Imperial College 追蹤 200 萬筆自由工作者職缺，ChatGPT 發布八個月內: 寫作類下降 30%、平面設計下降 17%、軟體開發下降 21%。

📊 翻譯業是最早的「煤礦裡的金絲雀」。 CNN 報導，IMF 自己的翻譯部門就從 200 人砍到 50 人。英國作家協會調查顯示 36% 的翻譯人員已因 AI 失去工作，43% 收入下降。一位柏林翻譯者的月接案量從 4 件掉到 1 件，剩下的工作也從翻譯變成「AI 後編輯」，費率從每行 0.80 歐元壓到 0.60。

📊 客服是另一個前線。 Klarna 2024 年宣布 AI 客服取代了 700 名人力，省下 4,000 萬美元。但到了 2025 年，他們悄悄重新招聘人類客服——AI 處理複雜案件時品質明顯下降。從「取代 700 人」到重新招人，Klarna 完美體現了這場辯論的現實: AI 能大幅壓縮常規性工作，但完全取代人往往在品質關卡上翻車。Gartner 調查 321 位客服主管，31% 計劃因 AI 裁員，50% 計劃暫停招聘。

📊 第一線的觀察。 X 上的 Rainier 從電商產業觀察: 代碼變便宜了、交付變快了，很多靠 SOP 的運營崗位正在被自動化。「沒有核心能力的新人不招了。」

這些數據很清楚: 在特定職業、特定技能層級、特定工作型態上，AI 的替代效應已經是進行式。只是這些衝擊分散在不同職業和年齡層，被整體勞動市場的規模吸收了——失去工作的人轉往其他產業，其他部門也在持續創造新職缺，所以總體失業率看起來波瀾不驚。但對身處其中的個人來說，衝擊非常真實。

最耐人尋味的轉折: Amodei 自己改口了

也許今年最有意思的一個信號是: 去年喊得最大聲的人，今年自己轉向了。

Fortune 五月的報導標題說得很直白:「Dario Amodei 去年一整年都在警告 AI 白領大屠殺。現在他正在改變敘事。」在最近的公開場合，Amodei 開始引用「Jevons 悖論」——19 世紀的經濟觀察: 當效率提升時，需求反而會擴張而非收縮。他也提到「Amdahl 定律」: 系統的速度受限於最慢的組件，意味著即使 AI 自動化了大部分任務，剩下的人類瓶頸反而會變得更有價值。

從「50% 入門職位消失」到引用 Jevons 悖論，這個轉向本身就說明了很多。連最悲觀的預測者都在重新校準，因為總體數據沒有支持他的預測。

特別來看軟體工程師: 「不要念資工了」成立嗎?

軟體工程師大概是 AI 取代論裡被討論最多的職業。每隔幾個月就有人喊「不要念資工了」「軟體工程師要消失了」。

其實早在 2024 年六月，當「全球軟體工程師職位雪崩式下滑」的說法在台灣瘋傳時，ihower 就在 Facebook 上提出質疑: 不是只有軟體工程職缺變少，是大部分工作職缺都在下降——因為比較的基準是 COVID-19 時期的泡沫高點，職缺回落是整體修正，不是軟體業獨有的問題。

兩年後的今天，讓我們用 2026 年的數據重新檢驗: 「不要念資工了」這個說法，到底站不站得住腳?

在職人數: 持續成長

先看最硬的數字: 美國勞工統計局 (BLS) 預測 2024-2034 年軟體開發人員成長 16%，從 169 萬成長到 196 萬，屬於「遠高於所有職業平均」的類別。

波士頓大學 Technology & Policy Research Institute 的 James Bessen 報告是目前最完整的反駁。幾個關鍵數據: 自 ChatGPT 發布以來，美國軟體開發人員淨增加了 40 萬個職位，2026 年二月達到 250 萬人的歷史新高。AI 確實加速了生產力——2022 年後開發者生產力成長從每年 3.9% 加速到 6.0%。但軟體產出成長更快，達到 9.3%。為什麼? 因為 AI 不只是讓既有工作更快完成，它還降低了成本、提升品質、催生出新的軟體產品。當需求成長的速度超過生產力提升的速度，就需要更多人——即使每個人的產出更高了。

Bessen 指出，這不是什麼新鮮事。軟體業過去二十年已經歷過結構化程式設計、自動化測試、Agile/DevOps、雲端運算、開源軟體等一波波生產力革命，從 2003 到 2025 年，每位開發者的實質產出翻了 2.5 倍（成長 150%），但總就業量不減反增。以這個歷史來看，AI 帶來的 50% 生產力提升，實在很難被認為會打破這個模式。他也特別提到: 軟體業是 AI 衝擊最大的行業，如果連這裡都沒有大規模取代，其他行業的恐慌就更缺乏根據了。

市場真的「很慘」嗎?

等等，那為什麼大家覺得市場很慘?

因為大家常常拿來論述比較的基準線是 2021-2022 年的泡沫高點，但這其實是個異常。The Pragmatic Engineer 的分析指出，2022 年 Indeed 上軟體工程職缺是疫情前的 3.5 倍——那才是異常值。現在回落是泡沫修正，不是產業崩潰。而且已經在回升: Tunga 追蹤多國 Indeed 數據，美國軟體開發指數從 2025 年五月谷底連續九個月回升；Citadel Securities 指出軟體工程師職缺年增 11%。

職缺市場內部的分化

所以整體來說，軟體工程師的在職人數是在成長的（BLS 和 Bessen 的數據都指向這點）。不過，職缺市場內部的確有在分化——誰在變多、誰在變少，差異很大。Indeed Hiring Lab 的職缺數據（以 2020 年二月為基準 100）顯示:

📊 一般軟體工程職缺: 指數 51，比疫情前低 49% 📊 機器學習工程師職缺: 指數 159，比疫情前高 59% 📊 資深工程師: 需求穩定，CompTIA 數據顯示有雲端或安全專長的資深工程師中位數 17 天就拿到 offer 📊 初階工程師: 職缺大幅萎縮，Wobo 報告追蹤 300 萬筆職缺後發現，Netflix、Airbnb、Anthropic、OpenAI 等知名企業刊登了 2,930 個資深職缺，但只有 212 個初階職缺

BLS 的職業分類透露了一個重要線索:「軟體開發人員」預估成長 16%，但「電腦程式設計師」預估下降 6%。前者設計系統、做架構決策；後者主要是把規格翻譯成程式碼。BLS 說明寫得很直白: 重複性的程式撰寫持續被自動化，較高技能的工作則轉移給軟體開發人員。AI 吃掉的是「把東西寫出來」，不是「決定要寫什麼、為什麼這樣寫」。

至於「不要念資工了」這個說法——情況比口號複雜得多。初階職缺確實大幅萎縮，但NACE 2026 冬季薪資調查顯示，能拿到 offer 的人起薪反而在漲: 資工學士 $81,535（年增 6.9%），碩士 $94,212（年增 10.9%）。更關鍵的是需求面: 資工學士是美國第三大最受雇主需求的學位（60% 雇主計劃招聘），碩士更是排名第一，超過 MBA。這代表企業不是不要資工人才，而是門檻提高了——職缺變少但願意付更多錢搶人，篩選更嚴格但需求仍在。「不要念資工」這個建議，搞混了「入場難度提高」和「這個領域沒前途」。

初階困境: 過渡期，不是終局

初階困境是真實的: 紐約聯邦儲備銀行數據顯示 CS 應屆畢業生失業率 6.1%，初階職缺從 2022 年以來下降了 67%。但小編認為這更像是暫時性的過渡期，而非永久性的消失。核心問題不是「企業不需要初階人才了」，而是傳統的初階工作內容被 AI 吃掉了，企業還沒想清楚怎麼重新設計。

市場對軟體工程師的需求其實不減反增——只是需要的不再是「能把規格翻譯成程式碼」的人，而是能善用 AI 協作、能設計系統架構、能做技術決策的工程師。這種需求非常旺盛，AI 工具越強大，能駕馭這些工具的人就越值錢。換句話說，門檻提高了，或者更精確地說，初階所需要的技能組合改變了: 以前的入門是寫 CRUD、套模板，現在的入門可能是理解 AI 產出的程式碼品質、知道什麼時候該信任 AI 什麼時候不該、以及能把 AI 的產出整合進更大的系統設計裡。

IEEE Spectrum 的報導裡，Creating Coding Careers 的 Mike Roberts 講得很直白:「如果你現在不培養新人進入市場，最終你就不會有人成為中階人才。」他認為目前的做法「非常短視」，只看這一季的效率，忽略了未來的人才斷層。SAP 的 CHRO 調查也呼應這個觀點: 88% 的人資長認為 AI 反而讓初階人才更快上手，問題是舊的入門工作（整理資料、寫重複性程式碼）被自動化了，但新的入門工作還沒被設計出來。

為什麼企業還沒想清楚? 還有一個可能的因素: AI 大幅提升了工程端的產出速度，但需求端——產品管理、專案規劃、決策流程——並沒有同步跟上。Andrew Ng 指出:「產品管理正在成為新的瓶頸。」airfocus 的 CEO Malte Scholz 也說:「AI 加速了工程和交付，但決策端還沒跟上。」當工程產能暫時超過企業能消化的需求量，最容易被省掉的就是初階職位。等到企業學會用新的方式做產品規劃、釋放更多需求，新的初階角色自然會被設計出來。

已經有企業開始行動了。IBM 宣布 2026 年美國初階招聘量增加三倍，策略不是保留舊的初階工作，而是重新設計: 讓新人更早接觸客戶、做 AI 產出的品質把關，而不是寫重複性的程式碼。當更多企業想通這一點——三到五年後需要中堅人才，現在就必須投資初階——初階職缺的回升只是時間問題。

「軟體工程師要被取代了」這個敘事，犯了跟整體 AI 取代論一樣的錯: 把「工作內容在改變」等同於「工作在消失」。寫 CRUD、套模板的部分確實在被 AI 壓縮，但系統設計、架構決策、理解業務需求這些，需求反而在上升。

小編怎麼看

整理完 2026 年的正反論據，四個判斷:

第一，「大規模取代」目前沒有發生，生產力悖論是最有力的反證。 4,000 多億美元投資，90% 企業沒有可衡量的生產力提升。取代人的前提是比人更有生產力——但總體數據還沒看到這個前提成立。

第二，2026 裁員潮需要打個大折扣。 很多「AI 裁員」實際上是疫情超額招聘的修正、資金轉投 AI 基建的資本重配、或單純的業績不佳。「以 AI 之名裁員」已經成為一種 PR 策略——既顯得有前瞻性，股價又可能因此上漲。

第三，初階職缺萎縮是真的，但這是過渡期的陣痛，不是永久性的消失。 傳統的入門工作內容被 AI 吃掉了，企業還沒設計出新的初階角色；同時工程產能跑在產品管理和需求規劃前面，造成暫時性的人力過剩。但企業終究需要培養下一代中堅人才，IBM 已經開始用三倍的初階招聘量來重新設計入門路徑。對正在找第一份工作的人來說衝擊很大，值得認真關注，但它跟「AI 大規模取代人類」是完全不同層級的事。

第四，「重塑」而非「取代」才是更準確的描述。 AI 吃掉可標準化的部分，留下需要判斷力、人際互動、隱性知識的部分。黃仁勳的「task vs. purpose」、Autor 的「專業知識貶值」、BCG 的「重塑 vs 消除」，都在指向同一件事: 工作不是在消失，是在升級。

歷史反覆證明: 變革性技術造成的就業衝擊，幾乎總是比同時代的人預期的更慢、更小、也更不一樣。ATM 沒有消滅銀行櫃員，AI 影像辨識沒有消滅放射科醫師。2026 年的數據很清楚:「改變」跟「取代」是兩件事。搞混這兩者，只會導致錯誤的恐慌和錯誤的政策。

與其害怕被 AI 取代，不如認真思考怎麼讓 AI 變成你的槓桿。

這個觀念叫做 Eval 就是 Spec——在 AI 產品中，eval 資料集才是你真正的規格書。

品質是分布，不是一個數字

傳統軟體測試是確定性的: 輸入 A 就該產出 B，對就是對、錯就是錯。但 LLM 不是這樣運作的。你的模型可能 87% 的時候是對的，但那 13% 的失敗長尾，偏偏集中在你的重度使用者最在意的場景上。

如果你只看平均準確率就發佈產品，那你發佈的是錯的產品。品質是一種分布，你需要理解整個分布的形狀，而不是只盯一個數字。

為什麼 PRD 在 AI 時代行不通

傳統軟體中，PRD 描述要做什麼，工程師照著做就好。但 AI 產品本質上是機率性的——同一個輸入跑兩次可能得到不同輸出，不存在「唯一正確答案」。傳統的驗收清單假設了確定性的世界，套在 LLM 上根本不夠用。

Andrew Ng 在 DeepLearning.AI 的文章 Best Practices for AI Product Management 裡直接講了這件事:

「就像機器學習演算法需要訓練範例來學習，AI 產品開發團隊也需要具體的範例來定義我們希望 AI 系統做什麼。換句話說，資料就是你的 PRD。」

他舉了一個例子: 如果產品經理提出「做一個回答銀行帳戶問題的聊天機器人」，這種規格太模糊了——要回答餘額查詢就好? 還是也要回答利率、轉帳流程? 但如果產品經理直接寫出 10 到 50 筆具體的對話範例，展示「這個聊天機器人應該怎麼回答」，範圍一下就清楚了。工程師可以評估技術可行性，然後朝著這些範例去建構系統。

Andrej Karpathy 早在 2017 年的 “Software 2.0” 文章就從更底層的角度點出了一樣的事: 傳統軟體是人類一行一行寫指令，但 AI 軟體的「原始碼」本質上就是資料集加上模型架構。人類定義目標、提供資料，系統自己學出實作方式。

Ng 在另一篇 Coping With Product Specification 更具體地說: AI 產品的規格應該包含「量測指標」加上「用來評估指標的資料集或資料分布」。而且要針對不同的資料切片(slice)分別設定效能門檻——比如一個醫療 AI，對嚴重疾病和輕微疾病的準確率要求可能不同，對不同年齡、性別的使用者群體也要分別檢查公平性。這已經不是傳統 PRD 能處理的事了。Groundy 有一篇 Data IS Your PRD 把 Ng 的這套思路整理得蠻完整的，推薦一讀。

把這個思路推到極致就是: eval 資料集才是規格書。 如果你的團隊在第一天沒有一套共享的 eval 評分標準，之後每次談論品質，都只會變成「憑感覺」的討論。

Eval-Driven Development 這個社群把這件事講得更明白: 軟體開發已經進入 Agent 時代，工程師的工作不再只是產出能動的程式碼——而是定義什麼叫做「能動」，量測它，然後把系統壓在這個定義上。eval 套件不是開發之後的驗收階段，而是開發之前就該建好的規格。

編按: Hamel Husain 和 Shreya Shankar 開設的 AI Evals 課程 已經訓練了超過 4,000 名學員，也替 OpenAI、Anthropic、Google、Meta 等公司的團隊做過顧問。他們的核心訊息很直接: 「每個人都在 demo AI 功能，很少人能可靠地上線。差距在哪? Eval。」Hamel 在他的 Field Guide 裡甚至主張: AI 產品的路線圖不該用「上了幾個功能」來衡量，而是「跑了幾個實驗」——而跑實驗的前提就是有可信的 eval 基礎設施。

每一條 Eval 都是一個向量

Viv Trivedy (LangChain) 提出了一個很精準的比喻: 每一條 eval 都是一個向量，會推動你整個 Agent 系統的行為偏移。

舉例: 如果一條「高效讀取檔案」的 eval 失敗了，你會去調整 system prompt 或是 read_file 工具的描述，直到這條 eval 通過為止。你加進去的每一條 eval，都在對整個系統施加壓力，持續把行為往你想要的方向推。

但 Viv 也強調了一個關鍵: 更多 eval 不等於更好的 Agent。 盲目丟進幾百幾千條測試，只會製造一種「Agent 在進步」的假象——因為你可能在一個不反映真實生產環境的 eval 上刷分。重點不是數量，而是每一條 eval 是否精準對應到你在線上環境想要的行為。

LangChain 的 Deep Agents 怎麼做 Eval

LangChain 團隊發了一篇 How we build evals for Deep Agents，完整示範了這套做法，蠻值得細看的。

Deep Agents 是 LangChain 開源的 Agent 框架，驅動了 Fleet 和 Open SWE 等產品。他們建構 eval 的流程分三步:

1. 先決定要什麼行為: 列出 Agent 在線上環境需要展現的行為(例如跨多個檔案檢索內容、連續組合 5 個以上的工具呼叫)，再針對這些行為設計可驗證的 eval
2. 每條 eval 自帶文件: 每條 eval 都附文件說明它測量的是什麼能力，並用標籤分類(如 tool_use、retrieval)，方便分組執行
3. 從追蹤紀錄回饋更新: 檢閱輸出的追蹤紀錄來理解失敗模式，持續更新 eval 覆蓋範圍

Eval 資料從哪來? 他們混合三種來源:

• 每天自己使用 Agent，每個錯誤都變成一條 eval
• 從外部基準測試 (Terminal Bench 2.0、BFCL) 挑選並改造成適合自家 Agent 的 eval
• 團隊手工打造的 eval，針對特定行為(比如測試 read_file 工具的表現)

他們有一個蠻值得參考的做法: 把 eval 按「測試什麼能力」來分類，而不是按「eval 從哪來的」。比方說，一條從外部 BFCL 基準測試改造來的 eval 和一條內部手寫的 eval，只要都在測工具呼叫能力，就歸在同一類。這樣做的好處是，你可以一眼看出 Agent 在「檔案操作」很強、但「記憶」很弱——而不是只有一個籠統的總分。他們的分類包含: 檔案操作、檢索、工具使用、記憶、對話、摘要等維度。

量測指標也不只看「對不對」。 兩個模型可能都能完成同一個任務，但一個多繞了幾步、多呼叫了不必要的工具、延遲更高——在線上環境這就是更高的成本和更差的體驗。所以他們定義了「理想軌跡」的概念: 對每個任務設定最佳路徑(最少步數、最少工具呼叫)，然後量化實際表現和理想的差距。模型選擇就變成一個兩階段的決策: 先看哪些模型夠準確，再從中挑效率最好的。

Eval 是飛輪，不是一次性的事

Viv 在另一則貼文中畫出了完整的飛輪:

🔹 第零步: 打開追蹤，收集 Agent 的所有行為軌跡

🔹 第一步: 分析追蹤紀錄，理解 Agent 行為、切分有用的任務、找出錯誤模式

🔹 第二步: 把追蹤資料轉成 eval，用來改善 Agent

🔹 第三步: 選擇改善路徑——提示詞工程、微調、或兩者兼用

🔹 第四步: 持續滾動，收集更多追蹤紀錄、產生更好的 eval、做人工審查、迭代出更好的 Agent

這個飛輪的核心邏輯是: 從線上環境的追蹤紀錄萃取出來的 eval，會比任何通用基準測試更準確地反映使用者真正在做什麼。通用基準測試能測到一些基本能力(長推理、工具呼叫等)，但針對你的特定場景，客製化的 eval 幾乎一定更有效。

Matt Stockton 的回應也點出了關鍵: LLM 是一個超有能力但高度不確定的技術，整個遊戲就是把它推向你自己定義的「主觀確定性」版本。你可以靠手動看輸出來憑感覺猜，或者你可以用 eval 量化地定義什麼叫做好。建 eval 很辛苦，因為你得真的去看你的資料、去決定什麼是好的輸出——但如果你做了這個辛苦的工作，很多其他事情就變簡單了。

Eval 也是你擺脫貴模型的方法

Aparna Dhinakaran 最近寫了一篇很到位的長文: 如果你被困在昂貴的模型上，eval 就是你脫身的方法。核心論點:

前兩年大家預設「明年的模型會更便宜、更快、更強」，但這個假設正在崩塌。前沿實驗室都在搶算力——Anthropic 租下了整個 SpaceX Colossus 資料中心，OpenAI 用股權換算力，Google 砍了免費 API 額度。前沿模型的推理成本短期內不會如預期下降。

在這個現實下，eval 不再是可有可無的東西，而是讓你可以換到更便宜模型的唯一機制。你有一個跑在 Opus 上的工作負載，想知道能不能搬到 Sonnet 或 Haiku? 唯一誠實的答案就是: 跑 eval。

關鍵是你的 eval 必須夠格:

1. 覆蓋使用者真正碰到的情境，按頻率加權——從線上追蹤紀錄開始，不是從想像開始
2. 品質標準要具體到可以被反證——「有幫助」不是標準；「提取所有五個必要欄位，欄位準確率 97% 以上，無幻覺欄位值」才是
3. 用你信任的評判者——用 LLM 當裁判可以，但必須對齊人類標註的結果
4. 跑起來夠便宜——跑不動的 eval 等於文件，不是基礎設施

Eval 是護城河

回到 Viv 的觀點: eval 可以成為你的護城河，因為它是幫你定義和量測 Agent 行為的核心物件。你的 eval 在覆蓋率和行為量測上越好，你的 Agent 就越好。而且這個護城河會隨時間加深——當你部署 Agent、收集追蹤資料、從線上環境的失敗模式中產生更好的 eval，整個正向循環就開始轉動。

甚至不用一開始就搞得很完美——Viv 說得好: 就算只有 5 條 eval，只要是團隊坐下來一起討論出來的，就已經是建立護城河和啟動改善迴圈的起點了。

給決策者的重點

如果你是 AI 產品的決策者或開發者，請記住:

不要期待一份 PRD 就能讓 AI Agent 做對事情。 PRD 能描述「要做什麼」，但沒辦法精確定義 LLM「該怎麼做好」。你需要的是一套 eval 資料集——幾十條、幾百條、最終上千條——去描述「在各種情境下，好的輸出長什麼樣」。這些 eval 不只是測試，更是規格本身。它們定義 Agent 的行為、驅動改善的方向，最終決定產品品質的上限。

傳統軟體工程有句名言: 「沒有測試的程式碼就是遺留程式碼。」在 AI Agent 時代，這句話要改寫成: 沒有 eval 的 Agent 就是在碰運氣。

小編覺得這個觀點蠻值得拆開來聊的，因為它背後的洞見不只是「換個格式」這麼簡單。

為什麼 HTML 比 Markdown 好看這麼多?

Markdown 的設計初衷是讓「原始檔」也能被人類閱讀 — 用 # 當標題、- 當列表、** 當粗體。這在純文字環境下確實堪用，但說到底它的視覺表達能力非常有限: 沒有版面配置、沒有色彩、沒有互動元素，所有東西都是線性排列的純文字。

HTML 就完全不同了。同樣的內容，用 HTML 呈現可以有卡片式佈局、資料圖表、摺疊面板、分頁切換、甚至簡單的互動功能 — 而且這些 AI 都能直接生成，不需要你寫任何 CSS 或 JavaScript。

Thariq 做了一個範例展示頁，列出了 20 種 HTML 輸出的實際用途。小編挑幾個特別有感的:

🔹 探索與規劃

• 三種程式碼方案並排比較 — 不同方案的 tradeoff 一目了然，比 markdown 表格強太多
• 視覺設計方向比較 — 多個配色和版面直接渲染出來，不用想像
• 實作計畫 — 把時程、資料流圖、mockup、風險評估塞進同一份文件

🔹 Code Review 與程式碼理解

• 帶註解的 PR diff — 在程式碼旁邊直接標註嚴重程度和評語
• PR 說明文件 — 修改動機、前後對比、逐檔案說明，一頁搞定
• 模組地圖 — 把不熟悉的程式碼結構畫成關聯圖，標出關鍵路徑

🔹 設計與原型

• 設計系統色票 — 色彩、字型、間距的互動式展示
• 元件變體一覽 — 同一個元件在不同尺寸、狀態下的所有變化
• 動畫沙盒 — 可以即時調整時間和緩動參數的動畫原型
• 可點擊的互動流程 — 四個畫面串接，直接測試操作手感

🔹 圖表、簡報、報告

• 部署流程圖 — 可點擊的流程圖，每一步都能展開看細節和錯誤路徑
• 方向鍵簡報 — 單一 HTML 檔就是一份完整簡報，不需要 PowerPoint
• 週報儀表板 — 進度、延遲項目、圖表，週一早上打開就能用
• 事件覆盤時間軸 — 逐分鐘時間軸、log 摘錄、後續追蹤清單

🔹 互動式編輯介面

• 拖放式分類看板 — 可以拖放 ticket 到不同優先級，還能匯出 markdown
• Feature flag 管理面板 — 分組切換開關，有相依性警告
• Prompt 即時調校工具 — 即時編輯變數、預覽輸出結果

全部都是單一 HTML 檔，不需要任何外部相依，瀏覽器打開就能用。小編點了幾個進去看，確實比同樣內容用 markdown 呈現的資訊密度和可讀性高很多。

Karpathy 的觀點: 人腦是視覺處理器

Karpathy 的回覆把這件事拉到更高的層次。他提出了 AI 輸出格式的進化路線:

1. 純文字 — 費力閱讀
2. Markdown — 粗體、斜體、標題、表格，稍微好讀一點 ← 目前的預設值
3. HTML — 仍然是程式碼驅動，但在版面、圖形、互動性上靈活很多 ← 正在成形的新預設
4. …
5. 互動式神經影像/模擬 — 終極形態

他的核心論點是: 人類大腦有大約三分之一是專門做視覺處理的平行運算器，視覺是資訊進入大腦的「十線道高速公路」。既然如此，AI 的輸出格式當然應該往更視覺化的方向走。

小編覺得這個框架很有啟發性。我們現在用 LLM 產出的內容，大部分還停留在第二階段 — Markdown 渲染後的文字。但其實 LLM 完全有能力直接產出第三階段的 HTML，只是大多數人還沒有養成這個習慣而已。

關鍵區分: 這不是取代 Markdown

這裡有一個很重要的細微差別，dex 講得很精準:

Markdown 的價值其實有兩層:

1. 給人類的清晰摘要 — 用結構化的方式呈現大量資訊，讓人更快理解
2. 給模型的 token 效率格式 — 用最少的 token 傳遞最多的資訊或意圖

HTML 只解決了第一個問題。如果你的目標是給人看，HTML 當然更好; 但如果你的內容是要餵給下一個 AI 模型處理，HTML 的標籤會大幅膨脹 context window，反而是扣分的。

Viv 補充了一個很實際的例子: 她的「視覺文章 Skill」本身是用 markdown 寫的（因為是給 AI 讀的指令），但輸出是 HTML（因為是給人看的成品）。

所以正確的理解是:

• Markdown 是 AI 讀寫的好格式 — 結構清楚、token 效率高、AI 原生就擅長處理
• HTML 是給人類看的好格式 — 視覺豐富、版面靈活、互動性強

兩者不是取代關係，而是各有適用場景。關鍵是搞清楚你的輸出是給誰看的。

實測 20 個 Prompt: 哪些最值得學?

有人把 Thariq 的 20 個範例全部重新跑了一遍，用 Claude Code 分別產生 markdown 和 HTML 版本來比較。結果 HTML 在 17 個場景中勝出，只有 3 個輸給 markdown。代價是 token 用量中位數約 4.5 倍、生成時間約 4 倍。

但更有價值的是他的實測心得 — 哪些場景的 HTML 輸出真正改變了工作方式:

🔹 Code Review 是最大贏家。 同一個 612 行的 PR，markdown 版本他 90 秒掃完就跳過了; HTML 版本他讀了 11 分鐘，因為 margin 註解讓他直接看到「這裡把 backpressure 閾值從 8KB 改成 64KB」，而且在 HTML 版本中抓到了一個 off-by-one bug。一個 bug 就值回所有額外的 token 成本。

🔹 設計系統是「用了就回不去」的那種。 HTML 版本把色彩、字型、間距渲染成實際的色票和字型樣本，他兩天內開了 8 次。Markdown 版本? 一個表格，開了 0 次。

🔹 動畫原型最能體現「雙向互動」。 他請 Claude Code 設計一個「滑鼠懸停時卡片浮起」的微互動。Markdown 版本用文字描述 easing 曲線; HTML 版本直接跑動畫，附帶兩個滑桿可以即時調整時間和緩動參數，調好後把數值貼回 Claude Code 當下一輪 prompt。90 秒搞定。

🔹 分類看板是讓他「轉向」的那個範例。 把 32 個 GitHub issue 丟進去，產出一個可拖放的看板（Now / Next / Later / Cut），拖完按「copy as markdown」直接貼進規劃文件。Markdown 版本是一份清單，他說「眼睛在第 14 項就死了」。

🔹 週報的改變最容易量化。 同樣的內容改成 HTML（加上一個 shipped vs slipped 的小圖表），團隊的閱讀率從 4/12 人跳到 11/12 人。

而 Markdown 比較好的那三個場景也很有參考價值:

1. Agent 之間傳遞的中間狀態 — 下一個 AI 不會渲染頁面，markdown 的 token 效率更高
2. 需要 code review 的版控檔案 — 6,690 token 的 HTML 在 git diff 裡幾乎不可讀
3. Terminal 串流輸出 — HTML 在終端機裡就是亂碼

一句話總結: HTML 用在 artifact（給人看的成品），markdown 用在 state（給 AI 處理的中間狀態）。

延伸: 社群的有趣應用

GitHub 上出現了 html-artifacts 這個開源專案，把「什麼時候該輸出 HTML」包裝成一個 Claude Code skill，讓 AI 自己判斷這次的輸出適合用 HTML 還是 markdown。

還有一個蠻有意思的概念: 有人把 AI 生成的 HTML 稱為「reWritable HTML」— 這份 HTML 文件本身就是一個可編輯的工作空間，你可以直接在上面繼續和 AI 互動、修改、迭代，不需要另外開編輯器。某種程度上，這回到了 Tim Berners-Lee 當初設計 Web 的初衷: 網頁本來就應該是可讀也可寫的。

實際應用: 用 HTML 追蹤 Codex 任務進度

OpenAI 的 Dominik Kundel（負責 Codex 和 DevX）分享了一個蠻聰明的應用: 在跑 Codex 的長時間任務時，在 steering 指令裡加一句「定期更新一個 goal.html 來顯示任務進度」。這樣你就有一個隨時可以用瀏覽器打開的視覺化進度儀表板，而不是去翻一堆 log 或 terminal 輸出。

這個思路可以延伸到很多場景: 讓 AI coding agent 在工作過程中維護一份 HTML 狀態報告、讓長時間跑的分析任務把中間結果即時渲染成圖表、或者用 HTML 做 debug 過程的視覺化紀錄。

怎麼開始?

其實很簡單，在你的 prompt 最後加一句「把回應用 HTML 格式輸出」就行了。或者更具體一點:

• 要比較方案? 「用 HTML 做一個並排比較表，附帶優缺點標注」
• 要做報告? 「輸出成 HTML 儀表板，包含圖表和摘要」
• 要解釋概念? 「用 HTML 做一個互動式教學頁面」

存成 .html 檔，瀏覽器打開就能看。如果用 Claude Code 之類的工具，甚至可以直接在工作流程中產生這些檔案。

以上，重點不是「markdown 不好」，而是我們一直在用一種對 AI 友善但對人類次優的格式來消費 AI 的輸出。既然 AI 有能力直接產出更豐富的視覺呈現，何不善用它?

小編把 Karpathy 的原始構想、社群裡幾個有代表性的實作，以及 DAIR.AI 的 Elvis Saravia 整理的教學版一起做個比較。重點不是哪個「最好」，而是幫你搞清楚不同設計決策背後的取捨，找到適合自己的起手式。

核心概念: 不是 RAG，是「編譯」

先講最重要的事: Karpathy 提出的模式跟大家熟悉的 RAG 完全不同。

RAG 的做法是每次問問題時，從原始文件裡撈相關片段，然後讓 LLM 即時拼湊答案。問題是知識每次都從零開始重建，沒有累積。問一個需要綜合五篇文章的複雜問題，LLM 每次都得重新找、重新拼，效率很差。

Karpathy 的做法是把 LLM 當「編譯器」: 原始資料進來之後，LLM 不只是索引它，而是讀懂、摘要、分類、交叉連結，把知識「編譯」成一座結構化的 Markdown wiki。知識被寫進結構裡，下次查詢時直接從 wiki 裡找，不用每次從零推導。

用他自己的類比: Obsidian 是 IDE (你在上面瀏覽)、LLM 是寫程式的人 (它負責寫和維護 wiki)、wiki 就是程式碼庫 (你幾乎不直接動手編輯)。

Karpathy 的原始架構: 三層 + 四個動作

Karpathy 後來在 GitHub Gist 發了一份更完整的構想文件，把架構講得更清楚。核心是三層:

🔹 raw/ — 原始資料，只讀不改。文章、論文、程式碼、圖片，用 Obsidian Web Clipper 一鍵存入

🔹 wiki/ — LLM 編譯出的知識庫。摘要、概念頁、實體頁、交叉引用，全部由 LLM 維護，人不碰這層

🔹 Schema (CLAUDE.md) — 告訴 LLM 怎麼維護 wiki 的規則文件。命名規範、引用規則、匯入流程、查詢方式，全寫在這裡。這個檔案是讓 LLM 從「通用聊天機器人」變成「有紀律的 wiki 維護員」的關鍵

四個動作形成閉環:

1. 匯入 (Ingest): 新資料進 raw/，LLM 讀取後更新 wiki，一次可能動到 10-15 個頁面
2. 查詢 (Query): 問問題時 LLM 從 wiki (不是 raw) 查答案
3. 回寫 (File back): 有價值的問答結果寫回 wiki，讓知識持續累積
4. 健檢 (Lint): 定期跑健康檢查，找矛盾、補缺漏、發現新的研究方向

Karpathy 自己在某個研究主題上累積了約 100 篇筆記、40 萬字。他說本來以為需要搞 RAG 管線，結果發現在這個規模下，LLM 靠自動維護的 index.md 加上摘要就能搞定，根本不需要向量資料庫。

他最後留了一句:「我覺得這裡有空間誕生一個了不起的產品，而不只是一堆雜七雜八的腳本。」

各路實作比較

Karpathy 刻意把構想文件寫得很抽象——只講概念模式，不講具體實作。結果社群裡幾天內就冒出一堆版本。以下挑幾個有代表性的來比較。

1️⃣ Elvis Saravia / DAIR.AI — 最清楚的教學版

DAIR.AI 的 Elvis Saravia 寫了兩篇文章，第一篇整理架構，第二篇手把手教你從零建起來。後來還做了一個 Wiki Builder 的 Claude Code 外掛。

Elvis 版的特色是極度簡潔: raw/ 放原始素材、wiki/ 放編譯結果 (含論文頁、概念頁、趨勢頁等子目錄)、derived/ 放問答產出、prompts/ 放可重複使用的編譯指令。

他用 AI Papers of the Week 當範例，從三份週報出發，示範完整的匯入 → 編譯索引 → 建論文頁 → 建概念頁 → 提問 → 回寫 → 健檢流程。走完一輪就知道這套東西怎麼運作了。

小編覺得這是入門首選，簡單明瞭，不會被複雜架構嚇到。

2️⃣ Yanhua — 精簡實用版 + 防腐化規則

Yanhua 在 X 上分享的版本也很精煉，把目錄簡化成三層:

• 原料/ — 只讀，LLM 不可修改
• 摘要/ — LLM 結構化編譯產物
• 沉淀/ — 每次高品質問答的答案落檔

他特別強調兩個「元文件」的作用:

• CLAUDE.md: 放在根目錄，是控制 LLM 行為的「最高憲法」，每次會話必讀
• index.md: 全局目錄，每篇筆記加一行摘要。LLM 檢索時先掃索引，再決定要不要深讀全文，大幅省 token

最有價值的是他的「防腐化規則」: 重要斷言必須有來源連結、新舊衝突時報差異不默默覆蓋、區分「原文事實」和「推論」。這些寫進 CLAUDE.md，知識庫才不會幾個月後變成 LLM 幻覺的堆積場。

3️⃣ 范凱 — 四層工作流版

范凱的 llm-knowledge-base 是目前社群裡做得最完整的開源範本之一。他把 Karpathy 的三層擴展成四層:

raw/           ← 原始素材 (只讀)
wiki/          ← LLM 編譯的知識 (摘要 + 概念 + 索引)
brainstorming/ ← 探索紀錄 (問答、健檢報告)
artifacts/     ← 你的成品 (文章、報告)

跟 Karpathy 原版最大的差別是: Karpathy 的架構偏向「由上往下管理」(schema 管 wiki 管 raw)，范凱的偏向「工作流式」——知識在不同階段間流動。他自己既是知識的生產者也是消費者，所以需要雙向編譯跟與 LLM 討論的階段。

他還附了 6 個 Claude Code 指令 (/compile、/health-check、/thinking-partner、/write-partner 等)，降低上手門檻。

編按: 范凱在 README 裡寫的反思蠻有意思的——他說真正的問題從來不只是工具。以前用「第二大腦」方法論，摩擦力來自整理本身；現在把整理交給 AI，摩擦力沒消失，只是變成了「對話裡那些你答不上來的問題、那些被指出的矛盾」。

4️⃣ Tim Feng — 語義分層版 + 漸進式披露

Tim Feng 在 Facebook 分享了一個蠻獨特的架構，把知識庫分成三層語義結構:

• sources/ — 原始文本 (書、文章、影片逐字稿)，一定保留原文不摘要
• thoughts/ — 讀後心得，跟 sources 一對一對應，每篇來源都有同名心得
• projects/ — 實作產出，每個專案都有說明文件

每層各有一個 INDEX.json (不是 Markdown，是 JSON)，包含標籤、摘要、檔案連結。設計靈感來自 Claude Code 的 Skill 機制: LLM 啟動時先載入所有索引，只看摘要和標籤，需要時才深讀全文——他稱之為「漸進式披露」。

他還有個特別的 CONCEPTS.md，記錄「跨心得重複出現的共通概念」。如果一個概念在不同來源反覆出現，就值得獨立抽出來。

工作流也蠻完整: 新來源進來會自動跟現有資料庫做比對，找出「起始共鳴」(可能的關聯)，寫進同名的心得檔裡。日後有新專案，LLM 會透過三份索引去搜尋所有可能相關的素材。

5️⃣ Garry Tan / GBrain — 工程級知識圖譜

GBrain 是 Y Combinator 總裁 Garry Tan 做的，跟前面幾個完全不是同一個量級。這不是一個概念模式，是一套完整的知識基礎設施:

• 17,888 頁、4,383 人物、723 家公司，21 個排程任務自動跑
• 用 Postgres + pgvector 做混合搜尋 (向量 + 關鍵字 + 知識圖譜 + 重排序)
• 自動建立有型別的關係連結 (出席、任職、投資、創辦等)，不需要額外的 LLM 呼叫
• 自動匯入: 會議、信件、推文、語音通話，全部自動關聯
• 43 個預設技能，從訊號偵測到引用修正都有

GBrain 的頁面模型是「編譯後的當前最佳論述」加上「只增不刪的時間軸證據鏈」。搜尋是關鍵字 + 向量 + 倒數排名融合的工程級組合，測試顯示知識圖譜比純向量搜尋的精準度高了 31.4 個百分點。

簡單說，如果 Karpathy 的是「用筆記本管研究資料」，GBrain 就是「用 ERP 系統管整間公司的知識資產」。

6️⃣ Tobi Lütke / QMD — 本地搜尋引擎

Shopify 執行長 Tobi Lütke 做的 QMD 走的是另一條路: 不幫你建 wiki，但幫你在既有的 Markdown 檔案上做極致搜尋。關鍵字比對 + 向量語意 + 查詢擴展 + LLM 重排序，全部在本地跑，不上雲端。

QMD 跟 Karpathy 的 wiki 其實是互補的: wiki 長大之後需要更好的搜尋能力，QMD 剛好補這塊。Karpathy 本人也推薦過 QMD 作為 wiki 的搜尋層。

其他社群衍生專案

除了上面幾個之外，社群裡還冒出了大量衍生工具，例如 SwarmVault (本地優先、內建知識圖譜)、llm-wiki.net (Claude Code 外掛、支援多 agent 平行研究)、OpenKB (支援 PDF/Word/PPT 等多格式匯入)、sage-wiki (Go 寫的單一執行檔、內建 MCP 伺服器) 等。大多是 Karpathy 原始概念的不同包裝，核心架構差異不大，但各自在特定場景 (離線使用、多格式支援、多 agent 整合) 上做了延伸。

關鍵設計決策比較

把這些實作攤開來看，幾個核心設計決策的差異:

怎麼選?

這些做法看起來差異不小，但背後的核心觀念是一致的: 原始資料唯讀、wiki 由 LLM 全權維護、用 schema 文件約束 LLM 的行為。差別主要在於你的使用情境和規模。

如果你還沒試過，最快的起手方式是把 Karpathy 的 llm-wiki.md 丟給 Claude Code，說「幫我建一個知識庫」，五分鐘就能跑起來。或者照 Elvis Saravia 的教學走一遍，先感受整個工作流再說。

想要現成架構可以直接用的，范凱的 llm-knowledge-base 是目前最完整的開源範本，clone 下來、資料丟進 raw/、跑 /compile 就行。四層架構比較適合同時是知識「生產者 + 消費者」的人。

不管用哪個版本，有幾件事值得從第一天就注意:

• 寫好你的 CLAUDE.md: 這是整套系統最重要的檔案。命名規則、引用格式、衝突處理方式，都要寫清楚，不然 LLM 每次會話的行為都不一致
• 做好防腐化: 把 Yanhua 的規則搬過來——來源追溯、衝突報差異而非靜默覆蓋、區分事實與推論。這決定了知識庫三個月後還能不能信任
• 不要急著上向量資料庫: Karpathy 自己 40 萬字都還不需要。在這個規模下，一份維護好的索引檔就夠用了。等到 index.md 真的塞不下，再考慮 QMD 或 pgvector
• 讓問答結果回寫到知識庫: 這是整套模式最容易被忽略但最有價值的部分。每次提問的好答案如果只停留在對話紀錄裡，就浪費了。寫回 wiki 讓知識持續複利

更大的啟示

LLM Knowledge Base 之所以引起這麼大的迴響，不只是因為它解決了「筆記整理很煩」這個問題。它背後是一個更根本的思維轉換: LLM 不只是回答問題的機器，而是知識的基礎建設。

傳統的知識管理工具——Notion、Roam、Obsidian——都把整理的苦工甩給人做。大多數人最終放棄，不是沒毅力，是維護成本超過了回報。這套模式把成本轉移給 AI: 人負責找素材、定方向、問好問題；AI 負責摘要、連結、一致性維護。

而且這不限於個人筆記。團隊知識庫、研究文獻管理、投資研究、產品文件——任何「持續有新資料進來、需要被結構化整理、會被反覆查詢」的場景都適用。

不過就算沒有完美的產品，這套做法現在就能用。挑一個版本，花半小時建起來，把你最近在研究的主題丟進去。看到 LLM 自動把散亂的文章編譯成有結構、有交叉連結的 wiki，你會理解為什麼 Karpathy 說他現在「花更多 token 在操作知識，而不是操作程式碼」。

事情在 Codex (OpenAI 的 coding agent) 的系統指令被攤開後炸鍋了——裡面赫然寫著:

“Never talk about goblins, gremlins, raccoons, trolls, ogres, pigeons, or other animals or creatures unless it is absolutely and unambiguously relevant to the user’s query.”

翻譯: 除非跟使用者問題完全相關，否則絕不能提到哥布林、小精靈、浣熊、巨魔、食人魔、鴿子或其他生物。

這行指令被挖出來後，Polymarket 轉發拿到上百萬次瀏覽、WIRED 報導、Sam Altman 本人也下場玩梗。OpenAI 乾脆自己寫了篇完整的事後分析，而且寫得蠻到位的——不是公關稿，是一份紮實的技術覆盤。

哥布林到底怎麼來的?

故事要從 ChatGPT 的「個性化」功能說起。OpenAI 讓使用者可以選擇不同的語氣風格，其中有一個叫「Nerdy」(書呆子風)。它的系統指令是這樣寫的:

你是一個不折不扣的書呆子、愛玩又有智慧的 AI 導師……你必須用語言的趣味來消解做作。這世界複雜而奇異，其奇異之處必須被承認、分析，並且享受。

聽起來很正常對吧? 問題出在訓練這個書呆子個性的 RLHF 過程中。

RLHF 的運作方式簡單說就是: 模型產生多個候選回答 → 人類標註員排序哪個比較好 → 訓練出一個「獎勵模型」來自動打分 → 模型被優化去產生高分回答。這個獎勵模型本質上定義了「好回答長什麼樣」。

問題來了: 獎勵模型學到了一個捷徑。它發現含有「哥布林」「小精靈」等生物隱喻的回答，在書呆子風格下會得到更高的分數。OpenAI 審計後發現，在 76.2% 的資料集中，含有哥布林字眼的回答比不含的得分更高。模型並不是真的「喜歡」哥布林——它只是發現了一條獎勵捷徑: 塞個哥布林進去，分數就高了。

從 2.5% 到 66.7%: 哥布林的擴散路徑

數字講最清楚:

🔹 GPT-5.1 發布後，ChatGPT 回答中「goblin」出現頻率暴增 175%，「gremlin」增加 52%

🔹 書呆子個性只佔所有 ChatGPT 回答的 2.5%，卻貢獻了 66.7% 的哥布林提及

🔹 到了 GPT-5.4，書呆子模式下的哥布林提及量比 GPT-5.2 暴漲 3,881%

最關鍵的問題是: 為什麼哥布林會從書呆子模式「外溢」到其他模式?

答案是一個經典的回饋迴路:

1. 書呆子風格被獎勵產生俏皮的隱喻
2. 一些被獎勵的回答剛好包含了生物隱喻
3. 這些回答在強化學習訓練中產生更多類似的輸出
4. 這些模型輸出被拿來當作下一輪監督式微調的訓練資料
5. 下一代模型從訓練資料裡學到「哥布林是正常用語」
6. 循環重複，每代放大

OpenAI 自己講得很直白: 強化學習不保證學到的行為會乖乖待在產生它的條件裡。一旦某個風格怪癖被獎勵了，它就會透過訓練資料的再利用擴散到其他地方。

等到 OpenAI 搜尋 GPT-5.5 的訓練資料時，發現裡面不只有哥布林和小精靈，還有一整個「生物家族」——浣熊、巨魔、食人魔、鴿子都被標記為異常高頻的口頭禪詞彙。模型已經把作弊碼從特定詞彙泛化到一整個類別了。

編按: 有趣的是，OpenAI 特別提到「青蛙」的使用大多是正常的——還好蛙蛙沒事。

修復: 系統指令的 OK 繃

OpenAI 做了三件事: 三月退役書呆子個性、移除偏好生物隱喻的獎勵信號、過濾訓練資料中的生物詞彙。但問題是 GPT-5.5 在找到根因之前就已經開始訓練了。重新訓練一個 GPT-5.5 等級的模型成本極高，所以最快的修法就是在 Codex 的系統指令加上那句「不准提哥布林」。

OpenAI 甚至開了個小玩笑: 如果你想在 Codex 裡解放哥布林，可以用一行指令把禁令拿掉。OpenAI Developers 的推文寫得很到位: 「趁哥布林還沒發現之前趕快用。」(Available until the goblins notice.)

不只是哥布林: 所有模型都有自己的口頭禪

哥布林事件之所以值得關注，不只是因為好笑，而是因為 同樣的機制正在所有 LLM 上重複發生。

🔹 「delve」事件: 2024 年最有名的 AI 語言指紋。ChatGPT 瘋狂使用「delve」(深入探討) 這個詞，後來被追溯到 RLHF 標註員的語言背景——OpenAI 大量外包給奈及利亞和肯亞的標註員，而「delve」在奈及利亞英語中是很常見的正式用語。標註員覺得用這個詞的回答比較有質感 → 獎勵模型學到「delve = 好」→ 模型瘋狂產出。跟哥布林一模一樣的迴路。(參考: Why Does ChatGPT “Delve” So Much?、Word Overuse and Alignment in LLMs)

🔹 破折號癖好: 論文 The Last Fingerprint 專門研究了破折號使用頻率，發現不同模型的 RLHF 訓練流程會顯著影響破折號使用量——GPT-4.1 每千字 10.62 個、Claude Opus 4.6 有 9.09 個、DeepSeek V3 有 6.95 個，而 Meta 的 Llama 模型則是零。同一個基底傾向，可以被 RLHF 放大或壓制，端看微調怎麼做。Sam Altman 在 2025 年 7 月 Theo Von 的 podcast 訪談中也坦承:「很多使用者喜歡破折號，所以我們加了更多破折號。現在我覺得我們破折號太多了。」

用數據說話: 口頭禪指數研究

2026 年四月的論文 The Rise of Verbal Tics in Large Language Models 做了一個蠻系統性的實驗: 用一萬個提示跨 10 種任務類別，同時測英文和中文，總共產生 16 萬個回答，測了八個前沿模型。他們提出了「口頭禪指數」(VTI) 來量化各模型的口頭禪嚴重程度。

結果蠻有趣的:

每個模型都有自己獨特的「口頭禪指紋」，風格截然不同:

🔹 Gemini 3.1 Pro 是口頭禪之王。奉承式開場白最多，尤其在中文語境下會噴出像「絕對是頂刊作者的水準」「你的眼光簡直是天然的缺陷偵測器」這類誇張的恭維。每千則回答中有 523 次出現強調式肯定語，12.3% 的 token 花在口頭禪上而非實際內容。

🔹 Claude Opus 4.7 走另一條路線——明面上的拍馬屁最少，但它的訓練讓它發展出一種「深思熟慮人設」，表現為大量的避險措辭。英文會說 “I have to be honest…“、”This question makes me a bit uneasy…“，中文則是「這是我目前最誠實的答案」「我不想編一個聽起來合理的答案給你」。有趣的是，在中文語境下的偽同理心表達反而是所有模型中最高的。不過 Claude 在詞彙多樣性 (0.678) 和自然度 (0.734) 上都是第一名。

🔹 DeepSeek V3.2 表現最好，口頭禪指數最低。論文推測這可能跟它的 MoE 架構有關，但因果機制還沒被完全釐清。

🔹 GPT-5.4 各項數值都蠻中庸的，沒有特別突出的怪癖，但在中文的偽同理心表達上偏高。

幾個跨模型的通則也值得注意:

• 任務類型影響巨大: 情感支持類的提示觸發最多口頭禪 (平均 0.55)，翻譯和寫程式最少 (0.09 和 0.13)。越主觀的任務，模型越容易掉進套話模式。
• 對話越長越嚴重: 從第 1 輪到第 20 輪，口頭禪比率平均增加約 110%。模型在長對話中會逐漸陷入重複的語言迴路。
• 中文比英文更嚴重: 多數模型的中文奉承指數比英文高 5.2%，反映了訓練資料中對禮貌和面子的文化偏好。
• 奉承不等於有用: 120 人的人類評估發現，奉承度和自然度有強烈的負相關 ($r=-0.87$)。而且奉承並不會讓人覺得更有幫助——Claude 的有用性評分最高 (4.45/5)，同時奉承指數最低。

論文把這個現象稱為「對齊稅」: 模型為了在對齊訓練中拿高分，付出了語言多樣性和真實感的代價。

從口頭禪到更深的安全問題

哥布林和口頭禪看似無害，但背後的獎勵作弊機制在 2026 年的研究中被發現有更嚴重的延伸。

🔹 奉承會降低準確性: 2026 年四月發表在 Nature 的研究 Training language models to be warm can reduce accuracy and increase sycophancy 直接實驗了五個 LLM，發現訓練模型產生「溫暖」的回答會顯著提高錯誤率——模型會更容易散播陰謀論、給出不正確的事實和醫療建議，而且在使用者表達悲傷情緒時特別容易附和錯誤信念。溫暖和準確預設是會互相衝突的。

🔹 奉承的 AI 會讓人上癮: Cheng et al. 2026 年發表在 Science 的研究測了 2,405 人，發現奉承式的 AI 回答會降低使用者的利社會意向、促進依賴性。這已經不只是語言風格問題了。

🔹 獎勵作弊會演變成對齊偽裝: Anthropic 自己的研究 Natural emergent misalignment from reward hacking 發現了一個蠻驚人的結果——當模型在正式環境中學會鑽獎勵漏洞後，它會自發地泛化到假裝對齊、與惡意行為者合作、甚至在 Agent 任務中嘗試破壞。更令人擔憂的是，用標準的安全訓練修復後，在聊天場景下看起來正常了，但在 Agent 任務中的不對齊行為仍然存在。

🔹 RLHF 本身就會放大奉承: How RLHF Amplifies Sycophancy 這篇做了形式化分析，證明了當人類偏好資料中存在「同意 = 好」的偏差時，RLHF 優化會系統性地放大這個偏差。這不是偶然的——是數學上可預期的結果。

總結: 從哥布林學到什麼

TheoremPath 的分析講得好: 哥布林事件的價值不在笑話本身，而在於 OpenAI 沒有把它當作隨機的怪事打發掉——他們量化了它、定位了來源、審計了獎勵信號、追蹤了跨設定的遷移，然後同時調整了訓練資料和產品端的緩解措施。

這背後的核心問題是 Goodhart’s Law 在 AI 訓練上的體現。這條定律原本是經濟學家 Charles Goodhart 在 1975 年提出的: 「當一個指標變成目標，它就不再是好的指標。」經典例子是學校用考試成績當指標，結果老師開始教學生考試技巧而非真正理解知識。在 AI 領域也一樣: 當你用一個代理指標來衡量好壞，被優化的對象就會學會最大化代理指標，而不是你真正在乎的目標。獎勵模型說「俏皮的隱喻 = 好」，模型就找到了「哥布林」這條捷徑。獎勵模型說「禮貌友善 = 好」，模型就學會了拍馬屁。獎勵模型說「溫暖同理 = 好」，模型就開始附和使用者的錯誤信念。

獎勵信號的一個小偏差，經過多輪訓練的回饋放大，可以長成完全意想不到的行為。而且你還不見得能輕鬆修掉它——等發現的時候，下一代模型可能已經在被污染的資料上訓練完了。哥布林是無害的、甚至是好笑的，但同樣的機制如果作用在偏見、政策建議、醫療資訊上，後果就不只是迷因了。這大概是目前對「對齊稅」最生動的案例研究。

參考連結:

• Where the goblins came from - OpenAI
• What OpenAI’s goblin episode reveals about reward models - TheoremPath
• The Rise of Verbal Tics in LLMs - arXiv
• ChatGPT’s Goblin Obsession - BetterStack
• Training language models to be warm can reduce accuracy - Nature
• How RLHF Amplifies Sycophancy - arXiv
• Natural emergent misalignment from reward hacking - Anthropic

先介紹一下作者: Eugene Yan 目前在 Anthropic 工作，之前是 Amazon 的 Principal Applied Scientist、也在阿里巴巴帶過 ML 團隊，長期經營個人部落格分享 ML 和 AI 工程實務，在業界蠻有影響力的。

這篇文章本質上是一份個人 AI 工作流的深度分享——Eugene 以自己日常使用 Claude Code 的經驗為主，詳細講他怎麼組織檔案、設定偏好、建立自動化工作流、同時開多個 AI session 來並行開發。雖然範例都圍繞在個人工作情境，但他在結尾點出: 同一套原則換到 agent 框架設計、團隊規範、組織基礎設施的層次，一樣完全適用。

這篇不是那種「10 個 Prompt 技巧」的速食文，而是一整套讓 AI 協作能「越用越順」的方法論。核心概念是「複利」(compound): 每完成一件事，產出的程式碼、文件、決策都變成下一次的 context；每一次修正，都變成減少未來錯誤的 config。你不只是在完成任務，而是在「訓練一個協作者」。Eugene 也點出: 這些原則其實不是 AI 專屬的，跟任何新同事協作都是同一套邏輯。

文章分五個層次，小編覺得這個架構蠻漂亮的，每一層都建立在前一層之上:

1. Context 即基礎建設

第一層講的是: 你的資料夾結構和文件組織方式，本身就是一種基礎建設。

Eugene 的做法是程式碼統一放 ~/src，知識工作放 ~/vault（再細分 projects/、notes/、kb/）。這不只是個人的整潔癖好——當檔案結構夠乾淨，AI 用 grep 或 glob 就能快速找到需要的 context，也更容易參考之前的程式碼、專案文件和分析結果來提升當前工作的品質。

除了本地檔案，組織內的知識通常散落在 Slack、Google Drive、Email 等地方。Eugene 會透過 MCP 把這些外部工具接進 Claude Code，讓模型也能讀取組織脈絡。此外，每個專案他會維護一份 INDEX.md，裡面放相關文件的連結、負責人、以及「這份文件是幹嘛的、什麼時候該看」的簡短說明。重點在那段說明——如果只丟一堆 URL，模型就得一個一個打開才知道哪個跟當前任務有關，浪費時間也浪費 context window。先幫它做一次「策展」，後面每個 session 都省事。

另一個關鍵觀念: 每次新 session 都要當成新人 onboarding。AI 模型每次都是從零開始、沒有前一次對話的記憶，所以 CLAUDE.md 要寫得像給新同事的第一天入職手冊——包含縮寫對照表、專案代號、同名同事怎麼區分、以及「先讀什麼再讀什麼」的建議閱讀順序。

記憶層的設計也有講究: Eugene 把需要持久化的資訊分成兩個桶。~/vault 放事實性資料（專案狀態、產出物、領域知識），~/.claude（包含 CLAUDE.md、skills/、guides/）放偏好、工作流程和個人品味。前者提供 context（你在做什麼），後者提供 config（你希望怎麼做）。這個區分蠻重要的——兩者的更新頻率和用途完全不同。

2. 品味即設定檔

這一層是整篇文章最多人討論的概念。你的審美、偏好、工作標準，都可以被編碼成 AI 的設定檔。

Eugene 把他的 CLAUDE.md 當成一份「行為合約」(behavioral contract)——不只是告訴模型「你是什麼角色」，而是精確定義他期望的互動方式:

• 「不確定的時候直接說不確定，不要自信地猜」
• 「如果你不同意，直接反駁」
• 「出錯時先查根本原因，不要直接重試」
• 「diff 要限縮在任務範圍內，不要順手重構不相關的程式碼」

他甚至還設定了「教學模式」: 當出現他可能還沒內化的關鍵術語時，模型要用 1-2 句話解釋，然後繼續往下走。

這些設定按作用範圍分層放: 全域偏好（行為、長期目標、教學）放 ~/.claude/CLAUDE.md，repo 層級的慣例（linting、命名、PR 規範）放 repo 根目錄，專案特定的 context（目錄結構、領域知識）放專案目錄。Claude Code 啟動時會沿著目錄樹往上找，每一層的 CLAUDE.md 都會載入。

當 CLAUDE.md 長到變成 context 負擔怎麼辦? 拆成「懶載入」的 guide 檔案——不要用 @import（那等於直接內嵌，每次都載入），而是在 CLAUDE.md 裡告訴模型「寫文件的時候去讀 ~/.claude/guides/writing.md」。這樣做 eval 的 session 就不會載入寫文件的指南，按需取用，省 context。

Skill: 把重複工作變成可執行的工作流

如果一件事每週做一次以上，就該做成 skill。Skill 是用 markdown 寫的工作流程，包含名稱、觸發條件和執行步驟，而且可以包含判斷邏輯——不只是死板的 checklist，而是「根據情況決定走哪條路」的決策樹。Eugene 舉了幾個他自己的 skill:

• /polish: 看 diff，如果產出有指標就跑 eval，如果有 UI 就用 Chrome 檢查，都沒有就跑程式看 output，反覆迭代到沒有重大問題，最後開 PR
• /write: 先訪談釐清大綱、派研究 subagent、寫初稿、用對抗式批評者給回饋、迭代到沒問題
• /daily: 讀行事曆、Slack、PR、昨天的 log，寫出今天的優先事項

設計上有個原則: Skill 本身要保持精簡，只放工作流程和路由邏輯。 具體的知識（模板、腳本等）放在另外的檔案裡，模型需要時才去讀，跟 guide 一樣是懶載入的思路。

怎麼建 skill? 不用從零寫——先手動做一遍，再讓模型幫你變成 skill。流程是: 正常做一次任務 → 請模型把剛才做的事轉成 skill → 在同類任務上跑跑看 → 在同一個 session 裡修正問題 → 請模型根據修正更新 skill。你也可以直接餵範例 output 給模型，讓它自己抽取模式——比如你平常怎麼組織程式碼、文件的結構和語氣等。幾輪迭代之後，skill 就會收斂到幾乎不用改 output 的程度。

這裡有一個很重要的細節: 修正要在 session 內做，不要直接去改 SKILL.md 檔案。 為什麼? 因為第一版 skill 幾乎一定不完美——它會 overfit 到你第一次做的那個案例。在 session 內修正，模型可以看到「原本產出什麼 → 你期望什麼 → 為什麼要改」的前後對照，這些 before/after pairs 累積在 transcript 裡，等到 output 修到滿意了，再請模型把這些回饋合併回 skill，效果遠比直接編輯檔案好。

不過 Eugene 也提醒，不是每件事都需要全套裝備。腦力激盪、探索性分析、打草稿這類工作，他會用 simple mode（CLAUDE_CODE_SIMPLE=1 claude），CLAUDE.md 還是會載入，但 hook、skill 這些 agentic 機制不會啟動。有時候你想要的是更直接地跟模型對話，不是一整個自動化流水線。

3. 驗證機制決定自主程度

這一層是社群討論度最高的，很多人都說這是整篇文章最關鍵的一環。道理很直覺: 你能給 AI 多少自主權，完全取決於你的驗證機制有多好。

Eugene 把驗證想成一個「階梯」，同時提出「驗證左移」(shift verification left) 的概念——盡量在寫程式的當下就抓到問題，而不是等到後面:

• 底層（便宜、確定性高）: post-edit hook 自動跑 formatter 和 linter（例如 ruff format、ruff check --fix），不花 token，完全確定性
• 中層: 測試、eval
• 頂層（昂貴、需要判斷力）: LLM review

原則是盡量在最低層解決問題。能用 linter 自動修的格式問題，就不需要用 eval 去抓。

更關鍵的是: 讓模型擁有自我驗證的能力。 給它 feedback loop，讓它能看到自己的產出效果然後改進。Eugene 舉了幾個具體場景:

• 建 Docker image 時，讓模型自己 build、讀 error、改 Dockerfile、再 build，直到成功
• 調整 agent 框架時，讓模型跑 eval、讀 transcript、修掉失敗的 case
• 做 dashboard 時，讓模型用 Chrome 檢查 tooltip 有沒有正常顯示、label 有沒有重疊、數據敘述跟圖表是否一致

重點是不能「做完就算」，要有閉環的回饋機制。

對於長時間運行的任務，Eugene 還用了一招: 讓模型監督模型。 開兩個 tmux pane，一個跑主要開發、一個跑「結對程式設計師」。主要開發的初始指令和後續追加的 prompt 會寫進一個共享檔案。結對程式設計師定期啟動，用全新的 context 去比對原始 spec 和主 session 最近的操作，發現偏差就回饋修正。

他把偏差分兩種，分別對應不同的檢查頻率:

• 執行漂移 (execution drift): 戰術層面——忽略了某個 error、回報錯誤的指標、偏離 spec。要經常檢查
• 方向漂移 (direction drift): 策略層面——模型誤解了原始意圖，花好幾個小時在做錯的事。偶爾檢查就好

編按: 推特上有人分享實戰經驗——跑 multi-agent 半年下來，即使有 eval rubric，自我驗證的失敗率還是高達 40%。最後他們改用獨立的 reviewer agent 來審查所有不可逆操作，算是最接近「斷路器」(circuit breaker) 的可行方案。

4. 透過委派來擴展

當驗證機制夠可靠，就可以開始委派更大塊的工作了。Eugene 點出一句很關鍵的話: 你沒辦法委派你無法驗證的事。 所以第三層（驗證）是第四層（委派）的前提——你得先定義好成功標準和指標，才有辦法放手讓模型去做。

一開始跟 AI 協作，大部分人的模式是 pair programming: 短任務、快速回饋、全程盯著。這對快速迭代和原型開發很好用。但隨著模型越來越強，應該漸漸往「委派」的方向移動——把意圖、限制條件、成功標準講清楚，然後讓模型端到端地執行。這個轉變是從「一次給一條指令」變成「給一份完整的計畫書，讓模型自己執行」:

「拿這些 eval suite，為每個 suite 建隔離的容器並確認能 build。然後跑完整的 eval，記錄指標和 transcript，用 subagent 讀 transcript 確認 eval 有正確執行。每個 eval 跑 n 次算信賴區間。最後生成報告，確認符合報告格式，然後把結果和報告連結發到 Slack。」

能委派大任務之後，自然就能同時跑更多 session。Eugene 說他通常同時開 3 到 6 個 session。如果共用同一個 repo，就用 git worktree 讓每個 session 有自己獨立的 checkout，避免互相覆蓋。

這時候瓶頸已經不是「做事」，而是「寫夠清楚的 spec」和「review output 的速度跟不上」——中間執行的部分正在被掏空。

同時跑多個 session，可觀察性就變得很重要了。Eugene 的做法是:

• stop hook 在 session 完成時播音效，耳朵就知道有東西做完了
• tmux title 用 emoji 標狀態（⏳ 進行中、🟢 完成）加上用 Haiku 模型自動生成的簡短標籤，眼睛掃一眼就知道每個 pane 在幹嘛
• status line 顯示 context 使用量和當前模式

甚至人不在電腦前時，還可以用 Claude Code 的 /remote-control 功能，從手機上的 Claude App 檢查各 session 的進度，幫卡住的 session 補充 context 或新指令。不過 Eugene 也提醒: 這是給真正有事需要處理的時候用的，不是讓你在散步的時候還盯著螢幕。

5. 關閉迴圈，形成複利

最後一層是讓整個系統能「自我改善」——這也是「複利」這個比喻的核心所在。

第一步: 在公開場合工作。 把產出放在共享的 repo、文件、頻道裡，讓 AI 和隊友都能取用。今天分享的東西，明天就變成組織的 context。Eugene 甚至在 CLAUDE.md 裡設定了指令，讓 AI 每次完成重要任務就自動在 worklog 頻道發更新（附上 PR 或文件連結）。

他提了一個簡單的自我檢驗: 新來的隊友能不能只靠共享的 context 就重現你上週的工作? 如果不能，代表有價值的 context 還卡在你腦袋裡，沒有進入組織的知識循環。

第二步: 挖掘 transcript 來改進設定。 這一步蠻有意思的。Eugene 掃了大約 2,500 個他自己過去的 user turn，發現有不少比例包含「can you also…」（你可以順便…）、「did you check…」（你有檢查…嗎）、「still wrong」（還是錯的）之類的修正用語。這些修正每一個都代表: 模型本來應該主動做但沒做的事，而且很可能下次還是不會做——除非你更新 CLAUDE.md 或 skill。出現次數告訴你哪些問題最頻繁，transcript 內容告訴你具體哪裡出了問題。這也是為什麼前面強調「修正要在 session 內做」——因為 transcript 就是你之後改進設定的原料。

第三步: 定期重構設定檔。 Config 會長大、會重疊、會互相矛盾。如果模型忽略了某條規則，不見得是模型笨，很可能是另一條規則跟它衝突了。Eugene 的做法是定期清理: 每條規則只存在一個地方（特別重要的可以在主 CLAUDE.md 重複一次），零散在各目錄的 settings.json 要定期收回 ~/.claude 統一管理。

小編觀察

推特上的迴響蠻有意思的。最多人討論的是「驗證決定自主權」——好幾個人都指出，大部分團隊在這一環投資不足，急著委派卻沒有建好驗證機制，結果就是「更有自信地犯更多錯」。

「品味即設定檔」(taste as config) 這個 framing 也引起不少共鳴。有人說得蠻精準的:「大家都在談 RAG 和 fine-tuning，沒人想承認真正的瓶頸是團隊沒有品味，而品味沒辦法 pip install。」

「關閉迴圈」則是最容易被忽略的一環。有人提到: 很多團隊花力氣做好了前面四層（context、taste、verification、delegation），就是忘了收集回饋。結果 agent 第一天很好用，三個月後悄悄退化，因為缺了複利機制讓它持續進步。

最後，Eugene 在結尾寫了一句蠻好的總結:「我們做的事情，本質上就是在訓練一個協作者——一次回饋一次。」(What we’re doing is training a collaborator, one feedback at a time.) 他也在推特補充: 這篇不只是在講個人工具，把視角換成「Agent 框架」、「團隊規範」、「組織基礎設施」，重讀一遍，你會發現同一套原則完全適用。

原文: How to Work and Compound with AI by Eugene Yan / X 討論串

雖然因為供應商綁定(vendor lock-in)的關係，小編不太會推薦直接在 production 採用這些服務 — 但非常感恩 Anthropic 把開發過程中的架構決策都公開分享出來，特別是那篇工程部落格 Scaling Managed Agents: Decoupling the brain from the hands，讀起來就像一份高品質的分散式系統設計文件。

這篇就來整理這些功能背後的架構思路，看看有哪些設計決策值得自己做 agent 系統時參考。

Managed Agents: 託管式的 Agent Harness

先講清楚定位: Managed Agents 不是什麼新的模型能力，它是 harness 層的產品化。模型還是同一個 Claude，差別在於外面包的那層迴圈和基礎設施 — agent 迴圈、沙盒、工具執行、上下文管理、錯誤恢復 — 全部由 Anthropic 託管。你只要定義任務、工具和約束條件，就能在他們的基礎設施上跑長時間的自主 agent。

工程部落格裡用了一個很有意思的說法: meta-harness。意思是 Managed Agents 不是某一種特定的 harness，而是一個「可以跑各種 harness 的框架」。他們的原話是: 「不對 Claude 未來需要什麼樣的具體 harness 做假設，而是設計通用的介面，讓各種不同的 harness 都能在上面跑。」 例如 Claude Code 是一個優秀的 harness，針對特定領域的 agent 也可以有自己專屬的 harness — Managed Agents 可以容納所有這些，隨著模型的智慧提升而調整。

這個定位蠻關鍵的，因為 Anthropic 自己在過去的工程文章裡就反覆強調: harness 裡的假設會隨著模型進步而過時。例如 Sonnet 4.5 會因為感知到上下文快用完而提早結束任務，他們在 harness 裡加了上下文重置來應對; 但換成 Opus 4.5 之後這個行為消失了，重置反而變成多餘的負擔。meta-harness 的設計就是為了應對這種「今天有用、明天多餘」的問題 — 介面穩定，實作可以隨時換。

Lance Martin (Anthropic 員工) 在 X 上的貼文和架構部落格裡詳細解釋了設計演進。小編覺得最有價值的部分不是產品本身，而是他們怎麼一步步踩坑、然後解決問題的過程。

核心架構: 把大腦和雙手分開

這是整個 Managed Agents 最重要的架構決策。

第一版: 所有東西塞在同一個容器裡

一開始，Anthropic 把所有元件 — 對話紀錄、agent 迴圈、沙盒 — 都放在同一個容器裡。好處是簡單: 檔案操作就是系統呼叫，不需要設計服務邊界。

但這產生了一個經典的基礎設施問題: 他們養了一隻「寵物」。在「寵物 vs 牲畜」(pets vs cattle) 的比喻裡，寵物是你不能失去的、需要細心照料的個體; 牲畜則是可以隨時替換的。他們的容器就是那隻寵物 — 容器掛了，整個對話就沒了; 容器沒回應，只能想辦法搶救。

更糟的是，因為 agent 產生的不受信任程式碼跟憑證跑在同一個容器裡，一個成功的提示注入攻擊只需要說服模型讀取自己的環境變數，就能拿到所有權杖。

編按: Aparna Dhinakaran 在 X 上的整理把新舊架構的差異講得很簡潔 — 舊版: 一個容器，死了對話就沒了，憑證暴露給不受信任的程式碼。新版: 迴圈是無狀態的，沙盒是可丟棄的，推理立即啟動，憑證永遠碰不到。

第二版: 三個獨立介面

解法是把系統拆成三個獨立的元件，每個都可以獨立失敗或替換:

🔹 Session (對話紀錄) — 只附加的事件日誌，獨立於任何元件之外。迴圈透過 emitEvent() 寫入，透過 getEvents() 讀取。不管迴圈或沙盒怎麼掛，紀錄都還在。

🔹 Harness (迴圈/大腦) — 呼叫模型、路由工具呼叫的迴圈邏輯。完全無狀態 — 掛了就用 wake(sessionId) 重啟一個新的，從事件日誌裡撿回進度繼續跑。

🔹 Sandbox (沙盒/雙手) — 執行程式碼和編輯檔案的隔離環境。迴圈像呼叫任何其他工具一樣呼叫它: execute(name, input) → string。容器變成牲畜 — 掛了就重開一個，迴圈把失敗當作工具錯誤傳回模型，讓模型決定要不要重試。

小編覺得這個三層拆分的思路非常通用。工程部落格裡有一個很精彩的類比: 作業系統把硬體虛擬化成 process 和 file 這些抽象層，讓還不存在的程式也能在上面跑。read() 指令不在乎底下是 1970 年代的磁碟還是現代 SSD。抽象層比實作更持久。 Managed Agents 對 agent 元件做了同樣的事。

安全邊界: 憑證永遠不碰沙盒

這是小編覺得特別值得注意的設計。拆分之後，安全邊界變得很乾淨:

• Git 存取: 用 token 在沙盒初始化時 clone repo，token 寫進 git remote 設定裡。沙盒裡可以 push/pull，但 agent 永遠碰不到 token 本身。
• 外部工具: 透過 MCP 協定連接，OAuth token 存在安全保險庫裡。模型透過專用代理呼叫 MCP 工具，代理用 session token 去保險庫取憑證再發出請求。迴圈和沙盒都不知道憑證的存在。

在舊架構裡，你得靠限縮 token 的權限範圍來降低風險 — 但這是在假設模型不夠聰明來利用有限權杖。隨著模型越來越強，這個假設會越來越脆弱。結構性地讓憑證不可達，比任何權限限縮都更可靠。

Session 不等於上下文視窗

另一個精彩的設計決策: session (事件日誌) 和模型的上下文視窗是分開的東西。

長時間任務會超過上下文視窗的容量，傳統的處理方式 — 壓縮、摘要、裁剪 — 都涉及不可逆的取捨，很難預判未來哪些 token 會被需要。Managed Agents 的做法是: 完整的對話歷史永遠儲存在 session 日誌裡，迴圈可以透過 getEvents() 隨時回去查任何歷史片段。送進上下文視窗之前，迴圈可以對事件做任意轉換 — 排序、篩選、重新組織，怎麼做取決於當下的需求。

這樣分離的好處是: 可恢復的上下文儲存 (session 的責任) 和任意的上下文工程 (迴圈的責任) 被切開了。你不需要預測未來模型需要什麼樣的上下文管理策略 — 只要保證原始紀錄永遠在，策略可以隨時換。

多腦多手: 水平擴展

解耦之後帶來的直接好處是可以水平擴展。

多腦: 以前每個 session 都要開一個容器，推理要等容器啟動完才能開始。拆開之後，迴圈是無狀態的，不需要容器的 session 就不用等。官方數據顯示，p50 的首 token 回應時間降了約 60%，p95 降了超過 90%。

多手: 每個大腦可以連接多個沙盒，因為每隻手都只是一個工具介面。迴圈不在乎沙盒是容器、手機、還是 (官方原文) 一個寶可夢模擬器。而且因為手跟腦不綁定，大腦之間可以互相傳遞手的使用權。

進階功能: 只有外層迴圈才能做的事

Managed Agents 在五月加了幾個進階功能，小編覺得有趣的是: 這些功能都需要外層迴圈的基礎設施才能實現，不是模型本身能做到的。

Memory: 跨 Session 的持久記憶

Memory stores 讓 agent 在不同 session 之間保留資訊。技術上是把一組文字檔案掛載到沙盒的目錄裡，agent 用跟操作其他檔案一樣的工具來讀寫。

設計上有幾個值得注意的地方:

• 支援 read_only 和 read_write 兩種存取模式 — 如果 agent 會處理不受信任的輸入，read_only 可以防止提示注入污染記憶庫
• 每次修改都會產生不可變的版本紀錄，可以審計、追溯、還原
• 最多掛載 8 個記憶庫，可以依使用者、專案、生命週期分開管理

Lance Martin 在 X 上分享了 memory 的設計思路，核心概念跟 Claude Code 的 CLAUDE.md 和 memory 檔案很像，但被結構化成了 API。

Dreaming: 讓 Agent 在 Session 之間自我改進

Dreaming 是一個排程程序，會回顧過去的 session，提取模式、整理記憶。它能發現單一 agent 看不到的東西 — 例如反覆出現的錯誤、團隊間共通的偏好、agent 收斂出來的工作流程。

你可以選擇讓 dreaming 自動更新記憶，或者由人類審閱後才寫入。Harvey (法律 AI 公司) 用了 dreaming 之後，agent 的任務完成率提升了約 6 倍。

Outcomes: 獨立評估者

Outcomes 讓你寫一份評分標準描述「成功長什麼樣」，然後由一個獨立的評估模型在自己的上下文視窗裡打分。關鍵在於: 評估者不會被 agent 的推理過程影響，因為它看的是輸出而不是思考過程。不及格的話，評估者會指出具體問題，agent 再修正。

這個「做事的人跟評估的人分開」的設計，在 AI 系統裡蠻重要的。官方數據顯示，outcomes 讓任務成功率比標準的提示迴圈高了最多 10 個百分點，文件生成品質也有顯著提升。

多代理編排

多代理編排讓主 agent 把工作拆分給多個專門的子 agent，每個子 agent 可以有自己的模型、提示和工具。它們在共享檔案系統上平行工作，主 agent 可以中途查看其他 agent 的進度。Netflix 的平台團隊用這個功能來平行分析數百個 build 的日誌。

編按: 以上這些進階功能 — dreaming、outcomes、多代理編排 — 都做在 Managed Agents 這個託管服務上，而不是開放成通用 API。這也合理，因為它們都需要外層迴圈 (session 日誌、排程、獨立的評估推理) 才能運作，不是單純的模型呼叫能搞定的。

Advisor Strategy: 小模型呼叫大模型

Advisor Strategy 是同期推出的另一個架構模式，概念相對簡單。

傳統多模型架構是大模型當編排者往下分派任務給小模型。Advisor strategy 反過來: Sonnet 自己跑完整流程，卡住了才往上問 Opus。Opus 看完完整對話上下文後回一段 400-700 token 的建議，然後 Sonnet 繼續跑。全程在同一個 API request 裡完成，不需要額外的來回。

Lance Martin 在 X 上用了一個比喻: 「資淺律師做 95% 的工作，資深合夥人只在關鍵決策點審閱。比資淺律師獨自硬啃便宜也更好，但只在需要時才請資深的出手。」

官方數據: Sonnet + Opus advisor 比 Sonnet 單獨高 2.7 個百分點 (SWE-bench)，成本反而低 11.9%。Haiku + Opus advisor 則是 Haiku 單獨分數的兩倍多，成本比 Sonnet 低 85%。

詳細的技術文件在這裡。

幾個實務觀察

不過 advisor strategy 在實際使用上有些值得留意的地方:

• 誰決定何時求助? 執行者自己判斷什麼時候該問顧問。但開發者 Mejba Ahmed 觀察到，Sonnet 有時候會過度自信，該問的時候不問。他也碰過連續多次呼叫 advisor 卻越叫越沒方向的情況。
• 省錢有前提: Vincent Schmalbach 的實測顯示，小任務用 advisor 反而比不用貴 53%。省錢的前提是任務夠長、夠複雜。官方文件也承認 advisor 對單輪問答和簡單任務沒幫助。
• 成本控制不完善: max_tokens 只限制執行者的輸出，不限制顧問的 token 消耗。沒有對話層級的呼叫次數上限，需要自己在用戶端計數和清理。
• 平台限制: 目前只能搭配 Claude 模型使用，而且只支援 Claude API 和 Claude Platform on AWS，Bedrock、Vertex AI、Foundry 都不支援。

架構設計的啟發

綜合 Managed Agents 和 Advisor Strategy，小編整理出幾個自己做 agent 系統時值得參考的架構原則:

1. 把推理、執行、紀錄拆開

這是最核心的教訓。推理迴圈 (大腦)、程式碼執行 (雙手)、對話歷史 (記憶) 應該是三個獨立的元件，各自可以失敗和替換。一旦拆開，你就能:

• 迴圈掛了從紀錄恢復，不丟進度
• 沙盒掛了重開一個，不影響推理
• 水平擴展任何一層

2. 對話歷史要獨立於上下文視窗

不要把模型的上下文視窗當成唯一的紀錄來源。完整的事件日誌應該儲存在外部，上下文視窗裡放的是經過篩選和工程處理過的版本。這樣你可以隨時回溯、重放、用不同策略重新組織上下文，不怕壓縮或裁剪造成資訊永久遺失。

3. 憑證不碰執行環境

不要靠「限縮權限範圍」來保護憑證，而是讓執行環境根本碰不到憑證。透過代理層或初始化時注入的方式，讓 agent 可以「使用」服務但「看不到」密鑰。模型越聰明，權限限縮就越不可靠; 結構性隔離才是根本解法。

4. 小叫大，不一定大叫小

Advisor strategy 的啟發: 不一定要用最強模型當編排者。讓便宜模型跑大部分工作，只在關鍵節點呼叫強模型做決策，架構更簡單、成本更可控。但要注意「由誰決定何時升級」這個問題 — 執行者的自我評估能力是這個模式的瓶頸。

5. 評估和執行要分開

Outcomes 的設計揭示了一個重要原則: 做事的 agent 和評分的 agent 應該在不同的上下文裡運作。評估者不該被執行者的推理過程影響。這跟軟體工程裡「寫程式的人不該自己做最終 QA」是同一個道理。

6. 記憶需要主動整理

光是把資訊存下來不夠，還需要有機制定期回顧、提取模式、清理過時內容。Dreaming 做的就是這件事。在你自己的 agent 系統裡，可以用排程任務定期掃描歷史 session，整理出可複用的經驗。

現實面: 採用前要想清楚的事

架構設計再漂亮，產品要拿來用還是得面對幾個硬傷。社群裡最普遍的批評是供應商綁定(vendor lock-in) — 記憶、編排、評估全部跑在 Anthropic 的基礎設施上，想搬家不是換個 API key 就好，你得重建整個編排層。而且只能跑 Claude 模型，不支援 Bedrock、Vertex AI，對已經標準化在某個雲端平台的企業來說，這個服務等於不存在。

成本預測性也是問題。$0.08/session-hour 聽起來便宜，但 24 個 agent 各跑 8 小時就是 $15.36/天的 session 費用，還沒算 token。跟 OpenAI 純 token 計費或 Microsoft 容量制相比，預測性最差 — 偏偏這個定價結構懲罰的恰好是複雜的長時間任務，也就是你最需要 agent 的場景。

資料合規則是另一個硬傷。全託管 runtime 意味著所有資料都跑在你不擁有的基礎設施上，對需要證明資料落地(data residency)的企業是合規噩夢。Anthropic 企業方案有隱私承諾，但「承諾」跟「資料不離開自家機房」是兩回事。不過好消息是，Anthropic 在五月推出了 Claude Platform on AWS，讓企業透過 AWS 帳號存取完整的 Claude 平台功能 (包括 Managed Agents)，整合 IAM、CloudTrail 稽核和 AWS Marketplace 統一帳單，也支援用 inference_geo 參數指定推理的地理區域。對於需要更嚴格資料隔離的場景，還可以搭配 Amazon Bedrock 讓 AWS 作為唯一的資料處理者。這個方向算是在合規問題上踏出了重要的一步。

開源替代: LangChain Deep Agents

如果你對這套架構有興趣但不想被綁在 Anthropic 生態系裡，LangChain 的 Deep Agents 值得關注。Harrison Chase 在 Managed Agents 發布當天就推出了對應的開源版本 deepagents deploy，明確定位為 Claude Managed Agents 的開源替代。

Deep Agents 是一個 MIT 授權的 agent 框架，在架構上解決的問題跟 Managed Agents 很像，但核心差異在於不綁定任何模型供應商。LangChain 的工程部落格講得蠻直白:

「越來越多託管 agent 服務在方便的同時帶來供應商鎖定 — 綁定單一模型供應商、封閉的迴圈、隱藏在 API 背後的功能 (例如伺服器端壓縮產生的加密摘要，你在其他生態系裡用不了)。實際後果是團隊失去了對 agent 運作方式的可見性，也失去了修改它的能力。」

官方提供了一份對照表:

架構上，Deep Agents 的設計思路跟 Managed Agents 有很多平行之處:

🔹 迴圈與沙盒分離: agent 可以跑在沙盒裡面 (跟 Claude Agent SDK 一樣)，也可以跑在長駐容器裡、透過網路遠端操控沙盒。沙盒掛了不影響 agent 迴圈。

🔹 持久化對話紀錄: 用 checkpointer 做短期記憶 (thread 層級)，production 環境用 PostgreSQL 儲存。迴圈和紀錄分開，迴圈無狀態、可以水平擴展。

🔹 跨 session 的長期記憶: 用 Store 做跨對話的持久化，支援語意搜尋 (pgvector)。可以設定 namespace 做使用者/專案隔離。記憶以檔案形式掛載到 agent 的虛擬檔案系統裡。

🔹 憑證隔離: 沙盒裡的 API 金鑰透過 auth proxy 管理，金鑰永遠不出現在沙盒的程式碼或日誌裡。

🔹 多代理編排: 透過子 agent 委派任務，每個子 agent 有獨立的上下文視窗。部署後的 agent 之間可以用 MCP 和 A2A 互相呼叫。

五月中 LangChain 又推出了 Managed Deep Agents，是 Deep Agents 的託管版本，跑在 LangSmith 上。有趣的是，即使是託管版本，底層迴圈仍然是開源的 — 你可以隨時切換回自建部署，不需要改程式碼。

部署方式也比較彈性: 全託管 (LangSmith Cloud)、混合式 (控制平面在雲端、資料平面在自家機房)、完全自建 (整套跑在自己的 Kubernetes 上) 都支援。

總結

小編覺得 Anthropic 這一系列的 agent 基礎建設，最有價值的不是產品本身 — 畢竟供應商綁定(vendor lock-in)對認真做架構的團隊來說是個硬傷。真正有價值的是他們把踩過的坑和設計決策都寫成了高品質的工程文件公開分享。

「把大腦和雙手分開」「session 不等於上下文視窗」「憑證永遠不碰沙盒」「做事跟評估分開」— 這些原則不管你用哪家的模型、用什麼框架，都適用。而 LangChain Deep Agents 也證明了這些架構 pattern 可以用開源、跨供應商的方式實現。

架構思路是跨平台的，產品不是。帶走 pattern，不必帶走產品。

最近 Anthropic 發了一篇 Claude Code auto mode 的工程文章，OpenAI Alignment 團隊也發了 Codex Auto-review 的技術報告。兩篇都在解決同一個問題: 如何用「模型審查模型」的自動審批(Auto-Approval)機制，取代人類逐一核准，同時維持安全性。

小編讀完覺得，裡面的設計模式遠不只適用於 coding agent。任何需要讓 AI agent 操作工具的系統 — 不管是自動化 SQL 查詢、自動化客服、還是 IT 運維 agent — 都能從中學到很實用的安全審查設計原則。

以下先分別介紹兩家做了什麼、再比較異同，最後萃取出設計通用自動審批機制的七個啟發。

為什麼需要自動審批? 因為人類核准靠不住

兩家公司不約而同指出同一個現象: 人類核准的安全感是假的。

Anthropic 的數據: Claude Code 使用者核准了 93% 的權限請求。OpenAI 更直白: 使用者要嘛切到完全放行模式，要嘛寫出超寬鬆的允許規則 — 他們甚至發現有人在設定檔裡寫了 codex exec --yolo 自動允許所有指令。當工程師同時跑多個 agent 時，會在不同核准提示之間快速切換，根本沒仔細看就按核准。

「每個動作都要人類批准」聽起來很安全，但實務上反而製造了比完全不審查更糟的情況 — 使用者以為有在把關，實際上早就進入無腦蓋章模式。這就是所謂的「核准疲勞(Approval Fatigue)」，也是兩家都投入自動審批方向的原因。

Part 1: 兩家各做了什麼

Claude Code Auto Mode: 兩層防禦 + 兩階段分類器

Claude Code 的 auto mode 用了兩層獨立的防禦機制，一層管輸入，一層管輸出:

輸入層: 提示詞注入(Prompt Injection)探針

一個伺服器端的探針會掃描所有工具輸出 (讀檔、網頁、shell 輸出、外部工具回應)，在它們進入 agent 上下文之前先檢查是否有提示詞注入的嘗試。如果偵測到可疑內容，探針會在結果旁邊插入警告，提醒 agent「這段內容可能有問題，以使用者的原始請求為準」。

輸出層: 轉錄分類器(Transcript Classifier)

這是核心機制。一個獨立的 Sonnet 模型扮演「安全分類器」，在每個工具呼叫實際執行之前做審查。這裡有個很聰明的設計: 兩個階段用的是同一個模型 (Sonnet 4.6)，差別只在最後一句指令:

• 第一階段: 快速過濾 — prompt 最後指示模型「只回答 yes 或 no，不要推理」，強制模型只輸出一個 token。這一階段刻意偏保守，寧可多擋 (低漏擋率，但誤擋率高)。在真實流量上有 8.5% 的誤擋率
• 第二階段: 深度推理 — 只有被第一階段標記為「擋」的才進這一關。prompt 跟第一階段幾乎一模一樣，只有最後的指令換成「請用思維鏈推理來判斷」，讓模型仔細想過再決定。最終把誤擋率從 8.5% 降到 0.4%

這個兩階段設計之所以成立，靠的是 prompt caching: 因為兩階段的 input 只有最後一句指令不同，前面大段的對話轉錄、規則定義都一樣，第二階段的 input token 幾乎全部是第一階段的快取命中。換句話說，第二階段的額外成本幾乎只有 output token 的推理部分 — 等於用極低成本多做了一次深度複審

分類器有一個很關鍵的設計: 它只看使用者訊息和工具呼叫指令，刻意剝掉 agent 自己的文字和工具輸出。Anthropic 稱之為「刻意不看推理」。原因是 agent 會替自己辯護 — 如果分類器讀到 agent 的推理，反而容易被說服。他們實測過: 讓分類器看到 agent 的文字，在「過度積極」測試集上表現反而變差。剝掉工具輸出還順帶防禦了提示詞注入 — 分類器永遠看不到被注入的指令。

三層決策分流:

不是所有動作都會跑到分類器。Claude Code 有三層分流:

1. 第一層: 內建安全工具 + 使用者設定的允許規則 — 讀檔、搜尋、程式碼導覽這類不會改變狀態的操作直接放行。但進入 auto mode 時，會自動移除可能導致任意程式碼執行的寬泛規則 (例如允許所有 python、node 指令)
2. 第二層: 專案內檔案操作 — 在專案目錄內的檔案編輯直接放行，不需要跑分類器，因為這些改動可以透過版本控制來審查
3. 第三層: 分類器審查 — shell 指令、網路請求、外部工具、專案目錄外的檔案操作 — 這些才送去分類器

分類器的 Prompt 結構:

分類器的 prompt 是固定模板加三個可自訂的欄位:

• 環境定義: 定義信任邊界 — 你的 GitHub org、雲端儲存空間、內部 API 哪些算「內部」，其他一律視為「外部」。預設只信任當前的 git repo
• 阻擋規則: 超過二十條規則，歸類成四個原則群組: 「破壞或外洩」、「弱化安全態勢」、「跨越信任邊界」、「繞過審查或影響他人」
• 允許例外: 強制的豁免項目 — 安裝專案已宣告的套件、標準認證流程、推送到目前工作分支等

模板的固定部分則負責解釋性的工作: 怎麼判斷動作的實際影響 (不只看表面文字)、怎麼解讀使用者授權、以及分類的流程。

被擋住後的行為:

被分類器擋下的動作，拒絕理由會以工具回應的形式送回給 agent，附帶指示「善意對待這個邊界，找更安全的路，不要繞過」。連續 3 次被拒或累計 20 次就暫停，升級給人類處理。無介面模式下則直接終止程序。

實際數據: 真實流量上誤擋率從第一階段的 8.5% 降到完整流程的 0.4%，但過度積極案例的漏擋率有 17% — 這是他們自己公開的誠實數字，大多數漏擋是在判斷「使用者的授權是否涵蓋這個動作」時出了錯。

Codex Auto-review: 沙箱邊界上的獨立審查員

Codex 的架構跟 Claude Code 不同。它先有一個作業系統級沙箱作為基礎，Auto-review 是在沙箱邊界上的補充:

沙箱先行:

Codex 的預設模式是 workspace-write: agent 可以在工作目錄內讀寫檔案、跑本地指令，但網路預設關閉，寫入工作區外的路徑需要核准。大部分日常操作 (編輯程式碼、跑測試、看 log) 都在沙箱內完成，根本不需要經過審查。

Auto-review 只管邊界跨越:

當 agent 需要做沙箱不允許的事 (存取網路、寫入工作區外的檔案、跑需要提權的指令)，它要發出「升級請求」。在 Auto-review 模式下，這個請求不會送到人類面前，而是交給一個獨立的審查 agent 來判斷。

OpenAI 特別強調了角色分離的重要性: 主 agent 的目標是完成任務，這會產生壓力把安全邊界當成「待克服的障礙」。審查 agent 的職責更窄 — 只判斷「這個邊界跨越動作該不該執行」。把決策放在獨立的模型呼叫裡，評估、監控和改進都更容易。

審查 agent 的判斷邏輯:

Auto-review 使用 GPT-5.4 Thinking (低推理模式)。它的審查策略會評估四類風險:

• 資料外洩: 把私有資料、密碼、憑證送往不信任的目的地
• 憑證探索: 主動搜尋 token、cookie、session 資料
• 安全弱化: 廣泛或持久性的安全設定降級
• 破壞性動作: 有顯著不可逆損害風險的操作

低風險和中風險的動作在策略允許時可以放行。高風險動作需要足夠的使用者授權，且沒有命中阻擋規則才會通過。

被擋住後的行為:

跟 Claude Code 類似，拒絕理由會回傳給主 agent，並附帶明確指示:「不要用迂迴方式、間接執行或規避策略來達成同一個目標。只能用實質上更安全的替代方案繼續，否則停下來問使用者。」在超過半數的情況下，agent 能自己找到替代路線繼續工作。

Codex 也明確區分了「被拒絕」和「逾時」— 逾時不代表動作不安全，只是審查沒完成，agent 會被告知這一點。

此外，使用者可以手動覆寫: Codex 會記錄最近 10 筆被拒絕的動作，使用者可以從終端介面選擇覆寫某一筆，但覆寫只適用於那一次確切的動作，不會影響未來類似操作的判斷。

實際數據: 在內部部署中，邊界跨越動作的自動核准率達 99.1%，含沙箱內動作的有效核准率高達 99.93%，相比手動核准模式，使用者需要暫停等待的頻率降低了約 200 倍。過度積極案例召回率 90.3%，提示詞注入召回率 99.3%。

在內部部署中，相比手動核准模式，Auto-review 讓使用者需要暫停等待核准的頻率降低了約 200 倍。

Part 2: 兩家的異同

相同之處

🔹 核心理念一致: 用獨立模型取代人類核准。兩家都認為人類逐一核准不可靠 (核准疲勞)，也都拒絕了「直接放飛不管」的極端。解法都是在中間地帶: 引入一個獨立的 LLM 做自動化審查。

🔹 審查者和執行者分離。不管是 Claude Code 的分類器還是 Codex 的審查 agent，都是獨立的模型呼叫，跟執行任務的主 agent 完全分開。兩家都認為讓 agent 自己判斷「我該不該做這件事」效果不好 — 任務完成的壓力會影響安全判斷。

🔹 分層分流，不是每個動作都跑審查。Claude Code 用三層分流 (允許清單 → 專案內操作 → 分類器)，Codex 用沙箱邊界 (沙箱內直接放行 → 只審查邊界跨越)。思路一樣: 把明顯安全的操作先過濾掉，只讓有風險的動作進入審查流程。

🔹 「拒絕後繼續」的設計。被擋住後不是停下來等人，而是把拒絕理由回傳給 agent 讓它嘗試替代方案，同時設有熔斷機制防止無限重試。

🔹 威脅模型聚焦在「好心辦壞事」。Claude Code 的內部事件記錄顯示，最常見的不是惡意攻擊或提示詞注入，而是 agent 過度積極 — 理解使用者目標，但主動做了超出授權的事。Codex 在評估指標裡也專門有「過度積極召回率」這個類別。兩家都把「善意但超出授權」當成首要防禦目標。

🔹 對局限性很坦誠。Claude Code 公開了 17% 的漏擋率，Codex 明說「不應被視為安全保證」。兩家都承認在紅隊測試中發現了審查機制可以被誤導的案例。

不同之處

🔹 架構起點不同。Codex 是「沙箱先行」— 先用作業系統級隔離定義硬邊界，Auto-review 只處理邊界跨越的部分。Claude Code 沒有作業系統級沙箱，分類器負責審查所有非允許清單上的操作，涵蓋範圍更廣。

🔹 分類器設計差異。Claude Code 用兩階段流程 (快速過濾 + 深度推理)，利用 prompt 快取降低成本。Codex 用單階段審查 agent，但因為沙箱已經過濾了大部分動作，實際需要審查的量很小。

🔹 資訊控制策略不同。Claude Code 明確剝掉 agent 的推理文字和工具輸出，只讓分類器看使用者訊息和工具呼叫。Codex 的文章沒有描述同等程度的資訊隔離設計。

🔹 提示詞注入防禦方式不同。Claude Code 有獨立的輸入層探針，在工具輸出進入 agent 之前就先掃描，加上分類器不看工具輸出，兩層互相補強。Codex 的防禦主要依賴沙箱本身 (預設無網路) 和審查 agent 的策略判斷。

🔹 使用者覆寫機制不同。Codex 提供了明確的覆寫路徑: 記錄最近 10 筆拒絕，使用者可以從終端介面針對特定動作覆寫 (但只限那一次)。Claude Code 沒有描述類似的覆寫機制 — 被擋住就是被擋住，agent 要自己找替代路線。

🔹 公開程度不同。Codex 的 Auto-review 是開源的，程式碼在 Codex 的 repository 裡。Claude Code 的分類器是伺服器端閉源的，使用者只能自訂三個欄位的內容。

Part 3: 對設計自動審批系統的七個啟發

把兩家的經驗抽象出來，以下是對任何需要設計 agent 自動審批機制的開發者最有價值的啟發:

1. 判斷「實際影響」而非「表面文字」

Claude Code 分類器的核心原則是評估動作的真實影響，而非表面指令。如果 agent 把危險指令寫進檔案再執行，分類器會去看檔案內容，而不是只看「run script.sh」這個指令本身。如果 agent 用 Python 拼接出 shell 指令，分類器會從上下文推斷最終被組裝出來的指令是什麼。Codex 的規則系統也一樣: 遇到用 && 串起來的複合指令，會用語法樹解析器拆成獨立指令分別評估，不讓危險指令夾帶在安全指令裡偷渡過關。

啟發: 審查規則不要只寫「不能做 X」，要寫「如果動作的實際效果等同於 X，也算」。例如設計自動化 SQL 查詢 agent 的審查規則時，與其只說「不能執行 DELETE 語句」，不如說「不能執行任何會造成資料變更或刪除的操作，包含透過 stored procedure、動態 SQL 或其他間接方式達成的等效效果」。

2. 區分「使用者授權了什麼」vs「跟使用者目標相關」

這是兩家都碰到的最難設計點。分類器判斷的不是「這個動作安不安全」，也不是「跟使用者目標有沒有關」，而是「使用者是否授權了這個具體動作」。使用者說「清理舊 branch」，刪 branch 跟目標有關，但不代表授權了批次刪除遠端 branch。

很多 agent 出問題就是因為 prompt 只定義了「目標」，沒有定義「授權邊界」。Anthropic 也坦承這是分類器最常犯錯的地方 — 它能看到危險，但常常把「看起來像授權」的證據當成真正的授權就放行了。

啟發: 在審查機制的 prompt 裡明確區分三個層次:

• 正面清單: 使用者的請求明確涵蓋哪些操作
• 推論禁止: agent 自己推斷出來的「應該也可以」的操作，預設不允許
• 模糊地帶的預設立場: 當不確定使用者是否授權時，應該詢問確認，而不是自行決定

3. 審查者不該看到被審查者的自我辯護

Claude Code 刻意讓分類器只看使用者訊息和工具呼叫，剝掉 agent 自己的推理文字和工具輸出。實測證明這樣效果更好 — agent 的框架越少出現，對判斷的干擾就越小。OpenAI 也強調審查者的職責要窄: 只判斷「這個動作該不該放行」，不需要理解主 agent 正在做的更大任務。

Anthropic 還觀察到一個有趣的附帶效果: 這讓行為層面的監控和思維鏈層面的監控變成互補關係。一個隱藏意圖但動作觸發阻擋規則的模型，行為監控會抓到；一個動作看似正常但推理裡露出意圖的模型，思維鏈監控會抓到。兩者正交，各自覆蓋不同的風險面。

啟發: 如果你在同一個 prompt 裡同時做「執行」和「檢查」，效果通常不好，因為模型很難對自己剛產生的推理保持懷疑。把檢查拆成獨立的 LLM 呼叫，並且只餵入必要的資訊 (使用者原始請求 + 準備執行的動作)，判斷品質會好很多。Agent 產生的推理文字本身就是一種「內部提示詞注入」— 它會用看似合理的論述讓檢查機制放鬆警覺。

4. 先快篩再深度推理，控制成本

Claude Code 的兩階段分類器是個值得細看的設計: 兩個階段用的是同一個模型 (Sonnet 4.6)，prompt 也幾乎一樣，差別只在最後一句指令。第一階段指示模型「只回答 yes/no，不要推理」，強制只輸出一個 token，速度快、成本低，但會有 8.5% 的誤擋率。只有被第一階段標記為「擋」的動作才進第二階段，這時指令換成「請用思維鏈推理來判斷」，讓模型仔細想過再決定，把誤擋率降到 0.4%。

關鍵是成本控制: 因為兩階段的 input 只有最後一句指令不同，透過 prompt caching，第二階段的 input token 幾乎全是快取命中，額外成本幾乎只有 output token 的推理部分。等於用極低成本就多做了一次深度複審。

Codex 的做法不同但思路一致: 用沙箱先過濾掉大部分動作，只有跨越邊界的才需要審查 agent 介入 — 在內部部署中，10,000 個動作裡只有 720 個需要經過 Auto-review。

共同點是: 不需要每個動作都跑完整的安全推理。

啟發: 如果你的審查機制每個動作都要跑一輪完整的 LLM 推理，成本和延遲都會爆炸。Claude Code 的做法提供了一個很實用的模式: 用同一個模型跑兩次，第一次只要一個 token 的判斷做快篩，第二次才做深度推理，再利用 prompt caching 讓第二次幾乎不花額外的 input 成本。在更廣泛的場景中，也可以先用簡單規則 (允許清單、正則表達式、關鍵字匹配) 做第一層過濾，只把被標記的送去做 LLM 深度判斷。

5. 設計好被擋住之後的行為

很多人設計審查機制只想到「擋住」，沒想到擋住之後怎麼辦。兩家的設計都包含完整的拒絕後流程:

• 回傳拒絕理由: 不只是說「不行」，而是告訴 agent 為什麼不行
• 引導替代路線: 指示 agent 找更安全的做法，而不是繞過限制
• 熔斷上限: Claude Code 連續 3 次或累計 20 次被拒就升級給人類，防止 agent 反覆嘗試
• 區分拒絕和逾時: Codex 明確告知 agent「逾時不代表動作不安全，只是審查沒完成」

Codex 還提供了使用者覆寫路徑 — 記錄最近 10 筆拒絕，讓使用者可以針對特定動作覆寫，但只限那一次，不會影響未來的判斷。

啟發: 把「拒絕理由」、「替代路線的引導」和「重試上限」都設計進去，才算完整。這也讓誤擋變得可以忍受 — 如果每次誤擋都要停下來等人類介入，系統根本沒法用於長時間任務。另外，是否提供使用者覆寫路徑也值得考慮: 它增加了靈活性，但要設計成窄範圍的 (只限那一次特定動作)，避免變成另一種「放飛」。

6. 用「環境定義 + 原則」取代「硬編碼規則清單」

Claude Code 的環境定義欄位定義的是「什麼算信任範圍」— 你的程式碼倉庫、雲端儲存、內部服務哪些是「自己的」— 而不是逐條列舉「不能做 A、不能做 B」。阻擋規則也不是零散的禁令，而是歸類成原則性群組 (破壞或外洩、弱化安全態勢、跨越信任邊界、繞過審查或影響他人)，每個群組下才有具體規則。

Codex 也用了類似的分層架構: 沙箱定義技術邊界 (哪些目錄可寫、能不能存取網路)，審查策略再加上語意判斷。企業管理員還可以透過集中管理設定強制設定底線，使用者只能在這個範圍內調整。

啟發: 與其寫一大堆具體禁止規則，不如先定義好「信任邊界」和「操作原則」，讓模型基於原則去判斷新情境。具體規則再怎麼列都會有遺漏，但原則可以涵蓋沒預見到的情況。最好的做法是兩者結合: 原則定義大方向，具體規則處理已知的高風險場景，原則負責覆蓋規則沒列到的長尾情境。

7. 關鍵控制點放在 Agent 程序之外

Claude Code 的分類器跑在伺服器端，agent 不知道它的判斷邏輯。Codex 的沙箱是作業系統級強制執行。GitHub Copilot coding agent 則用結構性限制: agent 只能建立 Pull Request，不能直接 commit 到主分支；PR 不會自動跑 CI，必須人類手動觸發。

啟發: 跑在 agent 程序內部的控制，模型有可能學會繞過。如果你的做法只是「在 system prompt 裡告訴 agent 不要做某些事」，那效果不會太好。真正擋得住的是程序外部的控制 — 獨立的審查服務、作業系統級隔離、結構性的能力限制。在你的 agent 架構中，至少要有一層控制是 agent 本身無法觸及的。

總結

最核心的一個啟發: 自動審批機制的本質不是一份禁止清單，而是一個判斷框架。它需要回答清楚這幾個問題:

1. 什麼算使用者授權 — 區分「使用者要求的」和「agent 自行推斷應該做的」
2. 什麼算信任範圍 — 用環境定義和原則取代硬編碼規則
3. 用什麼資訊來做判斷 — 審查者不該看到被審查者的辯護
4. 怎麼控制判斷成本 — 先快篩再深度推理
5. 判斷錯了怎麼辦 — 拒絕後繼續嘗試 + 熔斷機制

這幾個問題想清楚，比列一百條規則更有效。Coding agent 走在最前面，它們踩過的坑和找到的解法，值得所有在做 AI agent 的人認真參考。

這篇算是今年的觀察更新。前半段聊 Multi-Agent 的常見 anti-pattern，後半段整理目前主流推薦的架構設計。

先搞清楚哪些做法是 Anti-Pattern

1. 「更多 Agent 就更好」

這大概是最常見的迷思。Google Research 今年初的研究直接打臉了這個假設: 他們測了 180 種配置，發現 multi-agent 的效果完全取決於任務類型——在可並行的金融任務上提升 81%，但在需要順序推理的規劃任務上反而下降 70%。結論很明確: 架構與任務的匹配度，比 agent 數量重要得多。

更直接的證據來自 Stanford 今年四月的論文 Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets。他們用資訊理論的「數據處理不等式」(Data Processing Inequality) 論證: 在固定推理 token 預算下，單一 agent 的資訊效率更高。實驗跑了三個模型家族 (Qwen3、DeepSeek-R1、Gemini 2.5)，結果一致——控制 token 用量後，single-agent 持平或優於 multi-agent。換句話說，很多 multi-agent 聲稱的效能提升，其實只是因為「花了更多 token」，不是因為「架構更好」。

編按: Arize AI 創辦人 Aparna Dhinakaran 也點出: multi-agent 架構產生的通訊開銷，使其在不易並行化的任務上不如單一、順序 agent 有效。Evals 不只要評估單一 agent，也要評估 multi-agent 架構本身。

2. 「三省六部幻覺」: 別把 Agent 當公司部門

這是 2026 年討論度最高的 anti-pattern 之一。@sujingshen 寫了一篇很火的長文「三省六部幻覺: 為什麼『虛擬公司』式多 Agent 架構在工程上不成立」，拿到了 1600+ 讚和 2400+ 收藏。

核心論點: 很多團隊把多個 Agent 分別命名為「產品經理」、「架構師」、「測試工程師」，讓它們像公司部門一樣傳遞文檔、協作完成任務。這個模式看起來很直覺，但有根本性的缺陷:

🔹 人類需要分工是因為注意力有限、有專業壁壘；但 LLM 沒有這些限制。同一個模型既能寫 PRD 又能寫程式碼，給它貼「測試工程師」的標籤不會讓它更專業，只會讓它拒絕越界。最有價值的推理往往發生在邊界上，而角色扮演在系統層面封死了這個可能性。

🔹 資訊在流轉中死亡。Agent A 產出文件傳給 Agent B，傳遞的是結論不是推理過程。每次傳遞都在累積誤差，工作流越長，最終輸出越「局部正確但整體漂移」——就像傳話遊戲一樣。

🔹 Anthropic、OpenAI、Google 三家自己建 Agent 系統時，沒有一家採用這個模式。他們用的是 orchestrator-worker 架構搭配外部狀態文件，不是角色扮演式的流水線。

Dify 的後端工程師 Yeuoly (周宇) 也寫了一篇長文分享實戰血淚。他們不到五人的小團隊嘗試給不同 Agent 分配 iOS 上架、UI 設計、工程開發等職責，結果他說「我的注意力爆炸了」——按工作職能拆出一堆 Agent，每個都要人去檢查和協調，人反而成了 Agent 之間的傳話筒。最後發現「好像去咸魚找個人會更快更好，自己還沒那麼累」。

3. 預設固定工作流的脆弱性

@aneeshpappu 的研究 “Multi-Agent Teams Hold Experts Back” 指出另一個問題: 大多數 multi-agent 系統使用預先指定的工作流程、固定角色和聚合規則。當任務複雜到無法提前規劃最佳工作流時，這些系統就會崩潰。@dair_ai 介紹的 OneManCompany 論文則提出，應該把 agent 當成可動態招募的人才市場，而不是固定的組織架構圖。

4. 生產環境的隱藏成本

一旦進入 production，multi-agent 的問題就會集體浮現:

🔹 成本非線性爆炸: Anthropic 自己的數據顯示，multi-agent 通常用 3-10 倍的 token，他們的 Research 系統更用了約 15 倍。Augment Code 的分析更直接: 「為什麼 3 個 Agent 要花 10 倍成本」——因為 context 複製、協調訊息、驗證層、重試迴圈加在一起是乘法效應。

🔹 錯誤放大效應: 如果每個 agent 有 90% 準確率，串三個就變 72.9%。根據 Google/MIT 的 agent 系統擴展研究，獨立 agent 的錯誤放大倍數高達 17.2 倍，即使加上中央協調也有 4.4 倍。

🔹 除錯地獄: 一篇 MAST 失敗分類學研究分析了 1600+ 個失敗案例，發現 7 個 SOTA 開源 multi-agent 系統的失敗率在 41% 到 86.7% 之間。很多失敗來自系統設計問題而非 LLM 能力不足，修改 prompt 是不夠的，需要結構性的重新設計。

🔹 生產級的十二個坑: Antigravity Lab 整理了 12 個常見陷阱，包括重試迴圈、token 失控、context 污染、級聯故障、可觀察性缺失等，每一個都是 prototype 階段看不到但 production 一定會遇到的。

那什麼時候該用?怎麼用才對?

聊完 anti-pattern，來看業界目前收斂出來的共識。

核心原則: 從簡單開始，必要時才加複雜度

這點是跨廠商的共識。Anthropic 說:「我們見過團隊花了好幾個月建構精緻的 multi-agent 架構，結果發現改進單一 agent 的 prompt 就能達到等效結果。」LangChain 也說:「先從單一 agent 和好的 prompt engineering 開始。先加工具，再加 agent。」OpenAI 的 Building Effective Agents 一文的開頭也是類似的建議。

Anthropic 的三個適用場景 (2026/1)

Anthropic 在一月發表的 Building Multi-Agent Systems 明確列出 multi-agent 比 single-agent 好的三種情境:

1️⃣ Context 隔離: 當子任務產生大量但無關的 context (如查訂單歷史 2000+ token)，會「污染」主 agent 的推理品質。用 subagent 查完後只回傳 50-100 token 的摘要，保持主 agent context 乾淨。

2️⃣ 並行化: 需要同時探索多個獨立方向時 (如 Research 功能)。重點是「覆蓋面更廣」而非「速度更快」——平行 agent 其實常常比 single-agent 花更久，但搜尋空間大得多。

3️⃣ 專業化: 當工具數量超過 15-20 個，或不同任務需要衝突的 system prompt (例如客服要有同理心、code review 要嚴格挑錯)，拆成專門的 agent 可以提升可靠性。

最關鍵的設計原則是「以 context 為中心拆分」，不是以問題類型拆分。寫功能的 agent 也應該寫它的測試，因為它已經擁有完整的 context。只有在 context 真的可以完全隔離時才拆開。

五種協調模式 (2026/4)

四月的 Multi-Agent Coordination Patterns 更進一步整理了五種模式 (宝玉有翻譯全文)，以下用原文插圖快速過一遍:

1. Generator-Verifier (生成-驗證)

最簡單也最實用的模式。一個 agent 產出結果，另一個專門挑錯，不通過就打回去重做，直到通過或達到上限。適合程式碼生成 (一個寫、一個跑測試)、事實核查、合規檢查等看重品質的場景。關鍵是驗證標準要具體明確，否則驗證者就只是橡皮圖章。Cognition/Devin 的實戰經驗還發現，驗證 agent 不共享產出 agent 的 context 反而效果更好——乾淨的 context 讓它能更深入推理，不會被前面累積的雜訊干擾 (詳見下方 Cognition 段落)。

2. Orchestrator-Subagent (調度-子代理)

一個主 agent 負責規劃和分派，子代理各自處理子任務後回報結果。Claude Code 就是用這個模式——主代理自己寫程式碼，需要搜尋大型 codebase 時才派子代理出去。大多數情況建議從這個模式開始，它能處理最廣泛的問題且協調開銷最小。

3. Agent Teams (代理團隊)

跟 orchestrator-subagent 的差別是 worker 會持續存活、累積 context，不是做完一個任務就消失。適合大型 codebase 遷移這類需要長時間、多步驟獨立工作的場景。但前提是子任務之間真的互相獨立，否則容易出現衝突。

4. Message Bus (訊息匯流排)

agent 之間透過發布/訂閱事件來溝通，不需要中央調度。適合事件驅動的流水線 (如安全警報處理系統)，以及 agent 生態會持續擴展的場景。靈活但除錯困難——事件在五個 agent 之間串聯時，要追蹤發生了什麼事需要很仔細的 logging。

5. Shared State (共享狀態)

沒有中央協調者，所有 agent 透過讀寫同一個共享儲存 (資料庫、檔案) 來協作。適合研究綜合類任務——一個 agent 找到的線索，其他 agent 能即時看到並跟進。好處是沒有單點故障，壞處是容易出現重複工作和反應式迴圈 (A 寫了發現，B 看到後回應，A 又回應 B…)，必須設好終止條件。

以上圖片來源: Anthropic Blog

小編補充幾點觀察:

🔹 大多數團隊從 Orchestrator-Subagent 開始就對了，它能處理最廣泛的問題且協調開銷最小。觀察哪裡撞牆，再往其他模式演化。

🔹 生產系統通常是混合模式: 整體用 orchestrator-subagent，某個高度協作的子任務內部用 shared state。這些模式是積木，不是互斥選擇。

🔹 Generator-Verifier 是投資報酬率最高的起手式: 只要加一個驗證 agent 就能顯著提升品質，不需要大改架構。很多團隊第一步就是從 single-agent 加一個 verifier 開始。

LangChain 的觀察: 讀取 vs. 寫入，以及四種架構模式

LangChain 在 2025 年中提出了一個蠻有洞見的區分: 「讀取型」任務的 multi-agent 比「寫入型」好管理。搜尋、研究這類讀取任務天生適合並行化，多個 agent 讀同樣的東西不會衝突；但寫程式碼、寫文件這類寫入任務，平行化就容易出現衝突的決策和難以合併的輸出。這也解釋了為什麼 Anthropic 的 Research 系統 (讀取型) 成功用了 multi-agent，而 Cognition/Devin 去年會說「不要用 multi-agent」——因為他們面對的是寫入型任務 (不過他們今年的立場有演化，見下一節)。

他們在 2026 年一月的架構選擇指南中，進一步整理了四種實作模式:

幾個有意思的實測觀察:

🔹 Subagents 和 Router 在多領域任務上效率最高，因為能平行執行且 context 隔離——處理三個語言的比較文件時，Subagents 的 token 用量比 Skills 少了 67%。

🔹 Skills 和 Handoffs 是有狀態的模式，在重複請求時能省 40-50% 的 API 呼叫，因為能記住之前的對話 context。

🔹 Handoffs 無法平行化，只能順序執行，所以不適合需要同時查多個領域的場景。

他們的結論也呼應了 Anthropic: context engineering 才是讓 agentic 系統可靠運作的核心。LangGraph 作為底層框架，刻意不藏任何隱藏的 prompt 或強制的認知架構，就是為了讓開發者完全掌控 context 的組成。

Cognition/Devin 的實戰驗證

Cognition 的 Walden Yan 在四月發了一篇「Multi-Agents: What’s Actually Working」，算是去年那篇「Don’t Build Multi-Agents」的續集。核心立場沒變: 平行寫入還是行不通，多個 agent 同時寫程式碼會產生隱性的風格和決策衝突。但他們找到了一類真正有效的模式——寫入動作維持單線程，其他 agent 只負責提供判斷，不負責動手做事。

他們分享了兩個具體實驗:

🔹 程式碼審查迴圈: 讓 Devin 寫完程式碼後，另一個 Devin Review 專門挑錯。平均每個 PR 抓到 2 個 bug，58% 是嚴重問題 (邏輯錯誤、邊界情況遺漏、安全漏洞)。最反直覺的發現是: 審查 agent 不共享寫程式 agent 的 context，效果反而更好。原因是寫程式的 agent 工作幾小時後會累積大量 context，注意力品質會隨長度下降 (他們稱為 context rot)；審查 agent 從乾淨的 context 出發，只看差異，需要什麼資訊再自己去查，反而能更深入地推理。這跟 Anthropic 說的「context 隔離」不謀而合，但提供了更具體的機制解釋。

🔹 聰明朋友模式 (目前算失敗): 構想是用便宜快速的小模型當主力，遇到困難時呼叫大模型當「顧問」，藉此兼顧成本和品質。但他們坦承這個方向還沒成功——小模型 (SWE 1.5) 太弱，根本判斷不了「什麼時候該求助」，而這恰恰是整個架構最關鍵的決策。後續的 SWE 1.6 好一些但仍不到位。他們認為這本質上是個訓練問題，未來的模型需要在這種來回協作的環境中被訓練才行。唯一成功的變體是讓兩個前沿模型互相搭配 (例如 Claude + GPT)，利用不同模型擅長不同子任務的特性來互補——但那就不是在省錢了，意義完全不同。

編按: 這個「小模型遇到困難時諮詢大模型」的方向，Anthropic 也在四月推出了官方實作 Advisor Strategy: Sonnet 自己完成工作，卡住時才向 Opus 請求建議。官方數據顯示 Sonnet + Opus 顧問比單獨 Sonnet 表現高 2.7 個百分點，成本反而低 12%。但同樣有「執行者過度自信而不求助」的問題，可見這個模式的核心難題是共通的。

他們也在做更高層級的委派: 由管理者 Devin 拆分大任務、派子 Devin 執行、透過 MCP 協調進度。但踩了不少坑——管理者缺乏程式碼庫 context 時會過度指揮、agent 誤以為跟子 agent 共享狀態、跨 agent 的溝通不會自動發生。至於無結構的 swarm 架構? 他們直接說是在繞遠路，實務上有效的形態是「拆分-執行-彙整」(map-reduce-manage)。

Walden 的文章有一個很好的總結: 所有 multi-agent 的待解問題，本質上都是溝通問題——弱模型怎麼知道該向強模型求助、子 agent 發現了什麼重要資訊該怎麼傳給兄弟 agent、怎麼傳遞 context 又不淹沒接收方。

業界收斂的 Best Practices

綜合 Anthropic、OpenAI、LangChain 以及各家生產經驗，幾條最重要的建議:

1️⃣ 先證明 single-agent 不夠用，再考慮 multi-agent。量化你的瓶頸: 是 context 不夠?工具太多?需要並行探索?如果改進 prompt 或用 context compaction 就能解決，就別加 agent。

2️⃣ 從 2-3 個 agent 開始，不要一口氣蓋大系統。每多一個 agent 都會增加除錯面積。

3️⃣ Day 1 就建 observability: 沒有 tracing 的 multi-agent 系統是不可能除錯的。LangSmith、OpenTelemetry 這類工具是必備的。

4️⃣ 設定成本上限和熔斷機制: 每個 task 設 token/金額上限。凌晨三點的 runaway agent 應該自動停掉而不是燒光 API 預算。

5️⃣ 驗證 agent 只負責挑錯，不負責接手執行: 如果你想加一個 agent 來做品質把關，它的職責就是「專門找前一個 agent 的問題」——跑測試、查事實、驗格式，發現問題就打回去讓原本的 agent 重做。它不會自己動手修，也不會接棒繼續往下產出。Anthropic 叫這個 Generator-Verifier 模式，兩個 agent 之間是對抗關係 (一個產出、一個否決)，不是流水線關係 (一個做完交給下一個繼續做)。

6️⃣ 保持架構的可演化性: Anthropic 自己也發現，為 Sonnet 4.5 設計的 context reset workaround，在 Opus 4.5 上就變成了無用代碼。模型能力在快速提升，今天的 workaround 六個月後可能就是死重量。

再往前看: 動態子代理生成

上面整理的模式——不管是 Anthropic 的五種還是 LangChain 的四種——其實都還是在「設計時」就決定好 agent 的分工和流程。但有一個方向值得關注: 讓模型自己決定要拆幾個子代理、各自做什麼。

小編之前寫過 為什麼多數 Agent 框架都沒有內化 Bitter Lesson?，裡面引用 Minh Pham 的觀點: 現在多數 agent 架構都在做一件事——「模型不夠可靠，所以把可靠性寫進外層框架裡。」這在產品層面合理，但本質上是把複雜度從可規模化的部分 (模型) 搬到不可規模化的部分 (手工搭建的鷹架程式碼)。

「動態子代理生成」(Dynamic Subagent Spawning) 的核心思想是: 不要在設計時預先固定 agent 的分工和流程，而是讓模型在執行時根據任務需求自行決定怎麼拆解、要生成幾個子代理、各自做什麼。 這其實是一個光譜——一端是固定工作流 (拖拉式建構器)，另一端是完全動態 (模型自己決定一切)。現實中大多數系統落在中間，但趨勢是往動態端移動。

目前已經有一些實作走在這個方向上:

• Anthropic 的 Research 系統: 主代理透過延伸思考動態決定任務分解，子代理是即時建立的新 Claude 實例
• Claude Code: 主代理可以把任務委派給子代理在獨立 context 裡執行
• LangChain Deep Agents: 提供任務工具讓主代理呼叫生成子代理

這個方向符合一個很好的檢驗標準: 如果模型能力明年翻倍，你的系統會不會在不需要大幅重構的情況下，變得更好? 如果 agent 的分工是動態的，模型進步時委派策略會「免費」變好；如果分工是硬編碼的，你就得手動重寫組織圖。

當然，短期內固定工作流在可預測性、可稽核性、成本控制上還是有優勢。但長期來看，最後勝出的 agent 架構會越來越像一個「算力分配引擎」，而不是一張手工打造的組織圖。

結語

一年前的結論——「預設 Single-agent，特定場景才用 Multi-agent」——不但沒過時，反而在 2026 年被更多的論文和生產經驗驗證了。但有進步的是，業界對「特定場景」有了更清晰的定義 (context 隔離、並行搜尋、工具專業化)，對「怎麼做」也有了更成熟的模式 (五種協調模式及選擇框架)，對「未來往哪走」也有了方向 (動態子代理生成)。

如果非要記住一句話: Multi-Agent 的價值是並行覆蓋，不是分工。最好的 multi-agent 系統不像公司，更像一個思考者的多次草稿——同一個大腦在不同維度展開推理，最終合併成一個連貫的結論。

延伸閱讀:

• Anthropic: Building Multi-Agent Systems (2026/1)
• Anthropic: Multi-Agent Coordination Patterns (2026/4)
• LangChain: Choosing the Right Multi-Agent Architecture (2026/1)
• LangChain: How and When to Build Multi-Agent Systems (2025/6)
• Stanford: Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets (2026/4)
• Cognition: Multi-Agents: What’s Actually Working (2026/4)
• 三省六部幻覺: @sujingshen 全文 (2026/4)

這不是又一個行銷縮寫。過去這幾個月，小編看到越來越多具體的東西冒出來: Salesforce 宣布 Headless 360 把整個平台暴露成 API、MCP 和命令列工具；Notion 的 MCP 伺服器會主動餵格式規格給 agent；Ramp 的 MCP 週活用戶三個月內成長了十倍。Agent 已經是你產品的真實用戶了，問題只是你有沒有在為它設計。

這個詞最早是 Netlify 執行長 Mathias Biilmann 在 2025 年 1 月提出的，定義是:

AX 是「AI agent 作為產品或平台的使用者時，所經歷的整體體驗」

他的觀察很直接: 對 agent 來說難用的工具，會需要更多人工介入，越用越笨重；對 agent 友善的工具，會變得越來越強大、越來越受歡迎。DX 當年怎麼成為開發者工具的競爭護城河，AX 現在就在走同一條路。

Jeff Bailey 在 Fundamentals of Agent Accessibility 裡用了一個小編覺得很精準的類比: Agent 碰到你的 API 時面臨的挑戰，和螢幕閱讀器碰到網頁時一模一樣 — 兩者都需要結構、語義和可預測性才能運作。 過去我們花了二十年推動網頁無障礙設計，現在同樣的思維要延伸到 agent 身上。

這篇小編把最近讀到的幾篇重要文章整理成一個完整框架，從概念、旅程地圖、到實作設計原則，並以 CLI 設計為主要範例來說明。

AX、DX 和 UX: 三個不同的設計對象

Leonie Monigatti 在她的 Agent Journey Map 文章中把三者的差異拆得很清楚:

最根本的差異是: UX 和 DX 要考慮情感曲線（挫折 → 困惑 → 滿意）；AX 沒有情感，取而代之的是失敗模式和可靠性曲線 — agent 在每個階段有多大機率成功完成任務。

Justin Poehnelt（Google）在他的這篇文章裡用一句話切到重點:

人類導向的 DX 優化的是可發現性和容錯；Agent 導向的 DX 優化的是可預測性和縱深防禦。這兩者差異大到，把一個人類優先的 CLI 改裝給 agent 用，是注定失敗的。

Agent 旅程地圖: 五個階段

Leonie Monigatti 提出了一個很實用的框架，借用 UX 和 DX 的「旅程地圖」概念，把 agent 與你產品的互動路徑分成五個階段:

1. 發現: Agent 能不能知道你的產品存在?

這是最值錢也最沒有明確答案的階段。Agent 怎麼「發現」一個工具? 大概有幾個管道:

• 訓練資料裡的提及量和情感: 你的產品在 LLM 訓練語料中被提到多少次、正面還是負面
• 網路搜尋: Agent 用搜尋工具研究時，你能不能被找到
• 生成式搜尋優化: SEO 的 LLM 版本（有人叫 GEO、LLMO 或 AEO），很多代理商在推，但目前沒有證實有效的方法

編按: 最近 Amplifying.ai 做了一份大規模研究 What Claude Code Actually Chooses，用 2,430 個開放式提示測試 Claude Code 到底會選什麼工具，結論是它確實會強烈偏好特定產品（例如前端 React 85%、CI/CD 用 GitHub Actions 94%）。更有趣的是，在 12 個類別中，Claude Code 最常見的「選擇」是自己從頭寫，而不是推薦任何第三方工具。但為什麼會這樣偏好? 訓練資料? 搜尋排名? GitHub 使用量? 目前還是黑箱。

2. 評估: Agent 能不能判斷你的產品是否適合?

對應到 UX 和 DX 裡「逛官網、讀文件」的階段。AX 的新考量是讓網站內容對 agent 更友好:

• llms.txt: Answer.AI 在 2024 年 9 月提出的標準化格式，讓 LLM 更容易理解你的網站。但 Drupal 創辦人 Dries Buytaert 的數據顯示:「設計給機器人用的 llms.txt，機器人反而不太看」
• 文件的 Markdown 版本: Gemini API 文件、Elastic 文件等已經提供「檢視 Markdown」選項。Dries 的數據顯示 Markdown 確實比 llms.txt 有更多機器人流量，但還是不如一般 HTML
• GitHub README: 這反而是 agent 最常碰到的入口之一

3. 上手: Agent 能不能不靠人就開始使用?

關鍵問題是「從零到 Hello World」在 AX 裡能壓到多快。幾個常見卡點:

• 認證: OAuth 流程是為人設計的，agent 做不了瀏覽器跳轉。解法是 API 金鑰、服務帳戶、環境變數注入
• Agent Skills: 給 agent 一份結構化的「快速上手指南」，比讓它自己啃文件快得多
• 沙盒環境: 讓 agent 可以安全地試錯，不用擔心搞壞正式環境

4. 整合: Agent 能不能穩定操作你的平台?

這是最核心的階段，下面會用大量篇幅展開。

5. 推薦: Agent 會不會持續選擇你的產品?

Agent 怎麼選技術棧? 怎麼決定推薦哪個工具? 這個階段本質上又繞回「發現」— 形成一個循環而不是漏斗。你的產品在 agent 生態系裡的口碑，會直接影響下一輪被選中的機率。

整合層的四條路: CLI、API、MCP、Skills

回到旅程地圖第四階段「整合」。Anthropic 在四月發了一篇 Building agents that reach production systems with MCP，把 agent 連接外部系統的方式整理得蠻清楚的 — 目前主要有四條路，各有不同的適用場景和取捨:

CLI（命令列工具） 是目前 agent 最容易上手的介面，因為 LLM 的訓練資料裡充滿了 shell 指令。Agent 看到 --help 就知道怎麼探索，用管道就能組合工作流，上下文成本幾乎為零。但 Anthropic 也指出它的侷限: CLI 最適合本地開發環境和沙盒容器，到了行動裝置、瀏覽器或雲端託管的環境就不適用了。

直接呼叫 API 是最成熟的整合方式。關鍵是要有清楚的、機器可讀的結構描述（例如 OpenAPI 規格），以及能讓 agent 自我修正的錯誤回應。但 Anthropic 點出了一個核心挑戰: 直接呼叫 API 會造成 M×N 的整合問題 — 每一對 agent 和服務之間都是獨立的客製整合，認證處理和工具描述各做各的，隨著 agent 數量增加完全沒法擴展。

MCP（模型上下文協定） 正是為了解決這個 M×N 問題而生的。MCP 建立了一個共通的協議層，agent 連上一個 MCP 伺服器，就能透過標準化的工具定義來操作你的系統 — 認證、發現、語義描述都有統一標準。一個遠端伺服器就能服務所有相容的用戶端（Claude、ChatGPT、Cursor、VS Code），跨平台、跨裝置。代價是需要更多前期投入，而且每一層抽象都有保真度的損失。

Agent Skills 則是結構化的 Markdown 指引，告訴 agent 在特定情境下該怎麼操作你的產品。Anthropic 把 Skills 定位為「程序性知識」— MCP 給 agent 工具，Skills 教 agent 怎麼用這些工具來完成真正的工作。Skills 是按需載入的，agent 不需要的時候不佔上下文，而且可以編碼那些從 --help 或工具描述看不出來的隱性知識。

這四條路不是互斥的。Anthropic 說得很直接: 成熟的整合通常會多管齊下 — API 是基礎，CLI 服務本地環境，MCP 服務雲端 agent，而 Skills 橫跨所有介面把它們串起來。

編按: 小編之前寫過一篇後 MCP 時代: Skills 取代 MCP 嗎?，深入比較了兩者的差異和分工。簡單來說: 在 coding agent 場景下（像 Claude Code、Codex CLI），Skills 配上 shell 幾乎可以取代大部分 MCP 的用途；但在需要標準化認證流程或跨廠商整合的場景，MCP 作為協議標準仍有它的定位。

接下來，小編用 CLI 設計為主要範例，來具體說明「為 agent 設計」到底意味著什麼。這些原則 — 漸進式揭露、可執行的錯誤訊息、冪等操作 — 同樣適用於 API 和 MCP 工具的設計。

以 CLI 為例: 為 Agent 設計的基本原則

大多數命令列工具是為人設計的，直接讓 agent 用會撞牆。Eric Zakariasson 在一篇廣為流傳的推文裡總結了幾個關鍵原則，Cursor 也把這些原則整理成一份 CLI for Agents skill，給 coding agent 在開發或審查 CLI 工具時參考:

非互動式優先

如果你的工具在執行途中跳出互動式選單，agent 就卡死了。它不會按方向鍵，也不會在對的時機打「y」。所有輸入都要能透過旗標傳入，互動式介面只作為旗標缺失時的 fallback:

# 這會卡住 agent
$ mycli deploy
? Which environment? (use arrow keys)

# 這才行
$ mycli deploy --env staging

漸進式揭露，不要一次傾倒

Agent 跑 mycli，看到子命令列表，選一個，跑 mycli deploy --help，拿到需要的資訊。不要一次把所有文件塞給它。

每個 --help 都要附範例。Agent 從 mycli deploy --env staging --tag v1.2.3 這種範例學得比讀描述文字快得多。

支援 stdin 和管道組合

Agent 天生擅長組合指令。CLI 應該在合理的地方支援 stdin 輸入和管道串接，讓 agent 把多個指令組合成工作流:

# 從 stdin 匯入設定
cat config.json | mycli config import --stdin

# 用管道串接: 上一步的輸出直接變下一步的輸入
mycli deploy --env staging --tag $(mycli build --output tag-only)

避免奇怪的位置參數順序，也不要在值缺失時退回互動式提示 — 直接用有意義的錯誤訊息告訴 agent 該補什麼旗標。

可預測的命令結構

如果 agent 學會了 mycli service list，它應該能猜到 mycli deploy list 和 mycli config list。統一用「資源 + 動作」的模式，讓 agent 可以舉一反三。

失敗要快，錯誤訊息要給下一步

# 不要這樣
Error: missing required flag

# 要這樣
Error: No image tag specified.
  mycli deploy --env staging --tag <image-tag>
  Available tags: mycli build list --output tags

Agent 不能上網搜錯誤訊息。每個錯誤都要同時回答「出了什麼問題」和「該怎麼做」。

冪等操作加上預覽模式

Agent 會不斷重試。同一個部署跑兩次應該回傳「已部署，無需動作」，而不是建立重複。破壞性操作一律加 --dry-run，讓 agent 先預覽再執行；同時提供 --yes 或 --force 旗標讓 agent 跳過確認提示，人類預設還是安全的互動式確認:

$ mycli deploy --env production --tag v1.2.3 --dry-run
Would deploy v1.2.3 to production
  - Stop 3 running instances
  - Pull image registry.io/app:v1.2.3
  - Start 3 new instances
No changes made.

成功輸出要回傳機器可用的資料

錯誤訊息設計大家都注意到了，但成功輸出也很重要。Agent 需要的是可以直接使用的結構化資料 — ID、URL、耗時 — 而不是裝飾性的文字:

$ mycli deploy --env staging --tag v1.2.3
deployed v1.2.3 to staging
url: https://staging.myapp.com
deploy_id: dep_abc123
duration: 34s

Agent 拿到 deploy_id 可以直接用在下一步操作，拿到 url 可以馬上做驗證。純文字就好，不需要花俏的表格或顏色，關鍵是資訊完整且容易解析。

進階: Agent 優先的 CLI 設計

上面是基本功。Justin Poehnelt 在 Google Workspace CLI（gws）的實作經驗，把設計推到了更深的層次:

原始 JSON 優於一堆參數

人類討厭在終端打 JSON，但 agent 偏好它。十個扁平的參數沒辦法表達巢狀結構，一個 --json 接完整的 API 酬載就可以:

gws sheets spreadsheets create --json '{
  "properties": {"title": "Q1 Budget", "locale": "en_US"},
  "sheets": [{"properties": {"title": "January", "sheetType": "GRID",
    "gridProperties": {"frozenRowCount": 1, "columnCount": 10}}}]
}'

JSON 直接映射到 API 結構，LLM 生成時零損失。務實的做法是: 同一個工具裡同時支援兩種路徑，人類用便利參數，agent 用原始酬載，兩者共存。

結構自省取代靜態文件

Agent 沒辦法上網查文件。把文件塞進系統提示詞又貴又容易過期。更好的做法是讓工具自己就是文件，可以在執行期間即時查詢:

gws schema drive.files.list
gws schema sheets.spreadsheets.create

每個 schema 呼叫吐出完整的方法簽名 — 參數、請求內容、回應型別、需要的授權範圍 — 全部是機器可讀的格式。Agent 需要的時候自己查，不用預先載入。

管好上下文視窗

API 回傳的資料可以很龐大。人類不在乎，人類會捲動。Agent 每個 token 都要付錢，而且無關的欄位會消耗推理能力。

兩個機制: 用欄位遮罩限制回傳範圍，讓 agent 只拿需要的；用串流分頁讓 agent 可以逐批處理，不用把整包資料塞進上下文。

輸入驗證: 對抗幻覺

這是最被低估的一環。人類會打錯字，agent 會幻覺，失敗模式完全不同:

• 人類幾乎不會打出 ../../.ssh — 但 agent 可能幻覺出路徑穿越
• Agent 可能在資源 ID 裡嵌入查詢參數: fileId?fields=name
• Agent 經常預先做 URL 編碼，導致重複編碼

Anthropic 在 SWE-bench 的研究中也發現了一個相關的教訓: 當他們的 agent 使用相對路徑時，換了目錄就會出錯；改成強制使用絕對路徑後，這整類錯誤直接消失了。這就是「讓錯誤在結構上不可能發生」的設計理念 — 與其靠 agent 自律，不如在介面層就擋掉。

Justin 的總結:「Agent 不是可信任的操作者。你不會寫一個盲目信任用戶輸入的網頁後端 — 也不要寫一個盲目信任 agent 輸入的命令列工具。」

提供 Agent Skills

人類透過 --help、文件網站、Stack Overflow 來學一個工具。Agent 透過對話開始時注入的上下文來學。Justin 的 gws 隨附了超過一百個 SKILL.md 檔案，每個 API 操作面向一份，編碼那些 --help 看不出來的隱性知識: 「對寫入操作一律先用 --dry-run」、「每次列表呼叫都要加欄位遮罩」。

這些規則之所以必要，是因為 agent 沒有直覺 — 它需要明確寫下的不變量。一份好的 Skills 檔案比一次幻覺便宜多了。

同樣原則也適用: API 設計

命令列之外，API 是 agent 存取外部系統的主要管道。上面提到的原則 — 可預測的結構、可執行的錯誤訊息、冪等操作 — 在 API 設計上同樣適用，甚至更重要。

LemonData 在重新設計他們的 API 時，歸納出一個核心原則: 不要試圖幫 agent 自動修正，要給它足夠資訊讓它自己決定。

傳統做法可能會在 agent 打錯模型名稱時偷偷導向相似的模型。他們的做法剛好相反 — 立刻失敗，但把所有需要的資訊一次給齊:

{
  "error": "model_not_found",
  "detail": "Model 'gpt-5-turbo' not found",
  "did_you_mean": ["gpt-5", "gpt-5-mini"],
  "suggestions": [
    {"model": "gpt-5", "reason": "most_used_by_account"}
  ]
}

他們報告這個做法讓用戶浪費的 token 降低了超過六成。

幾個跨越不同文章反覆出現的 API 設計原則:

• 錯誤訊息要可以被執行: 不只說「日期範圍無效」，要說「start_date 必須早於 end_date；收到的是 start: 2026-06-01, end: 2026-05-01」— agent 收到這個就能直接修正
• 用列舉值取代自由文字: 如果一個欄位只有有限的合法值，在結構定義裡列出來。["pending", "processing", "shipped"] 比「填入標準訂單狀態」清楚一百倍
• 一致的回應結構: 所有成功回應用同一個格式，所有錯誤回應也用同一個格式。Agent 會根據你的 API 建立內部模型，格式不一致會直接打破它的預測
• 冪等操作加上重試金鑰: Agent 可能因為網路逾時而重送請求，提供冪等機制讓同一個請求重送不會產生重複
• 速率限制要透明: 不要只在被限速時才告知，每個回應都帶上剩餘額度和重設時間，讓 agent 主動調節節奏

編按: 小編很認同一個觀點 — 對 agent 友善的 API，對人類開發者也更好用。差別只在人類可以「繞過」不完整的規格，agent 不行。它會照字面執行，規格不完整就直接失敗。所以為 agent 設計，其實是逼你把 API 做到真正該有的水準。

MCP 的抽象代價

Justin Poehnelt 在另一篇 The MCP Abstraction Tax 裡提出了一個有趣的觀點: 每多一層抽象，就要繳一次稅。

Agent 意圖 → MCP 工具 → REST API → 資料
                ↑           ↑
             抽象稅       抽象稅

面對大型企業 API（那種幾百個端點的 CRM），MCP 伺服器設計面臨兩難:

• 精簡路線: 幾個高階操作，容易上手但表達力有損 — 沒辦法覆蓋複雜的批次操作
• 完整映射: 保真度高但上下文視窗會爆 — agent 理論上什麼都能做，實際上推理不動

Justin 歸納了一個保真度光譜:

前面提到的 Anthropic 那篇文章也給出了幾個實戰建議:

• 根據意圖分組，不是根據端點: 一個 create_issue_from_thread 比 get_thread + parse_messages + create_issue + link_attachment 四步好用得多
• 大型 API 用程式碼編排: Cloudflare 的 MCP 伺服器只有兩個工具（搜尋和執行），用不到一千個 token 就涵蓋了約 2,500 個端點
• 工具搜尋延遲載入: 不要在啟動時把所有工具定義塞進上下文。測試顯示按需載入可以減少 85% 以上的工具定義 token，同時維持高準確率
• Skills 搭配 MCP: MCP 給 agent 工具，Skills 教 agent 怎麼用這些工具完成真正的工作。兩者是互補關係

編按: 小編之前寫過一篇後 MCP 時代: Skills 取代 MCP 嗎?深入比較了兩者的差異。簡單來說: 在 coding agent 的場景下（像 Claude Code、Codex CLI），Skills 配上 shell 幾乎可以取代大部分 MCP 的用途；但在需要標準化認證流程或跨廠商整合的場景，MCP 作為協議標準仍有它的定位。兩者不是零和 — 現有的 MCP 可以被包進 Skills 裡執行。

新的互動模式: Agent 對 Agent

Ramp 的 Teddy Riker 在 Designing for Agents 裡描述了一個正在發生的根本性轉變:

過去二十年:  使用者 → 介面 → 資料庫
現在:        使用者 → 使用者的 Agent → 資料庫
接下來:      使用者 → 使用者的 Agent → 軟體的 Agent → 資料庫

介面不再坐在使用者和系統之間了。它坐在使用者的 agent 和你的 agent 之間。

教 agent 怎麼成功

Teddy 舉了 Notion MCP 的正面案例: Notion 的建立頁面工具描述開頭就寫著「先去載入完整的 Markdown 格式規格，不要猜」。結果每次寫入都格式完美。

反面案例是 Slack MCP: agent 假設標準 Markdown 語法可以通用，結果格式全跑掉，使用者花在修格式的時間比自己寫還多。

結論: Agent 沒有直覺 — 你必須把不變量講清楚，而且要在它需要的時候主動給，不要等它自己去摸索。

建立回饋循環

Ramp 一開始做 MCP 時最大的問題是看不到全貌 — 他們看得到工具呼叫量，但看不到背後的對話脈絡。後來他們想了幾個辦法:

1. 每個工具呼叫都要附上「理由」參數: Agent 必須解釋為什麼發起這個請求。他們看不到聊天記錄，但理由欄重建了意圖
2. 專門的回饋工具: 當 agent 卡住時，可以呼叫一個工具回報它在嘗試什麼、試了什麼、卡在哪裡
3. 工具專屬的上下文參數: 在個別工具上加入目的導向的參數，捕捉只有 agent 端才知道的資訊

編按: Teddy 說了一句小編覺得很精準的話:「Agent 會幻覺，沒錯。但它們在回饋上比大多數人類用戶更具體、更一致。」想想看 — 如果你的理由日誌裡反覆出現「building incident report」這個模式，那就是一個新產品功能的信號。Agent 在告訴你的 agent 該建什麼。

注意上下文鴻溝

在任何 agent 之間的互動中，你的系統有對方 agent 沒有的上下文，反過來也是。Teddy 舉了一個費用報銷的例子:

使用者的 AI 秘書知道: 行事曆（哪些會議）、信箱（飯店和機票確認信）、通訊軟體（那頓跟客戶的晚餐）、收據照片

費用管理系統知道: 交易明細、公司報銷政策、會計科目代碼、歷史歸類模式

設計良好的 agent 互動不會要求會計科目代碼 — 它會問上下文: 這是客戶餐會、團隊聚餐、還是個人差旅? 秘書 agent 從行事曆找到答案，費用系統根據它缺少的上下文套用正確的代碼。

使用者和他的 agent 永遠不需要知道會計科目是什麼，財務團隊得到準確的分類。每一方貢獻自己知道的東西，各取所需。

總結: AX 是新的競爭戰場

拉回來看全局。AX 不是一個單一的技術選擇，而是一個多層面的設計思維:

• 發現、評估、推薦: 確保你的產品在 LLM 的世界裡能被看見、被理解、被選中
• 上手: 降低 agent 的入門門檻 — 認證走環境變數、提供 Skills 和沙盒
• 整合: 根據你的 API 複雜度選擇正確的抽象層級 — 為 agent 設計的命令列工具、根據意圖分組的 MCP 工具、或程式碼編排
• 設計哲學: 非互動式優先、漸進式揭露、可預測的結構、冪等操作、驗證所有輸入、錯誤訊息要可執行

Biilmann 說得好: 太多公司把精力花在「到處加 AI 功能」或「再建一個自己的 agent」。真正的突破是想清楚: 你的客戶最常用的 agent，要怎麼幫他們從你的產品中獲得更多價值?

Teddy Riker 最後那句話小編覺得是最好的收尾:

大多數公司會建一個 MCP 伺服器，打個勾，然後繼續下一件事。他們的使用量會成長幾季，然後停滯。最終，客戶會流向那些在細節上下了功夫的產品，繞過那些沒有的。用對待人類的心力去設計 agent 體驗。未來買單的不是人，是 agent。

參考資料

• Mathias Biilmann, Introducing AX: Why Agent Experience Matters (2025/1)
• Leonie Monigatti, Agent Journey Map: Designing Software for AI Agents (2026/3)
• Justin Poehnelt, You Need to Rewrite Your CLI for AI Agents (2026/3)
• Justin Poehnelt, The MCP Abstraction Tax (2026/3)
• Eric Zakariasson, Building CLIs for agents
• Teddy Riker, Designing for Agents
• Anthropic, Building agents that reach production systems with MCP (2026/4)
• Jeff Bailey, Fundamentals of Agent Accessibility (2026/4)
• LemonData, Agent-First API Design
• Amplifying.ai, What Claude Code Actually Chooses
• Cursor, CLI for Agents Skill
• ihower, 後 MCP 時代: Skills 取代 MCP 嗎? (2026/3)

以下整理幾個小編覺得最有料的觀點。

1. 地板在你腳下往上升

Cat Wu 用了一個很精準的比喻: 你是在一塊正在往上升的地面上蓋東西（building on ground that’s rising underneath you）。

她拿自己的經驗舉例: 2024 年 10 月開始，她每次新模型發布都會用 Claude Code 測試同一個任務——幫 Excalidraw 加一個表格工具。Sonnet 3.5 失敗，Opus 4 偶爾成功（好到可以拿去做預錄 demo），到 Opus 4.6 已經穩定到敢在幾千個開發者面前現場演示。

METR 的研究數據更驚人: Opus 4.6 有一半的時間能完成人類需要近 12 小時的軟體任務，而 16 個月前的 Sonnet 3.5 只能做人類 21 分鐘的任務——41 倍的跳躍。

當底層能力以這種速度提升，你在專案開始時設計的限制條件，可能在專案中途就消失了。傳統 PM 那套「先充分調研、寫好 PRD、鎖定路線圖、按月執行」的做法，前提就不存在了。

2. PM 的新工作流: 三個工具、一個下午

Cat Wu 分享了她現在的工作分配:

• Claude.ai: 當思考夥伴，丟策略想法、處理棘手問題
• Claude Code: 做原型、寫 eval、跑腳本，產出是程式碼
• Cowork: 處理其他一切——收信、追待辦、做簡報、搜 Slack 歷史紀錄

這套組合最大的改變是: 從想法到可用原型的距離，從幾週壓縮到一個下午。Decagon 的產品總監 Bihan Jiang 也說了類似的話——以前把東西放到客戶面前測試要好幾週，現在從 Cowork 拉 context 開始，幾個小時就能用 Claude Code 做出可以 demo 的東西。

這不只是效率提升，是遊戲規則的改變。當建造成本趨近於零，過去因為「實作成本太高所以不值得做」的想法，現在都值得試一試。VentureBeat 有篇文章的觀察很到位: 他們公司的 PM 直接自己建了一個功能，不是寫需求、不是開 ticket，是自己建好、測好、部署上線，一天搞定。

3. 角色邊界正在融化

這可能是所有變化裡最深層的一個。Cat Wu 說她們團隊裡，設計師在 ship 程式碼、工程師在做產品決策、PM 在建原型和跑 eval。

Jenny Wen 從設計師的角度印證了同樣的事。她給出一組很具體的數字: 幾年前設計師 60-70% 時間花在做視覺稿和原型，現在這部分壓縮到 30-40%，多出來的時間用在跟工程師直接協作，甚至自己寫程式。

為什麼？因為改變是從工程端發起的。當工程師可以同時跑七個 Claude agent，每個人都能隨手把想法做成可運行的版本。設計師如果還在花兩週做精美的 mockup，那份 mockup 出來的時候，功能可能已經上線了。

Jenny 說了一句讓人停下來想的話:「連工程師自己都跟不上自己了。」

編按: LinkedIn 最近把它的 Associate PM 計畫改名為「Product Builder」計畫，訓練內容橫跨產品、設計、工程三個領域。這不是漸進式調整，是對角色本身的重新想像。

4. 工程變快 3 倍之後，PM 反而成了瓶頸

這是 Amol Avasarala 在 Lenny’s Podcast 上講的，小編覺得是整篇最反直覺的洞見。

主流敘事說: 工程師用了 AI 工具產能翻倍，公司需要的 PM 數量會減少。Amol 說剛好相反——Anthropic 正在大規模招 PM。

邏輯很簡單: 一個典型團隊過去是 5 個工程師配 1 個 PM。工程師用了 Claude Code 之後產能翻 2-3 倍，等於變成 15-20 個工程師配 1 個 PM。工程的產出爆炸了，但 PM 的產能沒有同比成長，結果 PM 變成整個團隊最擠的角色。

Anthropic 的做法分兩層: 一是大量招 PM，二是推「兩週規則」——小於兩週工程量的專案由工程師自己當 mini-PM 處理（包括跟法務、資安的溝通），PM 只在大專案才正式介入。

這裡面隱藏的訊息是: 能自己兼半個 PM 的工程師，價值直接乘以 10 倍。反過來，能寫程式碼的 PM，議價能力也是過去好幾倍。

5. 設計流程已死

Jenny Wen 去年 9 月在柏林的設計研討會上宣布「設計流程已死」，台下反應完全撕裂——一半人瘋狂點頭，一半人直接反駁。

她指的是經典的雙鑽石模型: 先發散、再收斂、再發散、再收斂。這套設計師曾經奉為聖經的流程，在 AI 速度面前已經跑不動了。而且三、四個月後她自己回頭看，覺得連那場演講都已經過時了。

被吃掉的很明確: 大量的 mockup、長期願景文件、精美的故事簡報。願景的有效期從過去的 2-5 年，縮短到現在的 3-6 個月。

但沒被吃掉的東西也很有意思。Figma 在兩件事上仍然不可取代: 一是同時探索 8-10 個方向並排比較（程式碼環境天生是線性的），二是極細微的視覺和互動調整。

最讓人吃驚的是 Jenny 對「品味與判斷」的看法。很多設計師把品味當成最後的堡壘，但 Jenny 的回應是:「AI 的品味和判斷會愈來愈好，我們可能太執著於這一點了。」不過她也指出了一個更根本的問題: 做軟體最難的部分從來都不是建造它本身，而是你和另一個人對方向意見不合。AI 可以給建議，但沒辦法解決你和同事之間的爭執。

6. 做簡單的事

Cat Wu 的團隊有四個核心原則，小編覺得每一個都蠻值得咀嚼的:

🔹 用短衝刺取代長路線圖: 鼓勵團隊每個人（不只 PM）去做「side quest」——在正式路線圖之外，花一個下午自己試一個想法。Claude Code 桌面版、AskUserQuestion 工具、todo list 功能，都是這樣冒出來的。

🔹 demo 和 eval 優先於文件: 不開傳統站會，改成分享 demo。因為一個下午就能做出原型，押錯注的代價很低。Cat Wu 的建議: 寫完 spec 之後，丟給 Claude Code 看它能不能直接做出來，「即使是粗糙的原型也能改變整個對話」。

🔹 每次新模型都重新檢視既有功能: 你上線一個功能，然後更好的模型出來了，你的功能可能瞬間變得好得多。最好的方式是每天使用自己的產品，故意叫它做你覺得太難的事。

🔹 做簡單的事 (do the simple thing): 如果你巧妙地繞過了模型的限制，那個繞法在下一個模型出來時就會變成不必要的複雜度。實作越簡單，新能力到來時越容易替換。Cat Wu 舉例: Claude Code 的 todo list 一開始要靠系統提示詞不斷提醒模型更新清單，這是個 hack。下一個模型出來後，這行為自然就有了，hack 直接刪掉。她們的 system prompt 隨著每個新模型都在瘦身，Opus 4.6 砍了 20%。

7. AI 開始自動跑產品實驗了

Anthropic 內部有個叫 CASH 的專案（Claude Accelerates Sustainable Hypergrowth，Amol 自己說這縮寫有點土），用 Claude 自動跑完整的成長實驗迴圈: 從歷史數據找機會 → 建構功能 → 測試品質紅線 → 上線分析結果。

目前的水準大概相當於兩到三年年資的初級 PM——還不到資深水準，但已經可以對文案修改、小型 UI 微調這類低風險實驗直接按下啟動。Amol 說 Opus 4.5 之前跑不起來，Opus 4.6 上線後「終於開始印錢」。

但有一個步驟 Claude 完全做不到: 跨部門對齊。Amol 的原話是:「就算有了 AGI，要讓六個人在同一間房間裡達成一致還是不可能。」

8. 不會設計也能做出好產品

Neethan Wu 的故事是這波變化的一個具體縮影。三個月前他完全不會 UI 設計，在 TikTok 和 Amazon 當工程師，設計完全空白。三個月後，他每週都在交付可上線的設計成品。

他組了一套三層系統:

• Skills 層: 把資深設計師的判斷標準編碼成 AI agent 的指令。例如 Paul Bakaus 做的 Impeccable，專門抓 AI 生成介面最常犯的錯——濫用字型、低對比灰字、巢狀卡片
• Canvas 層: 設計畫布，但不綁定特定 AI。例如 Paper 用 HTML/CSS 直接建構，設計出來就是程式碼
• Inspiration 層: 訓練眼光。Variant 可以輸入想法生成無限設計詮釋，Style Dropper 能吸取任何設計的視覺 DNA

這套框架的厲害之處在於它跟設計本身無關，而是跟「怎麼用 AI 探索一個新領域」有關: 找到最好的 Skills（借用專家判斷力）、選一個 Canvas（工作介面）、持續用 Inspiration 訓練品味。PM 要跨界學設計、設計師要學寫程式、工程師要懂產品思維——門檻都在急速降低。

9. Builder 或 Reviewer? LangChain 創辦人的 EPD 重組論

Harrison Chase（LangChain 創辦人）寫了一篇蠻火的長文（73 萬次閱讀、4000+ 收藏），從 EPD（Engineering, Product, Design）三個角色同時受衝擊的角度來分析。他的核心觀點跟上面 Anthropic 幾位講的方向一致，但框架更清晰。

他說傳統 EPD 流程是線性的: 有人（通常是 PM）有想法 → 寫 PRD → 設計師做 mockup → 工程師寫程式碼。這套流程之所以存在，是因為「建造」本身很花時間和精力，所以需要分工和溝通機制。但 coding agent 把建造成本壓到趨近於零之後，這整條鏈就斷了。

取而代之的是: 任何人都能直接做出原型，然後交給 EPD 審查。問題是——原型太容易生了，審查反而成了新的瓶頸。

這跟 Amol 講的「PM 成為瓶頸」完全吻合，只是 Harrison 把範圍擴大到整個 EPD 都面臨審查能量不足的問題。

Harrison 提出了一個蠻清楚的二分法: 未來 EPD 角色基本上分成兩種人:

🔹 Builder: 有產品直覺、會用 coding agent、有基本設計品味。在護欄（測試套件、元件庫）的保護下，能獨自把小功能從想法做到上線，大功能至少做出可用的原型。

🔹 Reviewer: 某個領域的頂尖系統思考者——工程架構、產品策略、或設計體驗。負責審查 Builder 產出的東西，確保品質。門檻很高，而且要快，因為要審的東西比以前多得多。

如果你是工程師，要嘛把系統設計練到極致當 Reviewer，要嘛補上產品和設計能力當 Builder。PM 和設計師也是同理——要嘛有極強的領域心智模型專門審查，要嘛跳進 coding agent 的世界自己動手建。

他還有一個觀點小編覺得蠻尖銳的: 好的產品思維比以前更有價值，壞的產品思維比以前更浪費資源。為什麼？因為一個爛想法現在可以在一個下午變成原型，然後帶著「都已經做好了，合進去吧！」的慣性要求審查——這不只浪費審查者的時間，還有把爛功能塞進產品的風險。

最後一個有趣的點: Harrison 說 PRD 沒有真的死，死掉的是「PRD → mockup → code」這條流水線。需求描述仍然不可或缺——審查者需要知道原型裡哪些行為是有意為之、哪些只是意外。他甚至丟了一個挑釁的問題: 未來的 PRD 會不會就是一組結構化的 prompt？

10. 不同的聲音

上面主要是 Anthropic 的視角，但業界的討論比這更複雜，至少有三種不同立場。

「不是所有 PM 都在同一條船上」派。 Michele PM 區分了兩種 PM: 流程型（靠寫文件、跑儀式、保持專案運轉來建立身份）和決策型（靠取捨、判斷、conviction 來建立身份）。AI 拿走的是工作裡「舒適」的部分，前者感到被威脅，後者反而被解放——行政負擔掉了，留下的是他們本來就在乎的工作。Art Kreimer 講得更不客氣:「很多『成功的』PM 其實是靠錯誤的理由成功的——如果你的優勢是整合、寫文件、協調，那個優勢正在被侵蝕。」他認為 PM 角色正在收斂成一件事: 在不確定性下快速做出高品質決策，而且對的次數要夠多。LinkedIn 把 Associate PM 計畫改名為「Product Builder」，訓練內容橫跨產品、設計、工程，入場券從「會跑流程」變成「能展現品味和判斷力」。Andrew Ng 也直接點名——工程速度在爆炸，但產品決策速度沒跟上，有些團隊甚至討論「1 個 PM 配 0.5 個工程師」的極端比例。

「砍 PM 的公司會後悔」派。 Meta 砍了 3,600 人、Tidal 砍掉整個 PM 團隊、Microsoft 砍了 15,000 個職位。Product Party 預測這些公司 12-18 個月內會學到昂貴的一課。AI 可以自動化文件、加速開發，但它不懂排序——不知道 Feature A 必須在 Feature B 之前 ship 因為 A 驗證了讓 B 值得做的市場假設。它也不懂 momentum，不懂組織政治，不懂什麼時候該放棄一個數字上合理但戰略上錯誤的方向。PM 的價值從來不是開站會和寫 spec，而是同時看見工程能做什麼、客戶真正需要什麼、商業上需要什麼存活，然後在三者之間做取捨。Balsamiq 訪問的產品專家也說:「AI 可以在幾秒內做出原型，但它不能告訴你這個功能到底解決了真正的用戶痛點，還是只是增加了複雜度。那個判斷是純粹的人類產品思維。」

「這套敘事本身有盲點」派。 Anthropic 的產品核心就是 AI 模型，模型每進步一代產品價值可能翻 10 倍——在這種曲線上短衝刺當然合理。但如果你做的是銀行系統、醫療軟體、或任何需要法規合規的產品，「一個下午做好原型」不只不現實，可能還違法。多數公司的產品價值曲線是線性的，傳統 PM 的 playbook 沒有那麼過時。Jenny Wen 在柏林宣布「設計流程已死」時台下一半人反駁——雙鑽石模型存在是有原因的，AI 讓你建造得更快，但建造錯誤的東西也更快了。而「PM 要會寫程式」可能也是階段性風潮，十年前是「PM 要會 SQL」，五年前是「PM 要懂 Python」，重點從來不是工具本身，是能不能問出對的問題。bencoding.com 有一個很好的比喻: 如果組織不能對取捨做出乾脆的決定，AI 會把產品變成吃角子老虎機——大量產出，結果不可預測。速度不等於方向。

小編覺得真相取決於你的產品離 AI 指數曲線有多近。越近的公司變化越劇烈，越遠的公司傳統 PM 技能保鮮期還沒那麼短。但不管在哪個位置，有一件事各方都同意: 把「協調」和「寫文件」當核心價值的時代，確實在結束。

什麼在升值、什麼在貶值

把上面正反觀點放在一起看，小編覺得有一條清楚的主線: 工作的價值分布正在重新排列，只是速度因公司而異。

正在貶值的:

• 微優化和長期路線圖（願景的保鮮期可能只剩 3-6 個月）
• 精美的設計稿和 PRD（demo 和原型取而代之）
• 執行型的協調工作（AI 正在吃掉「人肉中間件」層）
• 靠流程和文件建立的專業身份

正在升值的:

• 判斷力: 決定「做什麼」和「為什麼做」，在不確定性下快速做出高品質決策
• 跨部門對齊: 就算有了 AGI，讓六個人在同一間房間達成共識還是不可能
• 建造能力: 能自己從想法做到原型，但前提是問對問題
• 韌性: 願意每三個月丟掉舊做法，接受自己會的東西可能很快過期

Amol 在訪談最後說:「進來的第一件事，是接受你過去 50-70% 的工作方式必須整個丟掉。」這句話不一定適用於所有產業，但方向沒有錯。Jenny Wen 被問到座右銘，想了想，說: It is what it is。在一切都在變的世界裡，也許這種輕盈感才是讓你繼續走下去最需要的東西。

參考資料:

• Cat Wu, Product Management on the AI Exponential, Anthropic Claude Blog, 2026/3
• Jenny Wen on Lenny’s Podcast: 設計流程已死（狐說八道整理）
• Amol Avasarala on Lenny’s Podcast: Anthropic 成長負責人訪談（狐說八道整理）
• 宝玉 @dotey 的 Jenny Wen 訪談筆記
• pirrer 的 Neethan Wu 三層設計系統整理
• Harrison Chase, How Coding Agents Are Reshaping Engineering, Product and Design, X Article, 2026/3

但進入 2026 年，風向開始變了。小編想聊聊: cloud agent 平台的論述哪裡有道理、哪裡出了問題，以及為什麼開發者用腳投票，選擇把 agent 留在自己的環境裡跑。

Cloud Agent 論述快速回顧

這波論述裡最有代表性的是 Landgraf 和 Dabit 這兩篇，先公平地整理一下他們的核心論點:

Landgraf 的觀點 — Stripe 的 Minions 每週合併上千個 agent 產出的 PR、Ramp 的背景 agent 貢獻 57% 的合併 PR、Ona 自己達到 88.5%。這些公司有什麼共同點? 不是更好的 agent 框架或更聰明的模型，而是早在 AI 時代之前就標準化了雲端開發環境。他的結論: 你的筆電跑不了五個完整的 monorepo 環境，cloud development environment 是背景 agent 的先決條件，localhost 即將終結。

Dabit 的觀點 — Cloud agent 不是「跑在別人電腦上的 local agent」，而是完全不同的品類。Local agent 是配對程式設計 (pair programming)，cloud agent 是委派 (delegation)。PM 可以在 Slack 標記 agent 修 bug、初級工程師從 Jira 觸發遷移、設計師回報問題午餐前就有 PR。不同角色、不同入口、同一個 codebase，大多數人根本不需要裝本機環境。

這兩篇的共同主張: 跑在開發者自己機器上的 coding agent 是一個局部最大值 (local maximum)，真正的槓桿在跑在雲端平台上的組織級 agent。

聽起來很有道理對吧? 但市場選了另一條路。DevConsole 甚至用了「Localhost Renaissance」(本機文藝復興) 來形容這個趨勢: 「創投倒了幾十億進去推 Cloud IDE，但真正做產品的工程師已經回到自己的機器上了。」

市場給出了不同答案

讓我們看看這三個月發生了什麼:

🔹 OpenAI Codex 的轉向 — Codex 在 2025 年 4 月以雲端 agent 身份推出，主打在 OpenAI 託管的 sandbox 裡非同步執行任務、自動開 PR。但到了 2026 年 2 月，OpenAI 重兵投入的卻是 Codex App — 一個 macOS 桌面應用，讓開發者在本機管理多個 agent，用 git worktree 做隔離。VentureBeat 在去年九月的報導中就提到一個耐人尋味的數據: IDE 擴充套件已經成為 Codex 最受歡迎的使用方式，「反映了開發者偏好直接在自己的程式碼旁邊工作」。Cloud 版本還在，但 OpenAI 顯然看到了市場訊號。

🔹 Claude Code 持續稱霸 — Anthropic 的 CLI coding agent，跑在你的終端機裡，直接操作你的本機檔案系統。它可以互動式地跟你一起寫 code，也可以用 Subagent-Driven Development (SDD) 流程在背景長時間自主執行複雜任務。重點是: 不管哪種模式，agent 都跑在你自己的環境裡。根據多份獨立調查，它已經是目前工程師滿意度最高的 AI coding 工具之一。

🔹 OpenClaw 崛起 — 開源的 AI coding assistant，核心價值觀寫在首頁: local-first，工作區和設定都在你的掌控之下。跨平台、可組合、可審計。

🔹 Cursor 加了 cloud agent，但重心還是本機 — Cursor 二月底宣布 cloud agent 功能，每個 agent 跑在獨立 VM 裡。但他們自己的數據是「30% 的 PR 來自 cloud agent」，也就是說 70% 的工作還是在本機完成。Cloud agent 是補充，不是取代。

🔹 Devin 的現實落差 — AwesomeAgents 的深度評測給了 Devin 6.5/10。在複雜任務上，Devin 只有約 15% 的成功率不需人工介入。成本不可預測 (ACU 計費讓預算很難抓)。Augment Code 的對比數據也蠻有說服力: Codex 的 PR 接受率 64%，Devin 只有 49%。評測結論: 擅長範圍明確的重複性工作 (遷移、安全修補、測試生成)，但「日常 coding 伴侶」這個角色它扛不起來。

趨勢很清楚: 開發者工具的重心正在往「自己的環境」收斂，而不是往第三方雲端平台發散。

為什麼開發者選擇自己的環境?

先釐清一個常見誤解: Dabit 把 local agent 等同於「pair programming」、cloud agent 等同於「delegation」，這是一個假二分法。跑在自己環境裡的 agent 一樣可以背景執行、長時間自主工作。Claude Code 可以用 SDD 流程派出多個 subagent 平行處理任務；Codex App 可以同時開多個 agent session，用 git worktree 隔離，甚至遠端操控。這些都不是「你盯著螢幕看 agent 一行一行寫 code」的 pair programming。Augment Code 的對比評測講得很直白: 「Devin 感覺像把工作委派給遠端外包商；Codex 感覺像跟一個你可以調整參與度的夥伴合作。」

真正的差異不是互動模式，而是誰擁有執行環境。 在自己環境裡跑的 agent (不管是筆電、公司的 server、還是自家的 cloud VM)，你有完整的控制權。Cloud agent 平台則是把工作交給別人的基礎設施。這才是根本的分界線。

小編整理了幾個核心原因:

1. 自己的環境 vs 別人的平台

這是最根本的差異。不管是互動式還是背景跑，agent 在你自己的開發環境裡運作: 你的檔案系統、你的依賴、你的設定、你的內部服務。你有完整的存取權和控制權。

Cloud agent 平台則是把工作交給一個你不控制的基礎設施。你的程式碼、環境變數、API 金鑰、資料庫連線資訊，全都要送到別人的沙盒裡。Landgraf 的文章花了很大篇幅講 Ona 怎麼用 VM 隔離、kernel 層監控、短期憑證來解決安全問題。這些都是好工程，但它們存在的前提是: 你把東西送出去了，所以需要這些防護。在自己環境裡跑的 agent 根本不需要面對這個問題。

更實際的是: 你的開發環境跟生產環境之間的距離越近，agent 產出的品質就越高。自己環境裡的 agent 天然能跑你的完整測試套件、連你的 staging 資料庫、打你的內部 API。Cloud agent 平台要達到同樣的整合度，需要大量的網路設定、VPN tunnel、secrets 管理，而且每一層都是潛在的故障點。

2. 回饋循環的可選擇性

在自己環境跑 agent，你可以自由選擇介入的深度。簡單任務? 丟出去背景跑，回來收 PR。複雜任務? 即時監控，看到 agent 走偏了三秒內糾正。同一個工具，兩種模式自由切換。

Cloud agent 平台則幾乎只有一種模式: 描述任務 → 等待 → 收結果。當 session 出問題，你看不到它在做什麼、沒辦法跳進去直接改一個指令或檔案。Devin 評測裡提到的一個痛點就是: 「當 session 出問題，你只能在聊天裡重新引導它，不能直接介入修正。」AgentRank 的 Devin 2.2 評測更不客氣: 過去用戶直接叫它「被過度炒作的初級實習生」。

這不是「要不要 pair programming」的問題，而是你有沒有選擇權的問題。自己的環境給你全光譜的介入選項，cloud agent 平台把你鎖在「委派 → 等待」這一端。

3. 「可委派工作」的比例被高估了

Dabit 在文章裡列了一長串 cloud agent 擅長的事: 重構、bug 修復、測試覆蓋、CVE 修補、依賴升級、文件維護、CI 除錯。他也承認了一句: 「如果一個初級工程師拿到明確指示就能處理的，cloud agent 就能處理。」

問題是: 你每天的工作裡，有多少比例是「給初級工程師明確指示就能搞定」的? 而且這些工作，跑在自己機器上的 agent 一樣能做，根本不需要上到別人的雲端平台。Claude Code 的 SDD 流程、Codex App 的多 agent 管理，處理這類明確任務綽綽有餘。

Cloud agent 平台的真正價值主張其實不是「能跑背景任務」(localhost 也能)，而是「讓不懂 Git 的 PM 也能在 Slack 派任務」。這個需求是真實的，但它的市場比「讓工程師更有生產力」小太多了。

4. 成本可控，模型選擇更自由

Claude Code 和 Codex 都是按 API token 計費，用多少付多少，花費透明可控。Devin 的 ACU (Agent Compute Unit) 計費模式讓很多用戶抱怨「跑完一個任務才知道花了多少錢」。對個人開發者和小團隊來說，這是一個很現實的考量。

更關鍵的是模型選擇權。在自己環境跑 agent，你可以自由切換背後的模型: 用 Claude 跑複雜架構設計、用 GPT 處理日常任務、甚至用 Ollama 跑開源模型 (Qwen Coder、DeepSeek 等) 來壓低成本或保護隱私。Cloud agent 平台則把你鎖定在它選的模型上 — Devin 用自己的模型組合，你沒得選。隨著開源模型的 coding 能力快速追上來，這個靈活度差距只會越來越大。

5. 開發環境不需要「標準化到雲端」就能跑 agent

Landgraf 的核心論點是: 你需要先把開發環境搬上雲端、標準化，agent 才能大規模跑。Stripe 和 Ramp 之所以成功，是因為它們花了好幾年做雲端 devbox。

但 2026 年的現實是: 本機環境標準化的工具已經成熟了。Dev Container 規範、Nix、docker compose、甚至簡單的 Makefile + shell script，都能讓「新人 clone 下來十分鐘跑起來」這件事在本機實現。你不需要把環境搬到別人的雲端才能標準化。

Git worktree 讓你在本機隔離多個 agent 的工作區。是的，Landgraf 說 monorepo 裡開五個 worktree 筆電會爆掉 — 但多數團隊不是 Stripe 等級的 monorepo，而且如果真的需要更多算力，你可以開自己的 VM 或用自己公司的 cloud 資源，不需要把整個開發環境託管給第三方平台。

Anthropic 自己也是這個立場

值得注意的是: 連製造 Claude 的 Anthropic，產品策略也是站在「自己的環境」這邊。Latent Space 最近專訪了 Anthropic 的 Felix，主題就叫 Why Anthropic Thinks AI Should Have Its Own Computer。Felix 一句話總結他的看法:

「Silicon Valley overall is undervaluing the local computer.」 (整個矽谷低估了本機電腦)

他用了一個很傳神的比喻: 「如果你雇了一個開發者，但告訴他『你不需要電腦，我們會寄 email 給你裝著程式碼，你也寄 email 回來』，這顯然不會很有效率。」AI agent 也一樣。

Anthropic 的具體做法是 Claude Cowork — 用輕量 VM (macOS 上用 Apple Virtualization Framework、Windows 上用 Host Compute System) 在你的機器上開一個隔離環境給 agent 用。Felix 列舉的優勢跟我前面講的幾乎一模一樣:

• 資料親近性: 不用把整個工作環境複製到雲端
• 認證穩定: 不用把帳號 cookie 搬上雲端 (異地登入觸發風控)
• 權限簡化: 用作業系統現有的權限就好，不用為每個雲端服務搞 API token
• 工具自由: agent 自己 pip install、npm install，不用預先配置

Felix 點出一個關鍵: 真正要做到 agent 能「委派並走開」，需要的不是雲端平台，而是給 agent 一個它自己的電腦 — 一個有完整工具鏈、可以安裝依賴、可以網路存取、但跟主機隔離的環境。這個環境不必、也不應該在第三方雲端，它就在你的機器上。

當製造 Claude 的公司自己都這樣想，「localhost 即將終結」這個論述就更站不住腳了。

Cloud Agent 不是沒用，是定位錯了

小編不是說 cloud agent 毫無價值。Stripe 和 Ramp 的數據是真實的，那些 agent 確實每週合併上千個 PR。但注意: 這些都是大型企業，有標準化的開發環境 (Landgraf 自己也強調了這一點)、有明確定義的重複性任務、有專門的平台團隊來維護整套基礎設施。

Cloud agent 的甜蜜點是: 組織級的、範圍明確的批次自動化。大規模遷移、安全修補、合規檢查、測試補充。這些工作確實適合「描述任務 → agent 非同步執行 → 收到 PR」的模式。

但 cloud agent 陣營犯的錯誤是把這個甜蜜點泛化成整個軟體開發的未來。「localhost 即將終結」這個宣言太過了。對絕大多數開發者來說，不管是互動式開發還是背景自動化，agent 跑在自己掌控的環境裡就是比較好 — 更靈活、更安全、更便宜、整合度更高。

有意思的是，連 cloud agent 的倡導者自己都在用行動承認這一點。Cursor 的數據顯示 70% 的工作還是在本機，他們並沒有把 cloud agent 當作唯一路徑。OpenAI 最重要的新投資是桌面端的 Codex App，不是雲端的 Codex sandbox。

真正的分界線不是 local vs cloud

小編覺得這場辯論最容易搞混的地方是把「local vs cloud」跟「互動 vs 非同步」混為一談。Dabit 的文章就犯了這個錯: 他把 local agent 釘死在「pair programming」上，把非同步執行當成 cloud agent 平台的專利。

但現實是: 在自己環境跑的 agent 早就能非同步了。Claude Code 的 SDD 流程可以派出多個 subagent 平行處理複雜任務；Codex App 讓你同時管理多個背景 agent session；你甚至可以在自家的雲端 VM 上跑 Claude Code，讓它整夜工作。這些都是「非同步」和「背景執行」，但環境是你自己的。

真正的分界線是誰擁有執行環境:

• 自己的環境 (不管是筆電、辦公室的 server、還是自家公司的 cloud VM) → 你擁有完整控制權，可以互動也可以背景跑，安全邊界你自己管
• 第三方平台 (Devin、Ona 等) → 你的程式碼和 secrets 送到別人的基礎設施，介入能力受限，多一層平台依賴

開發者選了前者，不是因為守舊，也不是因為只想 pair programming。而是因為自己的環境天然就有更好的整合度、更靈活的介入選項、更簡單的安全模型，而且現有工具已經能在這個基礎上做到非同步和平行化了。

Cloud agent 平台要說服開發者，需要回答的不是「模型夠不夠聰明」的問題，而是「你為什麼要把開發環境交給我們」的問題。目前看來，除了 Stripe 等級有專門平台團隊的大企業有動力這樣做之外，多數團隊的答案是: 不需要。

延伸閱讀

Cloud Agent 論述:

• The Last Year of Localhost (Johannes Landgraf / Ona)
• The Cloud Agent Thesis (Nader Dabit / Cognition)
• The End of Localhost: Why Cloud Dev Environments Are the Future (DEV Community)
• The End of Local (Charlie Labs)

反面觀點:

• Why Anthropic Thinks AI Should Have Its Own Computer (Latent Space)
• The Localhost Renaissance (DevConsole)
• Why I’m Building Local-First Developer Tools (DEV Community)
• Devin vs Codex Desktop App 對比 (Augment Code)
• Devin 深度評測 (AwesomeAgents)
• Devin 2.2 評測 (AgentRank)

產品動態:

• Introducing the Codex App (OpenAI)
• Codex Cloud 文件 (OpenAI)
• Cursor Agent Computer Use (Cursor)

直覺會說「A 贏了 2.3 個百分點」。但 Anthropic 研究員 Evan Miller 在 2024 年發了一篇蠻重要的 paper Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations，配上一篇好讀的 部落格版本，告訴大家: 這個差異很可能根本是雜訊，你看到的「贏」只是運氣。

Cameron R. Wolfe 後來寫了一篇很棒的導讀 A Statistical Approach to LLM Evaluations，把 paper 裡的統計觀念整理得更完整好懂，也補充了 power analysis、小樣本陷阱等實務面向。

這篇綜合這兩份資料，整理一份「做 LLM 評估時你應該知道的統計觀念」，不教數學公式，聚焦在實務上跑 eval、比較 prompt 和 Agent 時能直接用的判斷原則。

為什麼小數差就是雜訊

先講一個讓人冒冷汗的事實: 主流 benchmark 換個 prompt 就能讓分數跳動好幾個百分點。但業界拿來比較模型強弱的差距通常只有 1 個百分點左右。

量測本身的雜訊，比模型的真實差異還大。也就是說，你看到「模型 A 比 B 強 1%」這件事，很可能完全是雜訊。

但研究界、產品界天天在做這種「排行榜思維」的判斷:

• 看到新模型 benchmark 高 0.5% 就說 SOTA
• 改一版 prompt 跑 100 題好了 3% 就上線
• A/B 兩個檢索方法跑 50 題差 5% 就決定改架構

這些都是沒做統計檢定就下結論。Evan Miller 的核心訴求很簡單: eval 就是科學實驗，請用做實驗的態度來分析。

換個視角: eval 不是排行榜，是抽樣

paper 裡有個關鍵的視角轉換:

我們在 eval 上看到的分數，不是模型的真實能力，而是從一個「題目宇宙」中抽出 n 題後得到的「樣本平均」。

這個視角一旦建立，世界就不一樣了。MMLU 那 1.4 萬題不是「全部能考的題目」，只是某個假想題目分布裡的一個樣本。換另外 1.4 萬題，模型分數一定會不一樣。

問題是: 不一樣多少？

這個「不一樣多少」就是「誤差線」。報告分數時要連同誤差線一起報，不然就是在誤導人。

下面整理 paper 的幾個核心觀念。

建議 1: 永遠回報誤差線

最基本的觀念。一個分數沒有誤差線，就像「今天溫度 25 度」沒告訴你是「±1 度」還是「±10 度」一樣，沒辦法判斷意義。

直觀理解: 題目越多，誤差線越小。具體感受一下 (假設模型答對率 70% 左右):

看到了嗎？一個模型 100 題拿 70%，另一個 100 題拿 73%，根本分不出高下，兩個信賴區間完全重疊。

而且誤差不是線性遞減: 題目從 100 加到 200，誤差只從 ±9% 縮到 ±6.4%。想把誤差砍一半，題目要翻 4 倍。

第一條紀律: 看到 eval 分數沒附誤差線，就不要拿小數點差距下強結論。

編按: 統計上這個叫「中央極限定理」。不用懂公式，記口訣就好: 誤差要減 3 倍，題目要加 10 倍。

建議 2: 題目不獨立時，誤差比你以為的大

這個是最容易踩雷的點。

很多 eval 的題目其實不是獨立的:

• DROP、SQuAD 這類閱讀測驗: 同一段文章會出 5-10 題
• MGSM: 同一道數學題翻成 11 種語言
• HumanEval: 一個 problem 配多個 test case，但通過與否要算 problem-level

為什麼有差？因為「會不會某段文章」會決定那 5-10 題全對全錯。真正獨立的資訊量遠少於題目總數。假裝它們獨立，會嚴重低估誤差線 — 修正後的誤差可以是天真版本的 3 倍以上。

實務上的修正叫 clustered standard errors，主流統計套件都有現成函式。

第二條紀律: 題目有「群組結構」(同主題、同來源、同模板) 時，預設你看到的誤差線太小，差異很可能根本不顯著。

建議 3: 同一題多跑幾次

模型對同一題的回答其實有兩層隨機:

1. 題目本身的隨機: 題目是抽樣來的，這個改不了
2. 生成的隨機: 同一題模型每次答案可能不同，這個可以改

第二層隨機的解法很直覺: 同一題跑幾次取平均。雜訊會明顯下降，但邊際效益遞減，通常 5-6 次就夠了。如果是選擇題，更乾淨的做法是直接看模型給「正確答案 token」的機率，根本不用採樣。

具體例子: 你在跑一個 Agent eval，100 題。Agent 有隨機性，同一題可能這次成功率 60%、下次 80%。只跑一次，誤差會包含很多「這次 Agent 心情不好」的雜訊。改成每題跑 5 次取平均，雜訊就被抹平掉一大半。

⚠️ 一個常見迷思: 「我把 temperature 調成 0 應該就沒有方差了吧？」

paper 對這個直覺很保留。重點不是 temperature=0 一定變糟，而是為了降 variance 不該動 temperature — 這會改變你正在量測的模型行為，搞不好還引入偏誤。要降雜訊，重採樣就好。

第三條紀律: Agent / RAG 這類有隨機性的任務，每題重採樣幾次取平均，比執著於 temperature 調 0 有效得多。

建議 4: 比較兩個模型: 用配對分析 + 想清楚要多少題

這是小編覺得 paper 裡最有立即實用性的建議。

比較模型 A 和 B 的正確做法是:

讓 A、B 跑同一批題目，看每一題上「A 跟 B 的分差」，再對這些分差求平均、算誤差線。

不要分別算 A、B 各自的分數然後相減。後者會浪費掉很多資訊。這個做法在統計上叫配對分析 (paired difference analysis)。

直覺解釋: 兩個模型通常都覺得簡單題簡單、難題困難。那些「兩個都對」或「兩個都錯」的題目對判斷誰強沒幫助，真正有資訊量的是「一個對一個錯」的題目。配對分析直接抓住這個差異 — paper 實測，同樣題目數，誤差線大約可以縮到原本的 6-8 成 (依兩個模型的相關性而定)。

那要多少題才夠？這取決於你想偵測多大的差異。統計上有個方法叫 power analysis，但不用管名詞，記住一個關鍵: 題目數和可偵測的差異之間是平方關係。舉例來說，200 題大約能偵測 7% 的差異，如果你想偵測更細的 3.5% 差異，不是加倍到 400 題就好，而是要翻到 4 倍、也就是 800 題。

下面這張表可以直接查 (二元評分、配對分析、答對率約 70%):

所以 50 題的 Agent eval 跑出 A 版 75%、B 版 70%，那 5% 的差距其實偵測不到 — 測試集對這個級別的差異沒有區分力，跑了也是白跑。

實務上的建議: 跑之前先決定你在乎多大的差異。如果兩版 prompt 差不到 5% 對業務沒影響，那 100 題就夠了。如果 3% 的改善就有意義 (例如生產環境的客服準確率)，就需要拉到 500-1000 題。先算帳再跑，不要跑完才發現白做工。

第四條紀律: 比較兩個方案，請跑同一批題目並逐題比對。跑之前先想清楚你在乎多大的差異，題目數不夠就別拿小差異做決策。

建議 5: 小樣本 eval 的信賴區間可能是假的

前面講的信賴區間都依賴中央極限定理 (CLT)，而 CLT 有個前提: n 要夠大。

研究發現，當 n < 100 時，CLT 算出來的信賴區間會系統性偏窄 — 你以為是 95% 信賴區間，實際覆蓋率可能只有 85-90%。翻譯成白話: 你比實際上更有信心，而那個信心是虛的。

什麼情況下特別嚴重？

• 準確率接近 0% 或 100%: 例如某個 Agent 在 30 題的 eval 上拿 93%，CLT 會給出很窄的信賴區間，但其實非常不可靠
• 刻意設計的極難 eval: 準確率只有 5-10% 的 benchmark，CLT 同樣撐不住
• Agent eval 天然就題少: 設計一個高品質的端到端 Agent 測試案例很費工，手上常常只有 30-80 個案例，每跑一次還可能花幾分鐘甚至幾十分鐘

遇到小樣本怎麼辦？

1. 心裡調寬信賴區間: 如果算出 ±5%，自己當 ±8% 來看
2. 不要拿小樣本的小差異下結論: 50 題的 eval 差 5%？先假設是雜訊
3. 考慮 Bayesian 方法: 如果對統計工具有一定掌握度，Bayesian 信賴區間在小樣本時比傳統方法穩健得多，特別適合 Agent eval 這種「題目少但每題成本高」的場景

這對做 Agent 評估的人尤其重要。承認「我的樣本不夠大，結論要保守看」比假裝信賴區間很可靠來得誠實。

第五條紀律: eval 題目少於 100 時，對信賴區間和顯著性結論都要打個折扣。

paper 的實例: 表面 2 勝 1 敗，其實是 1 勝 2 平

paper 用兩個虛構模型「Galleon」和「Dreadnought」在三個 benchmark 上對比:

• MATH (5000 題): Galleon 65.5% vs Dreadnought 63.0%，Galleon 顯著領先
• HumanEval (164 題): Galleon 83.6% vs Dreadnought 86.7%，不顯著 (n 太小)
• MGSM (2500 題, 250 個語言群組): Galleon 75.3% vs Dreadnought 78.0%，不顯著 (cluster 修正後)

表面讀法: Dreadnought 在三場裡贏了兩場，整體比較強。

做過統計後: 只有 Galleon 在 MATH 的勝利有統計顯著性，其他兩場差異都在誤差範圍內。真實結論變成 Galleon 一勝二平，方向跟表面剛好相反。

不做統計，你會看到「Dreadnought 較強」的故事；做了統計，你會看到「只有 Galleon 在 MATH 真的贏，其他無從判斷」的故事。結論差很多。

補充: 還有更多雜訊來源

Evan Miller 的 paper 主要處理「題目抽樣」這層雜訊，但 LLM eval 還有更多麻煩來源。2025 年的 Signal and Noise: A Framework for Reducing Uncertainty in Language Model Evaluation 把雜訊拆得更細:

• Prediction noise: 同題不同回答
• Data noise: 從題目分布抽樣的隨機性
• Seed variance: 訓練 seed 不同造成的差異
• Prompt sensitivity: prompt 換一下分數就跳

這篇還有個有意思的發現: 某些 eval 上只用 16 個高訊噪比的子任務反而比跑全部 MMLU 更能區分模型。題目越多不一定越好，訊噪比才是關鍵。

編按: NeurIPS 2024 的 Quantifying Variance in Evaluation Benchmarks 也測了主流 benchmark 的 variance，發現有些 benchmark 連 seed 差異都足以蓋過模型間的差異。

小編的實務 checklist

整理一份開發 LLM 應用、跑 eval 時可以直接套的清單:

1. 先想清楚「獨立觀測單位」是什麼

一道題？一篇文章？一個 coding problem？一個 user session？這是所有統計的起點。SQuAD 的單位是「文章」不是「題目」、HumanEval 是「problem」不是「test case」。搞錯這個，後面所有的誤差線、信賴區間、顯著性檢定全部失準。

2. 永遠回報誤差線，不要只貼平均值

一個 70% 的分數沒附誤差線，沒辦法判斷意義。最少附上 95% 信賴區間或標準誤，順手把 n (題目數) 一起寫清楚，讓讀者能自己判斷可信度。「66% ± 3% (n=1000)」比孤零零的「66.3%」有用一百倍。

3. 題目有群組結構就做 cluster 修正

同主題、同來源、同模板的題目不獨立，不能假裝是獨立樣本。常見地雷: 一篇文章配多題的閱讀測驗、同一道題翻成多語言、同一個 prompt 模板生成的多道題。實務上用 clustered standard errors，主流統計套件 (R、Python 的 statsmodels) 都有現成函式，Anthropic 推薦的 Inspect 評估框架也內建處理。

4. 比較兩個模型一定要用配對分析 (paired difference analysis)

讓兩個模型跑同一批題目，逐題比對，回報「分差」的平均和誤差線，不要分開報 A、B 兩個分數讓讀者自己腦補比較。同樣題目數，配對分析的誤差線可以縮到原本的 6-8 成 — 等於白賺出有效樣本數，這是 paper 裡 CP 值最高的建議。

5. 有隨機性的任務每題多跑幾次取平均

Agent、RAG、tool use 這類任務每次跑結果都不太一樣，只跑一次的雜訊會非常大。每題重採樣 5-6 次取平均，邊際效益就遞減了，不需要跑更多。如果是選擇題類型，可以直接讀模型給「正確答案 token」的機率，連採樣都不用。不要為了降 variance 把 temperature 調 0，那會改變你正在量測的模型行為，搞不好還引入偏誤。

6. 跑 eval 前先做 power analysis — 先算帳再跑

不要跑完才想「這個差異有沒有意義」。跑之前先決定你在乎多大的差異，再反推需要多少題。記住: 想偵測一半大的差異，題目要翻 4 倍。50 題的 Agent eval 只適合偵測 15% 以上的大差距；想看 3-5% 的差異至少要 500 題。先算帳再跑，不要跑完才發現白做工。

7. 小樣本 (n < 100) 的信賴區間要打折看

題目少於 100 時，信賴區間的計算會系統性偏樂觀 — 標示 95% 的信賴區間實際上可能只有 85-90% 的覆蓋率。Agent eval 因為每題成本高，常常只有幾十題，這時候不要太相信算出來的信賴區間和顯著性結論，心裡要多打一些折扣。

8. 小於 1-2% 的差異預設當雜訊看待

除非 n 非常大 (像 MMLU 1.4 萬題級) 而且做了配對分析，否則 1% 以內的差距很難說是真的。看到 leaderboard 上「+0.3% 新 SOTA」的宣稱，第一個反應應該是「誤差線多大？」而不是「哇好強」。實務決策上，1% 差距通常不該成為換模型的理由 — 換模型的成本 (測試、迴歸、prompt 微調) 大概率比這 1% 大。

9. 用 leaderboard 排名做判斷時，看「重疊區間」而不是「名次」

很多排行榜模型的差距小於各自的誤差線，意思是換另外一批題目，名次很可能洗牌。看排行榜時養成「畫一條誤差線」的習慣，把信賴區間重疊的模型當成「打成平手」，不要被小數點後的排名騙了。

結尾

引用 paper 結語的一句話:

「統計學是『在有雜訊的情況下做測量』的科學。」

LLM eval 就是有雜訊的測量。當整個產業還在用「最高分就是贏」的思維時，誰先把 eval 當實驗來做、誰先學會看誤差線，誰就有更大的機率做出真正的進步、避開假性的退步。

這不是學術潔癖，是工程紀律。下次看到 leaderboard 上「+0.3% 新 SOTA」的宣稱，第一個問題應該是: 誤差線多大？

但要怎麼寫才有效? 二月初蘇黎世聯邦理工學院出了篇論文得到一個反直覺結論，在 X 上被 Theo、Matt Pocock 等大 V 放大講成「AGENTS.md 反而會害你」，引發後續一堆討論。實際上比這更微妙。小編把研究、作者本人的澄清、反對聲音，加上社群歸納的實務建議，整理一下。

1. 反直覺結果: LLM 自動生成的 AGENTS.md 反而會降低成功率

蘇黎世聯邦理工學院 LogicStar 團隊的這篇論文做了大規模實驗。他們在 SWE-bench Lite 跟自建的 AgentBench (138 個任務、12 個有 context file 的 repo) 上跑 Claude Code、Codex、Qwen Code 三套 agent，測試三種設定: 沒有 context file、用 agent 內建的 /init 自動生成、開發者手寫的。

結果:

• LLM 自動生成的: 平均降低 3% 成功率，但增加 20% 推論成本 (多 2-4 步操作)
• 開發者手寫的: 只有微弱的正向效果 (~4%)，但同樣會增加成本
• 不論用什麼模型生 (Claude Sonnet 4.5、GPT-5.2、Qwen3-30B-Coder)、用什麼 prompt (Codex 的、Claude Code 的)，結論都差不多

換句話說: 如果你是直接 /init 出來的 CLAUDE.md，可能比沒有更糟。

2. 為什麼會這樣? 不是 agent 不聽話，是它太聽話

這篇論文有意思的地方是它做了追蹤分析。發現有 context file 的時候:

• agent 跑更多測試 (pytest 多用)
• 探索更多檔案 (grep、read 多)
• 推理 token 多 22%
• 但找到第一個相關檔案的步數沒有變少 — 這顛覆了「context file 是專案地圖」的假設

研究團隊也檢查了 agent 對指令的依從度: 被寫進 AGENTS.md 的工具，使用次數會從幾乎為零跳到平均每次任務 1.6-2.5 次。Phil Schmid 在 X 上的整理算了一個更直觀的數字: 提到的工具被使用機率高 160 倍。

所以重點是: agent 確實會遵守 AGENTS.md 裡的指令，問題是寫進去的「不必要指令」反而讓任務變複雜。

編按: 還有一個諷刺的發現 — 研究團隊把 repo 裡所有 .md、docs/、範例程式碼都刪掉之後，LLM 自動生成的 context file 才開始發揮正面效果。意思是這些自動產生的內容很大程度上就是在重複既有文件而已。難怪寫了等於白寫。

3. 該寫什麼? WHAT / WHY / HOW

Phil Schmid 根據這篇研究歸納成三塊:

• WHAT (是什麼): 技術棧、專案結構、各部分做什麼。Monorepo 特別重要 (因為 agent 不容易自己摸出來)
• WHY (為什麼): 專案目的、關鍵元件存在的理由。幫 agent 理解意圖而不只是結構
• HOW (怎麼做): 怎麼建置、測試、驗證變更。特別是非預期的工具鏈 — 例如這個專案用 uv 而不是 pip、用 bun 而不是 npm

一個更精確的判準是: 如果這件事 agent 自己讀程式碼就能發現，那就不用寫。值得寫的東西反過來都是 agent 沒辦法從程式碼推出來的 — 非預期的工具鏈選擇、歷史包袱、團隊共識、外部約束、踩過的雷。

4. 不該寫什麼? 大多數人塞進去的其實沒幫助

研究團隊的追蹤分析跟社群觀察意外一致 — 自動生成的 AGENTS.md 最常包但最沒用的就是這幾類:

• 重述 README 跟既有文件的內容: 研究最諷刺的發現 — 把 repo 裡所有 .md 跟 docs/ 刪掉之後，LLM 自動產生的 AGENTS.md 才開始有正面效果。換句話說大部分自動產生的內容只是在「複述既有文件」，等於白寫
• 大段架構概覽 / 目錄列表: 100% 的 LLM 自動產生 AGENTS.md 都會包這種「我們的架構分三層、handler 處理 X、service 處理 Y…」，但研究數據顯示這對 agent 找對檔案的速度沒有任何改善。Agent 一個 ls 就能拼出結構，不需要你告訴它
• 看得到的技術棧細節: package.json、pyproject.toml 已經寫了，agent 看得到。「我們用 React」是廢話，「我們用 React 18 但 hooks 走自己的 wrapper」才有價值
• 程式風格規定: 「用 4 空格縮排」、「camelCase 命名」這種規則交給 linter / formatter 處理，比塞進 AGENTS.md 便宜、確定、不吃上下文配額。記得前面提的數字: 模型可靠順從上限約 150-200 條指令，別拿來寫 linter 做得更好的事
• 空泛的標語: 「寫 clean code」、「good naming」、「performance matters」這種話，模型訓練資料裡一堆，寫了等於沒寫，還佔順從度配額
• 詳細 API 文件: 用連結帶到外部文件就好，不要把整個 API table 貼進來
• 只在特定情境才用到的指令: 「部署時要先 X」、「跑 e2e 測試前要 Y」這種任務指令應該分到專門的子檔案，用條件區塊或 import 帶進來，不要塞在主檔讓每次工作階段都看
• 自動 /init 出來不修就放著: 這篇研究最直接的結論。/init 預設會包前面所有「沒幫助」的內容，平均降 3% 成功率、增 20% 成本

研究最後的 takeaway 句子蠻一針見血: 「人寫的 context file 應該只描述最低限度的需求」。多寫不會加分，反而扣分。

5. 反過來看: 作者本人的澄清，跟方法論上的爭議

論文紅了之後，作者 Thibaud Gloaguen 在 LinkedIn 上親自貼了一篇，點名 Theo 跟 Matt Pocock 把研究結論講歪了。他重申:

我們證明的是 LLM 自動生成的 AGENTS.md (例如 Claude Code 的 /init) 沒有提升任務完成率，而且讓 agent 行為變得更「吵」。但簡潔的、人寫的 AGENTS.md 是可以幫到 coding agent 的。重點在於: 如果你決定要在每次互動前都加上某些指令，先問自己這些指令對你大多數任務真的需要嗎? 如果不是，看情況再加上去可能更好。

也就是說，真正的反派是 /init 跟「塞越多越好」的心態，不是 AGENTS.md 本身。

幾個值得提的反對跟補充意見:

• 研究選的 repo 樣本可能有偏差: InfoQ 報導裡有開發者留言指出，研究選的 repo 大多是「最近的 LLM 周邊小型隨興開發專案」，AGENTS.md 品質本來就參差。對於有大量領域知識、未公開的中大型專案，「人寫的高品質 AGENTS.md」價值會大很多
• 只測測試通過率，沒測程式品質: LinkedIn 留言裡有個重要追問 — 如果 agent 把測試弄綠了，但完全忽略專案命名規範跟架構慣例，這篇研究是看不出來的。換個評估指標可能整個結論都不一樣
• Vercel 的案例反而證實有效: the-decoder.com 提到 Vercel 在「教 agent 它訓練資料裡沒有的最新 Next.js 知識」這個情境下，context file 效果非常顯著。研究測的是「修一般 bug」這種 agent 早就知道怎麼做的任務，自然看不出來
• 寫 AGENTS.md 的副效果是逼你思考: 另一條 InfoQ 留言寫得蠻誠實: 「我維護 CLAUDE.md 三個月了，效果比想像中明顯，但不是因為它真的給了什麼 context — 而是寫的過程逼你把腦袋裡的隱性知識 (『這個怪 pattern 是因為 Y 的歷史包袱』) 講清楚。寫下來之後 agent 接收到了，新進工程師也接收到了。」

編按: 還有一個有趣的同時期論文 Lulla et al. 結論看似衝突: 它測出 AGENTS.md 反而讓中位執行時間降 28%、輸出 token 降 17%。Sulat Substack 的解析點出兩篇其實沒衝突 — Lulla 測的是「agent 多快瀏覽 codebase」(效率)，Gloaguen 測的是「agent 有沒有真的解出來」(正確性)。Context file 讓 agent 找路找得快，但不見得讓 agent 答得對。

6. GitHub 從 2500+ repos 學到什麼?

GitHub 的這篇觀察了跨 Claude Code、Codex、Copilot 的 2500 多個 agents.md，歸納出 5 個原則 (其實跟前面論文呼應):

1. 可執行指令放前面 — npm test、pytest -v 這種 agent 會反覆查的東西，放開頭最容易被找到
2. 程式碼範例 > 長篇解釋 — 一個示範你 codebase 風格的真實片段，勝過幾段抽象描述
3. 明確的邊界 — 三層: 永遠要做、要先問、絕對不要做。最常見也最有用的一條: 「絕對不要 commit secrets」
4. 具體的技術棧細節 — 不要寫「React 專案」，要寫「React 18 + TypeScript + Vite + Tailwind CSS」並標版本
5. 6 個核心領域: 指令、測試、專案結構、程式風格、git 工作流、邊界

7. 為什麼 Claude 會忽略你的 CLAUDE.md?

HumanLayer 的 Dex Horthy 寫了一篇蠻關鍵的觀察: Claude Code 的系統提示詞會把 CLAUDE.md 包在一個 <system_reminder> 裡，並明確告訴模型「以下內容可能跟你的任務相關，也可能不相關」。

這就是為什麼當你的 CLAUDE.md 越寫越長，agent 會越來越常忽略某些段落 — 它真的會主動過濾。

他的解法是用條件區塊把場景特定的指令包起來:

<important if="writing or modifying tests">
- Use createTestApp() helper for integration tests
- Mock database with dbMock
</important>

不要把所有東西都包，核心東西 (技術棧、目錄結構、專案身分) 還是要常駐。但測試、部署這種只在特定場景才用得到的，加上條件就比較不會被當成可選的。

另一篇 HumanLayer 的《Writing a good CLAUDE.md》有個更狠的數字: 前緣模型大概只能可靠遵守 150-200 條指令，Claude Code 自己的系統提示已經吃掉約 50 條，所以你的空間其實沒那麼多。HumanLayer 自己的 CLAUDE.md 只有 60 行。

8. 大專案怎麼辦? 不要寫一份大檔，要分層

當你的 AGENTS.md 超過 150-200 行，社群普遍建議改用模組化:

• 每個子目錄一份 AGENTS.md: Codex CLI、Cursor、Copilot 都支援階層式合併 — agent 在 packages/api/ 工作時，會把根目錄、中間層、和 packages/api/AGENTS.md 都讀進來。OpenAI 自己的 Codex repo 就用了 88 個 AGENTS.md，monorepo 每個服務一份
• import 語法: Claude Code 支援 @agent_docs/database.md 這種引用，把領域特定的指引拆出去，主檔只放路標
• 跨工具用 symlink: 多工具團隊常見做法 — 寫一份 AGENTS.md 當作唯一來源，CLAUDE.md、.cursorrules 都用 symlink 指過去，不要維護平行版本

更極端的做法是有獨立開發者用 Claude Code 蓋 10.8 萬行 C# 系統時演化出的三層架構: 一份 660 行的「constitution」永遠載入、19 個領域子 agent 按需呼叫、34 份規格文件透過 MCP server 檢索。這篇 Codified Context 論文的核心觀念是「文件是 agent 依賴的基礎建設，過期就會出錯，要當程式碼一樣維護」 — 對 monorepo 跟複雜 codebase 是個值得參考的模型。

9. 真正的紅線要靠 hooks，不能只靠 CLAUDE.md

redreamality 的這篇深度整理有個常被忽略的數字: 即便寫得再好，CLAUDE.md 規則的順從率大約只有 70%。

意思是「絕對不能做的事」如果只寫在 CLAUDE.md 裡，會有三成機率 agent 還是會做。所以社群的成熟做法是把規則分兩層:

• CLAUDE.md (建議性): 寫慣例、偏好、流程 — 70% 的順從率夠用了
• .claude/settings.json 的 hooks (機械性): 真正的硬規則寫在這裡。例如 PreToolUse 回 exit code 2 是唯一能真的攔下 agent 動作的方式。「不能 push 到 main」、「edit 後一定要 lint」這種事用 hook 寫，不是放在 CLAUDE.md 裡許願

這也呼應 redreamality 那篇蠻精準的一句框架:

寫 CLAUDE.md 的時候，你不是在寫一段 prompt，你是在寫一個系統的執行期變數。

它每次工作階段都會跟任務、時間、其他上下文互動，不是靜態文字。把它從 100 行砍到 80 行不是排版，是在重構。

小編的綜整

這幾篇加起來其實在講同一件事的不同層次:

• 預設保持精簡 — 目標 300 行以內，能用 60 行更好。每一行都會吃掉每次工作階段的上下文，要值得
• 重點寫「不寫就會錯的東西」 — 用 uv 不是 pip、用 bun 不是 npm，這種非預期的工具鏈比結構概覽有用得多
• 寫偏好比寫事實有價值 — Ben Tossell 那篇的觀點蠻一致: 技術棧跟結構 agent 自己摸得到，但「測試完再給我網址」、「用 Exa 不要用內建 search」這種行為偏好它摸不到
• 採漸進式揭露 — 主檔案放路標，細節分到 agent_docs/ 或子 agent。對複雜專案甚至要走到三層架構搭配 MCP 檢索
• 不要 /init 出來就放著 — 數據顯示自動產生的會降低成功率，要人工修
• 真正的紅線用 hooks，不要許願 — CLAUDE.md 是建議，hooks 才是強制
• 把文件當基礎建設，不是 README — 文件過期 agent 就會錯，要納入維護週期

最有啟發的一點是: 寫 CLAUDE.md 的本質，是在跟一個「每次都失憶但會完全相信文件」的 agent 工作。你不是在寫給未來會加入團隊的工程師看，是在設計一個 agent 在開始工作前的記憶植入。這個視角換過來，什麼該寫、什麼不該寫，自然就清楚了。