AI Agent 的上下文工程：一套实用的可靠性框架

AI Agent 的上下文工程（Context Engineering），是指在任务的每一步决定 Agent 应接收哪些信息、指令、工具、状态和记忆。目标并不是填满模型所支持的最大上下文窗口，而是提供一组最小但充分的高信号内容，让模型能够选对下一步行动，并产出可验证的结果。

本文面向正在设计或评估 AI Agent 的团队，尤其是需要让 Agent 研究资料、分析文件、调用工具并通过多步骤流程生成交付物的场景。我们会说明上下文工程与提示词工程的区别，给出一套实用的上下文筛选框架，并提供可直接用于真实工作流测试的模板。

研究与披露: 本文由 Ottermind 发布。我们于 2026 年 8 月 28 日查阅了 Anthropic、LangChain 与 OpenAI Agents SDK 的一手资料，以及 Lost in the Middle 研究论文。下文的五层上下文模型、Context Selection Loop、案例与模板均为原创编辑框架，不是 Ottermind 性能基准测试。

为什么 AI Agent 需要上下文工程

一次性的模型调用通常只有相对固定的输入：收到指令、生成答案，然后结束。Agent 改变了这个问题。它可能要搜索网页、读取文件、调用工具、观察结果、调整计划，并持续运行很多轮。每一步都会为下一步制造更多候选上下文。

不断增长的内容池里既有有用证据，也可能混入过时计划、重复的工具输出、失败尝试、互相冲突的指令或无关历史。把所有内容都继续传给模型并不是中性选择：它会增加成本与延迟，让关键证据更难被发现，还可能让模型继续遵循已经失效的假设。

Anthropic 将上下文描述为一种边际收益递减的有限资源，并建议寻找能够充分指导模型行为的最小高信号 Token 集合。长上下文研究也支持这种选择需求：Lost in the Middle 发现，即使全部输入都处于模型声明的上下文窗口内，当关键信息位于长输入中间时，模型表现仍可能下降。

因此，真正的工程问题不是“模型最多能读多少”，而是：

Agent 为了完成下一项判断究竟需要知道什么？信息应来自哪里？哪些内容应该留在模型上下文之外？

上下文工程与提示词工程有什么区别

提示词工程与上下文工程存在交集，但它们处理的范围不同。

提示词可以要求 Agent 创建一份有来源的市场分析备忘录；上下文工程则决定 Agent 在规划、研究或起草时，能看到哪些产品文档、访谈笔记、搜索结果、历史决策、工具说明和验收标准。

提示词质量依然重要。区别在于 Agent 的上下文是动态的：搜索结果会进入系统，文件会更新，审核者会批准一个方向，工具可能失败，新的约束也会出现。好的上下文工程会持续更新模型可见状态，而不是把完整任务历史变成一段没有层次的超长对话。

如果你需要定义目标、输入资料、约束和验收标准，可以先阅读 Ottermind AI 提示词指南。上下文工程发生在初始 Brief 进入动态、多步骤工作流之后。

Agent 上下文的五个层次

把上下文当成一大段文字，会掩盖不同信息的所有权与生命周期。更实用的方式是将它拆成五层。

并非所有层都应该完整进入模型上下文。OpenAI Agents SDK 会区分应用代码可访问的本地上下文与 LLM 可见上下文。用户 ID、数据库连接、权限判断逻辑或密钥可能是工具运行的必要条件，但不应自动发送给模型。

这种分离同时改善质量和安全：把运行依赖保留在应用状态中，只向模型暴露它完成当前判断真正需要的信息。

Context Selection Loop：上下文筛选循环

Context Selection Loop 是 Ottermind 提出的一套编辑框架，用来决定每个关键步骤之前 Agent 应该看到什么。

1. 先说清下一项判断

不要一开始就为整个项目组装全部上下文，而要先定位 Agent 面前最近的一项判断。

例如：

• 哪三个来源可以用于定义市场？
• 当前证据是否足以推荐一个定位方向？
• 哪个工具能提取所需字段，同时不修改源文件？
• 草稿是否符合已批准的论断和格式？

判断越明确，相关性就越容易验证。如果某条信息无法影响这项判断，它可能就不应该进入下一次模型调用。

2. 按层收集候选上下文

