前言

随着 Agent 应用从单点工具调用走向复杂任务执行，Multi-Agent 逐渐成为很多团队关注的方向。相比单 Agent，Multi-Agent 的核心价值不只是“多个模型一起聊天”，而是通过角色分工、任务拆解、并行执行、交叉验证和结果汇总，提高复杂任务的完成质量和可维护性。
但 Multi-Agent 也很容易被过度设计。很多项目一开始就设计十几个 Agent，结果任务状态混乱、上下文传递失控、成本急剧上升，最后效果还不如一个单 Agent 加几个工具。
本文从工程落地角度，总结 Multi-Agent 开发的最佳实践，重点讨论以下问题：

• 什么场景真的需要 Multi-Agent？
• 如何设计主 Agent 和子 Agent？
• 多 Agent 如何拆任务、传上下文、同步状态？
• 如何避免 Agent 之间互相“空转聊天”？
• 如何做权限、安全、评估和上线治理？

---

一、先判断是否真的需要 Multi-Agent

Multi-Agent 不是默认选项，而是复杂任务发展到一定阶段后的架构选择。
很多场景用单 Agent 更合适：

• 用户请求很简单。
• 工具调用链路较短。
• 任务不需要并行处理。
• 不需要多个专业角色互相审查。
• 上下文规模不大，一个 Agent 能稳定处理。
  如果这些条件都满足，强行拆多个 Agent 只会增加复杂度。

1.1 适合 Multi-Agent 的场景

以下场景更适合使用 Multi-Agent：

场景	原因
任务可以自然拆分	例如调研、设计、开发、测试、文档分别由不同角色完成
多个子任务可以并行	可以降低整体耗时，提高吞吐
需要专家角色	不同 Agent 使用不同工具、知识库或评估标准
需要交叉验证	一个 Agent 生成结果，另一个 Agent 审查或测试
上下文过长	单 Agent 无法同时承载全部材料
权限需要隔离	不同 Agent 只能访问不同资源
任务生命周期较长	需要状态持久化、阶段推进和异步执行

1.2 不适合 Multi-Agent 的场景

以下场景不建议使用 Multi-Agent：

• 只是为了显得架构复杂。
• 子 Agent 没有清晰职责。
• 所有 Agent 都读同一份上下文、做同一件事。
• 没有状态管理和结果聚合机制。
• 没有评估指标，无法判断多 Agent 是否真的提升效果。
• 成本敏感但任务收益不明确。
  一句话：没有明确分工、状态和评估的 Multi-Agent，本质上只是多轮 Prompt 链。

---

二、Multi-Agent 的核心架构

一个可落地的 Multi-Agent 系统，通常包含以下几个部分：

┌──────────────────────────────────────┐
│              用户入口                 │
│ Web / 飞书 / API / CLI / 定时任务      │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│              主 Agent                 │
│ 意图理解 / 任务拆解 / 调度 / 汇总 / 风控 │
└───────┬──────────┬──────────┬────────┘
        │          │          │
┌───────▼───┐ ┌────▼────┐ ┌────▼────┐
│ 调研Agent │ │ 开发Agent│ │ 测试Agent│
└───────┬───┘ └────┬────┘ └────┬────┘
        │          │          │
┌───────▼──────────▼──────────▼────────┐
│            状态与记忆层               │
│ Task Store / Context Store / Memory   │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│            工具与执行环境             │
│ 搜索 / 文件 / 代码 / 浏览器 / 数据库 / API │
└──────────────────────────────────────┘

2.1 主 Agent 的职责

主 Agent 不应该亲自完成所有细节工作，而应该承担“项目经理 + 架构师 + 质量负责人”的角色。
主 Agent 的核心职责包括：

1. 理解用户目标。
2. 判断是否需要拆分任务。
3. 设计任务计划。
4. 选择合适的子 Agent。
5. 分发最小必要上下文。
6. 跟踪子任务状态。
7. 处理阻塞和异常。
8. 聚合结果。
9. 做最终质量检查。
10. 决定是否需要用户确认。

2.2 子 Agent 的职责

子 Agent 应该职责单一、边界明确。
常见子 Agent 类型：

Agent 类型	职责
调研 Agent	搜索资料、读取文档、整理事实依据
分析 Agent	提炼结构、发现问题、形成判断
规划 Agent	拆解方案、制定里程碑和执行路径
开发 Agent	编写代码、修改配置、实现功能
测试 Agent	写测试、运行测试、验证结果
审查 Agent	Code Review、文档审查、安全审查
文档 Agent	生成报告、PRD、教程、使用说明
运维 Agent	部署、监控、日志分析、故障排查

