VerifyLoop：面向 Agent 的雙向持續驗證與糾錯協議

從生成式回答到可追蹤、可回溯、可修正的 Agent 工作流

作者：Neo.K 機構：EveMissLab / 一言諾科技有限公司 版本：Open Protocol Draft v0.1 類型：Agent 方法論 / 開源協議白皮書 / Reliability Layer / Trace-based Verification 日期：2026 7月

摘要

大型語言模型與 Agent 系統正在從「單次回答器」轉向「多步工作流執行器」。在這個轉換中，可靠性問題不再只是最後答案是否正確，而是整個 Agent 軌跡是否可追蹤、可回溯、可驗證、可修正。一次錯誤的計畫、一個不存在的檢索結果、一個被誤讀的工具回傳、一個未被標記的不確定推論，都可能沿著多步流程擴散，最終形成看似流暢但不可被信任的輸出。

本文提出 VerifyLoop：一套面向 Agent 工作流的雙向持續驗證與糾錯協議。VerifyLoop 不假設模型一次生成即可靠，而要求 Agent 對每次輸出保留任務鏈、推理鏈、證據鏈、工具鏈與版本鏈；並在輸出完成後，從結論反向檢查其必要前提、證據來源、工具記錄與任務目標是否一致。若正向生成鏈與反向驗證鏈不一致，系統不應直接輸出結論，而應標記 gap，分類錯誤來源，進入下一輪修正，或輸出「目前不可判定」。

VerifyLoop 的核心循環是：

Generate → Trace → Forward Check → Backward Check → Gap Diagnose → Correct → Version

本文將原始「雙向持續驗證糾錯系統」改寫為公開開源協議：不主張消除所有幻覺，不主張得到終極真理，而是提供一個可被不同 Agent 框架接入的可靠性層。它的目標是降低不可追蹤錯誤，提高輸出可審計性，讓 Agent 不只是會生成答案，也能留下自己如何抵達答案、哪些地方被驗證、哪些地方仍有缺口。

近期研究已顯示，Agent 幻覺與一般單輪回答幻覺不同，因為多步流程中的錯誤可能出現在 Planning、Retrieval、Reasoning、Human-Interaction、Tool-Use 等不同階段，且步驟級定位仍具挑戰；AgentHallu benchmark 報告的最佳模型步驟定位準確率仍有限，工具使用幻覺尤其難定位。這正好說明 Agent 可靠性需要工作流級 trace、gap attribution 與可審計驗證層。

關鍵詞

Agent、VerifyLoop、雙向驗證、持續糾錯、AI 幻覺、Agent 幻覺、RAG、Claim Verification、Tool Receipt、Trace-based Verification、Gap Diagnosis、Human-in-the-loop、Agent Reliability、開源協議

0. 開源定位聲明

0.1 本文是協議，不是封閉產品

VerifyLoop 不是單一產品，也不是特定模型、特定框架或特定供應商的功能。它是一個可以被不同 Agent 系統實作的工作流可靠性協議。

它可以被接入：

RAG 系統；
研究助理 Agent；
程式碼 Agent；
法律與政策分析 Agent；
資料分析 Agent；
瀏覽器操作 Agent；
知識庫維護 Agent；
多 Agent 協作系統。

VerifyLoop 的核心不是「讓模型變聰明」，而是讓 Agent 的輸出過程變得：

可追蹤；
可回溯；
可驗證；
可修正；
可版本化；
可審計。

0.2 本文不主張

本文不主張：

VerifyLoop 可以消除所有幻覺；
雙向驗證等於絕對真理；
Agent 可以完全不需要人類審查；
反向驗證一定正確；
多 Agent 檢查一定比單 Agent 可靠；
所有任務都值得高深度驗證；
所有知識都可以被完全形式化。

0.3 本文主張

本文主張：

