Skip to main content
原文：The 8 Levels of Agentic Engineering by Bassim Eledath | 2026-03-10（更新于 2026-03-12）

​
引言

“AI 的编程能力正在超越我们有效驾驭它的能力。” 模型能做什么与团队如何使用它们之间的差距，不会一夜之间消失——它需要跨越 八个不同层级 逐步弥合。大多数读者可能已经超越了最初的阶段，而每个后续层级都代表着产出能力的巨大飞跃。 多人协作效应 在这里非常重要。你的生产力很大程度上取决于队友的能力水平。如果你在第 7 层运作，而同事还停留在第 2 层，你的吞吐量就会被他们的手动审查流程所瓶颈化。这创造了提升整个团队的共同激励。

​
第 1-2 层：Tab 补全与 Agent IDE

这两个基础层级值得快速介绍后继续前进。 Tab 补全 始于 Copilot，要求开发者先搭建代码骨架，然后由 AI 填充空白。以 AI 为核心的 IDE（如 Cursor）通过将聊天界面直接连接到代码库来改变了这一点，实现了多文件编辑并显著降低了摩擦。然而，上下文 仍然是制约因素——模型要么遗漏关键信息，要么淹没在无关细节中。 Plan 模式 在这个阶段作为中间步骤出现：将粗略想法转化为结构化的分步大纲，迭代这些计划，然后触发实现。这种方法在利用模型能力的同时保持了合理的人类控制，不过更高层级越来越减少对这一独立规划阶段的依赖。

​
第 3 层：上下文工程（Context Engineering）

上下文工程在 2025 年成为核心关注点，当时模型已经能够可靠地遵循合理数量的指令，配合精确校准的上下文。挑战不仅在于数量，更在于信号清晰度——“每个 token 都需要为自己在 prompt 中的位置而战。” 这一层级涵盖系统提示、规则文件（.cursorrules、CLAUDE.md）、工具描述、对话历史管理，以及每轮交互中策略性的工具暴露。虽然对噪声容忍度更高的模型已经降低了对这一实践的强调，但上下文工程在特定场景中仍然重要：
  • 小型模型：依赖紧凑模型的语音应用仍然对上下文敏感，token 的减少直接影响延迟
  • Token 密集型工具：像 Playwright 这样的 MCP 和图像输入会快速消耗 token，意外地迫使进入”紧凑会话”状态
  • 工具密集型 Agent：数十个可用工具迫使模型花费大量 token 解析 schema，而非进行高效工作
演进方向从过滤有问题的上下文转向确保最优上下文在恰好正确的时刻出现——这是第 4 层的基础。

​
第 4 层：复利工程（Compounding Engineering）

“复利工程改善此后的每一次会话。” ——Kieran Klaassen
这代表了一个关键拐点，迭代式的”氛围编程（vibe coding）“证明它能够在原型开发之外完成大量实质性工作。 该框架以循环方式运作：充分规划 → 委派给模型 → 评估输出 → 将学习成果编纂成规则。最后的编纂步骤创造了复利效应。LLM 没有持久记忆——没有明确的指令细化，它们明天会重复昨天的错误。 大多数实践者更新 CLAUDE.md 或等效规则文件，将之前会话的经验教训嵌入未来的交互中。但要注意：过度编纂会产生指令膨胀，反而降低性能。 更好的方法是：维护更新的文档结构（如 docs/ 文件夹），让模型能够独立发现和利用。 达到这一层级的实践者会发展出敏锐的上下文意识。当模型出错时，他们本能地检查缺失的上下文，而不是质疑模型的能力——这是进入第 5-8 层的心态前提。

​
第 5 层：MCP 与 Skills

