题记与说明
标题：Effective context engineering for AI agents
作者：Anthropic Applied AI 团队（Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield，Rafi Ayub 等人贡献）
来源：https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
发布日期：2025-09-29（Anthropic 官网 Engineering 专栏）
存档日期：2026-11-01
标签：上下文工程 / AI Agent / 提示工程 / Agent 记忆 / 长程任务
一句话概括
Anthropic 给"上下文工程"正名的总纲之作：构建 agent 的重心，已从"怎么写提示词"升级为"在模型有限的注意力预算里，每一步放入什么 token"。
核心观点
- 上下文工程是提示工程的自然进化：不只管指令怎么写，而是持续策展推理时进入上下文的全部 token——系统提示、工具、消息历史、检索结果，即 "thinking in context"。
- 上下文是边际收益递减的有限资源：token 越多，模型精准召回信息的能力越弱（context rot）；Transformer 的注意力机制意味着 n 个 token 有 n² 个两两关系，每个新 token 都在消耗"注意力预算"。
- 好上下文 = 最小高信号 token 集：系统提示要写在"恰当海拔"（不过度硬编码、也不过于空泛）；工具要少而清晰——人类工程师都分不清该用哪个工具时，模型更分不清；示例胜过罗列规则。
- just-in-time 检索正在取代全量预载：agent 只持轻量标识符（文件路径、查询语句），运行时按需加载、渐进披露；Claude Code 的 CLAUDE.md 常驻 + grep/glob 即时检索是混合策略范例。
- 长程任务三板斧：compaction（对话临近上限时高保真压缩重启，先保召回再提精度）、结构化笔记 / agentic memory（NOTES.md 式外置记忆，Claude 打 Pokémon 靠它维持数千步的目标追踪）、子代理架构（子代理深挖数万 token，只回传 1,000–2,000 token 浓缩摘要）。
最值得记住的金句
- "好的上下文工程意味着找到最小的高信号 token 集，使期望结果出现的概率最大化。"
- "上下文必须被当作一种边际收益递减的有限资源来对待。"
- Agent 的新定义："LLMs autonomously using tools in a loop"——在循环中自主使用工具的 LLM。
对我的启发
- AI 编程工具："轻常驻 + 强检索"优于"全量塞入"；清除陈旧工具结果（tool result clearing）是最安全的压缩起点。
- Agent 系统：子代理"深挖数万 token、只回传千字摘要"的职责分离，是多代理系统设计的黄金法则。
- 个人知识管理：just-in-time 检索正是人脑的做法——我们不背下全部语料，而是靠文件系统、收件箱、书签这类索引按需取用。agent 的 NOTES.md 模式反过来也是个人笔记该有的样子：轻量、可索引、能被"未来的自己"续读。
- 写作：系统提示的"恰当海拔"同样适用于写作指令与文章结构——具体到足以引导，留白到足以灵活。
适合谁读
正在搭建 agent 工作流或 AI 编程助手的工程师，想理解 Claude Code、Cursor 类工具行为逻辑的重度用户，以及把 LLM 当长期协作者、需要管理"机器注意力"的知识工作者。这是该主题被引用最多的总纲，建议作为入口文献，再顺文中链接延伸阅读《How we built our multi-agent research system》等。