自我改進 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。