子 Agent 不应过度通用。越通用，越难评估；越具体，越容易优化。

三、任务拆解：Multi-Agent 的第一关键能力

Multi-Agent 系统的质量，很大程度取决于任务拆解质量。

3.1 推荐的任务拆解方式

主 Agent 拆任务时，应尽量把每个子任务定义为“可独立完成、可验证、可交付”的单元。
一个好的子任务应该包含：

• 背景。
• 目标。
• 输入材料。
• 输出要求。
• 约束条件。
• 验收标准。
• 是否依赖其他任务。
• 可使用的工具范围。
  示例：

任务：调研 LangGraph 与 AutoGen 的差异

背景：用户正在写一篇 Multi-Agent 框架选型文章。
目标：收集 LangGraph 与 AutoGen 的定位、核心机制、优缺点和适用场景。
输入：官方文档、GitHub README、近一年技术文章。
输出：一份结构化 Markdown 对比表。
约束：必须标明来源，不得使用无来源结论。
验收标准：至少包含 5 个对比维度，引用不少于 3 个可靠来源。

3.2 不好的任务拆解示例

你去研究一下 Multi-Agent。

这个任务太模糊，子 Agent 不知道：

• 研究范围是什么。
• 输出格式是什么。
• 需要多深。
• 以什么标准判断完成。
• 是否需要来源。
  模糊任务会导致子 Agent 产出不可控，主 Agent 也难以汇总。

3.3 拆解粒度控制

任务拆得太粗，子 Agent 容易跑偏；任务拆得太细，调度成本会过高。
建议粒度：

• 一个子任务最好能在 1 到 20 分钟内完成。
• 一个子任务只对应一个明确交付物。
• 一个子任务最多依赖 1 到 3 个上游结果。
• 子任务数量尽量控制在 3 到 8 个，除非是大型异步项目。

---

四、上下文传递：只传必要信息，不要广播全部上下文

Multi-Agent 最常见的问题之一，是每个 Agent 都拿到完整上下文，导致成本高、噪声多、责任不清晰。

4.1 最小闭环上下文原则

给子 Agent 的上下文应该满足“完成任务所需的最小闭环”。
包括：

1. 当前任务目标。
2. 必要背景。
3. 输入材料。
4. 输出格式。
5. 约束条件。
6. 验收标准。
7. 上游依赖结果。

不应该传：

1. 与任务无关的完整聊天记录。
2. 其他子 Agent 的内部推理过程。
3. 不必要的隐私数据。
4. 无关文件和日志。
5. 主 Agent 的全部系统提示词。

4.2 上下文传递格式

推荐使用结构化任务包：

{
  "task_id": "task-003",
  "role": "测试 Agent",
  "objective": "为用户登录接口补充单元测试",
  "background": "项目使用 FastAPI + Pytest",
  "inputs": [
    "登录接口文件路径：app/api/auth.py",
    "现有测试目录：tests/api/"
  ],
  "constraints": [
    "不得修改业务代码",
    "仅新增或修改测试文件"
  ],
  "expected_output": "测试文件路径、测试用例说明、测试运行结果",
  "validation": "pytest tests/api/test_auth.py 必须通过"
}

结构化任务包有利于：

• 降低歧义。
• 方便追踪状态。
• 方便失败重试。
• 方便审计和复盘。

---

五、状态管理：不要靠聊天记录管理项目

Multi-Agent 项目必须有独立的状态管理，而不是让状态散落在对话里。

5.1 任务状态模型

建议每个子任务都有明确状态：

Pending -> Dispatched -> InProgress -> Blocked / Success / Failed

状态含义：

状态	含义
Pending	已创建，等待调度
Dispatched	已分发给子 Agent
InProgress	正在执行
Blocked	遇到阻塞，需要主 Agent 或用户处理
Success	已完成并通过基本验证
Failed	任务失败，无法继续

5.2 子任务结果结构

子 Agent 完成任务时，不应该只回复一段自然语言，而应该输出结构化结果。
推荐格式：

{
  "task_id": "task-003",
  "status": "success",
  "summary": "已为登录接口补充 6 个单元测试",
  "outputs": [
    "tests/api/test_auth.py"
  ],
  "validation": {
    "command": "pytest tests/api/test_auth.py",
    "result": "passed"
  },
  "risks": [
    "未覆盖 OAuth 登录场景"
  ],
  "next_steps": [
    "如需覆盖 OAuth，需要补充 mock provider"
  ]
}

这样主 Agent 才能可靠地聚合结果。

5.3 状态存储位置

根据系统复杂度，可以选择：

