跳转至

智能体工程的八个层级

概述

智能体工程的八个层级是一套面向从业者的进阶框架，描绘了从基础 AI 辅助编码到完全自主的多智能体团队的演进路径。该框架由 Bassim Eledath 于 2026 年 3 月提出，阐述了工程团队如何逐步采纳智能体 AI——每个层级都在下方已建立能力的基础上进一步延伸。

框架有一个关键架构洞察：第 3–5 层是第 6–8 层的先决条件。 若上下文噪声过多、提示词描述不清，或工具定义不完善，更高层次的自动化只会放大混乱，而非解决问题。

交叉参考：Contrast Security 的"8 levels of context maturity"网络研讨会呈现了一个结构上高度相似的进阶框架——同样分为三个区域，最终汇聚成一个规划/委派/评估/固化式的循环——但专门应用于安全上下文成熟度，而非通用工程实践。两套框架系独立开发，却不约而同地收敛到相同的三区域八层级结构，这表明该进阶模式（手动 → 上下文设计 → 自动化反馈 → 自主）可能具有跨领域的普遍性，并非 Eledath 框架所特有。

八个层级

第 1 层：Tab 补全

以 GitHub Copilot 为代表，这是 AI 辅助编码的入门点。AI 根据上下文在行内自动补全代码，属于被动建议模式——每次交互均由开发者发起。

第 2 层：Agent IDE

Cursor 等 AI 专属集成开发环境引入了与代码库深度整合的对话功能，支持跨文件编辑和更丰富的智能体交互，但仍属同步、以开发者为主导的模式。

第 3 层：上下文工程

这一层的核心转变是：从"使用 AI"转向"为 AI 而设计"。指导原则：每一个 Token 都必须在提示词中赢得自己的位置。

上下文工程的实践范畴包括： - 系统提示词：在会话开始时塑造智能体行为的指令 - 规则文件：CLAUDE.md、.cursorrules、AGENTS.md——固化到每个后续会话的约定规范 - 工具描述：引导模型在可用工具中做出正确选择的元数据 - 对话历史管理：控制哪些内容保留在上下文中，哪些应被淘汰

达到这一层的从业者会对输入给 LLM 的上下文保持高度敏感。当模型出错时，他们的第一反应是"缺少了哪些上下文？"而非质疑模型能力。

第 4 层：复利式工程

目标是让每个新功能都比上一个更容易实现——颠覆传统模式中技术债务让每个新功能越来越难的困境。

实现机制是一个四步循环：

  1. 规划（Plan） — 明确任务与预期产出
  2. 委派（Delegate） — 将任务交给智能体执行
  3. 评估（Assess） — 审查智能体的产出，识别错误与缺失的上下文
  4. 固化（Codify） — 更新规则文件（CLAUDE.md、hooks、slash commands），让经验教训作用于所有后续会话

由于 LLM 是无状态的，每次获得的经验必须显式记录。固化步骤正是让这一过程产生复利效应的关键——缺少它，智能体会在不同会话中反复犯同样的错误。维护良好的 CLAUDE.md 本质上是在积累组织记忆，并将其自动注入每个未来的会话。

第 5 层：MCP 与技能

模型上下文协议（MCP） 和可复用技能使团队能够跨上下文、跨贡献者共享智能体能力。例如，一个 PR 审查技能可以拆分为多个专项子智能体，分别检查不同的质量维度（安全、风格、性能、正确性），并根据变更集的性质有条件地触发。

在这一层，从业者中出现了一个日益明显的趋势：倾向于使用 CLI 工具而非 MCP 服务器，以提升 Token 效率。CLI 允许智能体执行有针对性的命令，并仅将相关输出注入上下文窗口；而 MCP 服务器注册会在每次调用时注入完整的工具定义。

第 6 层：运行框架工程与自动化反馈回路

这一层将第 3–5 层构建的一切付诸运营实践。高质量上下文、复利规则、强大工具以及自动化反馈回路，现在无需人工直接监督，由现有基础设施按需触发。

