交接卡之後的兩個問題：承諾有沒有兌現、記的東西還對不對

今天我把半年來的 side projects 收斂成一個入口：agent-continuity-stack。五個等級，從零依賴的交接卡到組織級治理。開這個 repo 的原因很簡單——過去有七個 repo 各講各的故事，連我自己都很難一句話回答「所以該裝哪個」。

這半年社群對抗 AI 失憶的主流答案是交接卡：收工前把「做到哪、下一步是什麼」寫進檔案，新對話開場讀卡接手。這個方向是對的，我的 Tier 0 也是這個形態。交接卡把「上次做到哪」解掉之後，真正難的兩個問題才浮現。

問題一：承諾有沒有兌現

交接卡是快照。它記得「下一步是修 auth bug」，但它不記得這件事已經被推遲了三次、第一次出現是六月十號。Agent 每個 session 都誠實地把「下一步」抄進新的交接卡，然後誠實地繼續不做。

快照不會揭穿這件事，帳本才會。

我在 AMH（agent-memory-hall） 裡把這層叫 Baton：open_loops 記「說要做卻沒做的事」、follow_ups 記延宕次數和首見日期、active_decisions 記「當時為什麼選 A 不選 B」、patterns 記重複犯的錯。下個 session /start 時，agent 收到的不是「上次做到哪」，是「你承諾過修 auth bug，已經推遲兩次了」。

在我目前的調研範圍內，把承諾追蹤做成可查詢結構的工具仍屬少見。這不是因為難，是因為交接卡的體驗太順了，順到大家以為問題已經解完。

問題二：記的東西還對不對

交接卡的隱含假設是「訊息不失真就好」。但工程上「不失真」只保證傳輸，不保證時效。

假設交接卡寫著「測試用 Jest」，三週後專案換到 Vitest。開場讀卡會忠實地把這條過期結論帶進每一個新對話——越忠實，越錯。記憶不失真，反而成了缺陷。

所以失憶的解法不是把記憶存下來，而是治理記憶的生命週期。memcite 做的就是這層：每條記憶強制附引用來源，來源檔案變了就標 stale，CI 裡跑 am validate 把過期記憶當測試失敗處理。像對 agent context 寫單元測試。

順帶一提，「存下來」這件事本身也比看起來難。AI 回報「存好了」不等於真的存好了——寫入會靜默失敗。這週我把 write-then-read-back 加進了 AMH 的 /save：寫入後重開連線、用 row id 回讀、比對 hash，失敗就 exit 1。快照層都該有這個保險。

該裝哪個

一句話版本：交接卡解決「上次做到哪」；Baton 解決「承諾有沒有兌現」；memcite 解決「記的東西還對不對」。

由淺至深五級（統一入口：agent-continuity-stack），從哪裡痛就從哪裡進場，資料一路帶著走（SQLite 格式直接 import 進 server）：

• Tier 0：純交接卡 skills（零依賴，含寫入回讀驗證），三分鐘裝完
• Tier 1：AMH——加上 Baton 承諾追蹤
• Tier 2：pip install memcite——記憶正確性進 CI
• Tier 3：memory-hall server——語意搜尋與 team 共用
• Tier 4：ACP + ACA——多 agent 註冊、稽核與一致性規格

還沒做好的部分

寫到這裡必須誠實。入口收斂是這週才還的債，Tier 0 的獨立打包還在整理。另外 ACA Layer 4 的「資源政策」——派工前挑模型、控 scope、管配額——目前只有 spec 和權限模組，還沒有能跑的 gate；這是下一個要補的洞，補完之前我不會宣稱它已經 enforced。

這一輪 agent 記憶賽道，拼的不是誰先把東西存下來，是誰能把「兌現」和「過期」做成可驗證的 contract。

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