Agent 的輸出應被視為一條可檢查的工作流，而不是孤立文字；
可靠性不只來自更大的模型，也來自更好的驗證結構；
正向生成與反向驗證可以互相暴露盲點；
工具調用、檢索結果與推理聲稱應被分離記錄；
當鏈條不能補完時，系統應輸出 gap，而不是假裝確定；
知識庫與 Agent 輸出應支援版本化更新。

1. 問題：Agent 不是一次回答器，而是多步工作流

傳統聊天機器人多半被理解為：

Prompt → Answer

但 Agent 系統更接近：

Task → Plan → Retrieve → Tool Use → Reason → Act → Observe → Revise → Answer

在這種多步流程中，錯誤可能出現在任何一個階段：

計畫錯誤：Agent 設定了錯誤任務分解；
檢索錯誤：Agent 找到不相關或過期資料；
推理錯誤：Agent 從正確資料推出錯誤結論；
工具錯誤：Agent 聲稱使用工具，但工具未回傳該結果；
互動錯誤：Agent 誤解使用者意圖；
合成錯誤：Agent 把局部成立的資訊寫成全局結論。

AgentHallu 的分類也指出，Agent 幻覺需要按照工作流中的不同階段定位，而不是只看最終答案。其 benchmark 將幻覺分為 Planning、Retrieval、Reasoning、Human-Interaction、Tool-Use 等類型，並要求找出 responsible step 與 causal explanation。

因此，Agent reliability 的關鍵問題不再是：

答案對不對？

而是：

這個答案是怎麼來的？
每一步是否有紀錄？
每個 claim 是否有 evidence？
工具聲稱是否有 receipt？
結論是否超出證據？
錯誤若發生，能否定位在哪一步？

這就是 VerifyLoop 的問題起點。

2. 從 Output-based AI 到 Trace-based Agent

2.1 Output-based AI 的限制

Output-based AI 只檢查最後輸出：

最後答案是否看起來合理；
語氣是否流暢；
格式是否符合需求；
引用是否存在；
結論是否有說服力。

但這種檢查很容易被流暢性欺騙。

一個答案可以語氣穩定、格式完整、推理看似自然，卻在中間某一步引用了錯誤資料、漏掉時間限定、虛構工具結果，或把推測寫成事實。

2.2 Trace-based Agent 的核心

Trace-based Agent 不只看最後答案，而是要求 Agent 留下工作軌跡：

Task Trace：任務如何被理解；
Plan Trace：任務如何被拆解；
Evidence Trace：使用了哪些資料；
Tool Trace：調用了哪些工具，工具實際回傳什麼；
Claim Trace：最後輸出包含哪些可驗證聲稱；
Reasoning Trace：哪些推論是由哪些資料支持；
Correction Trace：哪些地方被修正；
Version Trace：不同版本之間差異在哪裡。

這些 trace 不一定要暴露模型私有思維鏈。VerifyLoop 不要求公開模型內部 chain-of-thought。它要求的是可審計工作紀錄，包括任務分解、引用、工具回傳、claim/evidence 對應、gap 報告與版本差異。

2.3 Trace 不是裝飾，而是可靠性基礎

沒有 trace，就無法知道錯在哪裡。

有 trace，才能做到：

錯誤定位；
局部修正；
責任分配；
版本比較；
自動回歸測試；
人類審查；
知識庫更新。

因此，VerifyLoop 的第一原則是：

Agent 的輸出必須從「答案」升級為「答案 + 可審計軌跡」。

3. VerifyLoop 協議總覽

VerifyLoop 的基本循環如下：

1. Generate：生成初始答案或行動計畫
2. Trace：記錄任務、計畫、資料、工具、推理與輸出
3. Forward Check：檢查正向生成鏈是否連貫
4. Backward Check：從結論反推必要證據與前提
5. Gap Diagnose：定位不一致、跳步、缺證據或工具錯誤
6. Correct：自動修正、請求補資料、降級結論或交給人類
7. Version：保存修正後版本與差異

它可以被簡化為：

Answer is not final until it survives its own reverse check.

中文可表述為：

答案不能只被生成，還必須能從結論回扣到任務、證據與工具紀錄。

