Agent上下文工程开始系统化

上下文工程不再只是“把 Prompt 写好”

Context Engineering 正在从零散技巧变成一套可以设计、测量和运维的 Agent 系统方法。 10 月 24 日，开发者 David Breunig 发布的《The State of Context Engineering》再次梳理了这个正在成形的领域；到了今天，也就是 2026 年 10 月 25 日，业界讨论的重点已经明显变化：问题不再是怎样写出一句更聪明的提示词，而是一个运行几十乃至数百步的 Agent，应该在每一步看到什么、忘掉什么，以及如何避免被自己的历史记录拖垮。

上下文工程是系统化设计、选择、组织、压缩和维护模型输入信息的工程实践。 这里的“上下文”不只是用户问题和系统提示，还包括工具定义、任务计划、检索结果、文件内容、工具调用返回、阶段性结论、错误记录、用户偏好以及其他 Agent 交付的中间产物。

提示词工程只是上下文工程的一个子集。 Prompt Engineering 主要优化单次输入的措辞和结构；Context Engineering 则管理一个动态信息系统，核心问题是“当前这一步，模型最需要知道什么”。对于聊天机器人，两者的差别可能不明显；对于持续调用工具的 Agent，这个差别直接决定成本、延迟和任务成功率。

| 概念 | 主要处理对象 | 解决的问题 | 常见失效模式 | |---|---|---|---| | 提示词工程 | 单次指令、示例和格式约束 | 怎样让模型理解当前要求 | 指令模糊、格式漂移 | | RAG | 外部知识检索结果 | 怎样补充模型不知道的信息 | 召回错误、排序不佳、材料过多 | | 记忆系统 | 跨轮次保存的状态与经验 | 怎样在未来恢复有价值的信息 | 旧信息污染、记忆冲突 | | 上下文工程 | 模型每一步实际看到的完整工作集 | 怎样在有限窗口内维持有效状态 | 上下文腐化、成本失控、长程任务漂移 |

长窗口没有消灭问题，只是推迟了事故

上下文窗口是模型在一次推理中能够直接处理的 Token 上限，而不是可靠的长期记忆。 即使模型可以接收数十万乃至更多 Token，把所有历史信息原封不动塞进去也并不等于模型会正确使用这些信息。窗口容量回答的是“能不能装下”，上下文工程回答的是“装进去是否值得”。

上下文腐化是无关、过时、重复或互相矛盾的信息逐步削弱模型判断能力的现象。 一段旧的任务计划、一次已经失败的工具返回、同一事实的三个不同版本，都可能继续留在窗口里，并在后续步骤中获得不应有的权重。模型没有数据库那样严格的版本控制，它可能把最新事实和旧事实混在一起，生成一个语言流畅但状态错误的答案。

Agent 的上下文记录通常按步骤线性增长，但累计推理成本可能接近二次增长。 假设一个任务被拆成 10 个子任务，每个子任务调用两次工具；如果每次调用产生一条请求记录和一条返回记录，再加上一条初始规划，系统会新增 41 条记录。记录数量本身是线性的，不是严格意义上的指数增长；真正麻烦的是，如果第 1 步发送一份历史、第 2 步发送两份历史，直到第 n 步发送 n 份历史，那么累计输入量近似为 n(n+1)/2，会随步骤数呈二次增长。

工具定义已经成为 Agent 最容易被忽视的固定 Token 税。 一个接入大量 MCP Server 或内部工具的平台，可能在任务开始前就加载几十个工具的名称、参数 Schema、说明和示例；这些定义即使本轮完全用不到，也会占据上下文、增加首 Token 延迟，并干扰模型进行工具选择。MCP 是一种连接模型与外部工具、数据源的开放协议，但协议统一不代表所有工具都应该同时暴露给模型，具体规范可在 Model Context Protocol 官方 GitHub 查看。

系统化的第一步，是把上下文拆成不同层

