云栈社区»论坛 › 站务中心「 Forum Service 」 › AI Agent上下文工程：在有限注意力中实现高效配置 ...

发回帖发新帖

4222 积分	0 好友	613 主题

发消息

AI Agent上下文工程：在有限注意力中实现高效配置

发表于 1 小时前 | 查看: 2| 回复: 0

在 2026世界读书日：不荐书，只荐这一份「Agent智能体圣经」清单中提到一份博客清单，本文是其中一篇《Effective-Context-Engineering-for-AI-Agents》的译文，为中文读者提供一个了解 Agent 智能体系统底层设计逻辑的入口。英文好的同学建议直接查看英文原文。

上下文对 AI Agent 而言是一种至关重要却又有限的资源。本文将探讨如何有效策划和管理驱动 Agent 运行的上下文信息。

在应用 AI 领域，提示词工程（prompt engineering）一直是焦点，而如今一个新术语开始崭露头角：上下文工程（context engineering）。语言模型的构建不再仅仅是寻找合适的词语和短语，而是回答一个更宏观的问题：“什么样的上下文配置最有可能激发出模型预期的行为？”

此处的“上下文”指大语言模型（LLM）采样时纳入的 token 集合。需要解决的工程难题是，在 LLM 的固有约束下，优化这些 token 的效用，稳定达成预期结果。要有效驾驭 LLM，往往需要具备上下文思维——即考虑 LLM 在任何时刻可获得的整体状态，以及该状态可能产生的各类行为。

上下文工程与提示词工程

在 Anthropic，我们将上下文工程视为提示词工程的自然演进。提示工程是撰写 LLM 指令以获取最优结果的方法（关于概述及实用策略，请参阅官方文档）。上下文工程则是在 LLM 推理过程中，策划并维护一组最优 token 的策略，包含除提示词之外所有可能进入上下文的信息。

早期 AI 工程中，提示占最大比重，因为大多数用例需要精心设计的提示词来完成一次性分类或文本生成。但随着我们构建更强大的 Agent（需在多轮推理和更长时间跨度下运行），便需要管理整个上下文状态，包括系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等。

一个循环运行的 Agent 会不断生成可能与下一轮推理相关的数据，这些信息必须周期性归纳和提炼。上下文工程是一门从持续演化的信息海洋中甄选并策划哪些内容应被纳入有限上下文窗口的艺术与科学（参考 Karpathy 的讨论）。

Prompt engineering vs context engineering 对比图，左侧为单轮查询的提示工程，右侧为多轮 Agent 的上下文工程，包含文档、工具、记忆文件、综合指令等元素，展示了上下文窗口的构建过程

与编写提示词的离散任务不同，上下文工程是迭代的，每次决定将什么传递给模型时，都会进行内容整理阶段。

为什么上下文工程对构建强大 Agent 至关重要？

尽管 LLM 发展迅猛，能处理越来越庞大的数据量，但它们在某个临界点也会注意力涣散或感到困惑。针对“大海捞针”式基准测试的研究揭示了“上下文腐坏”概念（参考 Chrom 研究）：随着上下文窗口中的 token 增加，模型准确回忆信息的能力下降。

虽然有些模型的性能衰退更平缓，但这一特征在所有模型中都存在。因此，必须将上下文视为边际回报递减的有限资源。类似人类有限的工作记忆容量（参考相关研究），LLM 在解码大量上下文时也要消耗“注意力预算”。每个新 token 都会消耗预算，使得精心筛选可用 token 变得更加重要。

这种稀缺性源于 LLM 的底层架构限制。LLM 基于 Transformer 架构（具体技术解析可参考人工智能板块），该架构允许每个 token 对上下文中所有其他 token 进行关注，产生 n² 组配对关系。随着上下文长度增加，模型捕捉这些关系的能力逐渐下降，形成上下文大小与注意力集中度之间的天然矛盾。此外，模型从训练数据分布中形成注意力模式，短序列通常比长序列更常见，导致模型对长距离上下文依赖经验不足，相关专用参数较少。

诸如位置编码插值这类技术，通过让模型适应其最初训练的较小上下文来处理更长序列，但会带来位置信息理解质量下降。这些因素共同造成性能的梯度递减，而非陡然下降。因此，构建强大的 Agent 离不开周密的上下文工程。

有效上下文的剖析

考虑到 LLM 受限于有限的注意力预算，良好的上下文工程意味着找到一组尽可能精简且信号密度高的 token，以最大可能性达成预期结果。本文后续章节将阐述这一原则在不同上下文组成部分中的应用。

