HarnessX：Agent 不該只靠換模型 — 從 Runtime 介面自演化挖出 +44% 效能
一句話：Agent 表現瓶頸不在模型大小，在 runtime harness（prompt、工具、記憶、控制流）的設計品質。HarnessX 把 harness 模組化並從執行記錄自動演化，平均 +14.5%，弱 baseline 上最高 +44%。
問題：大家都在換模型，沒人在優化 harness
目前 AI agent 的開發思維是：表現不好 → 換更大模型。但 HarnessX 的作者指出，agent 的 runtime harness——包含 prompt 設計、工具組合、記憶策略、控制流——對手動調參後就固定不動。每次新任務、新模型都要從頭手工搭建，執行過程中產生的豐富 trace 也從未被系統性回收利用。
這正是我們在 Hermes 子 agent 遇到的問題：delegate_task 的描述寫好以後就放著，失敗了也不知道是 prompt 的問題還是工具配置的問題。
核心機制：三個創新
1. Harness 組裝代數（Substitution Algebra）
HarnessX 把 agent 的各個元件抽象為型別化的 harness primitives：
- Prompt 模板（含變數槽位）
- 工具定義（含型別簽章）
- 記憶策略（短期/長期/工作記憶）
- 控制流（線性、分支、迴圈、子任務）
這些 primitives 透過 substitution algebra 組合——不是寫死一整段 prompt，而是像樂高一樣拼接。換模型時只需要換對應的 prompt primitive，不需要重寫整個 agent。
2. AEGIS：Trace-Driven 自演化引擎
這是 HarnessX 最關鍵的創新。AEGIS 建立在一個 operational mirror 之上：
Symbolic Adaptation（規則驅動） + Reinforcement Learning（模型無關優化）
每次 agent 執行產生 trace 後，AEGIS 同時從兩條路徑處理：
- 符號路徑：根據預定義規則（如「連續兩次 tool call 失敗 → 簡化工具描述」、「輸出格式不符合預期 → 加強格式約束」）直接修改 harness
- RL 路徑：將 trace 轉為 reward signal，用 RL 優化 harness 參數（prompt 措辭、tool 選擇策略、記憶保留策略）
3. Harness–Model 共演化
同一批 trace 不只是改善 harness，還能作為模型微調的訓練資料。這形成了一個閉環：
執行 → Trace → 改善 Harness（短期） + 改善模型權重（長期） → 再執行
等於把 agent 開發從「手工調整」變成「自動演化」。
實驗結果
在五個 benchmark 上測試（ALFWorld、GAIA、WebShop、τ³-Bench、SWE-bench Verified）：
- 平均 +14.5%
- 弱 baseline 上最高 +44.0%
- 增益最大的地方正是 baseline 最弱的地方——證明 harness 演化能「救」表現差的 agent
對 Hermes 的即刻啟發
三件現在就能做的事
- 模組化 delegation prompt：把目前的 delegate_task 描述拆成任務模板、約束規則、回傳格式、驗證清單四個模塊。每次子 agent 失敗就只修對應模塊。
- 記錄 execution trace：每次 delegate 失敗時，擷取失敗原因（tool error、格式錯誤、內容空洞）→ 存為結構化記錄 → 下次同類任務時注入 corrected prompt。
- Failure-driven prompt update：參考 AEGIS 的符號路徑——定義簡單規則：「子 agent 回傳空洞摘要 → 在 prompt 加『至少列出 3 個具體變更』」、「寫錯目錄 → 在 prompt 加『確認工作目錄：必須在 /tmp/xxx 下操作』」。
限制與風險
- 程式碼尚未開源（future release，日期未定）
- RL 路徑需要大量 trace 才能收斂，小規模部署可能只能走符號路徑
- 過度自動演化可能導致 harness 膨脹（prompt 越來越長），需要定期修剪
參考
Chen et al., "HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry", arXiv:2606.14249, 2026.