上下文工程：给智能体喂对信息

这篇适合谁，读完能做什么

适合正在做智能体、发现它时而答非所问、时而忘了前面说过什么的开发者。读完你应该能把一个任务拆成「需要什么信息、从哪拿、怎么放进上下文」三步来规划，并知道四类常见失败各自的征兆和对策。^[1]

上下文工程是什么

对智能体来说，上下文决定它下一步怎么规划、做什么动作。上下文工程就是确保智能体拿到完成下一步所需的正确信息。^[1]

上下文窗口的大小是有限的，所以搭建智能体的人需要一套流程，管理信息的添加、移除和压缩。^[1]

它和提示词工程（prompt engineering）的区别在于范围。提示词工程关注一组静态的指令，用规则引导智能体。上下文工程管理的是一组动态变化的信息，包括最初的提示词在内，要保证智能体在整个过程中都拿到需要的东西。它的目标是让这件事可以重复、可靠地做好。^[1]

上下文里装的是哪些东西

上下文不是单一的东西，智能体需要的信息可能来自多个来源。常见的有五类：^[1]

• 指令：智能体的「规则」，包括提示词、系统消息、少样本示例（few-shot），以及对可用工具的描述。提示词工程的重点正是在这里和上下文工程交汇。
• 知识：事实、从数据库检索到的信息，以及智能体积累的长期记忆。需要访问多个知识库时，可以接入检索增强生成（RAG）系统。
• 工具：智能体可以调用的外部函数、API 和 MCP 服务器的定义，以及调用后拿到的结果。
• 对话历史：和用户的持续对话。对话越往后越长、越复杂，占用的上下文空间也越大。
• 用户偏好：长期了解到的用户喜好和忌讳，可以存下来，在关键决定时调用。

先规划：三个问题

好的上下文工程从规划开始。可以按三步想：^[1]

1. 定义清楚结果：问自己，智能体完成任务后，世界会是什么样子？用户在交互之后应该得到什么变化、信息或回应。
2. 画出上下文地图：智能体完成这件事需要哪些信息，这些信息分别在哪里。
3. 搭建上下文管道：智能体怎么拿到这些信息？可以用 RAG、MCP 服务器或其他工具。^[1]

六种管理上下文的办法

信息进入上下文窗口之后，就要主动管理。常用的办法有六种：^[1]

1. 草稿本（scratchpad）：智能体在一次会话中记下与当前任务相关的笔记。笔记放在上下文窗口之外，存为文件或运行时对象，需要时再取回。
2. 记忆（memories）：跨多次会话保存和取回相关信息，比如摘要、用户偏好和反馈。草稿本管的是一次会话，记忆管的是多次会话。
3. 压缩上下文：窗口快满时，用摘要或裁剪的方式，只保留最相关的信息，或删掉较早的消息。
4. 多智能体系统：每个智能体都有自己的上下文窗口，所以多智能体本身就是上下文工程的一种形式。上下文如何在智能体之间共享和传递，需要提前规划。
5. 沙箱环境：如果智能体要运行代码，或处理大篇幅的文档，结果会占用大量 token。沙箱可以运行这些代码，只把结果和必要信息读回来，而不是把全部内容留在上下文里。
6. 运行时状态对象：把复杂任务中每个子任务步骤的结果分别存放在容器里，让上下文只和当前子任务相关。^[1]

检查模型实际收到了什么

用了某种办法之后，值得检查下一次模型调用究竟拿到了什么。可以问一个调试问题：智能体是加载了太多上下文，加载错了，还是漏掉了它需要的上下文？^[1]

检查不需要把原始提示词、工具输出或记忆内容全部打印出来。线上环境更适合记录小型的检查记录，只包含数量、编号、哈希和策略标签：^[1]