系统提示应当极其清晰，使用简单、直接的语言，以适合智能体理解的方式传达概念。需要避开两种常见失效模式的“黄金地带”：一种是在提示中硬编码复杂而脆弱的逻辑，试图精准控制 agent 行为，这会引入系统脆弱性并增加维护复杂度；另一种是提供模糊笼统的指引，既未给 LLM 明确信号，又错误预设共享上下文。最佳程度是既足够具体以引导行为，又足够灵活以提供强大的启发式方法。

校准系统提示词示意图，左侧为过于具体（Too specific）的硬编码 if-else 提示，中间为恰到好处（Just right）的结构化指导，右侧为过于模糊（Too vague）的描述，展示了三种提示质量等级

一方面看到脆弱的 if-else 硬编码提示，另一方面看到过于笼统或错误假设共享上下文的提示。

建议将提示组织成清晰的章节（如 <概述>、<工具指引>、<输出说明> 等），使用 XML 标签或 Markdown 标题来划分。无论采用哪种格式，都应追求用最少的信息清晰概括期望行为（“最少”不一定意味着短，仍需预先给予足够信息）。最佳实践先用最好的模型测试最小化提示，观察表现，然后基于失效模式逐步加入指令和示例。

工具允许 agent 与环境交互，并在工作过程中引入新上下文。工具定义了 agent 与其信息/行动空间的“契约”，因此设计要提升效率，返回高效信息并鼓励高效行为。在《为 AI Agent 设计工具——与 AI Agent 协同》（原文）中讨论了如何构建 LLM 完全理解且功能重叠最小的工具。工具应自包含、具备容错能力，对预期用途表述清晰。输入参数要描述明确，发挥模型固有优势。

常见失效模式是臃肿的工具集，要么覆盖过多功能，要么导致选择工具时出现模糊决策点。如果人类工程师都无法判断该用哪个工具，AI agent 也不行。精心策划最小可行工具集也有助于在长时间交互中维护和修剪上下文。

提供示例（少样本提示）是公认且仍强烈推荐的最佳实践。但团队常往提示里塞入大量极端情况来阐明规则，我们不推荐这种做法。应甄选一组多样化、具有代表性且能有效描绘预期行为的示例。对 LLM 而言，示例就是胜似千言万语的“图片”。

总体指导原则：要深思熟虑，保持上下文信息丰富的同时紧凑精炼。接下来探讨如何在运行时动态检索上下文。

上下文检索与 Agentic 自主搜索

在《构建高效的 AI Agent》（原文）中强调了基于 LLM 的工作流与 agent 的差异。我们逐渐倾向于简洁定义：agent 即 LLM 能在一个循环中自主使用各种工具。

与客户合作中，业界正向这一范式靠拢。模型能力增强，agent 的自主水平也随之提升：更聪明的模型使 agent 能独立驾驭微妙复杂问题并从错误中恢复。

如今，许多 AI 原生应用采用基于嵌入的预推理时间检索机制（embedding-based pre-inference time retrieval）为 agent 提供重要上下文。随着领域向更具 agentic 方式过渡，越来越多团队用“即时”（just in time）上下文策略增强这些检索系统。与预先处理所有数据不同，“即时”方法的 agent 维护轻量级标识符（文件路径、存储的查询、网页链接等），运行时通过工具动态加载数据到上下文中。Anthropic 的 agentic 编码解决方案 Claude Code 就采用此法：模型可编写目标查询、存储结果，并利用 Bash 命令如 head 和 tail 分析海量数据，无需将完整数据对象加载到上下文中。

这种方法类似人类认知：我们通常不记住整个资料库，而是引入外部组织和索引系统（文件系统、收件箱、书签等）按需检索。除了存储效率，这些引用的元数据还提供高效细化行为的机制。例如，在文件系统中运行的 agent，一个位于 tests 文件夹中名为 test_utils.py 的文件，其隐含用途与位于 src/core_logic/ 中的同名文件截然不同。文件夹层级、命名规范、时间戳都提供了重要信号。

让 agent 自主导航和检索数据，还实现了渐进式信息披露——允许 agent 通过探索增量式发现相关上下文。每次交互产生上下文指导下一步决策。Agent 能够层层递进构建理解，仅在工作记忆中保留必要内容，并利用笔记策略实现额外持久化。这种自我管理的上下文窗口能使 agent 专注于相关信息子集。

当然也需要权衡：运行时探索比检索预先计算的数据慢，需要精心设计确保 LLM 拥有合适的工具和启发式方法。缺乏适当引导时，agent 可能因误用工具或未能识别关键信息而浪费上下文。

某些场景下，最有效的 agent 采用混合策略：预先检索一部分数据保证速度，同时保留自主探索的主动权。例如 Claude Code 采用混合模型：CLAUDE.md 文件被直接放入前置上下文中，而 glob 和 grep 等基本工具允许它在环境中导航并即时检索文件，有效绕过索引过时和复杂语法树问题。对于法律或金融等动态程度低的语境，混合策略可能更适用。

