更聰明的模型殺死了外殼框架，還剩下什麼？——專訪 SpaceXAI 的 Jediah Katz

Jediah Katz 是 2025 年初加入 Cursor、後隨 Cursor 被收購而轉往 SpaceX 的工程師。他的論點是：代理框架（agent harness）並沒有死，死的只是那些用來補貼模型寫程式弱點的部分。整場演講大部分時間都在談他所謂的「資料飛輪」如何讓框架的各種技巧變得過時、Grokbot 的新框架為何又把護欄加回來，以及基礎設施、信任與成本這三項讓框架依然不可或缺的理由；標題那句「更聰明的模型殺死了框架」只是鋪陳，用來帶出他的反駁，並非整集的結論。

Katz 是 Cursor 代理框架團隊裡資歷最深的工程師，如今負責 Grokbot——Cursor 的自主知識工作同事——因此這份簡報建立在他第一手說明團隊加了什麼、刪了什麼、又加回了什麼之上。讀者讀完應該能掌握：飛輪模型、他引用來證明「框架選擇不影響評測分數」的兩份研究、他說模型無法吸收的三件事，以及他對基礎元件（primitive）、補丁（shim）與雲端執行環境的前瞻預測。

資料飛輪讓框架技巧過時，再解鎖新任務

Katz 的核心機制是一個四步迴圈，他稱之為資料飛輪。框架先把更難的寫程式任務帶進可及的範圍；接著更多使用者能用代理實際動手做這些任務，也就有更多寫程式的資料迴流給模型實驗室；模型終究會原生學會這些技能，框架便能刪掉當初需要的鷹架。他把這形容為框架「讓自己變得過時」。

flowchart TD
    A["框架把更難的寫程式任務帶進可及範圍"] --> B["更多使用者用代理嘗試這些任務"]
    B --> C["更多寫程式資料迴流給模型實驗室"]
    C --> D["模型原生學會這些技能"]
    D --> E["框架刪掉自己的鷹架"]
    E --> A

被刪掉的鷹架，例子很具體。Cursor 曾經只用一個小模型來把程式碼修改套進檔案，因為前沿模型當時做不好這件事；它也帶著一堆寫程式專用的指令，教模型怎麼探索程式碼庫、怎麼檢查自己的工作。Katz 說模型如今已「原生吸收了這些技能」，他和同事 Stefan 也寫過文章，談他們如何移除 Cursor 過去用來補貼模型智力不足的護欄。

他引用兩份研究，證明框架選擇已不太影響寫程式的評測分數。柏克萊的一項研究讓七個前沿模型分別跑在 Pi、Codex、Claude Code 等框架上，發現框架選擇並未顯著改變 SWE-bench Lite 的分數，尤其在較新的聰明模型上更是如此。Apple 與 EPFL 的研究則發現，專門的 MLE 框架在 MLE-bench 上也沒有帶來多大差別。Katz 對這能證明什麼相當謹慎：「在今日，花俏的框架已不再增加寫程式的智力。我認為這是真的。」

他也點名了那些宣告框架已死的人。Anthropic 的 Tariq 談到把 Claude Code 的系統提示砍掉一大半；Y Combinator 的 Garry Tan 認為框架會式微，只有技能才重要。Katz 的反駁是：這套說法漏掉了飛輪的最後一個箭頭——當寫程式被模型商品化之後，框架會替模型解鎖下一個待解的新疆界，迴圈於是重新啟動。

Grokbot 逆勢把提示與護欄加回來

在 Cursor，團隊是隨著模型進步不斷移除提示與護欄。但在 Grokbot，Katz 說：「我們反而發現自己把很多這類東西加了回來，加新的提示、加新的護欄。」原因是 Grokbot 鎖定的是模型還沒搞定的新領域與新工作方式。

Grokbot 的框架圍繞著長壽命的協調者機器人（coordinator bot）打造，由它排程一整隊工作型代理，而不是一次性的對話。Katz 的類比是：請一位頂尖律師，他掌握策略、直接跟你對口，但把任務分派給一群初階律師去做。他列出四個重點領域：關鍵網站流程（做簡報、訂機票）、溝通（讓使用者隨時掌握進度又不至於被淹沒）、行動與詢問的界線（像寄信給同事這類有風險的動作，只能照使用者的本意去做），以及透過記憶隨時間學習。

Katz 坦承，對用過寫程式代理的人來說，這些任務都不新。新的是：對 Grokbot 而言，「每個人都以某種方式需要這些能力」，這讓框架成了目前讓這些任務可行的關鍵。他把同樣的邏輯延伸到純寫程式之外的軟體工程工作，指出資深工程師寫的程式更少，做的卻是許多其他同樣重要的事。

框架正演變成排程多個代理的「元框架」