4. 正向鏈：Agent 如何產生答案

正向鏈描述 Agent 如何從任務走向輸出。

基本結構：

User Task
→ Task Interpretation
→ Plan
→ Retrieval / Tool Use
→ Intermediate Notes
→ Reasoning / Synthesis
→ Final Answer

每一步都應產生可紀錄節點。

4.1 正向鏈節點

forward_chain:
  - node_id: S0
    type: user_task
    content: "使用者原始需求"
  - node_id: S1
    type: task_interpretation
    content: "Agent 對任務的理解"
  - node_id: S2
    type: plan
    content: "要查什麼、要算什麼、要調用什麼工具"
  - node_id: S3
    type: retrieval
    content: "檢索到的資料與來源"
  - node_id: S4
    type: tool_call
    content: "工具調用與回傳"
  - node_id: S5
    type: synthesis
    content: "由資料到結論的合成"
  - node_id: S6
    type: final_answer
    content: "最後輸出"

4.2 正向檢查項目

正向檢查不是判斷答案最終真假，而是檢查流程是否基本連貫：

任務理解是否偏離使用者需求；
計畫是否覆蓋任務；
檢索是否真的支撐計畫；
工具回傳是否被正確讀取；
推理是否跳過必要中間步；
最後答案是否超出前面資料。

5. 反向鏈：答案需要什麼才能成立

反向鏈從最後答案出發，追問：

如果這個答案成立，它需要哪些前提？
如果這個 claim 成立，它需要哪些 evidence？
如果 Agent 聲稱用了工具，工具 receipt 是否存在？
如果結論包含比較，是否有完整比較集合？
如果結論包含時間判斷，時間限定是否明確？

反向鏈基本結構：

Final Answer
→ Claim Decomposition
→ Required Evidence
→ Evidence Availability
→ Tool Receipt Check
→ Task Alignment Check
→ Confidence / Gap Report

5.1 Claim Decomposition

最終答案必須拆成可驗證 claim。

例如：

「埃菲爾鐵塔建於 1889 年，高 324 米，曾是世界最高建築。」

可拆成：

claims:
  - claim_id: C1
    text: "埃菲爾鐵塔建於 1889 年"
    type: factual
  - claim_id: C2
    text: "埃菲爾鐵塔高度為 324 米"
    type: factual
  - claim_id: C3
    text: "埃菲爾鐵塔曾是世界最高建築"
    type: historical_comparison

若答案寫成：

「埃菲爾鐵塔是世界最高建築」

反向鏈會追問：

現在最高？
歷史上曾經最高？
比較集合是所有建築，還是當時建築？
資料時間點是何時？

這就是反向驗證的價值。

5.2 Evidence Requirement

每個 claim 都應標明需要哪種 evidence：

evidence_requirements:
  C1:
    required: ["historical_source"]
  C2:
    required: ["official_measurement_or_reliable_reference"]
  C3:
    required: ["historical_height_ranking", "time_range"]

5.3 Tool Receipt Check

如果 Agent 聲稱「我查詢了資料庫」「我讀取了檔案」「我執行了程式」，系統應檢查工具紀錄是否存在。

近年的 tool receipt 研究提出，Agent 可對工具執行產生不可由 LLM 偽造的簽名收據，再把 LLM 的聲稱與工具收據交叉檢查，以即時偵測虛構工具調用、錯報數量或把推論寫成事實等問題。

VerifyLoop 可將這個方向吸收為：

No tool claim without tool receipt.

中文：

沒有工具收據，就不能聲稱工具已經支持該結論。

6. 雙向一致性：Forward Chain 與 Backward Chain 的對接

VerifyLoop 不要求正向鏈與反向鏈字面相同，而要求它們在關鍵結構上相容。

6.1 一致性檢查項目

Claim 是否能在正向鏈中找到來源；
Evidence 是否真的支持 claim；
Tool receipt 是否支持 Agent 的工具聲稱；
反向鏈要求的前提是否在正向鏈中出現；
最後答案是否引入了正向鏈沒有的外部假設；
是否存在循環論證；
是否存在結論強度超出證據強度。