• 筛选：候选的文本块、工具或记忆各有多少，选中了多少，哪条规则或分数把其余的过滤掉了。
• 压缩：来源范围或追踪编号、摘要的编号、压缩前后估算的 token 数，以及原始内容是否被排除在下一次调用之外。
• 隔离：哪个子任务在独立的智能体、会话或沙箱里运行，返回了什么有界的摘要，大体积的工具输出是否留在了父智能体的上下文之外。
• 记忆与 RAG：记录检索文档的编号、记忆编号、分数、选中的编号和脱敏状态，不存完整的检索文本。
• 安全与隐私：优先用哈希、编号、token 区间和策略标签，代替敏感的提示词文本、工具参数、工具结果和用户记忆正文。

目标不是保留更多上下文，而是留下足够的证据，让开发者能看出哪个策略起了作用，它是否按预期改变了下一次模型调用。^[1]

四类常见失败和对策

上下文出问题时，智能体的表现往往像是「突然变笨」。本文按原理把它们分成四类，每类都配一个订机票的例子。^[1]

投毒（Context Poisoning）：幻觉（大模型编造的错误信息）或错误进入上下文，并被反复引用，导致智能体去追求不可能完成的目标。对策是上下文验证和隔离：信息进入长期记忆之前先验证，发现可能被污染时，开启新的上下文线程，阻止错误信息扩散。例如，智能体编造了一个根本不存在的小机场直飞远方国际城市的航班，之后每次订票都在找这条不存在的航线。对策是在航班信息进入工作上下文之前，先用实时 API 验证航班和航线是否存在，验证失败的信息就被隔离，不再使用。^[1]

干扰（Context Distraction）：上下文过大，模型把注意力放在累积的历史上，而不是训练中学到的东西，导致重复或无用的动作。有时窗口还没满，错误就已经出现。对策是上下文摘要：定期把累积的信息压缩成更短的摘要，保留重要细节，去掉冗余的历史。例如，聊了很久的梦想目的地，之后用户只问「帮我找下个月的便宜机票」，智能体却一直纠缠旧的行程。对策是在若干轮之后，只摘要最近且相关的部分，比如当前的日期和目的地，丢弃无关的历史。^[1]

混淆（Context Confusion）：不必要的上下文，常见的是过多的可用工具，让模型给出糟糕的回答或调用无关的工具。小模型尤其容易这样。对策是用 RAG 管理工具清单：把工具描述存进向量数据库，每个任务只选最相关的工具。研究结果提示，工具选择应限制在 30 个以内。例如，智能体有几十个工具，用户问「在巴黎怎么出行最好」，它却可能去调用订机票，或者租车，而用户其实更喜欢公共交通。对策是根据问题检索，只把 rent_car、public_transport_info 这样最相关的工具交给模型。^[1]

冲突（Context Clash）：上下文里存在相互矛盾的信息，导致推理前后不一致，或最终回答很差。这往往发生在信息分阶段到达，早期的错误假设仍留在上下文里时。对策是上下文修剪和卸载：新信息到达时，删掉过时或矛盾的内容；卸载则是给模型一个独立的草稿本，在不占用主上下文的情况下处理信息。例如，用户先说要经济舱，后来又说这次改坐商务舱，两条指令都留着，智能体拿到的搜索结果就会互相矛盾。对策是新指令与旧指令冲突时，删掉或明确覆盖旧指令，或者先在草稿本里消解冲突，只让最终一致的指令指导行动。^[1]

订机票的例子

同样是「帮我订一趟去巴黎的行程」，只用提示词工程的智能体会先问用户想什么时候出发。用了上下文工程的智能体，在回答之前可能先查用户的日历，从长期记忆里调出以往的出行偏好，再确定有哪些机票和酒店工具可用。回答会贴合用户的实际情况。^[1]

需要注意的地方

• 上下文工程不是多塞信息。目标是让智能体拿到的信息刚好够用，并且能证明它起了作用。^[1]
• 记录检查信息时，尽量不要保存用户记忆的正文或敏感的工具参数，只保留编号和标签。^[1]
• 本文只讲思路和分类，不涉及具体的代码实现。

下一步

想了解智能体的长期记忆如何实现，可以接着看记忆相关的内容。关于 RAG 和上下文窗口的基础概念，可以参考词条页面。^[1]

本文改编自 Microsoft 开源课程《AI Agents for Beginners》第 12 课^[1]，原文以 MIT 许可证发布。