上下文工程（Context Engineering）：给模型对的信息
"Prompt 工程的时代正在让位给 Context 工程。区别在于：prompt 关心'怎么说'，context 关心'给模型看什么'。本文讲清四类上下文、上下文窗口的管理策略（优先级/压缩/遗忘），以及一个 Agent 的上下文该怎么搭——决定 Agent 上限的，往往不是模型多强，而是你喂了什么。"
本文要点
- 主题聚焦：AI、大模型
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
过去两年大家痴迷于"怎么把 prompt 写好"。但随着模型变强、上下文窗口变长，瓶颈悄悄转移了：决定 Agent 表现的，不再是"你怎么措辞"，而是"你往它的上下文里放了什么"。这就是 Context Engineering（上下文工程）——它和 prompt engineering 不冲突，但关注点不同。
一、Prompt 工程 vs 上下文工程
一个粗略但有用的区分：
- Prompt 工程：关心指令怎么写——角色、格式、措辞、few-shot。
- 上下文工程：关心信息怎么选——这一刻模型应该看到哪些文档、历史、状态、工具结果。
举个对比：让 Agent 答一个领域问题。
- prompt 工程的思路：写一个很好的 system prompt，要求它"严谨、分点、引用来源"。
- 上下文工程的思路：先确保正确的资料被检索进来、无关内容被裁掉、关键约束被放在显眼位置。
模型足够强之后，"怎么说"它基本都听得懂；真正拉开差距的是"它看到的上下文质量"。Garbage in, garbage out 这句话在 LLM 时代变成了 Context in, quality out。
二、四类上下文
一个生产级 Agent 的上下文，通常由四类信息拼成：
| 类型 | 例子 | 特点 |
|---|---|---|
| 指令 | system prompt、规则、格式要求 | 稳定，适合 caching |
| 示例 | few-shot、参考输出 | 半稳定，精选 |
| 检索 | RAG 召回的文档、工具返回的结果 | 每次变化，要筛选 |
| 状态 | 对话历史、任务进度、已确认事实 | 累积，要压缩 |
很多 Agent 的上下文问题，出在这四类配比失衡：要么指令堆太多淹没检索结果，要么历史太长挤掉了关键指令，要么检索塞了一堆无关的。上下文工程的核心，就是动态地管好这四类的优先级和体量。
三、上下文窗口的管理策略
长上下文模型（100K–1M）让人产生"全塞进去就行"的错觉。但能塞 ≠ 该塞——上下文越长，模型对中间内容的注意力越稀释（lost-in-the-middle 现象），还会拖慢推理、烧 token。三个策略：
1. 优先级排序：重要的放两头。 模型对开头（system prompt、任务定义）和结尾（最新指令、待处理数据）的注意力最强。所以：稳定指令放最前，当前要处理的数据放最后，中间放检索/历史。
2. 压缩：别让历史无限增长。 多轮对话/长任务里，历史很快撑爆窗口。三种压缩：
- 滑动窗口 + 摘要：保留最近 N 轮原文，更早的压成摘要。
- 结构化状态：把"已确认的事实"抽成 JSON 存进 state，不依赖自然语言历史。
- 工具结果裁剪：工具返回的大段结果，提取关键字段，不留全文。
3. 主动遗忘：上下文不是越多越好。 过时的信息（早期假设、已被推翻的判断）要主动从上下文移除，否则会误导模型。一个会"忘掉自己之前错的想法"的 Agent，比一个全记住的 Agent 表现更好。
四、实战：搭一个 Agent 的上下文
假设做一个"代码库问答 Agent"，每轮它的上下文应该这样组装：
[指令区 - 稳定, 走 caching]
system: 你是代码库助手,只根据提供的代码片段回答…
规则: 找不到就说不知道;引用文件路径
[状态区 - 压缩]
已确认: 用户在调研支付模块;用 TypeScript
[检索区 - 本轮召回, rerank 后 top-3]
<file src="payment/service.ts">…</file>
<file src="payment/refund.ts">…</file>
[本轮指令 - 最新]
用户问题: 退款逻辑在哪?
要点：
- 指令稳定 → 命中 prompt caching，省成本。
- 状态压缩成两行，不堆历史。
- 检索只喂 rerank 后的少量，宁缺毋滥。
- 本轮问题放最后，注意力最强。
这个结构比"把整个对话 + 召回的 20 个文件 + system prompt 全塞进去"好得多——前者模型能精准回答，后者模型在信息洪流里迷失。
五、上下文工程的具体动作
把"上下文工程"落到日常，是一组可操作的习惯：
- 每轮问自己：模型这一步真正需要看到什么？ 不是"有什么相关都塞"，而是"没有这条它就答不了吗"。
- 给上下文加结构。 用标签/分隔符标清指令、检索、数据的边界，模型找信息更准。
- 监控上下文构成。 在 trace 里记录每次请求的"指令/检索/历史"各占多少 token——某类暴涨往往是问题信号。
- 检索质量 > 检索数量。 与其召回 20 条喂进去，不如花精力把 3 条最相关的喂进去。Rerank 的价值正在这里。
- 能用 state 就别用历史。 "用户已登录""订单已支付"这种事实，存进结构化 state，别让模型从几十轮对话里自己推断。
小结
模型一年比一年强，"怎么写 prompt"的边际收益在递减；而"给模型什么上下文"的边际收益在上升。Context Engineering 是 Agent 时代的新基本功。
四类上下文（指令/示例/检索/状态）、三个窗口策略（优先级/压缩/遗忘）、加上"每轮只喂必要信息"的纪律——这套组合，决定你的 Agent 是"性能强劲但乱撞"，还是"精准可控"。记住一句话：最强的模型配上最差的上下文，打不过中等模型配上精心组织的上下文。
Related