什么時候Agent能自己寫skill？

騰訊前沿科技論文解讀專欄，在代碼與商業的交匯處，尋找AI的確定性。

龍蝦為什么好用？其中一個答案就是它的skill太好用了。

2025 年 12 月 18 日，Anthropic 把 Agent Skills 發布為開放標準。一套標準化的文件夾規范，讓 agent 像裝 App 一樣加載專業技能。每個 skill 文件夾里有一份 SKILL.md，寫清楚這個技能是什么、怎么用，還可以放可執行腳本，讓 agent 除了「知道怎么做」，還能真正動手。

標準一出，行業跟進速度快得異常。Microsoft 在 VS Code 和 GitHub 里直接集成。OpenAI 在 ChatGPT 和 Codex CLI 里采用了幾乎一模一樣的架構，只是沒官宣。Cursor、Goose、Amp 等編碼工具也跟了。Box 用 skill 教 Claude 把文件轉成符合公司規范的 PPT 和 Excel，Notion 用 skill 讓 Claude 直接在筆記里執行任務而不是光聊天。

這個標準為什么重要？模型公司們用MCP、CLI、記憶層等harness改造給 agent 裝了手腳，但腦子里沒有專業知識。

Agent Skills 補的就是這一層。不是「你整體上能調用什么工具怎么做事」，而是「一件具體的事，你該怎么把事做對」。

Skill就是工作流程中Know how的結晶。它的另一個好處是可以快速復制。一家公司寫了一套合規檢查 skill，直接分發給所有同事的 Agent 就行。

藍圖確實漂亮，然后現實撞了上來。

Anthropic 自帶了一個叫 skill-creator 的工具，說是能幫用戶自動生成 skill。上線第一周，開發者 Samhita Alla 專門觀察了 100 多個用戶的使用情況，結論是「大多數實現看起來更像玩具而不是工具�！�

skill 該觸發時不觸發、塞進去的指令太多導致 agent 暈掉、安全漏洞、文件格式出錯。反復出現。

自動生成的 skill 粗糙、不可靠，真正好用的 skill 全靠人手工打磨。

當然，skill這個產品之所以能流行，正是因為現階段的Agent對于人類工作的流程、規范和know how還不夠了解。

但我們還是希望 agent 能自己發現解決問題的方法。

其實，「讓 skill 自己長出來」這個問題其實已經被追問了 26 年。

01 從權重到代碼，skill 追了二十六年

1999 年，Rich Sutton 和他的學生 Doina Precup、Satinder Singh 提出了一個叫 options framework 的理論框架。核心想法是，agent 應該能自己發現和組合可復用的行為模塊，而不是每次都從零開始、一步一步試。這是強化學習領域第一次正式提出類似skill的概念。

但那個年代的 skill 困在神經網絡的權重矩陣里，不可解釋、不可遷移、不可編輯。你訓練出一個開門的 skill，想把它用到另一個環境里，幾乎不可能。

這個困局持續了 24 年，直到 2023 年 Jim Fan 等人的 Voyager 在 Minecraft 里把 skill 從權重里拉到了代碼里。在那里，GPT-4 驅動的 agent 在游戲中自主探索，每學會一個新能力就把它寫成一段 JavaScript 函數，存進一個 skill library。下次遇到類似情況，先在 library 里檢索，找到了就直接調用，找不到再造新的。

結果Voyager 獲得的獨特物品數量是前代最強方法的 3.3 倍，解鎖科技樹的速度快了 15.3 倍。skill 用代碼寫，意味著它天然可解釋、可編輯、可組合、可遷移。

Voyager 架構圖：自動課程、迭代提示機制與 Skill Library（Wang et al., 2023）

Voyager 真正的貢獻不在數字。它證明了，當 skill 的表示形式從內部參數變成可讀代碼，整個游戲規則都變了。參數形態的 skill 是黑箱，看不到、改不了、沒法分享給別的 agent。代碼形態全都可以。這才是 26 年里真正的拐點。

Agent 不是變聰明了才學會 skill，而是 skill 變得可讀了，才能被積累、檢驗、傳播。

不過 Voyager 其實有個根本局限，它只活在 Minecraft 里。游戲規則封閉、狀態可觀測、驗證即時。真實世界不是這樣。一個處理財務數據的 agent 沒法即時驗證 skill 有沒有在特殊情況下出錯。

從 Minecraft 走進真實世界，驗證、質量保證、跨環境遷移，一整套問題等著解決。