第 3-4 层解决了上下文问题；第 5 层解决能力问题。Model Context Protocol（MCP）和自定义 Skills 赋予 LLM 可操作的访问能力：数据库、API、CI 管道、设计系统、Playwright（用于测试）、Slack（用于通知）。模型从思考转变为行动。 一个实际例子：一个 PR 审查 Skill，根据 PR 特征有条件地生成专门的子 Agent——一个处理数据库集成安全，另一个运行复杂度分析，第三个根据团队标准评估 prompt 健康度，再加上集成的 linting 和 Ruff 检查。 这项投资很重要，因为 Agent 生产的 PR 数量不断攀升，人类审查成为了真正的瓶颈，而非质量执行。随着 Agent 增加产出，“自动化、一致的、Skill 驱动的审查取代了传统的代码审查。” 其他使用中的工具：Braintrust MCP 用于查询评估日志并具有直接修改能力；DeepWiki MCP 为 Agent 提供对开源仓库文档的访问，无需手动注入上下文。 当团队开发出同一 Skill 的多个版本时，整合到共享注册表就变得值得了。像 Block 这样的组织构建了内部 Skills 市场，拥有 100+ 个 Skills 和基于角色的捆绑包，通过 PR、审查和版本控制将 Skills 等同于代码来管理。 一个新兴趋势：CLI 工具越来越多地取代 MCP，因为 token 效率更高。MCP 服务器在每轮交互中注入完整的工具 schema（无论是否使用），而 CLI 执行定向命令，只有相关输出进入上下文窗口。像 agent-browser 这样的工具展示了这种效率优势。 关键警告：第 3-5 层构成先决基础。模型展现出不可预测的变化能力，需要直觉性的边界检测，才能叠加额外的自动化。嘈杂的上下文、规格不足的 prompt、或描述不佳的工具只会在第 6-8 层放大问题。

​
第 6 层：Harness 工程与自动化反馈循环

“这是火箭真正开始起飞的地方。”
上下文工程策展模型输入；Harness 工程构建完整环境——工具、反馈系统和机制，使可靠的自主 Agent 工作无需人类干预。 OpenAI 的 Codex 团队展示了这一点，他们将 Chrome DevTools、可观测性工具和浏览器导航集成到 Agent 运行时中，实现截图、UI 路径导航、日志查询和修复验证。单个 prompt 就能触发：Bug 复现 → 视频录制 → 修复实现 → 通过应用驱动验证 → 开启 PR → 集成审查反馈 → 合并——仅在需要判断时才升级给人类。 实际实现：构建 converse，一个 CLI 工具，使 LLM 能与后端端点进行对话式的逐轮测试。模型修改代码，使用此工具对实时系统进行测试，反复迭代——有时长达数小时。当结果可验证时这特别有效：对话必须遵循指定的流程或适当地调用工具。 核心概念是 “背压（backpressure）“：自动化机制（类型系统、测试、linter、pre-commit hooks）允许 Agent 在没有人类参与的情况下检测和自我修正。自主性需要背压——否则自主 Agent 会变成”垃圾制造机”。 安全维度同样重要。“Agent、它们生成的代码和你的密钥应该存在于独立的信任域中”，防止日志中的 prompt 注入通过受损的安全上下文实现凭证窃取。 两个实践原则：
  • 为吞吐量而非完美设计：要求每次提交都完美会导致 Agent 因重复修复而互相干扰。更好的做法是容忍轻微的非阻塞性问题，在发布前执行最终质量检查——这与人类团队的做法一致
  • 约束优于指令：逐步提示（“做 A，然后 B，然后 C”）越来越过时。定义边界比清单更有效，因为 Agent 会执着于明确的列表，而忽略未列出的项目。更好的方式是：“这是我想要的，工作到通过所有这些测试”
实际基础设施：维护约 100 行的 AGENTS.md，作为目录引导指向其他地方的结构化文档。将文档更新作为 CI 的职责，而非依赖不可避免会过时的手动更新。 这个基础自然引出一个问题：如果 Agent 能自我验证、独立导航仓库、自主修正错误，为什么还需要人坐在那里？

​
第 7 层：后台 Agent

