ContinualSkillBench：技能演化的照妖鏡 — LLM Agent 真的能演化能力嗎？

一句話核心結論

過去一年 agent 技能研究的共識是「讓 agent 從任務回饋中自主演化技能庫，能力就會成長」。ContinualSkillBench 用五領域、總共 500 個難度遞增的互聯子任務，首次系統性檢驗了這個命題。結果出乎意料：explicit skill maintenance（主動建立技能庫）和 pure in-context learning（只看歷史對話不建技能）的平均表現幾乎持平（0.605 vs 0.602）——大量增益來自適應先前上下文和回饋，而非可重用的技能抽象。更關鍵的發現：弱模型傾向累積更多碎片化技能——GPT-4o 產出 384 個技能（平均品質 5.68），GPT-5.3-Codex 只產出 205 個（平均品質 7.94），但前者技能重用率更低。技能演化不是「有沒有」的問題，而是能不能把經驗壓縮成可重用抽象的問題——目前所有模型都還沒做好這件事。

核心洞察：技能演化增益的來源分解

論文設計了三種實驗條件來拆解 Sequential 增益的來源：

1. Independent（Ind.）：每個任務從頭開始，歷史和技能庫都重置——baseline
2. Sequential（Seq.）：保留完整歷史 + 主動建立/更新技能庫——當前 agent 框架的預設模式
3. In-Context Learning（ICL）：保留歷史對話回饋，但不能建立或修改技能——用於隔離「上下文適應」vs「技能抽象」的貢獻

結果揭示了一個常被忽略的事實：Seq. − Ind. 的增益不能直接歸因於技能演化。在 Law / Finance / Healthcare 三領域的 ICL 對比中，ICL（0.605）和 Seq.（0.602）的 normalized reward 差距僅 0.003——在統計上不顯著。真實的增益結構是：Seq. 改善了 Exact Match 和 Programmatic 任務（精確輸出），但 ICL 在 Rubric judge 任務上更強（開放式回答）。這意味著顯式技能對嚴格格式和確定性程序有幫助，但會過度適應早期評估標準而削弱開放式任務的靈活性。

技能庫動態：為什麼「技能多」不等於「能力強」

論文追蹤了 GPT-4o 和 GPT-5.3-Codex 的技能庫演化行為：

• 總量對比：GPT-4o 累積 384 個技能、GPT-5.3-Codex 只 205 個。但 Codex 在 14/15 組合中達到更高的絕對效能
• 重用率：GPT-4o 的技能在後續任務中被調用的頻率明顯低於 Codex——弱模型傾向為每個任務「單獨寫一個技能」，而非把相似經驗合併成通用程序
• 品質評分：Codex 技能平均 7.94 vs GPT-4o 5.68。最差的領域是 Law（GPT-4o 5.25）、最好的仍然是 Codex 的 Office（8.27）
• 碎片化陷阱：技能庫愈大、檢索和維護成本愈高，但弱模型的技能庫正好最大最碎片。這形成了一個負向循環：能力弱→無法抽象→產出碎片化技能→技能庫膨脹→檢索效率下降→能力更弱

這個發現直接挑戰了 SESA 等技能演化方法的假設——技能記憶不是自動變好的，蒸餾品質比蒸餾數量重要得多。

五領域實驗全景

• Healthcare 最大增益（+0.149）：GPT-5.3-Codex 和 Opus 4.7 都有大幅改善。醫療領域的程序性知識（診斷流程、術語映射）確實可透過序列執行累積
• Finance 次之（+0.076）：Numeric 任務改善最顯著（Codex +0.416）。財務計算的標準化程序容易被技能化
• Math 幾乎無增益（+0.052）：Opus 4.7 甚至退化（-0.008）。數學推理能力幾乎完全由模型參數決定，上下文和技能都幫不上忙
• Opus 4.7 的 paradox：獨立 baseline 最強（平均 0.572），但序列增益最小（+0.058）。能力強的模型從序列執行中獲益反而更少——因為它本來就做對了大部分任務，沒有太多「從失敗中學習」的空間
• GPT-4o 的相反模式：獨立 baseline 最弱（平均 0.252），但相對增益最大（+0.077 相當於 30.6% 提升）。弱模型從序列執行中受益更多，但受益方式主要是適應回饋格式而非技能遷移

RAG baseline 的啟發

論文還測試了 retrieval-augmented generation（RAG）baseline：不維護技能庫，而是索引並檢索先前的 trajectory 片段。結果與 ICL 相似——Rubric 提升、EM 不如 Seq.。這進一步印證：上下文適應（context adaptation）才是增益的主要引擎，技能抽象是輔助。對 Hermes 而言：conversation history 本身就是最強大的「技能庫」，強迫 agent 把經驗壓縮成結構化技能可能不是最優策略——至少對目前世代的模型而言。

對 Hermes / DKY 的啟發

• Skill 不一定優於 Context：這是最顛覆的發現。Hermes 的技能系統（skills/ + profile）假設結構化技能優於原始對話歷史。ContinualSkillBench 的數據顯示：在當前模型能力下，兩者效果幾乎相同。這意味著與其花力氣設計完美的技能蒸餾管線，不如確保對話歷史被有效保留和檢索
• 技能碎片化是沉默殺手：GPT-4o 的 384 個技能中大量是「一次性」的——僅在特定任務有用、從未被重用。Hermes 的 fact_store 和 consolidation 面臨同樣風險：每次固化都在增加儲存、但未必增加能力。需要引入重用率追蹤 + 定期淘汰機制
• 精確輸出 vs 開放式回答的 trade-off：Explicit skill 改善 EM 但傷害 Rubric——技能會讓 agent「過度格式化」回答。Hermes 的 skill 設計應區分兩類：嚴格式 skill（精確輸出場景）和 指導式 skill（開放場景），分別啟用
• 弱模型更需技能管理：ContinualSkillBench 顯示弱模型的技能庫問題最嚴重。Hermes 的子 agent（使用免費 LLM 池）正好是弱模型——它們需要更嚴格而非更寬鬆的技能庫管理。簡單規則（如「只保留被重用 ≥2 次的技能」）可能比複雜的蒸餾管線更有效
• 領域差異的啟發：Healthcare 增益大（程序性知識可遷移）、Math 無增益（參數知識無法遷移）。這對 Hermes 的 task routing 有意義：程序性任務保留歷史、參數性任務從頭開始——不要為了統一而浪費 context window

限制

• 雖覆蓋五領域，任務仍來自固定來源——真實部署的長尾場景（邊緣案例、資料偏移）未被評估
• 僅評估 GPT-4o / GPT-5.3-Codex / Opus 4.7 三模型兩 harness（Codex CLI + Claude Code），未涵蓋 Gemini、Cursor 等
• 序列僅 100 任務——長期（1000+ 任務）的技能庫動態未知：碎片化是否會持續惡化？最優技能庫大小是否存在上限？
• ICL 對比僅在三領域進行（API 成本限制），未覆蓋全部五領域
• 技能品質評分由單一 LLM（GPT-4.1-mini）判定，無人類評估對照
• 未測試跨領域技能遷移——真實 agent 工作中領域邊界是模糊的