2025 年下半年到 2026 年初，Anthropic 定義了標準，產業有了需求，學術界有了著力點，事情開始密集變化。不是一篇論文，是一整批。從 skill 的自主發現、封裝組合到持續改進，幾乎每個環節都有了系統性方案。

skill 有了流通的基礎設施之后，「skill 怎么來」從學術興趣變成了產業瓶頸。

這波研究按 skill 的生命周期展開，包括三個部分，skill怎么被發現、怎么封裝組合、怎么持續被改進。

02 三條路都走通了，探索、失敗、學習

最根本的問題先來。agent 能不能在沒人手把手教的情況下，自己發現有用的 skill？

2025 年 6 月，KAIST 的 Yongjin Yang 等人發了 EXIF（Exploratory and Iterative Feedback），提出了一個很有意思的雙 agent 架構。兩個 agent，一個叫 Alice，一個叫 Bob，分工明確。Alice 是探索者，被放進一個環境里自由探索，嘗試各種操作，記錄下什么行得通、什么行不通。然后 Alice 回頭看自己的探索軌跡，從中提煉出這算一個 skill 的定義。

接著這些 skill 被交給 Bob，Bob 拿著這些 skill 去執行具體任務。Bob 的表現被反饋回來，哪些 skill 好用，哪些不好用，Bob 在哪些地方卡住了，這些信息反過來引導 Alice 下一輪探索的方向。

這個循環持續迭代。Alice 探索 → 定義 skill → Bob 執行 → 評估短板 → 引導下一輪探索。重點在于整個過程不需要人類提供任何任務描述或 skill 定義，Alice 和 Bob 自己完成了從什么都不會到積累出一套可用 skill的全過程。

EXIF 架構圖：Alice 探索環境生成 Skill，Bob 執行任務并反饋

EXIF 最有意思的發現來自拆解測試。研究者試了讓同一個模型同時扮演 Alice 和 Bob，直覺上，自己教自己應該效果很差。但結果是，單模型自進化居然也有效。skill discovery 不一定需要兩個模型互補，一個模型的「探索」和「利用」能自己博弈出有效的 skill。

如果說 EXIF 是靠「探索」來發現 skill，Sentient 的 Salaheddin Alzubi 等人在 2026 年 3 月發表的 EvoSkill 則走了一條完全不同的路，靠「失敗」。

EvoSkill 不讓 agent 去自由探索環境。它讓 agent 直接執行任務，然后分析失敗原因。執行過程中的每一步操作都被記錄下來。當任務失敗時，一個 Proposer agent 審查這些執行記錄，診斷出失敗的具體原因，比如數據提取出了錯、時間粒度搞混了、缺少多源驗證，然后針對性地提出新 skill 或修改現有 skill。

提出的 skill 不是直接采納，而是要過一道淘汰賽。新 skill 必須在驗證集上證明自己比現有的 skill 組合更好，或者在不損害其他維度表現的前提下在某個維度上有進步，才能被保留。這套篩選機制借鑒了多目標優化里的帕累托前沿（Pareto frontier）思路。只保留那些「在任何維度上都不被別人全面壓制」的 skill，其他的淘汰。

EvoSkill 進化循環：從失敗中提出新 Skill，經帕累托篩選后保留

因為發布在Anthropic已經把Skill安全產品化了之后，EvoSkill 的優化純粹發生在 skill 層。不需要微調模型，不需要額外的訓練數據，只需要讓 agent 在任務上不斷失敗、不斷分析、不斷改進 skill。

經過迭代后的skill在 OfficeQA（辦公場景的問答任務）上提升 7.3%，在 SealQA（搜索增強問答）上提升 12.1%。但更值得關注的是跨任務的通用性。從 SealQA 進化出來的 skill，不做任何額外適配，直接拿到 BrowseComp（一個結構迥異的網頁搜索測試集）上用，提升了 5.3%。

進化出來的 skill 在自己的任務上管用，搬到別的任務上也管用。

SkillCraft 還有第三條路，需求驅動。agent 不靠探索也不靠失敗，而是在執行任務時發現「我缺一個處理這類情況的 skill」，直接造。這就像程序員寫代碼寫到一半，發現要用一個不存在的函數，于是停下來先寫函數再回來繼續。

這條路來自 UC Berkeley 和 EPFL 的聯合團隊。2025 年 12 月，Xu Huang、Junwu Chen 等人發表了 CASCADE（Cumulative Agentic Skill Creation through Autonomous Development and Evolution）。

