Appearance
上下文工程
构建可靠的智能体，必须处理好上下文信息，而不仅仅是写好提示词。本节将介绍“上下文工程”的概念及其在智能体中的实践。
引言
- 什么是上下文工程，与提示工程有何不同；
- 如何编写、筛选、压缩与隔离上下文；
- 常见的上下文故障及应对策略。
学习目标
- 定义上下文工程，并与提示工程区分开；
- 识别 LLM 应用中的关键上下文组成；
- 掌握编写、选择、压缩、隔离上下文的策略；
- 识别常见上下文失败（投毒、分心、混淆、冲突）并进行缓解。
上下文工程是什么？
上下文驱动智能体规划下一步动作。由于上下文窗口有限，我们需要建立流程来增删、压缩与管理信息，确保智能体始终拥有“合适的材料”。
提示工程 vs. 上下文工程
- 提示工程：撰写一组静态指令，定义规则；
- 上下文工程：在整个对话/任务生命周期中，动态地管理初始提示、工具结果、用户输入等多种信息，让流程可靠可重复。
上下文类型
智能体可能需要管理以下信息：
- 指令：系统消息、Few-shot 示例、工具描述等；
- 知识：事实、数据库信息、长期记忆；
- 工具：外部函数/API/MCP Server 的定义与返回结果；
- 会话历史：与用户的对话记录，会逐步膨胀；
- 用户偏好：长期积累的喜好与反馈。
有效的上下文工程策略
规划层面
- 定义清晰的目标：回答“智能体完成任务后，世界应该发生什么变化？”
- 绘制上下文地图：找出完成任务所需的信息来源。
- 建立上下文管道：规划信息的获取方式，例如 RAG、MCP、工具调用等。
实践层面
- Scratchpad（速记本）：在会话期内记录关键信息，存放于上下文窗口之外，以便随时回查。
- Memories（记忆）：跨会话保存用户偏好、总结、反馈等长期信息。
- 上下文压缩：当窗口接近上限时，可通过摘要、截断等方式保留最相关内容。
- 多智能体系统：不同智能体拥有独立上下文，需要设计上下文传递与共享机制。
- 沙箱环境：对于代码执行、长文档处理等场景，可在沙箱中执行，仅回传关键结果，减少上下文占用。
- 运行时状态对象：为复杂任务创建数据容器，逐步记录各子任务结果，避免主上下文混乱。
示例
假设用户说：“帮我订一趟巴黎之旅。”
- 仅做提示工程的智能体可能只会问：“你想什么时候去？”
- 采用上下文工程的智能体会在回答前：
- 检查日历获取可用日期；
- 回忆历史偏好（航空公司、预算等）；
- 确认可用的工具（机票、酒店等）；
- 然后给出个性化回复：“你好，XX！你十月第一周有空，要不要我帮你查查直飞巴黎、价格在 XXX 的航班？”
常见上下文失败
Context Poisoning（上下文投毒）
- 问题：幻觉或错误信息进入上下文后被反复引用，导致追逐错误目标；
- 策略：启用验证与隔离机制，先验证数据再写入长期记忆，发现异常立即重开上下文线程。
- 旅行示例：智能体幻觉出不存在的航班并写入上下文，之后一直尝试预订。解决方案：调用实时航班 API 验证后再写入；验证失败则丢弃。
Context Distraction（上下文分心）
- 问题：上下文过大导致模型关注历史噪音而忽略当前任务；
- 策略：定期进行上下文摘要，保留最相关的信息。
- 旅行示例：长时间讨论旧行程后，用户终于提出“帮我找下个月的便宜航班”，智能体仍纠结过去的背包旅行。解决方案：按轮次或大小对历史进行摘要，保留当前任务所需要点。
Context Confusion（上下文混淆）
- 问题：过多工具或无关信息导致错误调用，尤其是小模型；
- 策略：对工具描述进行向量检索，仅提供少量最相关工具（<30 个）。
- 旅行示例：智能体拥有几十个工具，用户问“在巴黎出行最好的方式是什么？”，结果调用
book_flight或rent_car。解决方案：按查询动态筛选public_transport_info等相关工具。
Context Clash（上下文冲突）
- 问题：上下文存在相互矛盾的信息；
- 策略：启用上下文修剪与“草稿本”机制，移除过期指令或在独立空间处理冲突。
- 旅行示例：先说“订经济舱”，后改口“这次走商务舱”。若两条指令均在上下文内，可能导致混乱。解决方案：检测到冲突时，移除旧指令或显式覆盖。
常见问题交流
欢迎加入 Azure AI Foundry Discord，继续探讨上下文工程实践。