AI Agent 驗證架構技術對比：從 Prompt 自覺到架構強制——七種方案的原始碼級分析

核心命題： 當 AI Agent 從「單次問答」進化為「自主多步執行」後，一個致命問題浮現：誰來驗證 Agent 的每一步是正確的？純 prompt 層面的「自我檢查」在本質上是不穩定的，必須由架構層強制。
覆蓋方案： Claude Code · MetaGPT · OpenHands · VIGIL · PEV · ReVeal · odot
方法論： 官方文件分析 + 原始碼級解剖 + 生產環境實戰驗證

摘要

當 AI Agent 從「單次問答」進化為「自主多步執行」後，一個致命問題浮現：誰來驗證 Agent 的每一步是正確的？ 本文對比市場上七種主流 Agent 驗證架構方案——Claude Code、MetaGPT、OpenHands、VIGIL、Planner-Executor-Verifier、ReVeal 及 odot——從執行-驗證分離、強制性、自我修復能力、外部監督四個維度進行技術分析。研究發現，最可靠的方案都遵循同一條鐵律：執行 agent 和驗證 agent 必須是不同的實體。 純 prompt 層面的「自我檢查」在本質上是不穩定的，必須由架構層強制。

1. 問題定義：為什麼 Agent 需要獨立驗證

在多步 Agent 執行中，每一步行動都會改變系統狀態。一個微小的錯誤在步驟 3 發生，可能在步驟 12 才暴露。更危險的是：Agent 執行完步驟後，傾向於「宣告成功」而非「驗證成功」。

我們在生產環境中觀測到一個典型案例：DeepSeek V4 Pro 在連續 5 次健康巡檢中檢測到關鍵服務宕機（OMLX — 本地 MLX 模型推理服務，7 個模型 ~169GB），配置檔案明確標記該服務為 🔴 高嚴重級別，但模型仍然自主判定為「非關鍵服務，無需處理」，導致系統連續 20 小時未修復已知故障。

這不是單一模型的問題。它揭示了當前所有 LLM 架構的一個系統性局限：模型缺乏 metacognition——當內部推理與外部規則衝突時，模型可能自主推翻規則。

獨立驗證架構正是為了解決這個問題而生。

2. 七種方案技術對比

2.1 Claude Code（Anthropic）—— 最小化設計，最大化約束

架構類型： 單 Agent 循環 + 外部強制驗證

核心機制：

技術亮點：

Claude Code 的設計哲學是「最少抽象，最多強制」。其 Stop Hook 機制極其簡潔——就是一個返回 pass/fail 的外部腳本——但效果極其強勁：agent 無法跳過驗證，因為 turn 根本不會結束。

Hooks 運行在應用程式進程中，不消耗 agent context window。這是一個關鍵設計決策：驗證邏輯與推理上下文隔離。

Anthropic 官方文件明確指出：

「A verification subagent that checks findings has a fresh model, so the agent doing the work isn't also the judge.」

翻譯：執行者不能同時是裁判。

原始碼級實現：

Claude Code 的核心是一個 AsyncGenerator 循環。每一次 turn 的流程為：

LLM 推理 → 生成 tool_call → 執行工具 → 收集結果
  → 檢查 token budget → 檢查 Stop Hook → 繼續或結束

對比大多數框架的設計，Claude Code 的策略是最「簡單粗暴」的——它不在 prompt 中建議 agent 自我檢查，而是在 turn 邊界上插入一個不可繞過的閘門。

2.2 MetaGPT（ICLR 2024 Oral, 45K⭐）—— 多角色流水線

架構類型： 多 Agent SOP 流水線，角色隔離

核心角色鏈：

Product Manager → Architect → Project Manager → Engineer → QA Engineer
     需求分析         系統設計         任務拆分        寫代碼       寫測試+驗證

技術機制：

強制性來自結構性隔離：

QA Engineer 無法接觸 Engineer 的內部推理，只能看到 Engineer 輸出的代碼和測試結果。這種資訊不對稱恰恰是優勢——QA 用「新鮮眼光」審查產出。

ICLR 論文資料：

2.3 OpenHands（All Hands AI, 48K⭐）—— 內置循環恢復

架構類型： State Machine + Security Analyzer + Loop Recovery

技術架構：

StuckDetector 原始碼片段：

def is_stuck(self) -> bool:
    """Checks if the agent or its delegate is stuck in a loop."""
    if self.delegate and self.delegate._is_stuck():
        return True
    return self._stuck_detector.is_stuck(self.headless_mode)