CASCADE 的出發點不一樣�？茖W研究用到的工具，比如材料模擬軟件、化學計算包、機器學習力場等都極度專業。而且其用法文檔分散，版本混亂，連人類科學家都經常要花幾天才能跑通一個新軟件。這使得讓 agent 去「自由探索」或者「從失敗中學」都不夠，因為它首先得弄明白這些工具到底怎么用。

CASCADE 的解法是給 agent 裝上兩個 meta-skill（學技能的技能）。第一個是持續學習，遇到不會用的工具，agent 會自己去搜索文檔、從網頁提取代碼示例、閱讀源碼，搞懂用法。第二個是自我反省，執行報錯后，agent 不是簡單地重試，而是回頭檢查運行時狀態，用知識圖譜回溯依賴關系，甚至直接去讀底層包的源代碼來定位問題根因。

這兩個 meta-skill 不是硬編碼的流程，而是通過精心設計的 prompt 和工具調用接口涌現出來的行為模式。

agent 在解決一個任務的過程中掌握的工具用法和調試經驗，會被固化到記憶系統里，從短期的 session memory，到跨會話的 consolidated memory，最終沉淀為可復用的 skill set。下次遇到類似的工具或問題，直接調用已有經驗。

在 SciSkillBench（116 個材料科學和化學研究任務）上，GPT-5 裸跑成功率 35.4%，加上 CASCADE 的進化機制后被曝光達到 93.3%。更值得注意的是，CASCADE 成功復現了已發表論文中的計算實驗，還能驅動真實實驗室的自動化合成流程。

這得操控一個它從未見過、沒有文檔、不在訓練數據中的內部軟件包。

CASCADE 架構圖：LLM + Skill Acquisition 范式與 DeepSolver 多 Agent 架構

上面提到的三條路徑其實對應了人類學習技能的三種方式，好奇心驅動（我去試試看）、失敗驅動（上次栽了所以學會了）、需求驅動（干活時發現缺這個）。

人類三種都用，但大多數人在大多數時候靠的是后兩種。目前的 agent 也一樣，探索這條路在真實環境里效率最低。

但人之所以學東西快，是因為三種模式可以自由切換，該探索時探索，該復盤時復盤，該查資料時查資料。目前沒有任何一個系統同時具備三種。EXIF 不會主動查文檔，EvoSkill 不會好奇地去探索未知領域，CASCADE 不會系統性地從失敗中提煉經驗。當前的 agent 在學習策略上還是偏科的。

至此，「skill 從哪來」這個問題有了答案，但答案還不完整。

03 簡單 skill 沒問題，組合一崩就全崩

一個skill 被發現之后，還得變成可靠的、可復用的模塊。這一步沒做好，前面的發現等于白搭。

上面這些方法發現的 skill，無一例外都是原子級的，單步操作、單個 API 調用、單一場景的處理邏輯。agent 造一個從網頁提取表格數據的 skill，沒問題。造一個調用某個 API 查詢天氣的 skill，也沒問題。哪怕是使用工程模式明確的復雜工具去處理一個問題，都沒問題。但真實世界的任務幾乎不會只需要一個 skill。

給 5 個貓品種各調 5 個 API 收集詳細信息，然后交叉對比生成報告。這需要把「查品種資料」「提取健康數據」「格式化輸出」等多個 skill 嵌套組合起來，循環 5 次，再做一層匯總。這件事，目前的 agent 做起來會崩。

2026 年 2 月，中科院和哈爾濱工業大學發表了 SkillCraft，專門測量 agent skill 組合能力。126 個任務，21 個 API 家族，按兩個維度縮放難度，實體數量（N）和每個實體的 API 調用復雜度（M）。N×M 構成一個二維矩陣，從 Easy（N=1, M=2）到 Hard（N=5, M=5），難度梯度很陡。

SkillCraft 設計了一個三階段 Skill Mode 協議。第一階段探索，給 agent 簡單版任務自己摸索。第二階段組合，把經驗封裝成可復用 skill。第三階段復用，面對大規模同類任務，必須復用之前的 skill。

有 skill 加持到底能做到什么程度？這個差距就是 skill 組合能力的直接度量。

Claude Sonnet 4 在 Easy 上 baseline 已經 95%，開 Skill Mode 還是 95%。成功率沒變，但 token 從 1.96M 降到 0.44M，省了 77%。強模型不需要 skill 幫它「做對」，但 skill 能幫它「做快」。

弱模型就翻車了。Kimi-K2-Thinking 在 Hard 上 baseline 38%，開 Skill Mode 反而掉到 33%。它造的 skill 有三分之一跑不通，一個 bug 在 5 個實體上反復執行，錯誤放大 5 倍。skill 沒幫上忙，反成了累贅。

