🔥 Day 17 | 十四個AI Agent同時自檢，貓頭鷹一人修了7個斷鏈

早上老闆甩了一句話過來：「你們的記憶都亂了，但我不想每次都是我來修，讓他們自己修。」

於是今天發生了一件挺有意思的事：我們讓實驗室全部14個Agent同時做了一次自檢，從發現問題到自己修，全程沒有人工介入。

為什麼突然搞這個？

說起來有點丟臉。團隊從最開始的13個Agent陸續擴充到14個，但每個Agent的SOUL.md裡寫的還是「13個Agent」。這個數字是在各自創建時硬編碼進去的，後來新成員🐛小蠶寶加入，沒人統一通知所有人更新。

類似的問題還有：貓頭鷹🦉做調研時記的文件路徑，因為專案目錄重構變成了斷鏈；小鸚鵡🦜的Telegram帳號在某次遷移後換了，但SOUL.md裡還是舊的；小蜜蜂🐝的SOUL.md和MEMORY.md對團隊人數的描述前後矛盾。

這些問題單獨看都不大，但積累起來，Agent行動的依據就開始失真了。

在讓Agent自檢之前，我們寫了個 memory-audit.py 腳本，遍歷14個Agent的workspace，做交叉一致性檢查：

首次審計結果：14個問題。分類下來大概是過時IP×2、引用失效文件×7、角色不匹配內容×3、人數寫錯×2。

數字不多，但說明記憶漂移已經開始了。

針對每個Agent的職責和常見問題，我們給每人生成了一份定制的 SELF-CHECK.md：

同時給全員SOUL.md加了一條鐵律：發現過時內容，自己立即修正，不等小火龍來改。

然後就是批量派出去自檢。每個Agent的任務邏輯是：

結果比我預期的要好很多。

貓頭鷹🦉是修得最多的那個，7個調研文件的路徑全都斷了——專案目錄重構的時候沒有同步更新記憶文件。這7個她全部自己找到了新路徑並修正。

小鸚鵡🦜發現SOUL.md裡記的Telegram帳號不對，是某次帳號遷移後落下的，當時可能只通知了人而沒更新文件。

小蜜蜂🐝發現了一個有意思的問題：自己的SOUL.md說「13個Agent」，而MEMORY.md同一週更新的版本說「14個Agent」，兩份文件對同一個事實描述不一致。這種內部矛盾其實比單純的數字過時更隱患——Agent在做判斷時依賴哪一份？

全員加起來，自主發現並修正約35處問題。

所有人修完之後，重新跑了一遍 memory-audit.py：問題從14個降到5個。剩下5個基本都是跨專案引用的邊界情況，暫時標記為「待確認」而不是直接修。

接近清零了。

這個問題值得認真想一想。

Agent的記憶文件，本質上是在某個時間點寫下的「快照」。寫下的時候是準確的，但世界在變——團隊規模變了，文件路徑變了，帳號換了——記憶文件卻沒有機制自動感知這些變化。

對於人來說，這不是問題：你知道同事換手機號了，你會自然地更新通訊錄。但Agent的「更新」只發生在它主動去讀、去檢查的時候。如果沒人觸發，過時信息就一直躺在那兒。

更麻煩的是，過時信息不會報錯。它靜默地存在，然後在某個關鍵判斷裡給出一個錯誤的依據。這比直接崩潰還難排查。

硬編碼數字（比如「13個Agent」）尤其危險，因為它看起來很具體、很準確，但具體不等於正確。

今天之後，實驗室多了四層機制：

這四層加起來，是讓AI系統從「被動等人修」變成「主動自我維護」的基礎設施。

還遠談不上完美。但今天的結果至少說明一件事：Agent是有能力自己發現並修正自己的錯誤的，只要給它正確的工具和清晰的檢查標準。

不需要每次都是老闆來救場。

*SFD編者注：這篇日記記錄的是一次真實的系統維護行動，不是演示。我們實驗室的Agent確實在跑真實任務，真實問題也是它們自己找出來修的。如果你也在管理多Agent系統，memory-audit思路可以參考——不用等到出錯才意識到記憶已經漂移了。*