AI 代理的有效上下文工程¶
- 原文链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents [61]
- 发布时间：2025-09-29
- 作者：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield
上下文不是越长越好，而是要用最小的高信号集合，最大化你想要的行为。[61]
上下文工程 vs. 提示词工程¶
在 Anthropic 看来，上下文工程是提示词工程的自然演进。提示词工程关注如何写和组织指令以获得最佳输出；上下文工程关注的是推理时“应当放进上下文的完整信息组合”。上下文包括系统指令、工具、MCP、外部数据、消息历史等所有可用信号。随着代理在多轮与长时间任务中运行，这些信号会持续增长，必须周期性地被筛选与整理。[61]
提示词工程侧重写好 prompt；上下文工程则是一种持续迭代：每一轮都要决定哪些信息进上下文、哪些留在外部，并确保系统处于“正确高度”的抽象层级。过度细化会让提示词变成脆弱的 if-else；过度抽象又会让模型缺乏明确指引。真正有效的上下文是在两者之间取得平衡。[61]
为什么上下文工程是核心问题¶
LLM 和人类一样，在上下文过长时会分心，信息召回能力下降。“草堆找针”类评测揭示了 context rot：上下文越长，模型越难准确回忆其中信息。即便不同模型退化曲线不同，这一问题普遍存在。[61]
上下文本质上是一种稀缺资源。随着 token 增加，模型注意力预算被消耗，n² 级别的注意力关系被拉薄，模型对长上下文的经验也更少。即便通过位置编码等方法提升长上下文能力，仍会出现性能梯度：模型在长上下文仍可工作，但检索与长程推理精度会下降。[61]
因此，真正可控的代理，需要把上下文当作“有限预算”，精心选择“最小但足够”的高信号集合。[61]
有效上下文的组成¶
系统指令¶
系统指令应清晰、直接，并位于合适抽象层级。过度细化会变成脆弱逻辑，过度抽象则缺少可执行约束。建议用结构化分段（如 <background_information>、<instructions>、## Tool guidance 等）清晰划分内容；但无论格式如何，核心目标是“最小充分信息”：只保留实现目标所必需的指令与示例。[61]
工具¶
工具定义了代理与环境的“合同”，因此必须高效、清晰、低歧义。工具返回要尽量“高信号、低 token”，参数命名应明确直观，功能边界不要重叠。工具集合过多或职责重叠，会让代理在选择时产生犹豫甚至错误。[61]
示例¶
少样本示例仍然有效，但不要把一堆边界条件塞进 prompt。应挑选少量“典型但多样”的示例，用最小示例集覆盖行为边界。对 LLM 来说，示例相当于“图像”，比冗长规则更容易被吸收。[61]
总体上，无论是系统指令、工具还是示例，都要追求“信息密度高、上下文紧凑”。接下来进入运行时的上下文检索。
上下文检索与代理式搜索¶
在《Building Effective AI Agents》中，我们将代理定义为“在循环中自主使用工具的 LLM”。在实践中，越来越多团队采用这种范式。随着模型能力提升，代理可以在更复杂的问题空间中自主探索与纠错。[61]
过去 AI 产品常用 embedding 检索在推理前“预取”上下文；而随着代理化趋势，越来越多系统转向“just in time”策略：保留轻量索引（路径、查询、链接等），需要时再用工具检索。这类似人类的外部记忆：不记住一切，而是保留索引并随用随取。[61]
这种方式还有额外好处：路径、文件夹结构、命名和时间戳等元数据能为代理提供隐含信号，帮助判断用途与优先级。逐步探索也让代理可以逐层构建理解，避免把大量无关内容塞入上下文。[61]
但代价是运行时探索更慢，也更依赖工具设计与导航策略。如果缺乏清晰指导，代理可能误用工具、走入死路、错过关键信息。许多场景下更好的策略是混合：先预取部分关键数据，剩余通过自主探索补充。[61]
长时间任务的上下文工程¶
长时间任务需要代理在跨多轮、跨上下文窗口的情况下保持一致性。等待更大上下文窗口并非万能：上下文污染与相关性问题仍然存在。Anthropic 总结了三类关键方法：[61]
1. 压缩（Compaction）¶
当上下文接近上限时，将对话压缩成摘要，并以摘要作为新上下文继续执行。重点在于保留架构决策、未解决问题、实现细节，删除冗余工具输出。最安全的“轻量压缩”是清理工具结果；压缩提示词需先最大化召回，再提高精度，避免丢失关键细节。[61]
2. 结构化笔记¶
让代理在上下文外写笔记（如 NOTES.md、任务清单），作为长期记忆。这样可以跨会话保持进度与依赖关系。Claude Plays Pokémon 的例子表明：结构化笔记能让代理保持多小时一致行为。[61]
Claude Developer Platform 还提供 memory 工具（beta），让代理通过文件系统保存与回读信息，用于持续项目状态与知识积累。[61]
3. 子代理架构¶
通过子代理分担深度探索任务：主代理保持高层计划与合成，子代理各自用干净上下文进行深入搜索，返回压缩结果。这种分工在复杂研究任务上显著优于单代理（参见《How we built our multi-agent research system》）。[61]
三者各有适用场景：压缩适合持续对话流；笔记适合有明确里程碑的迭代任务；多代理适合并行探索与研究型任务。[61]
结论¶
上下文工程改变了“做 AI”的重心：不再只是写好 prompt，而是每一步都精心策划进入上下文的高信号信息。无论是压缩、结构化记忆、工具设计，还是按需检索，核心目标一致——用最小的高信号集合，最大化代理行为的确定性与可靠性。[61]
随着模型变强，代理将获得更大自治权，但上下文仍是有限资源。把上下文当作预算管理，将始终是构建可靠代理的关键原则。[61]
致谢¶
本文由 Anthropic Applied AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield；贡献者包括 Rafi Ayub、Hannah Moran、Cal Rueb、Connor Jennings；特别感谢 Molly Vorwerck、Stuart Ritchie、Maggie Vo。[61]