生产级 Agent 的上下文应该是一组有来源、有优先级和有生命周期的信息对象，而不是一长串聊天消息。 如果系统只保存 role 和 content，后续就很难判断一段信息来自用户、检索器还是工具，也无法知道它是否已经过期、是否允许压缩，以及压缩后能否恢复原文。

一套可维护的上下文至少应区分六个层次。 这些层次不是为了增加架构复杂度，而是为了让系统能够采用不同的更新和淘汰策略：

1. 策略层：系统角色、安全边界、输出规范和不可违反的约束。
2. 任务层：用户目标、验收标准、当前计划和尚未解决的问题。
3. 能力层：本轮可用的工具、工具说明、参数约束与权限范围。
4. 证据层：检索文档、网页片段、数据库结果和工具返回。
5. 状态层：已完成步骤、当前工作区、失败原因和下一步动作。
6. 记忆层：用户偏好、历史经验、长期事实和可复用任务模板。

来源追踪是上下文维护的最低要求。 每一条重要信息都应附带来源、写入时间、适用任务、版本、可信度和原始内容引用；否则，压缩器生成的总结一旦出错，系统很难定位是哪一份原始证据被遗漏或曲解。

优先级应该由任务相关性、可信度和新鲜度共同决定。 用户刚刚确认的需求通常应覆盖旧的会话摘要，结构化数据库结果通常应优先于模型自己生成的猜测，而安全策略不能因为 Token 紧张被摘要器删除。简单按时间截断历史，是最便宜也最容易破坏任务状态的方案。

五类手段解决的是五种不同问题

目前较成熟的上下文工程可以归纳为外置、选择、压缩、隔离和缓存五类手段。 这五类方法不是互斥的竞争方案，而是一条 Agent 执行链上的不同控制点。

| 策略 | 核心做法 | 最适合解决的问题 | 主要风险 | |---|---|---|---| | 外置 Offload | 把完整内容写入文件、对象存储或数据库，窗口中只保留摘要和引用 | 工具返回太长、文件和网页占用过多 | 摘要不足导致模型不知道何时取回原文 | | 选择 Select / Retrieve | 按当前步骤检索所需片段，而非重放全部历史 | 长期资料库、跨会话记忆 | 召回遗漏、排序错误、权限过滤不严 | | 压缩 Compress / Reduce | 将旧对话、执行轨迹和证据改写成更短表示 | 长任务持续膨胀 | 细节丢失、否定条件和异常信息被抹平 | | 隔离 Isolate | 让子 Agent 在独立窗口中处理局部任务，只返回交付物 | 多 Agent、并行研究、复杂工具链 | 子任务边界不清，交接摘要失真 | | 缓存 Cache | 保持稳定前缀，复用相同上下文的计算结果 | 重复系统提示、稳定工具集合 | 只改善成本和延迟，不自动提升正确率 |

外置的关键不是把内容移走，而是保留足够好的索引。 例如，一个研究 Agent 不应把整篇网页持续放在窗口里，而应保存标题、来源、时间、主题、关键结论、原文位置和内容指纹；当后续步骤需要核对数字或原句时，再读取对应片段。Chroma 等向量数据库可以承担语义检索，但向量相似度只能回答“看起来相关”，不能替代来源验证和版本管理，具体实现可参考 Chroma 官方 GitHub。

选择策略的价值在于把“曾经出现过”改造成“当前确实需要”。 一个编程 Agent 修复测试失败时，通常需要当前报错、相关源文件、最近改动和测试命令，而不需要重新读取 30 步之前的依赖安装日志。检索器应该围绕当前子目标工作，而不是围绕整场会话做一次宽泛搜索。

隔离策略的本质是控制信息传播范围。 负责搜索资料的子 Agent 不需要获得用户全部私人偏好，负责运行测试的子 Agent 也不必看到市场分析材料；主 Agent 只接收结构化交付物、证据引用和未解决问题。隔离既节省 Token，也能缩小提示注入和错误状态扩散的影响面。

缓存策略是性能工程，而不是语义正确性的替代品。 KV 缓存是模型对已处理前缀计算结果的复用机制，稳定的系统提示和工具定义越靠前、变化内容越靠后，通常越容易复用缓存。频繁调整工具顺序、在固定提示前插入时间戳，或者每轮重新生成整段系统说明，都可能让缓存失效。

