SkillOpt：把 skill.md 當可訓練狀態，適合 OpenClaw 和 Hermes 嗎？

半夜調整 Agent 的 System Prompt，常常改了東牆西牆倒，分數改來改去還是在原地打轉？微調模型權重成本太高，直接用 Prompt 塞滿 Context 又容易讓模型迷路。微軟近期出的 SkillOpt (Text-Space Optimizer) 想解決的就是這個痛點：不要動模型權重，只動獨立的 Skill 檔案。

它把 Agent 的自然語言技能當成外部 State，透過一輪一輪的 Rollout、驗證、局部編輯，最後產出可部署的 best_skill.md。這種做法的重點不是「叫模型更會想」，而是把 Agent 的行為規則、工具習慣、失敗修正方式，收斂成可以反覆優化的文字產物。

微軟這套 text-space optimizer 在做什麼？

SkillOpt 是 Microsoft Research 出的工具，官方定位就是一個 text-space optimizer：

不是微調模型權重，而是把 Agent Skill 當成可訓練的文字 State。
用 Trajectory、Validation Gate、Rejected Edit Buffer 這類機制，去讓 Skill 檔案真正變好。

GitHub 專案：microsoft/SkillOpt

SkillOpt GitHub repo card PNG

簡單來說：把 skill.md 當成可訓練、可驗證、可部署的資產。

先說結論：到底什麼情境適合？

如果你的專案有這些情況，引進 SkillOpt 會非常省事：

Skill 是獨立檔案，不是散在聊天記憶或程式碼裡。
任務可以重播，可以觀察完整的 Trajectory。
有明確的 Train / Validation / Test 切分。
能接受「先改 Skill，再觀察分數」這種優化流程。
你在意的是部署後的行為改善，而不是只在訓練時拿高分。

所以答案很簡單：

Hermes：非常適合。
OpenClaw：也適合，但要看你怎麼把 Skill、Workspace 跟 Eval 流程接起來。

SkillOpt 實際的優化流程

它不是我們一般認知的那種 Fine-tuning，因為它完全不改模型權重。

SkillOpt 的運作邏輯大概是這樣：

讓凍結的 Target Model 跑任務。
收集 Rollout Trajectory。
用一個 Optimizer Model 來讀這些失敗與成功案例。
產生 Bounded Edits，也就是具體的 add、delete、replace 操作。
用獨立的 Validation Gate 檢查分數是不是真的變高。
只有通過驗證的修改才會收進去。
跑完設定的 Epoch 後，輸出最穩的 best_skill.md。

這裡面的幾個核心機制很值得注意：

Trajectory-driven edits：不憑空亂改，根據實際執行軌跡踩到的坑來修。
Validation-gated updates：沒通過驗證閘門的改動一律打回票。
Rejected-edit buffer：被打回的修改會記下來，避免之後重複犯錯。
Epoch-wise slow/meta update：每次更新都有節奏地累積，不搞一次性大改。
Zero inference-time cost：部署後完全不增加額外的推理成本。

這讓 SkillOpt 比較像是一個技能層的訓練系統，而不是那種要工程師手動猜測的 Prompt 小抄。

跟 DSPy、TextGrad、GEPA 有什麼不同？

雖然大家都在優化 Prompt，但思路完全不一樣：

DSPy

DSPy 著重在優化 Program 或 Prompt Pipeline。它的重點是把 LLM 當成程式模組，優化的是輸入輸出的結構與模組之間的連接。

TextGrad

TextGrad 更像對文字表示做梯度式改寫，思路非常接近「把文本當成可微分的參數」來做反向傳播。

GEPA

GEPA 偏向演化式或 Agent 式的 Prompt 改良，會生成很多 Candidate 去做隨機探索。

SkillOpt

SkillOpt 的定位很具體：

它不只改單一 Prompt，也不僅是做 Prompt Search。
它是把 skill.md 當成可版本化、可驗證、可部署的訓練結果。

如果你要的是能長期維護、版本控制的 Agent 技能檔，選 SkillOpt 會順手很多。

為什麼它跟 Hermes 的八字特別合？

Hermes 本來就很適合這種方法，原因不是「它是 Agent」，而是它已經很接近 SkillOpt 的操作邏輯。

Hermes 有幾個特點跟 SkillOpt 簡直是天生一對：

Skill 本來就是寫在 Markdown 檔案裡。
可以把行為知識沉澱成可重用的獨立技能。
Profile、Memory 與 Cron 可以直接串成持續迭代的 Pipeline。
可以把不同角色拆成不同的 Profile，再針對各自 Skill 做 Eval。
修完 Skill 之後，不需要把新邏輯塞回模型權重裡。

所以如果你在 Hermes 上跑的是 Coding Helper、筆記整理、社群互動或商業分析，SkillOpt 就像是幫你的 Agent 在做「技能層的自動校正」。

其中最關鍵的是：Hermes 的 Skill 檔是可見且可控版的，加上它可以把長期工作流拆成穩定的角色與測試集，這兩點讓它接 SkillOpt 非常直覺。

那 OpenClaw 這類框架也吃得下嗎？

OpenClaw 當然能用，但整合難度取決於你的專案結構。

如果 OpenClaw 只是個比較通用的 Agent 執行框架，那 SkillOpt 也能接上；只是你要自己動手寫腳本把這些環節串起來：

