上下文工程（Context Engineering）
| 分类 | 🧠 基础概念 |
| 阅读时间 | ⏱️ 16 分钟 |
| 更新时间 | 📅 2026-10-02 |
| 条目编号 | ENC-CONCEPT-27-context-engineering |
关键要点 ✦
- 据 Anthropic 2025 年 9 月发布的工程博客《Effective context engineering for AI agents》，上下文工程的核心是在每一步为模型找到「最小的高信号 token 集合」，而不是堆砌更多信息
- 上下文远不止提示词：完整上下文包括系统指令、工具定义、检索内容、消息历史与当前输入，提示工程通常只覆盖最后一项
- 多项研究显示模型表现随上下文变长而退化，即「上下文腐烂（context rot）」；arXiv:2307.03172 记录了 lost in the middle 现象——长上下文中部信息更易被模型忽略
- 长任务三大技术：压缩（compaction）、结构化笔记（agentic memory）与子智能体架构——分别对应对话延续、里程碑迭代与并行研究三类场景
- 工具设计本身也是上下文工程：返回精简、token 高效的工具结果，比堆砌宽泛的「万能工具」更能提升智能体表现
- 策略选择的通用法则是「用能解决问题的最简单方案」：先最小配置起步，再根据失败模式逐步加机制
从提示工程到上下文工程
提示工程关注「如何措辞一条指令」，上下文工程关注「每一步推理让模型看到什么」。随着智能体系统引入工具调用、检索结果与跨会话记忆，送入模型的不再是单一提示词，而是系统指令、工具清单、检索片段、文件内容、对话历史与当前输入共同构成的完整状态。Anthropic 在 2025 年 9 月的工程博客中将其表述为：构建语言模型应用的关键问题已从「找到合适的措辞」转向「什么样的上下文配置最可能产生期望行为」。
这一转向的工程含义是：上下文在每个调用周期都是被主动设计与筛选的对象，而不是被动累积的日志。前 OpenAI 研究者 Andrej Karpathy 将其概括为「用恰到好处的信息填满上下文窗口的精细艺术与科学」——信息太少则任务缺乏依据，信息太多则关键信号被稀释。
注意力预算与上下文腐烂
Transformer 架构中每个 token 都要与所有其他 token 做注意力交互，上下文越长，注意力被摊薄得越严重。Chroma Research 对十余个主流模型的测试显示，模型表现随输入长度增加一致退化；arXiv:2307.03172 记录的 lost in the middle 现象表明，长上下文中部位置的信息比首尾位置更易被忽略。这类现象被统称为上下文腐烂（context rot）。
更大的上下文窗口并不能消除这一约束。窗口从数万 token 扩展到百万 token 级别后，「塞得下」与「用得好」成为两个不同的问题——上下文工程的立足点正是把上下文当作一种需要精打细算的注意力预算来管理。
三大核心技术：压缩、结构化笔记与子智能体
压缩（compaction）指在上下文接近预算上限时，将历史对话摘要为保留关键决策、文件路径与当前计划的紧凑表示，丢弃已处理的原始工具输出与冗余消息。Claude Code 在上下文使用接近阈值时自动执行压缩，Anthropic 也将工具结果清除（tool result clearing）作为门槛较低、风险较小的压缩形式在开发者平台提供。
结构化笔记（agentic memory）指智能体定期把目标、已完成步骤、关键发现与待办写入上下文窗口之外的持久文件（如 NOTES.md 或待办清单），并在后续步骤读回。Anthropic 用「Claude 玩宝可梦」实验展示：借助跨上下文重置的精确笔记，智能体得以维持长达数千步的训练策略与探索地图。
子智能体架构以隔离换取深度：主智能体保留高层计划，子智能体在干净上下文中各自开展大规模检索或分析，只把 1000 至 2000 token 的蒸馏结论回传。Anthropic 在其多智能体研究系统博客中报告，该模式在复杂研究任务上明显优于单智能体长上下文方案。三种技术的选型经验：多轮往复对话用压缩，里程碑清晰的迭代开发用结构化笔记，可并行的复杂研究用子智能体。
工具与环境的上下文设计
上下文工程不止发生在消息层面。工具定义本身占用上下文预算：每个工具的名称、描述与参数模式都会进入每次请求，接入了大量 MCP 服务器的智能体可能在执行任何动作前就消耗大量 token。按需加载工具模式（tool search）因此成为主流——先暴露精简索引，用到时再加载完整模式。
工具返回值同样需要设计。Anthropic 的建议是工具结果应「token 高效」：返回摘要、引用与句柄而非整份文件，让智能体按需二次获取。这一原则与运行外壳（harness）层面的上下文管理相互配合，详见本站 Agent Harness 词条。
实践边界与常见误区
常见误区包括：把所有背景一次性塞进提示词、用脆弱的条件逻辑硬编码行为、构建臃肿的工具集、假设更大窗口能解决一切、忽视长会话中的上下文污染。Anthropic 给出的反直觉结论是：模型能力越强，所需的指令性工程越少，但「把上下文当作有限资源精心理配」这一原则不会过时。
上下文工程与智能体记忆模块、Agent Harness 是互补概念：记忆模块解决「跨会话存什么」，上下文工程解决「每一步看什么」，运行外壳则把两者工程化为可复用的执行框架。三者的关系与分工可分别参见本站相关词条。
🎯 应用场景
✅ 最佳实践
- 先以最小上下文配置测试，依据真实失败模式逐步增加机制，避免过早优化
- 优先清理已处理的原始工具输出与冗余消息——这是风险低、见效快的压缩起点
- 结构化笔记应有固定分区（目标、已完成、发现、待办），分区本身充当核对清单，防止信息渐进式丢失
- 工具定义按任务裁剪到最小集合，大型工具目录改用按需检索加载
- 压缩摘要需显式保留文件路径、已做决策与当前计划；持久性规则放在每轮都会重新注入的项目级文件而非单次提示
- 对子智能体只回传蒸馏结论，探索性上下文隔离在子任务内部，不回流主智能体
🔮 未来展望
随着模型能力提升，业界观察到更聪明的模型需要更少的指令性工程，智能体可承担更多自主性；但注意力预算的物理约束仍在。可以预期的是：上下文管理会继续下沉为平台能力（如托管运行时内建压缩与记忆），而应用开发者的关注点将从手工压缩技巧转向上下文策略的声明式配置与效果度量。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。