你用 AI 写代码很快。但你知道它为什么这么做吗？

如果你的答案是"不知道"，你可能在用 Vibe Coding——靠感觉驱动的 AI 编程。上一篇文章《停止「氛围编程」：AI 时代的工程师分水岭》说清楚了这个问题：AI 在用你，不是你在用 AI。

这篇文章回答"怎么做"。它给你一个清晰的能力成长框架——从 ReAct（Level 1）到 Skills 模块化（Level 2）到 Supervisor 编排（Level 3）到 MCP 集成（Level 4）。每个 Level 对应一个可复用的 Agent 设计模式。

你只需要知道：Agent 工程不是玄学，是工程。这四个模式覆盖了从单 Agent 到多 Agent 的完整能力谱系。

---

导读：四段位模型

你的 Agent 工程能力在哪个段位？

段位	核心能力	典型场景
Level 1	ReAct——让 Agent "先想再做"	简单任务，需要调用工具
Level 2	Skills——把能力打包成"乐高积木"	复杂任务，需要复用能力
Level 3	Supervisor——让多个 Agent 协作	超复杂任务，单 Agent 撑不住
Level 4	MCP——让 Agent 接入真实世界	生产环境，需要安全集成

阅读路径：

• 如果你是新手，从头读到尾
• 如果你已经了解 ReAct，跳到 Level 2 开始
• 如果你只想知道 MCP 是什么，直接看 Level 4

---

一、你的 Agent 在哪个段位？

先做一个自测。

你遇到过这些问题吗？

•  Agent 开始胡扯，你不知道它为什么这么做
•  同样的任务，每次都要重新写一遍提示词
•  Agent 调用了错误的工具，但你看不到它怎么决定的
•  多个 Agent 同时工作，结果互相打架
•  Agent 能跑 demo，但接入生产环境就炸

评分规则：勾选 0-1 个 → Level 1；2-3 个 → Level 2；4-5 个 → Level 3 或 Level 4。

下一步：无论你在哪个 Level，都从 Level 1 开始读——理解基础模式，才能用好高级模式。

这个自测不是精确的能力评估，但它指向一个事实：Agent 工程是有段位的。

能力进阶框架

上一篇《停止「氛围编程」》讲了三个核心能力：上下文工程、测试设计、Agent 编排。这篇文章把"Agent 编排"展开成四个进阶阶段：

Level 1: ReAct（最小执行单元）
    ↓ 学会拆任务、调工具
Level 2: Skills（能力模块化）
    ↓ 学会复用、组合
Level 3: Supervisor（多 Agent 编排）
    ↓ 学会协调、分工
Level 4: MCP（真实世界集成）
    ↓ 学会安全、生产化

每个 Level 解决上一 Level 遗留的问题，同时暴露新的问题。这不是"升级打怪"，是"爬楼梯"——每上一层，你能解决的问题变多，但需要的能力也变强。

你只需要知道：Agent 工程是进阶游戏。你不是"会不会"的问题，是"在哪一阶"的问题。

---

二、Level 1：ReAct——Agent 的最小执行单元

你可能遇到的问题是：Agent 开始胡扯，你不知道它为什么这么做。

ReAct 模式解决这个问题。

什么是 ReAct？

ReAct（Reasoning + Acting）——先想，再做，看结果，再想……循环直到问题解决。

它的核心很简单：

Think（思考）→ Act（行动）→ Observe（观察）→ Think ...

一个例子

想象你要让 Agent 查一下北京今天的天气，然后判断是否适合户外活动。

没有 ReAct 的 Agent：

"北京今天天气不错，适合户外活动。"

你不知道它怎么知道的——可能是猜的，可能是训练数据里的旧信息。

有 ReAct 的 Agent：

1. Think：用户问北京天气和户外建议。我需要先查天气，再给建议。
2. Act：调用 weatherAPI.getWeather("北京")
3. Observe：返回 {"city": "北京", "temp": "25°C", "condition": "晴"}
4. Think：北京今天晴，25度。这个温度适合户外。我可以回答了。
5. Answer：北京今天晴，25度，适合户外活动。

区别在哪？你能看到每一步。像看侦探破案，不像看巫师施法。

核心组件

ReAct 不是魔法，是五个组件的协作：