skill 質量和編碼能力高度相關（r=0.65）。比如 Claude 造的 skill 執行成功率 98%，給誰用都接近 100%。弱模型造的 skill 給自己用會出問題，給別人用更糟。

但真正致命的是嵌套。SkillCraft 對比了 flat（skill 平鋪互不依賴）和 hierarchical（skill 嵌套調用）兩種組織方式。直覺上嵌套應該更強，因為允許更高層抽象。

實測恰好相反。GPT-5.2 在 flat Skill Mode 下成功率 90%，hierarchical 直接掉到 79%。注意，單個 skill 執行成功率是 95%。零件都好使，裝到一起就崩了。

SkillCraft 層級組合案例：成功 vs 失敗的 Skill 嵌套對比（Chen et al., 2026）

論文還總結了嵌套崩潰的三個機制。第一，錯誤累積，成功率隨嵌套層數指數衰減，每層 95%，三層只剩 85.7%，五層剩 77.4%。第二，隱藏缺陷，底層 skill 創建時測試通過，是因為當時的輸入沒觸發特殊情況，被高層調用碰到新輸入才暴露。第三，排查成本，嵌套失敗要逐層追溯依賴鏈，調試成本經常超過直接打平重做。

比如上面踢的貓的案例。底層 skill「查品種檔案」沒做空值檢查，大多數品種的「性格」字段有值所以沒出錯。中層 skill 對這個字段做文本拆分，遇到沒有性格數據的品種就崩了。每一層單獨測都沒問題，但組合起來，一個底層的特殊情況像滾雪球一樣把整條執行鏈炸掉。

因此單個 skill 不是瓶頸，組合才是。

SkillCraft 畫出了這條線。發現原子級 skill 不是瓶頸，組合才是。而組合問題有兩層：弱模型的瓶頸是 skill 質量差（隨模型能力提升會自然緩解），強模型的瓶頸是嵌套組合時邊界條件的指數級放大（這個不是靠模型變強就能解決的，需要架構層面的創新）。

那學術界怎么攻這個問題？

04 從粗糙原型到可組合模塊，封裝和組合有了方法論

回到 SkillCraft 指出的第一個痛點：組合崩潰的根源不是組合本身，而是原子 skill 不夠穩定、接口不夠確定。

2025 年 4 月，Ohio State University 發表的 SkillWeaver，攻的就是這個問題。SkillWeaver 的過程分三步。

第一步和第二步，是結合了探索和試錯的skill發現流程。

第三步是關鍵，把這些經驗蒸餾成標準化的 API。不是文字描述（先點這個按鈕再填那個表單），而是一段封裝好的、有明確輸入輸出接口的可執行代碼。

蒸餾這一步的設計思路值得多說幾句。一般的 skill 存儲方式是自然語言描述加上示例，「當遇到 X 情況時，做 Y 操作」。這種方式的問題在于，自然語言是模糊的，不同的 agent 對同一段描述可能理解不同，執行路徑也不同。SkillWeaver 把 skill 蒸餾成代碼級的 API，接口明確、行為確定，不管誰調用結果都一樣。這就是為什么它的 skill 可以跨 agent 遷移。

數據上，SkillWeaver的skill 在 WebArena（標準化的 web agent 測試集）上提升 31.8%，在真實網站上提升 39.8%。

但最有說服力的數字是跨 agent 遷移實驗。用一個強 agent（GPT-4 級別）造出來的 API，直接給一個弱 agent（GPT-3.5 級別）用，弱 agent 在 WebArena 上的表現提升了 54.3%。skill 造出來之后，不是只有造它的那個 agent 能用，能力可以下傳。一個高手總結出來的操作手冊，新手拿著也能用。

SkillWeaver 三階段框架：Skill Proposal

→ Skill Synthesis

→ Skill Honing（Zheng et al., 2025）

AgentFactory 走了同一條路，但更極端。2026 年 3 月，北京大學的 Zhang Zhang 等人把封裝粒度從「一段 API 代碼」推到了「一個完整的 Python subagent」。

AgentFactory 的做法和前面所有方法有一個根本性的不同。之前的方法，EXIF、EvoSkill、CASCADE，造出來的 skill 都是文本描述或代碼片段。AgentFactory 造出來的不是 skill 片段，而是一個完整的 Python subagent。

當 agent 成功解決了一個任務，AgentFactory 不是把成功經驗存成一段反思文字（像此前的 Reflexion 系統那樣，讓 agent 用自然語言寫下「下次該怎么做」），而是把整個解決方案封裝成一個可獨立執行的 Python 程序，有明確的輸入輸出接口，有異常處理，有日志記錄。

