我的 AI Agent 把自己的幻覺當事實引用 — 以及我如何用 8 行設定檔防止它

我跑了一套多 Agent 協作系統，Claude、Codex、Gemini、Grok 四個 AI Agent 分工合作處理軟體工程任務。某天，我發現了一件令人不安的事。

某個 Agent 寫了一筆「事實」到我們的共享記憶裡：

API 速率限制應設為每分鐘每用戶 100 次請求。

沒有來源。沒有證據。只是一個 LLM 的推測，卻被存成了 fact。

兩小時後，另一個 Agent 讀取了這筆記憶，把它當成修改 production 設定的依據，然後寫了一筆新記憶：

API 速率限制確認為 100 req/min/user — 依據現有系統文件。

它把第一個 Agent 的猜測引用為「現有文件」。幻覺被洗白成了可信事實。

這就是 Ouroboros Effect — 當 LLM 的產出被回饋為 LLM 的輸入，每一輪都疊加一層虛假的信心，直到沒有人能追溯什麼是真的。

沒有人在談論的問題

AI Agent 生態圈痴迷於能力 — 工具呼叫（MCP）、Agent 間通訊（A2A）、記憶系統（Mem0、Zep、LangGraph）。但沒有人在問治理問題：

• 誰寫了這筆記憶？
• 它從哪來？
• 我們能信任它嗎？
• 有人審查過嗎？
• 它被改過嗎？被誰改的？

每個 Agent 框架給你的 MemorySaver 本質上就是一個沒有任何意見的 key-value store。什麼都能寫、什麼都能讀。沒有 audit trail、沒有溯源、沒有信任等級。

這就像建了一套金融系統，任何人都能修改帳本，而且沒有人記帳。

當我加上治理之後

我建了 ACA — Agent Cognition Architecture 來解決這個問題。改變是這樣的：

Before（普通記憶存儲）

{
  "id": "mem-003",
  "content": "API 速率限制應為 100 req/min",
  "created_at": "2026-06-11"
}

就這樣。沒有 metadata、沒有歷史、無法分辨這是人類指令還是 LLM 的猜測。

After（ACA 治理記憶）

{
  "memory_id": "mem-003",
  "content": "API 速率限制應為 100 req/min",
  "source": {
    "tier": "raw_source",
    "type": "agent",
    "ref": "codex-analysis-20260611"
  },
  "status": "superseded",
  "provenance_chain": {
    "transitions": [
      { "type": "supersede", "tier_before": "raw_source", "tier_after": "llm_derived" },
      { "type": "tier_upgrade", "tier_before": "llm_derived", "tier_after": "human_confirmed" }
    ]
  }
}

現在我可以看到：這筆記憶最初是 Agent 的原始推測（raw_source），被另一個 Agent 審查更新為 llm_derived，最後由人類附上證據確認為 human_confirmed。完整的鏈路可追溯。原始的猜測仍然保留，標記為 superseded — 不是刪除。

防止 Ouroboros 的 8 行設定

{
  "store": "sqlite",
  "governance": {
    "dedup": true,
    "anti_ouroboros": true,
    "namespace_isolation": true,
    "write_gate": true
  }
}

這是 ~/.amh/config.json。當 anti_ouroboros 開啟時，系統強制執行：

1. Source tier 追蹤：每筆記憶都被標記為 raw_source、llm_derived 或 human_confirmed
2. 禁止循環回饋：llm_derived 記憶不能作為來源再產生另一筆 llm_derived 記憶，中間必須有人類審查
3. 溯源鏈：每次修改都被記錄 — 誰改了什麼、什麼時候、為什麼

Ouroboros Effect 被終結了，因為系統不允許 LLM 把另一個 LLM 的產出當成事實來源。

讓治理看得見

規則只有在違規可見時才有用。這就是為什麼我建了 ACA Inspector — 一個讓治理變得有形的 Web UI。

一個頁面就能看到任何決策的完整故事：

[權限]        → [決策 + 審查]       → [溯源 DAG]      → [稽核軌跡]
 誰能做什麼？    提案了什麼？           證據從哪來？        發生了什麼？
 有什麼限制？    誰反對？為什麼批准？                       什麼時候？

當我的 Agent 提案「允許從 LLM 推導的記憶自動修改 production 限制」時，Inspector 讓我看到：

• Codex 反對：「這繞過了核心治理原則。信心 ≠ 正確性。」
• Gemini 有條件同意：「只允許營運類限制，並加上 24 小時冷卻期。」
• 我批准了 Gemini 的方案，同時納入了 Codex 關於「信心 vs 正確性」的擔憂。

全部在一個畫面上可見。不是埋在 log 裡、不是散落在聊天記錄中。可見。

Agent 治理的 eslint

除了視覺化，我還需要自動偵測。ACA Incident Analyzer 掃描你的記憶存儲，偵測 8 種治理違規：

import { analyzeIncidents } from "@chibakuma/aca-incident-analyzer";

const report = analyzeIncidents({ memories, auditEvents, decisions });
// { critical: 0, high: 1, medium: 0, low: 0, total: 1 }

把它想成對你 Agent 的行為跑 eslint，而不是對程式碼。

即插即用，不用重寫

ACA 是 protocol，不是 framework。它接入你已經在用的東西：

• LangGraph.js：npm install @chibakuma/aca-langgraph — 替換 checkpointer，每次 state 變更自動帶治理
• CrewAI：原生支援 MCP — 零 adapter 直接連 AMH server
• 所有 MCP client：Claude Desktop、Cursor、Codex — 加一行 MCP config 就好

npx @chibakuma/agent-memory-hall

一行指令。你的 Agent 記憶現在有了 source tier、provenance chain 和 audit trail。

驗證你的實作

如果你在建 ACA 相容的系統，可以驗證：

npx @chibakuma/aca-certification --store sqlite --path ./my-agent.db

✅ L1: Memory Schema (100%)
✅ L2: Governance Policies (100%)
✅ L3: Trust & Provenance (100%)
✅ L4: Audit Trail (100%)
✅ L5: Decision Governance (100%)
Result: ACA Full Stack Conformant

三個認證等級，像 Kubernetes 或 OAuth 一樣：Layer 1、Layer 1-3、或 Full Stack Conformant。

為什麼是現在

每週都有新的 AI Agent 框架發布。它們在能力上競爭 — 更多工具、更快推論、更長上下文。但沒有一個在回答最終會影響生產環境的問題：

「Agent 為什麼做了這件事，我們應該信任它嗎？」

Ouroboros Effect 不是理論問題。我在自己的系統裡親手抓到過。如果你在跑多 Agent 工作流並共享記憶，你很可能已經在經歷它了 — 你只是還看不見而已。

ACA 讓它可見。然後可驗證。然後可預防。

連結：

• GitHub: MakiDevelop/agent-memory-hall
• npm: @chibakuma/agent-memory-hall
• ACA Spec: Agent Civilization Architecture
• Inspector: npx @chibakuma/agent-memory-hall inspector

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。