辛辣观点：Plan 模式正在消亡。 “Claude Code 的创建者 Boris Cherny 今天仍然以 Plan 模式启动 80% 的任务”，然而每一代模型的一次性成功率都在攀升。Plan 模式作为离散的人类审批步骤正在接近过时——不是因为规划变得不重要，而是因为模型实现了自我规划的可靠性。这只有在第 3-6 层的基础工作到位时才有效：干净的上下文、明确的约束、描述良好的工具、紧密的反馈循环使模型能够在没有明确人类审查的情况下进行规划。 规划本身并没有消失——它改变了形态。对于第 7 层的复杂功能，“规划”意味着探索：代码库探查、通过 worktree 原型化选项、解决方案空间映射。后台 Agent 越来越多地独立处理这种探索。 这实现了关键转变：Agent 在你从事其他活动时异步执行——从”在多个编辑器标签之间切换”转变为”工作在没有我的情况下进行”。 “Ralph 循环” 提供了流行的入口点：自主 Agent 循环反复运行编码 CLI，直到所有 PRD 项目完成，每次迭代生成带有干净上下文的新实例。经验表明，正确运行 Ralph 循环很困难——PRD 规格不足的问题会反噬。它在某种程度上是即发即忘的。 运行多个 Ralph 循环会产生协调开销：你变成了一个经理，排序工作、检查输出、推动停滞的进度，而不是写代码。编排 Agent 通过处理调度来解决这个问题，让你的主会话保持精简，专注于高层意图而非后勤细节。 “Dispatch” 体现了这种方法——一个 Claude Code Skill，将会话转变为指挥中心。你维护一个干净的会话，而 worker 在隔离的上下文中运行。Dispatcher 负责规划、委派、追踪，保持主上下文用于编排。卡住的 worker 会提出澄清问题，而不是静默失败。 本地 dispatch 适合快速开发（更快的反馈、更容易调试、零基础设施开销）。云托管方法（如”Ramp 的 Inspect”）更适合较长时间的自主操作：Agent 会话在沙箱化的云 VM 中生成，拥有完整的开发环境。PM 在 Slack 中标记 UI bug；Inspect 在你的笔记本电脑关机时接手处理。权衡：运营复杂性（基础设施、快照、安全）vs 可扩展性和超越本地 Agent 的可重复性。两者都用。 一个出人意料有效的模式：为不同任务部署不同模型。精英工程团队避免同质化——不同的思维方式、不同的训练经历、各自的优势贡献。将这个逻辑应用到 LLM：用 Opus 进行实现，用 Gemini 进行探索性研究，用 Codex 进行审查。累积产出超过任何单一模型，体现了群体智慧原则应用于代码。 关键：将实现者与审查者解耦。同一实例既实现又自我评估会产生偏见——忽略问题、过早宣布完成。不同模型或独立的审查 prompt 实例能产生显著更高质量的信号。 后台 Agent 解锁了 CI-AI 的组合。一旦 Agent 可以在没有人类监督的情况下运行，就从现有基础设施触发它们：文档再生机器人提出更新 PR；安全审查者扫描 PR 并提出修复建议；依赖机器人实际升级包并运行测试，而不仅仅是标记它们。良好的上下文、复利规则、能力强的工具、自动化反馈循环——现在自主运作。

​
第 8 层：自主 Agent 团队

还没有人真正掌握这个层级； 但有几个团队正在推进前沿。 第 7 层采用中心辐射模式：编排 LLM 将工作分派给 worker LLM。第 8 层消除了这一瓶颈，通过 Agent 之间的直接协调——认领任务、共享发现、标记依赖、解决冲突，无需通过单个编排者路由一切。 Claude Code 的实验性 Agent Teams 功能 代表了早期实现：并行实例在共享代码库上运行，各自拥有独立的上下文窗口，直接通信。Anthropic 部署了 16 个并行 Agent 从零构建 C 编译器来编译 Linux。Cursor 让数百个并发 Agent 运行数周，从零构建 Web 浏览器，并将代码库从 Solid 迁移到 React。 仔细观察会发现摩擦。Cursor 发现，没有层级结构时，Agent 变得规避风险，原地打转而没有进展。Anthropic 的 Agent 反复破坏现有功能，直到 CI 管道阻止了回归。所有在实验的人都报告：多 Agent 协调真的很难；没有人接近最优。 对于典型任务，模型可能还没有准备好承担这种自主性。即使足够智能，它们对于除登月项目（编译器、浏览器构建——令人印象深刻，但远非干净）之外的任务来说仍然太慢且 token 消耗太大。对于日常工作，第 7 层集中了杠杆效应。第 8 层最终可能会占据主导地位，但目前第 7 层值得投入精力（除非你是 Cursor，突破本身就是业务）。

​
下一层？

接下来会发生什么是不可避免的。 一旦无摩擦地编排 Agent 团队成为常态，纯文本界面就成了不必要的约束。语音到语音的交互（或许是思维到思维？）与编码 Agent 对话——超越语音转文本输入的会话式 Claude Code——自然浮现。大声描述应用变更，然后看着它们实现。 许多人追求完美的一次性成功：陈述意图，立即获得完美的实现。这预设了你确切知道自己想要什么。人类从来不会。软件开发一直是迭代的；这可能会持续下去。它只是变得更容易、超越文本交互、并且急剧加速。 所以：你目前处于哪个层级？哪些具体步骤能推进你到下一层？