AgentFactory 的 subagent 庫會越長越大。早期，agent 遇到新任務需要從頭解決，成本高。但隨著庫的積累，越來越多的新任務可以通過調用或組合已有的 subagent 來完成，后期的平均解決成本持續下降。

這是一個正反饋循環，用得越多，積累越多，成本越低。

SkillWeaver 和 AgentFactory 解決的是同一個問題，讓原子 skill 從模糊的文字描述變成確定性的可執行代碼，消除每次調用結果不一樣的不穩定性。

零件可靠了，就該處理組合了。

目前看，組合能力這件事情，屬于模型的一種基本能力，處理的方法，只有通過訓練。

University of Wisconsin-Madison 和 Amazon Science 的 Jiongxiao Wang 等人在 2025 年 12 月發表的 SAGE（Skill Augmented GRPO for self-Evolution），把 skill 直接嵌入強化學習的訓練循環。它解決的是另一個層面的問題，agent 怎么被激勵去主動積累和復用 skill。

SAGE 的核心設計有兩個。第一個是「邊干邊攢」（Sequential Rollout）。agent 在執行一個長任務時，每完成一個階段就檢查自己的操作序列，看有沒有值得抽取為 skill 的重復模式。抽取出來的 skill 被加入 library，后續階段如果遇到類似情況就直接調用，不再從頭執行。任務鏈越長，積累的 skill 越多，后面的階段就越高效。

第二個是「獎勵造技能」（Skill-integrated Reward），在強化學習的獎勵函數里顯式加入兩個信號，造新 skill 有獎勵，復用已有 skill 也有獎勵。這等于是在訓練目標層面告訴 agent，學會積累和復用能力這件事本身就是值得做的，跟任務完成率一樣重要。

效果在 AppWorld（一個模擬真實 app 環境的標準測試集）上驗證了。目標完成率提升 8.9%，這個數字本身不算驚艷，但兩個效率指標更耐看，交互步驟減少 26%，token 消耗減少 59%。skill 積累帶來的效果在效率上更明顯。做同樣的任務花的力氣少了很多。

SAGE 架構圖：Skill Library Agent 與 Sequential Rollout + Skill-integrated Reward

2026 年 2 月，University of North Carolina at Chapel Hill 的 Peng Xia 等人發表了 SkillRL，把 skill 的錘煉推到了一個新的層次，即遞歸進化。

SkillRL 建了一個叫 SkillBank 的分層 skill library。和之前的 skill library 不同，SkillBank 里的 skill 不是平鋪的，而是分層級的，低層 skill 可以被組合成高層 skill，高層 skill 又可以被進一步組合。

這個層級結構不是人類設計的，而是在 RL 訓練過程中自動涌現的。agent 在解決越來越難的任務時，自然地把之前學會的小 skill 拼成更復雜的大 skill。

SkillRL 的另一個關鍵設計是自適應檢索。agent 不是在每個任務開始前就決定調用哪些 skill，而是在執行過程中根據實時狀態動態決定。這更接近人類使用技能的方式。你不會在做一道菜之前先列出所有要用到的技巧，而是切到一半發現肉太硬了，才想起來"對了，我會一個叫腌漬的技巧"。

在 ALFWorld、WebShop 和 7 個搜索增強任務上，SkillRL 超過最強 baseline 14%。復用率數據也印證了這一點。隨著訓練推進，agent 調用已有 skill 的頻率穩步上升，新造 skill 的頻率逐漸下降，說明 SkillBank 確實在積累可復用的能力，而不是每次都白手起家。

SkillRL 框架：從軌跡蒸餾到分層 SkillBank，再到遞歸進化

SAGE 在訓練層面解決積累激勵，讓 agent 知道攢 skill和完成任務一樣重要。SkillRL 把組合推到了遞歸層級，底層 skill 自動涌現成高層 skill，層級結構不是人設計的，是 RL 訓練出來的。

從粗糙原型到可靠模塊，再到分層組合，skill 工程化這條路的骨架搭起來了。

05 造出來只是開始，Skill 怎么越用越好

發現、封裝、組合的問題都有人在解了。但還有一個問題被懸著，skill 造出來之后怎么辦？一個今天好用的 skill，一個月后可能因為環境變了、API 改了、需求變了而完全失效。

更常見的情況是，skill 不是突然失效，而是慢慢變差。最初跑出 90% 成功率的 skill，因為環境變化，用了兩周后掉到 70%，但沒人注意到，因為沒有持續監控的機制。

