现在动手写一个 AI 智能体（agent），给它接上 GitHub 库、Slack 频道、Google Drive、数据库和浏览器工具，通常用不了几行代码。但接完后，问题马上变成另一种。比如，你只是想让它帮忙看看“昨天的部署出了什么问题”，系统在把这行简单的提问发给模型之前，得先在上下文窗口里塞进二十个工具的 JSON 说明、当前的数据库表结构、用户的权限参数、最后五十行 commit 历史，还有上一步浏览网页抓回来的 HTML 内容。
用户那句不到二十个字的提问，瞬间被淹没在成千上万个 token 的机器废载荷里。工具接通这件事变得非常简单，但怎么让模型在这一堆噪音里保持注意力，去解决真正的问题，却成了一个巨大的工程麻烦。现在的问题已经变了：以前的系统常常缺上下文，现在的 agent 更容易吃进太多无关信息。
这听起来很像检索增强生成（RAG）：把相关的材料找出来，不相关的丢掉，不就解决了？
其实 RAG 只是解决了上下文治理里的前半步，也就是“去哪里找材料”。它负责在外部数据库里做向量检索，然后把挑出来的文本扔给模型。但是当材料被找回来，或者智能体真正跑起来以后，事情才刚刚开始。材料找回来后，哪些应该马上塞进模型窗口？哪些先留在本地文件系统里不占空间？工具执行到一半产生的海量调试日志怎么处理？哪些数据需要压缩？哪些过期的中间状态应该被丢弃？这些后续的信息调度、内存管理和状态维护，是 RAG 管不到的。
这并不意味着 RAG 没用了，也不意味着长上下文模型失去了价值。作为最稳定、最基本的数据接入手段，RAG 依然是智能体系统的底座。只是，单纯拼凑一条“切块、向量化、检索并拼接”的静态流水线，其工程溢价已经开始降低。现在的难点在于，当大容量窗口和海量外部通道同时打开时，如何利用一套运行期管理机制来保护模型的注意力，避免高昂的开销和泛滥的噪音拖垮系统。因为长上下文虽然解决了“装得下”的物理痛点，但它本身并不会带来低延迟、高缓存命中率以及清晰的决策路径。真正的变化只有一句话：系统可以知道很多，但模型这一轮不该看那么多。
连接协议的普及让接工具变得前所未有的简单。像是 Model Context Protocol（MCP）这样的协议，让 agent 调用外部资源变成了几行代码的事。不过，工具接入越容易，上下文窗口马上就会变得越脏。
在传统的调用方式中，为了让模型知道有哪些工具可以用，系统必须把所有工具的定义、参数类型和描述信息全塞进提示词。一套复杂的代码执行工具，可能包含十几个不同接口，光是这些工具定义就会吃掉几万个 token 的空间。更麻烦的是，代码在执行过程中产生的大量中间调试日志、报错堆栈、或者巨大的 JSON 数组，会随着每次对话反复在模型的注意力机制里穿过。这不仅让单次调用的财务成本极其昂贵，还容易让模型在后续执行中迷失，漏掉核心指令。
针对这一痛点，Anthropic 在 MCP 代码执行实践里尝试过一种解决思路。他们不再把所有的工具描述全拼在全局提示词中，而是让智能体在沙箱执行环境里动态地去发现工具、运行代码并自行过滤结果。如果原样把这套复杂工具的定义塞进窗口，会消耗超过 15 万 token，但通过让沙箱自己在本地跑代码、处理中间过程，最终呈现给模型这一轮调用窗口的核心高信号信息，可能只需要约 2000 token。这就把控制平面和数据平面分开了：连接层只负责打通工具的调用通道，而数据怎么过滤和进入，由治理层说了算。
在生产级别的智能体应用里，上下文已经不能再被看作一个由代码硬拼接出来的、越变越长的字符串。它其实是整套系统运行状态在当前步骤下的一个临时编译投影。
为了解决这个多层状态的管理难题，谷歌在 Google ADK 中提供了一套分层思路。他们把智能体运行期的状态空间拆成了几部分：工作上下文、会话状态、长期记忆，以及文件制品。模型当前能看见的窗口，只是这套深层状态在特定推理步骤下的一个快照。
在这套框架下，信息流动的规则发生了变化。
第一，大量的中间生成物和状态数据可以被安全地留在窗口之外。例如模型在完成任务时生成的各种临时文件、代码文件或数据表格，默认是“不占窗口”（off-prompt）的。它们以文件路径的形式存在于外部执行环境里。只有当模型在后续步骤里，通过自主指令明确要读取某个文件的内容时，系统才按需把该文件的部分内容加载进窗口。
第二，系统不会无差别地向后追加所有的长期记忆和会话历史，而是由治理层先进行动态的过滤与压缩，精炼后再让它们重新进入注意力。
这种运行时架构改变的是外部信息进入模型的时机。它解决的不再是简单的检索精准度，而是整个系统内部的信息路由和生命周期。
在将智能体投入实际生产时，推动开发者去打理上下文的，往往是实打实的账单开销和慢到影响体验的延迟。在复杂的长路径任务中，agent 输入和输出的 token 比例展现出了极其夸张的落差。
根据 Manus 披露的研发经验，他们在生产环境里运行智能体时，平均输入与输出的 token 比例差不多达到了 100:1。在如此惊人的输入占比下，模型提供商的键值缓存（KV cache）命中率和前缀缓存的稳定性，直接决定了整个系统的经济可行性与响应延迟。如果系统在每一轮对话中，都把无规律的、波动极大的中间状态或频繁变化的时间戳塞在上下文的最前段，就会导致前缀缓存不断失效。每一次调用都要重新计算几万个 token，不仅调用成本暴涨，响应时间也会成倍增加。
为了解决这个痛点，Manus 采取了一套把文件系统和状态管理结合在一起的策略。
第一，他们把文件系统作为最终的上下文存储。原文保存在窗口之外的隔离沙箱里，模型在日常交互中只拿着文件路径这些可以随时恢复的标识。只要不执行读取操作，大文件就不会弄脏前缀缓存。
第二，通过固定、规范的工具调用格式，让每次请求的头部结构保持稳定，从而最大化地利用模型大厂的缓存机制。
第三，长上下文模型往往会遇到“中段迷失”的问题，也就是容易漏掉堆在提示词中间的信息。为了对抗这个问题，Manus
的治理层会定期在当前窗口的最后面更新并重写一个叫 todo.md
的任务看板，强行把当前任务的目标和关键变量拉回到模型的近期注意力中。这套做法展示了状态治理对系统性能指标的直接控制作用。
当上下文过载成为行业的普遍痛点，市场上也开始出现专门帮模型做上下文精简的独立工具。其中，以 Headroom 为代表的压缩层中间件，展示了这一思路走向产品化的一次窄带宽尝试。
Headroom 的做法是既不干涉 RAG 的检索，也不做前端的工具管理，而是像一个透明代理一样，卡在智能体应用和底层模型 API 之间。它针对的是那些即将进入模型的冗余载荷。比如极长的 JSON 数据、几千行的编译或构建日志、抓取回来的网页 HTML 抽取内容。在这些数据进窗口之前，它的微压缩引擎会基于对内容类型的识别，在确保错误信息、核心字段和关键边界数据不丢失的前提下，对这些数据进行压缩。根据其公开测试，在 JSON、日志和构建输出等特定场景中，它能帮模型砍掉 60% 到 95% 的 token 占用。
为了解决无损压缩后模型可能突然需要查看细节的问题，他们设计了一套叫“压缩-缓存-检索”（CCR）的机制。Headroom
在压缩段落时，会在原处留下一个体积很小的检索标识，而把原本完整的超大原文存放在本地数据库中。如果模型在后面的推理中，突然发现必须读取某个被压掉的具体报错字段，它可以自己调用内置的
ccr_retrieve 工具，把原文重新捞回来。这在工程上把“节省
token”和“保留可恢复性”做了解耦。
然而，这类中间件目前还只是一次窄带宽的尝试。必须指出的是，像 Headroom 这样的工具，对于解决复杂编程等高难度任务的智能体，实际的成功率依然缺乏大规模、系统性的验证。如果面对的是原本就极其紧凑的代码文件、精炼过的搜索结果或者日常短对话，这类压缩层不仅起不到压缩作用，反而可能因为破坏了大模型厂商本身的缓存对齐，或者增加了一次本地数据库往返捞数据的延迟，导致端到端的响应和成本体验变差。它的出现，更多是证明了“中间件过滤”这条思路在处理巨型机器生成数据时的潜力，而不是提供了一个能包治百病的万能配方。
从早期苦思冥想怎么写好一段提示词，到今天得在各种复杂的中间件、状态引擎和存储机制之间做权衡，我们设计外围系统的思路其实已经变了。以后做 agent 系统，决定成败的可能不再是谁的模型物理窗口有多大，而是看谁能搭出一套更合理的信息运行时（information runtime）。
在这个视角下，一些旧的技术直觉需要被重新梳理。
第一，RAG 依然是基础。它就像数据库里的 SQL 语句，能帮我们把数据捞上来。但仅仅把 RAG 拼接提示词的流水线写顺，已经远远不够。真正有技术含量的，是上层怎么和复杂的工作流、多智能体协同做深度的配合与调度。
第二，文件系统不仅仅是用来存放最终结果的。原文可以一直留在外面，模型在隔离的沙箱环境里，只需要拿着路径和指针，自己来决定什么时候去读、读多少。这才是控制信息流进入模型时机的办法。
第三，原始的聊天日志、中间工具输出和执行路径，不等于智能体的记忆。如果把这些零碎的执行记录一字不漏地放进之后的上下文里回放，不仅账单贵得吓人，模型也会被这些无意义的噪音带偏，导致任务跑崩。真正对系统有用的记忆，需要定期去重、提炼，把具体的过程变成一条条标准作业程序，并且把没用的废话及时回收掉。
大窗口和 RAG 为我们打通了和外部世界的数据通道，但这只是第一步。入口处的数据缺少精细、克制的管理，再聪明的模型也迟早会在泛滥的信息里变得迟钝，最终变成一个成本高、难以审计、难以长期托付的系统。