智能体工程的 8 个等级

AI 的编程能力正在超越我们驾驭它的能力。这就是为什么所有那些拼命刷 SWE-bench 分数的努力，并没有与工程领导层真正关心的生产力指标同步。Anthropic 团队用 10 天就上线了 Cowork，而另一个团队用着同样的模型却连一个 POC（概念验证）都搞不定——区别在于一个团队已经弥合了能力与实践之间的差距，而另一个还没有。

这个差距不会一夜之间消失，而是分等级逐步缩小。总共 8 个等级。读到这篇文章的大多数人可能已经过了前几个等级，而你应该迫不及待地想达到下一个——因为每升一级都意味着产出的巨大飞跃，而每次模型能力的提升都会进一步放大这些收益。

你应该在意的另一个原因是多人协作效应。你的产出比你想象的更依赖于队友的等级。假设你是 7 级高手，晚上睡觉时后台智能体就在帮你提好几个 PR。但如果你的代码仓库需要一位同事审批才能合并，而这位同事还停留在 2 级，仍在手动审查 PR，那你的吞吐量就被卡死了。所以帮队友升级，对你自己也有利。

通过和许多团队及个人交流他们使用 AI 辅助编程的实践，以下是我观察到的等级进阶路径（顺序并不绝对严格）：

智能体工程的 8 个等级

第 1 和第 2 级：Tab 补全与智能体 IDE

这两个等级我会快速带过，主要是为了记录完整。可以随意跳读。

Tab 补全是一切的起点。GitHub Copilot 拉开了这场运动的序幕——按一下 Tab 键，自动补全代码。很多人可能早就忘了这个阶段，新入行的人甚至可能直接跳过了。它更适合有经验的开发者，他们能先搭好代码骨架，然后让 AI 来填充细节。

以 Cursor 为代表的 AI 专用 IDE 改变了格局，它们将聊天与代码库连接起来，让跨文件编辑变得轻松得多。但天花板始终是上下文。模型只能帮你处理它能看到的内容，而令人抓狂的是，它要么没看到正确的上下文，要么看到了太多无关的上下文。

处于这个等级的大多数人也在尝试所选编程智能体的计划模式：把一个粗略的想法转化为结构化的分步计划给 LLM，反复迭代这个计划，然后触发执行。在这个阶段效果不错，也是保持掌控的合理方式。不过后面的等级我们会看到，对计划模式的依赖会越来越少。

第 3 级：上下文工程

现在进入有意思的部分了。上下文工程（Context Engineering） 是 2025 年的年度热词，它之所以成为一个概念，是因为模型终于可以可靠地遵循合理数量的指令，配合恰到好处的上下文。嘈杂的上下文和不充分的上下文一样糟糕，所以核心工作在于提高每个 token 的信息密度。“每个 token 都要为自己在提示词中的位置而战”——这就是当时的信条。

同样的信息，更少的 token——信息密度才是王道（来源：humanlayer/12-factor-agents）

在实践中，上下文工程涉及的面比大多数人意识到的要广。它包括你的系统提示词和规则文件（.cursorrules、CLAUDE.md）。它包括你如何描述工具，因为模型读取这些描述来决定调用哪个工具。它包括管理对话历史，避免长时间运行的智能体在第十轮对话后迷失方向。它还包括决定每轮暴露哪些工具，因为太多选项会让模型不知所措——就像人一样。

如今你已经不太听到上下文工程这个说法了。天平已经倾向于那些能容忍更嘈杂的上下文、在更混乱的场景中依然能推理的模型（更大的上下文窗口也有帮助）。但注意上下文的消耗仍然很重要。以下几个场景中它依然会成为瓶颈：

• 小模型对上下文更敏感。 语音应用通常使用较小的模型，而且上下文大小也与首 token 延迟相关，影响响应速度。
• Token 消耗大户。 像 Playwright 这样的 MCP（Model Context Protocol，模型上下文协议）和图片输入会快速吞噬 token，让你在 Claude Code 中比预期更早进入“压缩会话”状态。
• 接入了几十个工具的智能体， 模型花在解析工具定义上的 token 比做实际工作的还多。

更宏观的要点是：上下文工程并没有消失，只是在进化。 重心已经从过滤坏上下文转向确保正确的上下文在正确的时间出现。而正是这个转变为第 4 级铺平了道路。

第 4 级：复合工程

上下文工程改善的是当前这一次会话。复合工程（Compounding Engineering，由 Kieran Klaassen 提出）改善的是此后的每一次会话。这个理念对我和许多人来说都是一个转折点——它让我们意识到“凭感觉编程”远不只是做原型那么简单。