其實前面講 skill 發現時提到的 EvoSkill，已經包含了進化的種子。它不只是發現新 skill，更是一個「執行→失敗→診斷→改進」的持續循環，每一輪失敗都在定向修復已有的 skill。

但 EvoSkill 的進化是綁定在發現skill的過程里的，skill 造出來之后獨立運轉時怎么持續變好，需要專門的機制。

學術界在 2025-2026 年密集發表了三篇代表性工作，AutoRefine、ACE、EvolveR。它們的切入點不同，但回答的問題可以收斂成三個。

第一問，經驗從哪來？

agent 在執行任務時會留下大量軌跡，但軌跡不等于經驗。從原始操作記錄中提煉出可復用的策略，是進化的起點。

三個方案走了三條不同的提取路徑。

AutoRefine（2026 年 1 月）用批量對比提取。它不是每做完一個任務就提一條經驗，而是每 10 個任務攢一批，把成功軌跡和失敗軌跡放在一起做對比分析（contrastive analysis）。一個專門的 extraction agent 看一批成功記錄和一批失敗記錄，通過反事實推理（counterfactual reasoning）找出「成功時做了什么、失敗時差了什么」，然后抽象成可復用的模式。

批量是因為單個任務的成功可能是偶然的，只有跨任務反復出現的策略才值得提取。

AutoRefine 論文 Figure 1 三階段框架總覽。左側 Task Execution 展示雙形態經驗（Skill Pattern + SubAgent Pattern），中間 Pattern Extraction 是對比分析流水線，右側 Pattern Maintenance 是三維評分+合并/修剪

ACE（2025 年 10 月，Stanford 和 SambaNova）則選擇了用實時評估的方法。ACE 的 Generator（干活的 agent 本身）在執行任務時不只是產出結果，還會標注自己用了 playbook 里的哪些條目，并給出「有幫助」或「有誤導」的投票。每條經驗的 helpful/harmful 計數器在每次使用后被更新。不需要事后分析，信號在使用過程中就自然產生了。

與此同時，Reflector（反思器）檢查 Generator 的執行軌跡，提取新策略（bullet），對表現差的舊策略提出修正建議。關鍵設計是它可以多輪迭代反思（multi-epoch），同一批任務跑多遍，每一遍 playbook 都在變好。

EvolveR（上海人工智能實驗室）用的是離線自蒸餾（Offline Self-Distillation）。agent 的策略參數被凍結，它回顧自己之前的執行軌跡，用自己的模型（不依賴外部教師模型）扮演專家角色，從成功軌跡中提取「指導原則」，從失敗軌跡中提取「警示原則」。

每條原則由自然語言描述加結構化知識三元組組成。三種方法的對比很清晰。AutoRefine 靠事后對比，ACE 靠實時評估，EvolveR 靠自我蒸餾。

提取的時機不同（批量 vs 實時 vs 離線），但目標一致，都是從原始軌跡里提煉出可復用的策略。

ACE 論文 Figure 4 三角色架構。Generator 產出軌跡并投票，Reflector 提煉洞察，Curator 以 Delta 方式增量更新 Playbook

第二問，經驗庫怎么管？

提取只是第一步。經驗庫會不斷膨脹。好的經驗需要保留，壞的需要淘汰，冗余的需要合并。如果不做管理，經驗庫最終會變成一個塞滿過時策略的垃圾堆，反而拖累 agent 的表現。

AutoRefine 設計了三維評分追蹤每條經驗的健康狀況。被檢索次數（有多少次被翻牌）、被實際采用次數（翻牌后真的用了多少次）、成功次數（用了之后成功了多少次），三項相乘得出綜合評分。其中「采納精度」這一項很妙。

如果一條經驗總是被檢索但從不被采納，說明它的描述寫得像是相關，但實際上沒用，這種虛假相關的經驗需要淘汰。維護頻率不是固定的，而是指數遞增間隔（10、20、40、80 次任務后各做一次清理）。因為早期經驗庫不穩定需要頻繁修剪，后期穩定了就減少干預。embedding 相似度超過 0.85 的同類經驗，由一個專門的 merge agent 判斷是否值得合并，檢查它們是否解決同一個子任務、流程步驟是否兼容、適用場景是否重疊，確認后合并成一條更精煉的版本。

ACE 的管理者叫 Curator（策展器）。它做了三件事。

• 增量合并，新 bullet 不替換舊的，而是以 delta 的方式追加，舊知識不會丟。

• 語義去重，用 embedding 相似度檢測冗余 bullet，合并同義項。

