為什麼多數 Agent 框架都沒有內化 Bitter Lesson?
看到這篇 Minh Pham 的 Why Most Agent Harnesses Are Not Bitter Lesson Pilled，覺得觀點蠻犀利的，把 Rich Sutton 經典的「Bitter Lesson」套用到 2026 年的 agent 架構設計上來檢視。
Bitter Lesson 是什麼?
2019 年 Rich Sutton 寫了一篇短文觀察到: 在 AI 歷史上，利用大規模運算的通用方法，幾乎總是打敗人類精心設計的特定領域知識。這個教訓之所以「苦澀」，是因為它違反研究者的直覺——我們總想把自己的理解灌進系統裡，但這些手工知識最終都會被純粹靠算力的方法輾壓。
最經典的例子: Deep Blue 靠大量西洋棋知識 + 搜尋贏了卡斯帕洛夫，但 AlphaZero 從零開始自我對弈就把所有傳統引擎打趴。
套用到 Agent 框架: 三個反模式
作者指出現在多數 agent 架構都在做一件事:「模型不夠可靠，所以我們把可靠性寫進外層框架裡。」這在產品層面合理，但本質上是把複雜度從可規模化的部分（模型）搬到不可規模化的部分（手工搭建的鷹架程式碼(scaffolding)）。
🔹 工作流陷阱(Workflow Trap): 視覺化的工作流建構器讓你用拖拉方式把「研究 → 摘要 → 撰寫」串起來，但你其實是把自己對任務分解的假設硬編碼進架構了。模型進步時，你的工作流不會自動變簡單，因為團隊已經綁死在那個流程圖了。
🔹 專職子代理幻覺(Specialized Subagent Illusion): 設計一個研究 agent、一個寫程式 agent、一個寫作 agent，這很像人類組織架構。但人類組織是在認知有限、溝通成本高的約束下演化出來的，AI 不一定有這些限制。當你把固定的角色分工凍結在架構裡，你是在進口人類的限制而不是利用運算的優勢。
🔹 迴圈天花板(For-Loop Ceiling): 「LLM + 迴圈 + 工具就夠了」聽起來很精簡，但你唯一的擴展旋鈕就是迭代次數。面對複雜任務，這是一維的擴展，很難平行化，也容易浪費 token。
什麼才是對的方向?
作者認為符合 Bitter Lesson 的做法有兩個特徵: 把額外的算力轉化為更好的決策，而不依賴固定的人類設計分解方式。
1️⃣ 動態子代理生成(Dynamic Subagent Spawning): 不要預先定義團隊，讓系統在執行時動態創建需要的子代理。這其實更像是一種設計原則，而不是某個特定的實作方式。核心思想就一句話: 不要在設計時預先固定 agent 的分工和流程，而是讓模型在執行時根據任務需求自行決定怎麼拆解、要生成幾個子代理、各自做什麼。
具體實作方式其實差異很大，但都符合這個概念:
- Anthropic Multi-Agent Research: 主代理透過 prompt + 延伸思考動態決定任務分解(decomposition)，子代理就是透過工具呼叫建立的新 Claude 實例
- LangChain Deep Agents: 提供一個任務工具，主代理呼叫它就能生成子代理，但可用的子代理類型是預先註冊的
- Claude Code: 主代理可以把任務委派給子代理在獨立上下文裡執行
回到 Bitter Lesson 的框架，真正重要的區分不在於具體用什麼框架或 API，而是一個光譜: 一端是固定工作流——人類在設計時就決定了所有步驟和分工（如拖拉式的工作流建構器）；另一端是完全動態——模型自己決定要拆成幾個子任務、每個子任務要怎麼做、要不要再遞迴拆下去。現實中大多數系統都落在中間——你還是會提供一些結構（可用的工具、子代理模板、協調協議），但盡量把「怎麼拆、何時拆、拆多深」的決策權交給模型。
關鍵是: 隨著模型進步，委派策略(delegation policy)可以「免費」變好，不需要你重寫組織圖。
2️⃣ 遞迴語言模型(Recursive Language Models, RLMs): MIT 的研究把整個 prompt 當成外部字串，模型透過程式碼和遞迴自我呼叫來推理。可以處理比原生注意力視窗(attention window)大 100 倍的輸入，在 6-11M token 的基準測試上達到 91% 以上準確率，而且因為模型是選擇性檢視上下文而非全部處理，成本可以便宜到 3 倍。這讓模型自己決定要檢視、壓縮、遞迴什麼，而不是人類來規定。
一個實用的檢驗標準
作者提出一個很好的判斷準則:
如果模型能力明年翻倍，你的系統會不會在不需要大幅重構的情況下，變得顯著更簡單、更便宜、或更可靠?
如果答案是肯定的，你可能站在 Bitter Lesson 這邊。如果你的擴展計畫是「加更多節點/角色」，那你是在擴展人力。如果是「讓模型透過通用方法分配更多算力」，那你才是在擴展運算。
當然，作者也強調這描述的是長期趨勢，不是立即的處方。短期內工作流因為提供確定性、可稽核性、安全控制和可除錯性，在產品層面還是會繼續贏。Anthropic 建議從簡單開始也是對的。
但往後幾年，最後勝出的 agent 框架會越來越不像手工打造的組織圖，而更像一個算力分配引擎(compute allocation engine): 動態委派、遞迴分解、學習式控制策略，以及越來越多由模型驅動而非規則驅動的評估迴圈。
結構不是有害的——而是結構應該從學習中浮現，而不是從設計中強加。Agent 框架應該是通往可規模化運算的薄薄介面，而不是你把智慧藏進去的地方。
歷史對聰明但無法規模化的設計並不仁慈，但對押注運算的人相當慷慨。