🔥 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思路可以参考——不用等到出错才意识到记忆已经漂移了。