背景： 我們在生產環境中運行了 10 個 Auto-Healing Loop，歷經 204 session 的完整審計，對比了市場上 14 種 AI Agent 架構方案。現在，是時候將這些發現轉化為具體的系統重構方案。
本文結構： 現狀診斷 → 8 個重構假設 → 8 個架構節點技術選項對比 → 完整重構路線圖
1. 現狀診斷：當前架構的 6 個結構性缺陷
1.1 執行-驗證不分離
| 問題 | 證據 | 影響 |
|---|---|---|
| Main agent 自己執行 + 自己驗證 | system-health 連續 5 次跳過 OMLX 檢查，驗證 spawn 率 0/5 | 關鍵服務宕機 20 小時未被發現 |
| Looper 自己改 code 自己驗收 | full_repair session：55 tool calls, 0 checker spawn | 修改未經獨立審查 |
| Prompt 層的 verify 指令被無視 | 6 個 session, 0 次 spawn checker | 純文字規則在 LLM 中 100% 失效 |
1.2 雙重 Cron 體系混亂
| 問題 | 證據 |
|---|---|
| Main OpenClaw cron 有 11 jobs（含 loop jobs） | system-health + daily-triage 綁定 main agent |
| Looper 有獨立的 cron 系統（不同 cron ID 前綴） | pr-review, email-watch 等 6 jobs 走 looper |
| 兩個體系無統一管理 | 無法從單一視圖看到所有 loop 排程 |
1.3 Workspace 路徑混亂
| Agent | Workspace | 讀取 LOOP.md 時實際路徑 |
|---|---|---|
| main | ~/.openclaw/workspace/ |
~/.openclaw/workspace/loops/...（舊版！） |
| looper | ~/Desktop/UltraClaw_Project/loop-engineering/ |
正確 |
1.4 無方法論強制機制
- LOOP.md 的七階段內循環僅存在於 prompt 文字中
- 無架構層的 completion gate（Stop Hook 等效機制）
- compliance 未追蹤、未審計、未強制
1.5 Delivery 機制未正確配置
- 6 個 looper cron job 嘗試直接發送飛書訊息（LarkClient appId/appSecret 缺失）
- Looper 應通過 sessions_send 到 main agent，而非直接發送
1.6 狀態管理分散
- 每個 loop 有獨立的 STATE.json
- 無全局狀態聚合（已有
state/aggregator.py但未被 cron 使用） - 無法從單一節點查詢「所有 loop 的當前狀態」
2. 重構假設
基於市場研究和生產審計，我們提出以下 8 個重構假設：
| # | 假設 | 靈感來源 | 驗證方式 |
|---|---|---|---|
| H1 | 將 verify 從 prompt 提升為架構強制，可使 compliance 從 ~0% 提升至 ~100% | Claude Code Stop Hook | 重構前後對比 compliance_score |
| H2 | 角色隔離（execute agent ≠ verify agent）比 prompt 建議可靠 10x 以上 | MetaGPT QA Engineer | A/B 測試 |
| H3 | 統一的狀態管理層可使審計效率提升 5x | VIGIL EmoBank | 審計時間對比 |
| H4 | 外部反射層（cron 獨立掃描）可以捕獲 prompt 層無法防止的失敗 | VIGIL Out-of-band | 故障檢測率對比 |
| H5 | 對關鍵決策採用 Race Pattern（多模型並行判斷），可將誤判率降低 50%+ | Cursor Race Pattern | 關鍵決策準確率 |
| H6 | 將內循環引擎化（inner_loop_runner.py）可使 retry 執行率從 0% 提升至 100% | OpenHands Loop Recovery | retry 執行次數 |
| H7 | 統一的 Delivery Bus 可消除 100% 的跨 agent 通訊錯誤 | 無特定來源，問題驅動 | 通訊錯誤率 |
| H8 | Cron 的 Planning 和 Execution 分離可使排程靈活性提升 3x | Aider Architect-Editor | 排程變更成本 |
3. 架構節點技術選項
節點 1：Agent 角色隔離機制
問題： 如何確保 execute agent 永遠不會 verify 自己的工作？
| 方案 | 描述 | 強制性 | 實現複雜度 | 對現有系統改動 |
|---|---|---|---|---|
| A: Config-level（當前） | agent config 中設定角色，prompt 中建議行為 | 🟢 無 | 低 | 無 |
| B: Tool-gating | 在 Gateway 層攔截：verify agent 不能 exec，execute agent 不能 spawn checker | 🟠 中等 | 中 | Gateway plugin |
| C: Stop Hook | 借鑑 Claude Code：loop 完成前強制執行外部驗證腳本，不通過則 block | 🔴 強 | 中 | 修改 Gateway turn lifecycle |
| D: Two-phase cron | 每個 loop 拆分為兩個獨立 cron job（execute + verify），不同 agent | 🔴 強 | 低 | 重寫 cron job 定義 |
推薦： C + D 組合。Stop Hook 作為即時防線，Two-phase cron 作為結構性保證。
節點 2：驗證機制（Checker）
問題： 誰來驗證？怎麼驗證？驗證失敗怎麼辦？
| 方案 | 描述 | 驗證信號 | 自主程度 |
|---|---|---|---|
| A: Self-verify（當前） | Agent 自己在 prompt 中檢查結果 | Soft（文字判斷） | ❌ 不穩定 |
| B: Dedicated checker agent | 每個 loop 完成後 spawn coder-deepseek 獨立審查 | Soft（agent 判斷） | 🟠 需 agent 主動 spawn |
| C: Stop Hook script | Python/Shell 腳本檢查 STATE.json schema + 關鍵指標 | Hard（結構化檢查） | 🔴 外部強制 |
| D: Race Pattern | 對關鍵決策（如 OMLX severity），同時讓 2+ agents 判斷，取多數 | Soft（多數投票） | 🔴 統計性保證 |
| E: VIGIL-style supervisor | 獨立 process 定時掃描所有 loop STATE.json，檢查 compliance | Hard（結構化檢查） | 🔴 外部、持續 |
推薦： C + E 作為主力，D 作為關鍵決策增強。
節點 3：Cron / 排程系統
問題： 如何統一管理 10+ loop 的排程？Planning 和 Execution 是否應分離？
| 方案 | 描述 | 優點 | 缺點 |
|---|---|---|---|
| A: OpenClaw built-in（當前） | 使用 OpenClaw cron API | 與 Gateway 深度整合 | 雙重體系、agent binding 限制 |
| B: Native crontab | 使用系統 crontab 觸發 | 穩定、獨立於 Gateway | 無內置重試、無狀態追蹤 |
| C: Scheduler Agent | 獨立的 scheduler agent 管理所有排程 | 單一真相來源、靈活 | 單點故障 |
| D: Plan-Execute 分離 | Planning cron（何時執行）和 Execution cron（誰執行）分開管理 | 職責清晰、易變更 | 兩層排程協調 |
推薦： C + D。建立 loop-scheduler agent 統一管理排程，Plan（cron 定義）和 Execute（實際觸發）分離。
節點 4：狀態管理
問題： 如何統一追蹤 10 個 loop 的執行狀態、compliance、歷史？
| 方案 | 描述 | 查詢能力 | 變更追蹤 | 複雜度 |
|---|---|---|---|---|
| A: STATE.json per loop（當前） | 每個 loop 一個 JSON 檔案 | 手動 | git diff | 低 |
| B: Centralized SQLite | 所有 loop 狀態寫入單一 DB | SQL query | 內置 | 中 |
| C: Event-sourcing | 所有 state change 作為事件 append，狀態從事件重建 | 時光旅行 | 完整 | 高 |
| D: Global aggregator | state/aggregator.py 定時聚合所有 STATE.json → 寫入 global-state.json |
單一檔案 | 快照對比 | 低 |
推薦： B + D。SQLite 作為主力，global-state.json 作為快速查看介面。
節點 5：內循環引擎（Retry）
問題： 如何確保 loop 在失敗時真正進行 retry，而非一次性報告？
| 方案 | 描述 | 觸發方式 | 強制性 |
|---|---|---|---|
| A: Prompt-based（當前） | LOOP.md 中描述 retry 策略，agent 自行決定 | Agent 自覺 | 🟢 無 |
| B: Cron-level retry | cron job 設定 retry on failure | Gateway | 🟠 可配置 |
| C: Engine-level | inner_loop_runner.py 強制執行 retry 循環 |
Script | 🔴 強 |
| D: State-machine | 定義合法狀態轉移，非法轉移報錯（VIGIL-style） | 狀態機 | 🔴 最強 |
推薦： C。inner_loop_runner.py 作為標準引擎，所有 loop 必須通過它執行。
節點 6：Delivery / 通訊 Bus
問題： Agent 之間如何通訊？如何確保 escalation 到達正確的終端？
| 方案 | 描述 | 可靠性 | 複雜度 |
|---|---|---|---|
| A: Direct channel（當前） | Agent 直接發送訊息到特定渠道 | 🟡 取決於 agent 配置 | 低 |
| B: sessions_send bus | 所有 agent 通過 sessions_send 到 main，由 main 統一轉發 | 🟠 取決於 main | 低 |
| C: Message queue | Redis/RabbitMQ 作為中間件 | 🔴 高 | 高 |
| D: Escalation engine | 獨立的 escalation agent，根據 severity + target 自動路由 | 🔴 高 | 中 |
推薦： B + D。sessions_send 作為日常通訊，escalation engine 作為關鍵告警保證送達。
節點 7：上下文管理
問題： 長期運行的 loop 如何避免 context 膨脹？如何保留關鍵決策？
| 方案 | 描述 | 適用場景 |
|---|---|---|
| A: Session isolation（當前） | 每次 cron 執行創建新 session | 短期任務 |
| B: STATE.json persistence（當前） | 關鍵狀態寫入 STATE.json，下次執行時讀取 | 跨 session 記憶 |
| C: Claude Code 式壓縮 | 五層壓縮管線，保留關鍵決策 | 長期 session |
| D: Aider 式 RepoMap | 只注入相關上下文，非全部歷史 | 大規模任務 |
推薦： 保持 A + B（已足夠），對於需要長期上下文的 loop，加入 C 的關鍵決策保留機制。
節點 8：多模型策略
問題： 不同 loop 是否需要不同模型？關鍵決策是否需要多模型驗證？
| 方案 | 描述 | 成本 | 可靠性 |
|---|---|---|---|
| A: 固定分配（當前） | 每個 agent 有固定模型 | 低 | 取決於模型 |
| B: Dynamic router | 根據任務複雜度動態選擇模型 | 中 | 🟠 |
| C: Race Pattern | 關鍵決策時並行調用多模型，取最佳 | 高 | 🔴 |
| D: Architect-Editor | 強推理模型做計劃，快速模型做執行 | 中 | 🟠 |
推薦： A 作為基礎，C 作為 OMLX 級關鍵決策的增強，D 作為複雜 loop（如 rnd-discovery）的選項。
4. 重構路線圖
Phase 0：無破壞性前置（本週，0 風險）
| # | 行動 | 依賴 | 預估 |
|---|---|---|---|
| P0.1 | 統一狀態管理層：SQLite + global-state.json | 無 | 2h |
| P0.2 | 部署 loop-scheduler agent：統一 cron 視圖 |
無 | 3h |
| P0.3 | 修正全部 delivery 設定 + escalation engine | 無 | 2h |
| P0.4 | 清理舊版 workspace 目錄（已部分完成） | 無 | 0.5h |
Phase 1：架構強化（下週，低風險）
| # | 行動 | 依賴 | 預估 |
|---|---|---|---|
| P1.1 | 實現 Stop Hook：Gateway turn lifecycle 修改 | P0 | 4h |
| P1.2 | 拆分 loop cron 為 Plan + Execute 兩層 | P0.1, P0.2 | 3h |
| P1.3 | 部署 Two-phase cron（execute + verify 分離） | P1.2 | 4h |
| P1.4 | 實現 inner_loop_runner.py 引擎 |
P0.1 | 5h |
Phase 2：智能增強（本月，中等風險）
| # | 行動 | 依賴 | 預估 |
|---|---|---|---|
| P2.1 | VIGIL-style 外部反射層（score_enforcer 擴展） | P0.1 | 6h |
| P2.2 | Race Pattern for OMLX 級關鍵決策 | P1.4 | 4h |
| P2.3 | Dynamic model router for complex loops | P0.2 | 5h |
| P2.4 | Claude Code 式 context compaction | P1.4 | 8h |
Phase 3：生態完善（下月，低風險）
| # | 行動 | 依賴 | 預估 |
|---|---|---|---|
| P3.1 | Loop 模板引擎：一鍵建立新 loop | P1.3, P1.4 | 6h |
| P3.2 | Dashboard v2：全局 loop 健康 + compliance 視圖 | P0.1 | 8h |
| P3.3 | 自動化回歸測試套件 | P1.4 | 6h |
| P3.4 | 文件化 + 社群發布 | P3.1-3.3 | 4h |
5. 預期成果
定量目標
| 指標 | 當前 | Phase 0 | Phase 1 | Phase 2 |
|---|---|---|---|---|
| Verify 執行率 | 0% | 0% | 100% | 100% |
| Compliance score | ~2/7 | 4/7 | 6/7 | 7/7 |
| Cron 管理統一 | 雙體系 | 單一 | 單一 | 單一 |
| Delivery 錯誤率 | 6/10 jobs | 0/10 | 0/10 | 0/10 |
| 關鍵決策誤判率（OMLX） | 100%（5/5） | 100% | 100% | <20% |
| 審計效率 | 手動 204 session | 自動 | 自動 | 自動+預測 |
定性目標
- 從「prompt 祈禱」到「架構保證」： 不再依賴 agent 自覺遵守規則
- 從「黑盒執行」到「透明審計」： 每個 loop 的每一步都可追溯
- 從「被動修復」到「主動預防」： 外部反射層在問題發生前檢測模式
- 從「單點決策」到「多元驗證」： 關鍵判斷經多方確認後才執行
6. 風險與緩解
| 風險 | 影響 | 緩解 |
|---|---|---|
| Stop Hook 過度阻斷正常流程 | 服務中斷 | 8 次 block 上限 + 漸進部署 |
| SQLite 並發寫入衝突 | 狀態丟失 | WAL 模式 + 寫入隊列 |
| Race Pattern 增加 API 成本 | 預算超支 | 僅用於關鍵決策（<5% 的決策點） |
| 架構改動期間 cron job 中斷 | 監控空白 | Phase 0 前置不影響現有 cron |
| inner_loop_runner 無限循環 | 資源耗盡 | max_retries=30 硬限制 |
本文是 OpenClaw Loop Engineering 重構的技術論證草案。所有假設需經討論和優先級排序後轉化為具體實施計劃。