Anthropic 官方：压住 AI 成本的是上下文工程，不是提示词技巧

原作者：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield（Anthropic 应用 AI 团队） 原文链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

结论先行

Anthropic 工程团队给出的核心原则只有一句：好的上下文工程，是找到「最小的高信号 token 集合」，让目标结果出现的概率最大化。这不是修辞——它来自一个硬约束：随着上下文变长，模型准确召回信息的能力会持续下降（文中称之为 context rot），因为 Transformer 里 n 个 token 会产生 n² 个成对关系，注意力预算被摊薄，形成的是「性能梯度」而不是「硬悬崖」。

由此推出四类可落地手段：即时检索（只存轻量标识符，运行时按需加载）、压缩（接近上限时摘要重启）、结构化笔记（把状态写到上下文之外）、子 Agent 架构（探索数万 token，只回传 1,000–2,000 token 摘要）。

本站判断：这篇文章表面讲提示词写法，实质讲的是成本控制——你往上下文里塞的每一个 token 都要付钱，而它同时还在稀释模型注意力。对三维项目来说，「少给一点、给准一点」是同时省钱和提升正确率的少数双赢操作。

原文出处

作者：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield（Anthropic 应用 AI 团队） 原文：Effective context engineering for AI agents（Engineering at Anthropic） 发布：2025-09-29 链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

要点解读

1. 上下文工程是提示词工程的下一步

Anthropic 把两者区分得很清楚：

  • 提示词工程关注「怎么写指令」——尤其是系统提示的组织与措辞；
  • 上下文工程关注「每一步该让模型看到什么」——包括系统指令、工具定义、MCP、外部数据、消息历史在内的全部 token。

原文的表述是：与「写一个提示词」这种离散任务不同，上下文工程是迭代的，每次决定传什么给模型时，策展工作都在发生。

2. 为什么上下文是有限资源

三条机制支撑同一个结论：

  1. 上下文腐化：token 越多，模型从上下文中准确召回信息的能力越差。原文特别强调，这个特性在所有模型上都存在，只是退化速度不同。
  2. 注意力预算：模型解析大量上下文时要消耗注意力预算，每引入一个新 token 都会消耗一部分，所以「上下文必须被当作有限资源，边际收益递减」。
  3. 架构层面的原因：n 个 token 产生 n² 个成对关系；训练数据里短序列比长序列常见，模型对长距离依赖的经验更少；位置编码插值虽然能扩展窗口，但会带来位置理解的退化。

本站判断：这解释了一个常见困惑——为什么把整个场景文件、模型清单、材质说明一次性喂给 AI，结果反而更差、还更贵。不是模型不行，是注意力被摊薄了。

3. 有效上下文的三个组成部分

系统提示：找「恰当的高度」。 原文称之为 Goldilocks 区间——一端是硬编码的复杂 if-else 逻辑，脆弱且难维护；另一端是过于笼统的高层指导，或错误假设了共享上下文。建议组织成多个清晰章节（<background_information>、<instructions>、## Tool guidance、## Output description），用 XML 标签或 Markdown 标题分隔。

工具：自包含、抗错误、用途极其明确。 最常见的失败模式是工具集臃肿——覆盖功能太多，或让模型在多个工具间难以抉择。原文的判断标准很直接：如果人类工程师都无法确定某个场景该用哪个工具，就不要指望 AI 能做得更好。

示例：少而精。 不建议堆砌大量边缘案例，而是策展一组多样化、典范性的示例。原文的说法是：对 LLM 来说，示例就是「一图胜千言」的那张图。

4. 手段一：即时检索（just-in-time）

思路是不预先加载所有相关数据，而是让 Agent 维护轻量标识符（文件路径、存储的查询、网页链接），运行时用工具动态加载。

文中给的实例是 Claude Code：它可以写定向查询、把结果存起来，用 Bash 的 head 和 tail 分析海量数据，不需要把完整数据对象加载进上下文。

