I6：上下文工程概述
Easy Data x AI 课程 · 产业应用篇 · 第 6 节
本节定位
本节把模型每次决策前看到的内容拆成来源、记忆、任务状态、上下文准备与交接五类数据，解释它们的职责边界与组合方式，并建立相关性、预算、引用、冲突处理与成本的分析框架。本节讨论的是通用工程问题，下一节再用 PowerContext 展示一套完整实现。
学习目标
完成本节后，你将能够：
- 解释上下文工程与提示词工程的分工，以及提示词堆叠的局限；
- 区分来源、记忆、任务状态、上下文准备与交接的职责边界；
- 说明长期知识与单次决策视图的关系；
- 用相关性、预算、引用三要素分析一次上下文装配；
- 理解修订、证据引用与冲突处理对可追溯性的作用；
- 分析上下文质量、延迟与成本的权衡；
- 判断什么场景值得引入独立的上下文管理系统。
1. 为什么上下文需要工程化
基础篇已经讲过模型的输入边界：模型每次请求只看到本次提供的输入。上下文窗口虽然不断变大，输入的每一个 Token 仍要占用窗口、产生费用，把更多内容塞进去也换不来等比例的回答质量提升。
工程上真正的问题在别处。一个长期项目里，Agent 每次决策可以拿到的材料包括项目文档、历史对话、用户偏好、当前任务进度、工具返回结果和代码库状态。把这些材料全部塞进一次请求，是 D4 与 X2 已经否定的做法；但只塞一小段又可能漏掉关键约束。决策点不同，需要的内容也不同。
1.1 提示词堆叠的边界
提示词堆叠指把静态指令和资料写死在 System Prompt 里，随用随加。它有三个边界：
| 问题 | 表现 | 例子 |
|---|---|---|
| 选择问题 | 没有依据判断哪些内容属于本次决策 | 项目已有 200 条规范，全部注入还是注入哪几条 |
| 预算问题 | 内容总量超过窗口或成本上限 | 全量 Skill、全量聊天记录直接拼接 |
| 追溯问题 | 内容没有来源和版本，无法核验 | 规范更新后，注入的仍是旧表述 |
提示词工程解决的是把指令写清楚的问题。上下文工程解决的是另一个问题：管理模型在什么时间看到什么信息。X6 已经给过这组递进关系，本节从数据视角展开其中的实现问题。
1.2 每次决策只看一个视图
把一次请求的内容看作一个视图，这个视图应当满足三个条件：
- 足够：覆盖完成本次任务所需的约束与事实；
- 相关：不携带与决策无关的历史包袱；
- 可追溯：每条注入内容都能定位到出处、版本与收集时间。
视图模型是本节的主线。模型不直接面对全部项目数据，它面对的是上下文系统为这一次决策准备好的视图。视图背后是谁在收集数据、谁在决定取舍、谁在标注引用，就是本节要拆解的内容。
2. 上下文准备链路的五个角色
把一次决策的前前后后展开，可以得到五类数据角色。先看它们的宏观分工：
| 角色 | 保存什么 | 变化频率 | 典型问题 |
|---|---|---|---|
| 来源 | 发生过的事实与证据 | 持续追加 | 我引用的内容出自哪个文件、哪个版本 |
| 记忆 | 需要长期复用的知识 | 按需增删改 | 用户偏好和决策约束放在哪里 |
| 任务状态 | 当前任务的进行位置 | 每次推进都更新 | 进行到哪一步，还有哪些阻塞 |
| 上下文准备 | 本次请求的临时视图 | 每请求重建 | 这次注入什么、按什么顺序 |
| 交接 | 换人换会话后的接续信息 | 任务边界处产生 | 下一个接手者从哪开始 |
课程已有的 P3、D4 把记忆讲得很细，X2 把 Skill 的按需加载讲得很细。本节补充它们共同的上游与下游：来源决定记忆的可信度，上下文准备决定记忆最终是否进入本次请求，任务状态与交接决定跨会话的连续性。
2.1 来源：记录发生了什么
来源是未经选择的证据层。一次用户纠正、一次任务结果、一份外部文档，只要值得留下位置信息，都可以作为来源。
来源与记忆有一条硬边界：来源只负责回答发生过什么，记忆负责回答以后还要不要用。某条来源被采集成功，表示证据已经落位，它不会自动变成记忆。反过来，显式写入记忆也可以不经过来源层，例如直接记录一条用户偏好。判断一条数据应当进来源还是记忆，取决于它未来的用途，也取决于它是否需要作为可引用证据存在。
2.2 记忆：留下什么
记忆是经过选择、以后仍要影响判断的知识：决策、约束、偏好、状态类事实。它与会话历史的关系在 D4 已经讲清楚，这里补充两个工程视角：
- 记忆需要身份与版本。同一条主题被修订后，旧版本仍应可读，新注入默认使用当前版本；
- 记忆需要遗忘机制。过期记忆应当能退出检索面，同时保留审计所需的原始记录。
2.3 任务状态与交接：进行到哪里
任务状态描述一件正在进行的工作：目标、已验证的进展、阻塞点、下一步。它可以存在于会话内，也可以跨会话保存。
交接信息与任务状态不同。任务状态是内部视图，交接信息是写给下一个参与者的外部视图，它除了状态还要带上目标、证据边界与已知缺口。人和 Agent、Agent 和 Agent 之间都适用同一条规则：接手者拿到的是可核验的接续信息，一段无法确认的对话摘要满足不了交接需求。比如在 PowerContext 的体系里，Work Contract 表达委托基线，Handoff 表达交接物，任务结果 Task Outcome 回写闭环，这三者的关系将在下一节中展开说明。
2.4 上下文准备：本次请求看什么
上下文准备是一次请求的装配环节。它从记忆与任务状态中召回候选，按预算裁剪，按信任层级排序，再标注引用后交付给模型。
准备结果有两个特征值得强调：
- 它是一次性视图。下一次请求会重新装配，视图本身不承担长期存储职责；
- 它有明确边界。什么能进、什么不能进、超出预算如何处理，都由装配规则决定，规则要写在系统里，不能靠提示词临时商量。
2.5 一条判别清单
工程中经常拿不准一条数据该交给哪个角色，可以用下面的问题定位：
| 判别问题 | 落位 |
|---|---|
| 它是本次发生的、要保留的证据吗 | 来源 |
| 它会影响以后的判断吗 | 记忆 |
| 它描述当前工作的进行位置吗 | 任务状态 |
| 它是某一次请求的临时呈现吗 | 上下文准备 |
| 它要让下一个接手者直接开工吗 | 交接 |
3. 相关性：召回什么
上下文预算有限，第一步永远是先选出候选，再谈放不放得下。这一步的质量通常用相关性衡量。
3.1 相关性要绑定决策点
脱离决策点谈相关性没有意义。同一份仓库规则，对一次提交前的代码审查高度相关，对一次会议纪要整理可能只字不提。因此检索请求至少要携带任务意图，例如当前查询文本、目标文件或场景标识。
3.2 检索方式的取舍
课程 D2 已经实现过向量、全文与混合检索，X1-1 讨论过两阶段检索。本节把它们放进上下文装配语境，结论一致：
| 方式 | 擅长的匹配 | 局限 | 典型场景 |
|---|---|---|---|
| 全文检索 | 词面与术语精确匹配 | 同义改写会漏 | 规范编号、报错关键字 |
| 向量检索 | 语义相近的表达 | 词面精确性弱、需要向量模型 | 用户意图与历史记录 |
| 混合检索 | 两类信号合并 | 需要融合策略与调参 | 大部分生产场景 |
3.3 召回排序与准入是两件事
检索系统返回的是排序列表，上下文系统需要的是准入结果。两者职责不同：
- 排序负责让最可能相关的候选靠前；
- 准入负责判断候选是否达到进入视图的质量基线，例如词面命中、语义相似度阈值或来源可信度。
排序高不等于可以注入。候选可能内容残缺、来自历史版本、或者与当前任务的信任层级冲突。准入规则要把这些情况挡在视图之外，并留下可观察的跳过原因。
4. 上下文预算：装得下什么
相关性解决哪些内容值得考虑的问题，预算解决最终放得下多少的问题。
4.1 预算的两套计量
工程约束按字节表达更可复现，费用与窗口约束按 Token 表达更接近模型侧事实。两者要分开处理：
| 计量单位 | 反映的问题 | 谁在控制 |
|---|---|---|
| UTF-8 字节 | 注入内容的物理大小，跨后端可复现 | 上下文系统 |
| Token | 窗口占用与计费 | 模型提供方 |
一个可复现的实现会先按字节预算装配，再让调用方核对 Token 层面的窗口占用。字节与 Token 之间没有稳定换算，不要在设计契约里假装二者等价。
4.2 信任层级决定注入顺序
候选内容来自不同信任层级。当前指令、实时状态与仓库规则高于历史记录，历史记忆与交接内容默认视为不可信历史。装配结果应当整体标记为不可信历史，只能作为历史数据注入，并排在当前指令之后：
注入顺序（从低优先级到高优先级）
不可信历史上下文
→ 检索到的记忆与交接摘要
当前请求与实时状态
→ 系统指令与仓库规则4.3 一个可执行的裁剪规则示例
以 2026 年 9 月的 PowerContext 实现为例，它的上下文准备接口按字节预算工作：
| 规则 | 取值 |
|---|---|
| 预算范围 | 512 到 32768 字节，默认 8000 |
| 单条内容上限 | 2000 字节 |
| 条目总数上限 | 8 条 |
| 超限处理 | 先截断，仍放不下则跳过该条 |
| 结果状态 | 有内容返回 ready，一条都放不下返回 empty |
规则的价值不在数字本身，在确定性。同样的输入在任意一次请求都得到同样的裁剪结果，调用方才能复现问题、核对消耗。
5. 引用、修订与冲突处理
注入内容如果无法核验，上下文工程就退回了提示词堆叠。可追溯性由三个机制共同保证：引用、修订与冲突处理。
5.1 引用精确到版本
引用要能唯一定位到一条内容的一个版本。理想形态是一个结构化引用：内容族、内容标识与版本号。文本相似度检索可以用来找候选，但不能用来证明出处，出处必须来自写入时记录的引用关系。
引用做到精确之后，还要遵守两条纪律：
- 引用旧版本时，系统不能悄悄把它替换成新版本；
- 引用可见时，应允许读取被引用版本的完整内容用于核验。
5.2 修订链与不可变版本
内容修订产生新版本，旧版本保留可读。这样设计有三个工程收益：
- 引用不会因为内容更新而失效或漂移；
- 审计可以回答某次回答依据的是哪个版本；
- 冲突检测有了比较基线。
停用与修订分开处理。停用让内容退出检索面，同时保留历史记录供审计；真正的物理删除应当极少出现，并且要有明确理由。
5.3 冲突处理的三种模式
同一主题出现矛盾信息时，P3 已给出产品层的三种处理模式，这里补充实现层的落点：
| 模式 | 实现方式 | 适用情况 |
|---|---|---|
| 时间戳优先 | 保留较新的版本，旧版本进入历史 | 事实类更新 |
| 置信度加权 | 按来源可信度排序 | 多来源结论不同 |
| 人工介入 | 生成待审候选，人工批准后发布 | 影响大或双方证据都充分 |
实现层要额外保证两点：冲突本身可见，解决过程可回滚。修订链让旧版本随时可取，候选审核保证未批准的改写无法进入注入面。
5.4 两个容易混淆的概念
上下文准备与交接都包含临时视图，但生命周期完全不同：
| 概念 | 生命周期 | 用途 |
|---|---|---|
| 准备好的上下文 | 本次请求结束后即失效 | 单次决策的输入 |
| 交接信息 | 随任务推进持续存在，可提交为里程碑 | 下一次会话的起点 |
一次交接的准备态可以先于提交存在，供接手方预览；只有显式提交后，交接才成为可引用的历史记录。这两类对象混用是上下文系统最常见的架构错误。
6. 质量、延迟与成本的三角
上下文系统的工程决策最终都落到质量、延迟与成本三个目标上。
6.1 质量从三个环节看
| 环节 | 质量问题 | 常见对策 |
|---|---|---|
| 收集 | 该记的没记、记了不该记的 | 准入规则、事件驱动采集 |
| 检索 | 该召回的回不来、噪声多 | 混合检索、重排、准入阈值 |
| 装配 | 顺序错、引用丢、预算超 | 确定性裁剪、引用标注、回归测试 |
质量评估要绑定任务结果。注入字节数下降本身价值有限，同一任务在控制组与实验组上的完成质量差异才是有效信号。
6.2 延迟从哪来
| 环节 | 延迟特征 | 对策 |
|---|---|---|
| 检索 | 随数据规模与检索方式变化 | 索引、近似检索、缓存 |
| 重排 | 需要额外模型调用 | 默认关闭，按需开启 |
| 装配 | 纯本地计算 | 几乎可忽略，保持确定性 |
准备环节自身应当轻量。把模型调用留在生成阶段，把重排这类可选项做成显式开关，避免每次请求都被迫付出额外延迟。
6.3 成本怎么花
上下文成本主要花在每次请求重复注入的内容上：
| 策略 | 机制 | 代价 |
|---|---|---|
| 只注入当前需要 | 预算裁剪 | 需要可靠的召回 |
| 稳定前缀复用 | 利用提供方 Prompt 缓存 | 约束内容编排顺序 |
| 摘要替代原文 | 模型压缩 | 信息损失，需保留引用 |
| 分层存储 | 热内容直读，冷内容按需展开 | 多一层调度逻辑 |
I5 讨论模型派生数据时强调过按真实用量计费，上下文侧同理：优化效果要按实际注入与缓存命中后的费用验证，不能只比较裁剪掉的字符数。
6.4 一张权衡决策表
| 场景 | 侧重的目标 | 建议 |
|---|---|---|
| 高频小任务 | 延迟 | 尽量少的候选与稳定的本地检索 |
| 复杂长任务 | 质量 | 更大预算、混合检索与多轮核对 |
| 批量离线任务 | 成本 | 摘要压缩与缓存友好编排 |
三个目标通常无法同时满足，上下文系统要做的，是把权衡参数暴露成配置，替业务保留决策权。
7. 什么场景需要独立的上下文管理系统
前几节讲的职责可以在应用代码里手工实现，也可以在独立系统里落地。两条路各有边界。
7.1 手工拼装的临界点
手工实现的下述成本会随规模放大：
- 会话增多后，跨会话续接没有统一入口；
- 来源更新后，历史注入内容无法失效与重查；
- 多人或多种 Agent 协作时，记忆与交接没有共同格式；
- 引用关系散落在提示词里，审计无从下手。
当这些成本开始超过一个独立系统的引入成本时，就值得把上下文管理从业务代码里拆出来。
7.2 系统的职责边界
一个完整的上下文管理系统至少要承担：
| 职责 | 说明 |
|---|---|
| 数据写入 | 来源采集、记忆写入、状态更新 |
| 检索 | 全文、向量、混合检索与准入 |
| 装配 | 预算裁剪、信任排序、引用标注 |
| 生命周期 | 修订、停用、清理与审计 |
| 接口 | 进程内 SDK、HTTP、MCP 等多入口共用同一语义 |
课程 I4、I5 讨论过把文件检索与模型派生数据下沉到数据引擎。上下文管理同样存在下沉问题：状态与记忆放在应用层时，每个 Agent 宿主都要重复实现一遍；放在独立服务时，所有宿主共享同一份数据契约。
7.3 能力分级
引入系统后，可以按能力分级逐步验收：
| 级别 | 覆盖能力 | 典型形态 |
|---|---|---|
| 最小 | 记忆读写、来源采集、上下文注入 | 单机服务加本地存储 |
| 推荐 | 加上任务契约、交接与结果回写 | 多会话、多人协作 |
| 完整 | 加上经验沉淀、技能管理与人工审核 | 长期运行的团队项目 |
分级的意义在于按需引入。第一级跑通之前，先不要追求完整级的功能。
8. 常见误区
8.1 误区一：上下文越长越聪明
窗口变大只放宽了上限。注入无关内容会稀释注意力、放大检索噪声并抬高费用，决策质量最终取决于视图的相关性，与视图的字节数没有固定关系。
8.2 误区二：记忆等于完整聊天记录
聊天记录是来源的一种形态。全量聊天记录会带来重复、冲突与隐私问题，长期记忆应保存经选择的结论，完整记录按需归档。
8.3 误区三：检索结果可以直接注入
检索结果缺少预算裁剪与信任排序，直接拼接会把排序噪声、历史版本和低信任内容带进视图。检索与装配之间必须有明确的处理环节。
8.4 误区四：版本管理只属于代码
代码之外的约束、偏好、交接与规范同样会被修订。给这些内容保留版本与引用，才能回答某次输出的依据是什么。
8.5 误区五：状态都算任务状态
任务状态与记忆经常被混为一谈。任务是会结束的，任务状态在任务结束后应当归档；记忆是跨任务复用的，归档时要把仍有价值的部分沉淀为记忆。
9. 一套最小验收流程
无论自研还是引入现成系统，都可以用下面的步骤验收：
- 定义两类数据：必须记住的约束与偏好，必须保留的原始证据；
- 写一条显式记忆，换一个会话检索到它；
- 修改这条记忆，确认新会话注入新版本，旧版本仍可精确读取；
- 制造一条停用记忆，确认它退出检索但不消失；
- 提交一次任务交接，用新的会话继续任务，确认目标与证据随行；
- 构造两份矛盾记忆，确认冲突被标记或进入审核；
- 设置一个小预算，确认裁剪规则可复现、超限原因可观察；
- 记录每次注入的字节与 Token 消耗，对照任务质量回归。
第 5 步与第 7 步最容易暴露系统设计的真实缺陷，建议优先执行。
10. 本节小结
上下文工程把每次决策的输入从提示词堆叠变成一条可管理的数据链路：
- 来源保存证据，记忆保存知识，任务状态保存进度，交接保存连续性；
- 上下文准备为单次请求装配有界、可引用的视图；
- 相关性决定召回什么，预算决定放得下什么，引用决定能否核验；
- 修订与冲突处理让长期内容可演进、可审计；
- 质量、延迟与成本按场景权衡，参数要暴露成配置；
- 独立系统的价值在多会话、多来源、多参与方的场景才开始显现。
数据先于提示词被管理，提示词才有机会把任务完成得可信。
11. 与其他课程的关系
- F1《AI 必知必会（一）》：模型的上下文窗口与输入成本边界；
- P2《Agentic RAG 产品设计》：从产品目标拆解召回与精确；
- P3《Agent 记忆系统设计》：记忆的分类、时效与冲突处理；
- P4《Skill 与 Agent 知识管理》：程序记忆外化为 Skill 的管理；
- D2《AI 应用的数据层》：向量、全文与混合检索的实现基础；
- D4《Agent 开发与记忆系统》：记忆系统的最小可运行实现；
- X2《多 Skill 给上下文工程带来的麻烦》：全量注入问题的实证；
- X6《从 Harness 到 Loop，再到 Graph Engineering》：上下文工程在工程分层中的位置；
- I7《PowerContext 的设计与实现》：本节的框架落成一套可运行的案例。