6.2 一致性分數

VerifyLoop 可輸出一個非絕對的 verification score：

verification_score:
  overall: 0.82
  task_alignment: 0.95
  claim_support: 0.80
  evidence_quality: 0.76
  tool_receipt_integrity: 1.00
  contradiction_check: 0.70
  uncertainty_handling: 0.85

這個分數不是「真理分數」，而是「目前 trace 下的可支持程度」。

7. Gap 三分法

當正向鏈與反向鏈不一致時，VerifyLoop 不應只說「錯了」，而應輸出 gap 類型。

7.1 Technical Gap

技術性斷鏈：

資料存在；
規則存在；
工具可用；
但 Agent 沒有查到、沒展開、沒引用、沒算完，或推理跳太快。

處理方式：

加深檢索；
展開中間步；
重新調用工具；
補充引理；
增加 claim-level verification；
生成更詳細版本。

7.2 Systemic Gap

系統性斷鏈：

目前知識庫、工具、規則或任務設定不足以支持結論。

例子：

缺少即時資料；
缺少專業資料庫；
任務需要法律判斷但無司法管轄區；
任務需要實驗結果但目前沒有實驗；
Agent 缺少可執行工具。

處理方式：

請求新工具；
請求人類提供資料；
降低結論強度；
改成假設性回答；
輸出需要外部驗證。

7.3 Undecidable Gap

不可判定斷鏈：

在目前資料、工具與規則下，不能可靠回答。

處理方式：

明確輸出不確定；
列出需要哪些資料才能回答；
避免假裝知道；
避免用流暢語氣掩蓋不可判定。

這是 VerifyLoop 的重要倫理點：

不可判定不是失敗。把不可判定說成確定，才是失敗。

8. 驗證深度 D

VerifyLoop 使用「驗證深度」表示不同任務需要不同程度的檢查。

8.1 深度分級

D0：直接回答，不做額外驗證。
D1：基本自我一致性檢查。
D2：檢索佐證，補來源。
D3：拆成原子 claim，逐條驗證。
D4：多 Agent 或多路徑交叉驗證。
D5：工具 receipt + 版本紀錄 + 人類審查。

8.2 深度選擇原則

低風險、日常任務：D0-D1；
一般資訊查詢：D2；
研究、政策、法律、金融、醫療、工程：D3-D5；
高風險自動化執行：至少 D4，最好 D5；
不可逆行動：必須人類審查。

8.3 驗證深度不是越高越好

高驗證深度需要成本：

更多 token；
更多工具調用；
更多延遲；
更多工程複雜度；
更高假陽性可能；
更多人類審查成本。

因此 VerifyLoop 不追求所有任務都最大驗證，而是追求：

任務風險 × 證據需求 × 成本限制

之間的動態平衡。

9. 系統模組設計

VerifyLoop 可拆成以下模組。

9.1 Trace Logger

紀錄整個 Agent 工作流。

trace:
  trace_id: "vl_2026_0001"
  task_id: "task_001"
  agent_id: "agent_research_assistant"
  timestamp: "2026-07-01T00:00:00+08:00"
  steps:
    - step_id: S0
      type: user_task
      content: "..."
    - step_id: S1
      type: plan
      content: "..."
    - step_id: S2
      type: retrieval
      source_refs: ["src_001", "src_002"]
    - step_id: S3
      type: tool_call
      tool_receipt_id: "receipt_001"
    - step_id: S4
      type: synthesis
      content: "..."

9.2 Claim Decomposer

把輸出拆成可驗證聲稱。

claim:
  claim_id: C001
  text: "..."
  type: factual | comparative | causal | predictive | normative | speculative
  required_evidence:
    - source
    - tool_receipt
    - calculation
  risk_level: low | medium | high

9.3 Evidence Retriever

為每個 claim 尋找 evidence。

