过去一年，关于 AI Agent 的讨论几乎都围绕着同一组关键词展开：更强的模型、更长的上下文、更丰富的工具、更复杂的工作流。很多团队相信，只要模型足够聪明、工具足够多、链路足够长，Agent 自然会越来越接近“自动完成复杂任务”的理想状态。

但真正做过 Agent 开发的人，通常会比旁观者更早意识到一个残酷事实：
Agent 系统最先撞上的，不是推理能力的上限，而是 Context 管理的上限。

这不是一个边角问题，也不是一个单纯的 token 成本优化问题。它更像是 AI 时代重新出现的一类基础设施问题：当模型开始频繁调用工具、持续处理外部世界的数据时，Context 本身就不再只是 Prompt 的一部分，而开始扮演“运行时内存”的角色。而一旦你把 Context 当成“内存”来看，许多今天 Agent 的奇怪现象，其实都变得很好理解了。

模型不是突然变笨了，而是“内存污染”了。
不是任务太复杂了，而是“工作内存溢出”了。
不是工具不够强，而是工具返回的数据正在摧毁推理过程本身。

一、今天的 Agent，为什么总是在“越跑越傻”

很多 Agent 的失败，表面看起来是模型能力不够，实际上却是上下文管理失控。

一个典型场景是这样的：Agent 为了完成任务，调用浏览器工具读取网页，调用文件工具读取代码仓库，再调用 shell、git、搜索、日志分析等工具获取外部信息。每一步似乎都合理，但问题在于，这些工具返回的往往不是“知识”，而是未经处理的原始数据洪流。

一次 Playwright 快照可能就是几万 token。
一次 git log 或 diff 可能又是上万 token。
网页 HTML、控制台日志、结构化 JSON、运行栈信息，这些全都以“原文”进入上下文窗口。

于是，Agent 的运行逐渐出现一个非常熟悉的退化轨迹：

一开始，它还能跟住目标；
接着，它开始忘记早先的约束；
然后，它重复尝试已经失败过的方案；
再往后，它甚至连当前任务的主线都抓不住；
最后，整个会话只剩下大量噪音，开发者不得不手动重启。

这个过程和我们直觉里“模型在思考”完全不同。真实情况更像是：模型被迫在一堆日志、快照、JSON、网页片段里挣扎，真正重要的任务状态反而被淹没了。

所以，很多 Agent 不是死于“不会做”，而是死于“记不住自己在做什么”。

二、Context 的本质：它不是提示词容器，而是运行时内存

如果把大型模型只看作一个“回答问题的聊天引擎”，那么 Context 看起来只是对话历史和提示词的组合。但一旦进入 Agent 场景，这种理解就立刻变得不够用了。

Agent 不是静态问答，而是一个持续运行的系统。它要规划、执行、观察、修正、继续执行。在这个循环里，Context 承担的功能，其实非常接近传统计算机系统中的“内存”：

它保存当前目标；
它暂存最近的执行结果；
它携带中间状态；
它影响下一步决策；
它决定模型在这一刻“看到什么”。

从这个角度看，Agent 的很多问题都可以被重新翻译成操作系统语言：

• Context Window 就像物理内存，容量有限
• 工具原始输出直接写入 Context，就像无节制地占用内存页
• 长日志和大快照进入主上下文，就像把垃圾数据常驻 RAM
• 模型忘记任务目标，就像关键状态被挤出工作集
• 会话必须重启，就像进程因内存管理失效而崩溃

这也是为什么“更长的上下文窗口”并没有真正解决 Agent 的根本问题。更大的窗口，只是延缓了爆炸，而没有改变爆炸机制本身。
只要系统仍然允许原始工具输出无差别地进入上下文，那么上下文再长，也只是在给混乱腾出更多空间。

因此，Context 管理的核心，不是扩容，而是治理。不是让模型看到更多，而是让模型只看到值得它看到的东西。

