给Agent接上全公司数据，它为什么还是答错？

一个Agent能读wiki、读任务追踪、读CRM，还能翻三年的Slack记录。它依然不知道一个决定是谁拍的板。它不知道四份文档里哪份是现行版本，不知道团队上季度试过什么又放弃了，也不知道哪些话能对谁重复。 于是它猜。而且猜得很自信。 我们习惯把锅甩给模型。这个诊断是错的。模型对一个它从未真正见过的公司，推理得挺好。真正重要的决定发生在一个讨论串里、一场会上、一条私信里，没有任何东西把它记录成Agent能用的形式。 **AI不是笨，是瞎** 大部分被我们叫做"Agent记忆"的东西，并没有解决这个问题。它只是给这份"瞎"配了一个更大的文件柜。 作者写了35年软件，维护着yfinance，这个库每月大约有3000万次下载。过去一年，他在VarOps为跨整个组织工作的Agent构建记忆系统。上个月他们公布了结果：三个公开基准、一个测试框架，以及保留在里面的负面结果。 今年有两件事变了。 Agent走出了单个开发者的终端。一旦一个团队共享记忆，它就继承了个人聊天历史从未有过的问题。事实会变。人会意见不合。有些人无权看到另一些人说过的话。 开放权重模型也变强了，强到可以在自己掌控的硬件上做正经工作。这比听起来更重要，因为这意味着公司的知识不必住在别人的模型里。 **把记忆当存储，是最常见的错** 常见的错误是把记忆当成存储。全都留下，做嵌入，把最近的片段拉进提示词，然后要求模型好好表现。作者管这叫"检索、塞入、祈祷"。演示效果很好。上了生产，它会以四种方式崩掉。 - 模型会填补碎片之间的空隙，而且没人发现 - 旧片段因为排名更高，会压过新片段 - 证据会随着上下文窗口一起消失 - 访问控制交给模型来执行，而模型恰恰是我们想约束的那个东西 作者在AI DevCon上会讲完整设计。这里先说三个最关键的决策。 传统观点认为记忆越多越安全。留着完整记录，以后总能找到答案。 但记录不等于知识。我们俩都不会记住这篇文章的每一个字，我们会记住它确立了什么。系统也是照这个思路建的。每一条进来的观察都被蒸馏成"主张"。每条主张说明：谁说了什么、什么时候说的、在哪个时间段内为真、以及源材料里哪一段能证明它。其余的一切被有意丢弃。 这听起来有风险。数字给出了相反的答案。蒸馏是有意做成有损的，但在LongMemEval这个包含500个问题、基于长聊天历史的公开基准上，正确的证据依然出现在99.8%问题的前十结果里。摄入约3500万token花了8.24美元，跑在两颗CPU上，没有GPU，用的是免费的本地嵌入模型。 做蒸馏的模型也不必是前沿模型。他们用Gemma 4——一个310亿参数的开放权重模型——在一张租来的GPU上重建了整份记录。它写下的主张数量和前沿提取器差不多。答案质量只移动了一到两分。 蒸馏还给了记忆一个唯一的入口，而这个入口可以说不。在一次基准运行中，一个转换bug开始输出人类可读的日期，而不是机器可读的时间戳。这个入口隔离了5732条提交，接受了零条。一个普通的存储会把它们全部索引进去。 **拒绝回答，值多少分** 传统做法是追加加检索，剩下的交给模型去理清。 问题在这里。一条三月的片段和一条六月的片段讲的是同一个事实，它们就只是两条片段。谁排名高谁赢。而当检索返回空结果时，模型分不清"我们没找到"和"我们根本不追踪这个"，于是它去填这个空。 他们改了两件事。什么都不覆盖。新事实取代旧事实，两者都留在记录上，各自带着日期。每个问题都归结为一个明确状态：已回答、搜过但没找到、或者超出系统所知的范围。 他们通过移除这个机制，测出了"拒绝"值多少。同一个系统、同一份数据，被指示永远不要说信息缺失。总分几乎没动，从88.0到87.2。但30次诚实的拒绝变成了30条编造的答案。如果只按可回答问题计分——也就是从不拒绝的系统常用的报告方式——同样的答案读数是92.8。下次看到某个记忆产品公布一个头条数字、却用了不拒绝协议时，值得想起这一点。 多数团队用两种方式之一处理权限。要么所有人共享一个上下文，要么在提示词里告诉模型它不能说什么。 第一种意味着系统永远不能持有任何敏感信息。第二种意味着由模型来执行策略。而蒸馏本来就会打破文档级的访问控制。一条主张可能由四个来源构建，而这四个来源有四种不同的权限级别。 所以他们先解析身份，在那个人的授权下检索，然后才调用模型。模型永远不会收到提问者无权看到的内容。披露级别在事实被写入时就确定，而不是在读取时才做删减。 报告里有一个具体的测试。一个财务读者问一个营收数字，得到2,140,000。一个销售读者问同一个主题，得到2.0M到2.5M的区间和一个趋势，"上升"。精确值一个字节都不在他们的证据里。而权限范围之外的人分不清"被保留"和"空"，所以没人能通过返回的内容去试探秘密。