上下文工程：AI 智能体时代的核心技能

一句话结论：随着智能体要跨多轮、长时段运行，"写好一句提示"已经不够了。核心问题变成：在有限的上下文窗口里，每一步该放进去哪些 token——这就是上下文工程。

本文完整编译自 Anthropic 工程博客《Effective context engineering for AI agents》（作者：Anthropic Applied AI 团队），并做了中文整理。

一、提示工程 vs. 上下文工程

• 提示工程关注的是"如何写出有效的提示"，尤其是系统提示。
• 但当我们构建的是跨多轮推理、更长时段运行的智能体时，需要管理的是整个上下文状态：系统指令、工具、MCP、外部数据、消息历史等。

一个在循环中运行的智能体，会不断产生"对下一轮可能有用"的新信息，这些信息必须被循环地提炼。

上下文工程，就是从"不断膨胀的可能信息宇宙"里，为有限的上下文窗口策展该放什么。

区别在于：写提示是一次性的动作；而上下文工程是迭代的——每一次决定"传给模型什么"，都是一次策展。

二、为什么它对"能力强的智能体"至关重要

一个反直觉的事实：上下文越长，模型准确回忆其中信息的能力反而下降。针尖里找针（needle-in-a-haystack）类评测揭示了一个现象——上下文腐化（context rot）：token 越多，召回越差。虽然不同模型退化程度不同，但这是所有模型共有的特性。

因此，上下文必须被当作一种有限资源，且存在边际收益递减：

• 人类的工作记忆容量有限；LLM 也有一个"注意力预算"。
• 每引入一个新 token，都会消耗一部分预算。

这种"注意力稀缺"源于架构约束：

1. Transformer 让每个 token 都能注意所有其它 token，n 个 token 就是 n² 组两两关系。上下文一长，这些关系被"摊薄"了。
2. 模型的注意力模式来自训练数据分布，而短序列比长序列常见——所以模型对"全局依赖"的经验和专门参数都更少。
3. 位置编码插值等技术能让模型处理更长序列，但对 token 位置的理解会有一定退化。

这些因素叠加，形成的是性能梯度（gradient），而非断崖：模型在长上下文里依然能干活，但信息检索与长程推理的精度会下降。

结论：想要打造可靠的智能体，认真的上下文工程是必需的。

三、有效上下文的"解剖"

既然注意力预算有限，好的上下文工程就是：

找到一组尽可能小的"高信号" token，最大化得到期望结果的概率。

这句话说起来容易。下面按上下文的几个组成部分展开。

3.1 系统提示

系统提示应当极其清晰，用简单直接的语言，把内容放在对智能体而言"恰当的抽象高度"上。

这个"恰当高度"处在两种常见失败模式的中间：

• 太低（过度工程）：把复杂、脆弱的逻辑硬编码进提示，想精确控制行为——结果是脆弱、难维护。
• 太高（过于含糊）：给的是模糊的高层指引，没有具体信号，或错误地假设了共享上下文。

最优解是平衡：具体到能有效引导行为，又灵活到能给模型强启发式。

做法建议：

• 把提示分成清晰的区块（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），用 XML 标签或 Markdown 标题分隔。
• 追求能完整描述期望行为的"最小信息集"。注意："最小"不等于"短"——该给的上下文还是要给足。

推荐流程：先用最强模型 + 最小提示试跑，再根据暴露出的失败案例，逐步加入清晰指令和示例。

3.2 工具

工具定义了智能体与信息/动作空间之间的契约，所以必须"高效"：

• 返回信息要 token 高效；
• 激励高效的智能体行为。

工具应像设计良好的代码库函数：自包含、抗错误、用途极其明确；输入参数要有描述性、无歧义，并贴合模型擅长的方式。

最常见的失败模式之一是"工具膨胀"：工具集覆盖太多功能，导致"该用哪个"含糊不清。

如果人类工程师都无法确定某情形该用哪个工具，就不能指望 AI 智能体能做得更好。

后续会讲：维持一个最小可用工具集，还能让长交互中的上下文更可靠地维护与裁剪。

3.3 示例（few-shot）

提供示例是长期的最佳实践。但团队常犯的错是：把一大堆边缘情况塞进提示，试图穷举所有规则——不推荐。

正确做法是：策展一组多样、典型的规范示例（canonical examples），清晰地体现期望行为。对 LLM 来说，示例是"胜过千言的图"。

3.4 消息历史

总体原则：让上下文既有信息量，又保持紧凑。

四、运行时检索与"智能体式搜索"

先给智能体一个简单定义：LLM 在循环中自主使用工具。随着模型变强，智能体的自主度可以提升。

上下文设计正在发生一个转变：

• 过去：推理前的嵌入检索（pre-inference retrieval）——提前把重要上下文检索出来。
• 现在：越来越多团队在此基础上叠加 "just in time"（即时） 策略。

4.1 Just-in-time 与渐进式披露

即时策略不预处理所有数据，而是让智能体维护轻量标识符（文件路径、存储的查询、网页链接等），在运行时用工具动态加载。

Claude Code 就是这么做的：它在大数据库上做复杂分析时，会写针对性查询、存储结果，并用 head、tail 这类 Bash 命令分析大量数据，而从不把整个数据对象塞进上下文。

这像人类认知：我们并不记住全部语料，而是借助文件系统、收件箱、书签等外部组织与索引，按需取回。

