Anthropic 上下文工程

概述

Anthropic 发布了两篇关于上下文工程（Context Engineering）的重要文章：一篇详细介绍其多智能体研究系统，另一篇则全面阐述如何为 AI 智能体实现高效的上下文工程。两篇文章共同覆盖了生产环境中上下文管理的架构模式，以及为何必须将上下文视为有限且宝贵资源的底层原则。

智能体 AI 的高效上下文工程

来源：Anthropic Engineering Blog

上下文即有限注意力预算

Anthropic 将上下文工程定位为提示词工程的自然演进。随着智能体从单轮任务迈向多轮、长时序工作，核心挑战也从"如何写好提示词"转变为"在每个步骤中，怎样的上下文配置最能产生期望行为"。

核心约束：LLM 拥有有限的注意力预算（Token 预算）。Transformer 架构对 n 个 Token 构建 n² 对的关联关系。随着上下文增长，模型捕捉这些关联的能力逐渐被稀释。这形成了一个性能渐变梯度——而非骤降的悬崖——模型在更长上下文下仍具备一定能力，但在信息检索和长程推理方面精度下降。

核心原则：找到尽可能小的高信噪比 Token 集合，使期望结果出现的概率最大化。

系统提示词设计

追求"金发姑娘区间"（Goldilocks zone）：介于僵硬的硬编码逻辑与模糊的高层指引之间。
使用 XML 标签或 Markdown 标题将提示词组织为独立章节（如 <background_information>、<instructions>、## Tool guidance 等）。
从最优可用模型的最简提示词出发，再根据观察到的失败模式补充指令——而非提前预设。
样例（few-shot）的价值远超边界情况规则的长篇列举。应筛选一组多样且规范的样例，而非试图穷举所有情形。

工具设计

工具应自包含、具备错误容错性，且预期用途无歧义。
最常见的失败模式之一：功能重叠的工具集过于臃肿。如果人类工程师在特定场景下也无法明确判断应使用哪个工具，则不能期望 AI 智能体做得更好。
精简到最小可行工具集，同时也简化了长交互中上下文剪枝的难度。

即时上下文检索

智能体不预先加载所有相关数据，而是维护轻量级标识符（文件路径、URL、存储查询），在运行时通过工具动态加载数据。Claude Code 正是这一模式的典型实现：CLAUDE.md 文件在启动时预加载，而 glob 和 grep 则支持即时文件检索。

即时加载的优势： - 避免索引过时 - 支持渐进式信息披露——智能体通过探索发现相关上下文 - 元数据（文件名、目录结构、时间戳）提供了关于相关性和用途的隐式信号

长时序上下文技术

压缩（Compaction）：当对话接近上下文窗口上限时，将内容汇总并以摘要重新发起。Claude Code 的实现方式是将消息历史传递给模型进行汇总，保留架构决策、未解决的缺陷和实现细节，同时丢弃冗余的工具输出。智能体以压缩后的上下文加上最近访问的五个文件继续运行。

压缩调优：先最大化召回率（保留所有相关内容），再迭代提升精确率（剔除多余内容）。工具结果清除（Tool result clearing）——在处理完原始工具输出后将其删除——是最轻量的压缩形式，现已作为功能在 Claude 开发者平台上线。

结构化笔记：智能体定期将笔记写入上下文窗口之外的记忆中，并在后续轮次检索。Claude Code 的待办清单模式就是一例。那个玩宝可梦的 Claude 智能体利用这一模式在数千个游戏步骤中精确记录——跨越上下文重置，持续追踪目标、已探索区域和战斗策略。

子智能体架构：专门化子智能体以干净的上下文窗口处理聚焦任务。每个子智能体可能消耗数万 Token，但只向主智能体返回精简摘要（通常为 1,000–2,000 Token）。这实现了关注点分离：详细的搜索上下文留在各子智能体内部，主智能体专注于综合归纳。

Anthropic 如何构建多智能体研究系统

来源：Anthropic Engineering Blog

架构

Research 功能采用编排者-工作者（Orchestrator-Worker）模式： - LeadResearcher 智能体分析查询、制定策略并派生子智能体。 - 子智能体并行运行，各自拥有独立上下文窗口，分别探索查询的不同方面。 - CitationAgent 对发现结果进行后处理，识别并标注来源。

LeadResearcher 首先将计划保存至记忆（外部存储），因为超过 200K Token 的上下文会被截断，计划必须能够持久保存。

为何多智能体适合研究任务

Token 使用量解释了 BrowseComp 评测中 80% 的性能差异。多智能体架构能有效扩展超出单智能体限制的任务所需 Token 量。以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在内部研究评测中比单智能体 Claude Opus 4 表现提升了 90.2%。

权衡：多智能体系统消耗的 Token 约为普通对话交互的 15 倍。该模式仅对高价值任务在经济上可行。

研究系统中的上下文管理

