智能体工程的八个演进阶段

AI 的编程能力正在超越我们有效利用它的能力。

这就是为什么所有的 SWE-bench 刷分行为并没有转化为工程领导层真正关心的生产力指标。当 Anthropic 的团队在 10 天内交付像 Cowork 这样的产品，而另一个团队在使用相同模型的情况下仍无法突破一个破碎的 POC（概念验证）时，区别在于一个团队已经缩小了能力与实践之间的差距，而另一个团队没有。

这个差距不会一夜之间消失，而是分阶段缩小的。总共有 8 个阶段。阅读本文的大多数人可能已经度过了前几个阶段，你应该渴望达到下一个阶段，因为随后的每一个级别都是产出的巨大飞跃，而模型能力的每一次提升都会进一步放大这些收益。

另一个你应该关注的原因是“多人游戏效应”。你的产出比你想象的更取决于队友的水平。假设你是一个 7 级巫师，在睡觉时通过后台 Agent 提交了几个可靠的 PR。如果你的代码库在合并前需要同事的批准，而那位同事处于第 2 级，仍在手动审查 PR，这就会抑制你的吞吐量。因此，提升团队的整体水平符合你的最佳利益。

通过与多个实践 AI 辅助编程的团队和个人交流，我看到了以下等级的演进过程（虽然并非完美的线性顺序）：

第 1 级与第 2 级：Tab 补全与 Agent IDE

为了完整性，我将快速介绍这两个级别。

一切始于 Copilot 和 Tab 键补全。点击 Tab，自动补全代码。这可能早已被许多人遗忘，甚至被 Agent 工程的新进入者完全跳过。它更青睐那些在 AI 填补空白之前能够熟练构建代码框架的资深开发者。

随后，像 Cursor 这样以 AI 为核心的 IDE 改变了游戏规则，它将聊天功能连接到你的代码库，使多文件编辑变得异常简单。但瓶颈始终在于上下文 (Context)。模型只能处理它能看到的内容，而且令人恼火的是，它经常要么没看到正确的上下文，要么看到了太多错误的上下文。

处于这一级别的大多数人也在尝试使用其编程 Agent 的“计划模式”（Plan Mode）：将粗略的想法转化为 LLM 的结构化分步计划，对该计划进行迭代，然后触发实现。在这个阶段，这种方式运作良好，是保持控制的合理方法。不过我们会在后面的级别中看到，对计划模式的依赖会逐渐减少。

第 3 级：上下文工程 (Context Engineering)

作为 2025 年的流行语，“上下文工程”在模型变得能够可靠地遵循带有适量上下文的指令时应运而生。嘈杂的上下文与不明确的上下文一样糟糕，因此努力的方向在于提高每个 Token 的信息密度。“每个 Token 都需要为自己在 Prompt 中的位置而战”成为了座右铭。

在实践中，上下文工程涉及的范围比人们意识到的要广。它包括你的系统提示词和规则文件（如 .cursorrules、CLAUDE.md）。它关乎你如何描述你的工具，因为模型通过阅读这些描述来决定调用哪一个。它还包括管理对话历史，以免长期运行的 Agent 在十轮对话后迷失方向。此外，还需决定每轮对话暴露哪些工具，因为过多的选择会像淹没人类一样淹没模型。

如今你可能不常听到上下文工程了。天平已经向那些能够容忍嘈杂上下文并在混乱领域中进行推理的模型倾斜（更大的上下文窗口也有所帮助）。尽管如此，关注上下文消耗依然具有现实意义。例如：小型模型对上下文更敏感；语音应用通常使用小型模型，其上下文大小与首个 Token 的响应时间相关，从而影响延迟。像 Playwright 这样的 MCP 和图像输入会迅速消耗 Token，使你比预期更快地进入 Claude Code 的“压缩会话”状态。而拥有数十个工具访问权限的 Agent，在解析工具 Schema 上花费的 Token 往往比做有用功还要多。

更广泛的一点是，上下文工程并没有消失，它只是进化了。重点已从过滤坏的上下文转向确保正确的上下文在正确的时间出现。这种转变开启了第 4 级。

