> ## Documentation Index
> Fetch the complete documentation index at: https://adonis-til.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Agentic Engineering 的 8 个层级：从代码补全到自主 Agent 团队

> 翻译自 Bassim Eledath 的博客文章，系统梳理 AI 辅助编程从 Tab 补全到自主 Agent 团队的 8 个进化层级，每一层都代表产出能力的巨大飞跃

> 原文：[The 8 Levels of Agentic Engineering](https://www.bassimeledath.com/blog/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——自然浮现。大声描述应用变更，然后看着它们实现。

许多人追求完美的一次性成功：陈述意图，立即获得完美的实现。这预设了你确切知道自己想要什么。人类从来不会。软件开发一直是迭代的；这可能会持续下去。它只是变得更容易、超越文本交互、并且急剧加速。

**所以：你目前处于哪个层级？哪些具体步骤能推进你到下一层？**