子智能体输出至文件系统：子智能体将输出写入外部系统，并将轻量级引用返回给协调者。这避免了多阶段处理中的信息丢失，同时减少了通过对话历史复制大量输出所带来的 Token 开销。
长时序对话管理：当上下文即将触达限制时，智能体派生拥有干净上下文的新子智能体，通过细致的交接维持连续性。智能体从记忆中检索已存储的上下文（如研究计划），而非在上下文限制处丢失它。
扩展思考作为草稿空间：主智能体使用扩展思考（Extended thinking）规划其方案——评估工具、判断查询复杂度、定义子智能体职责。子智能体在工具调用结果返回后使用交错思考（Interleaved thinking）评估质量并优化下一步查询。

提示词工程经验

原则	详情
像智能体一样思考	在 Console 中用精确的提示词和工具构建仿真；观察智能体逐步运作，以揭示失败模式
教会编排者学会委派	每个子智能体需明确：目标、输出格式、工具/来源指引、清晰的任务边界
按查询复杂度匹配投入	嵌入扩展规则：简单事实用 1 个智能体 + 3–10 次工具调用；复杂研究用 10+ 个子智能体
工具设计至关重要	工具描述不当会将智能体引入歧途；每个工具需有独特用途和清晰描述
让智能体自我改进	Claude 4 系列模型能诊断提示词缺陷并提出改进建议；一个工具测试智能体重写了 MCP 工具描述，使任务完成时间减少 40%
先广后窄	提示智能体从短而宽泛的查询开始，再逐步缩小焦点
并行工具调用	引入并行子智能体和并行工具调用，使复杂查询的研究时间最多缩短 90%

生产工程

彩虹部署（Rainbow deployments）：在保持新旧版本同时运行的前提下，逐步将流量从旧版本迁移至新版本，避免中断正在运行中的智能体。
持久化执行（Durable execution）：智能体在大量工具调用中维持状态；错误必须可恢复，无需从头重启。重试逻辑与定期检查点配合使用，同时辅以模型层面的优雅降级。
可观测性（Observability）：完整的生产链路追踪，用于诊断智能体失败原因。在不监控具体对话内容的前提下，对智能体决策模式进行高层次监控。

上下文管理 API 原语（Cookbook）

来源：Tool Use Context Engineering Cookbook — Anthropic

这本 Cookbook 提供了三种第一方 API 原语的详细实证演练，用于管理长时运行智能体中的上下文。测试用例是一个生物学研究智能体，需跨两个会话读取 8 份约 40K Token 的文档（共约 328K Token）——这一工作负载自然会触发所有三类上下文问题。

三种原语

原语	API 标识符	Beta 请求头	触发条件	解决问题
压缩（Compaction）	`compact_20260112`	`compact-2026-01-12`	Token 阈值（最低 50K，默认 150K）	所有会话内上下文增长
工具结果清除	`clear_tool_uses_20250919`	`context-management-2025-06-27`	Token 阈值（默认 100K）	专门针对工具结果膨胀
记忆工具	`memory_20250818`	无（独立使用）	模型驱动的工具调用	跨会话持久化

三种原语针对上下文问题的不同切面，相互组合而非相互竞争。清除和压缩管理当前窗口内的内容；记忆将信息移出窗口，使其在会话间得以留存。

基线：不使用上下文管理时的情况

不做任何上下文管理时，研究智能体的上下文在 5 轮后增至 335,279 Token。运行结束时的分布如下：

文件读取结果：约 322,946 Token（占比 96.3%）
工具调用记录：约 6,287 Token（占比 1.9%）
智能体推理文本：约 5,660 Token（占比 1.7%）
用户/任务提示词：约 357 Token（占比 0.1%）

在 200K Token 限制的模型上，同一运行会在任务中途遭遇硬性中止。在 1M Token 模型上，运行可以完成，但上下文腐化（Context rot）会降低对早期文档的召回能力——第一个读取的文件虽然技术上仍存在于上下文中，却被后续数十万 Token 的内容所掩埋。

压缩（Compaction）

压缩将接近上下文窗口上限的对话进行内容汇总，再以该摘要重新发起。这是一个全量转录操作：用户消息、助手消息、工具调用、工具结果以及之前的压缩块，全部被展平合并进摘要。

在 Cookbook 的研究智能体运行中（触发阈值设为 180K），压缩在第 4 轮触发一次，将前几轮替换为约 2,783 Token 的摘要。峰值上下文从基线的 335,279 降至 169,164。

压缩后保留与丢失的内容对比： - 与任务核心相关的高层事实（寿命数据、生物体身份、主要对比）：通常保留 - 晦涩细节（附录表格单元格、异质性统计、精确措辞）：通常丢失

这与清除有本质区别：清除直接丢弃工具结果，内容在重新获取前消失无踪；而压缩以压缩形式保留实质内容，但失去逐字细节。

有效实施压缩：instructions 参数会完全替换默认汇总提示词（而非补充）。默认提示词为：

"You have written a partial transcript for the initial task above. Please write a summary of the transcript. The purpose of this summary is to provide continuity so you can continue to make progress towards solving the task in a future context... You must wrap your summary in a <summary></summary> block."

对于研究智能体，自定义指令可以是："汇总此研究智能体的转录内容。保留每一个定量寿命数据和效应量及其来源生物体，并标注哪些文档已读、哪些尚未读取。"

