你的 AI Agent 什么都记不住：修复 context 膨胀的 MCP 技巧

没有人愿意公开的问题

每一个 AI 编程 agent 的演示都大同小异：干净的终端、清晰的指令、整齐的输出。没有人给你看第三个小时发生了什么，此时 agent 已经读过四十个文件、跑过十几套测试，把每一条执行过的命令的嘈杂输出都塞满了它的 context window。到那一步，agent 不会变得更聪明，反而会变笨、健忘，还会自信地重复它早就完成的工作。

这是 agentic 编程里最不体面、也最普遍的问题。context 就是 agent 的工作记忆，而它是有限的。agent 读到的每一样东西都在争夺同一块空间，而它读到的大部分都是垃圾：构建日志、堆栈跟踪、目录列表、那些它只需要一行却抓来了全文的文件。窗口被沉淀物填满，最初让 agent 变得有用的那部分推理能力被挤了出去。

解决这个问题的工具，并不是在基准测试里胜出的那些工具。它们是管道。而在这个十月，正是这些管道爬上了 GitHub 的热榜。

工具输出 sandboxing 背后的思路

浮出水面的比较有意思的项目中，有一个面向编程 agent 的 context 优化层，它从源头下手解决这个问题。它最亮眼的数字是：到达模型的工具输出量减少了大约 98%。

机制在概念上很直接。与其让命令的原始输出直接倒进对话里，你把它放进 sandbox 里运行，只把模型需要的那部分结果交给它：一段摘要、退出状态、命中查询的那几行。完整记录仍然可以被模型主动取用，但它不会仅仅因为“也许有用”就一直占着窗口的空间。

这和一位优秀工程师的习惯性做法是同一种纪律。当关键只是那一行报错时，你不会把整段日志粘进对话。而 agent 一旦放任不管，做的恰恰相反。

这背后是有账单的，所以这些工具并不只是工程上的锦上添花。context window 不是免费的。模型要处理的每一个 token 都在花钱、花时间，它要记住的每一个 token 都在消耗注意力。一个往会话里倒进十万 token 构建输出的工具，是在向你收两次费：一次是 token 本身，另一次是当信号被埋没之后模型判断力的下降。这 98% 的削减，其实是披着省钱外衣的质量修复。

比会话更长寿的记忆

问题的另一半是：agent 不只是在一个会话内会忘，它会跨会话遗忘。关掉终端，context 就没了。第二天重新打开，agent 完全不知道你做过什么决定、否决过哪条路线、代码为什么长成现在这样。你重新解释一遍，agent 重新推导一遍，某个决定就这样被做了两次。

这个领域里的持久化记忆工具采用了不同的路子。其中最受关注的一个会捕获 agent 在会话里做的事，用模型把它压缩，再把相关的部分注入到未来的会话里。它的卖点并不炫酷，但说得很对：一个记得你项目大致模样的 agent，比一个在单一任务上稍微聪明一点的 agent 更有价值。主流的模型厂商也在往同一个方向走，加入了让 subagent 比父对话更早压缩自身 context 的开关，恰恰就是为了不让它把整个会话的历史带进一个根本不需要这些历史的任务里。

这里有意思的设计问题是：该记住什么。什么都记，你等于用更慢的方式重建了最初的问题。记得太少，记忆就毫无用处。真正获得势头的项目，都是那些有选择地记忆的项目，它们信奉的理论是：对过去一个月的一份好摘要，胜过对过去一小时的一份完美记录。

把 routing 当作 context 策略

第三块拼图是 routing：在任务运行之前，就决定它需要哪个模型、哪些工具，这样它就不会被加载上一堆永远用不到的能力。一个被告知了十七种不同集成的模型，即便任务只需要其中一种，也会为这十七种都花掉 context。跨平台强制执行 routing 听起来像是个基础设施细节，实际上它是一项伪装起来的 context 预算决策。

到了这一步，问题就不再像缓存问题，而开始像系统设计。agent 的 context window 是一种资源，就像内存和磁盘是资源一样，而那些把它当资源对待的工具，才能让 agent 在长任务中保持一致。sandboxing、记忆和 routing 这几个项目走到一起并非偶然：它们是同一种稀缺性的三个侧面。

subagent 模式是最清楚的例子。当一个 agent 派生出一个助手去做某项很窄的工作时，这个助手并不需要继承整段对话。交给它一个只包含手头任务的干净 context，既更便宜也更准确，这也是为什么较新的 harness 允许 subagent 比父级更早地压缩自己的 context。父级保留长长的历史，子级得到一张干净的书桌。那些让 agent 跑过长达一周重构的团队，往往会自己得出这条规则，通常是在看着一个 subagent 把整个窗口都花在重读一段它根本不需要的对话之后。

为什么是现在

这些问题都不是新问题。从第一个 agent 跑起来开始，agent 就一直在丢 context。变化在于：现在人们期望 agent 能连续跑上好几个小时、跨很多个会话、处理真正重要的工作。玩具忘了东西无所谓。而一个团队赖以进行一周重构的工具，忘掉东西的代价就大得多。

市场已经注意到了。两年前，“我们的 agent 有 200k 的 context window”是个卖点。现在真正有用的问题是：这个窗口里有多大比例花在了信号上。懂得这一点的厂商正在推出压缩控制和 subagent 的 context 隔离。社区则在推出让其余部分变得可以忍受的管道。

不体面的结论

人们很容易把十月这波 agent 新闻读成一个关于更聪明的模型和更巧妙的插件的故事。但更安静、更持久的故事是关于卫生的。agent 已经变得足够有用，可以长时间运行，而长时间运行会暴露出它们管理自身记忆方式上的每一处弱点。

在热榜上爬升的项目，都是那些接受了一个平淡事实的项目：自主工作的瓶颈很少是纯粹的智能，而是能否不淹没在自己的笔记里、始终待在任务上。把记忆修好、把噪声放进 sandbox、把能力做好 routing，一个仅仅称职的模型会突然显得很出色。做错了这些，即便是前沿模型也会把它一下午的时间花在重读一个它已经读过五遍的日志文件上。