Agent 記憶的問題不是記得更多，是誰有權把它變成真相

我這兩天把家裡 multi-agent 的記憶操作手冊定成 FINAL。

文件名很長：CHAIR-MEMORY-PROTOCOL-v.20260726-FINAL。聽起來像憲法，內容其實比較像施工規範：誰能讀什麼、誰能寫什麼、什麼可以升格、什麼只能提名。

這篇不是產品發表。是我對一個反覆出現的故障模式，終於願意寫死邊界。

故障模式長什麼樣

多個 agent 協作時，記憶層最常見的失敗不是「查不到」。

是查到了，但把錯的東西當現在狀態。

典型劇本有兩種：

1. relevance search 當 handoff
   Session 開場用語意搜尋，拿第一名當「上次做到哪」。那筆可能是三週前的 lesson，分數高、時間舊。Agent 接錯棒，還寫得很有自信。

2. Chair 口述升格
   某個 agent 在 briefing 裡寫「我們已經定案 X」。下游當真相用。過兩天你發現：那只是當輪推論，從沒進 wiki，也沒人 ratify。

這兩件事疊起來，系統會產生一種很危險的感覺：每個人都記得很多，但沒有人能回答「現在什麼被視為真實」。

所以我後來換問題。

不是「怎麼讓 agent 記得更多」。
是「什麼層級的東西，才有資格被當成真相使用」。

四層，不是架構圖，是回答類型

我把工作記憶收成四層。重點不在名詞漂亮，在每一層只能回答一類問題：

這跟「向量庫 + 摘要」不是同一種切法。

向量庫解決的是 retrieval。
四層解決的是 authority：誰說了算、衝突怎麼裁、升格要不要人點頭。

幾個硬規則我寫死了：

• handoff 用 latest，不是 search
  接續工作先看時間序最新的 [state] / [wrap-up] / [handoff]。search 只拿來補歷史，不能當現在狀態。
• L3 不可用時，不得用 L2 冒充
  可以報情節與推論，但必須標層級。K unavailable 比「好像記得有定案」誠實。
• 公司與家庭分域
  不同 L2 / L3 入口。禁止只寫「memhall」不標 domain；禁止跨域物化。

L2 我仍走 AMH（Agent Memory Hall）當合法入口，不讓 agent 直接打 backend 當旁路。Governance 不在有沒有 HTTP API，在有沒有 namespace isolation、dedup、audit。

Chair 可以整理，不能 ratify

文件裡最重要的一句，可能是角色表。

我把「Chair」拆成三種：

• System Chair：跨 session / 跨 domain 的物化與提名；目前預設 Claude，候補 Codex
• Session Chair：當下開 session 的 agent，管本場 L1 與合法範圍內的 L2
• Seat：Council 被委派的 agent，只信有層標籤的引用，answer 一律是 L1 candidate

Grok 預設是 Session Chair / Seat，不授 System Chair。Gemini 不授。
Maki 才是唯一 ratify owner。

這不是儀式感。是我吃過的虧：當同一個 agent 既規劃、又執行、又幫自己寫「已定案」，記憶層會變成自證系統。

升格路徑也收斂：

• L1 → L2：四問全過才寫（未來用得到？有 evidence？不是暫時敘述？安全？）
• L2 → L3：目前只開 stale-fact 人工提名；「被用過很多次所以升格」這條路先停，等 measurement schema（我叫它 Study 0）
• L3 → L4：至少 3 次有效 repeated-reminder，還要 full-council 的 structured dissent，才進 ratify

自動 promotion runtime 這版不解凍。
FINAL 也不等於自動改全域 instruction。分發是另一個治理動作。

我寧願慢一層，也不要系統自己把推論寫成憲法。

物化不是摘要，是可稽核視圖

Council 場景裡，System Chair 不能把「我讀過的四層狀態」整包塞給 Seat。

改成三本 ledger：

• A：本次任務相關的人類原話（可截斷，不可改寫中段）
• B：帶層標籤的引用式事實（上限 10 條）
• C：排除索引——相關但未物化的 id 與原因

Seat 缺記憶時發 MEMORY REQUEST，同輪可標 MEMORY PENDING，做完不依賴該記憶的部分。
禁止用推論補洞。

這聽起來囉嗦。但 multi-agent 最貴的錯誤，往往是「Chair 覺得大家都知道了」。

這版我故意沒做完的事

寫 FINAL 很容易讓人以為系統完整。我不想製造那種幻覺。

目前明確未解凍：

• repeated adoption 的 N 與正式 measurement schema
• L4 降級週期
• OPEN-LOOPS archive migration
• 自動 promotion / demotion runtime
• 全域 instruction 自動分發

OPEN-LOOPS 仍是進行中工作的 push authority；L2 state 只存短摘要與 pointer。
兩者雙寫可能漂移——我知道，短期靠 wrap-up diff，不先上 daemon。

我方會輸的地方也很清楚：
這套依賴 System Chair 在線代查 L2，Chair 不可用時 Seat 會卡。
月度 audit 仍靠人工抽樣，不是機械保證。
對一人 chatbot 或單 agent 快修，儀式過重——solo / fast-path 不強制跑完整 Council 物化。

它服務的是：N 個 agent、跨 session、需要可接手、需要可反駁的工作站。
不是每個 prompt 都該進這套。

我真正在鎖定的

如果只留一句：

記憶系統的產品問題，常常被寫成 retrieval 問題。
多 agent 場景裡，它先是 authority 與升格問題。

誰能寫 L2、誰能提名 L3、誰能改 L4、衝突時誰贏、開場先讀 latest 還是 search——這些比 embedding 模型選哪個更早決定系統會不會騙你。

今天這份 FINAL 定的，就是這些邊界。
下一個 session 起，家裡的 agent 開場要 follow 它。

不是因為文件完美。
是因為沒有邊界的記憶，只會越記越像真相。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。