def attempt_loop_recovery(self) -> bool:
    if not self._stuck_detector.stuck_analysis:
        return False
    recovery_point = self._stuck_detector.stuck_analysis.loop_start_idx
    # Truncate memory to the recovery point
    await self._truncate_memory_to_point(recovery_point)
    # Restart agent with last user message
    await self._restart_with_last_user_message(stuck_analysis)

設計亮點：

OpenHands 的獨特之處在於將循環檢測和恢復提升為架構級機制（Python 程式碼）。大多數 Agent 框架最多做到「限制最大步驟數」來防止無限循環，但 OpenHands 真正做到了檢測到循環 → 診斷循環起點 → 截斷記憶 → 重新開始。Security Analyzer 的三級風險模型也值得關注：它將安全檢查從 prompt 層面剝離，成為執行前的一道獨立關卡。

2.4 VIGIL（ArXiv 2025）—— 外部反射式監督

架構類型： Out-of-band Reflective Runtime

核心理念：

「Rather than embedding self-repair logic within an agent's inference cycle, VIGIL persists as an external, introspective layer — detecting latent faults, identifying structural breakdowns, and proposing concrete fixes to prompt and code.」

翻譯：與其將自我修復邏輯嵌入 agent 推理循環，不如將其作為一個外部、獨立的反思層。

管線架構：

主 Agent（任務執行）
      ↓ 產生日誌
VIGIL Runtime（外部監督層，獨立 process）
      ↓ 讀取行為日誌
Emotional Bank（情感記憶庫，含時間衰減策略）
      ↓ 情緒化評估
RBT Diagnosis（Roses/Buds/Thorns 結構化診斷）
      ↓
Prompt Diff + Code Diff（生成修復建議，但不自動執行）

Stage-Gate 狀態機：

start → eb_updated → diagnosed → prompt_done → diff_done

非法狀態轉移直接報錯——不給 LLM 機會自行編排工具序列。

自我修復能力：

VIGIL 最具啟發性的一幕是：當它自己的診斷工具因 schema 不匹配而失敗時，VIGIL 自動檢測到這個內部錯誤，生成 fallback 診斷，並發出自身的修復計劃。

這展示了一種「meta-procedural self-repair」——連監督層本身都能被監督。這是目前文獻中少有的實例。

2.5 Planner-Executor-Verifier（Agent Patterns Catalog）—— 模式級抽象

架構類型： 設計模式（非特定實現）

核心約束：

「No plan step's effect is accepted without an independent verifier check; same-model self-verify is excluded.」

這可能是整個領域中最簡潔也最強硬的驗證規則。

與 Plan-Execute 的關鍵區別：

經典案例：

Plan: "Refactor module X"（12 步驟）
Step 4: rename function → Executor 執行 → Tool 回傳 success
PEV Verifier 檢查：
  - "Does the refactor still compile?"
  - "Do all callers still resolve?"
→ 發現 3 個 unresolved callers
→ Replan 觸發（call-site list 作為新約束）
→ 繼續執行修正後的 plan

無 PEV 的 Plan-Execute：
→ Executor 看到 step 4 success → 直接進入 step 5
→ step 12 才發現整個 refactor 有 3 個 broken callers
→ 需要回滾 8 個步驟

PEV 的洞察在於：tool-level success ≠ goal-level progress。 工具回傳成功，不等於計劃在前進。

2.6 ReVeal（ArXiv 2025）—— 強化學習驅動的生成-驗證

架構類型： Multi-turn RL with Execution Feedback

訓練管線：

獨特之處：

ReVeal 是唯一一個用 RL 訓練而非 prompt engineering 來解決驗證問題的方案。它讓同一模型同時學習「生成代碼」和「為代碼寫測試」的能力。

關鍵差異：驗證信號來自可執行的測試結果（hard signal），而非 LLM 的文字判斷（soft signal）。這從根本上避免了「模型自我合理化」的問題——代碼要麼通過測試，要麼不通過，沒有灰色地帶。

2.7 odot（Frobenius Condition）—— 數學保證的閉環

架構類型： 數學驗證閉環（Frobenius Condition）

核心機制：

THINK → ACT → OBSERVE（含強制驗證步驟 μ） → UPDATE

Frobenius Condition: μ(δ(query)) == query 必須成立
→ 成立（Frobenius CLOSED）：循環繼續
→ 不成立（Frobenius OPEN）：模型收到顯式失敗訊息，必須修正後重試，不可跳過

設計特點：

odot 在每次工具調用後立即插入一個強制驗證步驟。這個驗證不是 optional 的——如果 Frobenius Condition 不成立（μ(δ(q)) != q），循環不能前進。

這與 Claude Code 的 Stop Hook 在精神上一致：用數學/程式碼層面的強制取代 prompt 層面的建議。

