Context Engineering：上下文工程

前置阅读：Prompt Engineering 从入门到精通、Harness
这篇专门讲 AI 工程的"第二站"——Context Engineering：当模型已经听得懂话了，下一步要解决的就是"它到底拿到了什么信息"。

一、一句话定义

Context Engineering（上下文工程）= 在每一次模型请求里，决定"塞什么进去 / 不塞什么进去 / 怎么塞"，让有限的上下文窗口里装着最有用的信息。

如果说 Prompt Engineering 是"怎么说话"，那 Context Engineering 就是"说话之前，先把哪些资料摆到桌子上"。

二、为什么需要 Context Engineering

大模型有一个绕不开的物理限制：上下文窗口（Context Window）是有限的。

模型	上下文窗口
GPT-3.5	4K～16K tokens
GPT-4	8K～128K tokens
Claude 3.5	200K tokens
Gemini 1.5 Pro	1M～2M tokens

看起来 200K、1M 已经够大了，但真实场景里你会发现根本不够用：

• 整个项目代码塞进去 → 几百万 token
• 公司知识库全文 → 几亿 token
• 一次长对话两小时 → 几十万 token
• Agent 跑了 50 轮工具调用 → token 爆炸

而且更扎心的是：装得下 ≠ 用得好。研究反复证明，上下文越长，模型对中间内容的注意力越差（"Lost in the Middle"现象）。

所以工程上必须回答这三个问题：

1. 有限的窗口里，应该优先装什么？
2. 不必要的内容，怎么剔除？
3. 该装的内容，怎么压缩、组织、排序？

这就是 Context Engineering 要做的事。

三、上下文窗口里到底有什么

一次发给模型的请求，看起来只是一段对话，实际是这些东西层层叠加而成的：

┌─────────────────────────────────────────┐
│  System Prompt（系统人设、规则、风格）   │ ← 几乎每次都在
├─────────────────────────────────────────┤
│  Tools 定义（每个工具的 JSON Schema）    │ ← 注册了多少占多少
├─────────────────────────────────────────┤
│  历史对话（user / assistant 来回）       │ ← 越聊越长
├─────────────────────────────────────────┤
│  检索到的资料（RAG 抓回来的片段）        │ ← 临时塞进来
├─────────────────────────────────────────┤
│  长期记忆（用户偏好、项目笔记）          │ ← 跨会话的
├─────────────────────────────────────────┤
│  本轮用户问题                            │ ← 真正的"提问"
└─────────────────────────────────────────┘

每一行都在抢同一个窗口的额度。 Context Engineering 干的就是给这些内容排座位、定份额、做精简。

四、Context Engineering 的核心动作

1. 选（Selection）——只装相关的

不是所有信息都该进上下文。

• 用户在聊"今天的代码 Bug"，昨天聊菜谱的对话就不该带进来。
• 项目里 1000 个文件，这次只动两个，就只把这两个加上。
• 注册了 50 个工具，这次任务只需要 3 个，剩下的别注册。

选不对，再大的窗口也是浪费。

2. 压（Compression）——让内容变小但不变味

常见的压缩手段：

手段	做法	适用场景
截断	只保留最近 N 轮	闲聊、短任务
摘要	用模型把前面对话压成一段总结	长对话、客服
结构化提取	把对话压成一个 JSON：“用户偏好=…”	长期记忆、用户画像
滑动窗口	永远保留 system + 最近 K 条	流式聊天
分层缓存	近期完整 + 中期摘要 + 远期标签	Agent 长任务

3. 排（Ordering）——把重要的放对位置

由于"Lost in the Middle"现象：

• 最重要的指令：放在 System Prompt 开头 或 用户消息末尾。
• 关键资料：宁可放在末尾，也别夹在中间。
• 历史对话：可以摘要后放头部，详细的最近几轮放尾部。

一个好用的经验法则：

首尾醒目，中间打折。

4. 取（Retrieval）——按需现取

与其把所有资料塞进上下文，不如让模型在需要时自己去拿：

• 用 RAG 从知识库里实时检索几段相关的
• 用 Tools 让它自己调 API、读文件
• 用渐进式披露（progressive disclosure），一开始只给目录，需要细节时再读对应章节
  （这正是 Agent Skill 的核心思路）

5. 存（Memory）——跨会话保留

长期记忆不该塞在每次对话里，而应外置：

• 关键事实写进文件 / 数据库
• 用户偏好结构化存储
• 每次只把和当前问题相关的那部分捞回来

Memory 不是"记得越多越好"，而是"该记的记得住，不该带的不带进来"。

五、一个真实例子：长对话怎么管

假设你做了一个客服机器人，用户已经聊了 80 轮。直接把 80 轮喂给模型，token 爆炸还效果差。工程上的标准做法：

[System Prompt]                        ← 固定不变
[长期记忆：用户姓名/会员等级/历史订单]   ← 从数据库捞
[摘要：前 70 轮对话压成 5 句话]         ← 模型自己总结
[最近 10 轮原文]                       ← 保留细节
[本轮用户问题]                         ← 当前提问

好处：

• token 大幅缩减（80 轮 → 摘要+10 轮）
• 重要事实不丢（写进了"长期记忆"）
• 当前语境清晰（最近 10 轮原文）

六、Context Engineering 的常见反模式

反模式	为什么糟糕
把整本文档塞进 Prompt	模型注意力被稀释，关键信息反而被忽略
“反正窗口大，全塞进去再说”	又贵又慢，效果还差
每轮都重新塞一次系统提示+工具+历史	浪费 token、错过 prompt cache
不做摘要，硬靠截断	关键信息一旦被截掉就再也找不回来
把工具定义写得又长又啰嗦	工具 schema 也是占 token 的
临时资料和长期记忆混在一起	该忘的忘不掉，该记的记不住

七、Context Engineering 与 Prompt / Harness 的关系

再回到那条因果链：

阶段	关心的问题	类比
Prompt Engineering	一句话怎么说？	写一句台词
Context Engineering	这一次请求里装什么？	给演员一份剧本
Harness Engineering	整个系统长期跑下去如何稳定？	整个剧组的运作

Prompt 是"一句话"的工程；Context 是"一次请求"的工程；Harness 是"一整个系统"的工程。

Context Engineering 是承上启下的关键——它把 Prompt 工程的"那句话"，扩展到一整个信息空间的设计。

八、给开发者的 6 条实战准则

1. 能不塞就不塞：每加一段都问自己"这次任务真的需要它吗？"
2. 结构化优于自然语言：能用 JSON 表达的状态，别用一段散文。
3. 首尾放重点，中间放铺垫：避免"Lost in the Middle"。
4. 历史对话必须有压缩策略：截断、摘要、分层，三选一。
5. 工具按需注册：当前阶段用不到的工具就别注册。
6. 善用 Prompt Cache：把不变的部分（System、工具）放在最前面，让缓存能命中。

九、小结

• Context Engineering = 给模型"摆桌子"的艺术。
• 核心五个动作：选、压、排、取、存。
• 不是"窗口越大越好"，而是"装得越准越好"。
• 它处于 Prompt 和 Harness 中间，是 AI 工程化绕不开的一环。

一句话总结：模型能不能做对事，常常不是它笨，而是你给它的信息不对。