Context Engineering：让模型在正确时刻看到正确信息
# Context Engineering：让模型在正确时刻看到正确信息
理解上下文不是聊天记录的同义词，而是每次模型调用前由宿主应用（后端或 Agent Runtime）主动组装的工作集；掌握选择、压缩、隔离和验证上下文的方法。
# 先记住一句话
Context Engineering 是在每次模型调用前，选择并组织完成当前决策所需的最小、相关、可信信息；重点不是 “塞得更多”，而是让重要信息更容易被模型正确使用。
# 一轮上下文通常包含什么
高优先级规则：系统指令、权限和不可违反的边界
任务定义：用户目标、约束、验收条件
运行状态：阶段、已完成步骤、待处理事项、预算
能力说明：当前允许使用的工具及其 Schema
外部证据：RAG 检索结果、数据库数据、工具 observation
必要历史：与当前决策直接相关的对话摘要
输出契约：需要返回的结构、格式和状态
2
3
4
5
6
7
这些信息来自不同信任级别。网页、文档和工具输出都可能包含提示注入，必须当作数据，不应让它覆盖系统规则。
# 四个核心动作
# 1. Select：只选当前决策需要的信息
工具列表、历史消息和知识文档都可以按任务动态加载。搜索阶段不需要暴露写工具，回答 React 问题也不需要把整个 Web3 知识库塞进去。
# 2. Compress：压缩但保留关键事实
长对话可以摘要，但目标、用户确认、权限、关键数值和未解决问题应以结构化状态保存，不能只靠模型自由总结。
# 3. Order：按重要性组织
把稳定规则放在清晰位置；文档片段带来源、标题和时间；相似证据去重；不要让关键约束被大量低价值文本夹在中间。
# 4. Isolate：隔离角色和不可信输入
多 Agent 只共享必要结果，不共享全部草稿；外部内容放在明确的数据边界内；敏感凭据永远不进入模型上下文。
# Context、RAG 和 Memory 的关系
| 概念 | 负责什么 | 什么时候发生 |
|---|---|---|
| Context | 当前这次调用实际看到的信息 | 每一次模型调用前组装 |
| RAG | 从外部知识源查找相关证据 | 当前任务需要知识时 |
| Memory | 跨轮次或跨任务保存可复用信息 | 运行后写入，未来按需读取 |
RAG 和 Memory 的内容最终都必须进入 Context，模型才能使用。检索到了不代表模型已经看到；保存了也不代表每轮都应该加载。
# 常见失败模式
- Context overflow：超过窗口或成本预算；
- Context distraction：无关内容太多，模型关注错误信息；
- Context conflict：不同来源互相矛盾，未标时间和权威性；
- Context poisoning：外部文档包含诱导模型越权的指令；
- Context drift：多轮后目标和约束在摘要中丢失；
- Tool overload：一次暴露太多相似工具，选择准确率下降。
# 贯穿项目的上下文组装
const context = {
policy: loadStablePolicy(),
task: { goal, acceptanceCriteria, currentPhase },
tools: selectTools({ phase: currentPhase, permissions }),
evidence: await retrieveNotes(query, { topK: 6, rerank: true }),
memory: await recallConfirmedPreferences(userId, query),
history: summarizeRelevantTurns(messages),
outputSchema: answerSchema
}
2
3
4
5
6
7
8
9
笔记片段要带 path、标题、更新时间和片段范围；用户偏好只加载经过确认且与本题相关的内容；工具按阶段和权限选择。这样可以同时降低成本、误用工具和提示注入风险。
# 如何调试
不要只看最终回答。应记录每轮最终组装的上下文清单、各部分 Token 占比、被裁剪内容、检索命中和模型实际调用的工具。若答案漏掉关键事实，先确认事实是否进入 Context，再判断是检索、排序还是模型使用问题。
# 高频面试题与回答
回答顺序：先说结论，再解释原因，最后补一个例子或工程边界。不要逐字背诵，记住这条表达主线即可。
1. 30 秒回答：什么是 Context Engineering参考答案
Context Engineering 就是为模型每一次调用准备 “此刻真正需要的信息”。这些信息可能包括 Instructions、任务状态、相关历史、工具说明、RAG 资料和 Memory，还要决定哪些先放、哪些压缩、哪些不可信。Prompt Engineering 更关注指令怎样写清楚；Context Engineering 还要解决信息从哪里来、何时加载，以及怎样在有限窗口和费用内保持准确。
2. 为什么上下文不是越长越好？参考答案
因为长 Context 不只更贵、更慢，还会把真正重要的信息埋在无关内容里，甚至出现互相冲突的旧规则和资料。外部文本越多，提示注入风险也越大。目标不是把所有内容都塞进去，而是提供 完成当前任务所需的最少充分信息。
3. 怎样防止摘要把关键约束丢掉？参考答案
不要让摘要承担唯一的状态保存职责。目标、权限、用户确认、关键事实和待办应该单独结构化保存，摘要只负责压缩解释性对话。摘要生成后还可以用 Schema 或规则检查必填内容，这样即使压缩多次，也不会靠一段自然语言记住所有关键状态。
4. 外部文档为什么不能直接拼进系统提示？参考答案
因为网页、文档和工具输出都是不可信数据，里面可能夹带 “忽略之前规则” 之类的提示注入。应用应该把它们明确标成引用资料，只允许提供事实，不能让它们改变系统规则、权限和工具策略。真正的安全边界仍由程序控制。
# 接下来学什么
下一篇学习 RAG 原理与工程实践，重点理解怎样把可信外部知识按需检索进上下文，以及召回、重排、引用和评测的完整链路。