evidence:
  evidence_id: E001
  claim_id: C001
  source_type: document | web | database | tool_output | user_provided
  content_summary: "..."
  freshness: "current | stale | unknown"
  supports_claim: true
  confidence: 0.78

9.4 Tool Receipt Verifier

檢查工具聲稱是否被真實工具紀錄支持。

tool_receipt:
  receipt_id: R001
  tool_name: "calculator"
  input_hash: "..."
  output_hash: "..."
  timestamp: "..."
  signed: true
  verified: true

9.5 Backward Verifier

從 claim 反推其必要支持條件。

backward_check:
  claim_id: C001
  required_conditions:
    - "需要來源 A"
    - "需要時間限定"
    - "需要比較集合"
  matched_conditions:
    - "來源 A 已存在"
  missing_conditions:
    - "缺少比較集合"
  status: partial

9.6 Gap Classifier

分類 gap。

gap:
  gap_id: G001
  claim_id: C001
  location: "final_answer.paragraph_2"
  type: technical | systemic | undecidable
  severity: low | medium | high
  explanation: "缺少支持該比較結論的完整排名資料"
  recommended_action: "retrieve_additional_evidence"

9.7 Correction Engine

根據 gap 類型採取修正。

Technical Gap → 補資料、補步驟、重跑工具。
Systemic Gap → 請求人類、要求新工具、降低結論。
Undecidable Gap → 明確輸出不確定。

9.8 Version Manager

保存版本差異。

version:
  version_id: V002
  parent_version: V001
  changes:
    - "將『是世界最高建築』改為『1889-1930 年曾為世界最高建築』"
    - "新增哈里發塔比較資料"
  verification_score_before: 0.42
  verification_score_after: 0.91

10. VerifyLoop JSON 規格草案

10.1 最小輸出格式

{
  "answer": "...",
  "verifyloop": {
    "trace_id": "vl_001",
    "verification_depth": "D3",
    "claims": [],
    "evidence": [],
    "tool_receipts": [],
    "gaps": [],
    "verification_score": {
      "overall": 0.0
    },
    "status": "verified | partial | corrected | uncertain | failed"
  }
}

10.2 Gap Report 格式

{
  "gap_id": "G001",
  "type": "technical",
  "severity": "medium",
  "location": {
    "claim_id": "C003",
    "answer_span": "paragraph_2_sentence_1"
  },
  "description": "The claim requires a time-bounded comparison but no comparison set was retrieved.",
  "required_action": "retrieve_comparison_data",
  "auto_correctable": true
}

10.3 Verification Report 格式

{
  "trace_id": "vl_001",
  "status": "corrected",
  "depth": "D3",
  "summary": "3 claims verified, 1 corrected, 0 unresolved.",
  "claim_results": [
    {
      "claim_id": "C001",
      "status": "supported",
      "confidence": 0.92
    },
    {
      "claim_id": "C002",
      "status": "corrected",
      "confidence": 0.88,
      "correction": "Added historical time range."
    }
  ],
  "remaining_gaps": []
}

11. 典型工作流

11.1 RAG 回答驗證

1. 使用者提問；
2. Agent 檢索資料；
3. Agent 生成答案；
4. VerifyLoop 拆解 claim；
5. 每個 claim 對應 retrieval evidence；
6. 若 claim 無 evidence，標記 gap；
7. 若 evidence 矛盾，要求重新生成；
8. 輸出答案 + verification report。

MARCH 這類多 Agent 自檢框架已開始採用 claim-level decomposition 與資訊隔離檢查：Solver 先生成答案，Proposer 將回答拆成可驗證原子命題，Checker 在不看原始答案的情況下對 retrieved evidence 驗證，以降低 self-confirmation bias。VerifyLoop 可吸收這個精神，但把它一般化為開源 Agent 協議。

11.2 工具型 Agent 驗證

1. Agent 宣稱已查詢資料庫；
2. VerifyLoop 檢查 tool receipt；
3. 若沒有 receipt，禁止把結果寫成工具支持事實；
4. 若 receipt 存在，檢查輸出數值是否被正確引用；
5. 若 Agent 把推論寫成工具結果，標記 tool-use hallucination。

