SkillOpt 把技能當權重訓練

SkillOpt 把 agent 技能當成可編輯文字，透過驗證門檻做受控更新，讓技能能像模型權重一樣被優化。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：GPT-5.5 直聊 +23.5 分
• 突破點：驗證門檻式文字優化

SkillOpt: Executive Strategy for Self-Evolving Agent Skills 想處理的是一個很實際的問題：agent 的技能，能不能不要再靠零散的 prompt 微調，而是用更像訓練模型的方式來改進？這篇論文的核心主張很直接。技能不該只是靜態設定，而應該是可被優化、可回溯、也可控的文字資產。

這個方向對開發者很有感。因為很多 agent 系統真正卡住的，不是底層模型不夠強，而是技能寫法不穩、改一次壞一次、很難重現。SkillOpt 就是想把這種「靠感覺修 prompt」的流程，變成一個有規則的優化迴圈。

這篇論文在解什麼痛點

作者批評現有 agent 技能的更新方式，常見問題是太隨意。可能是人工寫、一次生成、或在自我迴圈裡反覆改寫，但這些方法都不像真正的 optimizer。它們很難控制，也很難重現。更重要的是，當有回饋訊號時，這些方法不一定真的能穩定變好。

這個痛點在實務上很常見。當 agent 要用工具、跑工作流、遵守步驟時，技能文本常常就是決定成敗的地方。若技能更新是噪音很大的試錯，團隊最後就會回到手工修 prompt，變成一種脆弱的工程習慣。

SkillOpt 的思路是把技能文本當成外部狀態。底層 agent 保持 frozen，不直接改模型本體；真正被優化的是那份 skill document。這個設計很像把「權重空間的訓練」概念搬到文字空間裡，只是操作對象不是參數，而是可讀的技能描述。

SkillOpt 怎麼運作

論文把 SkillOpt 定義成一個 controllable text-space optimizer。做法不是讓模型隨便重寫整份技能，而是由另一個 optimizer model 讀取 scored rollouts，然後對單一 skill document 提出有限制的修改。

這些修改只允許三種操作：add、delete、replace。這點很重要。因為它把搜尋空間鎖住了，不讓系統把整份技能無限制地洗掉重來。對工程師來說，這比較像受控編輯，而不是自由發散式重寫。

真正的保護機制是 validation gating。只有當某個修改能夠「嚴格提升」一個 held-out validation score，這次編輯才會被接受。也就是說，系統不只是相信 optimizer 的判斷，而是要求看得見的驗證分數改善，才讓技能版本往前走。

論文還提到三個穩定化機制：textual learning-rate budget、rejected-edit buffer、epoch-wise slow/meta update。摘要沒有把實作細節講滿，但名字已經透露出設計意圖：限制每次能改多少、記住被拒絕的編輯、而且更新節奏要更保守。

這種設計很像把 prompt 優化拉近正式訓練流程。不是靠即興修改，而是有步幅、有回饋、有拒絕機制。對想把 agent 放進 production 的團隊來說，這種可控性通常比「看起來很聰明」更重要。

論文實際證明了什麼

作者用六個 benchmark、七個 target models、以及三種 execution harness 來測 SkillOpt，分別是 direct chat、Codex 和 Claude Code。這個測試矩陣算是相當廣，因為 agent 的表現通常會隨執行環境大幅變動，不同 runtime 可能會把同一份技能放大或削弱。

摘要給出的結論很強：SkillOpt 在 52 個 model-benchmark-harness cell 裡，都是最佳或並列最佳。它也優於每個 cell 的其他 skill 競品，包含 human、one-shot LLM、Trace2Skill、TextGrad、GEPA 和 EvoSkill。這些都是摘要中的比較宣稱，但目前公開文字沒有提供完整逐項 benchmark 表格，所以還看不到每個測項的細節。

最明確的數字來自 GPT-5.5。SkillOpt 在 direct chat 模式下，把 no-skill accuracy 平均提升 +23.5 分；在 Codex agentic loop 裡提升 +24.8 分；在 Claude Code 裡提升 +19.1 分。摘要沒有公開原始 baseline 百分比，所以這些應該解讀為相對增幅，而不是絕對分數。

論文也提到 transfer 效果。優化後的 skill artifact 可以跨 model scale 保留價值，也能在 Codex 與 Claude Code 的執行環境之間轉移，甚至能直接搬到一個相近的數學 benchmark，而不需要再重新優化。這代表它學到的不只是某一個環境的局部技巧，至少在作者的測試裡，具備一定可遷移性。

對開發者來說，這代表什麼

如果你在做 agent，這篇論文最實際的啟發是：技能可能不是一次寫完就結束的設定，而是可以被版本化、被訓練、也能被轉移的資產。SkillOpt 的核心承諾，是把技能改進變成一個更系統化的流程，而且部署時不需要額外增加 inference-time 的模型呼叫。

這點很關鍵。很多 agent 改善方案都會把複雜度塞到每一次請求裡，導致線上成本和延遲一起上升。SkillOpt 的做法是把成本搬到離線優化階段。換句話說，模型在上線時保持 frozen，真正變動的是技能文本本身。

這種架構對維運也比較友善。技能可以像程式碼或設定檔一樣管理，適合做版本控制、回滾、比較不同版本的效果。若團隊要追查 agent 為什麼突然失常，這種明確的 skill artifact 也比一團隨機對話記錄好 debug 得多。

但限制也要看清楚。摘要沒有交代 benchmark 名稱、驗證切分方式、技能文件大小、或 optimizer 可能失敗的場景。也沒有說明這個方法對 held-out validation set 有多敏感，或人工介入要到什麼程度。這些都會影響它能不能從研究原型走到穩定流程。

另外，任何 text-space optimizer 都有一個共同風險：技能好不好，最後還是取決於搜尋過程夠不夠好。如果 optimizer model 太弱，或回饋訊號本身就偏掉，系統還是可能往錯的方向累積。驗證門檻能降低亂改的風險，但不能自動消除評估設計的問題。

為什麼這篇值得繼續看

SkillOpt 有意思的地方，在於它把 agent 改善拉回開發者熟悉的語言：迭代、約束、驗證、轉移。這比起「讓 agent 自己反省，然後希望它變好」更像一個可落地的工程流程。

即使不直接採用這個方法，它也提供了一個很清楚的設計方向：底層模型保持固定，把技能明確抽成可管理的 artifact，再用有門檻的方式去優化它。這對除錯、回滾、重用都比較友善。

對正在做 agentic workflows 的團隊來說，這篇論文真正值得注意的，不只是分數提升，而是它示範了一種把技能當成長期資產的思路。技能可以跨模型、跨執行環境演化，而且不必把每一次推理都變得更重。

目前從摘要能確定的，是它在多模型、多環境測試下拿到強勢結果，並且有明確的驗證門檻與受控編輯機制。至於它在更大規模實務場景裡會不會一樣穩，還要看完整論文怎麼處理那些目前摘要沒說清楚的細節。

• SkillOpt 把 agent 技能當成可優化的文字資產，而不是一次寫死的 prompt。
• 它用 bounded edit 和 validation gating 來控制技能更新，避免無限制重寫。
• 摘要聲稱它能跨模型與執行環境轉移，但完整 benchmark 細節未在摘要公開。