夜雨聆风导读：AI Agent 的能力瓶颈不在模型智商，而在上下文管理。Anthropic 工程团队把多年构建 Claude Code 的实战经验提炼为一套上下文工程方法论。读完你会知道：为什么塞进去的信息越多效果越差，以及怎样用最少的 token 让 Agent 持续做对事。
为什么 Prompt Engineering 已经不够用了
2025 年 9 月，Anthropic 工程博客发表了 Effective context engineering for AI agents，正式把一个新概念推到台面上：Context Engineering（上下文工程）。
原文地址
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
写这篇的是 Anthropic 应用工程团队，他们的日常工作就是构建 Claude Code 这类长时间自主运行的 Agent 产品。他们每天面对的问题不是怎么写一个好 prompt，而是 Agent 跑了 20 轮之后为什么开始犯蠢。
Andrej Karpathy 在同期也表达了类似观点：现在做 AI 产品的核心工作已经不是找到那个魔法提示词，而是回答一个更大的问题，什么样的上下文配置最有可能激发模型的目标行为。
这就是 Context Engineering 和 Prompt Engineering 的核心差异。Prompt Engineering 关注怎么写指令，Context Engineering 关注每次推理时模型的上下文窗口里应该放什么。当你只做一轮对话时，两者没什么差别。但当你构建一个循环执行的 Agent，每一轮都会产生新数据，都需要决定哪些保留、哪些丢弃、哪些压缩，Prompt Engineering 就不够用了。
上下文是一种有限资源，而且边际收益递减
Anthropic 团队提出了一个非常直觉的说法：LLM 有一个注意力预算，每多塞一个 token 进去，这个预算就多消耗一点。
这不是比喻，是 Transformer 架构的数学现实。模型中每个 token 都要与其他所有 token 做注意力计算，n 个 token 就有 n² 组关系需要维护。当 n 增大，模型对每一对关系的处理精度就会被稀释。研究者把这种现象称为 context rot（上下文腐烂）：随着 token 数量增加，模型从上下文中准确回忆信息的能力会下降。
虽然不同模型的衰减曲线不同，但趋势是一致的。上下文不是越大越好的容器，它是一种边际收益递减的稀缺资源。
这跟人类的工作记忆限制惊人地相似。心理学研究表明，人类的工作记忆容量大约是 4±1 个组块。我们不会试图把一整本书装进脑子里再做决策，而是建立外部索引系统，在需要时检索。好的 Agent 设计应该模仿这个策略。
好的上下文是什么样的
Anthropic 给出了一条极简原则：找到能最大化目标结果的最小高信号 token 集合。
说起来容易。落地时需要把上下文拆成几个组件分别优化。
系统提示的高度问题。Anthropic 观察到两种常见失败模式：一种是在 prompt 里硬编码大量 if-else 逻辑试图覆盖所有边界情况，结果导致系统极其脆弱且难以维护；另一种是给出模糊的高层指导（比如"做好这件事"），假设模型能自动理解所有暗含的上下文。好的系统提示在两者之间找到平衡点：足够具体以引导行为，足够灵活以提供启发式判断的空间。
工具集的精简原则。最常见的问题是工具太多、功能重叠。Anthropic 的判断标准很务实：如果一个人类工程师无法明确判断在某个场景下应该用哪个工具，那 AI Agent 同样做不到。工具应该像良好代码库中的函数一样：自包含、健壮、用途清晰。
少量范例比大量规则更有效。很多人倾向于在 prompt 里堆砌大量边界情况的规则，试图覆盖所有可能。Anthropic 建议反过来做：用精选的、多样化的典型例子来展示期望行为。对模型来说，例子就是一图胜千言。
即时检索比预加载更聪明
传统做法是在推理前用 embedding 把可能相关的信息全部检索出来塞进上下文。Anthropic 团队发现另一个策略越来越有效：just-in-time context（即时上下文加载）。
具体来说，不预先加载大块数据，而是让 Agent 持有一组轻量级的标识符，比如文件路径、存储查询、网页链接。运行时，Agent 通过工具按需加载具体内容。
Claude Code 就是这个策略的典型实践。它在处理大型数据库分析时，不会把整个数据库加载进上下文，而是用 SQL 查询获取目标数据，用 head 和 tail 命令检查大文件的片段，逐步组装出完成任务所需的信息。
这种方式的好处不止是节省 token。文件系统中的元数据本身就包含信号：一个叫 test_utils.py 的文件放在 tests/ 目录和放在 src/core_logic/ 目录，对 Agent 的含义完全不同。命名规范、目录层级、文件时间戳都在为 Agent 提供导航线索，帮它判断什么值得深入查看。
Anthropic 把这个过程称为 progressive disclosure（渐进式披露）：Agent 通过探索逐步发现相关上下文，每次交互的结果为下一步决策提供信号。它只在工作记忆中保留当前必要的子集，避免被海量但可能不相关的信息淹没。
当然有个权衡：运行时探索比预计算检索慢。Claude Code 用了一种混合策略，CLAUDE.md 文件在启动时直接加载（相当于预计算索引），而 glob 和 grep 等工具让它在运行时按需检索文件内容。这样既有启动速度，又避免了静态索引过时的问题。
记忆管理：Agent 的核心能力
当 Agent 执行多步骤任务时，对话历史会迅速膨胀。Anthropic 介绍了几种管理策略。
上下文裁剪是最基础的一种。就是在 token 接近上限时，主动截断或压缩历史消息。Claude Code 的做法是保留系统提示和最近的交互，压缩中间部分。但裁剪的风险在于可能丢掉后面还会用到的关键信息。
更优雅的方式是 summarization（摘要化）。与其简单截断旧信息，不如让模型把早期对话压缩成结构化摘要。比如把一段完整的调试过程压缩为一条结论：已修复 auth 模块第 47 行的类型错误。关键决策和发现被保留，中间的探索过程被丢弃。
Anthropic 还提到一种更激进的架构：分层记忆系统。类似人类的短期记忆和长期记忆分离，Agent 可以维护一个持久化的 scratchpad（便签本），把跨任务有价值的信息写入长期存储，而只在当前上下文中保留临时工作状态。
Claude Code 的实际架构就体现了这个分层思想：CLAUDE.md 是长期记忆（项目规范和偏好），文件系统是外部存储（可按需检索），对话上下文是工作记忆（当前任务状态）。
什么时候不需要上下文工程
如果你的应用场景是单轮对话（用户提问→模型回答→结束），上下文工程的大部分技巧都用不上。这时候 Prompt Engineering 就够了。
如果你的 Agent 只执行 2-3 步的简单流程，上下文膨胀不会成为问题。直接把相关信息塞进去就行，不需要复杂的检索和压缩机制。
上下文工程真正重要的场景是：Agent 需要长时间自主运行、处理复杂任务、在执行过程中不断产生新信息并需要决策哪些保留。当你的 Agent 开始忘事或者犯迷糊的时候，就是上下文工程该介入的时候。
我从这套方法里提炼的三条操作原则
先做减法再做加法。拿到一个 Agent 的性能问题时，第一反应不应该是要不要加更多信息，而是上下文里有没有噪音在干扰模型。实操中我发现删掉 30% 的系统 prompt 内容，Agent 表现反而更好。
工具就是上下文的入口。工具不只是让 Agent 能做事，它决定了 Agent 能获取什么信息。设计工具时应该同时考虑它的信息检索价值，不只是它的执行功能。
摘要比截断便宜。token 接近上限时，很多框架默认的策略是丢弃最早的消息。但在长任务中，早期的决策和发现可能是后续步骤的关键前提。花 200 token 做一次摘要，可能比丢掉 2000 token 的历史信息划算得多。
上下文工程不玄乎，本质就是在有限的注意力空间里做信息调度。模型越强，对信息调度的需求反而越高，因为你会想让它做更复杂、更长链条的事情。