别卷 Prompt 了，上下文工程正在淘汰你

AI Agent 应用的竞争逻辑，正在发生根本性变化。

当许多团队还在死磕提示词优化（PE 工程）时，一些优秀团队开始重心转向了上下文工程 (Context Engineering) 。

国庆期间，我反复研读一些 AI 上下文工程资料。今天，我想基于Anthropic 发布blog，和你聊聊这个将成为 AI 产品新护城河的系统性工程。

这篇文章介绍如何有效构建 Agent 环境，其中主要的观点是 ：AI Agent 应用关注的重心，正在从「提示词工程（Prompt Engineering）」，迅速转向「上下文工程（Context Engineering）」。

这个方案的变化，标志着 AI Agent 产品设计与竞争的逻辑进入了下一个阶段：一个更加精细化管理，更能拉开不同团队 AI 工程化效果的阶段。

互联网黑化叫做：深水区。

感兴趣的话，也可以点文章最后的「阅读原文」查看英文资料。

01｜提示词工程的辉煌和它的局限性

在过去几年，我们投入了大量精力去研究和优化提示词（Prompt）。

我们学习怎样向 AI 下达更清晰的指令、提供更丰富的背景，以及通过少量例子来引导大模型，这一切都是为了在单次交互中获得尽可能惊艳的结果。

这个阶段，整个行业的普遍迷信更大的上下文窗口（Context Window），好像长上下文就能带来更强的智能，似乎只要把所有相关资料都灌给大模型，大模型就能解决我们需要一切。

于是，去年 3 月份开始，以 Kimi 为代表，开始卷大模型的上下文长度。

各家模型厂商纷纷卷了起来…

但最近随着 AI Agent 应用的迭代，各位 Agent 开发者用实践证明，纯 PE 的这条路很快就遇到了瓶颈。

这篇文章指出：大型语言模型在处理信息时，存在注意力预算（Attention Budget）的限制。

当上下文窗口被海量、未经筛选的信息填满时，模型的性能并不会线性提升，反而会因为信息过载而下降，产生所谓的「上下文衰减（Context Rot）」。

也就是说模型会忘记或忽略上下文开头或中间的关键信息，导致输出结果的连贯性和准确性大幅降低。

同时，基于传统单条提示词 + 参考资料的 PE 范式，正在被上下文工程淘汰。

上下文工程到底是个啥？下图直观地展示了两种模式的根本区别：

同样做一个 Agent 应用，左侧的提示词工程，是一条单向、一次性的路径。而右侧的上下文工程，则是一个动态、循环的系统。

强调在将信息送入模型之前，必须经过一道关键工序：策展（Curation）。

我简单做了一个对比的表：

02｜上下文工程的三大核心策略

上下文工程的本质，是一套关于如何为AI精心筛选和管理信息的系统性方法论。

它不再追求将所有信息都塞给模型，而是追求：尽可能在任务的每一个环节，都为模型提供最优的信息组合。

根据Anthropic的实践，我们可以将其归纳为三大核心策略。

策略一、优化窗口内的信息流：动态压缩（Compaction）

为了解决长对话中的信息遗忘问题，最直接的方法是在上下文窗口接近上限时，对上下文内容进行智能压缩。

不过，这不是简单的粗暴总结，而是一个保留关键决策、待办事项和核心上下文的提炼过程。

在文章中提到了一个Claude 玩宝可梦的 Agent， 这个实验中清晰地展示了这个方案。

系统通过一个循环的「摘要 / 管理」模块，让Claude能够持续地总结游戏进展，这样能让 AI 在长达好几个小时的游戏过程中保持目标和记忆的连贯性。

下图是我翻译了关键说明的版本，如果微信压缩了，可以后台留言「宝可梦」获得高清大图。

通过这种方式，AI获得了在长时间任务中进行自我反思和状态跟踪的能力，确保「注意力预算」始终用在最关键的信息上。