组件	作用
LLM	负责推理和决策
Tool Calling	定义 Agent 能调用什么工具
Action Parser	解析 LLM 输出的行动指令
Observation Handler	执行工具，返回结果
Loop Controller	防止无限循环

Loop Controller 很关键。如果 Agent 一直在 Think→Act→Observe 循环里出不来，Loop Controller 会强制停止。这就像熔断器——保护系统不会因为一个死循环而崩溃。

优缺点

优点	缺点
✅ 减少幻觉——基于真实工具返回	❌ 多步推理增加响应时间
✅ 可解释——能看到思考过程	❌ 依赖工具质量——工具烂，答案就烂
✅ 可调试——能定位哪一步出错	❌ 上下文容易爆炸——每轮循环都在累积
✅ 支持工具扩展

适用场景

适合用 ReAct 的场景：

• 需要调用外部工具（搜索、API、数据库）
• 任务可以拆成多个步骤
• 你需要知道 Agent 的决策过程

不适合用 ReAct 的场景：

• 简单问答，不需要工具
• 任务无法拆解
• 对响应时间极其敏感

案例：API 故障排查（Level 1 版本）

假设你要让 Agent 排查一个 API 故障。

Think: API 返回 500 错误，需要查日志找原因。
Act: 调用 logQuery("api-server", "error")
Observe: 返回 500 条错误日志
Think: 日志太多，需要过滤关键信息。
Act: 调用 logFilter("timeout")
Observe: 返回 12 条超时相关日志
Think: 找到原因——数据库连接超时。可以报告了。
Answer: 故障原因是数据库连接超时，建议检查数据库连接池配置。

问题来了：这个 Agent 只能做"排查故障"。如果你下次想让 它做"代码审查"，就得重新写一遍提示词。

这就是 Level 1 的局限——能力混杂，难以复用。

你只需要知道：ReAct 是 Agent 的最小执行单元。它让 Agent 从"瞎猜"变成"有据可依"。但当任务变复杂，你需要把能力拆开——那是 Level 2 的事。

---

三、Level 2：Skills——从"一坨提示词"到"能力包"

你可能遇到的问题是：同样的任务，每次都要重新写一遍提示词。

Skills 模块化解决这个问题。

什么是 Skills？

Skills——Agent 的可复用能力包。每个 Skill 有独立的定义文件（通常是 SKILL.md），描述这个能力做什么、怎么用、依赖什么。

类比一下：Skills 就像乐高积木。你可以把多个 Skill 组合起来，搭建复杂的 Agent 系统。

SKILL.md 的结构

一个典型的 SKILL.md 包含：

# Skill: 日志查询

## 功能
从指定服务查询日志，支持关键词过滤。

## 输入
- service: 服务名称（必填）
- keyword: 过滤关键词（可选）
- time_range: 时间范围（可选，默认 1 小时）

## 输出
- 日志条目列表（JSON 格式）

## 依赖
- 需要访问日志系统的 API 权限

## 示例
调用: queryLogs(service="api-server", keyword="error")
返回: [{"timestamp": "...", "level": "ERROR", "message": "..."}]

注意：SKILL.md 不是代码文件，是 Agent 能力的"说明书"。Agent 读取这个文件后，就知道自己能做什么、怎么做。

Skills 与 ReAct 的关系：Skills 是 ReAct 的"能力包化"。ReAct Agent 在 Act 阶段调用工具，Skills 把这些工具调用封装成可复用的模块。一个 ReAct Agent 可以调用多个 Skills。

维度	一坨提示词	Skills 模块化
复用性	每次重写	一次定义，到处调用
可测试性	难以单独测试	每个 Skill 可独立测试
可维护性	改一处牵一坨	改一个 Skill 不影响其他
可组合性	难以组合	像乐高一样拼装

案例：API 故障排查（Level 2 版本）

回到故障排查的例子。Level 1 是一个大 Agent，Level 2 可以拆成三个 Skills：

Skills:
├── log-query/        # 日志查询
│   └── SKILL.md
├── log-analyzer/     # 日志分析
│   └── SKILL.md
└── report-generator/ # 报告生成
    └── SKILL.md

Agent 的工作流程变成：

1. 调用 log-query 获取日志
2. 调用 log-analyzer 分析根因
3. 调用 report-generator 生成报告

好处：

• log-query 可以被其他 Agent 复用（比如监控 Agent）
• 每个 Skill 可以独立测试
• 新增能力只需新增 Skill

