目錄
今日總覽
Agent 技能（skill）正在從「一次寫完就不動」演變成「會自我進化的活文件」，但進化本身帶來三個未解的問題：進化的回饋訊號會衰減、不知道一個技能裡哪些步驟真正重要、以及記憶與技能缺少共同的進化基礎設施。今天三篇各解決其中一個：SkillEvo 證明多輪互動回饋可以讓進化梯度持續供應、不會在第一輪修補後就歸零；SkillShapley 用 Shapley 值量化每個步驟的邊際貢獻，讓技能編輯從盲目裁剪變成有依據的決策；MindMemOS 則把記憶與技能放在同一個可攜帶的作業系統層裡，讓兩者共同進化。三篇合起來勾勒出一幅圖景：Agent 技能的未來不是「更好的初始版本」，而是「持續進化的系統」。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agent Skill（技能） | 一份自然語言的步驟指引，插進 Agent 的 harness 裡讓它知道怎麼執行特定任務——不改模型權重，只改行為 |
| 進化梯度（Evolution Gradient） | 告訴技能「該往哪個方向修改」的回饋訊號；如果回饋只能發現表面問題，修完一輪就沒有新訊號了 |
| Shapley 值 | 賽局論裡衡量每位玩家邊際貢獻的方法——放到技能裡，就是量化每個步驟對最終成功率的貢獻度 |
| 聯盟（Coalition） | Shapley 計算裡的子集組合——在技能情境裡就是「只保留某些步驟」的技能變體 |
| 記憶作業系統層（Memory OS） | 把 Agent 的長期記憶管理抽象成一個獨立層級，處理儲存、檢索、合併、衝突解決，像作業系統管檔案一樣管記憶 |
論文一｜SkillEvo：用多輪互動回饋讓技能進化不停滯
SkillEvo: Self-Renewing Evolution Gradients from Multi-Turn Interaction Feedback
Qianxi Yan, Chunrong Chen, Jiuzhou Zhao et al.（Tencent Cloud Andon / Zhejiang University） · arxiv: 2608.13120
TL;DR
把多輪使用者模擬從「評估終點」改成「回饋生成器」，讓每一輪修訂既消耗回饋又產生新回饋，搭配獨立治理層防止結構劣化，在 9 個生產技能上比自我反思進化高 23 分、比單輪 QA 驅動進化高 15.4 分。
Read Priority
必讀 — 如果你在做技能自動化或 Agent 持續改善，這篇直接回答了「為什麼我的技能進化跑兩輪就停了」這個問題。
領域背景
現有的技能進化方法（如自我反思、單輪 QA 評估）都面臨同一個問題：回饋訊號會衰減。第一輪修補完表面缺陷後，單輪評估已經看不出更深層的問題——那些只在多輪對話中才會浮現的缺陷就永遠修不到。加上治理機制只有一個標量分數當閘門，能擋掉明顯退化但無法定位或修復結構性原因。
中階導讀
- 問題：想像你寫了一份客服 SOP，單獨測試每個問答都沒問題，但一旦客戶追問三輪就露餡——語氣矛盾、資訊重複、遺漏上下文。問題出在你的測試方式只有單輪，所以改善也只能改到單輪能暴露的問題。
- 方法：SkillEvo 有兩個核心組件。第一個把多輪使用者模擬重新定位為「回饋生成器」——追問會一層一層暴露缺陷，每一輪修訂消耗舊回饋同時產生新回饋，形成自我更新的進化梯度。第二個是獨立的治理層，不是被動地用分數擋掉退化版本，而是主動修復事實退化和結構膨脹。
- 為什麼重要：對 Agent 平台而言，技能不是寫完就不動的靜態文件。SkillEvo 證明「回饋的品質決定進化的天花板」——用多輪互動取代單輪 QA，天花板就顯著拉高。
深入要點
- 在 6 類雲端服務、9 個生產技能、98 份技能參考檔上測試
- 比自我反思基線高 23.0 分，比單輪 QA 進化高 15.4 分 ⚠️（Tencent 自測，需等外部複現）
- 進化梯度的核心洞察：單輪回饋的資訊量在第一輪後急遽衰減，多輪追問則持續供應新訊號
- 治理層主動修復兩類問題：事實退化（進化過程中引入錯誤資訊）和結構膨脹（技能越改越長越冗餘）
- 落地門檻：需要建立多輪使用者模擬的管道，小型團隊可以從現有的對話日誌中挖掘追問模式
- Limitation：目前只在雲端服務場景測試，對 coding 或開放式推理任務的效果待驗證
Reviewer 一句話評
問題定義精準——「進化梯度衰減」是一個真實且普遍的瓶頸，多輪回饋的解法直覺且有效。但 9 個技能的測試規模偏小，且所有技能都是 Tencent Cloud 內部場景，泛化性需要更多證據。
給你的 take-away
- 如果你在維護 Agent 技能庫：把現有的單輪評估管道升級為多輪追問模式，用「使用者可能會怎麼追問」作為技能品質的壓力測試
- 如果你在做技能自動進化：把治理從「分數閘門」升級為「主動修復層」，區分事實退化和結構膨脹兩種劣化模式分別處理
論文二｜SkillShapley：用賽局論告訴你技能裡哪些步驟值錢
SkillShapley: Boundary-Adaptive Shapley Valuation for Skill Step Attribution in LLM Agents
Chang Liu, Yuqi Zhang, Yiman Zhong et al.（Beihang University / Shandong University） · arxiv: 2608.13173
TL;DR
把 Agent 技能的每個步驟當成賽局論裡的玩家，用 Shapley 值量化每個步驟對最終任務成功率的邊際貢獻。提出的 BAES 演算法在 99 次技能變體評估內就能逼近精確 Shapley 排序，並發現「決策橋接步驟」比「背景說明步驟」有價值得多。
Read Priority
必讀 — 這篇解決了一個很實際的問題：一個 skill.md 裡面通常有 10 個以上的指令區塊，你不知道哪些是必要的、哪些是可以刪的、哪些刪了會爆炸。SkillShapley 給了一個可量化的答案。
領域背景
技能設計目前仍是反覆試錯。端到端的 benchmark 可以告訴你整體分數，但說不出「這個步驟是拉分的還是拖累的」。Prompt 壓縮方法針對 token 層級，workflow 優化針對執行結構，兩者都不是在步驟語意層級做歸因。
中階導讀
- 問題：你有一份 10 步驟的技能文件，跑 benchmark 拿了 80 分。想精簡到 6 步驟，但不知道該刪哪 4 步——刪錯一步可能掉 30 分，刪對一步可能完全不影響。
- 方法：把技能的每個步驟當成合作賽局裡的一個玩家，「聯盟」就是「只保留某些步驟的技能變體」，效用就是 benchmark 成功率。BAES 演算法分兩階段：暖機階段用快取感知的貪心策略建立廣泛覆蓋，自適應階段集中評估高不確定性的步驟-大小層，用快取的 one-flip 邊際來最大化每次評估的資訊量。
- 為什麼重要：這讓技能編輯從「盲目嘗試」變成「有量化依據的決策」。高價值步驟的模式是「把條件連到可執行決策規則」——這個發現對技能撰寫有直接指導意義。
深入要點
- 在 SkillsBench 的 3 個任務上測試，步驟數分別為 10、9、11
- 精確 Shapley 在低步驟技能上可行（10 步驟 = 1024 個聯盟組合），BAES 在 99 次評估內達到良好近似
- BAES 的快取效率：相同 99 次評估預算，BAES 產生 206 個可重用的 one-flip 邊際邊，MC 取樣只產生 130 個（115 個不重複）
- 關鍵發現：高價值步驟是「決策橋接」（procedural bridge）——把任務條件連到 API 操作、修復決策、驗證指令的步驟。低價值步驟是「資訊孤島」——提供背景事實但不改變 Agent 的下一步決策
- 與 SHAP、Leave-One-Out、LeastCore 比較，Shapley 在 top-ranked removal 驗證中產生最快的效能衰退曲線
- Limitation：強耦合的流水線式技能不適用——移除中間步驟會崩潰整條管線，Shapley 值反映的是結構必要性而非步驟品質
Reviewer 一句話評
把 Shapley 值從特徵歸因搬到技能步驟歸因是一個自然且有效的延伸，BAES 的快取感知設計確實降低了評估成本。但目前只在低步驟數技能上有精確參照，高步驟數技能的近似品質需要更多驗證。
給你的 take-away
- 如果你在寫技能文件：確保每個步驟都是「決策橋接」——把條件連到可執行動作，而不是寫一堆背景說明。背景資訊放在 reference 檔案裡，不要塞進 skill 步驟
- 如果你在管理技能庫品質：用 removal curve 作為技能健康度的指標——如果移除任何一個步驟都不影響成功率，那這個技能可能有大量冗餘
論文三｜MindMemOS：讓記憶與技能在同一個作業系統層裡共同進化
MindMemOS: A Portable and Self-Evolving Memory Operating Layer for AI Agents
Kaichao Liang, Yuqi Cui, Hao Kong et al.（Noah's Ark Lab, Huawei Technologies） · arxiv: 2608.12428
TL;DR
把 Agent 記憶管理做成一個可攜帶、可自我進化的作業系統層——用「實體-屬性-時間」統一結構組織記憶，搭配演化式記憶 schema 優化和「做夢」式記憶整合，LOCOMO 準確率達 94.03%，技能進化讓 SpreadsheetBench 成功率提升 9.2 個百分點。
Read Priority
略讀 — 架構設計全面但偏重系統論文，適合正在建構 Agent 記憶基礎設施的團隊深讀。對純應用開發者，核心 insight 是「記憶和技能應該在同一套進化機制裡」。
領域背景
現有的 Agent 記憶系統在開發完成後大多就固定了——記憶的 schema、組織策略、檢索方式都不會隨使用而改善。這等於讓 Agent 用固定的檔案系統去面對不斷變化的使用場景。先前的工作（如 Mem0、MemGPT）各自解決記憶的某個面向，但缺少一個統一的「記憶作業系統」概念。
中階導讀
- 問題：想像你給 Agent 一個記憶系統，它可以記住使用者偏好和過去的操作經驗。但記憶的分類方式、合併策略、和技能的關聯——全部在部署後就凍結了。三個月後使用場景大變，記憶系統卻還在用舊的 schema 存新的東西。
- 方法：MindMemOS 有三個自我進化機制。MindMemEvolve 用驗證驅動的演化搜尋來優化記憶 schema——針對目標場景自動演化出最適合的記憶模型。「做夢」機制（dreaming）在離線時整合累積的記憶，合併冗餘、解決衝突。MindSkillEvolve 把 Agent 的執行軌跡轉化為可重用且持續精煉的技能。
- 為什麼重要：把記憶和技能放在同一個進化框架裡，而不是各自獨立演化，這讓兩者可以互相增強——好的記憶讓技能執行更精確，好的技能產生更有價值的記憶。
深入要點
- LOCOMO 對話記憶準確率 94.03%，PersonaMem 人設記憶 70.63%
- MindSkillEvolve 在 SpreadsheetBench 上比初始技能基線提升 9.2 個百分點 ⚠️（Huawei 自測，需等外部複現）
- 統一記憶結構：實體（entity）-屬性（property）-時間（time），覆蓋事件、偏好、事實、經驗四類記憶
- 「做夢」機制：離線時掃描所有記憶，找出冗餘記錄合併、發現衝突記錄標記，類似人類睡眠時的記憶整合
- 隱式修正回饋：當使用者糾正 Agent 時，系統自動回溯並修正對應的記憶條目
- 可攜帶性：記憶 OS 層可以搬到不同的 Agent 框架上（LangGraph、CrewAI 等）
- Limitation：「做夢」過程的運算成本和品質控制細節尚未充分討論
Reviewer 一句話評
把記憶管理抬升到「作業系統」的抽象層級是正確的方向，MindMemEvolve 的演化搜尋設計也有新意。但 35 頁的系統論文包含太多組件，每個組件的消融實驗不夠深入，難以判斷哪些設計決策真正不可或缺。
給你的 take-away
- 如果你在建構 Agent 記憶系統：把記憶和技能放在同一個進化框架裡考慮，而不是各自獨立。實體-屬性-時間的統一結構是一個值得參考的起點
- 如果你的 Agent 有長期運行需求：「做夢」機制（離線記憶整合）是一個低成本的品質維護手段——定期合併冗餘、解決衝突，比讓記憶無限膨脹好得多
今日收穫
之前以為技能進化的瓶頸是「模型的編輯能力不夠」或「迭代次數不夠多」，今天 SkillEvo 讓我意識到真正的瓶頸是回饋訊號的品質——單輪回饋在第一輪就耗盡了資訊量，之後的迭代都是在原地打轉。同時 SkillShapley 改變了我對技能步驟的認知：不是「越詳細越好」，而是每個步驟必須是「決策橋接」——把條件連到動作，否則就是在浪費 context。
參考資料
Loading...