• 投票淘汰，被標記為 harmful 次數多的 bullet 被修剪掉。

還有一個關鍵設計叫 Grow-and-Refine。先讓 playbook 自由增長（grow），積累夠多之后做一輪整理（refine），去重、修剪、合并。整理可以是「每次追加后立刻做」（proactive），也可以是「等 context window 快滿了再做」（lazy）。兩種模式的選擇取決于任務密度和上下文預算。

EvolveR 的管理邏輯更嚴格。新蒸餾出來的原則不是直接塞進庫里。先做同批次去重。同一道題生成的多個原則，如果語義等價，只保留一個代表。再做兩階段匹配，先用 embedding 相似度檢索庫中最相似的已有原則，再用 LLM 做語義等價判斷。

如果是全新的洞察，加入庫中；如果是已有原則的新證據，把新軌跡合并到已有條目下，增強它的支撐力度。

每條原則有一個動態評分 s(p) = (成功次數+1) / (使用次數+2)，分數低于閾值的原則被定期修剪。

三個方案在管理上的差異，反映了對「什么是好經驗」這個問題的不同理解。

AutoRefine 用多維量化（被翻牌、被采納、被驗證三重篩選），ACE 讓 agent 自己投票（用的人最有發言權），EvolveR 用貝葉斯式的動態評分（每條原則的分數隨使用結果持續更新）。

但它們有一個共同的直覺，進化的過程本身就包含管理，淘汰劣質經驗、合并冗余經驗、持續校準評分，這些不是進化之外的維護工作，而是進化機制的一部分。

第三問，經驗怎么起效？

這是最關鍵的分歧。經驗提取出來了，庫也管好了，它到底以什么方式影響 agent 的行為？改 prompt？改 context？還是改模型本身？

AutoRefine 做了一件其他方案都沒做的事。它提取出來的經驗不只是文字規則，還包括活的子 agent。

AutoRefine 定義了兩種經驗形態。第一種叫 Skill Pattern，簡單策略，以自然語言指南或可執行代碼片段的形式存在，比如「發票文件應該歸到 financial而不是 personal」。

第二種叫 Subagent Pattern，復雜的多步驟流程，直接封裝成一個獨立的子 agent，有自己的推理能力和記憶。

比如「交通規劃」這個子任務太復雜了，一條文本規則寫不清楚，于是 AutoRefine 把整個解決方案蒸餾成一個專門的子 agent，主 agent 遇到相關子任務時直接把活委托給它。別人提取經驗都是文本，AutoRefine 提取的經驗可以是一個活的 agent。

ACE 的經驗以 playbook 的形式注入 agent 的 context。Generator 在執行時參考 playbook 中的條目，playbook 在使用中不斷被投票篩選和更新。ACE 的進化邏輯和 AutoRefine 方向相反。AutoRefine 是從軌跡中蒸餾新經驗，ACE 是在使用中篩選舊經驗。

一個靠提取，一個靠投票。

但兩者有一個共同的天花板，它們都不改模型本身。經驗庫再好，也是外掛的。模型的推理策略沒有因此進化。

EvolveR 跨過了這條線。它的三階段閉環中，前兩步（離線自蒸餾 + 在線交互）和其他方法類似蒸餾經驗，在推理時檢索經驗引導行為。但第三步是 AutoRefine 和 ACE 都沒做的。EvolveR 用 GRPO（Group Relative Policy Optimization）對 agent 的策略參數做強化學習更新。

獎勵函數有兩個分量，結果獎勵（答對了給分）和格式獎勵（推理過程結構完整、有合理的檢索行為也給分）。

關鍵在于，因為 agent 在線階段的行為是被經驗庫引導的，RL 更新學到的不是泛化的推理策略，而是「怎么有效利用自己蒸餾出來的經驗」這個能力。

模型本身在進化，而不只是外掛的經驗庫在進化。這是一個真正的閉環。蒸餾經驗→用經驗引導行為→從行為結果中學習→更好地蒸餾和利用經驗。在 HotpotQA、NaturalQuestions 等七個問答基準上，EvolveR 顯著超過所有 agentic baseline，而且在從未見過的數據集上也能泛化，說明蒸餾出來的策略原則確實有遷移能力。

EvolveR 論文 Figure 2 經驗生命周期完整流程。左側 Online/Offline 雙階段閉環，右側 Experience Base 的檢索與維護邏輯

三種方案構成了一個光譜。AutoRefine 用經驗創造新的能力載體（活的子 agent），ACE 用經驗調節已有行為（playbook），EvolveR 用經驗改變模型本身（RL 策略更新）。越往右走，進化越深，但工程成本也越高。