具体示例： - 文档机器人：在每次合并时重新生成文档，并发起 PR 将新发现的约定更新到 CLAUDE.md - 安全审查员：自主扫描 PR 并提交修复 PR - 依赖升级机器人：自动升级依赖包并运行完整测试套件，之后再请求人工确认

这一层的智能体运行框架（harness）包含前馈引导（告知智能体应做什么）和反馈传感器（验证智能体是否做对了）。完整的工程模式请参见运行框架工程。

第 7 层：后台智能体

编排者 LLM 以中心辐射模式将任务分发给工作者 LLM。智能体通宵工作，独立处理模糊情况，每天早晨呈现已完成的成果——"智能体在你入睡时提交 PR"。

架构模式：将本地后台智能体（适合短时任务）与云端沙箱智能体（适合长时、高自主性任务）配对使用。Ramp 的 Inspect 工具是该模式的参考实现：每个智能体会话在预装了完整开发环境的云端沙箱虚拟机中独立启动。

这是目前大多数工程团队应重点投入的层级。 工具已相当成熟，杠杆效益显著。

第 8 层：自主智能体团队

第 8 层打破了第 7 层中单一编排者的瓶颈。智能体之间直接协作：认领任务、共享发现、标记依赖关系、解决冲突，无需将所有事务路由至中央编排者。

Claude Code 的实验性 Agent Teams 功能是早期实现：多个 Claude Code 实例并行处理同一代码库，每个实例在各自的上下文窗口中运行，并直接与其他实例通信。

当前局限：作者评估认为，对于日常开发工作，大多数模型尚未准备好达到这一自主程度。即便模型能力足够，其速度之慢、Token 消耗之高，也使该模式在高价值的"登月"项目（编译器开发、浏览器构建、大规模重构等能充分发挥并行优势的场景）之外难以在经济上立足。

层级总览

层级 名称 模式 核心能力
1 Tab 补全 被动 行内代码建议
2 Agent IDE 交互 跨文件对话编辑
3 上下文工程 设计 提示词与规则优化
4 复利式工程 系统化 规划-委派-评估-固化循环
5 MCP 与技能 共享 可复用、可组合的智能体能力
6 运行框架工程 自动化 无需监督的反馈回路
7 后台智能体 自主 通宵作业，中心辐射式编排
8 自主智能体团队 实验性 智能体间直接协作

核心洞察

  • 第 3–5 层是基础。 LLM 在某些事情上出色，在另一些事情上则差强人意，且难以预测。团队必须先摸清这些边界，再在此之上叠加更多自动化。
  • 固化步骤是飞轮。 若不把经验教训显式记录到规则文件中，复利效应便无从产生——智能体每次会话都从零开始。
  • 上下文质量会被放大。 第 3 层埋下的问题，到第 6–8 层不会被解决，只会被放大：嘈杂的上下文在规模化场景下浪费 Token，产出不可靠的结果。
  • 第 7 层是当下的最佳点。 工具成熟、模式经过验证，对大多数工程团队而言杠杆效益高。
  • 第 8 层仍是研究前沿。 自主智能体间的协调协议、冲突解决机制以及共享状态管理，仍是尚未解决的开放问题。

最佳实践

所属层级 挑战 建议
第 3 层 系统提示词过于泛化 在规则文件中具体编码代码库约定、错误处理模式及命名规范
第 4 层 遗漏固化步骤 每次智能体会话结束前，更新 CLAUDE.md 记录本次所学，再关闭会话
第 4 层 智能体反复犯相同错误 错误重现时，找出缺失的上下文；不要轻易归因于模型能力不足
第 5 层 MCP Token 开销过高 Token 敏感的任务优先使用 CLI 工具；MCP 更适合有状态或结构化的集成场景
第 6 层 过早跳入自动化 在构建自动化反馈回路之前，务必充分验证第 3–5 层
第 7 层 单一本地智能体成为瓶颈 将本地智能体与云端沙箱智能体配对，应对长时任务
第 8 层 过早采纳 将第 8 层留给"登月"项目；典型工程工作用第 7 层经济效益更好

参见

参考资料