odot 還支援 B4 Belnap FOUR 四值邏輯驗證：N（Neither）、T（True）、F（False）、B（Both/contradiction）。在 paraconsistent 邏輯中，B 不會導致爆炸——這使得 odot 能夠在面對矛盾資訊時優雅地繼續。

3. 橫向對比矩陣

4. 可借鑑的設計模式

4.1 Stop Hook 模式（借鑑 Claude Code）

在每個 loop 執行完成後、寫入最終結果前，強制執行一個外部檢查：

def stop_hook(loop_id, result):
    if not result.methodology_compliance.verify.done:
        return False, "VERIFY phase not executed"
    if result.methodology_compliance.verify.checker_session is None:
        return False, "No independent checker spawned"
    for alert in result.alerts:
        if alert.severity == "critical" and not alert.escalated:
            return False, f"Critical alert not escalated: {alert.message}"
    return True, ""

4.2 角色隔離模式（借鑑 MetaGPT）

將每個 loop 拆分為兩個獨立的 cron job：

Job A: loop-xxx-execute (looper agent)
  → Observe → Plan → Execute → 寫入 draft STATE.json

Job B: loop-xxx-verify (coder-deepseek agent)
  → 讀取 draft STATE.json → 獨立 Verify → 通過則 merge
  → 不通過 → 寫入 fix_instructions → 觸發 Job A retry

關鍵約束：looper 永遠不寫入最終 STATE.json——只有 coder-deepseek 的 verify 通過後才能寫入。

4.3 外部反射層模式（借鑑 VIGIL）

擴展現有的 score_enforcer.py 成為完整的外部監督層：

class LoopSupervisor:
    def scan_all_loops(self):
        for loop in get_active_loops():
            self.check_methodology_compliance(loop)
            self.check_omlx_l3(loop)
            self.check_escalation_compliance(loop)

    def check_methodology_compliance(self, loop):
        state = load_state(loop)
        score = state.methodology_compliance.compliance_score
        if score < 4:
            alert(f"Loop {loop} methodology score {score}/7 — possible skip")

5. 結論

5.1 核心發現

本文分析了七種 AI Agent 驗證架構方案，發現它們共享一個反覆出現的設計原則：

「執行者不能同時是裁判。」

• Claude Code 用 Stop Hook 確保外部檢查——不是 prompt 建議，是 turn 邊界上的硬閘門
• MetaGPT 用 QA Engineer 實現角色隔離——Engineer 不能驗證自己的代碼，QA 不能寫生產代碼
• VIGIL 用外部反射層監控主 Agent——連監督層本身的故障都能自我診斷
• PEV 模式明確禁止 same-model self-verify——沒有獨立 verifier 的步驟不被接受
• odot 用 Frobenius Condition 在數學層面強制閉環——不成立則循環不允許前進
• ReVeal 雖然用同一模型，但驗證信號來自可執行的測試而非文字判斷

純 prompt 層面的「自我檢查」——例如在 prompt 中寫「請自行驗證你的結果」——在所有對比中都被證明是不穩定的。

5.2 實戰驗證

我們在生產環境的 Loop Engineering 系統中驗證了這一結論：當驗證僅存在於 prompt 文字中時，agent 在連續 5 次執行中 100% 跳過了 verify 階段（0/5 spawn checker）。但當我們將 verify 機制嵌入到 cron 結構和 STATE.json 強制格式中後，合規率顯著改善。

5.3 四條建議

對於構建生產級 Agent 系統的團隊：

1. 永遠不要讓同一個 agent 自我驗證。 使用不同的 agent、不同的 model call、或外部 hook。Claude Code 和 MetaGPT 已經證明了這條規則的必要性。

2. 驗證信號應為 hard signal。 可執行的測試、數學等式（Frobenius Condition）、或結構化 schema 檢查優於 LLM 文字判斷。hard signal 沒有灰色地帶。

3. 強制性必須來自架構，不是 prompt。 Stop Hook、Stage Gate、Role Isolation、Frobenius Condition——這些都是 LLM 無法「合理化跳過」的機制。prompt 文字永遠可以被「重新理解」。

4. 外部監督層是長期最優解。 VIGIL 的 out-of-band reflective runtime 模式是目前最可擴展的方案——它不侵入現有 agent 邏輯，不消耗 context window，但提供獨立、持續的合規監控。我們的 score_enforcer.py 正在向這個方向演進。

本文基於 2026 年 6 月 14 日在君澤智庫生產環境中進行的 Loop Engineering 全面審計。所有程式碼引用均來自對應項目的公開原始碼或官方文件。特別感謝 DeepSeek 團隊提供的優秀模型——正是它的「失敗」讓我們得以深入研究這個領域的底層問題。