EvolveR 論文 Figure 1 四種 Agent 學習范式對比。從「無狀態執行」到「自蒸餾+進化」，越往右走 Agent 的自主進化程度越高

這三個方案是學術界的回答。產品界也有人在做，而且做法很不一樣。

2026 年 3 月，Anthropic 悄悄把 Skill Creator 升級到了 2.0。舊版只幫你寫 SKILL.md，新版變成了一個完整的生命周期管理工具，包含四個模式。

Create 負責創建。通過對話生成 skill 文件，這部分沿用舊版。Eval 負責驗證——用子 agent 并行執行，一組帶著 skill 跑，一組不帶，同樣的任務同時跑兩份，然后由 Grader（評分器）做斷言評分，Comparator（比較器）做盲 A/B 對比，Analyzer（分析器）做統計分析。這樣不是人拍腦袋說「感覺變好了」，而是有量化數據。

Improve 負責迭代。基于 Eval 的數據改進 skill。核心機制是 Description Optimization，把評估集分為 60% 訓練集和 40% 測試集（防止過擬合），最多跑 5 輪迭代，選出最佳版本。用戶還可以在瀏覽器查看器里逐個審查測試用例的輸出，留下定性反饋。

Benchmark 負責度量。定量比較通過率、Token 消耗和執行時間，支持新舊版本快照對比。

四個模式構成了一個閉環。Create→Eval→Improve→Benchmark，然后基于 Benchmark 的結果決定是否再來一輪 Improve。

Skill Creator 2.0 的哲學和學術界的方案有一個本質區別。學術界的進化是自動的，agent 自己提取經驗、自己評估、自己淘汰，人類不介入。

Skill Creator 2.0 的進化是人機協作的。自動化測試提供數據，但最終的判斷和反饋由人來做。它不追求完全自主進化，而是讓人類開發者能高效地參與進化循環。這可能是更務實的路徑。

OpenClaw 的 Self-Improving 模塊走了另一條路，打通了從運行時經驗到 skill 標準文件的自動轉化。

agent 在執行任務時積累的臨時經驗，通過分層記憶系統逐步固化，先是短期記憶（本次會話內的操作記錄），然后是長期記憶（跨會話的模式總結），最終沉淀為 SKILL.md 文件。AutoSkill 組件負責最后一步，把成熟的經驗自動寫成符合 Anthropic 標準的 skill 文件，包括元數據頭（frontmatter）、觸發條件、執行步驟，甚至版本號。

每次更新不是覆蓋式重寫，而是語義級增量修改，只改變需要改的部分，其余保持不變。

Anthropic Skill Creator 2.0 則代表了產品界的務實選擇，不追求完全自主進化，而是用 Eval→Improve→Benchmark 的自動化流水線讓人類開發者高效地參與進化循環。

skill 生命周期上，「持續變好」這一環開始閉合了。

06 26年的進化，走到了臨界點

回到開頭的矛盾。Anthropic 定義了 skill 怎么流通，這波研究正在解決 skill 怎么來、怎么變好、怎么維護。生命周期上的每一環，發現、封裝組合、流通、持續改進，都有了技術原型。

一年前，「agent 能不能自己學新技能」還是一個學術興趣。今天它是一個工程問題。從學術興趣變成工程問題，意味著基礎的可行性已經不需要被證明了，剩下的是怎么做得更穩、更安全、更可擴展。

Sutton 在 1999 年問了這個問題，Voyager 在 2023 年用 Minecraft 里的 JavaScript 函數給了第一個可信的回答，Anthropic 在 2025 年底讓 skill 有了產品級的標準和流通基礎設施。

2026 年初這波研究，第一次讓「agent 自己造 skill」在真實任務上跑出了可觀的數據。

二十六年，從一個理論框架到一個產品級問題。

說到底，這不是一個純粹關于 AI 的問題。它關乎知識如何積累和傳承。人類文明的核心競爭力就是每一代人不需要從零開始，上一代人造了輪子，下一代人直接用，把精力花在造汽車上。

如果 agent 真的學會了這一點，不只是在單次對話中完成任務，而是能把經驗沉淀成可復用、可傳承、可進化的能力模塊，那它就不再只是一個工具。它會成為一種能自我積累知識的基礎設施。

我們還沒走到那一步。

但方向已經確認了，路上已經有了腳印。

來源 | 騰訊科技（ID：qqtech）

作者 | 博陽 ; 編輯 | 呼呼大睡

內容僅代表作者獨立觀點，不代表早讀課立場