这是一个“计划、委派、评估、沉淀” 的循环。你规划任务，给 LLM 提供足够的上下文让它成功。你把任务委派出去。你评估产出。然后关键的一步——你把学到的东西沉淀下来：什么有效、什么出了问题、下次应该遵循什么模式。

复合循环：计划、委派、评估、沉淀——每一轮都让下一轮更好

魔力就在“沉淀”这一步。LLM 是无状态的。如果它昨天重新引入了一个你明确移除的依赖，明天它还会这么做——除非你告诉它不要。最常见的解决方法是更新你的 CLAUDE.md（或等效的规则文件），把经验教训固化到每一次未来的会话中。但要注意：什么都往规则文件里塞的冲动可能适得其反（指令太多等于没有指令）。更好的做法是创造一个环境，让 LLM 能自己轻松发现有用的上下文——比如维护一个保持更新的 docs/ 文件夹（第 7 级会详细讲这个）。

实践复合工程的人通常对喂给 LLM 的上下文高度敏感。当 LLM 犯错时，他们的本能反应是先想上下文是不是缺了什么，而不是怪模型不行。正是这种直觉，使得第 5 到第 8 级成为可能。

第 5 级：MCP 与技能

第 3 和第 4 级解决的是上下文问题。第 5 级解决的是能力问题。MCP 和自定义技能让你的 LLM 能访问数据库、API、CI 流水线、设计系统，还有用于浏览器测试的 Playwright、用于通知的 Slack。模型不再只是在思考你的代码库——它现在可以直接操作了。

关于 MCP 和技能的优质资料已经不少，我就不赘述它们是什么了。但举几个我使用它们的例子：我们团队共享一个 PR 审查技能，大家一起迭代改进（现在仍在改），它会根据 PR 的性质有条件地启动子智能体。一个负责检查与数据库的集成安全性，一个做复杂度分析来标记冗余或过度工程，另一个检查提示词健康度以确保提示词遵循团队标准格式。它还运行 linter 和 Ruff。

为什么在审查技能上投入这么多？因为当智能体开始批量产出 PR 时，人工审查就成了瓶颈而非质量关卡。Latent Space 提出了一个令人信服的论点：我们熟知的代码审查已经死了。取而代之的是自动化的、一致的、技能驱动的审查。

在 MCP 方面，我使用 Braintrust MCP 让 LLM 能查询评估日志并直接做出修改。我使用 DeepWiki MCP 让智能体可以访问任何开源仓库的文档，而无需手动把文档拉入上下文。

当团队中多个人开始各写各的同类技能时，就值得整合成一个共享 registry 了。Block（致以慰问）有一篇很好的文章：他们构建了一个内部技能市场，拥有超过 100 个技能，并为特定角色和团队策划了技能套餐。技能和代码享受同等待遇：pull request、审查、版本历史。

还有一个值得关注的趋势：LLM 越来越多地使用 CLI 工具而非 MCP（而且好像每家公司都在发布自己的：Google Workspace CLI，Braintrust 也即将推出一个）。原因是 token 效率。MCP 服务器在每一轮都会把完整的工具定义注入上下文，不管智能体是否使用它们。CLI 则反过来：智能体运行一个针对性的命令，只有相关的输出才进入上下文窗口。我大量使用 agent-browser 而不是 Playwright MCP，正是出于这个原因。

在继续之前暂停一下。 第 3 到第 5 级是后续一切的基石。LLM 在某些事情上出奇地好，在另一些事情上又出奇地差，你需要培养出对这些边界的直觉，然后才能在上面叠加更多自动化。如果你的上下文是嘈杂的、提示词是不充分或不准确的、工具描述是含糊的，那么第 6 到第 8 级只会放大这些问题。

第 6 级：Harness Engineering

火箭真正开始起飞了。

上下文工程关注的是模型看到什么。Harness Engineering 关注的是构建整个环境——工具、基础设施和反馈循环——让智能体能在你不干预的情况下可靠地工作。给智能体的不只是编辑器，而是完整的反馈循环。

OpenAI 的 Codex 工具链——一套完整的可观测性系统，让智能体可以查询、关联和推理自己的输出（来源：OpenAI）

OpenAI 的 Codex 团队把 Chrome DevTools、可观测性工具和浏览器导航集成到了智能体运行时中，让它可以截屏、驱动 UI 流程、查询日志、验证自己的修复结果。给一个提示词，智能体就能复现 bug、录制视频、实现修复。然后它通过操控应用来验证，提交 PR，回应审查反馈，合并——只在需要判断时才上报人工。智能体不只是写代码，它能看到代码产生了什么效果，然后迭代改进——就像人类一样。

