# 15.4 成为上下文工程专家

上下文工程专家的标志，不是会背更多框架名称，而是能在真实系统里回答四个问题：什么信息应该进入模型窗口，什么信息应该留在外部系统，什么信息必须被隔离或压缩，以及如何证明这些选择没有让系统退化。

本节把全书的方法收束成可检验的成长路线。读者可以把它当成自我评估表，也可以把它用作团队培养上下文工程能力的标准。

## 15.4.1 能力雷达

上下文工程能力应围绕可交付产物来判断，而不是围绕抽象标签来判断。

| 能力    | 能回答的问题                 | 可验证产物                       |
| ----- | ---------------------- | --------------------------- |
| 任务建模  | 这个任务真正需要模型看到什么？        | 用例边界、失败样例、拒答条件              |
| 信息治理  | 信息从哪里来，谁能看，何时失效？       | 来源清单、权限矩阵、更新策略              |
| 窗口预算  | 哪些内容进入窗口，哪些内容检索、摘要或丢弃？ | Token 预算、分层上下文结构、压缩策略       |
| 检索与记忆 | 如何找到正确材料，并避免错误记忆污染？    | 分块方案、索引版本、召回和重排序评估          |
| 工具边界  | 模型能调用什么，副作用如何受控？       | 工具 allowlist、参数校验、人工确认和审计日志 |
| 质量评估  | 改动是否真的提升了答案质量？         | 评估集、回归门槛、失败样例库              |
| 生产运维  | 系统退化时如何发现、止损和回滚？       | SLO、告警规则、灰度和回滚清单            |

初级工程师通常先关注“怎么把材料塞进提示词”；成熟的上下文工程师会先问“哪些材料不该进入提示词”。后一个问题决定了系统的安全边界、成本边界和可维护性。

## 15.4.2 三阶段成长路线

### 第一阶段：能跑通

目标不是追求复杂架构，而是完整经历一次最小闭环。

1. 选择一个真实但低风险的问题。
2. 整理 10-30 条带来源的知识材料。
3. 建立最小检索、组装、回答和引用流程。
4. 写出 5-10 条评估样例，至少覆盖命中、无证据、越权和相似误召回。
5. 记录每次失败的原因：检索失败、上下文污染、提示不清、权限缺失、模型误判或评估样例不足。

这一阶段的验收标准很简单：别人能在你的说明下复现实验，看到同样的输入、上下文、答案、引用和评估结果。

### 第二阶段：能诊断

当系统可以跑通后，真正的能力来自定位问题。

| 失败现象        | 优先排查                    |
| ----------- | ----------------------- |
| 答案看似正确但无来源  | 引用链、检索结果、答案后处理          |
| 找不到明明存在的材料  | 分块、嵌入、查询改写、同义词和元数据过滤    |
| 引用了相似但错误的材料 | 重排序、领域术语、时间版本、冲突来源      |
| 多轮对话逐渐跑偏    | 会话摘要、状态覆盖、历史截断、角色边界     |
| 成本或延迟突然升高   | 上下文膨胀、重试循环、工具调用、缓存命中率   |
| 低权限用户看到敏感信息 | ACL 过滤、索引元数据、日志脱敏、工具返回值 |

这一阶段的验收标准是：你不仅能修复单个坏例子，还能把它沉淀为评估样例、监控指标或发布门禁。

### 第三阶段：能取舍

专家级能力体现在取舍，而不是堆技术。

* 当任务只需要稳定格式转换时，优先选择短提示词和规则校验，不急着引入 RAG。
* 当知识库小而更新慢时，优先做好来源管理和版本标记，不急着上复杂图谱。
* 当问题需要最新事实时，优先设计实时检索和来源时间戳，而不是依赖长期记忆。
* 当工具有副作用时，优先做权限、沙箱、确认和回滚，而不是扩大模型自主权。
* 当评估集还很弱时，优先补失败样例和人工复核，不急着自动调参。

这一阶段的验收标准是：你能解释为什么没有采用某个热门方案，并能用成本、风险、验证证据和用户价值支撑这个决定。

## 15.4.3 上下文架构评审卡

大型项目启动前，可以用下面的评审卡判断设计是否具备出版级、生产级的完整性。它也可以作为读完本书后的复盘清单。

| 评审项   | 核心问题                    | 不合格信号                |
| ----- | ----------------------- | -------------------- |
| 任务边界  | 系统承诺回答什么，不回答什么？         | 所有问题都尝试回答，没有拒答策略     |
| 信息来源  | 每类上下文来自哪里，可信度如何？        | 文档、日志、记忆和工具结果混在一起    |
| 写入策略  | 哪些信息需要持久化？              | 把临时状态写进长期记忆          |
| 选择策略  | 如何从候选材料中选出当前任务需要的内容？    | 只靠向量相似度，没有元数据和版本约束   |
| 压缩策略  | 压缩后保留了哪些事实和不确定性？        | 摘要丢失来源、时间和责任边界       |
| 隔离策略  | 不同任务、租户、角色和工具结果如何隔离？    | 靠提示词提醒模型“不要泄露”       |
| 权限与来源 | 答案是否能追溯到可访问来源？          | 检索时过滤权限，生成时又拼入未过滤上下文 |
| 预算与性能 | Token、延迟、缓存和工具调用成本是否可控？ | 只有平均延迟，没有长尾和预算告警     |
| 失败模式  | 无证据、冲突证据、越权、工具失败时怎么办？   | 只设计 happy path       |
| 回归评估  | 每次改动如何证明没有退化？           | 没有固定评估集和发布阻断条件       |

如果一张设计图无法回答这些问题，它就还不是上下文工程架构，只是把若干 AI 组件串在了一起。

## 15.4.4 实践作品集

成为专家需要作品集，而不是只读更多资料。一个有说服力的作品集至少包含以下四类产物：

1. **最小可运行系统**：能本地运行，能展示检索、引用、权限过滤和评估结果。
2. **失败样例库**：记录误召回、幻觉、越权、冲突来源、上下文污染和压缩丢失。
3. **评估与门禁**：说明哪些指标会阻断发布，哪些指标只触发观察。
4. **架构复盘**：解释一次取舍，例如为什么不用长上下文、为什么不微调、为什么把某类记忆设为短期。

这些产物比证书和工具清单更能说明能力。它们展示的是工程判断：能否把不确定的模型能力变成可观察、可回滚、可持续改进的系统。

## 15.4.5 学习输入系统

学习上下文工程时，不要把注意力平均分配给所有新框架。更有效的做法是建立稳定的信息输入系统：

* **官方文档**：用于确认 API、模型能力、协议字段、价格和安全约束。
* **论文与技术报告**：用于理解新方法的适用前提、评估集和失败条件。
* **开源实现**：用于观察工程边界，例如缓存、重试、权限、日志和配置管理。
* **事故与复盘**：用于学习哪些风险不会出现在教程里。
* **自己的实验记录**：用于沉淀可复用的参数、坏例子和判断标准。

阅读资料时，始终追问三个问题：这个方法解决了哪个具体失败模式，它引入了什么新的成本或风险，我如何用一个小实验判断它是否适合自己的系统。

## 15.4.6 结语

上下文工程的长期价值，不在于把更多内容交给模型，而在于让模型只看到当前任务真正需要、被授权、可追溯、可评估的信息。

当你能持续设计这种信息环境，并能用证据解释每一次写入、选择、压缩、隔离和回滚决策时，你就已经从“会使用大模型的人”进入了“能构建可靠 AI 系统的人”的行列。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/15_future/15.4_becoming_expert.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.