压缩不能只做一段“对话摘要”

上下文压缩是把高体积历史转换成低体积但仍足以支撑后续决策的表示过程。 一个合格的压缩结果不应该只是“用户和助手讨论了部署问题”，而要明确当前目标、已经确认的事实、采用过的方案、失败原因、待办事项和可回溯证据。

压缩应该按信息类型分别处理。 工具日志可以去掉重复进度信息，保留退出码、异常堆栈和关键输出；检索材料可以抽取事实、数字和来源；任务历史可以折叠为状态机；用户要求则应尽量保留原文，尤其是否定条件、边界条件和验收标准。

可逆压缩是生产系统比普通摘要更稳妥的选择。 可逆压缩并不要求摘要能够逐字恢复原文，而是要求系统保留指向原始数据的引用，使模型或开发者可以在需要时重新展开。摘要是导航层，原始记录才是证据层；删除原始记录的“压缩”，本质上是在用不可验证的模型输出覆盖事实。

错误信息比成功信息更不应该被过度压缩。 长程 Agent 最危险的行为之一，是在摘要时只保留“已经尝试过方案 A”，却删掉“方案 A 因权限错误失败”的原因，导致模型几步之后再次执行同一路径。错误类型、输入参数、环境状态和失败时间至少要结构化保留。

压缩触发机制应该由预算和任务阶段共同决定。 团队可以把上下文窗口的 60% 至 70% 设为初始预警区间，并为模型输出、临时检索结果和工具返回预留 20% 至 30% 的空间，但这些比例只是起始配置，不是通用标准。更稳妥的做法是在子任务结束、工具产生超长结果、检索主题切换或模型开始重复动作时主动压缩，而不是等窗口即将溢出才处理。

记忆维护比“保存一切”更重要

Agent 记忆是能够跨步骤或跨会话恢复的持久化状态，而不是聊天历史的永久副本。 真正有价值的记忆通常包括稳定偏好、已经验证的事实、持续项目状态和可复用经验；临时闲聊、过期计划和未经确认的模型推断，不应该自动升级为长期记忆。

分层记忆适合用短期、中期和长期三个时间尺度管理。 短期记忆服务于当前任务，需要高频更新；中期记忆保存近期项目状态，需要周期性合并；长期记忆保存稳定偏好和经过验证的知识，需要严格的写入、修订与删除机制。LangGraph 将状态、持久化和执行图结合，是目前观察 Agent 状态管理的一种代表性实现，代码与设计可参考 LangGraph 官方 GitHub。

记忆写入必须比记忆读取更谨慎。 用户某一次要求“这次用表格回答”，不能直接推导成“用户永远偏好表格”；模型在一次失败任务中形成的猜测，也不应成为后续任务的事实。长期记忆最好具备明确触发条件，例如用户直接确认、同一偏好重复出现、外部系统提供权威状态，或者人工审核通过。

记忆冲突需要显式解决，而不是让模型自行折中。 当旧记忆记录“项目使用 Python 3.11”，新仓库配置显示已经升级到 Python 3.13，系统应依据来源可信度和更新时间标记旧记录失效，而不是把两个版本同时送入上下文。每条记忆都应支持覆盖、合并、过期和撤回。

上下文工程必须拥有自己的评测指标

只看最终回答是否正确，无法定位上下文系统的问题。 一个任务失败，可能是检索没有召回、压缩删掉关键约束、工具选择受无关定义干扰，也可能是模型本身推理错误；如果这些环节没有独立指标，团队只能继续“改 Prompt”碰运气。

生产环境至少应追踪八项上下文指标。 这些指标共同描述成本、质量和稳定性：