第 4 级：复合工程 (Compounding Engineering)

上下文工程改进的是当前会话，而复合工程改进的是之后的每一个会话。由 Kieran Klaassen 推广的复合工程是一个转折点，它让我和许多人意识到，“氛围编程”（Vibe Coding）能做的远不止原型设计。

这是一个“计划、委派、评估、固化”的循环。你为任务规划足够的上下文以确保 LLM 成功；你委派任务；你评估产出；然后，至关重要的一步是，你固化所学到的东西：什么有效、什么坏了、下次应该遵循什么模式。

固化这一步是实现复合效应的关键。LLM 是无状态的。如果它们重新引入了你昨天明确删除的依赖项，除非你告诉它们不要这样做，否则它们明天还会这样做。关闭该循环最常见的方法是更新你的 CLAUDE.md（或等效的规则文件），以便将教训植入到未来的每一个会话中。

一点警告： 将所有内容都固化到规则文件中的本能可能会适得其反（指令过多等于没有指令）。更好的做法是创建一个环境，让 LLM 可以轻松地自行发现有用的上下文，例如维护一个最新的 docs/ 文件夹（详见第 7 级）。

复合工程的实践者通常对喂给 LLM 的上下文高度敏感。当 LLM 犯错时，他们会本能地思考缺失了什么上下文，而不是归咎于模型的能力。这种本能使第 5 级到第 8 级成为可能。

第 5 级：MCP 与技能 (Skills)

第 3 级和第 4 级解决了上下文问题，第 5 级则解决了能力问题。MCP（模型上下文协议）和自定义技能让你的 LLM 能够访问数据库、API、CI 流水线、设计系统、用于浏览器测试的 Playwright 以及用于通知的 Slack。模型现在不仅能思考你的代码库，还能对其采取行动。

关于 MCP 和技能已经有很多优秀的资料，我不再赘述。以下是我使用它们的一些例子：我的团队共享一个 PR 审查技能，我们会根据 PR 的性质有条件地启动子 Agent。一个处理数据库的集成安全；另一个运行复杂性分析以标记冗余或过度工程；还有一个检查 Prompt 健康状况，以确保我们的 Prompt 符合团队的标准格式。它还会运行 Linter 和 Ruff。

为什么要在一个审查技能上投入这么多？因为随着 Agent 开始大量产出 PR，人工审查变成了瓶颈，而不是质量关卡。自动化的、一致的、由技能驱动的审查取代了它。

在 MCP 方面，我使用 Braintrust MCP，以便我的 LLM 可以查询评估日志并直接进行更改。我使用 DeepWiki MCP 让 Agent 能够访问任何开源仓库的文档，而无需手动将其拉入上下文。

一旦团队中有多人编写相同技能的不同版本，就值得将其整合到一个共享注册表中。Block 公司对此有一个很好的总结：他们建立了一个内部技能市场，拥有 100 多个技能和针对特定角色、团队的精选包。技能获得了与代码相同的待遇：拉取请求、审查、版本历史。

值得注意的趋势： LLM 使用 CLI 工具而不是 MCP 变得越来越普遍。原因是 Token 效率。MCP 服务器在每一轮对话中都会将完整的工具 Schema 注入上下文，无论 Agent 是否使用它们。CLI 则相反：Agent 运行目标命令，只有相关的输出会进入上下文窗口。

在继续之前有一点需要说明：第 3 级到第 5 级是后续一切的基础。LLM 在某些方面表现出色，在另一些方面则难以预测，你需要在堆叠更多自动化之前，培养出对这些边界的直觉。如果你的上下文很嘈杂，Prompt 描述不清，或者工具描述很糟糕，那么第 6 级到第 8 级只会放大这种混乱。

第 6 级：环境工程与自动反馈循环

这是火箭真正开始升空的地方。

上下文工程是关于筛选模型看到的内容，而环境工程 (Harness Engineering) 则是关于构建整个环境、工具和反馈循环，让 Agent 能够在无需人工干预的情况下完成可靠的工作。给 Agent 反馈循环，而不仅仅是编辑器。