三、真正有效的方案，不是“总结一下”，而是分层架构

在很多工程实践中，一个正在浮现的有效思路是：把工具执行层与模型推理层彻底分开。

这背后的关键不是“摘要”本身，而是分层。

一种更成熟的 Agent 架构，不应该让工具输出直接流入主对话历史，而应该经过至少三个层次：

首先是执行层。工具仍然照常运行，拿到完整输出，不牺牲能力边界。

其次是存储层。原始结果不直接进入主 Context，而是被保存到外部存储中，例如本地文件、SQLite、全文索引、向量数据库或其他可检索系统。原始数据被留在这里，等待未来需要时再访问。

最后才是推理层。进入模型上下文的，不是大段原始内容，而是压缩过的结果：一个简短摘要、几个关键字段、一段带来源标识的结论，或者一个可被后续查询的句柄。

换句话说，Agent 不再把 Context 当作“所有信息的唯一容器”，而是把它降级成“当前推理所需的高价值工作区”。
原始数据则退居二线，成为外部记忆系统的一部分。

这就是所谓“沙盒 + 索引 + 按需检索”方案真正有价值的地方。它的意义不在于节省一些 token，而在于它第一次让 Agent 具备了最基础的系统分层：

• 工具负责采集
• 存储负责保留
• 索引负责定位
• 模型负责理解和决策

这比简单地“让模型自己总结一下”要重要得多。因为后者仍然把模型置于洪流中心，而前者是在结构上切断洪流对主上下文的污染。

四、为什么这套思路像“虚拟内存”，而不像“提示词优化”

很多人会把这类方案理解成 prompt engineering 的进阶版，认为无非是“写个中间层，压缩下工具输出”。这种理解低估了它的意义。

它更像操作系统中的虚拟内存机制。

传统程序不可能把所有数据都常驻在物理内存中，于是操作系统引入分页、换入换出、缓存、索引等机制，让系统在有限物理资源下处理更大规模的信息。
同样地，Agent 也不应该把所有感知结果都常驻在 Context Window 里。它需要一套机制，决定：

哪些内容必须常驻；
哪些内容可以延迟加载；
哪些内容只保留摘要；
哪些内容只保留索引；
哪些内容应该被回收。

一旦引入这个视角，Context 管理就不再是“语言模型的小技巧”，而是一个完整的运行时问题。你会开始自然地思考下面这些原本很“系统化”的问题：

• 主 Context 的固定预算是多少？
• 哪类信息有资格进入主 Context？
• 工具输出的默认策略是保留原文，还是只保留摘要？
• 检索什么时候触发？触发阈值是什么？
• 子任务结束后，哪些状态应该回填主上下文？
• 历史执行记录是给模型看的，还是给系统恢复和人类调试用的？

这正说明，Agent 正在从“聊天程序”演化成“有状态的计算系统”。而一旦跨过这个边界，Context 管理就会像内存管理一样，成为一切上层能力的前提。

五、第三方工具和 MCP 暴露了更深的问题：协议层没有“输出治理”

如果说内置工具还可以通过框架层做拦截、压缩和索引，那么第三方工具生态里暴露的问题则更根本。

以 MCP 这类工具协议为例，很多响应是通过 JSON-RPC 或类似机制直接传递给模型的。只要协议默认假设“工具结果应完整送达模型”，那么即便上层框架想做 Context 管理，也会面临一个结构性障碍：数据已经到达模型侧了，污染已经发生了，治理来不及了。

这说明问题不只是“某个 MCP 服务写得不好”，而是当前工具协议本身缺乏一层至关重要的设计：输出网关。

一个面向 Agent 的成熟工具协议，理论上应该允许至少以下几种机制存在：

• 对大结果设置预算上限
• 支持服务端摘要而非默认全文返回
• 支持分页、懒加载和结果句柄
• 区分“给模型看的内容”和“给系统保存的内容”
• 允许中间层在数据进入模型前做裁剪、脱噪和结构化压缩