何时跳过压缩：若会话自然地在上下文上限之内，压缩只带来信息损耗而无收益。若上下文膨胀主要来自可重新获取的工具输出，清除更廉价且无损。

工具结果清除（Tool-Result Clearing）

清除是子转录操作：它遍历消息列表，将 tool_result 内容块精确替换为简短占位符，其余内容（用户消息、助手推理、tool_use 记录）保持不变。模型保留了调用记录及其输入，但庞大的响应体消失了。

在 Cookbook 的运行中（触发阈值 30K，keep=4），清除触发 4 次，每次释放约 163K Token。峰值上下文：173,137，而基线为 335,279。此操作无推理成本——纯属对消息列表的机械编辑。

清除的代价：除最近 keep 个以外的所有文件读取内容均从上下文中消失。若智能体再次需要该内容，必须重新调用工具。代价大小取决于工具类型：重新读取本地文件几乎免费；重新调用受速率限制或响应缓慢的 API 则代价不菲。

有效实施清除：与压缩和记忆不同，清除没有提示词可调优。关键参数： - trigger：清除触发的 Token 阈值 - keep：保留最近工具结果的数量（默认 3） - clear_at_least：每次触发的最低清除 Token 量（对于缓存失效经济性至关重要——清除会使缓存提示词前缀失效，因此需清除足够多以使缓存写入成本物有所值） - exclude_tools：豁免清除的工具名称列表（与记忆工具组合使用时至关重要——详见下文）

何时跳过清除：若智能体确实需要完整查看历史工具结果（如跨文档对比中需要并排可见多段文字），清除会迫使冗余的重复读取。

记忆工具（Memory Tool）

记忆工具通过持久化文件目录，使模型能够跨对话存储和检索信息。模型在工具调用循环中自主决定保存什么、何时保存。一条自动注入的系统提示词建立了"先检查记忆"的协议："ALWAYS VIEW YOUR MEMORY DIRECTORY BEFORE DOING ANYTHING ELSE... Your context window might be reset at any moment."

该工具为客户端实现：API 提供协议和工具 schema，应用负责实现文件后端。工具支持六种操作：view、create、str_replace、insert、delete、rename。

Cookbook 两会话对比： - 无记忆的第二次会话：8 次文件读取，峰值上下文 333,977 Token（需从头重新发现一切） - 有记忆的第二次会话：4 次文件读取，峰值上下文 172,623 Token（读取第一次会话保存的笔记，跳过对 4 份文档的重复读取）

有效实施记忆： - 主题指引：在系统提示词中加入"仅将与 <topic> 相关的信息写入记忆系统"，引导保存内容方向。 - 组织管理：加入"编辑记忆文件夹时，始终保持内容最新、连贯且有组织……非必要不创建新文件"，防止积累内容重叠的笔记。 - 初始化会话：对于多会话任务，在正式工作开始前运行一个专门的首次会话，建立记忆资产（进度日志、功能清单、参考资料）。 - 存储卫生：追踪文件大小防止无限制增长；防范路径穿越攻击（../../etc/passwd）；考虑清除长期未访问的文件。

何时跳过记忆：若每次会话应从头开始（例如每次对话相互独立的面向用户聊天机器人），记忆会引入不希望存在的跨会话状态。

三者组合使用

Claude Code 在生产中综合运用了多种策略：压缩用于长对话，以及两套互补的记忆系统——CLAUDE.md 文件（用户编写，纳入源码管理）和自动记忆（模型自动写入的学习成果与规律）。

将清除与记忆工具组合使用时，应设置 exclude_tools: ["memory"]，防止智能体的记忆读写操作被清除。若不设置，智能体可能丢失对刚刚保存内容的追踪。

在 Cookbook 的三者组合运行中（触发阈值设于第一批次之上，使三者在同一会话内均被激活）： - 峰值上下文：169,938 Token（基线为 335,279） - 最终上下文：13,749 Token（基线为 335,279） - 清除触发 9 次；压缩触发 1 次；记忆写入 3 个文件

工作负载与原语的映射

工作负载特征	优先尝试	需留意
会话跨天或跨周	记忆工具	工具调用开销；若事实变更记忆可能过时
智能体应跨会话学习用户偏好	记忆工具	个人信息/敏感数据政策；偏好过时
大量可重新获取的工具结果	清除	智能体重复读取刚被清除的内容；调优 `keep` 和 `trigger`
对话为主要上下文	压缩	具体数据在汇总时被概括掉
工具结果不易重新获取（临时 API、上传内容）	压缩优于清除	对这些特定结果的摘要保真度
每次会话应从头开始	跳过记忆	不希望出现的跨会话状态
会话自然处于窗口上限之内	跳过压缩	不必要的信息损耗

关于更大上下文窗口

Claude Sonnet 4.6 和 Opus 4.6 提供 1M Token 的上下文，硬性限制已离得很远——但上下文腐化和预填充延迟随窗口内实际内容量而扩展，而非随窗口上限扩展。基线的上下文分布显示，96.3% 的 Token 是陈旧的文件读取结果。即便硬性上限尚远，保持精简的工作集仍然值得。