今日總覽
今天三篇論文分別把手術刀伸進 Agent 系統裡三個容易被當成「調好就不用管」的零件:鷹架、技能檔案、記憶。RRSI 發現讓 LLM 自動迭代改鷹架這件事本身會過擬合——四種現有方法裡最強的一種,拿到新任務反而比什麼都不做還差 1.7 分,加了正規化之後才把這個風險壓下去,換來的是跨網域表現贏過起點超過 1 分。SkillSpec 把矛頭指向正在爆炸性成長的 Agent Skill 生態系,用 Hoare 邏輯的前置/後置條件去比對「說明寫的」跟「程式碼做的」,在 515 個真實 skill 裡挖出 239 個藏著缺陷。Jev-Mem 則問一個更底層的效能問題:記憶系統的每個小決定,真的都需要呼叫一次完整的 LLM 生成嗎?拆成 System One/Two 之後,效能與速度雙雙變好。三篇證據成熟度不同——RRSI 與 SkillSpec 都有大規模基準與明確的驗證程序,Jev-Mem 目前只在單一長對話記憶基準上驗證——但共同點是:Agent 能力的提升,越來越取決於模型以外那些「看起來只是工程細節」的部分有沒有被認真檢查過。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agent 鷹架(Harness) | 包在凍結的模型權重外面的一整套系統:prompt、工具介面、記憶、context 管理與控制流程,決定同一個模型能不能把事情做對 |
| 遞歸自我改進(Recursive Self-Improvement, RSI) | 讓系統用自己產生的回饋去反覆修改自己——這裡改的是鷹架而不是模型權重,理論上能持續變強,但也可能只是把訓練用的任務集背下來 |
| 過擬合(Overfitting) | 在特定任務集上分數變好,換一批沒見過的任務反而變差,這裡特別指鷹架自我改進對評估用的那批任務記得太熟 |
| Hoare 邏輯 / 前置後置條件 | 一種形式化描述「程式該做什麼」的方法:輸入狀態符合前置條件,執行完之後狀態該符合後置條件;SkillSpec 把這套邏輯搬來檢查 Agent Skill |
| Agent Skill | 打包給 Agent 用的可重複使用能力單元,通常是一份 SKILL.md 說明文件加上腳本或其他資源,近年成為 Agent 生態系的標準發布單位 |
| System One / System Two 認知 | 心理學裡區分「快速直覺」與「慢速深思」兩種思考模式的框架,Jev-Mem 借來把記憶系統裡的高頻決策交給不用生成的 System One,複雜推理留給 System Two |
論文一｜RRSI:讓 Agent 自己改鷹架,會不會只是在背答案?
RRSI: Regularized Recursive Self-Improvement of Agent Harnesses Peng Xia, Rujun Han, Zifeng Wang et al.(Google Cloud AI Research + Stanford University + Washington University in St. Louis + UNC-Chapel Hill) · arxiv: 2609.24972
TL;DR
現有鷹架自我改進方法裡評估集表現最強的一種(TTHE),換到沒見過的任務反而比完全不改的起點還差 1.7 分;加上正規化的 RRSI 犧牲掉大部分評估集分數,換來跨八個基準、三個網域最多 4.7 分的跨網域增益,整體跨網域平均贏過起點 43.6 分對 39.7 分。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.LG 主分類、cs.AI 跨列,2026-09-21 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429);發布 1 天,尚無引用資料 |
| 機構 | Google Cloud AI Research,合作機構含 Stanford University、Washington University in St. Louis、UNC-Chapel Hill |
| 社群反應 | 2026-09-22 HuggingFace Daily Papers 批次收錄;程式碼與專案頁已公開釋出 |
| 可信度 | 通過 — 正文附完整方法設計、跨三網域八基準的實驗表格與消融比較 |
| 證據成熟度 | 較完整 — 涵蓋 evolve/held-out 兩種分割、與四種既有方法的直接對照,但作者自陳仍侷限於凍結骨幹模型與有限的評估基準集 |
| 可復現性 | 完整產物 — 程式碼與專案頁皆公開(github.com/google-research/rrsi) |
| 為什麼選這篇 | 直接 — 直接檢驗「鷹架自我改進」這個近期熱門技術路線本身有沒有過擬合風險 |
| 方向新意 | 實質增量 — 首次把機器學習裡的正規化原則(稀疏更新、證據感知的信用分配、保守選擇)系統性搬進鷹架演化的搜尋過程 |
| 今日重要性 | 高 — 任何在用 meta-harness / 自動鷹架調優的團隊都該重新檢查自己的 OOD 驗證流程 |
| 實務連結 | 明確 — 提供可直接套用的三條規則:退火式編輯預算、證據感知信用分配、critic + pruner 選擇機制 |
| 編輯信心 | 高 — 主張範圍(既有方法在 OOD 上排名反轉、RRSI 的正規化能修正這個問題)由完整對照實驗支撐 |
| 閱讀建議 | 必讀 — 正在做或評估自動鷹架優化系統的工程團隊 |
| 主要限制 | 只處理凍結骨幹模型的鷹架層優化,未涉及模型權重同步更新;效果仍依賴 evolve set 品質與正規化超參數的選擇 |
領域背景
近年 Agent 產品的進步很多來自鷹架工程而不是新模型權重,但這套工程過去靠人工檢視失敗軌跡、手動調整,進度受限於工程師能讀多少軌跡。近期方法開始用 LLM 自動迭代提出並選擇鷹架的元件式編輯,實質上是在 agent-system 層級做遞歸自我改進——但這類方法多半只在單一評估集上驗證,對「evolve set 上的進步是否真的可以遷移」這個問題缺乏系統性檢驗。
中階導讀
- 問題:想像工程師用一套自動化迴圈,讓 LLM 反覆修改 Agent 的 system prompt、工具介面與記憶管理規則,對照一組訓練用的任務集不斷選出分數最高的版本。跑完之後這套鷹架在訓練集上表現亮眼,但換一批型態相近、卻沒見過的任務,分數反而掉到起點以下——問題不是模型變差了,是這套「自動改鷹架」的搜尋過程本身學到的是怎麼在這批任務上考高分,而不是真正更好的機制。
- 方法:RRSI 同時在提案端與選擇端加正規化,但不縮小鷹架能被改動的範圍。提案端用退火式的編輯預算限制單輪能綁在一起的修改數量(早期允許多個協同修改探索新機制,後期收緊到接近可歸因於單一修改)、記錄每個候選的假設與結果讓後續提案能參考證據而不是重複測試已經被否定的方向、並在搜尋停滯時鼓勵探索沒碰過的鷹架元件。選擇端配一個 critic 篩掉針對特定基準訂做的提案,再配一個 pruner 移除太小、太貴或已經沒用的改動。
- 為什麼重要:這代表「鷹架自我改進有沒有進步」跟「這個進步能不能遷移到新任務」是兩件必須分開驗證的事——這篇證明只看 evolve set 分數的評估方式,可能會把一個實際上讓系統變差的方法誤判成成功。
深入要點
- 在涵蓋 coding、agentic workspace、engineering design 三個網域的八個基準上測試,包括 SWE-bench Verified、JobBench、GDPval、APEX-Agents 與 Frontier-Eng
- RRSI 在 evolve split 上最多拿下 14.1 分增益,在五個 out-of-distribution held-out 基準上最多拿下 4.7 分增益,且產生的鷹架比未正規化的演化少花 30% policy token
- 對照組裡表現最強的既有方法(TTHE)在 evolve set 上分數最高,但 OOD 平均反而比完全不改的起點(H0)低 1.7 分 ⚠️(作者自測,尚未外部複現);另一個對照方法(Meta-Harness)OOD 只多拿 0.9 分
- RRSI 本身是所有被評估方法裡 evolve-set 增益最小的一個,卻是唯一 OOD 平均贏過起點超過 1 分的方法:43.6 分對 39.7 分
- 落地門檻:需要一套能自動提出並執行鷹架編輯的既有 pipeline(如 meta-harness 類工具),RRSI 是在這之上加正規化規則,不是從零建置的新系統
- Limitation(作者自述):只處理鷹架層優化、骨幹模型權重維持凍結;效果仍依賴有限的 evolve set 品質與正規化超參數選擇;更廣泛的驗證仍待涵蓋差異更大的 agent 架構、工具生態與更長時間的自我改進過程
Reviewer 一句話評
把機器學習裡熟悉的正規化原則系統性搬進鷹架自我改進的搜尋過程,而且用完整的 evolve/OOD 對照證明現有方法確實存在排名反轉的風險,是這篇最有價值的貢獻;但目前的驗證仍停留在幾套精心設計的評估基準,離真實產品裡雜訊更多、任務分布更漂移的自我改進迴圈還有一段距離。
給你的 take-away
- 如果你在做鷹架的自動化調優(meta-harness / 自我改進迴圈):把 RRSI 的四條規則當成 checklist——退火式編輯預算、證據感知信用分配、critic 篩選、pruner 修剪,尤其是「限制單輪能改的元件數量」這條最容易被自動化工具忽略
- 如果你在評估別人發布的鷹架自我改進成果:先追問 OOD held-out 的數字,而不是只看 evolve set 上的漂亮分數——這篇證明兩者可能反著排名
論文二｜SkillSpec:你的 Agent Skill,說明書跟程式碼真的對得上嗎?
SkillSpec: Intent-Masked Specification Reasoning for Agent Skill Correctness Yizhuo Zhang, Bo Kang, Yi Yang et al.(Beihang University) · arxiv: 2609.06052
TL;DR
用 Hoare 邏輯比對「skill 說明宣稱的意圖」與「程式碼與指令實際做的事」,在 515 個真實世界 skill 裡找出 239 個(46.4%)藏著至少一個經人工確認的缺陷,累計 763 個確認缺陷,沙盒驗證下精準率 61.2%。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.SE 主分類、cs.AI 次分類,2026-09-05 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429);發布 18 天,尚無引用資料 |
| 機構 | Beihang University(北京航空航天大學) |
| 社群反應 | 2026-09-22 HuggingFace Daily Papers 批次收錄;程式碼與缺陷資料集已公開釋出(github.com/IainZhang/SkillSpec、huggingface.co/datasets/IainZhang/SkillSpec) |
| 可信度 | 通過 — 正文附完整方法設計、515 個真實 skill 的實測結果與人工確認流程,並說明資料洩漏風險與程序性變異的控制方式 |
| 證據成熟度 | 較完整 — 大規模真實語料、人工確認缺陷、跨模型家族的節點級分析,但作者自陳 skill 圖分解本身並非唯一解,結果會隨分解方式變動 |
| 可復現性 | 完整產物 — 程式碼與缺陷資料集皆公開釋出 |
| 為什麼選這篇 | 直接 — 正面回應「Agent Skill 正在爆炸性成長,但正確性檢查幾乎是空白」這個具體缺口 |
| 方向新意 | 實質增量 — 首次把 Hoare 式規格推理同時用在靜態缺陷偵測與動態沙盒驗證上,涵蓋 workflow 與程式碼兩種異質產物 |
| 今日重要性 | 高 — 對正在發布或維運 Agent Skill 的團隊,提供目前少見的自動化品質保證方法 |
| 實務連結 | 明確 — 沙盒驗證流程可直接借用作為 skill 上架前的自動化第一道品管關卡 |
| 編輯信心 | 高 — 主張範圍(真實 skill 生態系裡缺陷普遍存在,且能被規格推理系統性抓出)由大規模人工確認結果支撐 |
| 閱讀建議 | 必讀 — 正在維護公開或內部 skill 庫的工程團隊 |
| 主要限制 | skill 圖分解本身非唯一,不同分解方式可能得到不同結果;殘留誤報主要來自規格推斷不準確或驗證器自建的、實務上不會發生的邊界案例 |
領域背景
Agent skill 生態系正快速擴張——論文指出六個月內釋出超過 20 萬個 skill——但既有研究多聚焦在基準測試、能力增強與安全性,skill 本身的缺陷檢查幾乎沒人碰。傳統軟體的行為由程式碼決定,可以靠型別系統、測試與執行期錯誤檢查;但 agent skill 大量依賴自由格式的自然語言指令,失效模式不只是傳統程式缺陷,還包括「描述漂移」「意圖衝突」這類語意層級的不一致,而且常常被底層模型的能力悄悄蓋過,變成看不出來的靜默失效。
中階導讀
- 問題:想像你安裝了一個「產出報表」的 skill,說明文件寫著該用某種格式輸出,但附帶的腳本其實做了一件稍微不同的事。因為底層模型很有能力,它可能會自己填補這個落差,產出一份看起來合理但其實不符合原始意圖的結果——這個缺陷從來不會以明顯的「執行失敗」出現,只會安靜地存在,直到某次剛好被人發現。
- 方法:SkillSpec 把整個 skill repository 轉成一個統一的圖表示,對齊描述、指令與程式碼產物。對圖上每個節點,從周邊宣稱的意圖推出「應該做到什麼」的 ExpectSpec,再從實作在部分揭露意圖的情況下推出「實際做了什麼」的 FactSpec。一個「意圖遮罩」控制能看到多少上下文(整體 / 世系 / 鄰近 / 局部四種視角),用來平衡「看太多上下文導致偏向宣稱行為」與「看太少導致推論失控」這兩種相反的風險。標出候選缺陷後,再放進獨立沙盒實際執行驗證。
- 為什麼重要:這代表在越來越多框架把 SKILL.md 當成標準發布單位的當下,終於有一套形式化、可自動化的方法能回答「這個 skill 說的跟做的,到底對不對得上」,而不用等使用者踩到問題才發現。
深入要點
- 語料來自 SkillsBench 與 skills.sh 上下載量最高的 skill(SkillsTop),共 515 個真實世界 skill 進行評測
- 收集當時 skills.sh 共有 884,669 個 skill,篩出安裝數超過 1,000 次的 7,577 個做生態系特徵分析:近半數只有單一 SKILL.md、72.6% 僅含 Markdown 檔案
- SkillSpec 在 239 個 skill(46.4%)裡找出經人工確認的缺陷,累計 763 個確認缺陷,沙盒驗證下的整體精準率為 61.2%
- 跨多個模型家族的節點級分析顯示:規格推理對程式碼節點持續可靠,純文字節點仍是主要瓶頸;多數缺陷發生在宣稱意圖與實作的邊界處
- 落地門檻:需要能執行沙盒重跑的環境(warm container + 每次乾淨 workspace),對已經有 CI/CD 或沙盒基礎設施的團隊,整合成本相對明確
- Limitation(作者自述):skill 圖分解本身非唯一,自然語言 workflow 不像程式碼圖可以被決定性解析;為控制這個變異,論文對所有模型使用同一份凍結圖做對照;殘留誤報主要來自規格推斷不準或驗證器自建、實務上不會出現的邊界案例;驗證也受限於不可得的依賴、憑證、硬體與執行時間
Reviewer 一句話評
把「這個 skill 會不會默默做錯事」轉成一個可測試的 Hoare 式規格一致性問題,並用真實下載量加權的語料與沙盒驗證支撐,對目前幾乎沒有測試文化的 skill 生態系是一個扎實的新方向;但 61.2% 的精準率意味著超過三分之一標出的候選是誤報,而作者自己也承認 skill 圖分解非唯一解,代表結果多少會隨 SkillSpec 恰好怎麼切分特定 skill 而變動。
給你的 take-away
- 如果你在維護或發佈公開的 Agent Skill:用「宣稱的意圖」對「程式碼實際做的事」這個框架自問一輪,尤其留意純文字說明的步驟——這是論文發現最容易藏缺陷的地方
- 如果你在建構 skill marketplace 或內部 skill 庫:SkillSpec 的沙盒驗證流程可以直接參考,作為上架前的自動化第一道品管關卡,不用等使用者回報才發現缺陷
論文三｜Jev-Mem:記憶系統的每個小決定,真的都需要一次完整的 LLM 生成嗎?
Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents Dongming Jiang, Yi Li, Bingzhe Li(The University of Texas at Dallas) · arxiv: 2609.23986
TL;DR
把記憶系統裡「分類、路由、評分、何時停止」這類高頻但範圍明確的決策,從呼叫一次完整生成式 LLM 改成用不需要生成的 System-One 控制器處理,在 LoCoMo 基準上整體 LLM-as-a-Judge 分數達 0.777(比最強對照高 11.0%),記憶建構時間降到 158 秒(比最快對照快 6.6 倍),平均查詢延遲降到 0.93 秒(降 36.7%)。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.AI 主分類、cs.LG 次分類,2026-09-21 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429);發布 1 天,尚無引用資料 |
| 機構 | The University of Texas at Dallas |
| 社群反應 | 2026-09-22 HuggingFace Daily Papers 批次收錄;程式碼已公開釋出(github.com/libingzheren/Jev-Mem) |
| 可信度 | 通過 — 正文附完整架構設計與 LoCoMo 基準上對多個現有記憶系統的直接對照 |
| 證據成熟度 | 初步 — 效能與效率數字完整且對照清楚,但目前只在單一長對話記憶基準(LoCoMo)上驗證,尚未涵蓋其他任務類型 |
| 可復現性 | 完整產物 — 程式碼已公開釋出 |
| 為什麼選這篇 | 直接 — 直接拆解「記憶系統要多聰明」與「每個決策都要用生成式 LLM 做」這兩件被混在一起的事 |
| 方向新意 | 實質增量 — 把 System One/Two 認知框架系統性套用到記憶生命週期的建構與檢索兩端,而不是只優化其中一步 |
| 今日重要性 | 中 — 對長時間執行、記憶量大的 Agent 系統有直接的成本與延遲意義,但驗證範圍目前較窄 |
| 實務連結 | 明確 — 提供具體的架構分工模式:高頻結構化決策交給輕量控制器,複雜推理才留給一般 LLM |
| 編輯信心 | 中 — 效能提升的主張在 LoCoMo 這個設定下由完整對照數字支撐,但推廣到其他任務類型的說法目前缺乏證據 |
| 閱讀建議 | 略讀 — 對正在自建或優化 agent 記憶模組的工程師特別有參考價值 |
| 主要限制 | 目前驗證侷限於 LoCoMo 一個長對話記憶基準,尚未涵蓋程式碼助理、長期規劃等其他任務類型下的表現 |
領域背景
Agent 記憶系統已經從單純的被動儲存與語意相似度檢索,演進到會主動篩選、整合、組織成多關係知識圖譜的複雜子系統。但隨著記憶變得更豐富,控制它的成本也隨之上升——多數系統仍仰賴固定規則(有效率但不靈活)或一般生成式 LLM(語意靈活但每次判斷都要付出 token 生成的代價)來做記憶生命週期裡的各種決策,而這些決策往往頻繁出現在記憶的關鍵路徑上。
中階導讀
- 問題:想像你的 Agent 每次要判斷「這則新筆記跟舊的哪一則有關」「該從哪個記憶區塊檢索」「檢索到的證據夠不夠、要不要繼續搜」,都要呼叫一次完整的 LLM 生成才能拿到答案——即使答案本身只是一個分類標籤或一個分數。一個長時間執行的 Agent 光是做這幾千次小判斷,累積的延遲與成本就會遠超過真正需要深度推理的那些時刻。
- 方法:Jev-Mem 借用 System One/Two 認知框架,把記憶生命週期裡高頻、範圍明確的決策(記憶分類、關聯判斷、查詢路由、檢索預算分配、圖遍歷、候選評分、何時停止)都交給一個不需要生成的 System-One 控制器處理,輸出的是機率或分類而不是自由文字;真正需要開放式推理與答案生成的部分才呼叫一般的 System Two。記憶本身維護在一個多關係資料平面裡,語意、時間、因果、實體四種關係視角共用同一批節點。
- 為什麼重要:這代表「記憶系統要多聰明」跟「記憶系統的每個決策都要用生成式 LLM 做」其實是兩件可以拆開的事——拆開之後,同時拿到效能與效率的提升,不是常見的「犧牲一個換另一個」的取捨。
深入要點
- LoCoMo 基準上整體 LLM-as-a-Judge 分數達 0.777,比最強對照系統高 11.0%(相對值)
- 記憶建構時間降到 158 秒,比最快的對照記憶系統快 6.6 倍
- 平均查詢延遲降到 0.93 秒,比對照系統低 36.7%
- 論文明確指出:目前的 System-One 控制器(Jev)只是一種具體實現方式,核心創新是「把記憶控制拆成獨立系統層」這個架構原則,換其他底層決策器仍待驗證
- 落地門檻:需要能替換掉現有記憶系統裡「用 LLM 判斷」的那些節點,對已經用圖結構組織記憶的系統,改動範圍相對可控
- Limitation(作者自述):目前的效能與效率數字全部來自 LoCoMo 這一個長對話記憶基準,尚未驗證在程式碼助理、長期規劃等其他任務類型下是否保有同樣的提升
Reviewer 一句話評
把「記憶系統的哪些決策真的需要生成式 LLM」這個過去很少被單獨拆出來討論的系統設計問題講清楚,並用公開程式碼與完整對照數字證明成本與效能可以同時改善,是扎實的系統貢獻;但目前的驗證只覆蓋單一長對話基準,距離不同任務類型下的通用結論還有一段距離。
給你的 take-away
- 如果你在建置長時間執行的 agent 記憶系統:盤點你的記憶模組裡有多少「判斷」其實是靠呼叫一次完整的 LLM 生成完成的(分類、路由、何時停止檢索),這些通常就是可以優先換成輕量控制器的候選
- 如果你在評估現有記憶系統的效能:把「準確率」和「建構 / 查詢延遲」分開看,這篇顯示兩者可以同時進步,不必預設要犧牲準確率換速度
今日收穫
之前以為鷹架自我改進、skill 檔案、記憶系統這幾個工程細節,只要跑起來分數變好就代表做對了;今天發現真正的問題往往藏在幾個容易被跳過的檢查步驟裡——有沒有換一批沒見過的任務再測一次、說明文字跟程式碼是否真的對得上、這個決定是不是非要生成式 LLM 才能做。三篇的方法完全不同,但指向同一件事:Agent 系統裡看起來「調好就好」的那些零件,其實都需要獨立的、可驗證的品質保證程序,而不是靠模型夠聰明去悄悄補上落差。
參考資料
- RRSI: Regularized Recursive Self-Improvement of Agent Harnesses
- RRSI — alphaxiv
- RRSI — code & project page
- SkillSpec: Intent-Masked Specification Reasoning for Agent Skill Correctness
- SkillSpec — alphaxiv
- SkillSpec — code & defect dataset
- Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents
- Jev-Mem — alphaxiv
- Jev-Mem — code
- arXiv cs.AI new listings
- HuggingFace Daily Papers
Loading...