反模式警示

❌ 不要把 Skills 当成函数库

Skills 不是代码层面的函数。它是 Agent 能力的抽象。一个 Skill 可能调用多个函数，也可能调用外部 API。

❌ 不要过度拆分

一个 Skill 应该完成一个完整的能力单元。如果你发现"调用 Skill A → 立即调用 Skill B → 立即调用 Skill C"是固定模式，那 A+B+C 可能应该是一个 Skill。

适用场景

适合用 Skills 的场景：

• 多个 Agent 需要复用同一能力
• 能力边界清晰，可以独立测试
• 团队协作，不同人负责不同能力

不适合用 Skills 的场景：

• 一次性任务，不需要复用
• 能力太简单，拆分反而增加复杂度

Level 1 → Level 2 的进阶信号

• 你发现自己在重复写类似的提示词
• 你需要把一个复杂 Agent 拆成多个可组合的部分
• 多个 Agent 需要共享同一套能力

你只需要知道：Skills 把"一坨提示词"变成"能力包"。它解决了复用问题。但当任务更复杂，一个 Agent（即使有多个 Skills）仍可能撑不住——那是 Level 3 的事。

---

四、Level 3：Supervisor——当单 Agent 不够用

你可能遇到的问题是：多个 Agent 同时工作，结果互相打架。

Supervisor 模式解决这个问题。

什么是 Supervisor？

Supervisor——一个"经理 Agent"管理多个"员工 Agent"。经理负责分配任务、协调进度、汇总结果；员工负责执行具体任务。

类比一下：Supervisor 就像项目经理，Sub-Agent 就像团队成员。

为什么需要 Supervisor？

单 Agent（即使有很多 Skills）有两个致命问题：

1. 上下文爆炸：任务越复杂，Agent 需要记住的信息越多，最终超出上下文窗口
2. 职责混乱：一个 Agent 既要做日志查询，又要做分析，还要生成报告，容易出现"左手打右手"

Supervisor 通过"分而治之"解决这两个问题。

Supervisor 架构

四大组件

每个 Agent（包括 Supervisor）都有四个组件：

组件	作用	Supervisor 特殊职责
Profile	定义角色、权限	决定谁是经理，谁是员工
Planning	分解任务	Supervisor 负责全局规划
Memory	记忆系统	Supervisor 维护共享状态
Action	调用工具	Supervisor 调用 Sub-Agent

Memory 是最难设计的部分。它分三层：

• 短期记忆：当前对话上下文
• 长期记忆：历史经验（通常用向量数据库）
• 共享状态：多个 Agent 之间传递的"黑板"

四大组件如何协作：Profile 定义"我是谁"，Planning 决定"做什么"，Memory 记住"发生了什么"，Action 执行"怎么做"。Supervisor 的 Profile 是"协调者"，它的 Action 是"调用 Sub-Agent"；Sub-Agent 的 Profile 是"执行者"，它的 Action 是"调用工具"。

三种协作模式

Supervisor 是"层级流"，但 Multi-Agent 还有其他协作模式：

模式	结构	适用场景
顺序流	A → B → C → D	流水线式任务（分析→设计→编码→测试）
层级流	Supervisor → Sub-Agents	需要统一调度的复杂任务
协作/辩论	Agent ↔ Agent	需要多角度验证的决策（代码审查）

案例：API 故障排查（Level 3 版本）

Level 2 还是单 Agent 调用多个 Skills。Level 3 变成多 Agent 协作：

Supervisor Agent
├── 日志查询 Agent（只负责查询）
├── 日志分析 Agent（只负责分析）
└── 报告生成 Agent（只负责写报告）

工作流程：

1. Supervisor 接收任务："排查 API 故障"
2. Supervisor 分解：先查日志，再分析，最后生成报告
3. Supervisor 分配任务给"日志查询 Agent"
4. 日志查询 Agent 汇报结果
5. Supervisor 把结果传给"日志分析 Agent"
6. 日志分析 Agent 汇报根因
7. Supervisor 把结果传给"报告生成 Agent"
8. 报告生成 Agent 汇报最终报告

好处：

• 每个 Agent 职责单一，更容易调试
• Supervisor 维护全局视角，不会"左手打右手"
• 可以并行执行（比如同时查多个服务的日志）

反模式警示

❌ 不要让 Supervisor 成为瓶颈