几个值得记的细节：

  • 元数据本身就是信号：文件夹层级、命名约定、时间戳都有信息量。tests/test_utils.py 和 src/core_logic/test_utils.py 的用途显然不同。
  • 渐进式披露：Agent 通过探索逐步发现上下文——文件大小暗示复杂度，命名暗示用途，时间戳可以当作相关性的代理。
  • 权衡：运行时探索比预计算检索更慢，且需要精心设计的工具与启发式规则。
  • 混合策略：Claude Code 用的是混合模型——CLAUDE.md 预先放进上下文，同时用 glob、grep 这类原语即时导航环境，从而绕开陈旧索引和复杂语法树的问题。

5. 手段二：压缩（compaction）

定义是：当对话接近上下文上限时，摘要内容并用摘要重启一个新的上下文窗口。

Claude Code 的实现保留了架构决策、未解决的 bug、实现细节，丢弃冗余的工具输出，然后带着「压缩后的上下文 + 最近访问的 5 个文件」继续工作。

两个关键提醒：

  • 过度激进的压缩会丢失微妙但关键的上下文——有些信息只有在后面才发现重要；
  • 调优顺序是先最大化召回，再迭代提升精度，逐步剔除多余内容。最简单的一种压缩形式就是清理工具调用与结果（tool result clearing）。

6. 手段三：结构化笔记（Agentic Memory）

Agent 定期把笔记写到上下文窗口之外的存储中，需要时再拉回来。Claude Code 用它维护 to-do 列表，自定义 Agent 则维护 NOTES.md。

文中给了一个很有说服力的例子——Claude 玩 Pokémon 时，能跨越数千游戏步维持精确计数、绘制探索区域地图、记录战斗策略：

「过去 1,234 步我一直在 1 号道路训练宝可梦，皮卡丘已经升了 8 级，目标是 10 级。」

随 Sonnet 4.5 发布，Anthropic 在 Claude Developer Platform 上公开 beta 发布了 memory tool。

7. 手段四：子 Agent 架构

专门的子 Agent 用干净的上下文窗口处理聚焦任务：主 Agent 负责高层规划与结果综合，子 Agent 做深度技术工作或信息检索。

关键数字：子 Agent 可能探索数万 token，但只回传一个 1,000–2,000 token 的浓缩摘要。原文称这在复杂研究任务上相比单 Agent 系统有显著提升。

本站判断：这是四条里最省钱的一条。它把「上下文成本」从线性增长变成了常数回传——探索得再深，主 Agent 只吃那一两千 token。三维项目里「摸清一个陌生场景文件的结构」正是这类任务。

8. 三种手段怎么选

原文给的判断标准：

场景推荐手段
需要大量来回交互的任务压缩（保持对话连续性）
有清晰里程碑的迭代开发结构化笔记
需要并行探索的复杂研究与分析多 Agent 架构

代码与验证

文章没有给完整代码，但给了两个可直接落地的检查点：

  1. 工具集体检：把当前工具列表摊开，逐个问「人类工程师能否明确说出这个场景该用哪个工具」。说不清的就是要合并或删除的。
  2. 压缩效果验证：观察压缩后的会话是否还需要回头重新查已经查过的信息——如果需要，说明摘要漏掉了状态，属于典型的「压缩反效果」。

原文附了官方的 memory and context management cookbook，可以跟着跑一遍。

适用场景与坑

该用：长时运行的 Agent、大仓库、需要跨多轮保持状态的开发任务。三维项目几乎全部符合——文件大、状态多、迭代周期长。

别用：单轮问答或短任务不需要这套工程，引入压缩和子 Agent 反而增加复杂度和延迟。

已知的坑：

  • 即时检索比预计算慢，工具和启发式规则设计不到位会得不偿失；
  • 压缩过于激进会丢掉「事后才显得重要」的细节，建议从最大化召回开始调；
  • 工具集臃肿是最常见的失败模式，比工具太少更麻烦；
  • 位置编码插值扩展窗口会带来位置理解退化，长窗口不等于长上下文可用；
  • 上下文的退化是性能梯度而非硬悬崖，意味着它不会报错，只会悄悄变差——这让问题更难被发现。