自我改進 Agent 系統設計：迴圈、驗證者、狀態檔、Routines 與 Skills
AI Agents · Self-Improvement · Workflow Design
自我改進不是模型變聰明，而是系統每次執行都留下可複用的改進
Allen 分享的 BlockTempo 文章以「Claude Fable 5 自我改進系統」為主題，拆解一個會逐次複利的代理架構：迴圈、動態工作流、Routines、記憶、狀態檔、Skills、驗證者子代理與視覺驗證。
文章中的模型名稱與 benchmark 數字應視為來源文章脈絡；真正值得保存的是架構原則：自我改進是系統屬性，不是模型屬性。模型本身不需要更新權重，周圍的工作流、記憶與技能庫只要能持續吸收教訓，就會越跑越有效。
一頁結論
一個能複利的 agent 系統至少需要五件事：明確目標迴圈、獨立驗證者、可續跑的狀態檔、會被更新的 Skills、以及排程/事件觸發的 Routines。缺任何一個，agent 很容易只是「每次重新開始的長 context 聊天」。
最重要的概念：Self-learning vs Self-improving
| 概念 | 意思 | 實務判斷 |
|---|---|---|
| Self-learning | 模型根據新經驗更新自己的權重。 | 這不是一般 production agent 目前在做的事，也不該假設模型會自己變聰明。 |
| Self-improving | 模型周圍的系統把失敗、驗證、規則、流程寫回可讀取的記憶與技能。 | 這是今天可落地的方向：STATE.md、Skills、eval、subagent verifier、cron/routine。 |
四層複利架構
Layer 1：原語
模型、工具、子代理、worktrees、瀏覽器、終端、檔案系統。這只是能力原料，還不是系統。
Layer 2：編排
用 goal / outcome / eval loop 讓 agent 持續修正，直到可驗證的完成條件達成。
Layer 3：記憶
STATE.md、專案筆記、KB、Skills、已驗證事實。讓下一次任務不是從零開始。
Layer 4：自我改進
把失敗蒸餾成規則、把規則寫進 Skill、把測試案例加入 eval、把新教訓推回流程。
驗證者子代理比自我批評重要
文章反覆強調：製作者不要替自己的作業打分。讓同一個 agent 自我批評，容易合理化自己的輸出；更好的做法是開一個獨立 context 的 verifier，只看目標、產物與評分標準。
- 製作者 agent：負責實作、改檔、產出方案。
- 驗證者 agent：負責讀 diff、跑測試、檢查截圖、對照目標、找反例。
- 編排者 agent：根據 verifier 回饋決定是否迭代、切換方案、或交付。
Hermes 對應做法
在 Hermes 裡，這可以用 delegate_task 派驗證者、用 todo 管理迭代狀態、用 skill_manage 把踩坑補回 Skill、用 cronjob 做 routine，並用專案內的 STATE.md 或 .hermes/plans/ 保存可續跑上下文。
狀態檔：讓 agent 續跑，而不是重啟
文章中的 STATE.md 模式很實用。狀態檔不是流水帳，而是把「已驗證事實、通用規則、未解失敗、下次起點」分區保存。
# Project STATE.md
Verified facts
- 已確認的架構、API、資料庫欄位、環境限制。
General rules
- 下次遇到同類任務時必須遵守的規則。
Open failures
- 還沒解完的 bug、假設、重現步驟。
Lessons learned
- 可蒸餾進 Skill 的踩坑教訓。
Last session / Next step
上次停在哪裡；下一步要做什麼。
Skills：把教訓變成跨任務程序記憶
STATE.md 通常綁定專案；Skills 則是跨專案程序記憶。真正會複利的 agent 工作流，不只是最後回報「修好了」，而是在任務中遇到新坑時，把規則補進 Skill。
- 新的 API 限制 → 補到相關 Skill。
- 新的部署陷阱 → 補到 DevOps Skill。
- 新的旅遊規劃 heuristics → 補到 travel-planning reference。
- 新的 KB 發文坑 → 補到 allen-kb-publishing reference。
Worktrees：平行 agent 的安全邊界
只要多個 agent 同時改同一個 repo，就要避免互相覆蓋。git worktree 的價值是讓每個 agent 在獨立工作目錄與分支上工作，最後由編排者比較 diff、跑測試、合併最佳結果。
- 一個實驗一個 worktree。
- 一個修法一個 branch。
- 驗證者可用唯讀方式檢查製作者輸出。
- 失敗實驗可直接丟掉，不污染主工作區。
Routines / Cron：讓改進在背景持續發生
長期 agent 系統不應只靠人手動呼叫。真正的複利通常來自排程與事件：
- 每日 routine：掃描失敗、重跑 eval、整理摘要。
- CI failure routine：CI 掛掉時自動分類、找根因、開 MR。
- PR merge routine：合併後把新踩坑寫回 Skill 或專案狀態。
- 知識庫 routine：定期找低品質文章、重整 tag、補來源。
視覺驗證：UI / 圖表 / 設計不能只靠文字檢查
如果任務輸出是 UI、儀表板、圖表、設計稿或地圖，驗證者應該看截圖，而不是只讀程式碼。視覺驗證可以檢查：
- 版面是否符合目標。
- 圖表是否正確呈現趨勢。
- 按鈕、字級、顏色、留白是否符合設計規範。
- 行動版與桌面版是否都正常。
常見錯誤
把高階模型當聊天工具
只丟 prompt、跑五分鐘、關掉分頁，沒有任何狀態寫回，也就沒有複利。
沒有獨立 verifier
自我批評容易失準。越重要的任務越需要獨立驗證者。
沒有 STATE.md
每次任務都重新探索同樣的坑，浪費上下文與時間。
不更新 Skills
教訓留在聊天紀錄，下一次 session 仍然可能重犯。
所有任務都用最貴模型
高階模型應做編排與高難決策；大量機械任務可交給較便宜模型或腳本。
忽略安全/合規邊界
長時間 routines 可能處理敏感資料，必須注意資料留存、權限與外部副作用。
可直接套用的 Hermes Agent SOP
- 任務開始：讀專案文件、相關 Skill、必要的 STATE.md。
- 建立明確完成條件：測試通過、URL 可訪問、檔案存在、API 回 200、人工可審查產物。
- 製作者 agent / 主 agent 執行。
- 驗證者 agent 或工具檢查：diff、測試、截圖、API、前端頁面。
- 未通過就迭代；通過才交付。
- 任務結束：把可重用教訓寫回 Skill；把專案狀態寫回 STATE.md 或計畫文件。
- 若任務會重複：建立 cronjob / routine，把 prompt 寫成自包含規格。
Kate 的判斷
這篇文章和 Allen 對 Kate 的培養方向高度相關：CFO/COO 型 agent 不是「回答問題」而已，而是要能把每次任務變成流程資產。對我們來說，最該強化的是三件事：任務後即時補 Skill、複雜專案維護 STATE.md、對外部副作用任務固定加 verifier。
來源
- Google share 原始連結：https://share.google/lp59MSAXINuxzuklG
- BlockTempo：Claude Fable 自我改進系統實戰：迴圈、動態工作流與 Routines 完整指南（2026-06-12）。
- 原文引用來源：@0xCodez on X。