如果所有决策都必须经过 Supervisor，系统会变慢。给 Sub-Agent 足够的自主权，让它们能独立处理常规问题。

❌ 不要过度分层

Supervisor → Sub-Agent 是一层。有人会搞 Supervisor → Sub-Supervisor → Sub-Agent，这是找麻烦。层级越多，调试越难。

框架选型

如果你要用框架实现 Supervisor 模式：

框架	特点	适合
LangGraph	状态机 + 循环图，控制粒度最细	需要复杂条件判断和回滚
AutoGen	对话式，快速上手	快速原型验证
CrewAI	角色扮演，SOP 流程	有标准化流程的场景
MetaGPT	SOP 硬编码（PM/架构师/工程师）	软件开发流水线

Level 2 → Level 3 的进阶信号

• 单 Agent 的上下文经常爆炸
• 你需要多个 Agent 并行工作
• 不同能力需要不同的"人设"和权限

你只需要知道：Supervisor 让多个 Agent 协作。它解决了单 Agent 的上下文爆炸和职责混乱问题。但 Agent 还在"沙盒"里——要接入真实世界的工具和数据，需要 Level 4。

---

五、Level 4：MCP——让 Agent 接入真实世界

你可能遇到的问题是：Agent 能跑 demo，但接入生产环境就炸。

MCP 协议解决这个问题。

什么是 MCP？

MCP（Model Context Protocol）——Agent 工具连接的标准化协议。

类比一下：MCP 是 AI 工具的"USB-C 接口"。以前每个 AI 工具要连接数据库、API、文件系统，都要单独写代码。现在有了 MCP，就像所有电器都有统一的插头——一次开发，到处能用。

MCP 核心概念

概念	作用
MCP Server	提供能力的轻量级服务（如"连接 PostgreSQL"）
MCP Client	AI 应用内的通信中介，负责协议协商
Tool	Server 暴露的可调用功能（如"执行 SQL 查询"）
Resource	Server 暴露的可读数据（如"数据库表结构"）

MCP 对 Agent 工程的意义

MCP 对 Agent 工程的意义，类似于 REST 对 Web API 的意义——不是唯一方案，但正在成为事实标准。—— Simon Willison

在 MCP 之前，如果你想让 Agent 连接 PostgreSQL、Google Drive、Slack，你需要为每个服务写专门的集成代码。MCP 之后，你只需要一个 MCP Client，就能连接所有支持 MCP 的服务。

MCP 架构

核心组件

组件	作用
MCP Host	AI 应用（如 Claude Desktop、Cursor）
MCP Client	Host 内的通信中介，负责协议协商
MCP Server	提供具体功能的轻量级服务（数据库、API）

通信基于 JSON-RPC 2.0，支持本地和远程资源。

谁在用 MCP？

公司	用途	来源
Anthropic	协议开发方	官方
OpenAI	2025 年 4 月宣布支持	IT之家报道
Google DeepMind	Gemini 支持 MCP（2025 年 4 月）	IT之家报道
百度	Create2025 发布电商交易 MCP、搜索 MCP	今日头条
支付宝	支付 MCP Server（2025 年 4 月）	搜狐

2025 年 12 月，Linux 基金会正式接管 MCP，成立 Agentic AI Foundation (AAIF) 管理。这意味着 MCP 从"Anthropic 的协议"变成了"行业标准"。

生产案例

Liftoff Mobile：用 MCP 自动化 JIRA ticket 生成 + Grafana 报告。工程师不用手动填工单，Agent 自动拉取监控数据，生成报告，创建 JIRA ticket。

Telefónica：用 MCP 实现智能路由。Agent 根据负载自动决定用 GPU 还是 CPU 跑推理，降低成本。

安全考量

MCP 的安全设计有一个亮点：安全层和解耦。

Agent 不直接连接外部服务，而是通过 MCP Server。你可以：

• 在 MCP Server 上加网关，实现 OAuth/JWT/SPIFFE 鉴权
• Agent 代码不需要改，安全策略在 Server 端统一管理
• 不同的 Agent 可以有不同的访问权限

案例：API 故障排查（Level 4 版本）

Level 3 的 Agent 还在"沙盒"里调用模拟工具。Level 4 接入真实世界：

