> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 上下文工程：AI 智能体时代的核心技能 - URL: https://www.hubwiz.com/blog/context-engineering-for-ai-agents/ - Published: 2026-10-13T22:05:07.000Z - Updated: 2026-10-14T17:16:44.000Z - Description: 上下文是一种有限资源，存在"注意力预算"。本文完整编译 Anthropic 工程博客：有效上下文的解剖（系统提示/工具/示例/历史）、运行时 just-in-time 检索、以及长程任务的压缩、结构化笔记与子智能体架构。 - Author: admin - Tags: AI Agent, 上下文工程, 提示工程, LLM, MCP, #Import 2026-10-14 14:41 **一句话结论**：随着智能体要跨多轮、长时段运行，"写好一句提示"已经不够了。核心问题变成：**在有限的上下文窗口里，每一步该放进去哪些 token**——这就是上下文工程。 本文完整编译自 Anthropic 工程博客《Effective context engineering for AI agents》（作者：Anthropic Applied AI 团队），并做了中文整理。 --- ## 一、提示工程 vs. 上下文工程 - **提示工程**关注的是"如何写出有效的提示"，尤其是系统提示。 - 但当我们构建的是**跨多轮推理、更长时段运行的智能体**时，需要管理的是**整个上下文状态**：系统指令、工具、MCP、外部数据、消息历史等。 一个在循环中运行的智能体，会不断产生"对下一轮可能有用"的新信息，这些信息必须被**循环地提炼**。 > **上下文工程**，就是从"不断膨胀的可能信息宇宙"里，为有限的上下文窗口**策展**该放什么。 区别在于：写提示是一次性的动作；而上下文工程是**迭代的**——每一次决定"传给模型什么"，都是一次策展。 ![提示工程 vs. 上下文工程：从“写提示”到“策展上下文”](https://www.hubwiz.com/blog/content/images/2026/10/img_9a396bc6892c7af25f9590d5ee7888ff-1.png) ## 二、为什么它对"能力强的智能体"至关重要 一个反直觉的事实：**上下文越长，模型准确回忆其中信息的能力反而下降**。针尖里找针（needle-in-a-haystack）类评测揭示了一个现象——**上下文腐化（context rot）**：token 越多，召回越差。虽然不同模型退化程度不同，但这是**所有模型共有的特性**。 因此，上下文必须被当作**一种有限资源**，且存在**边际收益递减**： - 人类的工作记忆容量有限；LLM 也有一个**"注意力预算"**。 - 每引入一个新 token，都会消耗一部分预算。 这种"注意力稀缺"源于架构约束： 1. Transformer 让**每个 token 都能注意所有其它 token**，n 个 token 就是 **n² 组两两关系**。上下文一长，这些关系被"摊薄"了。 2. 模型的注意力模式来自训练数据分布，而**短序列比长序列常见**——所以模型对"全局依赖"的经验和专门参数都更少。 3. **位置编码插值**等技术能让模型处理更长序列，但对 token 位置的理解会有一定退化。 这些因素叠加，形成的是**性能梯度（gradient），而非断崖**：模型在长上下文里依然能干活，但**信息检索与长程推理的精度会下降**。 结论：想要打造可靠的智能体，**认真的上下文工程是必需的**。 ## 三、有效上下文的"解剖" 既然注意力预算有限，好的上下文工程就是： > **找到一组尽可能小的"高信号" token，最大化得到期望结果的概率。** 这句话说起来容易。下面按上下文的几个组成部分展开。 ### 3.1 系统提示 系统提示应当**极其清晰**，用简单直接的语言，把内容放在**对智能体而言"恰当的抽象高度"**上。 这个"恰当高度"处在两种常见失败模式的中间： - **太低（过度工程）**：把复杂、脆弱的逻辑硬编码进提示，想精确控制行为——结果是脆弱、难维护。 - **太高（过于含糊）**：给的是模糊的高层指引，没有具体信号，或**错误地假设了共享上下文**。 最优解是平衡：**具体到能有效引导行为，又灵活到能给模型强启发式**。 ![系统提示的“恰当高度”：介于“硬编码脆弱逻辑”与“过于含糊”两个失败模式之间](https://www.hubwiz.com/blog/content/images/2026/10/img_861c370bac5c79f51d0ac4760a60fe1d-1.png) 做法建议： - 把提示**分成清晰的区块**（如 ``、``、`## 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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents?ref=hubwiz.com)（作者：Anthropic Applied AI 团队） ## 延伸阅读（本站） - [MCP 是什么](https://www.hubwiz.com/blog/what-is-mcp-model-context-protocol/) - [Agent / MCP 完全指南](https://www.hubwiz.com/blog/agent-stack/) *本文由汇智网编译整理，转载请注明出处。*