我的团队做的是技术故障排查的语音和聊天智能体，所以我做了一个叫 converse 的 CLI 工具，让任何 LLM 都可以与我们的后端接口聊天，进行逐轮对话。LLM 修改代码后，用 converse 在线上系统测试对话，然后迭代。有时这种自我改进循环会连续运行好几个小时。当结果可验证时这尤其强大：对话必须遵循这个流程，或者在特定情况下调用这些工具（比如转人工客服）。

支撑这一切的核心概念是回压机制（Backpressure）——自动化的反馈机制（类型系统、测试、linter、pre-commit 钩子），让智能体能在不需要人工干预的情况下发现并纠正错误。如果你想要自主性，就必须有回压机制，否则你得到的就是一台垃圾生产机器。 这一点也延伸到安全领域。Vercel 的 CTO 指出，智能体、它们生成的代码和你的密钥应该处于不同的信任域中，因为埋在日志文件里的一条提示词注入攻击就可能诱使智能体窃取你的凭证——如果所有东西共享同一个安全上下文的话。安全边界就是回压机制：它们约束的是智能体失控时能做什么，而不仅仅是应该做什么。

两个让这个理念更清晰的原则：

• 为吞吐量而非完美设计。 当要求每次提交都完美时，智能体会在同一个 bug 上反复纠缠，互相覆盖对方的修复。更好的做法是容忍小的非阻塞性错误，在发布前做一次最终的质量检查。对人类同事我们也是这么做的。
• 约束优于指令。 一步步地提示（“先做 A，再做 B，然后做 C”）正在变得过时。根据我的经验，定义边界比列清单更有效，因为智能体会死盯着清单，忽略清单之外的一切。更好的提示是“这是我想要的结果，一直做直到通过所有这些测试。”

Harness Engineering 的另一半是确保智能体能在没有你的情况下在代码仓库中自如导航。OpenAI 的做法是：把 AGENTS.md 控制在大约 100 行以内，作为目录指向其他结构化文档，并把文档的时效性纳入 CI 流程，而不是依赖那些很快就会过时的临时更新。

当你把这一切都建好之后，一个自然的问题就出现了：如果智能体能验证自己的工作、在仓库中自如导航、不需要你就能纠正错误——那你为什么还需要坐在椅子上？

提个醒，对于还在前几个等级的朋友，接下来的内容可能听起来很科幻（但没关系，先收藏，回头再来看）。

第 7 级：后台智能体

辣评：计划模式正在消亡。

Claude Code 的创造者 Boris Cherny 目前仍有 80% 的任务以计划模式开始。但随着每一代新模型的发布，经过计划后的一次性成功率不断攀升。我认为我们正在接近这样一个临界点：计划模式作为一个独立的人工介入步骤将逐渐消失。不是因为计划本身不重要，而是因为模型已经足够聪明，能自己做好计划了。但有个重要前提：只有当你做好了第 3 到第 6 级的工作，这才成立。如果你的上下文是干净的、约束是明确的、工具描述是完善的、反馈循环是闭合的，模型就能在不需要你审查的情况下可靠地规划。如果这些工作没做到位，你还是得盯着计划不放。

说清楚一点，计划作为一种通用实践并不会消失，只是在改变形态。对于新手来说，计划模式仍然是正确的入口（如第 1 和第 2 级所述）。但对于第 7 级的复杂功能，“计划”看起来不再是写一个分步大纲，而更像是探索：探查代码库、在 worktree 中做原型实验、摸清解决方案的空间。而且越来越多的时候，是后台智能体在替你做这些探索。

这很重要，因为正是它解锁了后台智能体。如果一个智能体能生成靠谱的计划并执行而不需要你签字确认，它就能在你做别的事的时候异步运行。这是一个关键转变——从“我同时切换着多个标签页”变成了“有工作在没有我的情况下推进着”。

Ralph 循环是流行的入门方式：一个自主智能体循环，反复运行编程 CLI 直到 PRD（产品需求文档）中的所有事项完成，每次迭代都会启动一个带有全新上下文的新实例。在我的经验中，要把 Ralph 循环跑好并不容易，PRD 中的任何不充分或不准确的描述最终都会反噬。它有点太“扔出去就不管了”。

你可以并行运行多个 Ralph 循环，但智能体启动得越多，你就越会发现时间都花在哪了：协调它们、安排工作顺序、检查输出、推动进度。你已经不写代码了——你变成了一个中层管理者。 你需要一个编排智能体来处理调度，这样你才能专注于意图而非后勤。

