最近在学习 Context Engineering 时，我重新回顾了一下自己以前对上下文窗口的理解。

刚开始，我把更大的上下文窗口当成一个直接的好消息：历史消息不用删，检索结果、工具说明和中间过程也能全部交给模型。

既然放得下，为什么还要费力修改prompt？

但在 Agent 场景里，问题逐渐从“装不下”变成了“到底应该装什么”。窗口没有超限，并不代表其中的信息都对当前决策有帮助。

我更愿意把上下文看成 Agent 的工作台，而不是资料仓库。如果上面堆着旧文件、无关工具、重复结果和过期任务，再大的空间也会混乱。

放得下，不等于看得清

普通问答的上下文比较简单，通常由用户问题、系统提示和少量参考资料组成。Agent 的上下文却会随着执行不断膨胀：

• 用户的原始目标和补充要求；

• 已经进行的多轮对话；

• Agent 生成的计划与中间判断；

• RAG 检索返回的文档片段；

• 工具定义、调用参数和执行结果；

• 失败重试产生的错误信息；

• 子任务返回的临时结论。

这些内容单独看都有价值，放在一起却可能相互干扰：旧计划可能让模型继续执行已取消步骤；多个文档版本可能带来过期结论；大量工具定义也会淹没真正需要的工具。

上下文窗口解决的是容量问题，却没有自动解决相关性、时效性和优先级问题。

上下文不是越长越完整

以前我容易把“保留完整过程”和“保留全部文本”等同起来。后来我发现，真正重要的是关键状态没有丢失，而不是每句话都原样存在。

Agent 完成一个阶段后，通常不必保留所有试探过程。相比十几轮“尝试—报错—修改参数”，后续可能只需要最终参数、执行结果和验证状态。

但压缩也不能只保留一句模糊的“任务已完成”。时间、状态、来源和未解决问题如果被删掉，摘要本身又会成为新的误导。

所以，上下文管理并不是简单做加法或减法，而是要判断哪些信息仍会影响下一步决策。

我会先区分四类信息

不同信息在上下文中的作用不同，也应该采用不同的保留策略。

信息类型	主要作用	处理方式
目标与约束	决定任务方向和不可违反的边界	优先保留，更新时替换旧版本
当前状态	说明已经完成什么、下一步是什么	结构化保存，随执行持续更新
外部证据	为判断和回答提供依据	按当前问题检索，保留来源与时效
工具信息	告诉 Agent 能做什么以及如何调用	根据当前步骤按需加载

这个分类让我不再把所有内容都视为“聊天历史”。目标需要稳定，状态需要实时更新，证据需要重新检索，工具定义则只在可能使用时出现。

四个比扩大窗口更实用的动作

1. Select：只选择当前步骤真正需要的信息

Agent 在查询资料时，不一定需要看到完整的写入工具说明；在生成报告时，也不一定需要保留前面所有接口报错。

我现在会先判断“下一步要做什么”，再选择相关状态、证据和工具，而不是让模型从全部资料中自行筛选。

2. Compress：压缩过程，保留决策依据

压缩不是简单缩短文字。一个有用的阶段摘要，至少应该说明完成结果、关键参数、证据来源、失败原因和剩余问题。

换句话说，可以删掉重复对话，但不能删掉后续决策还需要依赖的事实。

3. Isolate：让不同任务拥有独立的工作区

多个子任务共享同一份上下文，看似方便，却容易发生信息串扰。独立的会话、Scratchpad 或子任务上下文，可以让每个执行单元只处理自己的局部问题。

完成后，子任务返回结构化结果，不把完整过程再次塞回主上下文。

4. Load on demand：工具和资料按需加载

当 Agent 可以连接几十甚至上百个工具时，一开始就加载全部定义会占用大量上下文，也会增加工具选择难度。

更合理的方式是先根据任务缩小候选范围，再加载少量相关工具的完整说明。资料也一样：先定位可能相关的文档，再取回当前步骤需要的片段。

按需加载让我意识到，Context Engineering 不只是“整理文本”，还包括设计信息在什么时机进入模型。

给上下文设置预算

上下文预算不应该只有一个总 Token 上限。更实用的方式，是为不同信息预留空间并设置淘汰规则。

例如，目标与安全约束必须始终保留；当前计划只保留最新版本；工具返回中的大段原始数据存放在外部，需要时再读取；历史对话则优先保留仍然影响当前任务的部分。

一个简单的上下文结构可以是：

固定区：系统规则、用户目标、安全边界
状态区：当前计划、已完成步骤、待处理问题
证据区：本轮检索片段及来源
工具区：当前候选工具及最近一次调用结果

这种划分不一定适合所有 Agent，但每一部分都应该有明确用途，不能因为“可能有用”就永久保留。

Context Engineering 的重点是取舍

学习这部分内容以后，我不再把大上下文看成省略设计的理由。

窗口越大，系统越容易把筛选责任推给模型。但 Agent 真正需要的，不是随时翻阅一间堆满资料的仓库，而是在执行每一步时，有一张干净的工作台，上面放着当前目标、可信证据和需要使用的工具。

好的上下文并不一定长。它应该相关、及时、边界清楚，并且能够说明信息从哪里来。

Context Engineering 不是想办法让模型看到更多，而是在正确的时刻，让它看到刚好足够的内容。

参考资料

• Anthropic：Effective context engineering for AI agents

• Sourcegraph：Context Engineering — A Practical Guide for AI Agents

• Anthropic：Code execution with MCP — building more efficient AI agents