打造高效 AI Agent：Context Engineering 实践指南

在 AI 应用领域，Prompt Engineering（提示工程）火了好几年之后，一个新概念开始受到关注：Context Engineering（上下文工程）。现在用大语言模型做开发，已经不只是给提示词找对词汇和句式这么简单了，而是要回答一个更核心的问题：“给模型什么样的上下文，最容易让它做出我们想要的行为？”

Context（上下文）说白了就是你输入给大语言模型（LLM）的那些内容（token）。现在的工程问题就是：怎么在 LLM 的限制条件下，让这些内容发挥最大价值，稳定地得到我们想要的结果。想要用好 LLM，关键是要基于上下文来思考——也就是说：随时考虑 LLM 能看到什么信息，这些信息会让它产生什么行为。

这篇文章里，我们会聊聊 Context Engineering 这门新手艺，给大家提供一个清晰的思路，帮助你构建好用、靠谱的 AI Agents。

Context Engineering vs. Prompt Engineering

在 Anthropic，我们把 Context Engineering 看作是 Prompt Engineering 的升级版。Prompt Engineering 就是怎么写好提示词，让 LLM 给出最好的结果（可以看看我们的文档了解更多技巧）。而 Context Engineering 则更进一步，它关注的是在 LLM 运行过程中，怎么精心挑选和维护最合适的信息集，不只是提示词，还包括所有其他可能输入的内容。

早期用 LLM 做开发时，主要就是写提示词，因为大部分场景都是做文本分类或生成这种一次性任务。但现在不一样了，我们开始构建更强大的 AI Agents——这些 Agents 能进行多轮思考，能长时间运行——所以我们需要管理整个上下文状态，包括系统指令、工具、模型上下文协议（MCP）、外部数据、聊天历史等等。

AI Agents 在循环运行时，会不断产生大量可能对下一步有用的数据，这些信息需要不断筛选和提炼。Context Engineering 就是要从这个不断膨胀的信息海洋中，精心挑选出最关键的内容，塞进有限的上下文窗口里。

写提示词是一次性的工作，而 Context Engineering 是持续迭代的——每次给模型传内容时，都要精心挑选。

为什么 Context Engineering 对构建强大的 AI Agents 很重要

虽然 LLM 速度快，能处理海量数据，但我们发现它和人一样，处理太多信息时会分心、会犯糊涂。研究人员做了很多“大海捞针”式的测试，发现了一个叫 Context Rot（上下文腐烂）的现象：上下文窗口里塞的内容越多，模型从中准确找信息的能力就会下降。

所有模型都有这个问题，只是程度不同。所以，上下文就像一个收益递减的有限资源。就像人的工作记忆容量有限一样，LLM 处理大量上下文时也有个“注意力预算”。每加一个 token，都会消耗一点这个预算，所以我们得仔细挑选给 LLM 看什么。

这种注意力稀缺性，来自 LLM 的底层架构限制。LLM 基于 Transformer 架构，它让每个 token 都能关注其他所有 token，覆盖整个上下文。这会产生 n² 级别的成对关系（n 是 token 数）。

随着上下文越来越长，模型处理这些成对关系的能力就会被稀释，在上下文大小和注意力集中度之间产生矛盾。而且，模型是从训练数据中学习注意力模式的，训练数据里短文本比长文本多得多。这意味着模型处理长上下文的经验更少，专门的参数也更少。

正因为这些现实情况，深思熟虑的 Context Engineering 对构建强大的 AI Agents 至关重要。

有效 Context 的关键要素

既然 LLM 的注意力预算有限，好的 Context Engineering 就是要找到最精简的高质量内容集，来最大化得到理想结果的可能性。说起来简单，做起来难，下面我们来看看这个原则在不同组件中怎么应用。

System Prompt（系统提示）

要特别清晰，用简单直白的话，在合适的抽象层次给 AI Agent 提供指导。使用 XML 标签或 Markdown 标题来标记。

Tools（工具）

工具的效率特别重要——既要返回精简高效的信息，也要引导 Agent 高效行动。工具应该是自包含的、能处理错误的，在用途上也要特别明确。

Few-shot Prompting（少样本提示）

我们建议精心挑选一组多样化的典型示例，有效地展示 Agent 应该有的行为。对 LLM 来说，示例就像“一图胜千言”。

Context 检索和 Agent 搜索

和提前处理所有相关数据不同，用“即时”方法构建的 Agent 只维护轻量级的标识符（文件路径、查询、网络链接等），在运行时用工具动态加载数据到上下文中。这种方法其实很像人类的认知过程：我们通常不会记住所有信息，而是用外部的组织和索引系统（比如文件系统、收件箱、书签）来按需检索相关信息。

让 Agent 自主导航和检索数据，还支持渐进式披露——换句话说，让 Agent 通过探索逐步发现相关上下文。Agent 可以逐层构建理解，只在工作记忆中保留必要的内容。

长期任务的 Context Engineering

对于那些要花几十分钟到几小时的任务（比如大型代码库迁移或综合研究项目），Agent 需要一些专门的技术来应对上下文窗口大小的限制。

Compression（压缩）

压缩就是把快满的对话进行总结，用摘要来重启一个新的上下文窗口。它的核心思想是：尽可能高保真地提炼上下文窗口的内容，让 Agent 能以最小的性能损失继续工作。

Structured Notes（结构化笔记）

结构化笔记，或者叫 Agent Memory（记忆），是一种让 Agent 定期把笔记存到上下文窗口之外的内存里的技术。这种策略开销很小，却能提供持久记忆。

Multi-Agent 架构

与其让一个 Agent 在整个项目中维护状态，不如让专门的子 Agent 用干净的上下文窗口处理专注的任务。主 Agent 负责高层规划和协调，而子 Agent 执行深入的技术工作或用工具查找相关信息。

结论

Context Engineering 代表了我们使用 LLM 构建应用方式的根本转变。随着模型越来越强大，挑战不再只是写个完美的提示——而是要在每一步深思熟虑地选择什么信息进入模型有限的注意力预算。