Context Engineering：上下文工程
你将学到什么
- 为什么更长的上下文不等于更好的响应
- 大模型上下文的 4 种失效模式（中毒、干扰、混淆、冲突）
- 6 大修复技巧在产品设计中的应用
- 如何设计 AI 产品的上下文管理策略
为什么重要：上下文管理是 AI 产品质量的核心。理解上下文失效模式，能帮你在产品设计时避开常见陷阱，提升 Agent 可靠性。
核心观点：更长的上下文 ≠ 更好的响应。上下文过载时，AI 会产生幻觉、重复错误、调用无关工具，甚至自相矛盾。
什么是上下文工程？
正如 Andrej Karpathy 所说：
上下文工程是一门精妙的艺术与科学——在上下文窗口中填充恰到好处的信息，以支持下一步推理。
随着对话轮次增加、工具调用累积、文档检索叠加，上下文会变得：
- 有毒（poisoned）：错误信息反复被引用
- 干扰性（distracting）：模型过度关注历史而忽略训练知识
- 混乱（confusing）：无关信息干扰决策
- 冲突（clashing）：内部信息自相矛盾
四种失效模式
1. 上下文中毒（Context Poisoning）
现象：幻觉或错误进入上下文后，被模型反复引用和强化。
典型案例：Agent 系统一旦产生幻觉认为需要完成某个不存在的任务，就会不断重复无效行为，陷入死循环。
产品影响：
- ❌ Agent 产品如果没有错误恢复机制，一个早期错误可能导致整个任务崩溃
- ✅ 需要设计检查点和回滚机制
真实案例
某代码 Agent 在第 3 步误判"需要创建 config.json"，后续 20 步都在尝试创建这个不存在的文件，最终任务失败。
根本原因：错误信息进入上下文后，模型把它当作"事实"反复引用。
2. 上下文干扰（Context Distraction）
现象：上下文过长时，模型过度关注历史记录，忽略了自身的训练知识。
数据支撑：
- Llama 3.1 405B 的正确率在 32k token 左右就开始下降
- Multi-Agent 系统在信息碎片化时性能下降 39%
产品影响：
- ❌ 不要以为上下文窗口越大越好——塞满信息可能比精准检索效果更差
- ✅ RAG 的价值不是"塞更多"，而是"选更准"
面试加分点
能说出"Lost in the Middle"现象：当上下文过长时，模型对中间部分的信息记忆最差，开头和结尾的信息权重更高。这也是为什么 RAG 要把最相关的文档放在 Prompt 开头或结尾。
3. 上下文混淆（Context Confusion）
现象：给模型的工具太多，性能反而下降。
数据支撑：实验表明，将工具从 46 个减少到 19 个，模型成功率明显提升，即使上下文窗口还很充裕。
产品影响：
- ❌ AI 工具箱不是越全越好
- ✅ 给模型呈现的工具数量要精简到当前任务必要的范围
类比理解：就像给人一个 100 个按钮的遥控器，反而不如 10 个按钮的好用。
4. 上下文冲突（Context Clash）
现象：多轮对话中，前面的错误回答留在上下文里，影响后续推理。
数据支撑：微软和 Salesforce 实验显示，同样内容分多轮提供 vs 一次性提供，性能平均下降 39%，OpenAI o3 从 98.1 分跌到 64.1 分。
产品影响：
- ❌ Agent 流程中的错误状态会一直往下传
- ✅ 关键步骤必须有检查点和错误恢复机制
互动练习：识别失效模式
场景：你的 AI 客服产品，用户反馈"AI 一直在问我已经回答过的问题"。
这属于哪种上下文失效模式？应该如何解决？
查看答案
失效模式：上下文冲突（Context Clash）
可能原因：
- 上下文中保留了早期的错误理解
- 多轮对话中，模型没有正确更新对用户意图的判断
- 上下文过长，模型"忘记"了中间的关键信息
解决方案：
- 短期：在每轮对话后，用摘要更新用户状态（如"用户已提供：姓名、电话、地址"）
- 中期：实现上下文压缩，定期将历史对话压缩成结构化信息
- 长期：设计状态机，明确记录用户已完成的步骤，避免重复询问
六大修复技巧
技巧 1：RAG（检索增强生成）
原理：精准检索相关信息塞入上下文，而不是把所有文档全部塞进去。
产品应用：
- 知识库问答：只检索 Top-3 最相关文档
- 代码助手：只加载当前文件的依赖项，而非整个代码库
PM 启示
"RAG 已死"是误解。无论上下文窗口多大，精准信息管理仍然关键。RAG 的本质是信息选择，不是窗口大小的竞争。
技巧 2：工具精简（Tool Loadout）
原理：动态选择当前任务必要的工具，而不是把所有工具都暴露给模型。
产品应用：
- 客服 Agent：根据用户意图（退款/咨询/投诉）动态加载对应工具集
- 代码 Agent：根据编程语言（Python/Java/Go）加载对应的调试工具
数据支撑：工具从 46 个减少到 19 个，成功率提升 15-20%。
技巧 3：上下文隔离（Context Quarantine）
原理：将不同子任务放在独立的上下文线程中处理，避免相互污染。
产品应用：
- Multi-Agent 系统：每个子 Agent 有独立上下文
- 复杂任务分解：将"写代码"和"写测试"放在两个独立会话中
数据支撑：上下文隔离使 Multi-Agent 系统性能提升 90.2%。
常见误区
不是所有信息都要共享。很多 PM 设计 Multi-Agent 时，让所有 Agent 共享一个大上下文，结果互相干扰。正确做法是：只在必要时通过消息传递关键信息。
技巧 4：上下文剪枝（Context Pruning）
原理：主动删除上下文中的无关信息。
产品应用：
- 长对话产品：定期清理不再相关的历史内容
- Agent 系统：删除已完成任务的中间步骤
数据支撑：某案例中，剪枝将 Token 从 25k 压缩到 11k，质量反而提升。
技巧 5：上下文压缩（Context Summarization）
原理：用摘要替代原始内容，保留关键信息的同时大幅压缩 Token。
产品应用：
- 客服系统：将前 10 轮对话压缩成"用户问题：退款；已提供：订单号、照片"
- 会议助手：将 1 小时会议压缩成"决策事项 3 条 + 待办任务 5 条"
成本优化：这也是控制 AI 使用成本的重要手段。
技巧 6：上下文卸载（Context Offloading）
原理：把信息存到外部工具和记忆系统，需要时再调用，而不是一直放在上下文里。
产品应用：
- Agent 记忆系统：工作记忆（上下文）+ 长期记忆（向量库/知识图谱）
- 个人助手：用户偏好存在数据库，而非每次都放在 Prompt 里
数据支撑：上下文卸载策略使系统性能提升 54%。
延伸阅读
详细的 Agent 记忆系统设计，参见 Agent 记忆系统。
实战应用
场景 1：设计长对话产品
问题：用户与 AI 助手对话 50 轮后，AI 开始答非所问。
诊断：上下文干扰 + 上下文冲突。
解决方案：
- 每 10 轮压缩一次：将历史对话压缩成结构化摘要
- 关键信息置顶：用户偏好、当前任务目标始终放在 Prompt 开头
- 错误修正机制：用户纠正 AI 时，立即更新上下文摘要
场景 2：设计 Multi-Agent 系统
问题：3 个 Agent 协作时，经常出现重复工作或互相矛盾。
诊断：上下文冲突 + 上下文混淆。
解决方案：
- 上下文隔离：每个 Agent 独立上下文
- 消息传递：通过结构化消息（JSON）传递关键信息
- 协调者模式：设计一个 Coordinator Agent 负责任务分配和结果整合
场景 3：优化 RAG 系统
问题：检索了 10 篇文档，但 AI 回答质量不如只检索 3 篇。
诊断：上下文干扰。
解决方案：
- 重排序（Rerank）：用专门的 Rerank 模型筛选最相关的 Top-3
- 分段检索：先检索章节标题，再检索具体段落
- 动态调整：根据问题复杂度动态调整检索数量（简单问题 1-2 篇，复杂问题 3-5 篇）
PM 设计 Checklist
在设计 AI 产品时，问自己这几个问题：
- [ ] 每次调用给模型多少上下文？是否有精简机制？
- [ ] 工具集是否按场景精简，而不是全量暴露？
- [ ] 多轮对话是否有错误恢复机制，防止错误状态传递？
- [ ] 长对话产品是否有上下文压缩/遗忘策略？
- [ ] Multi-Agent 场景中各 Agent 的上下文是否相互隔离？
- [ ] RAG 系统是否有重排序机制，而非简单堆砌检索结果？
面试应用
高频问题："如何优化 Agent 系统的上下文管理？"
回答框架：
- 识别失效模式：先诊断是中毒、干扰、混淆还是冲突
- 选择修复技巧：根据场景选择 RAG/工具精简/隔离/剪枝/压缩/卸载
- 给出具体方案：结合产品场景，说明如何实施（如"每 10 轮压缩一次"）
- 提供数据支撑：引用性能提升数据（如"隔离后性能提升 90%"）
加分点：能说出"Lost in the Middle"现象，或提到"上下文工程是 Andrej Karpathy 提出的概念"。