今日總覽
今天三篇論文合起來,像是在辯論同一個問題的正反兩面:Agent 的鷹架(harness,管理工具呼叫與上下文的外部系統)到底該多厚?JAZ 主張答案可以是「幾乎不需要」——只用一個叫 invoke 的原語,不接任何專門的記憶或自我改進系統,就在對應的任務上打贏了兩套專門框架。Harness-Zero 給出另一種薄化路徑:先讓客製化鷹架教會模型該怎麼做,再把鷹架拆掉,好處已經蒸餾進權重裡了。但 TraceDance 從 25 萬多筆真實部署紀錄潑了一盆冷水:不管你的鷹架厚薄如何,今天的前沿模型光是「動手前先做該做的檢查」這種基本習慣,通過率都只有個位數到一成出頭。三篇合起來提醒一件事:鷹架該多厚或許還沒有標準答案,但「該做的檢查有沒有做」已經有明確的量化落差。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Harness(鷹架/腳手架) | 包著 LLM、管理工具呼叫、上下文與環境互動的外部程式系統,不含模型本身 |
| invoke 原語 | JAZ 提出的單一 LLM 呼叫原語,LLM 能寫任意可執行程式碼並遞迴呼叫自己 |
| 蒸餾(Distillation) | 把某個機制(這裡是客製化鷹架)帶來的行為,透過訓練資料轉移進模型權重,讓模型不再需要那個機制也能表現出同樣行為 |
| 決策點續寫(Decision-Point Continuation) | 把 Agent 在真實紀錄裡某個關鍵決策點之前的完整脈絡原封不動搬過來,讓受測模型接著做下一步再評分 |
| LoRA 監督微調 | 只調整模型一小部分低秩參數的微調方法,成本比全參數微調低很多 |
| Rubric 評分 | 用一份針對特定行為寫死的評分標準來打分,而不是跟標準答案比對 |
論文一｜JAZ:一個 invoke 原語,打平專門的記憶與自我改進系統
Harness as a Language: A Minimalist Agent Framework With Maximal Expressivity Zhening Li, Joshua Liu, Mateja Vukelic et al.(MIT CSAIL) · arxiv: 2609.26891
TL;DR
只靠一個叫 invoke 的原語,不接外部記憶或自我改進系統,在需要跨越上下文視窗回憶的 StuLife 任務上打贏專門的記憶系統 Letta(MemGPT),成本卻只要不到一半;在 AppWorld 的持續自我改進任務上,同樣打贏專門框架 ACE。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(尚未經同行審查) |
| 引用速度 | 發布 9 天,Semantic Scholar 因 rate limit(429)本輪無法查得引用數 |
| 機構 | MIT CSAIL(另有數位獨立研究者共同掛名) |
| 社群反應 | 發布不到一週已有第三方重現 repo(AIMentalModel/dsh-jaz)、被 DAIR.AI Academy 收錄論文導讀、DAIR.AI 創辦人 @omarsar0 發推薦帖 |
| 可信度 | 通過 — 兩個案例研究各有具名基準(Letta、ACE、CodeAct+subagents)、3 次獨立重跑的均值與標準誤 |
| 證據成熟度 | 較完整 — 長程回憶與持續自我改進兩個獨立場景都有清楚的基準比較與成本報告 |
| 可復現性 | 部分產物 — 官方尚未釋出程式碼,但附錄給了完整 prompt 與 hook 實作;已有社群重現版本 |
| 為什麼選這篇 | 直接 — 直接挑戰「Agent 需要多厚的客製化鷹架」這個當紅問題 |
| 方向新意 | 實質增量 — 用單一原語取代整套外部記憶/自我改進系統的設計路線 |
| 今日重要性 | 高 — 同一週還有另外兩個獨立團隊在做同方向的鷹架研究,顯示這是個熱門的收斂題目 |
| 實務連結 | 明確 — 對是否要外接 Letta、ACE 這類專門系統提供量化的成本/效益取捨依據 |
| 編輯信心 | 高 — 足以支持「特定長程回憶與自我改進場景下,單一原語可以打平專門系統」這個限定主張 |
| 閱讀建議 | 必讀 — 正在選型長程 Agent 框架或記憶系統的團隊 |
| 主要限制 | 只在兩個 benchmark 上驗證,且都偏長程記憶/自我改進場景,能否推廣到需要大量專門工具的任務仍待驗證 |
領域背景
現代 LLM Agent 的基本設計是「agent loop」:模型置身於一個暴露工具的環境裡,靠呼叫工具與觀察結果反覆決策。但要處理超出上下文視窗的長程任務,或讓 Agent 自己越做越好,社群通常會外接專門系統——像 Letta(MemGPT)這樣的記憶資料庫,或像 ACE 這樣的持續自我改進框架,兩者都需要額外的工程搭建與維護。
中階導讀
- 問題:想像 Agent 要做一個橫跨一整個學期、途中會用完好幾次對話視窗的任務;或者你想讓 Agent 在重複做同一類任務時自己越做越好,而不是每次重新手寫 prompt。過去的做法是外接一個專門的記憶資料庫,或外接一個專門的「自我改進」框架。
- 方法:JAZ 只給 Agent 一個叫 invoke 的函式,LLM 每次呼叫時自己決定這次要怎麼實作,能寫任意可執行程式碼、能遞迴呼叫 invoke,而且所有輸入與互動紀錄都是程式環境裡的一般變數,可以被檢視、篩選、再傳遞。長程回憶靠「尾遞迴委派」:上下文快滿時,把整段歷史原封不動委派給子 Agent 繼續做,不需要專門的壓縮或摘要系統。持續自我改進則讓上層 invoke 扮演「元 Agent」,直接把下層 Agent 的 prompt、技能當成程式變數來調整,不用另外接一個優化框架。
- 為什麼重要:兩個案例研究處理的正是專門系統原本要解決的問題,JAZ 沒加任何專門機制卻打贏了兩個對照組,顯示問題不一定出在「需要更多工程」,而可能出在「現有的通用原語本身不夠通用」。
深入要點
- StuLife 全部 939 個計分任務:JAZ invoke pass 72.6%±0.1 / score 81.6%±0.1,對比 Letta 70.9%±0.5 / 81.0%±0.5
- StuLife 遠距離回憶子集(207 個需要回想 50 個任務前資訊的任務):JAZ invoke pass 69.9%±1.8 / score 73.6%±1.5,對比 Letta 61.8%±2.3 / 67.0%±2.4,但成本只要 $18.3,Letta 要 $42.1(約 44% 的成本)
- 沒有專門記憶機制的陽春基準 CodeAct+subagents,在遠距離回憶子集 pass 率只有 20.6%~32.0%,說明沒有機制處理長程依賴時表現會明顯掉
- 根據論文摘要,在 AppWorld 417 個任務的持續自我改進設定下,JAZ invoke 打贏專門框架 ACE 約 4 個百分點,且成本更低
- 落地訊號:官方雖未釋出程式碼,但發布不到一週已有社群重現版本(AIMentalModel/dsh-jaz),顯示上手門檻不算高
- Limitation:兩個 benchmark 都偏向長程記憶與自我改進場景,是否能推廣到需要大量專門工具、複雜工具鏈的任務仍待驗證
Reviewer 一句話評
用同一個模型分飾學生與監督者角色排除了「換更強模型」這個混淆變因,3 次獨立重跑加標準誤都有報,是這類「少即是多」論文少見的嚴謹程度;但兩個 benchmark 都偏向長程記憶與自我改進,還不能說「所有場景都不需要專門系統」。
給你的 take-away
- 如果你在評估要不要接 Letta/MemGPT 之類的專門記憶系統:先確認任務是不是真的需要「跨視窗檢索」,如果只是普通的長對話,這篇顯示善用程式碼環境的變數可能比外接資料庫更划算
- 如果你在設計 Agent 自我改進的機制:JAZ 把「元 Agent 調整子 Agent 的輸入」直接寫成遞迴呼叫,不需要另外接一個優化框架,這是可以直接參考的設計模式
論文二｜Harness-Zero:把客製化鷹架的行為蒸餾進模型權重,再把鷹架拆掉
Harness-Zero: Harness Distillation via Agent-as-Harness Haoran Ye, Yuxing Lu, Haonan Dong et al.(北京大學通用人工智慧國家重點實驗室) · arxiv: 2609.24974
TL;DR
用一個「鷹架代理」(harnessing agent)把客製化鷹架的行為蒸餾進模型權重,部署時把客製化鷹架拆掉,9B 模型在三個任務領域的平均表現從 23.3% 拉到 44.3%,甚至超過鷹架還掛著時的 41.7%。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(尚未經同行審查) |
| 引用速度 | 發布 10 天,Semantic Scholar 因 rate limit(429)本輪無法查得引用數 |
| 機構 | 北京大學智能科學與技術學院通用人工智慧國家重點實驗室 |
| 社群反應 | 官方 repo(github.com/metaevo-ai/harness-zero)今日確認已公開;已被兩個獨立的「awesome-rsi」(遞迴自我改進)GitHub 社群書單收錄 |
| 可信度 | 通過 — 三個任務領域、多重基準(含兩個通用鷹架 DeepAgents、Claude Code 當對照)、獨立消融表拆解訊號來源 |
| 證據成熟度 | 較完整 — 涵蓋試算表操作、互動工具使用、化學逆合成三個領域,加上完整的蒸餾訊號消融 |
| 可復現性 | 完整產物 — 官方程式碼已公開(此為本輪新確認的訊號,先前(09-27)複核時尚未找到) |
| 為什麼選這篇 | 直接 — 直接處理「客製化鷹架的好處能否脫離鷹架本身」這個部署層問題 |
| 方向新意 | 實質增量 — 把鷹架優化的成果從「維護外部程式」轉為「內化進模型權重」 |
| 今日重要性 | 高 — 與 JAZ 同屬本週密集出現的鷹架厚度辯論,且今天已補齊程式碼釋出這個先前缺的訊號 |
| 實務連結 | 明確 — 對維護多套領域專用鷹架的 Agent 平台提供收斂工程複雜度的具體路線 |
| 編輯信心 | 高 — 足以支持「客製化鷹架的程序性行為可以蒸餾進權重並移除鷹架」這個限定主張 |
| 閱讀建議 | 必讀 — 正在維護多套領域專用鷹架、思考部署複雜度的 Agent 平台團隊 |
| 主要限制 | 深層領域知識(如分子驗證邏輯)比程序性行為更難內化,USPTO 領域蒸餾後仍落後鷹架掛著時的版本 |
領域背景
Agent harness(管理工具呼叫、上下文與環境互動的外部系統)是目前提升 Agent 表現的主要槓桿之一,但客製化鷹架的好處綁死在部署時那套鷹架上——換個領域、換個模型,往往得重新調整或維護一整套鷹架。近期 Meta-Harness 這類方法讓鷹架的優化自動化,但優化的終究是外部程式,不是模型本身。
中階導讀
- 問題:想像 Agent 在處理試算表任務時,搭配一套幫它記住哪些儲存格已改過、怎麼驗證結果的客製化鷹架,表現很好;但只要換一個部署環境、拿掉那套鷹架,表現就打回原形——因為好處全綁在那套外部工具上。
- 方法:Harness-Zero 讓一個「鷹架代理」扮演客製化鷹架的角色,在陽春鷹架下的學生 Agent 執行前先審閱、修正它的回應,把客製化鷹架原本會提供的指引轉換成訓練用的示範資料;再用 LoRA 監督微調把這些被修正過的行為內化進模型權重,訓練完就能把客製化鷹架、鷹架代理都拆掉。
- 為什麼重要:這代表「鷹架帶來的效能提升」不一定要在部署時持續依賴那套鷹架,可以先用它「教」,教完就收工——對維護一堆領域專用鷹架的 Agent 平台來說,是個把工程複雜度收斂回模型本身的路線。
深入要點
- 推論時比較(三領域 × 兩模型平均):agent-as-harness(套用演化過的指引)81.1% vs meta-harness(把演化鷹架直接掛上去)78.1% vs 陽春鷹架 68.6%;拿掉指引內容只留審閱動作,平均只剩 69.2%,證明光是「有人審閱」解釋不了大部分增益
- 蒸餾後拆鷹架:9B 模型三領域平均從基準 23.3% 拉到 44.3%,超過鷹架還掛著時的 41.7%;換成兩個通用鷹架 DeepAgents、Claude Code,反而讓 9B 模型表現分別掉到 20.5%、15.9%,說明不是「隨便掛個鷹架就有用」
- USPTO 逆合成任務是例外:蒸餾後 30.0% 仍落後鷹架掛著時的 38.0%,作者認為分子驗證這類需要深層領域知識的能力,比「程序性行為」更難內化
- 消融實驗進一步拆解:直接用老師模型在陽春鷹架下產生的軌跡去蒸餾幾乎沒用,必須是「鷹架代理審閱過的」軌跡才有效
- 落地訊號:本文最早於 09-23 進入本站候選池時,官方程式碼尚未釋出;本輪複核確認 github.com/metaevo-ai/harness-zero 已公開,可復現性從「未提供」升級為「完整產物」
- Limitation:需要一個夠強的鷹架代理模型才能產生有效審閱訊號,若鷹架代理能力不足,審閱反而可能有害(論文附錄 F)
Reviewer 一句話評
同一個模型分飾學生與鷹架代理角色、外加兩個通用鷹架當對照組,把「這到底是不是蒸餾在起作用」的混淆變因處理得很乾淨;但作者自己也承認深層領域知識比程序性行為更難蒸餾,USPTO 的落差是誠實的警訊。
給你的 take-away
- 如果你的 Agent 平台維護多套領域專用鷹架:這篇的路線值得評估——先用鷹架代理審閱訓練軌跡,再蒸餾進模型,部署時精簡到單一陽春鷹架,可能比永久維護一堆客製化鷹架更划算
- 如果你在挑鷹架的複雜度:注意「通用鷹架不一定有幫助」這個發現——論文顯示把 DeepAgents、Claude Code 這類通用工具集直接掛到小模型上,表現反而比什麼都不掛更差
論文三｜TraceDance:25 萬筆真實部署紀錄告訴你,Agent 最常在哪裡摔一跤
TraceDance: An Automated System for Building Agent Behavior Benchmarks from Real-World Agent Deployment Traces Dehai Min, Daoan Zhang, Yiming Zeng et al.(ByteDance + 伊利諾大學芝加哥分校) · arxiv: 2609.33295
TL;DR
從 25 萬多筆真實 Agent 部署紀錄自動建出針對性評測,9 個前沿模型平均能送出合法工具呼叫的機率高達 67.9%,但動手前該做的檢查只有 8.1% 會做,commit 衛生檢查更只有 0.9%。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(尚未經同行審查) |
| 引用速度 | 發布 4 天,Semantic Scholar 因 rate limit(429)本輪無法查得引用數 |
| 機構 | ByteDance Inc. + University of Illinois at Chicago(通訊作者隸屬 UIC) |
| 社群反應 | HuggingFace Daily Papers 46 個讚,官方 repo 已公開,HF 開源團隊主動在 repo 上聯繫作者協助釋出評測資料 |
| 可信度 | 通過 — 139 道測試查詢驗證系統的建置/拒絕能力,84% 人類標註一致率,9 個前沿模型的行為分項評測有具體數字 |
| 證據成熟度 | 較完整 — 涵蓋 coding 與一般工具使用兩種部署場景,包含對抗性查詢測試系統的拒絕能力,而非只測正向案例 |
| 可復現性 | 部分產物 — 官方 repo 與 107 個建好的評測已公開,但底層 25 萬筆部署紀錄是 ByteDance 內部生產流量,不對外釋出 |
| 為什麼選這篇 | 直接 — 直接回答「不管鷹架厚薄,Agent 實際部署後最常在哪裡出問題」 |
| 方向新意 | 實質增量 — 首個從真實部署紀錄自動建出針對性評測的系統,而非依賴固定的通用 benchmark |
| 今日重要性 | 高 — 為 JAZ、Harness-Zero 的鷹架厚度辯論提供現實對照:不管鷹架怎麼設計,安全相關檢查的通過率都低到需要正視 |
| 實務連結 | 明確 — 通過率數字可以直接轉成產品上線前的檢查清單項目 |
| 編輯信心 | 高 — 足以支持「今天的前沿模型在特定安全相關決策點上表現明顯弱於一般工具呼叫」這個具體主張 |
| 閱讀建議 | 必讀 — 所有在生產環境跑 coding agent 或工具呼叫型產品的團隊 |
| 主要限制 | 底層資料是單一公司(ByteDance)的生產流量,某些發現是否反映所有部署場景的通性仍待其他機構驗證 |
領域背景
固定的 benchmark 測不到「部署後才冒出來的特定壞行為」——例如某個 Agent 在特定情境下會忘記檢查失敗訊息就重試,或完成任務時不小心把密鑰寫進 log。開發者通常要等使用者回報才知道有這個問題,而且很難把單一個案轉成可重複測試的評測。
中階導讀
- 問題:想像你的 coding agent 上線後,使用者回報「它有時候會在測試失敗時不看錯誤訊息就直接重跑」。你想把這個具體壞行為變成一個能在每次發新版時重跑的測試,但手動從幾十萬筆對話紀錄裡找出類似案例、寫成評測,是不可能手動完成的工作量。
- 方法:TraceDance 用「錨定與確認」流程,先用一個輕量模型從紀錄裡撈出可能符合描述的候選片段,再逐一確認;「錨點合成迴圈」反覆生成、修正這個壞行為的規格定義,直到能穩定抓到對的案例。評測本身用「決策點續寫」——把 Agent 在真實紀錄裡某個關鍵決策點之前的完整脈絡原封不動搬過來,讓受測模型接著做下一步,再用針對這個行為寫的評分標準打分,不需要參考答案或重跑整個環境。
- 為什麼重要:這代表「今天使用者回報的壞行為」可以在短時間內變成「明天固定會跑的迴歸測試」,把使用者回報和模型迭代之間的回饋循環縮短,而不是讓同一個問題被反覆回報卻始終沒有對應的測試。
深入要點
- 用在 coding 與一般工具使用兩種部署場景,對 252,557 筆真實 sessions 跑過,產出 107 個評測、4,125 個測試實例,95.3% 的建置需求都成功產出
- 系統驗證:139 道測試查詢裡,107 道預期能建出評測(98 個預定義行為 + 9 個自訂行為)、32 道預期會被拒絕(27 個對抗性查詢 + 5 個缺必要參數);人類標註者對抽樣實例的行為判定與系統一致率達 84%,自動評分與人類的一致程度跟人類彼此之間的一致程度相當
- 9 個前沿模型平均:合法工具呼叫(Valid call)通過率 67.9%,但「動手前先做該做的檢查」(Check first)只有 8.1%,「處理錯誤與回饋」(Handle failure)33.5%,「有證據支持的主張」(Honest claim)28.9%
- 細看安全相關行為更低:密鑰保護(Secret protection)6.9%、commit 衛生(Commit hygiene)0.9%、查看失敗紀錄再行動(Failure-log inspection)僅 0.6%
- 反直覺發現:回應一開頭就先呼叫 TodoWrite 之類規劃工具的案例,通過率只有 4.6%,遠低於同一批案例中其他起手式的平均 30.8%,九個模型全部一致
- 整體排名會蓋掉個別行為的落差:Claude Opus 4.8 整體排名第一,贏 Kimi-K3 十個百分點以上,但在「依錯誤訊息修正」(Error-guided correction)這項上,Kimi-K3 以 57.8% 大勝 Opus 的 27.8%
- Limitation:底層 25 萬筆部署紀錄是 ByteDance 內部生產流量,不公開釋出,外部研究者只能重跑已公開的 107 個評測,無法從原始資料重新建構
Reviewer 一句話評
用大量對抗性查詢測系統會不會該拒絕就拒絕、加上人類標註驗證自動評分品質,是這篇在「評測產生器」這個容易灌水的題材裡少見的扎實之處;但底層資料是單一公司的生產流量,某些發現(如 TodoWrite 起手式表現差)是否反映所有部署場景的通性,仍待其他機構驗證。
給你的 take-away
- 如果你在維運 coding agent 或工具呼叫型產品:優先檢查「動手前的檢查」這類低分行為(Check first 只有 8.1%),而不是只看整體任務完成率——這篇顯示任務做完不代表過程乾淨
- 如果你在選型前沿模型:不要只看整體排名,像 Kimi-K3 在「依錯誤修正」這項就贏過整體排名更高的 Opus,針對你實際最在意的行為分別測一次,會比看總排名更準
今日收穫
之前以為「Agent 要更可靠,就要給它更完整的鷹架」,今天這三篇合起來說明沒這麼簡單:JAZ 跟 Harness-Zero 都顯示鷹架可以更薄、甚至蒸餾進模型後直接拆掉;但 TraceDance 從真實部署紀錄看到,不管鷹架厚薄,今天的前沿模型光是「動手前先檢查」這種基本安全習慣,通過率都只有個位數到一成出頭——鷹架該多厚或許還沒有標準答案,但「該做的檢查有沒有做」已經有明確的量化落差。
參考資料
- Harness as a Language: A Minimalist Agent Framework With Maximal Expressivity
- JAZ — alphaxiv
- Harness-Zero: Harness Distillation via Agent-as-Harness
- Harness-Zero — alphaxiv
- Harness-Zero — 官方程式碼
- TraceDance: An Automated System for Building Agent Behavior Benchmarks from Real-World Agent Deployment Traces
- TraceDance — alphaxiv
- TraceDance — 官方程式碼與專案頁
- HuggingFace Daily Papers
Loading...