• 简单任务：内存状态。
• 中等任务：本地 JSON / SQLite。
• 长周期项目：数据库任务表。
• 企业项目：工作流引擎或项目管理系统。
  只要任务超过一次对话，就建议持久化。

---

六、通信机制：Agent 之间不要自由闲聊

多 Agent 系统里，Agent 之间如果没有通信协议，很容易陷入低效对话。

6.1 推荐通信模式

更稳妥的方式是“中心化调度”：

子 Agent A -> 主 Agent -> 子 Agent B

而不是：

子 Agent A <-> 子 Agent B <-> 子 Agent C 自由聊天

中心化调度的好处：

• 主 Agent 能控制上下文。
• 任务依赖关系更清晰。
• 更容易审计。
• 更容易做权限隔离。
• 防止 Agent 间无限循环。

6.2 什么时候允许子 Agent 直接通信

只有在以下条件满足时，才建议允许子 Agent 直接通信：

• 通信协议明确。
• 有轮次上限。
• 有明确问题和回答格式。
• 有超时机制。
• 主 Agent 能看到通信记录。
• 不涉及高风险工具调用。

例如，开发 Agent 可以向测试 Agent 询问失败用例细节，但不应该直接让测试 Agent 修改生产配置。

6.3 避免无限循环

必须设置：

• 最大通信轮次。
• 最大工具调用次数。
• 最大执行时间。
• 最大 Token 预算。
• 阻塞上报机制。

如果超过限制，子 Agent 应停止并报告：

当前任务已达到最大重试次数，建议人工介入或重新拆解任务。

---

七、角色设计：少而精，比多而全更重要

一个常见误区是给系统设计大量角色：产品 Agent、研发 Agent、测试 Agent、架构 Agent、运营 Agent、增长 Agent、安全 Agent、数据 Agent、文档 Agent……
角色越多，协调成本越高。

7.1 从三个基础角色开始

大多数场景可以从三个角色开始：

1. 主 Agent负责理解目标、拆解任务、调度执行、汇总结果。
2. 执行 Agent负责具体执行，例如写代码、查资料、处理文件、调用工具。
3. 审查 Agent负责检查结果质量，例如测试、校验、事实核查、安全审查。
   这个组合已经能覆盖很多复杂任务。

7.2 按瓶颈增加角色

不要提前设计角色，而是根据实际瓶颈增加。
例如：

• 调研结果不可靠，再增加调研 Agent。
• 代码质量不稳定，再增加 Code Review Agent。
• 上线风险高，再增加安全审查 Agent。
• 文档质量差，再增加文档 Agent。

角色应该来自真实问题，而不是架构想象。

---

八、工具权限：不同 Agent 应有不同工具集

Multi-Agent 的一个重要价值，是权限隔离。
不要给所有 Agent 开全量工具。

8.1 工具权限示例

Agent	可用工具	禁止工具
调研 Agent	搜索、读文档、读网页	写文件、发消息、删数据
开发 Agent	读写代码、运行测试、查日志	直接部署、删除数据库
测试 Agent	运行测试、读取报告	修改核心业务代码
文档 Agent	读资料、写文档	执行 Shell、修改配置
运维 Agent	查日志、重启测试服务	未确认前操作生产环境
审查 Agent	读取产物、运行检查	直接修改被审查结果

8.2 权限分级

建议按风险分级：

权限级别	说明
Read	只读查询、搜索、读取文件
Draft	生成草稿、写临时文件
Write	修改工作区文件、创建任务
Execute	运行命令、调用外部 API
Publish	对外发送、发布、上线、删除

默认只给 Read 和 Draft。Write 以上权限必须按任务授权。Publish 类权限必须人工确认。

---

九、结果聚合：主 Agent 不是简单拼接答案

多个子 Agent 的结果不能简单合并。主 Agent 必须做判断和整合。

9.1 聚合时要处理的问题

主 Agent 需要检查：

• 子任务是否都完成。
• 输出是否符合格式。
• 不同子 Agent 结论是否冲突。
• 是否有缺失部分。
• 是否有未经验证的假设。
• 是否存在安全风险。
• 是否需要用户补充信息。

9.2 冲突处理

如果两个子 Agent 结论冲突，主 Agent 不应该随便选一个，而应：

1. 标记冲突点。
2. 检查来源和证据。
3. 必要时派发复核任务。
4. 在最终结果中说明不确定性。
   例如：

调研 Agent 认为方案 A 成本更低，但分析 Agent 认为方案 B 运维风险更小。
经复核，方案 A 的成本优势成立，但依赖第三方服务，稳定性风险更高。
建议短期采用方案 B，长期评估方案 A。