Katz 用一條內部的修 bug 流程，說明他所謂的元框架（meta-harness）。某個頻道回報的 bug 會由自動化流程自動分流，接著啟動一個雲端代理嘗試修復；該代理會留下工具，展示修復前後的影片作為佐證。修復合併、開始部署後，Cursor 的 rollout 產品會再啟動另一個代理，盯著正式環境有沒有出問題。

他把這連上更宏觀的「軟體工廠」概念——多個代理在整個軟體開發生命週期中協同運作。他稱這「離成形的願景還很遠」，卻是全業界框架創新最密集的地方。他指出的架構轉變是：以前的框架是把一堆 LLM 呼叫組起來，而 Grokbot 和軟體工廠這類新框架則以代理為核心積木。

模型無法吸收的三件事：執行環境、信任、成本

Katz 認為框架仍值得關注的第二個理由，是有些部分位在上下文層之外，模型學不到。他把這些分成三類。

| 框架層 | 模型為何無法吸收 | Katz 的具體說明 |
|---|---|---|
| 基礎設施與執行環境 | 代理現在會跑上幾分鐘、幾小時、幾天甚至更久，會休眠的筆電撐不住 | 自主的同事必須跑在雲端 |
| 信任與安全 | 一個 bash 加 API key 的框架就能解寫程式任務，但會暴露機密 | 許可權要限定到特定代理與特定人員；要有護欄擋下災難性動作或一萬美元的 API 帳單 |
| 效率 | 評測分數也許打平，但每項任務的成本沒有 | 快取命中率、Token 效率與模型混搭，讓 Grokbot 在品質不降的前提下壓低成本和延遲 |

談到效率，Katz 指出他引用的兩份研究都發現：即使分數相近，每項任務的成本仍有顯著差異。他說自己過去一個月都在最佳化 Grokbot 的框架，使用者也很買單隨之而來的速度與成本改善。他的結論是：你愈是用代理來工作，一個效率拉滿的框架對你就愈重要。

產品又跑得比模型快了，框架只會更亂

Katz 預測飛輪正在加速，「產品又一次跑得比模型快」。結果是框架在整理乾淨之前會先變得更亂，功能也愈出愈多。他由此推出三個設計上的意涵。

第一，框架的設計要讓功能容易上、也容易下。具體表現之一，是 Grokbot 這類產品愈來愈少把框架的內部運作暴露給使用者。他引用海勒姆定律（Hyrum's Law）——凡是暴露給使用者的東西，就會被依賴——並說犧牲可見度換來的是更快的迭代與更少的變更管理負擔。

第二，更重視基礎元件（primitive）。他定義為可組合的積木式介面，能延伸成各種功能。基礎元件讓你新增功能時不會讓代理的處境變複雜，移除功能時也不必大動干戈重構。他的例子是「訂閱」：一套框架、一個工具，就能讓代理在事件發生時被喚醒——例如 Slack 有人發文、代理關注的 PR 在 CI 上掛掉，或到了某個時間點——而不必為每種情境各做一套整合。

第三，團隊把確定性的護欄集中當成「補丁」（shim）來管理，並記錄模型每次用到哪一個。有個機器人盯著儀錶板，一旦某個補丁不再觸發，代理就會開一個 PR，說這個補丁可以清掉了。Katz 說補丁「有點像 hack」——例如 Grokbot 回應使用者太慢時推它一把——但他寧可現在就修，而不是等下一次模型改版。

Katz 預測：半年內九成的代理工作會離開筆電

Katz 最後給出一個預測：六個月內，九成的代理工作會在筆電之外執行。他說這已是進行中的方向，也是真正自主、能照使用者想要的方式與人協作的代理所必需的。連同前面談的執行環境論點，這是整場演講裡最清楚、可被驗證的預測，也最值得拿 Cursor 與 SpaceX 的產品發布來對照檢驗。

他的整體結論是一分為二的。框架裡那些讓它更會寫程式的部分已死，而這正是飛輪在運作。但框架作為解鎖下一個工作疆界的機制，加上它提供的信任、效率與基礎設施，並不會消失。他的結語是：「昨日的框架或許已死，但明日的代理框架萬歲。」

飛輪論點與效率論點其實互相拉扯

這場演講未解的矛盾在於：Katz 用同一批證據得出兩個不同結論。柏克萊與 Apple／EPFL 的研究顯示框架選擇不影響寫程式分數，他讀成寫程式鷹架已過時的鐵證；但他同時引用這些研究裡每項任務成本的落差，當作框架效率依然極其重要的鐵證。兩者可以同時成立，卻指向不同的未來：一種是框架的差異化最終收斂到價格與延遲，另一種是框架設計仍是持久的護城河。他的 Grokbot 例子暗示解答在於領域擴張——框架只有在持續找到模型尚未吸收的任務時才有價值——這也讓「半年內上雲」的預測與清理補丁的機器人，成為最值得追蹤的兩個營運訊號。這場演講也帶著推銷色彩：Katz 推薦 Grokbot，稱它「具有突破性」、是「新品類」，這些說法讀者應視為廠商的自薦，而非獨立的研究發現。