最近讀到 Lilian Weng 寫 harness engineering 的文章，讓我想到一個很常見的研究現場。大家把 agent 換成新模型，成功率上升幾個百分點，就說它變聰明了；但過兩週再跑同一批任務，結果卻找不到當初為什麼變好。像十年大博士的實驗資料夾一樣，檔名叫 final、final2、final_really_final，最後連自己都不知道哪個結果可以相信。

簡單來說，harness 是包住基礎模型的整套部署系統。它決定 agent 怎麼規劃、怎麼呼叫工具、哪些 context 可以看、產出的 artifacts 放哪裡，以及結果怎麼被評估。模型只是其中一個元件。對長期任務來說，workflow、persistent state、permission control 和 evaluation 的設計，常常比 prompt 再加兩段說明更能決定它能不能穩定進步。

我會把「讓 agent 自我改進」拆成四個問題，而且順序很重要。

先固定什麼

第一個問題是，這次實驗到底固定了哪些條件。至少要固定 model version、工具版本、任務輸入、權限範圍、最大步數、timeout、隨機種子或等價的重跑設定。若今天把 model 換了，明天又把 context policy 改了，後天新增一個可以寫入 production 的工具，那麼分數變化沒有辦法歸因。

我在做 multi-agent 實驗時，曾經把單一任務拆成 planner、coder、reviewer 三個 sub-agent。第一次跑 20 個 case，通過 11 個。後來通過 16 個，我原本以為是 reviewer prompt 改善，結果追 log 才發現同時把 timeout 從 120 秒改成 300 秒，並且讓 coder 可以重新執行測試。真正有效的因素很可能是工具與時間，不是 prompt。這種結果如果沒有 config snapshot，會被錯誤地寫成「agent reasoning 提升」。

第二個問題是，哪些東西必須留下來，才能在一週後重建這次結果。不要把所有 logs 塞回 context，context 不是倉庫。每一次 rollout 至少要留下 task id、commit hash、完整 config、每個 tool call 的輸入輸出、error trace、產出的檔案、評估結果與停止原因。sub-agent 平行執行時，還要有明確的 status 和 files，否則主 agent 只看到一句「我完成了」，卻無法知道它到底跑過測試，還是只是生成了一段看起來很像答案的文字。

一個很實用的目錄可以長這樣。

run-2026-10-11-0042/
  config.json
  task.json
  rollout.jsonl
  agents/planner/status.json
  agents/coder/diff.patch
  agents/coder/test.log
  eval/raw.json
  eval/judge.json

這不只是方便除錯，也是在建立可反駁性。當 agent 說「我成功了」，研究者可以回頭問，成功是依據哪個測試、哪個版本、哪一段 artifact 判定的。

讓記憶變成可管理的物件

第三個問題是 persistent state 要怎麼更新。很多系統所謂的 memory，其實只是把上一輪對話整段貼進下一輪。短期看起來很有連續性，長期卻會累積過期結論、錯誤猜測和彼此矛盾的規則。

ACE 的想法我覺得很值得借用。它讓 generator 產生候選經驗，reflector 分析哪些經驗有用，curator 再整理成帶有 ID 的 context playbook。重點不是把 prompt 寫得越長，而是讓每條規則都能被新增、修正、刪除和追蹤。例如不要只存「遇到 API 錯誤時重試」，而要存成：

id=api_retry_07, rule=timeout 先退避 2、4、8 秒，最多三次, evidence=run-0042/run-0051, scope=GET request, status=active

這樣下一次失敗時，agent 可以引用規則，也可以指出新案例與規則衝突。MCE 所區分的 context-management mechanism 和 context artifact 也很重要。前者是怎麼取資料、怎麼壓縮、什麼時候更新，後者才是被管理的記憶內容。兩者混在一起時，你很難知道是檢索策略錯了，還是記憶本身已經腐化。

權限和評估要一起設計

第四個問題是 agent 被允許做什

麼，以及我們怎麼知道它真的做到了。權限控制不是部署完成後才加的安全欄杆，它也會改變學習訊號。若 agent 可以直接改 production、刪除失敗紀錄，短期成功率可能上升，實際上只是把負面證據藏起來。

我會把工具分成 read、write、execute 三層。自我改進初期，agent 可以讀取 repo、寫入 sandbox、執行測試，但不能刪除歷史 artifacts，也不能碰 production。要升級權限，必須先通過獨立 evaluator，並留下 diff 和審核結果。這裡的原則很像做人體實驗，先控制變因，再逐步放寬條件，不要一開始就讓受試者自己改實驗室的儀器。

評估也不要只看單一 pass rate。至少同時追蹤 task success、重跑一致性、工具錯誤率、平均成本、權限違規次數，以及 evidence completeness。假設 pass rate 從 70% 升到 82%，但平均 token 從 8,000 變成 35,000，重跑一致性從 90% 降到 51%，那未必是改善。它可能只是更願意試錯，或碰巧在 grader 的漏洞上花更多步數。

我的停止條件

每次做 self-improvement，我會先寫好三個停止條件。第一，連續兩輪在未參與優化的 holdout set 沒有改善，就停止改 prompt。第二，主指標改善時，若成本增加超過 30%、重跑一致性下降超過 10 個百分點，視為未通過。第三，任何 evidence completeness 低於 95% 的 rollout，不納入正向更新，因為你連它怎麼成功都不知道。數字可以依任務調整，但停止規則必須在看結果前決定。

一個很典型的反例是，團隊讓 agent 讀取過去所有成功案例，再用同一批案例當 evaluator。三週後分數從 0.62 升到 0.94，demo 看起來非常漂亮。換成 50 個沒有出現在 playbook 的任務，分數卻掉到 0.58。這不是 agent 變得更會解題，而是 context 和考卷互相洩漏。另一個反例是只保留最後答案，不保留中間 tool calls。當成功率下降時，團隊無法判斷是規劃錯、權限被拒，還是測試本身沒有執行，只好再訓練一輪，然後把不可診斷誤當成模型問題。

所以我現在判斷 agent 有沒有變好，會先看一張小表，而不是先看排行榜。它是否在固定條件下改善。它是否能在 holdout 任務上維持改善。它是否留下足夠證據讓別人重跑。它是否在成本、穩定性和安全邊界內改善。四題中只要有兩題答不出來，我就不把結果稱為能力提升。

Meta-Harness 把 harness code 本身也變成可評估、可搜尋的目標，這個方向的意義正在這裡。真正需要優化的，可能不是某一句 prompt，而是任務如何被切分、狀態如何被保存、工具如何被授權，以及失敗如何進入下一輪。研究 agent 的時候，我們很容易盯著模型的腦袋，卻忘了替它設計一個可以留下足跡的實驗室。博士念到第十年，我越來越相信，能穩定進步的系統，首先得能說清楚自己上一輪到底做了什麼。