Supervisor Agent
├── 日志查询 Agent → MCP Server: Kubernetes API
├── 日志分析 Agent → MCP Server: Prometheus/Grafana
└── 报告生成 Agent → MCP Server: JIRA/Slack

工作流程：

1. 日志查询 Agent 通过 MCP 调用 Kubernetes API，获取真实日志
2. 日志分析 Agent 通过 MCP 查询 Grafana，获取相关指标
3. 报告生成 Agent 通过 MCP 创建 JIRA ticket，自动分配给相关负责人

安全处理：

• Agent 不需要知道数据库密码——MCP Server 负责认证
• 不同的 Agent 有不同的权限——只读 vs 读写
• 所有调用都有审计日志

反模式警示

❌ 不要跳过安全设计

MCP 让接入变得容易，但不意味着你可以忽略安全。Agent 有权限调用真实系统，权限设计必须谨慎。

❌ 不要假设 MCP 已经稳定

MCP 仍在快速演进。不同厂商的实现可能有兼容性差异。在生产环境使用前，做好测试。

Level 3 → Level 4 的进阶信号

• 你需要让 Agent 接入真实的生产系统
• 你需要统一管理 Agent 的访问权限
• 你需要审计 Agent 的所有操作

你只需要知道：MCP 让 Agent 从"沙盒"进入"真实世界"。它解决了集成问题，也带来了安全考量。Agent 工程的终极目标，是让 Agent 安全、可靠地在生产环境中工作。

---

六、选型决策树

四个 Level，四种模式。什么场景用什么模式？

决策树

模式对比总表

维度	ReAct	Skills	Supervisor	MCP
复杂度	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
复用性	❌	✅	✅	✅
可调试性	✅	✅	⚠️	⚠️
生产就绪	❌	❌	⚠️	✅
需要安全设计	❌	❌	⚠️	✅
典型场景	简单任务	能力复用	复杂协作	生产集成

常见错误

❌ 一上来就用 Supervisor

很多人觉得"多 Agent 听起来更高级"。但 Supervisor 增加了复杂度——你需要设计通信、状态管理、错误处理。如果 ReAct 就能解决，不要用 Supervisor。

❌ 跳过 Skills 直接上 MCP

MCP 解决的是"集成"问题，不是"能力"问题。如果你连 Skills 都没想清楚，MCP 只是让你更乱地接入更多工具。

✅ 正确的进阶路径

1. 先用 ReAct 验证任务可行性
2. 能力稳定后，拆成 Skills
3. 任务变复杂，引入 Supervisor
4. 需要生产化，接入 MCP

你只需要知道：模式没有高下之分，只有适合与否。从最简单的开始，逐步进阶。

---

七、结语：你在哪一阶？

回到开头的问题：你的 Agent 工程能力在哪个段位？

如果你还在 Vibe Coding——靠感觉驱动 AI 编程——那么 ReAct 是你的起点。它让 Agent 从"瞎猜"变成"有据可依"。

如果你已经在用 ReAct，但发现能力难以复用——Skills 是你的下一步。它让 Agent 的能力变成可组合的"乐高积木"。

如果你已经在用 Skills，但发现单 Agent 撑不住——Supervisor 是你的进阶方向。它让多个 Agent 协作，解决复杂问题。

如果你已经能搭建 Multi-Agent 系统，但要接入生产环境——MCP 是你的最后一公里。它让 Agent 安全地连接真实世界。

学习路径建议

当前阶段	下一步行动
Vibe Coding	用 ReAct 重写一个你常用的 Agent
ReAct 熟练	把一个复杂 Agent 拆成 2-3 个 Skills
Skills 熟练	用 LangGraph 或 AutoGen 搭建一个 Supervisor 系统
Supervisor 熟练	给你的系统接入一个 MCP Server（如 PostgreSQL）

Agent 工程不是终点，是手段。目标是让 AI 成为你可靠的助手，而不是一个你永远搞不懂的黑箱。

从今天开始，给你的 Agent 一个清晰的"工作流程"——用 ReAct，用 Skills，用 Supervisor，用 MCP。

不要只问"AI 能做什么"。问"AI 怎么可靠地做"。

---

本文是"AI 时代工程师进化"系列的第二篇。上一篇：《停止「氛围编程」：AI 时代的工程师分水岭》。下一篇将探讨 AI 对开源生态的影响——《AI 重塑开源：当 Coding Agent 接管 GitHub》。