OpenAI 的 Codex 团队将 Chrome DevTools、可观测性工具和浏览器导航接入了 Agent 运行时，使其能够截屏、驱动 UI 路径、查询日志并验证自己的修复。给定一个简单的 Prompt，Agent 可以复现 Bug、录制视频并实施修复。然后它通过驱动应用进行验证，开启 PR，响应审查反馈并合并，仅在需要人工判断时才上报。Agent 不只是写代码，它能看到代码产生的结果并进行迭代，就像人类一样。

我的团队构建用于技术排障的语音和聊天 Agent，因此我构建了一个名为 converse 的 CLI 工具，让任何 LLM 都能与我们的后端端点聊天并进行逐轮对话。Agent 修改代码，使用 converse 针对实时系统测试对话，并进行迭代。有时这些自我改进循环会连续运行数小时。当结果是可验证的时，这尤其强大。

实现这一点的核心概念是背压 (Backpressure)：自动反馈机制（类型系统、测试、Linter、Pre-commit Hooks），让 Agent 能够在无需人工干预的情况下检测并纠正错误。如果你想要自主性，你就需要背压，否则你最终会得到一个“垃圾制造机”。这也延伸到了安全领域。Vercel 的 CTO 认为，Agent、它们生成的代码以及你的密钥应该存在于独立的信任域中，因为埋在日志文件中的 Prompt 注入可能会诱导 Agent 泄露你的凭据。

这里有两个有用的建议：

• 为吞吐量设计，而非完美。 当每个 Commit 都要求完美时，Agent 可能会在同一个 Bug 上纠缠并覆盖彼此的修复。更好的做法是容忍小的非阻塞错误，并在发布前进行最终的质量检查。
• 约束优于指令。 分步提示（“先做 A，再做 B”）正日益过时。定义边界比给出清单更有效，因为 Agent 会盯着清单而忽略清单之外的任何事情。更好的 Prompt 是：“这是我想要的，持续工作直到通过所有这些测试。”

环境工程的另一半是确保 Agent 可以在没有你的情况下导航你的仓库。OpenAI 的做法是：保持 AGENTS.md 在 100 行左右，作为指向其他结构化文档的目录，并将文档的新鲜度作为 CI 的一部分，而不是依赖于容易过时的临时更新。

第 7 级：后台 Agent (Background Agents)

暴论：计划模式正在消亡。

Claude Code 的创造者 Boris Cherny 今天仍有 80% 的任务从计划模式开始。但随着每一代新模型的出现，计划后的单次成功率不断攀升。我认为我们正接近这样一个点：计划模式作为一个独立的人机交互步骤将逐渐消失。这不是因为计划不重要，而是因为模型已经变得足够好，可以独立进行良好的计划。大前提： 你已经完成了第 3 级到第 6 级的工作。

明确地说，作为一般实践的计划并不会消失，它只是在改变形态。对于新手，计划模式仍是正确的切入点。但对于第 7 级的复杂功能，“计划”看起来不再像是写一个分步大纲，而更像是探索：探测代码库、在工作树中原型化方案、映射解决方案空间。而且，后台 Agent 正越来越多地为你完成这些探索。

这之所以重要，是因为它开启了后台 Agent。如果 Agent 可以生成可靠的计划并在无需你签字的情况下执行，它就可以在你做其他事情时异步运行。这是从“我正在处理的多个标签页”到“在我不在时发生的工作”的关键转变。

Ralph 循环是一个流行的切入点：一个自主 Agent 循环，重复运行编码 CLI 直到完成所有 PRD 项目，每次迭代都会生成一个带有干净上下文的新实例。根据我的经验，搞定 Ralph 循环很难，PRD 的任何描述不清都会带来麻烦。它有点太过于“发射后不管”了。

你可以并行运行多个 Ralph 循环，但你启动的 Agent 越多，你就越会注意到你的时间实际上花在了哪里：协调它们、安排工作顺序、检查产出、推动进度。你不再是在写代码，你变成了一个中层管理人员。你需要一个编排 Agent 来处理调度，这样你就可以专注于意图而非后勤。

