上周看到 a16z 领投了一家叫 Sentra 的公司，500万美元种子轮，做的事情叫"组织记忆"。

他们要解决的问题很具体：公司里真正影响决策的信息，大部分发生在非正式对话里——走廊聊两句、Slack 上吐个槽、开会时随口提一嘴。但工具只记录正式文档。人一走，这些东西就蒸发了。

Sentra 管这个叫"上下文衰减"。

他们解决的是几百人公司的协调问题，难度和我碰到的完全不是一个量级。但这个概念击中了我——因为我自己的 AI 系统，刚刚经历了一模一样的事。

只不过规模小得多。小到只有我一个人。

A 它开始记错了

大概两周前，我发现一个问题：我的 AI 助手开始给出前后矛盾的答案。

同一个问题，上午问一次，下午问一次，回答不一样。不是那种"换个说法"的不一样，是逻辑上打架。

一开始我以为是模型的问题。换了个模型，还是一样。

后来才搞明白：不是模型变笨了，是我给它塞了太多东西。

一个 Agent 同时管内容、管数据、管日程、管知识库。每个任务都往 context 里堆信息。堆到一定程度，它不是不知道答案——它是分不清哪个答案对应哪个问题了。

这就是个人版的"上下文衰减"。知识还在，但执行已经走样。

P 知识不等于存档，规则不等于执行

Sentra 的核心洞察有一句话我觉得说得特别准：知识 ≠ 存档，规则 ≠ 执行。

你把规则写在文档里，不代表系统会遵守。你把知识存进数据库，不代表它能在对的时间被调用。

我的系统就是这样。规则写了一堆，但写在哪里？写在各种散落的文件里。Agent 启动的时候不一定读到，读到了也可能被后面的 context 冲掉。

更要命的是：当 context 窗口快满的时候，最先被挤掉的，恰恰是最早加载的那些规则。

规则的位置，决定规则能不能被执行。

这句话是我踩了坑之后总结的。放在被操作的文件里没用——Agent 操作文件的时候，注意力全在内容上，不会回头看规则。规则必须放在它启动时第一步就读取的地方。

A 四步修好了这个问题

发现问题之后，我花了大概两天时间重构。做了四件事：

四步做完，矛盾回答的问题基本消失了。

不是模型变聪明了，是系统设计对了。

G 你的 AI 系统迟早也会碰到这个

如果你在用任何形式的 AI 助手——不管是自己搭的还是现成的产品——迟早会碰到类似的问题。

一开始很好用，慢慢变得不太对，最后你发现它在"记错"。

这不是 AI 的 bug，这是所有基于 context window 的系统的物理限制。窗口有限，塞得越多，质量越差。

Sentra 在企业层面解决这个问题，需要几百万美元和一整个团队。我在个人层面解决它，只需要想清楚两件事：

第一，一个 Agent 不要做太多事。

第二，规则放在系统读得到的地方，不是你觉得合理的地方。

规模不同，逻辑一样。

AI 系统不会告诉你它快撑不住了。它只会悄悄地开始给你错误的答案。

等你发现的时候，你已经基于错误的信息做了好几个决定。

所以，别等它记错。提前设计。