一个智能体跑到第十步时，模型眼前可能已经堆着系统指令、工具说明、十轮对话、网页正文和几次失败输出。最初那句提示词仍然在，可它只占全部输入的一小部分。接下来该留下什么、删掉什么、临时再查什么，决定了模型还能不能把任务接着做下去。
我顺着 Anthropic 的上下文工程说明查了一遍。它把上下文定义为模型采样时收到的全部 token，系统提示、工具、MCP 接口、外部资料和消息历史都算在内。上下文工程要在每次调用前整理这批内容，因此它会随着智能体的行动不断发生。
长窗口也会分心
上下文窗口给出了能装多少 token 的上限。装得下并不等于每一段都能被同样准确地使用。Anthropic 汇总的长上下文观察提到，内容增长以后，模型从中准确找回信息的能力会逐步下降。它称这种现象为 context rot。不同模型下降速度有差别，工程上仍要把注意力当成有限资源。
这会改变资料处理方式。若任务只需要核对一份合同中的付款条款，把整套项目文件都塞进去，会带来更多相似条款、旧版本和无关附件。更稳的做法是先保留文件名、日期和路径，需要时再读取对应段落。模型看到的信息少一些，出处反而清楚。
系统指令也要控制密度。指令太宽，模型不知道遇到边界时怎样选。把每种情况都写成层层嵌套的规则，又会变得难维护。官方工程说明建议从能够完整表达预期行为的最小信息集开始，用清楚的分区组织背景、行动要求、工具说明和输出格式，再根据真实失败补规则与示例。
工具返回值同样占上下文。搜索接口一次吐回几百条完整记录，会把后续判断淹没。工具可以先返回数量、标识和摘要，让智能体选中少量结果以后再读正文。工具之间功能重叠太多，模型还要额外判断该调用哪一个，输入参数和错误信息也应让它一眼看懂。
让资料按需进来
即时检索会保留轻量引用，例如文件路径、已保存查询和网页链接，等问题走到那里再加载内容。文件层级、命名和修改时间也能帮助模型判断用途。这个办法节省上下文，代价是运行时多几次探索，工具不好用时还会走弯路。
许多任务适合混合处理。稳定且每次都要遵守的规则提前放入，体积大的资料按需查。长任务接近窗口上限时，可以把已经确认的决定、未解决问题和关键路径压成一份短记录，舍弃重复的工具输出。压缩后的内容仍要能回到原文件核对，摘要写错也会把后续带偏。
验收上下文工程时，别只看一次答案。记录每轮送进模型的内容类别、token 数、检索来源和被删除的历史，再用同一组长任务测试。任务进行到后半段仍能记住目标、找到正确版本并引用原文，这套整理才算有用。
提示词仍然重要。它负责说明要做什么。上下文工程管得更宽，连同模型此刻凭什么做、有哪些工具、已经发生过什么一起处理。智能体跑得越久，这项工作越像日常维护，必须持续删去失效内容，并把重要状态留在可核对的地方。