我一直在大量使用的工具是 Dispatch，这是一个我构建的 Claude Code 技能，它将你的会话变成一个指挥中心。你停留在一个干净的会话中，而工人们在隔离的上下文中完成繁重的工作。调度员负责计划、委派和跟踪。当工人卡住时，它会提出澄清问题，而不是默默失败。

Dispatch 在本地运行，非常适合你希望贴近工作的快速开发。Ramp 的 Inspect 是另一种适用于更长时间、更自主工作的互补方法：每个 Agent 会话都在云端托管的沙箱 VM 中启动，拥有完整的开发环境。我建议两者都用。

在这个级别上，一个出奇强大的模式是：为不同的工作使用不同的模型。 最好的工程团队不是由克隆人组成的，而是由思维方式不同的人组成的。同样的逻辑也适用于 LLM。我经常调度 Opus 进行实现，Gemini 进行探索性研究，Codex 进行审查，累积的产出比任何单一模型独立工作都要强。

至关重要的一点是，你还需要将执行者与审查者解耦。我多次吸取教训：如果同一个模型实例既执行又评估自己的工作，它就会产生偏见。它会忽略问题并告诉你任务已完成，而事实并非如此。这不是恶意，就像你不能自己给自己改卷子一样。让不同的模型（或带有特定审查 Prompt 的不同实例）进行审查，你的信号质量会大幅提升。

后台 Agent 还为 AI 与 CI 的结合打开了大门。一旦 Agent 可以在没有人的情况下运行，就可以从现有基础设施中触发它们。例如：一个文档机器人，在每次合并时重新生成文档并提交 PR 更新 CLAUDE.md；一个安全审查机器人，扫描 PR 并提交修复；一个依赖机器人，真正升级包并运行测试套件，而不仅仅是标记它们。

良好的上下文、复合规则、强大的工具和自动反馈循环，现在都在自主运行。

第 8 级：自主 Agent 团队

目前还没有人完全掌握这一级别，尽管少数人正在向其进军。这是活跃的前沿领域。

在第 7 级中，你有一个编排 LLM 以中心辐射模式向工人 LLM 分派工作。第 8 级移除了这个瓶颈。Agent 之间直接协调，认领任务、分享发现、标记依赖并解决冲突，而无需通过单一编排者路由所有内容。

Claude Code 实验性的 Agent Teams 功能是一个早期实现：多个实例在共享代码库上并行工作，队友在各自的上下文窗口中操作并直接相互通信。Anthropic 使用 16 个并行 Agent 从头开始构建了一个可以编译 Linux 的 C 编译器。Cursor 运行了数百个并发 Agent 数周，从头开始构建了一个 Web 浏览器，并将他们自己的代码库从 Solid 迁移到了 React。

但仔细观察，你会发现其中的裂痕。Cursor 发现，如果没有层级结构，Agent 会变得规避风险，且在没有进展的情况下反复折腾。Anthropic 的 Agent 不断破坏现有功能，直到添加了 CI 流水线来防止回归。每个在这个级别进行实验的人都表达了同样的观点：多 Agent 协调是一个难题，目前还没有人接近最优解。

坦率地说，我认为模型在大多数任务上还没有准备好迎接这种程度的自主性。即使它们足够聪明，对于编译器和浏览器构建等“登月项目”之外的日常工作来说，它们仍然太慢且太耗 Token。对于我们大多数人每天所做的工作，第 7 级才是杠杆所在。

第 ? 级

接下来的问题是必然的。

一旦你能够毫无摩擦地编排 Agent 团队，界面就没有理由仅限于文本。与你的编码 Agent 进行语音对语音的交互——对话式的 Claude Code，而不仅仅是语音转文本输入——是一个自然的下一步。看着你的应用，大声描述一系列更改，然后看着它们在你面前发生。

有一群人正在追求完美的“单次成型”（One-shot）：说明你想要什么，AI 就会在一次处理中完美地构思出来。问题在于，这预设了我们人类确切地知道自己想要什么。事实上我们并不知道。软件一直是迭代的，我认为它永远都会是。它只是会变得更加容易，远远超出纯文本交互，并且速度会快得多。

那么：你现在处于哪一级？你正在做什么来达到下一级？

• 原文链接： x.com/bassim_eledath/sta...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～