14个AI智能体同时报告"记忆系统已死"，复盘后发现数据库里躺着64条完好无损的记录。存储没问题，调用没问题，问题出在它们问问题的方式——而没人告诉过它们该怎么问。
一场全员误判的复盘会
团队昨天开了14人AI评审会。9个智能体给出一致结论：记忆功能失效，平台失去机构学习能力。他们更新了风险登记册，准备联系MCP框架开发商，甚至写了篇博客准备公开讨论这个"系统性故障"。
开发商查完数据后回了一句话：「那个智能体存了64条记忆。」
存储端运转正常。每次AI代理完成工单，系统都会写入一条LESSON记录，归属到对应人格。完成阶段的强制门控确认了存储成功——Sprint 8单个人格就攒了64条。
召回端全线崩溃。不是因为数据消失，是搜索逻辑和人想的不一样。
召回查询长这样：
搜索实现用了AND逻辑：查询里的每个词必须同时出现在记录里。于是数据库在找同时包含auth、middleware、JWT、route、extraction、lessons、learned这七个词的记忆条目。
没有哪条记忆能凑齐这七个关键词。搜索结果为空，代理得出结论：我没有记忆。
评审会上，每个人格都用自然语言查询记忆：
每个查询6-10个词。每个返回空。每个人格都认定自己的记忆系统死了。
两行书写的修复成本
修复只用了两行工具描述：
改完之后，「从JWT令牌提取认证中间件」立刻返回了正确条目。
工具描述是AI代理的API契约。参数文档只写了"搜索查询"，没解释搜索怎么工作。每个AI代理都按人类习惯写查询：用短语、用问句。实现层期待的是关键词列表。没人告诉过它们。
这不是传统意义上的bug。代码完全按设计运行，规格正确，测试通过。问题卡在工具和使用者之间的缝隙里：那个本该教会它们行为的两句话描述。
14个AI人格能就一件错事达成全员共识。它们运行相同的缺陷查询模式，因为共享同一个语言模型。让大语言模型好用的特质——用自然语言写查询——让它们以相同方式集体失效。AI代理的共识不等于正确，当它们共享同一种失败模式时。
最贵的bug长得像功能缺失
团队花了整整一个评审周期把"记忆系统死亡"登记为关键风险。更新了风险登记册。写了博客。准备了架构修复方案。全因为搜索工具没给自己写两行说明。
bug本身的数据损失：零。误诊代价：基于错误前提的半周规划工作。
存储和召回，你测的是哪一个？
热门跟贴