9.3 最终输出结构

推荐最终输出包含：

• 结论。
• 关键依据。
• 已完成事项。
• 未完成事项。
• 风险和限制。
• 下一步建议。
• 附件或产物链接。

---

十、评估体系：证明 Multi-Agent 真的有用

Multi-Agent 成本更高，因此必须证明它带来了收益。

10.1 核心指标

建议跟踪：

指标	说明
任务完成率	用户目标是否完成
一次成功率	是否首次执行成功
平均完成时间	多 Agent 是否提升效率
成本	Token、工具调用、计算资源
子任务失败率	哪类 Agent 最容易失败
人工接管率	是否仍需频繁人工介入
结果一致性	多次执行是否稳定
用户满意度	用户是否认可交付质量

10.2 与单 Agent 做 A/B 对比

不要只看 Multi-Agent 自己的表现。应该和单 Agent 做对比：

• 同样任务，单 Agent 完成质量如何？
• Multi-Agent 是否更快？
• 是否更准确？
• 是否更贵？
• 贵出来的成本是否值得？
  如果 Multi-Agent 只是更复杂但没有提升，就应该回退到单 Agent。

10.3 建立基准任务集

建议准备一组标准任务：

• 调研类任务。
• 代码开发类任务。
• 数据分析类任务。
• 文档生成类任务。
• 故障排查类任务。
• 多步骤工作流任务。
• 高风险权限任务。

每次调整 Agent 角色、Prompt、工具或模型，都要跑回归测试。

---

十一、安全治理：Multi-Agent 风险会被放大

Multi-Agent 系统中，风险不是简单相加，而可能被放大。

11.1 常见风险

风险	说明
权限扩散	子 Agent 获得了不必要的工具权限
上下文泄漏	一个 Agent 收到了不该看的数据
错误传染	上游错误被下游继续放大
循环执行	Agent 之间互相触发，无法停止
成本失控	多个 Agent 并行调用模型和工具
责任不清	不知道最终错误来自哪个 Agent
自动化误操作	多个 Agent 协作执行了高风险动作

11.2 安全策略

必须落实：

• 最小权限。
• 工具白名单。
• 高风险动作人工确认。
• 会话隔离。
• 子任务超时。
• 最大重试次数。
• 审计日志。
• 产物校验。
• 敏感信息脱敏。
• 外部内容不作为系统指令。

11.3 高风险动作统一由主 Agent 审批

子 Agent 不应直接执行高风险动作。正确流程：

子 Agent 提出操作建议
  ↓
主 Agent 评估风险
  ↓
需要时询问用户确认
  ↓
授权后执行
  ↓
记录审计日志

例如：部署、删除、发消息、付款、修改权限，都应走这个流程。

---

十二、成本控制：Multi-Agent 必须有预算意识

Multi-Agent 系统很容易成本失控。

12.1 成本来源

主要成本包括：

• 多个 Agent 的模型调用。
• 上下文重复传递。
• 工具调用费用。
• 搜索和浏览器操作。
• 代码执行和容器资源。
• 长周期任务的后台运行。

12.2 控制策略

建议：

1. 优先使用小模型处理简单子任务。
2. 只有关键任务使用强模型。
3. 子 Agent 不要共享完整上下文。
4. 对搜索、浏览器、代码执行设置调用上限。
5. 任务失败后先分析原因，不要盲目重试。
6. 对长任务设置预算。
7. 对低价值任务直接拒绝或简化执行。

12.3 模型分层

可以采用模型分层策略：

任务类型	推荐模型
分类、路由、格式转换	小模型
简单摘要、信息提取	中等模型
复杂规划、代码生成、综合判断	强模型
审查和安全判断	强模型或规则加模型

不是所有 Agent 都需要最强模型。

---

十三、常见架构模式

13.1 Manager-Worker 模式

最常见、最稳妥。

Manager Agent
  ├── Worker Agent A
  ├── Worker Agent B
  └── Worker Agent C

适合：

• 任务拆解明确。
• 子任务可以并行。
• 主 Agent 负责最终汇总。

13.2 Planner-Executor-Reviewer 模式

适合复杂交付任务。

Planner Agent -> Executor Agent -> Reviewer Agent -> Final Answer

优点：

• 规划和执行分离。
• 审查环节能提高质量。
• 适合代码、报告、方案设计。

13.3 Debate 模式

多个 Agent 从不同角度提出观点，再由裁判 Agent 汇总。
适合：

• 方案选型。
• 风险评估。
• 战略分析。
• 多观点讨论。
  注意：Debate 模式成本高，且容易空转，必须有轮次限制。

