跳到主要内容

Context Engineering

如果说 Prompt Engineering 关注的是“怎么把一句指令写清楚”，那么 Context Engineering 关注的就是“在模型回答之前，到底应该把哪些信息送进上下文，以及这些信息该怎么组织”。

它更像是在给模型搭工作环境，而不是单纯写一句 prompt。

1. Context Engineering 是什么​

Context Engineering 可以理解为：围绕模型每次调用时的全部输入信息，去做选择、组织、裁剪、增强和更新的一整套方法。

这里的“context”不是只指用户最后一句话，而是模型真正能看到的整包信息，比如：

  • 系统规则
  • 开发者指令
  • 用户当前问题
  • 历史对话
  • 示例
  • 检索资料
  • 工具调用结果
  • 用户偏好
  • 当前任务状态
  • 输出格式要求

所以它解决的核心问题不是“怎么提问更像高手”，而是：

  • 给模型什么信息最有用
  • 不该给什么信息
  • 信息该按什么顺序排列
  • 历史记录要保留到什么程度
  • 外部资料什么时候补进来
  • 如何让复杂任务在多轮中保持连续性

2. 为什么它重要​

很多复杂任务效果不好，不一定是 prompt 写得差，而是上下文出了问题。

常见问题有：

  • 信息不够，模型只能猜
  • 信息太多，重点被淹没
  • 信息顺序混乱，模型抓不到主线
  • 历史对话太长，旧内容干扰当前问题
  • 检索资料不准，导致回答偏题
  • 工具结果杂乱，模型难以整合
  • 没有任务状态，模型每轮都像重新开始

从工程角度看，复杂 AI 系统的上限，往往更多取决于 context 的设计质量，而不只是 prompt 本身。

3. 它和 Prompt Engineering 的区别​

二者可以这样区分：

3.1 Prompt Engineering​

更关注：

  • 指令怎么写
  • 角色怎么设
  • 示例怎么给
  • 输出格式怎么限制

它更像是在优化“说法”。

3.2 Context Engineering​

更关注：

  • 上下文里放什么
  • 历史如何裁剪
  • 检索内容如何选
  • 工具结果如何注入
  • 状态如何维护
  • 多轮任务如何延续

它更像是在优化“信息环境”。

一个很直观的类比：

  • Prompt Engineering：像给员工写任务单
  • Context Engineering：像给员工准备资料、历史记录、工作台、工具和进度板

4. Context 通常由哪些部分组成​

一个比较完整的上下文，通常由下面几类信息组成。

4.1 Instruction Context​

也就是规则和任务要求，比如：

  • 你是谁
  • 你的职责是什么
  • 哪些边界不能越过
  • 最终要输出什么格式

4.2 User Context​

也就是当前用户的目标、偏好和约束，比如：

  • 用户到底要做什么
  • 用户希望中文还是英文
  • 用户偏好简洁还是详细
  • 当前输入内容是什么

4.3 Conversational Context​

也就是历史对话中仍然相关的部分，比如：

  • 已经确认的需求
  • 已经排除的方案
  • 当前轮还需要沿用的背景

4.4 Knowledge Context​

也就是外部知识，比如：

  • RAG 检索出来的文档
  • 产品文档
  • API 文档
  • 企业知识库
  • 网页资料

4.5 Tool Context​

也就是工具的返回结果，比如：

  • 搜索结果
  • 数据库查询结果
  • 函数调用返回值
  • 代码执行结果

4.6 State Context​

也就是任务当前所处的状态，比如：

  • 已完成什么
  • 正在做什么
  • 还差什么
  • 下一步是什么

4.7 Memory Context​

也就是跨轮保留的长期信息，比如：

  • 用户长期偏好
  • 稳定的项目背景
  • 常用输出风格
  • 已经确认的长期设定

5. Context Engineering 的核心目标​

一个好的上下文，通常要同时满足下面 5 点：

  • 相关：只放当前任务真正有用的信息
  • 完整：足够支持模型完成任务
  • 紧凑：尽量减少噪音和重复
  • 结构化：让模型能快速理解主次
  • 动态更新：任务推进时及时调整

重点不是“越多越好”，而是“越合适越好”。

6. 常见技巧​

下面这些技巧，是最值得在实战里优先掌握的部分。

6.1 信息分层​

不要把所有内容堆成一个大段落，最好按层级组织。

常见顺序是：

  1. 系统规则
  2. 当前任务
  3. 背景事实
  4. 外部资料
  5. 工具结果
  6. 输出要求

这样模型更容易区分“什么是规则，什么是证据，什么是目标”。

6.2 历史裁剪​

不是所有历史消息都值得保留。

应该优先保留：

  • 已确认需求
  • 当前问题依赖的背景
  • 已做出的关键决策

可以删除或压缩：

  • 闲聊
  • 重复确认
  • 已经过时的信息

6.3 历史摘要​

长对话不要原样拼接，而要压缩成摘要。

一个好摘要通常会保留：

  • 用户目标
  • 已确认约束
  • 已尝试方案
  • 当前阻塞点
  • 下一步方向

这比直接把几十轮对话全塞进去更有效。

6.4 检索增强​

不要把所有知识长期塞进上下文里，而是在需要时做检索。

这就是 RAG 在 Context Engineering 里的典型用法：

  1. 根据问题检索相关资料
  2. 选最相关的片段
  3. 再把片段注入当前上下文

这样可以降低噪音，也能利用更实时、更私有的知识。

6.5 控制检索粒度​