盘点候选指令、任务要求、证据、工具和状态，并保留来源元数据。一条可用证据不仅是一段文字，还应包含出处、发布时间或获取时间，以及它是否有资格支持对应论断。

检索不等于筛选。搜索可能返回二十个看似相关的网页，上下文工程要决定哪些段落足够相关，值得进入 Agent 的工作上下文。

3. 用五项标准过滤

逐项检查候选内容：

1. **相关性：**这条信息能否改变下一项判断？
2. **权威性：**它是不是支持该论断的正确来源？
3. **时效性：**对当前任务来说是否足够新？
4. **一致性：**是否与更新的决策或更强来源冲突？
5. **权限：**模型是否被允许看到和使用它？

一条内容可能相关，却依然无法通过权威性或权限检查。例如，竞争对手整理的价格信息对比较文章有用，但当前官方价格页通常是更强来源；客户记录可能与支持任务相关，却不应该进入无关的模型调用。

4. 整理选中的上下文

筛选决定使用什么，整理则让内容真正可用。

• 把目标、约束和输出要求放在容易找到的位置。
• 标记来源，明确区分证据与指令。
• 删除重复工具输出和页面导航噪声。
• 总结长历史，但保留已批准决策、未解决问题和来源链接。
• 需要比较或验证时使用结构化字段。
• 专门任务如果会干扰主任务，就隔离执行。

LangChain 将常见方法归纳为写入、选择、压缩和隔离上下文。这些并不是互斥选项：长时间运行的 Agent 可以把重要状态写入持久存储，为下一步检索少量相关内容，压缩旧历史，并把专业子任务隔离到独立上下文中。

5. 观察结果并更新状态

模型或工具执行后，要检查发生了什么变化：

• 结果是否回答了当前问题？
• 是否出现新事实、新决策或冲突？
• 哪些临时上下文应该丢弃？
• 哪些信息需要写入状态或长期记忆？
• 下一项判断是什么？

这样才完成闭环。上下文工程不是一次性的输入准备，而是伴随 Agent 运行的控制过程。

案例：从研究资料到决策备忘录

假设产品团队要求 Agent 制作一份竞争对手决策备忘录。资料包里有六个产品网页、三份客户访谈、一个旧战略演示文稿、一张功能需求表，以及最新路线图会议笔记。

较弱的做法是把所有文件一次性上传并要求给出建议。模型可能把过时战略与当前决策混在一起，过度相信重复出现的营销论断，或者完全忽略验收标准。

经过上下文工程设计的流程会分阶段运行：

这个例子并不能证明某个模型或产品一定会因这种流程而表现更好。它展示的是怎样让 Agent 的信息环境可检查。真实实施时，应使用代表性任务对比输出，并记录准确率、人工干预次数、延迟、成本和审核接受率。

上下文工程最佳实践

从最小充分上下文开始

补充缺失证据时，更多上下文可能有帮助；加入干扰项时，它也可能有害。先使用能力足够的模型、清晰的任务契约和完成该步骤所需的最少证据，再根据实际失败补充指令与材料。

分开保存事实、指令和状态

指令规定 Agent 应做什么，证据支持论断，状态记录已经发生了什么。混在一起会让冲突难以解决。使用明确章节或结构化记录，让系统能够应用正确的优先级规则。

压缩时保留来源

摘要可以节省 Token，也可能抹掉不确定性和出处。高质量摘要应保留来源链接、日期、已批准决策、争议点和未解决问题。不要把“来源 A 认为 X、来源 B 反对”压缩成“X 是事实”。

为工具设计狭窄而有用的契约

工具说明和工具结果也是上下文的一部分。只返回任务所需字段，采用可预测的 Schema，并让错误信息足够可执行。返回整页 HTML 的搜索工具，会比返回标题、URL、日期和相关摘录制造更多上下文管理工作。

工具可见性也是权限边界。只显示当前阶段需要的能力，并在工具或应用内部执行权限检查，不要只依赖提示词约束。

保存决策，而不是保存每个 Token

长期记忆应保留有用且可纠正的信息：批准的偏好、重复使用的约束、最终交付物，以及带日期或来源的经验。保存所有对话会让后续检索充满噪声，也可能把错误永久当成规则。

使用同一任务评估上下文变化

测试新的检索规则、摘要格式、工具描述或记忆策略时，应固定任务与验收标准。比较准确率、无来源论断、工具选择、人工干预、延迟、成本和审核结果，否则无法判断变化来自上下文优化还是工作负载改变。