13.4 Pipeline 模式

任务按阶段流转。

输入解析 -> 检索 -> 分析 -> 生成 -> 审查 -> 发布

适合：

• 文档生成。
• 数据处理。
• 内容生产。
• 标准化工作流。

13.5 Swarm 模式

多个 Agent 自主领取任务，适合大规模并行。
适合：

• 批量数据处理。
• 大规模测试。
• 多文件代码改造。

但 Swarm 模式治理难度最高，必须有强状态管理和任务队列。

---

十四、推荐落地流程

阶段一：单 Agent 验证

先用一个 Agent 验证任务是否可行。
重点：

• 明确用户目标。
• 明确工具需求。
• 跑通基础流程。
• 建立最小测试集。

阶段二：引入审查 Agent

当单 Agent 能完成任务后，先增加 Reviewer，而不是马上拆很多 Worker。
重点：

• 检查事实准确性。
• 检查代码质量。
• 检查安全风险。
• 检查输出格式。

阶段三：拆分执行 Agent

当任务复杂度提升后，再拆执行角色。
例如：

• 调研 Agent。
• 开发 Agent。
• 测试 Agent。
• 文档 Agent。

阶段四：引入异步任务和状态管理

当任务周期变长时，引入：

• Task Store。
• 状态机。
• 队列。
• 超时处理。
• 审计日志。

阶段五：生产化治理

最后补齐：

• 权限体系。
• 成本控制。
• 监控指标。
• 测试集。
• 回归评估。
• 人工接管机制。

---

十五、Multi-Agent 开发检查清单

15.1 任务设计

• 是否真的需要 Multi-Agent？
• 是否有明确主 Agent？
• 子 Agent 职责是否清晰？
• 子任务是否可独立完成？
• 子任务是否有验收标准？

15.2 上下文与状态

• 是否采用最小闭环上下文？
• 是否避免广播完整上下文？
• 是否有任务状态机？
• 是否持久化长周期任务？
• 是否记录子任务输入输出？

15.3 工具与权限

• 不同 Agent 是否有不同工具权限？
• 是否遵守最小权限原则？
• 高风险工具是否需要主 Agent 审批？
• 是否有工具调用日志？
• 是否能回滚或恢复？

15.4 通信与调度

• Agent 之间是否有通信协议？
• 是否限制通信轮次？
• 是否有超时机制？
• 是否避免无限循环？
• 是否支持阻塞上报？

15.5 评估与成本

• 是否与单 Agent 做对比？
• 是否记录任务完成率？
• 是否记录成本？
• 是否有回归测试集？
• 是否定期复盘失败任务？

---

十六、一个推荐的 Multi-Agent 开发范式

明确任务目标
  ↓
判断是否需要 Multi-Agent
  ↓
设计主 Agent 职责
  ↓
拆分少量高价值子 Agent
  ↓
定义任务包格式
  ↓
定义状态机
  ↓
配置工具权限
  ↓
加入 Reviewer 审查环节
  ↓
建立日志与评估指标
  ↓
灰度上线
  ↓
根据失败案例迭代角色、工具和流程

核心原则：

1. 从单 Agent 开始。
2. 优先增加审查，而不是增加角色数量。
3. 子 Agent 要职责单一。
4. 任务状态必须可追踪。
5. 上下文必须最小化。
6. 高风险动作必须统一审批。
7. Multi-Agent 必须证明比单 Agent 更好。

---

十七、总结

Multi-Agent 的价值，不在于“有多少个 Agent”，而在于是否能把复杂任务拆解成清晰、可执行、可验证的协作流程。
一个好的 Multi-Agent 系统应该具备以下特点：

1. 主从清晰：主 Agent 负责目标、调度和汇总，子 Agent 负责专业执行。
2. 任务明确：每个子任务都有输入、输出、约束和验收标准。
3. 上下文克制：只传完成任务所需的信息。
4. 状态可追踪：每个任务都有状态、结果和日志。
5. 权限隔离：不同 Agent 使用不同工具权限。
6. 结果可验证：通过 Reviewer、测试、来源引用或规则校验保证质量。
7. 成本可控制：限制轮次、工具调用、模型级别和执行时间。
8. 安全可治理：高风险动作必须人工确认，所有关键动作可审计。

Multi-Agent 不是单 Agent 的简单复制，而是一套面向复杂任务的组织方式。它更像软件工程里的团队协作：有人规划，有人执行，有人审查，有人交付。只有当角色、流程、状态和责任都设计清楚时，Multi-Agent 才能真正提升复杂任务的完成质量。