这些引用的元数据本身也提供精炼行为的信号：在文件系统里，tests/test_utils.py 和 src/core_logic/test_utils.py 含义不同；目录层级、命名约定、时间戳都在告诉人和智能体"该怎么用"。

让智能体自主导航，还能实现渐进式披露（progressive disclosure）：每一次交互都产生"指导下一次决策"的上下文——文件大小暗示复杂度，命名暗示用途，时间戳可作为相关性代理。智能体逐层拼装理解，只在工作记忆里保留必要信息，并用笔记策略做持久化。

代价：运行时探索比读取预计算结果更慢；而且需要用心工程——给对工具与启发式。否则智能体会误用工具、钻进死胡同、或漏掉关键信息。

4.2 混合策略

某些场景下最有效的智能体会用混合：一部分数据提前检索（求快），其余自主探索（求准）。边界取决于任务。

Claude Code 就是混合：CLAUDE.md 预先放进上下文，而 glob、grep 等原语让它即时导航、取文件，从而绕开"索引过期 / 语法树复杂"的问题。

随着模型变强，设计会越来越倾向"让聪明的模型自主行动，人类少干预"。但就目前而言，"做能跑通的最简单的事"仍然是最好的建议。

五、长程任务的上下文工程

长程任务指 token 总量超出上下文窗口的任务（例如大型代码库迁移、综合研究），可能持续几十分钟到数小时。

等"更大的上下文窗口"看似是解法，但可预见的未来里，任何规模的窗口都会面临上下文污染与相关性下降（尤其在追求最强表现时）。

为此有三类技术：压缩、结构化笔记、多智能体架构。

5.1 压缩（Compaction）

把接近窗口上限的对话摘要化，再用摘要开启一个新窗口继续。它通常是提升长期连贯性的第一根杠杆。

核心是高保真地蒸馏：让智能体以最小性能损失继续。

在 Claude Code 里，做法是把消息历史交给模型摘要压缩：保留架构决策、未解决的 bug、实现细节，丢弃冗余的工具输出或消息；然后用"压缩后的上下文 + 最近访问的 5 个文件"继续。

难点在于取舍：压缩太激进，会丢掉"当下不起眼、后来很关键"的细节。

给实现者的建议：

• 在复杂智能体轨迹上仔细调提示；
• 先最大化召回（recall），确保不遗漏相关信息；
• 再迭代提升精度（precision），剔除冗余；
• 一个"低垂的果实"是清理工具调用与结果——工具早就在历史深处调用过了，为什么还要再看原始结果？工具结果清理是最安全、最轻量的压缩形式。

5.2 结构化笔记（Structured note-taking / agentic memory）

让智能体定期把笔记写到上下文之外的持久记忆里，之后再按需取回。开销小、收益大。

例子：

• Claude Code 自己维护待办清单；
• 自定义智能体维护一个 NOTES.md。

这让智能体能跨复杂任务跟踪进度、保住关键上下文与依赖，而这些在几十次工具调用后本来会丢失。

更生动的例子：Claude 玩宝可梦。它能在数千步里维持精确计数（"过去 1234 步我在 1 号道路训练，皮卡丘朝目标 10 级涨了 8 级"），在没有任何记忆结构提示的情况下，自己画出了已探索区域的地图、记住了已解锁的关键成就、并维护战斗策略笔记。上下文重置后，它读自己的笔记，继续数小时的训练或地下城探索。

这种"跨摘要步骤的连贯性"，让单靠上下文窗口不可能实现的长程策略成为可能。

配套：Anthropic 在 Sonnet 4.5 发布时，在 Claude 开发者平台公测了 memory 工具，用基于文件的方式让智能体在窗口之外存取信息，从而积累知识库、跨会话保持项目状态、引用此前工作。

5.3 子智能体架构（Sub-agent architectures）

另一种绕过上下文限制的方式：不再让一个智能体维护整个项目的状态，而是让专用子智能体在干净的上下文窗口里处理聚焦任务。

• 主智能体负责高层规划与协调；
• 子智能体做深度技术工作或检索；
• 子智能体可能探索数万 token，但只返回一个精炼摘要（常见 1000–2000 token）。

这实现了清晰的关注点分离：详细的搜索上下文被隔离在子智能体内，主智能体专注综合与分析。Anthropic 的多智能体研究系统表明，这在复杂研究任务上显著优于单智能体。

5.4 怎么选

即便模型持续变强，在长交互中维持连贯性，仍将是构建有效智能体的核心挑战。

六、结论

上下文工程代表了"用 LLM 构建应用"的一次根本转变：挑战不再只是"打磨完美提示"，而是每一步都用心策展进入模型有限注意力预算的信息。

无论你是在为长程任务实现压缩、设计 token 高效的工具、还是让智能体即时探索环境，指导原则都一样：

找到一组尽可能小的高信号 token，最大化得到期望结果的概率。

这些技术会随模型进步而进化。我们已经看到，更聪明的模型需要更少的"指令式工程"，能自主度更高。但即便如此，把上下文当作珍贵而有限的资源，仍将是构建可靠、有效智能体的核心。

参考来源

• Anthropic Engineering：Effective context engineering for AI agents（作者：Anthropic Applied AI 团队）

延伸阅读（本站）

• MCP 是什么
• Agent / MCP 完全指南

本文由汇智网编译整理，转载请注明出处。