随着模型能力提升，agentic 设计将朝着让智能模型自主行动的方向发展，逐步减少人工干预。鉴于该领域发展日新月异，“做最简单有效的方法”仍是我们给基于 Claude 构建 agent 的团队的最佳建议。

面向长周期任务的上下文工程

长周期任务要求 agent 在一系列动作中保持连贯性和目标导向行为，即使 token 超过上下文窗口。对于持续数十分钟乃至数小时的任务（如大规模代码迁移或综合研究），agent 需要专门技术克服上下文窗口限制。

等待更大的上下文窗口似乎是显眼策略，但在可预见的未来，无论窗口多大，都可能受上下文污染和信息相关性困扰——至少期望 agent 发挥最佳表现时如此。我们开发了几种直接应对上下文污染的技术：压缩、结构化笔记和 Multi-Agent 架构。

压缩

压缩是一种实践：当对话接近上下文窗口极限时，对其进行归纳总结，用总结内容重新创建上下文窗口。这是提升长程任务连贯性的主要手段。核心在于以高保真度提炼上下文，使 agent 能在性能损失最小的情况下继续工作。

例如在 Claude Code 中，通过将消息历史传递给模型，让其总结关键细节，保留架构决策、未解决 Bug 和实现细节，同时丢弃冗长的工具输出或消息。之后 agent 基于压缩后的上下文加最近访问的五个文件继续执行任务，用户获得工作连续体验而无需担心上下文窗口限制。

压缩的艺术在于选择保留什么、丢弃什么。过于激进的压缩可能导致微妙但关键的上下文丢失。建议先最大化召回率，确保压缩提示能捕捉所有相关信息，然后通过迭代优化去除冗余提高精确度。

一个安全且改动最小的压缩形式是清除工具调用结果，该特性已作为功能在 Claude 开发者平台上线。

结构化笔记

结构化笔记（agentic 记忆）是一种由 agent 定期将笔记持久化到上下文窗口之外的技术。这些笔记在后续时刻被重新拉入上下文窗口。该策略能以最小开销提供持久化记忆。

就像 Claude Code 创建待办事项列表，或者自定义 agent 维护 NOTES.md 文件一样，这个简单模式使 agent 能在复杂任务中追踪进度，保留关键上下文和依赖关系。Claude 玩《宝可梦》的例子（直播回放）展示了记忆如何提升 agent 能力：该 agent 在数千个游戏步骤中维持精确计数，追踪目标，绘制已探索区域地图，记住关键成就，保存战斗策略笔记。在上下文重置后，通过读取自己的笔记，就能继续长达数小时的训练序列。

作为 Sonnet 4.5 版本发布的一部分，Anthropic 在开发者平台以公测形式发布了一个记忆工具，通过基于文件的系统方便地在上下文窗口之外存储和查阅信息。

Sub-agent 架构

Sub-agent 架构是另一种绕过上下文限制的方法。由专门化的子 agent 在各自干净清晰的上下文窗口中处理特定任务，主 agent 基于高层计划协调，子 agent 执行深度技术工作或使用工具查找相关信息。每个子 agent 可能消耗数万 token，但最终只返回一份浓缩提炼的精简摘要（约 1000-2000 token）。这种方法实现了清晰的职责分离，在《我们如何构建 Multi-Agent 研究系统》中有详细讨论，复杂研究任务上显示了对单 agent 系统的显著性能提升。

选择哪种方法取决于任务特点：

压缩：保持对话流畅性，适用于需要大量来回交互的任务。
笔记：擅长具有明确里程碑的迭代式开发。
Multi-Agent 架构：适合复杂研究和分析，并行探索能带来丰厚回报。

即使模型不断进步，在更长时间交互中保持连贯性的挑战，仍是构建更高效 agent 的核心课题。

结语

上下文工程代表我们使用 LLM 构建方式的一种根本性转变。随着模型越来越强大，挑战不再是精心雕琢一个完美提示，而是要在每一步中精心甄选哪些信息能进入模型有限的注意力预算。无论你是在为长周期任务实施压缩、设计 token 高效的工具，还是赋能 agent 进行即时环境探索，根本指导原则始终不变：找到信号密度最高的最小 token 集合，以最大可能性达成理想结果。

本文概述的技术将随模型进步持续演化。更聪明的模型不再需要那么规范的工程设计，agent 能以更高自主性运行。但即便能力不断增强，将上下文视为宝贵且有限的资源，这一理念仍将是构建可靠、高效 agent 的核心。

立即在 Claude 开发者平台开始你的上下文工程实践，并通过记忆与上下文管理手册获取实用技巧和最佳实践。

致谢

本文由 Anthropic 应用 AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，并有团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 的贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。

扩展阅读：