• 输入 Token/步：每一步实际发送给模型的 Token 数。
• 累计 Token/任务：完成整个任务消耗的总输入和输出 Token。
• 有效上下文率：被模型引用或影响决策的信息占已发送信息的比例。
• 检索命中率：正确证据是否进入候选结果。
• 压缩保真率：关键事实、约束和错误原因在压缩后是否保留。
• 缓存命中率：稳定前缀被复用的比例。
• 重复动作率：Agent 是否因状态遗失反复调用同一工具或重试同一路径。
• 长程任务成功率：任务步数增长后，完成率下降了多少。

上下文评测应该包含“删除测试”和“污染测试”。 删除测试逐项移除上下文片段，检查哪些内容对结果真正有贡献；污染测试则主动加入过时记录、冲突事实和无关工具，观察 Agent 能否维持正确决策。前者可以发现 Token 浪费，后者可以测出系统对现实噪声的抵抗力。

离线回放是调整压缩器和检索器的低风险方式。 团队可以保存脱敏后的任务事件流，在不影响线上用户的情况下，更换摘要策略、召回数量和工具路由规则，并比较任务完成率、平均延迟和总 Token，而不是凭单个案例判断优化是否有效。

一套更实际的落地顺序

大多数团队不需要先造一个全自动“上下文优化模型”。 更可行的路径是先建立可观测性，再进行规则化治理，最后才让模型参与动态决策。

1. 记录完整事件流。 保存每一步的输入来源、工具调用、状态变更和输出，不把聊天消息数组当成唯一事实源。
2. 拆分固定与动态上下文。 固定策略放在稳定前缀，当前任务、检索结果和工具返回按需装配。
3. 建立工具路由。 先选择当前需要的工具集合，再把对应定义交给模型，避免一次加载全部能力。
4. 外置大对象。 文件、网页、日志和表格保留原文存储，活动窗口只放摘要、元数据和引用。
5. 引入检查点。 每完成一个子任务，就更新目标、事实、失败记录和待办列表。
6. 分类型压缩。 对对话、工具日志、证据和计划使用不同压缩模板。
7. 加入回填能力。 当模型需要核对细节时，能够根据引用重新读取原文。
8. 最后再做模型驱动优化。 让专门模型决定何时压缩、保留什么和写入哪些记忆，并用离线评测约束其行为。

上下文优化器将成为 Agent Runtime 的核心组件。 它类似操作系统的内存管理器：不是让程序无限占用内存，而是在任务运行期间持续装入工作集、换出冷数据、维护索引、处理冲突，并给关键过程保留空间。不同之处在于，上下文中的信息具有语义，一次错误换出可能不会立即崩溃，却会在十几步之后变成错误决策。

判断：窗口会继续变大，但上下文工程不会消失

更大的上下文窗口只会提高工程上限，不会取消信息选择。 数据库容量变大没有消灭索引，计算机内存增加也没有消灭缓存；同样，百万 Token 窗口也不会让重复日志、过期事实和几十个无关工具突然变得有用。

上下文工程已经具备成为独立系统层的条件。 它有明确的对象——模型工作集，有稳定的操作——写入、选择、压缩、隔离和缓存，也有可以量化的指标——Token、延迟、召回、保真度和长程成功率。接下来的竞争不会只发生在基础模型之间，也会发生在谁能让同一个模型用更少、更干净、更及时的信息完成更长任务。

对 Agent 开发者而言，最重要的设计原则可以压缩成一句话：不要问窗口还能塞多少，而要问下一步究竟需要什么。 一个可靠的 Agent 不应该记住一切，它应该知道哪些事实必须保留、哪些材料可以暂存、哪些错误不能遗忘，以及何时回到原始证据重新确认。

参考来源

• Model Context Protocol GitHub：MCP 官方组织与相关规范实现，用于理解工具和数据源如何接入 Agent。
• LangGraph GitHub：面向有状态、长流程 Agent 的编排框架，可参考其状态持久化与检查点设计。
• Chroma GitHub：开源向量数据库项目，可用于实现外部记忆和语义检索。
• Anthropic Cookbook GitHub：包含长上下文、工具使用和 Agent 工作流相关实践。
• OpenAI Cookbook GitHub：包含检索、评测、工具调用与多步任务设计示例，可用于构建上下文评测基线。