上下文工程可以理解为：围绕下一步决策所需的信息，系统性地构建、选择、压缩、隔离并更新输入上下文的实践。它关注的是一套可重复、可度量、可持续运行的流程，让代理在每次调用大模型时都能拿到恰当且可信的信息集合，而不是把所有希望都押在一次性的提示文本上。换句话说，提示工程更像制定静态规则，强调怎么说；上下文工程更像治理动态信息环境，强调该给什么、何时给、给到什么粒度、如何保持一致。

代理的表现，不仅由模型能力决定，也由你为它构建的信息供应链决定。

1、上下文的组成

1.1 五类典型上下文及其作用边界

Agent 常见需要管理的上下文至少覆盖五类来源。

  • 第一类是指令，包括系统消息、提示、少样本示例以及工具使用规则，它们定义了代理的边界与行为准则；

  • 第二类是知识，包含事实性信息、数据库检索结果或长期记忆，很多场景会通过 RAG 把外部知识动态注入到上下文；

  • 第三类是工具，既包括可调用的外部函数/API/MCP 服务器定义，也包括工具调用后返回的结果与反馈；

  • 第四类是对话历史，它帮助代理保持连续性，但也是最容易膨胀并挤占窗口空间的部分；

  • 第五类是用户偏好，例如预算、品牌偏好、出行习惯等，适合沉淀为可复用的长期信息，在关键决策点被再次调用。

1.2 把所有内容都塞进上下文并不是好策略

上下文并非越多越好。输入过多会增加噪声并放大模型的注意力分配问题：

  1. 代理可能被无关历史牵引而忽略当前任务；

  2. 另一方面，当工具描述和候选工具数量变得庞大时，模型会出现选择困难甚至误调用。

上下文工程的目标不是堆料，而是通过结构化与分层，让代理在每个子任务上只看到完成这一步最需要的那部分信息，其余信息要么压缩为摘要，要么转移到上下文窗口之外的存储与运行时状态里。

2、规划阶段与运行期治理如何配合

2.1 规划阶段

先把结果定义清楚，明确代理完成任务后用户能获得什么变化或产出；再绘制上下文地图，回答代理为了达成结果需要哪些信息、这些信息可能存放在哪里；最后建立上下文管道，设计代理如何通过 RAG 、 MCP 服务器或其他工具去获取这些信息，并在何时注入到模型调用里。

这样做的价值在于把信息来源显式化、可追踪化，避免代理在运行时临时拼凑，导致流程不可控、难复现。

2.2 运行期治理

当信息开始持续流入上下文窗口，运行期治理比单次提示更关键，因为要保证历史信息的连贯，也要维护现有重点信息，同时还要保证上下文窗口的限定。

  • 用 Agent Scratchpad（草稿本）记录会话内关键事实但把它放在窗口外，以便按需检索；

  • 用 Memories（记忆）跨会话保存摘要、偏好与反馈；

  • 当窗口接近上限时进行压缩，通过摘要与修剪保留最相关信息；

  • 用多代理系统把复杂任务拆分给不同代理，让它们各自维护更小的上下文；

  • 用沙箱环境在外部执行代码或处理大文档，只把必要结果回填；

  • 用运行时状态对象保存分阶段产出，让主上下文始终聚焦当前子任务。

3、实践案例与失败模式

3.1 案例

如果只有提示工程，代理通常会停留在单轮问答，例如先问你什么时候去巴黎，后续再逐步询问预算、偏好与住宿需求。这种模式并非错误，但它把信息获取完全交给用户对话，效率低且容易遗漏关键约束。

引入上下文工程后，代理在回复前会主动拉取与决策相关的信息：比如检查日历确认可用日期、从长期记忆里回忆过往偏好（常用航司、预算、是否偏好直飞）、识别可用的订票与酒店工具，然后再给出更贴近目标的建议性方案。关键不在于更会聊天，而在于它拥有可重复的信息获取与注入流程。

3.2 四类常见上下文失败

上下文工程的另一面是失败治理。

  • 第一类是上下文中毒：幻觉或错误信息进入上下文并被反复引用，代理会围绕不存在的事实制定计划。应对方式是上下文验证与隔离，例如把关键航班信息在写入记忆前用实时 API 校验，发现异常就开启新的上下文线程防止传播。

  • 第二类是上下文分心：上下文过大时模型过度关注历史，出现重复或无用行为。应通过定期摘要把长对话压缩为与当前目标相关的短摘要。

  • 第三类是上下文混淆：当不必要的上下文（尤其是过多工具）导致误调用。建议用 RAG 做工具载入管理，把工具描述放入向量库并按任务检索，只给模型最相关的一小组工具（研究表明把工具选择限制在 30 个以内是有效的）。

  • 第四类是上下文冲突：上下文里同时存在相互矛盾的信息（例如先说经济舱、后改商务舱），导致推理不一致。可通过上下文修剪移除过时指令，或把冲突调和过程外卸到草稿区，确保主上下文只保留最终一致的约束。

结论可以概括为：上下文工程既是供给侧建设（信息管道），也是质量控制（验证、压缩、隔离与一致性维护）。