如果这些能力缺失，那么协议做得越开放，模型吃到的垃圾也就越多。工具生态表面繁荣，实际却可能是在放大上下文污染问题。

这也是为什么我们不能把 Agent 的未来简单寄托在“更多 MCP server”上。
没有上下文治理能力的工具协议，最终只会让 Agent 变成一个高成本、低稳定性的自动化外壳。

六、为什么真正的机会不在应用层，而在“Agent OS”这一层

今天很多人谈 Agent 创业，第一反应是垂直场景：客服、销售、法律、编程、分析、办公、内容生产。这些方向当然会有价值，但如果从技术演化的角度看，真正还没有被充分做好的，并不是应用壳层，而是更底下的那一层。

那一层我更愿意把它叫作：Agent 操作系统层。

它不直接回答用户问题，也不直接表现为炫目的 demo。它做的事情更像底盘工程：

• Context 生命周期管理
• 长短期记忆划分
• 工具输出治理
• 状态持久化
• 子 Agent 隔离
• 执行分支与回滚
• 恢复与重试
• 成本预算控制
• 任务审计与可解释性

如果今天的 Agent 还像早期 DOS 时代的程序，那么这层基础设施就是未来的 Windows、Linux 和现代运行时。
谁把这层做成熟，谁才能真正支撑大规模、长周期、高复杂度的 Agent 系统。

也正因为如此，Context 管理绝不是“优化项”，而是 Agent 基础设施的入口问题。谁先把这个入口处理好，谁就更有可能建立系统稳定性、成本效率和任务深度三者之间的平衡。

七、面向未来的一个判断：Agent 的上限，取决于它如何“忘记”

在传统软件里，我们往往强调“记住”。数据库要可靠，缓存要命中，状态要持久。但在 Agent 系统里，一个同样重要、甚至更难的问题是：它如何正确地忘记。

因为不是所有信息都值得一直保留。
网页源码不值得。
大段日志不值得。
重复错误栈不值得。
临时调试输出不值得。
一次性工具中间结果也未必值得。

真正应该保留的，是那些对下一步推理仍有因果影响的状态：目标、约束、结论、失败教训、未完成事项、关键证据路径。

所以，从某种意义上说，强 Agent 不等于记住更多，而等于更精准地区分：

什么该进入主 Context，
什么该进入外部记忆，
什么该保留摘要，
什么该被删除。

这是一种新的工程能力。它既不是传统的软件架构问题，也不是单纯的模型训练问题，而是二者之间的新交叉地带。

未来最优秀的 Agent 系统，不会是那个“什么都塞给模型”的系统，而会是那个能够像成熟操作系统一样，高效分配注意力、谨慎管理内存、在复杂环境里保持状态清醒 的系统。

AI Agent 的真正基础设施，才刚刚开始

如果说过去一年大家主要在比拼模型、工具和工作流，那么接下来几年，真正拉开差距的，可能会是另一类能力：谁更懂得管理 Context。

因为 Context 不只是 token，不只是对话历史，不只是 Prompt 拼接。
在 Agent 时代，Context 是运行时状态，是工作内存，是推理舞台，也是系统稳定性的根基。

而今天的大多数 Agent，之所以看起来“不够可靠”，不是因为它们没有更强的模型，而是因为它们还没有一套成熟的“内存系统”。

这也是为什么我越来越相信：
AI Agent 的下一个重大机会，不是再做一个应用，而是去构建它的操作系统。

当工具输出不再直接污染上下文，当记忆有层次、状态可恢复、检索按需触发、子任务彼此隔离，Agent 才会真正从“会聊天的工作流”进化成“可以长期运行的计算系统”。

而这一切的起点，就是重新理解 Context。
不是把它当作提示词容器，
而是把它当作 AI 时代最重要的系统资源之一