从提示词工程到上下文工程

Anthropic 在不久前发布了一篇关于智能体上下文工程的长文，读完之后觉得很有启发，这里把核心观点梳理一遍，算是一份读书笔记。

01 — Prompt Engineering vs Context Engineering

先搞清楚一个基础概念：上下文，指的是从大语言模型（LLM）采样时包含的那些 token 集合。

下面这张对比图很直观地解释了提示词工程和上下文工程的区别。提示词工程的核心是“引导”，教会大模型怎么思考，从而得到我们想要的结果。而上下文工程呢？它更像是一个后端管家，负责把智能体运行过程中，大模型吐出的信息进行整合、提炼，甚至做持久化的管理。这两者并不是非此即彼的关系，它们是互相打配合的。

两者各有专攻：提示词工程解决的是“单次问答”的最优解，而上下文工程瞄准的是“多轮自主任务”的最优解。场景不同，侧重点自然也不一样。

02 — 上下文工程对智能体的重要性

文章里提到了一个很有意思的观点：上下文是会“腐烂”的。

Anthropic 用“大海捞针”这个经典实验，给出了一组相当冷酷的数据：上下文长度低于 8k 时，模型召回率高达 95%；一旦撑到 32k，召回直接掉到 78%；要是拉到 100k，关键信息被模型“视而不见”的概率直接飙到 30%。

说白了，随着上下文窗口里 token 数量的膨胀，模型准确回忆信息的能力是直线下降的。

这个问题的根源，其实藏在 LLM 的架构基因里。Transformer 架构让每个 token 都能跟整个上下文里的所有其他 token 建立关联，这就会产生 n² 级别的成对关系。上下文一长，模型想要精准捕捉这些关系，就越来越吃力了。这就像是在上下文的大小和模型的注意力焦点之间，天生存在着一股拉扯的力量。

数据摆在这里，现实就很清楚了：要想构建出真正有能力的智能体，上下文工程这件事，必须认真对待。

03 — 好上下文的 4 个配方

1、提示词：高信号、低噪音

不要在提示词里写那种“if A 且 B 且 C 则执行 D”的脆弱逻辑，也别只说一句“请尽量做好”这种空话。正确的姿势是：把边界、目标、输出格式都清晰地给出来，让模型自己去推理路径。建议将提示词组织成不同的部分，比如 <背景信息>、<指令>、## 工具指导、## 输出描述 等，用 XML 标记或 Markdown 标题来划分，一目了然。

2、智能体工具调用：高效 token 和高效行为

工具是让智能体跟环境互动的桥梁，也在运行时不断引入新的上下文。但我们看到的常见失败模式之一，就是工具集过于臃肿，功能太多，导致模型在决定用哪个工具时模棱两可。这里有一个很朴素的道理：如果人类工程师自己都没法明确说出在某个场景下该用哪个工具，就别指望 AI 能做得更好。为智能体策划一个最小可行的工具集，反而有利于在长时间交互中维护和精简上下文。通过工具返回 token 高效的信息，同时规范智能体的行为，这才是提升 token 效率的关键。

3、示例（few-shot）：典型优于边缘

挑选 3 个能覆盖 80% 主流场景的典型示例，远胜于堆砌 20 条“罕见 corner case”。前者能让模型举一反三，后者只会让它迷失在细枝末节里。

4、动态检索

Anthropic 在另一篇文章里重新定义了智能体：LLM 在循环中自主使用工具。这也带来了上下文字段设计思路的转变。现在，很多 AI 原生应用开始采用基于嵌入的“推理前检索”模式，先检索出重要上下文，再交给智能体去推理。这不再是提前把所有数据都塞进上下文，而是走“即时”路线——智能体只维护轻量级的标识符（比如文件路径、存储查询、网页链接），通过工具在运行时按需动态加载数据到上下文中。这种做法，其实很像人类认知的方式：我们不会记住整个信息库，而是依靠文件系统、收件箱、书签这类外部系统，在需要的时候检索信息。

04 — 长程任务如何解决上下文问题

当任务从“分钟级”拉长到“小时级”，上下文窗口必然爆掉。针对这个难题，Anthropic 内部总结了三把“瑞士军刀”。

1、压缩

比如在 Claude Code 里，通过把消息历史传给模型去总结和压缩。模型会做一次“精加工”，把冗余的工具输出或消息丢弃掉，只保留架构决策、未解决的错误和实现细节这类真正关键的信息。优先对智能体深处的工具调用及结果进行压缩，往往效果最好——一旦工具在一次调用后深埋于消息历史里，后面的智能体就无需再看原始结果了。

2、结构化笔记

简单说就是智能体记忆。让智能体定期把笔记写入持久化的“抽屉”里，这个“抽屉”在上下文窗口之外，等到需要的时候再把它拉回来。这样就能把上下文空间腾出来给即时使用的信息。

3、子智能体架构

这是绕过上下文限制的另一种方案。与其让一个智能体整个项目都扛着重量级上下文，不如让专门的子智能体用轻量上下文去处理集中的任务。主智能体负责高级计划与协调，子智能体则深入执行具体的技术工作或用工具搜索信息。每个子智能体可能会耗费数万个 token 做大量探索，但最终只返回一份浓缩的总结（通常 1,000-2,000 token）。这实现了关注点的清晰分离——详细的探索上下文被关在了子智能体内部，而主智能体专注做综合和分析。Anthropic 在他们的多智能体研究系统中测试过，在分析 100 页 PDF 的任务上，子智能体方案比单智能体系统准确率提升了 27%，而 token 消耗反而降低了 40%。

05 — 结语

提示词时代，我们像搭讪高手，用一句话吸引模型；上下文时代，我们像电影导演，用整场戏讲好故事。当你的智能体开始自己查资料、写笔记、指挥小弟干活时，请记住：限制它的从来不是智商，而是你给它的注意力预算。