常见失败模式

上下文倾倒

系统把所有消息、文件和工具结果继续传递。关键信息被无关历史淹没，成本与延迟不断增长。

**更好的做法：**围绕下一项判断选择上下文，把完整记录留在模型窗口之外。

过早压缩

系统在尚不清楚哪些细节重要时就开始总结，导致限制条件、来源冲突和精确要求消失。

**更好的做法：**在判断明确前保留原始证据，压缩时继续保留来源和开放问题。

过时记忆

旧偏好、价格、计划或产品事实静默覆盖当前证据。

**更好的做法：**记录日期和来源类型，区分事实与偏好，并规定当前证据何时取代旧记忆。

工具过载

模型看到几十甚至上百个描述相近的工具，容易选择低效工具或生成无效参数。

**更好的做法：**只暴露当前阶段需要的小型工具集，使用清晰契约，并在模型之外执行权限控制。

状态变化不可见

Agent 更新计划、记忆或记录，却没有留下可检查的决策轨迹。

**更好的做法：**记录改变了什么、依据什么证据，以及是否经过人工批准。

没有完成定义

上下文里有大量背景资料，却没有验收标准。Agent 可能不断研究，或者返回一份看似完整却无法判断质量的结果。

**更好的做法：**在执行前明确交付物、受众、必要证据、格式和停止条件。

可复用的上下文工程模板

以下 Brief 可用于设计单个 Agent 步骤或短工作流。

任务与下一项判断：
完成[具体任务]。Agent 当前必须判断[需要作出的判断]。

完成定义：
- 交付物：[成果或行动]
- 受众：[个人或团队]
- 必要证据：[来源或字段]
- 验收标准：[质量与格式检查]
- 在以下情况停止或升级：[风险、缺失证据或权限边界]

行为上下文：
- 遵循[政策、来源优先级与约束]。
- 未经批准，不得[编造、发送、发布、购买、删除或修改记录]。

证据上下文：
- 使用[选中的文件、段落、记录或链接]。
- 将[来源]视为[论断类型]的权威来源。
- 保留引用，并标记冲突。

操作上下文：
- 可用工具：[少量相关工具]。
- 所需权限：[读取、起草、写入、批准]。
- 工具结果返回格式：[Schema 或字段]。

连续性上下文：
- 当前状态：[已完成步骤与当前计划]。
- 已批准决策：[决策记录]。
- 开放问题：[会影响下一步的信息缺口]。

步骤完成后：
返回结果、使用的来源、假设、未通过的检查、状态变化和建议的下一项判断。

模板有意保持明确。当工作流已经可靠后，部分字段可以由应用状态自动生成，而不需要反复放入模型可见文本。

怎样评估上下文质量

不要只看 Agent 有没有生成答案，还要评估答案是否可信、是否可用。

正确目标不是不计代价地减少 Token，而是找到能够让任务稳定产生预期行为的最少上下文。

从一个边界清晰的 Agent 任务开始

当你能够检查真实任务的输入、判断、工具、状态和输出时，上下文工程才会变得具体。先选择一个边界清晰的工作流，例如把资料包转换成研究备忘录、Campaign Brief、报告或演示文稿。定义验收标准，在每个阶段运行 Context Selection Loop，再把结果与只使用一次 Prompt 的基线进行比较。

要了解更完整的执行模型，可以阅读什么是 Agentic Workflow。如果想了解记忆、工具、审核和最终交付物如何组合成产品类别，可以参考最佳 AI Agent Workspace。对于研究型任务，AI 研究助手指南介绍了如何评估检索、引用、分析和报告生成。

在 Ottermind 中，把来源文件、链接、约束和所需交付物放到同一个工作空间。先要求生成来源地图和计划，审核证据与方向，再继续制作任务所需的报告、页面或演示文稿。目标不是写出更长的 Prompt，而是建立一条从上下文到完整工作的可控路径。

来源

• Anthropic：Effective context engineering for AI agents
• LangChain：Context engineering in agents
• LangChain：Context Engineering
• OpenAI Agents SDK：Context management
• OpenAI Agents SDK：Agent memory
• Lost in the Middle：How Language Models Use Long Contexts
• Manus：Context Engineering for AI Agents