Dispatch 跨 3 个模型并行启动 5 个 worker——你的会话保持精简，智能体在干活

我最近在大量使用的工具是 Dispatch，这是我做的一个 Claude Code 技能，把你的会话变成一个指挥中心。你留在一个干净的会话中，worker 在隔离的上下文中完成繁重的工作。调度器负责计划、委派和跟踪，你的主上下文窗口被保留用于编排。当 worker 卡住时，它会抛出澄清性问题而不是默默失败。

Dispatch 在本地运行，非常适合你想与工作保持紧密联系的快速开发场景：反馈更快、调试更方便、没有基础设施开销。Ramp 的 Inspect 则是互补方案，适用于运行时间更长、更自主的工作：每个智能体会话都在云端沙箱 VM 中启动，带有完整的开发环境。一个 PM 发现了 UI bug，在 Slack 中标记出来，Inspect 就会在你合上笔记本电脑的时候接手并处理。代价是运维复杂性（基础设施、快照、安全性），但你获得的是本地智能体无法比拟的规模和可复现性。我建议两者都用（本地和云端后台智能体）。

在这个等级有一个出人意料地强大的模式：用不同的模型做不同的工作。最好的工程团队不是由一群克隆人组成的。团队成员有不同的思维方式、不同的训练背景、不同的优势。同样的逻辑适用于 LLM。这些模型经过了不同的后训练，有着明显不同的性格特点。我经常把 Opus 分配给实现工作，Gemini 做探索性研究，Codex 负责审查，综合产出比任何单一模型独立工作都更强。可以理解为群体智慧，但用在了代码上。

至关重要的是，你还需要把实现者和审查者解耦。这个教训我吃了太多次亏：如果同一个模型实例既负责实现又负责评估自己的工作，它会有偏见。它会忽略问题，告诉你所有任务都完成了——实际上并没有。这不是恶意，原因和你不会给自己的考试打分一样。让另一个模型（或一个带有审查专用提示词的不同实例）来做审查。你的信号质量会大幅提升。

后台智能体还为 CI 与 AI 的结合打开了闸门。一旦智能体可以在没有人坐镇的情况下运行，就可以从现有基础设施中触发它们。一个文档机器人在每次合并后重新生成文档，并提交 PR 来更新 CLAUDE.md（我们在用这个，节省了大量时间）。一个安全审查机器人扫描 PR 并提交修复。一个依赖管理机器人不只是标记问题，而是真正升级包并运行测试套件。好的上下文、持续沉淀的规则、强大的工具、自动化的反馈循环——现在全都在自主运行。

第 8 级：自主智能体团队

目前还没有人真正掌握了这个等级，尽管有少数人正在向它进发。这是当前的前沿。

在第 7 级，你有一个编排 LLM 以中心辐射式模式向工作 LLM 分发任务。第 8 级移除了这个瓶颈。智能体之间直接协调——认领任务、共享发现、标记依赖关系、解决冲突——一切都不需要经过单一的编排者。

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

但仔细看就会发现问题。Cursor 发现没有层级结构时，智能体变得畏首畏尾，原地打转毫无进展。Anthropic 的智能体不断破坏已有功能，直到添加了 CI 流水线来防止回归才有所改善。所有在这个等级做实验的人都说同一件事：多智能体协调是个很难的问题，还没有人找到最优解。

说实话，我不认为模型已经为大多数任务的这种自主程度做好了准备。即使它们够聪明，对于编译器和浏览器构建以外的月球登陆级项目来说，它们仍然太慢、太费 token，在经济上划不来（令人印象深刻，但远谈不上成熟）。对于我们大多数人日常的工作来说，第 7 级才是真正的杠杆所在。我不会意外第 8 级最终成为主流模式，但现在我会把精力放在第 7 级上（除非你是 Cursor——突破本身就是你的业务）。

第 ? 级

不可避免的“接下来是什么”问题。

一旦你能熟练地编排智能体团队而没有太多摩擦，交互界面就没理由只停留在文本上了。语音对语音（也许是思维对思维？）与编程智能体的交互——对话式的 Claude Code，而不仅仅是语音转文字输入——是自然的下一步。看着你的应用，大声描述一连串改动，然后看着它们在你面前发生。

有一群人在追逐完美的一次性生成：说出你想要什么，AI 一步到位地完美呈现。问题在于这个前提假设我们人类确切地知道自己想要什么。但我们不知道。从来都不知道。软件开发一直是迭代式的，我认为它永远会是。只不过它会变得容易得多，远远超越纯文本交互，而且快得多。

所以：你在哪个等级？你在做什么来达到下一个？