上下文工程
Agent 运行中需要提供给 LLM 的一切相关信息——对话历史、用户输入、背景知识、工具结果——都是上下文。进入模型窗口的每个 token 都是资源：窗口有限、注意力会稀释、位置有远近之分。上下文工程（Context …
Agent 运行中需要提供给 LLM 的一切相关信息——对话历史、用户输入、背景知识、工具结果——都是上下文。进入模型窗口的每个 token 都是资源：窗口有限、注意力会稀释、位置有远近之分。上下文工程（Context Engineering）关注的就是如何高质量地筛选、压缩、组织上下文，从而最大化模型的决策与推理能力。2025 年这个词开始取代「提示词工程」成为行业关键词——因为单 Agent 时代已经过去，决定 Agent 质量的不再是「提示词写得好不好」，而是「整个上下文窗口被管理得好不好」。这一章讲清楚上下文工程的来源、核心方法和它为什么是 Agent 时代的必修课。深度工程细节见 Agent 核心 13 · 提示词工程与上下文工程。
1. 演进脉络：从 Prompt 到 Context 的关键词变迁
1.1 为什么 Prompt Engineering 不够了
提示词工程（第 02 章）只关注「输入里的指令部分怎么写」。但 Agent 系统里，模型看到的远不止指令：
系统提示词（角色+规则）
用户目标（本次任务）
对话历史（多轮来回）
工具定义（几十个函数的 schema）
工具结果（检索片段、API 返回、代码输出）
长期记忆（用户画像、历史结论）
这些加起来动辄数万 token——指令只是其中一小块。Agent 的效果取决于整块上下文的质量，而非提示词一隅。
1.2 2025：Context Engineering 概念成形
2025 年，两个标志性动作让「上下文工程」从一句口号变成一门方法论：
- Anthropic 官方文章《Effective context engineering for AI agents》——系统化论述上下文设计的原则
- LangChain 官方发文《Context Engineering》——把「上下文生命周期」工程化：构建、注入、管理、评估
两个权威来源的立场一致：Prompt Engineering 是 Context Engineering 的子集。前者管指令，后者管全部。
1.3 2026：工程化落地
上下文工程从概念走向工程实践：
- 上下文预算成为 Agent 设计的核心指标（每轮多少钱、多少 token）
- 压缩与缓存成为标准手段（摘要、向量记忆、KV Cache 复用）
- 上下文可观测成为 Agent 调试工具标配（每轮注入什么、什么被裁掉）
2. 核心概念：上下文的生命周期
上下文工程把「上下文」当作一个有生命周期的产品来管理，四个阶段：
| 阶段 | 问题 | 手段 |
|---|---|---|
| 构建 | 什么该进窗口？ | 筛选高价值信息，剔除噪声 |
| 注入 | 放哪里、什么顺序？ | 首尾放关键指令（位置敏感），分区组织 |
| 管理 | 窗口满了怎么办？ | 摘要、裁剪、KV Cache、向量记忆 |
| 评估 | 注入是否有效？ | 消融测试、质量指标、成本核算 |
2.1 两个底层规律（为什么这些手段有效）
- 注意力经济学：模型的注意力是稀缺资源——无关 token 稀释关键信息的权重。每少一个噪声 token，关键 token 的「浓度」就高一分。这就是「筛选」的价值。机制上：Transformer 的自注意力要求每个 token 与输入中的所有其他 token 建立关联，每多一个 token 都在消耗这份注意力预算——上下文越长，「找到关键信息」越难，模型越容易抓不住重点
- 位置敏感：模型对上下文开头和结尾的记忆显著优于中间（「中段遗忘」）。这就是「组织」的价值——关键信息放首尾
2.2 四个核心手段
筛选（Selection）：不是所有工具结果都值得进窗口。检索 Top-K 截断、工具输出精简、去重合并——「少而精」胜过「多而全」。
压缩（Compression）：窗口满了不丢信息，而是降级存储——对话历史摘要化、长文档分层（先摘要后细节）、记忆外置到向量库。
组织（Organization）：用分区标签、固定顺序、角色划分让模型知道「哪里是指令、哪里是数据、哪里是约束」——结构本身就是提示。
隔离（Isolation）：不同子任务、不同角色使用彼此独立的上下文，互不污染——单 Agent 塞不下时拆成多 Agent（第 08 章），或在系统内部按职责分区。上下文隔离正是「多 Agent 架构」真正的价值来源——拆 Agent 的本质，是拆上下文。
3. 关键认知：上下文工程和什么绑在一起
- 与成本强相关：Token 即金钱。上下文工程是 Agent 应用「降本增效」的第一抓手——同样的任务，上下文管理得好能省 50%+ 的 token
- 与 Agent 可靠性强相关：多轮 Agent 的「上下文漂移」（早期目标被遗忘、被中间结果带偏）是翻车主因——上下文工程就是给 Agent 装「方向盘」
- 与 RAG 互补：RAG（第 04 章）解决「检索什么」，上下文工程解决「检索到之后怎么用」——检索结果要筛选、要压缩、要放在正确的位置
4. 现状与趋势（2026）
- KV Cache 与长上下文：缓存命中让重复上下文近乎免费，上下文工程从「省 token」转向「设计最优注入策略」
- 上下文即产品：Agent 的「上下文设计文档」成为系统架构的一部分——设计什么进、什么不进，比写代码更早发生
- 自动化上下文管理：Agent 框架开始内置「自动摘要/自动裁剪/记忆分层」，工程师从「手写管理」转向「配置策略」
5. 记忆：上下文工程的长周期延伸
上下文工程处理的是「这一轮对话里放什么」，但 Agent 要长期工作（跨天、跨周），就需要记忆——把上下文工程从「会话级」延伸到「生命周期级」。业界习惯把记忆分三层：
| 记忆层 | 存什么 | 生命周期 | 典型实现 |
|---|---|---|---|
| 工作记忆 | 当前任务进行中的中间状态 | 本次任务内 | 上下文窗口本身 |
| 情景记忆 | 与用户的历史交互、过往结论 | 数天-数月 | 会话摘要、向量记忆库 |
| 长期记忆 | 用户画像、偏好、知识库 | 长期 | 外部存储 + 按需检索注入 |
关键认知：记忆的本质是「上下文工程的缓存层」——把值得留的东西压缩存储，需要时再通过检索/摘要「注入」回上下文。三个实践要点：
- 先压缩再存储：直接存原始对话很快撑爆存储与检索质量，先摘要、抽结论、结构化
- 注入要克制：记忆不是「全塞回去」，而是按当前任务检索最相关片段（否则就是换一种方式污染上下文）
- 记忆可写可改：用户的偏好会变，记忆系统要支持更新与遗忘——「记得住」不如「记得准」
延伸阅读
- 《Effective context engineering for AI agents》（Anthropic，2025）——方法论权威来源
- 《Context Engineering》（LangChain，2025）——上下文生命周期工程化
- 深度版：Agent 核心 13 · 提示词工程与上下文工程