但我个人在业务上的尝试发现，即便动态摘要，假设用户的内容都很重要不太好放弃的话…迟早还是会达到大模型上下文上线的。

策略二、突破窗口的物理限制——持久化记忆（Persistent Memory）

大模型上下文窗口终究是有限的，它类似计算机的内存一样，断电就消失了。

如果想要让 AI 具备长期记忆和真正的个性化能力，就必须为它配备一块硬盘：持久化的外部记忆模块。

上下文工程通过赋予 AI 调用工具的能力，使得大模型能够随时读写外部的知识库或笔记文件。

这同样在宝可梦的 Agent 里得到了体现，AI可以通过工具随时更新自己的「知识库」，记录下它的关键发现和个人的偏好。

还是这张图，为了避免你翻页，我再贴一下。

这个策略使得 AI 能够超越单次对话的限制，对用户和项目知识的理解得以沉淀，这是构建能与用户共同成长的、真正伙伴式 AI 的基础。

策略三、分解复杂任务的上下文：子智能体架构（Sub-agent Architectures）

当 AI 面临一个极其复杂的、需要多种专业能力的任务时，让单一 AI 承载所有上下文和工具，通常会导致混乱和低效。

Anthropic 里给出的更优的策略是「分而治之」。

子智能体架构，就是将一个相对宏大目标分解，交给多个专职的子 Agent 协同完成。

每个子Agent都拥有自己独立的、高度优化的上下文环境，专注于解决特定的子任务。

例如，在文章中的一个例子里，一个中心化的 Agent 将开发任务分解，并协同调度四个子Agent分别处理邮件、搜索、总结和清理等不同工作。

这种架构极大地降低了单个模型的认知负担，通过上下文的隔离和分发，实现了系统整体性能和稳定性的提升。

这是另一篇关于多 Agent 设计的 blog，推荐。

https://www.anthropic.com/engineering/multi-agent-research-system

03｜ 从理论到实践：上下文工程的价值

上下文工程不仅是理论上的进步，更在实践中带来了可量化的性能提升。

Anthropic的内部数据显示，无论是集成Slack还是Asana的工具，经过针对模型特性进行精心设计和优化的版本（即应用了上下文工程思想的版本），任务完成的准确率都显著高于仅由人类工程师按常规思路编写的版本。

这些数据有力地说明，AI 产品的性能上限，不仅取决于模型本身的能力，更取决于我们围绕模型所构建的「信息整理系统」的精巧程度。

换言之，就是有效的 AI 工程化方案，能让你的产品显著和其他产品拉开差距。

无论是成本，还是产品效果。

对工具返回格式的细微调整（例如提供concise或detailed选项让AI自行选择），也能有效提升交互效率和任务成功率。

终｜上下文工程将成为你新的护城河

这篇文章看起来简简单单，但这对我们这些身处牌桌上的产品经理、创业者和管理者，意味着什么？

我觉得，上下文工程的兴起其实是为所有 AI 产品和创业者明确了新的战略焦点：

未来 AI 产品的核心竞争力，开始从追基础模型的原生能力，转向开发者对大模型的架构能力。

对于我们来说，我们需要转变思维，开发的工作重心需要从单纯地追求更好的模型转向设计更高效的、符合产品定位的上下文工程化架构。

毕竟，现在大模型基模的能力快到边界，基模也卷不动了。

换言之，以后你的产品的护城河，将不再是你调用了哪个最牛逼的模型，因为模型能力会迅速趋同。

接下来要卷的，在于：

这些，共同构成了你的上下文管理的架构，这些就算是恶意用户都根本没办法像提示词那样套出来。

它才是真正无法被轻易复制的核心竞争力。

上面说了对产品的要求，我个人认为开发者的组织构成，或者说团队能力模型也需要随之做一定的调整。

得益于 Vibe Coding 的崛起，对于产研团队的核心能力，也需要从提示词调优技巧的提升，扩展到信息流管理、智能体协同设计和动态数据策展等等这样的系统工程能力。