过去，我们普遍认为写好 Prompt 就能让 AI 变得更聪明，但 Anthropic 的最新研究揭示了另一个关键：AI 的未来真正取决于“上下文工程”——它决定了 AI 能否在复杂任务中保持逻辑清晰、高效执行。接下来，我们将用最简单易懂的方式，一步步拆解这个新概念的核心要点。
1. 从 Prompt Engineering 到 Context Engineering 的范式转变
过去，我们专注于学习如何编写 Prompt，运用各种技巧让 AI 准确理解指令，就像在学一门外语时努力表达清楚。但如今，AI Agent 需要处理的任务越来越复杂——不再是简单的一问一答，而是需要像人类一样结合上下文、进行多步骤推理与行动。
这时，只优化 Prompt 就像只教员工“好好听话”，却不给他工作所需的资料和背景信息。即使他听得再明白，也很难高效完成任务。“上下文工程”正是为了解决这个问题——它研究在 AI 执行任务的每一步，应该提供哪些最关键、最有效的信息。这些信息构成了 AI 的“工作记忆”。
可以看到，Prompt 只是输入的一部分，而上下文则包含系统指令、工具、MCP、外部数据、历史对话等，是 AI 当前所能感知到的全部信息。管理好这些内容，才是让 AI 变得更聪明的核心。
小提示：下次写 Prompt 时，先问自己：“我需要哪些背景信息能让 AI 更容易理解任务？” 而不是只纠结于措辞表达。
2. AI 注意力机制与“上下文腐烂”现象
你可能会问：信息越多越好吗？我把所有资料都塞给 AI 不就行了？事实上恰好相反。研究发现，当 AI 的上下文窗口（Context Window）中信息量持续增加时，它的表现反而会下降。这个现象被称为“上下文腐烂 (Context Rot)”。
这和我们人类的情况很相似：想象你正在处理一个重大项目，如果有人不断在你耳边唠叨无关紧要的事情，你的注意力会被分散，效率大幅降低。AI 同样有“注意力预算 (Attention Budget)”——每一个进入上下文的信息都会消耗它的注意力资源。信息过载时，AI 就会像我们一样出现“脑雾”，抓不住重点，甚至遗忘最初的目标。
因此，上下文工程的核心原则就是：用最少、最高效的信息，让 AI 做出最正确的决策。
常见问题：怎么判断上下文窗口是否过载？
答：观察 AI 是否开始重复回答、忘记之前的指令、或者输出逻辑混乱。许多 AI 平台会显示当前使用的 token 数量，当接近上限时就需要精简上下文了。
3. Anthropic 提出的三条高效上下文构建黄金法则
3.1 系统提示 (System Prompts)
系统提示是给 AI 设定规则的地方。写作时要像一位好领导：目标明确，指令清晰，同时也给员工留出自主发挥的空间。
- 太死板不行：如果你用一堆 if-else 逻辑把 AI 的每一步都写死，它就会变得很脆弱，遇到一点新情况就容易“死机”。
- 太模糊也不行：如果你只给一个“要智能一点”这样模糊的指令，AI 根本不知道具体该做什么。
最好的方式是，用清晰的语言（比如 Markdown 标题或 XML 标签）把指令分成不同模块。例如：
（背景信息）
（操作指令）
## 输出格式这样 AI 就能一目了然地理解结构。
常见问题：系统提示里要不要放入示例？
答：可以放少量示例，但不要把示例堆满。专门的“少样本提示”模块更适合。系统提示主要用于定义规则和背景，而非教学。
3.2 工具 (Tools)
我们给 AI 提供的工具，本质上是一种全新的软件。它不再是传统代码中输入 A 就必须输出 B 的模式，而是确定性系统（你的代码）和不确定性智能体（AI）之间的一份合约。这份合约写得好不好，直接决定了 AI 的办事效率。Anthropic 发现，最让 AI “头大”的工具通常有以下几个问题：
- 命名模糊，让人猜谜：比如参数叫
user，连人都得猜是指用户 ID、用户名还是邮箱地址。好的参数应该叫user_id或user_email，清晰明确。 - 功能重叠，选择困难：同时给了
search_jira和find_issue_in_jira，AI 可能当场“死机”。最好使用命名空间，比如jira.search_issue和asana.search_task，让 AI 清晰知道不同工具的服务边界。 - 返回一堆“天书”：工具执行完返回一堆计算机才看得懂的
uuid或内部 ID，浪费注意力预算。好的工具应返回人类可读的name，并提供 “简洁模式 (concise)” 和 “详细模式 (detailed)” 选项，让 AI 只在需要时才去获取技术细节。
简单来说，设计工具的原则和管理上下文一样：用最清晰、最高效的方式，给 AI 提供决策所需的最少信息。
小提示：在定义工具参数时，尽量使用有意义的英文名称（如
user_email），并在描述里写明预期格式，比如“格式如 xxx@example.com”。
3.3 少样本提示 (Few-shot)
使用示例来教 AI 是一个好方法，但很多人容易犯错——恨不得把所有极端情况都写成例子塞给 AI。Anthropic 指出，这样做反而会适得其反。
正确的做法是，精心挑选几个多样化、有代表性的经典案例。对 AI 来说，一个好的例子就像一张胜过千言万语的图片，能帮助它迅速领悟我们期望的行为模式。
常见问题：少样本提示应该放多少个示例合适？
答：通常 3-5 个高质量示例就足够。如果任务特别复杂，可以增加到 7-10 个，但不要超过 10 个，否则会稀释注意力。关键是要保证示例覆盖不同场景，而不是重复雷同。
4. 三种更高级玩法：应对超长任务
对于那些需要几个小时甚至更长时间的超长任务（比如迁移大型代码库），AI 的上下文窗口显然不够用。怎么办？Anthropic 提出了三种更高级的玩法：
- 压缩 (Compaction)：当对话快要超出限制时，让 AI 自己把前面的聊天记录做个总结，提炼出关键信息，然后带着这个“会议纪要”开始新的对话。
- 结构化笔记 (Structured Note-taking)：让 AI 学会自己记笔记。比如在做一个复杂项目时，它可以随时把重要发现、待办事项写在一个外部的
NOTES.md文件里。需要的时候再拿出来看，这样就不会忘记关键信息。 - 子智能体架构 (Sub-agent Architectures)：把一个大任务分包给几个“专家”AI，比如一个“资料搜集员”、一个“代码分析师”、一个“报告撰写员”。主 AI 负责统筹，各个子 AI 专注于自己的领域，最后把结果汇总。这样既高效，又不会让主 AI 的“脑子”过载。这个就是 Claude Code 的 Subagents。
常见问题：压缩后的总结会不会丢失重要细节？
答：有可能。建议让 AI 在总结时按优先级标记：关键决策、待办事项、重要数据等。另外，可以在压缩前手动备份原始对话，以备核查。
下次当你的 AI Agent 表现不佳时，别再只去折腾 Prompt 了。去看看它的上下文里，是不是塞了太多垃圾信息，或者缺少了关键的指引。
