8.0
热点
AI SCORE
技术实践2026-03-16 08:00
智能体工程进阶：从 Tab 补全到 Agent 团队的 8 个等级
宝玉 AI#Agent#AI编程#进阶路线
Editor brief · 编辑速览
系统梳理 AI 编程能力的完整进阶路线，从基础补全到自主 Agent 团队，为开发者提供清晰的能力进阶框架。
AI 的编程能力正在超越我们驾驭它的能力。这就是为什么所有那些拼命刷 SWE-bench 分数的努力，并没有与工程领导层真正关心的生产力指标同步。Anthropic 团队用 10 天就上线了 Cowork，而另一个团队用着同样的模型，却连一个 POC（概念验证）都搞不定——区别在于，一个团队已经弥合了能力与实践之间的差距，而另一个还没有。
这个差距不会一夜之间消失，而是会分等级逐步缩小。总共有 8 个等级。读到这篇文章的大多数人可能已经越过了前几个等级，而你应该迫不及待地想达到下一个——因为每升一级，都意味着产出的巨大飞跃；每次模型能力的提升，又会进一步放大这些收益。
你应该在意的另一个原因，是多人协作效应。你的产出比你想象中更依赖队友所处的等级。假设你是 7 级高手，晚上睡觉时，后台智能体就在帮你提交好几个 PR。但如果你的代码仓库需要一位同事审批才能合并，而这位同事还停留在 2 级，仍在手动审查 PR，那么你的吞吐量就被卡死了。所以，帮助队友升级，对你自己也有利。
通过与许多团队和个人交流他们使用 AI 辅助编程的实践，以下是我观察到的等级进阶路径，顺序并不绝对严格。
这两个等级我会快速带过，主要是为了记录完整。可以随意跳读。
Tab 补全是一切的起点。GitHub Copilot 拉开了这场运动的序幕——按一下 Tab 键，自动补全代码。很多人可能早就忘了这个阶段，新入行的人甚至可能直接跳过了。它更适合有经验的开发者：他们能先搭好代码骨架，然后让 AI 填充细节。
以 Cursor 为代表的 AI 专用 IDE 改变了格局。它们将聊天与代码库连接起来，让跨文件编辑变得轻松得多。但它的天花板始终是上下文。模型只能帮你处理它能看到的内容，而令人抓狂的是，它要么没有看到正确的上下文，要么看到了太多无关的上下文。
处于这个等级的大多数人，也在尝试所选编程智能体的计划模式：把一个粗略的想法转化为提供给 LLM 的结构化分步计划，反复迭代这个计划，然后触发执行。在这个阶段，它的效果不错，也是保持掌控的一种合理方式。不过在后面的等级中，我们会看到，对计划模式的依赖将越来越少。
现在进入有意思的部分了。
上下文工程（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 级铺平了道路。
上下文工程改善的是当前这一次会话。复合工程（Compounding Engineering，由 Kieran Klaassen 提出）改善的是此后的每一次会话。
这个理念对我和许多人来说都是一个转折点——它让我们意识到，“凭感觉编程”远不只是做原型那么简单。
这是一个“计划、委派、评估、沉淀”的循环。你规划任务，为 LLM 提供足够的上下文，让它能够成功；你把任务委派出去；你评估产出；然后是关键的一步——把学到的东西沉淀下来：什么有效、什么出了问题、下次应该遵循什么模式。
复合循环：计划、委派、评估、沉淀——每一轮都让下一轮变得更好。
魔力就在“沉淀”这一步。LLM 是无状态的。如果它昨天重新引入了一个你明确移除的依赖，那么明天它还会这么做——除非你告诉它不要这样做。
最常见的解决方法，是更新你的 CLAUDE.md 或等效的规则文件，把经验教训固化到未来的每一次会话中。但要注意：什么都往规则文件里塞的冲动，可能会适得其反——指令太多，等于没有指令。
更好的做法，是创造一个环境，让 LLM 能够自己轻松发现有用的上下文。例如，维护一个持续更新的 docs/ 文件夹。第 7 级会详细讨论这一点。
实践复合工程的人，通常对喂给 LLM 的上下文高度敏感。当 LLM 犯错时，他们的本能反应是先思考上下文是不是缺少了什么，而不是责怪模型能力不行。正是这种直觉，让第 5 到第 8 级成为可能。
第 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。而且看起来每家公司都在发布自己的 CLI，例如 Google Workspace CLI，Braintrust 也即将推出一个。
原因在于 token 效率。MCP 服务器会在每一轮中把完整的工具定义注入上下文，不管智能体是否会使用它们。CLI 则恰好相反：智能体运行一个有针对性的命令，只有相关输出才会进入上下文窗口。我大量使用 agent-browser，而不是 Playwright MCP，正是出于这个原因。
在继续之前，先暂停一下。
第 3 到第 5 级是后续一切的基石。LLM 在某些事情上出奇地好，在另一些事情上又出奇地差。你需要先培养出对这些能力边界的直觉，然后才能在其上叠加更多自动化。
如果你的上下文很嘈杂、提示词不充分或不准确、工具描述含糊不清，那么第 6 到第 8 级只会放大这些问题。
上下文工程关注的是模型能看到什么。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 流程，而不是依赖那些很快就会过时的临时更新。
当你把这一切都构建好之后，一个自然的问题就出现了：
如果智能体能够验证自己的工作、在仓库中自如导航，并且不需要你就能纠正错误——那么你为什么还需要坐在椅子上？
提个醒：对于还停留在前几个等级的朋友，接下来的内容听起来可能很科幻。不过没关系，可以先收藏，回头再来看。
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 并提交修复。
一个依赖管理机器人不只是标记问题，而是真正升级软件包并运行测试套件。
好的上下文、持续沉淀的规则、强大的工具、自动化的反馈循环——现在全都可以自主运行。
目前还没有人真正掌握这个等级，尽管已经有少数人正在向它进发。这是当前的前沿。
在第 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 一步到位地完美呈现。
问题在于，这个前提假设我们人类确切地知道自己想要什么。
但我们不知道。从来都不知道。
软件开发一直是迭代式的，我认为它永远都会如此。只不过，它将变得容易得多，远远超越纯文本交互，而且速度会快得多。
所以：你在哪个等级？你正在做什么，以达到下一个等级？