Skill 的存放與讀取規格。
任務的 Trajectory 回放機制。
撈資料與評分驗證的流程。
Train / Val / Test 的 Dataset 切分。
版本管理與 Rollback 機制。

簡單來說，Hermes 的設計本來就往這個方向靠攏，而 OpenClaw 則需要你多寫一點 Glue Code。

如果你在 OpenClaw 裡已經有設計好的 Skill 檔、Workspace 與 Eval 集，那上 SkillOpt 就很合適；如果你的 Flow 比較散，那整合的踩坑成本就會高一些。

除了對話，還能拿來搞什麼？

SkillOpt 不只適用於聊天型的助理，它最擅長的是流程可重播、結果可驗證、失敗可回放的 Agent 情境：

Coding Agents：會跑 Repo、改檔、修 Bug、補測試的 Agent。
CLI Agents：大量依賴命令列工具、可回放的操作流程。
Browser Agents：要進網站、點 UI、撈資料、做表單操作的 Agent。
Research Agents：有明確資料集、檢索規則、答案驗證的研究 Flow。
Support / Ops Agents：客服、內部工單、SRE、資料處理等有 SOP 的流程。

如果你的 Agent 行為高度依賴即興發揮，或者根本沒有固定的 Eval 指標，那 SkillOpt 就不太適合。

跟 Claude Code 或 Codex 玩得起來嗎？

答案是可以，而且這通常是實務上最能產生價值的地方。

就目前釋出的論文與測試來看，SkillOpt 的實驗就是直接把 Codex 和 Claude Code 當作實際 Harness 來評估，所以它不是紙上談兵的學術玩具。

在 Workflows 上可以這樣規劃：

先用 SkillOpt 跑測試集，訓練出最穩的 best_skill.md。
把這份 Skill 檔直接當作 Claude Code / Codex 的 System Prompt 或專案 Rule 載入。
讓它們照著這份優化過的 Skill 執行日常的開發任務。
踩到新坑時，再把錯誤軌跡丟回 SkillOpt 做下一輪優化。

這樣的分工很清楚：SkillOpt 負責訓練與優化 Skill，Claude Code / Codex 負責執行任務。這不是說有官方一鍵安裝的 Extension，而是工作流上能完美互補。

動手起一個 SkillOpt 試試

SkillOpt 的架設與安裝路線蠻直接的。

1. clone + install

git clone https://github.com/microsoft/SkillOpt.git
cd SkillOpt
pip install -e .

這段指令先把 SkillOpt 的專案本體從 GitHub 抓下來，並以可編輯模式（editable mode）安裝到你的 Local 環境，方便你直接修改裡面的 Optimizer 邏輯。

2. 準備環境變數

先複製 .env.example，接著填入你的 API Key。

微軟官方文件提到 Azure OpenAI 是主要路線，所以 AZURE_OPENAI_ENDPOINT 也是必填欄位。

3. 準備資料切分

它要的 Dataset 目錄結構長這樣：

data/my_split/
├── train/items.json
├── val/items.json
└── test/items.json

這是 SkillOpt 運作時需要的資料夾結構，把任務樣本拆成訓練、驗證跟測試三份，讓 Tool 知道去哪裡讀取 Trajectory 與進行 Validation Gate 篩選。

4. 跑訓練

以 SearchQA 任務為例，下這行指令：

python scripts/train.py \
  --config configs/searchqa/default.yaml \
  --split_dir /path/to/your/searchqa_split \
  --azure_openai_endpoint https://your-resource.openai.azure.com/ \
  --optimizer_model gpt-5.5 \
  --target_model gpt-5.5

這行腳本會直接啟動 SkillOpt 的優化循環，我們把 Target Model 設成要優化的對象，並讓 Optimizer Model 去觀察錯誤軌跡、自動迭代並產出修改後的 Skill 檔案。

5. 跑 eval only

訓練跑完後，記得單獨跑一次 Eval。確認這份優化後的 Skill 在 Test Set 也能泛化，而不是只在 Train 過程裡自嗨。

我自己會這樣來規劃 Workflow

實務上要在 Hermes 或 OpenClaw 引入這套工具，我會建議這樣做：

把 Skill 當成有版本控制的程式碼檔案來維護。
先準備一個小而精準的 Benchmark 集，不要好大喜功。
限制 SkillOpt 每次修改的幅度，避免失控。
盯緊那些失敗的 Trajectory，那才是精進的養分。
善用 Rejected Edits Buffer，不要重複踩同一個坑。
把不同的 Task 拆給不同的 Profile，一個 Profile 只練一組 Skill。

這樣做能讓你很快抓出是 Skill 寫太籠統，還是工具的說明不夠明確，甚至能幫你檢視 Eval 指標有沒有訂錯。

不過，這幾種狀況先別用

SkillOpt 不是銀彈，在這些情境下它幫不上忙：

你手邊根本沒有穩定、可重複驗證的 Eval Dataset。
Agent 的行為完全塞在不可見的 System Prompt 裡，改 Skill 也吃不到。
你想要的是 Runtime 的即時學習，而不是 Offline 的批次優化。
任務過程隨機性太大，無法回放與評估。
你的 Agent 核心 Workflow 都還沒理順。

這些時候，先回頭理清你的業務流程，會比急著上優化器更有用。