Context Engineering：决定 AI Agent 智能上限的工程

引言：为什么同样的模型，表现天差地别

同一个 GPT-4 级模型，有人用它写代码像高级工程师，有人用它写代码像刚毕业的实习生。差距不在模型，在上下文。

模型的推理能力在训练时就被冻结了，但它的"工作记忆"是每次请求时由上下文动态决定的。上下文里装了相关的规范、相关代码、相关历史，它就聪明；上下文里塞满了无关信息，它就开始犯低级错误——漏掉关键约束、答非所问、编造不存在的事实。

Context Engineering 要回答的问题就三个：

1. 什么信息必须进上下文？
2. 什么信息不该进上下文？
3. 进了上下文的信息，如何组织和保鲜？

本文讲清楚这个领域的关键机制、工程手段和常见误区。它和我之前写过的 Skill 工程化是配套的——Skill 解决"能力怎么封装"，上下文工程解决"封装好的能力怎么精准地出现在模型眼前"。

一、先搞懂上下文为什么"有限"

大模型上上下下流传一句话：窗口很大，但"有效注意力"很小。这不是玄学，是有实验支撑的：

• Lost in the middle：当需要的信息位于长上下文的中间位置时，模型检索能力明显下降；开头和结尾的信息更容易被利用。这意味着一味往上下文里加东西不只是"浪费 token"，而是主动降低性能。
• 注意力稀释：上下文里的无关 token 会分摊有限的注意力预算。塞进 50KB 无关材料去"以防万一"，等于让 50KB 噪音稀释 10KB 有效信息。
• 上下文污染：过时的、矛盾的、低质量的信息进入上下文后，模型会如实继承这些"错误记忆"，而且很难靠提示词纠正。上下文里的一条错误比没这条信息更糟。

所以上下文工程的第一个原则是反直觉的：处理上下文的重点不是"装得下多少"，而是"装得多准、多干净"。

二、上下文工程的四个操作面

可以把上下文工程拆成四个连续动作：注入、压缩、检索、遗忘。

1. 注入（Injection）——决定"默认底座"

固定进上下文的系统级内容：人格设定、全局规则、工具清单、安全约束。这部分是"常驻内存"，被反复调用，必须极简。

• 每句话都要问：这句话是每次都需要，还是偶尔需要？
• 偶尔需要的内容不进 system prompt，改走检索或动态拼装。
• 注入的内容要可版本化、可审计。线上事故排查时，你得能回答"昨天 19 点，它看到的是什么版本的规则"。

2. 压缩（Compression）——决定"能装多少历史"

对话越长，上下文越贵、越容易漂移。压缩有三个层级，由轻到重：

• 摘要式压缩：把较早的历史对话压缩成摘要，保留结论和未完成事项。适合有明确结论的场景。
• 结构化压缩：只保留"事实型"信息（决策、任务状态、约束、ID），丢弃过程性对话。适合任务执行类 Agent。
• 外部化：把完整历史落库，上下文里只保留指针和索引，需要时按需拉回。这是最彻底也是工程成本最高的方案。

3. 检索（Retrieval）——决定"按需能拿到什么"

当信息量大到无法常驻时，就必须精准地"捞"进上下文。这就是 RAG 和各类知识插件存在的意义。关键技术点：

• 分块要符合"语义完整 + 足够小"的平衡，粗暴按固定字数切块会切断语义。
• 检索结果要降噪：只取 score 最高的 top-k，并给每块标注来源与时间，让模型知道自己读到的是什么。
• 检索失败比不检索更糟——没检索到相关内容时，要明确告知模型，避免它基于缺失知识强行编造。

4. 遗忘（Forgetting）——决定"什么时候过期"

上下文不是越全越好，过时信息必须能被清除：

• 带时间的指令（"按上周的方案执行"）要显式失效机制。
• 来自不同会话的信息不能混入当前上下文，防止跨会话串味。
• 用户的更正优先级要高于早前指令，并且只能推向后续请求，不能回改已执行的步骤。

三、与他人的关系：Context Engineering 和其他手段怎么分工

三条边界值得强调：

• 能靠上下文解决的，不要靠微调。微调擅长改变"行为风格"（输出格式、语气、工具调用习惯），不擅长记忆大量事实——事实频繁更新，模型参数里的知识却无法热更新。
• 能靠检索解决的，不要常驻上下文。知识库动辄百万量级，常驻是浪费；按需检索既省 token 又减少稀释。
• Context Engineering 是上述手段的上游。检索到的内容、微调后的行为，最终都要通过"组织好的上下文"才作用于模型。它是在提示词之上更高一层的抽象。

四、落地时的通用抓手

无论用什么技术栈，以下五件事是最高杠杆的：

1. 把所有"偶尔才需要"的内容从 system prompt 里搬走，改成按需动态注入或检索。这一步通常能立竿见影。
2. 给每段注入的内容标时间戳和来源，让模型具备"这份信息新不新"的判断依据。
3. 固定缓存友好的内容布局：把稳定的规则放开头（被打包在 prompt cache 里）、把易变的内容放末尾，最大程度复用缓存、降低成本。
4. 建一份"上下文清单"：像清单一样记录当前会话里到底注入了哪些模块、各占多少 token、分别是什么来源。没有这张清单，就无法复盘"这次表现为什么好/坏"。
5. 给关键路径加度量：至少记录 token 消耗、检索命中率、按模块拆分的注入占比。退化都是缓慢累积的，没有度量就看不见。

五、常见误区

• "窗口大，随便装"：窗口大不等于注意力够用，装得越多反而越笨。
• "把全部知识倒进 system prompt"：这是最常见的做法，也是最容易的退化方式——上下文迅速膨胀，核心信息被稀释。
• "多放一点背景总没错"：放进去的每块背景都要经过"真实相关"的验证，未经验证的背景是噪音。
• "历史会话全保留"：保留全部历史对话是偷懒，会让早期错误决策持续污染后续所有请求。
• "只重视准确率，不重视丢失率"：检索链路的召回率下降时，模型不会报错，它会安静地凭想象作答——这比报错可怕得多。

总结

Context Engineering 的核心心法只有一句：上下文是一种稀缺资源，要用工程手段管理，而不是靠直觉堆砌。

• 注入：常驻内容要极简、可版本化。
• 压缩：历史要分级处理，能外部化就别常驻。
• 检索：按需捞取，捞不到要明说，别让模型脑补。
• 遗忘：过时的信息必须被清除，不能被继承。

把上下文当数据库一样治理——有 schema、有版本、有审计、有监控——Agent 系统的性能才会有确定性。这也是 Skill 工程化（能力封装）、RAG（知识供给）、Context Engineering（信息架构）三者合起来，构成现代 Agent 工程黄金三角的原因。