检索片段太大，噪音会多；太碎，又容易上下文断裂。

所以常见做法包括：

  • 合理 chunk 切分
  • 去重
  • 排序
  • 截断
  • 相邻片段合并

6.6 给上下文打标签​

不同来源的信息最好显式标注，比如：

  • 任务说明
  • 背景事实
  • 用户偏好
  • 检索结果
  • 工具返回
  • 当前状态

这样模型更容易判断每部分信息的用途和优先级。

6.7 设置信息优先级​

上下文里可能会出现冲突信息，所以最好明确优先级。

常见优先顺序可以是：

  1. 系统规则
  2. 当前任务指令
  3. 最新工具结果
  4. 当前轮检索资料
  5. 历史对话
  6. 模型自身先验

这能帮助模型在信息冲突时更稳定地取舍。

6.8 分离事实与指令​

很多上下文质量差，是因为把规则、目标、事实、示例全揉在一起。

更好的方式是至少拆开：

  • 任务指令
  • 背景事实
  • 外部证据
  • 输出要求

6.9 动态装配上下文​

上下文不应该是一个固定模板永远不变，而应该在每次调用前按任务动态组装。

例如：

  • 做总结时重点带原文和摘要规则
  • 做排障时重点带日志、错误信息和监控数据
  • 做规划时重点带目标、约束和当前进度

6.10 维护工作记忆​

复杂任务里，建议显式维护一份状态摘要，类似“工作记忆”：

  • 当前目标
  • 已完成步骤
  • 待办项
  • 风险点
  • 下一步行动

这对长链路任务、Agent、自动化流程特别有帮助。

7. 常见系统模式​

7.1 Summarized History​

保留最近几轮原始对话，再配一份历史摘要。

这是长对话系统里最常见的模式之一。

7.2 Rolling Context Window​

只保留最近 N 轮消息，加上一个长期摘要。

优点是：

  • 成本可控
  • 重点更集中
  • 不容易被老内容污染

7.3 Retrieval-Augmented Context​

按需把外部资料拉进上下文，而不是永久放进去。

它适合：

  • 企业知识库问答
  • 文档助手
  • 实时信息问答
  • 私有数据问答

7.4 Tool-Augmented Context​

把工具结果结构化地纳入上下文。

例如：

  • 搜索结果摘要
  • 数据库查询表格
  • API 返回字段
  • 测试执行结果

7.5 State Buffer / Scratchpad​

维护一份中间状态，而不是每轮都从零开始理解任务。

适合：

  • 多步任务
  • Agent
  • 代码执行流程
  • 自动化编排

7.6 Memory-Augmented Context​

引入长期记忆来增强连续体验，比如：

  • 用户偏好中文回答
  • 用户常要 Markdown 表格
  • 当前项目是 React + TypeScript

但长期记忆必须谨慎，不然会持续污染后续回答。

8. Context Engineering 最重要的原则​

最值得记住的一句话是：

Context Engineering 的核心不是给更多信息，而是给更对的信息。

很多系统的失败，不是因为缺少内容，而是因为上下文里混入了太多无关、过时、重复或低质量的信息。

所以真正重要的是：

  • 选择
  • 裁剪
  • 组织
  • 更新

而不是简单堆砌。

9. 一个直观例子​

假设用户要你分析一个接口超时问题。

只写一个 prompt，可能是：

请分析这个接口超时的原因，并给出排查方案。

但如果做 Context Engineering，可以把输入组织成这样：

系统规则：
你是资深后端故障排查助手，回答要准确、可执行。

当前任务：
分析某接口超时原因，并提供排查步骤。

已知事实：
- 接口平均响应时间从 200ms 升到 8s
- 问题发生在今天 14:20 之后
- 最近刚上线了缓存改动

日志摘要：
- 数据库连接等待时间显著上升
- 部分请求出现 Redis 超时

监控摘要：
- CPU 正常
- 数据库连接池接近耗尽
- Redis 延迟抖动

输出要求：
1. 先列出最可能的 3 个原因
2. 再给排查顺序
3. 最后给临时止损方案

这时候回答质量通常会明显更高，因为模型拿到的是“正确组织过的信息环境”。

10. 常见误区​

10.1 上下文越长越好​

不是。长度只会增加成本，不一定增加效果。

10.2 历史消息要全部保留​

不是。很多历史内容已经失效，继续保留只会干扰当前任务。

10.3 检索结果越多越稳​

不是。召回过多常常会引入噪音和冲突。

10.4 工具返回原样塞进去就行​

不是。工具返回通常需要清洗、摘要和结构化。

10.5 Prompt 写好就够了​

不是。复杂任务里，context 的影响往往比 prompt 更大。

10.6 记忆越多越聪明​

不是。低质量记忆会在后续每一轮都持续污染结果。

11. 最值得先掌握的 8 个点​

如果你刚开始系统学习 Context Engineering，建议先抓住这 8 个：

  1. 区分“指令”和“上下文”
  2. 学会做历史摘要
  3. 学会筛选相关信息
  4. 学会按层组织上下文
  5. 学会按需检索外部知识
  6. 学会维护任务状态
  7. 学会处理工具返回结果
  8. 学会控制长度和噪音

12. 一句话总结​

Context Engineering 的本质，是为模型搭建一个“刚好够用、结构清晰、动态更新、信息可信”的工作环境，让它在有限上下文里更稳定地完成复杂任务。

如果说 Prompt Engineering 是“怎么说”，那 Context Engineering 就是“模型在回答之前，到底看到了什么”。