同步台帳的損壞是無聲的。資料庫說有 763 筆。我們不再相信它，用瀏覽器逐一登入 21 個 AI 平台，在頁面內呼叫各平台自己的 API，按 ID 逐筆比對——真實存在的約 400 筆。
這是那道缺口的稽核紀錄。數字來自 2026-08-18 對真實帳號的量測，沒有任何假設。
對象是從一個實際使用的帳號裡蒐集的 AI 代理資產台帳，共 763 列——對話、專案、技能、指令檔案、記憶，橫跨 Claude、ChatGPT、Gemini、Grok、Perplexity、Kimi、Qwen 等 21 個平台。
驗證方法比工具更重要，先寫方法。
fetch（credentials: 'include'）呼叫該平台自己的清單 API，分頁翻到底數量一致，內容仍可能是兩份不同的清單。只有 ID 差分能告訴你那裡到底有什麼。
763 與 400 之間的差距不是一個 bug，而是三種相互獨立的故障模式，每一種在儀表板上都顯得一切正常。
| 故障模式 | 發生了什麼 | 確認列數 |
|---|---|---|
| 幽靈 | 平台上已刪除，台帳裡還活著 | 至少 173 |
| 漏採 | 平台上存在，卻從未進入台帳 | 至少 63 |
| 誤報 | 平台發給所有人的預設內容被當成使用者資產 | 至少 109 |
注意這個結構：幽靈和誤報把台帳吹大，漏採把它縮小，兩者部分抵消。所以總數是唯一保證能把三種故障全部藏起來的指標。
分頁上限變成了數量。 某平台的技能欄在台帳裡是 100 筆。使用者實際安裝的是 4 筆。其餘 96 筆是平台向所有使用者展示的公共目錄，而「100」這個數字本身，就是清單 API 的 page_size 上限被原樣記成了帳號的事實。
設定頁的範例文字變成了記憶。 使用者實際儲存了 8 筆資訊，蒐集器一筆都沒拿到，反而把設定頁預留文字（「例：……」兩行）當成使用者資料存了進去。只看台帳，這個格子像是正常運作的那一類。
從未存在過的檔案佔了 42 列。 42 列指令檔案指向的本機規則目錄，在這台機器上根本不存在。不是被刪了，是從來就沒有過。蒐集器照樣寫下了 42 列。
以上每一列，都是由回報了成功的工作寫入的。這才是重點。
不是改良蒐集器，而是把回讀稽核（read-back audit）變成一等操作：每次同步後重新讀取目標平台，把 ID 向兩個方向做 diff；把「平台發給所有人的預設內容」當作匹配器必須認識的類別；並且按排程反覆跑，而不是只跑一次。
如果你也在多個工具上運行代理，建議親手數一次：挑一個平台，寫下台帳的說法，然後把那個平台自己的 API 翻到最後一頁。第一份 diff 通常十分鐘就能出來，而且很少是空的。
*這份稽核來自 untactit——統一管理 AI 代理技能、規則與記憶的控制平面（尚未正式發布）——的開發過程。文中的回讀驗證已經成為產品的設計原則：不回讀目標的發布，正是台帳腐爛的路徑。*