11.3 研究助理 Agent

1. 輸入研究問題；
2. Agent 建立初步文獻地圖；
3. VerifyLoop 將每個研究主張拆成 claim；
4. 對每個 claim 檢查引用、年份、研究限制；
5. 對過時或未驗證 claim 加上 uncertainty label；
6. 生成可審計研究摘要。

11.4 知識庫批量更新

1. 將既有文件拆成段落與 claim；
2. 為每個 claim 建立 evidence requirement；
3. 批量檢索或讀取來源；
4. 標記 supported / contradicted / stale / uncertain；
5. 自動提出修正草稿；
6. 保存版本差異；
7. 人類審查高風險修改。

12. 與既有研究的關係

12.1 Agent 幻覺歸因

AgentHallu 的研究方向說明，Agent 幻覺不應只在最終輸出層面處理，而應定位到多步軌跡中的 responsible step。VerifyLoop 的 Trace Logger、Gap Classifier 與 Backward Verifier 正是面向這類 step-level attribution 的協議化實作。

12.2 多 Agent 自檢

MARCH 顯示，多 Agent 分工、自我檢查與資訊隔離可以降低 verifier 的 confirmation bias。VerifyLoop 不限定一定要多 Agent，但在 D4 以上的驗證深度中，建議使用多 Agent 或多路徑檢查。

12.3 Tool Receipt

NabaOS / tool receipt 方向指出，互動式 Agent 不一定適合用高成本密碼學證明；較輕量的 tool execution receipt 加 claim cross-check 可能更實用。VerifyLoop 將 tool receipt 視為 Tool Trace 的關鍵證據層。

12.4 Agent 幻覺 Survey

LLM-based agents 的幻覺 survey 已整理出 agent workflow 中不同階段可能出現的幻覺與對應緩解方法，並指出多步代理系統的幻覺偵測與緩解是重要研究方向。VerifyLoop 可被視為一種 workflow-level mitigation protocol。

12.5 Embodied Agent 與不可行任務

具身 Agent 的幻覺研究也顯示，當任務與環境不一致時，Agent 可能仍嘗試執行不可能任務，而不是明確指出不可行。VerifyLoop 的 Undecidable / Systemic Gap 分類可用來要求 Agent 在任務不可行時輸出邊界，而不是繼續行動。

13. 開源實作路線

13.1 Repository 建議結構

verifyloop-agent/
  README.md
  LICENSE
  docs/
    protocol.md
    schemas.md
    examples.md
  schemas/
    trace.schema.json
    claim.schema.json
    evidence.schema.json
    tool_receipt.schema.json
    gap_report.schema.json
    verification_report.schema.json
  verifyloop/
    trace_logger.py
    claim_decomposer.py
    evidence_checker.py
    backward_verifier.py
    gap_classifier.py
    correction_engine.py
    version_manager.py
  examples/
    rag_verification/
    tool_receipt_check/
    knowledge_base_update/
    research_assistant/
  tests/
    test_gap_classifier.py
    test_claim_decomposer.py
    test_receipt_verifier.py

13.2 MVP 模組

第一版不需要做太大。MVP 只需要：

輸入：Agent final answer + retrieval sources + optional tool logs
輸出：
1. claim list
2. evidence mapping
3. unsupported claims
4. contradiction warnings
5. gap report
6. corrected draft

13.3 Minimal API

from verifyloop import VerifyLoop

vl = VerifyLoop(depth="D3")

report = vl.verify(
    task=user_task,
    answer=agent_answer,
    sources=retrieved_sources,
    tool_logs=tool_logs
)

print(report.status)
print(report.gaps)
print(report.corrected_answer)

13.4 Integration Target

LangChain / LangGraph；
LlamaIndex；
AutoGen；
CrewAI；
OpenAI-compatible tool-calling agents；
自製本地 Agent；
知識庫批量處理 pipeline。

14. 限制

14.1 VerifyLoop 不能保證終極正確

VerifyLoop 只能提高可追蹤性與可驗證性，不能保證所有結論絕對正確。

原因包括：

知識庫可能錯；
資料可能過時；
檢索可能漏掉關鍵來源；
反向驗證器也可能推理錯；
多 Agent 可能共享同一偏差；
工具 receipt 只能證明工具回傳，不等於工具回傳本身正確；
高風險領域仍需專家審查。

14.2 Trace 不是私有思維鏈

VerifyLoop 不要求暴露模型私有 chain-of-thought。

它要求的是：

任務紀錄；
工具紀錄；
資料紀錄；
claim/evidence 對應；
gap 報告；
版本差異。

這些是可審計工作產物，不是模型內部思考逐字稿。

14.3 高驗證深度有成本

VerifyLoop 必須允許不同模式：

Fast Mode：快速、不完全驗證；
Standard Mode：基本檢索與 claim check；
Strict Mode：逐 claim 驗證與 tool receipt；
Audit Mode：多 Agent + 人類審查 + 版本化。

15. 結論：Agent 的下一步不是更會生成，而是更會驗證

生成能力已經足夠強。問題是：生成之後，誰來檢查？如何檢查？錯在哪裡？怎麼修正？如何避免同一錯誤在下一輪再次出現？

VerifyLoop 的答案是：

不要只看答案。
看 trace。

不要只做正向生成。
做反向驗證。

不要只說錯了。
定位 gap。

不要只修一次。
保留版本，持續修正。

不要假裝確定。
在不可判定時輸出不可判定。

VerifyLoop 的核心並不是讓 Agent 永不犯錯，而是讓錯誤變得可見、可定位、可修正、可累積學習。

Agent 的下一階段，不只是更強的生成，而是更可靠的工作流。

一句話總結：

VerifyLoop 是一套開源 Agent 驗證協議：它要求 Agent 不只生成答案，還要留下正向生成鏈、反向驗證鏈、證據紀錄、工具紀錄與 gap 診斷，並在不一致時進入持續修正循環。

附錄 A：術語表

附錄 B：狀態碼

VERIFIED：所有主要 claim 已被支持。
PARTIAL：部分 claim 被支持，部分仍有 gap。
CORRECTED：原答案已被修正。
UNCERTAIN：目前資料不足，無法可靠回答。
FAILED：驗證失敗，答案不應輸出。
HUMAN_REVIEW_REQUIRED：需要人類審查。

附錄 C：最小 Gap 分類器邏輯

def classify_gap(claim, evidence, tool_receipts, task_context):
    if claim.requires_tool and not tool_receipts.exists_for(claim):
        return "technical", "Missing tool receipt"

    if claim.requires_current_data and not evidence.has_current_source():
        return "systemic", "Current data unavailable"

    if evidence.contradicts(claim):
        return "technical", "Contradicted by retrieved evidence"

    if claim.is_high_risk and evidence.is_insufficient():
        return "undecidable", "Insufficient evidence for high-risk claim"

    if claim.exceeds_task_scope(task_context):
        return "technical", "Conclusion exceeds task scope"

    return "supported", "No obvious gap"

附錄 D：README 短版

# VerifyLoop Agent Protocol

VerifyLoop is an open protocol for trace-based verification of LLM agents.

It turns an agent answer into:

- forward chain
- backward verification chain
- claim list
- evidence map
- tool receipt check
- gap report
- corrected version

Core loop:

Generate → Trace → Forward Check → Backward Check → Gap Diagnose → Correct → Version

VerifyLoop does not guarantee absolute truth.
It improves auditability, error localization, and iterative correction.

附錄 E：公開版邊界聲明

本文由內部理論「萬物雙向持續驗證糾錯系統」降維改寫而來。原始版本包含更強的知識演化、本體論與算力深度敘述；公開版刻意將其改寫為 Agent 協議與開源方法論。本文不主張真理可被完全驗證，而主張 Agent 的輸出應具有可審計軌跡、雙向檢查與持續修正能力。

全文完。