Multi-Agent 原理与应用：从协作模式到生产系统设计

日期：2026-10-30 · 主题：AI Agent、多 Agent 编排、系统设计

当一个 AI Agent 需要完成复杂任务时，常见问题不是它完全不会做，而是任务中存在太多不同类型的工作：它需要查资料、理解业务、调用工具、核对数据、写结论，还要在有限上下文和时间内保持整个过程一致。

一种自然的想法是把工作分给多个 Agent：研究 Agent 查资料，数据 Agent 获取数据，分析 Agent 解释结果，审查 Agent 寻找错误，主 Agent 整理结论。

但仅仅创建五个角色，不会自动得到一个可靠的系统。它们可能重复检索、互相传递错误、竞争同一个文件，甚至同时执行同一笔有副作用的操作。

理解 Multi-Agent 的关键，是把它看成一个需要任务分解、状态管理、通信协议、权限控制、故障恢复和结果验证的协作系统。

本文覆盖常见原理、编排模式和应用场景。示例架构与运行数据均为教学设计，不能视为已经实现的产品能力；具体框架和接口以各自文档为准。Multi-Agent 仍在快速发展，“所有场景”无法被一份清单穷尽，本文重点覆盖软件研发、信息工作与业务系统中的主要类型。

一、从一个问题理解 Multi-Agent

假设用户提出：

分析一次线上订单量下降：找出可能原因，检查最近发布、支付渠道和系统错误，并给出有证据的结论。

单 Agent 可以逐项执行：

检查发布记录 → 查询支付指标 → 查看错误日志 → 整理结果

如果这些调查可以独立进行，系统也可以分配给多个 Agent：

主 Agent
  ├── 发布调查 Agent：检查部署与配置变化
  ├── 支付调查 Agent：查看渠道成功率与异常
  ├── 日志调查 Agent：检查错误和请求量
  └── 汇总与审查：比较时间线、证据与相互矛盾的发现

各 Agent 并行调查后，主 Agent 汇总结果。

但它不能简单地说：“三个 Agent 都认为是支付问题，所以支付一定是根因。”因为三个 Agent 可能引用同一条错误日志，也可能都在重复最初的错误假设。最终结论需要回到原始证据、时间关系和未排除的其他解释。

Multi-Agent 的价值，是组织多个有边界的工作过程；系统是否可靠，取决于任务、证据和决策怎样被协调。

二、Agent、Agent Loop 和 Multi-Agent 分别是什么？

单个 Agent

可以把一个 Agent 粗略理解为：

模型 + 指令 + 可用工具 + 运行状态

它根据当前信息选择回答或调用工具，再读取结果并决定下一步。

Agent Loop

接收任务
→ 模型生成下一步
→ 运行时检查并执行工具
→ 获取观察结果
→ 更新上下文
→ 继续或结束

一个 Agent 可以调用很多工具，并不因此自动成为 Multi-Agent。计算器、数据库查询和文件搜索即使有多个，仍然可能由同一个 Agent Loop 管理。

Multi-Agent

Multi-Agent 增加了多个相对独立的工作单元，以及它们之间的协调机制：

多个 Agent Loop
+ 任务分配
+ 状态与消息交换
+ 控制权规则
+ 结果合并
+ 权限和停止条件

这些 Agent 可以使用同一个模型，也可以使用不同模型；可以共享同一个运行时，也可以由不同服务承载。决定它是不是多 Agent 的关键，不是模型厂商数量，而是系统是否存在多个独立的任务执行与协调单元。

关于单个循环如何处理工具调用和状态，可参考：理解 Agent Loop。

三、为什么要用多个 Agent？

1. 分离职责

一个 Agent 负责理解客户问题，另一个只负责查询订单，还有一个专门负责售后规则。每个 Agent 可以拥有不同指令、工具和输出格式。

这有助于减少一个巨大提示词中不相关规则互相干扰，但也会增加交接成本。

2. 并行探索

发布记录、渠道指标和日志可以同时调查。若任务没有依赖，多个 Agent 有机会缩短等待时间。

顺序执行：
准备 10 秒 + 三项调查各 20 秒 + 汇总 10 秒 = 80 秒

理想并行：
准备 10 秒 + 最慢调查 20 秒 + 汇总 10 秒 = 40 秒

这是假设性的时间示例。实际延迟还包含调度、排队、网络、重复工作和合并开销。若所有 Agent 都受同一个慢速数据库限制，并行可能不会带来明显改善。

3. 隔离上下文

不同子任务不必同时把所有日志和文档塞进一个上下文窗口。每个 Agent 查看与自身任务相关的材料，再提交带来源的结论。

这降低了无关内容干扰，但摘要也可能丢失关键证据，因此应保留原始来源和可追溯的产物。

4. 独立提出候选与审查

一个 Agent 提出实现方案，另一个从故障或安全角度审查，第三个检查测试覆盖。

这种分工可能提高发现问题的机会，但“多个 Agent 一致同意”不等于结论一定正确。如果它们共享同样的错误前提或同一个错误数据源，错误可能高度相关。

Anthropic 描述过用于研究任务的主 Agent 与并行子 Agent 架构；其公开报告也指出，该方案的效果与成本取决于任务类型和计算投入，不能直接推广到所有场景。Anthropic：How we built our multi-agent research system

四、先判断：真的需要 Multi-Agent 吗？

不是所有任务都适合分工。

OpenAI 的公开文档也将独立、有边界的调查和实现列为多 Agent 的适用场景；对强顺序依赖或共享可变状态竞争的任务，单 Agent 可能更合适。OpenAI：Multi-agent

一个实用问题是：

如果去掉一个 Agent，系统会失去什么明确的能力、隔离或可验证价值？

如果答案只是“少了一个角色名称”，很可能不需要它。

五、六种常见协作模式

模式一：路由 Router

用户请求
   ↓
路由判断
   ├── 订单查询 Agent
   ├── 退款咨询 Agent
   └── 技术支持 Agent

适用场景：不同请求属于不同领域，通常只需要其中一条路径。

路由可以由规则、分类模型或 LLM 完成。关键风险是误路由：退款问题被送到订单状态 Agent，可能得到正确但不完整的答案。需要设计低置信度处理、复合问题拆分、路由理由和转交后的上下文。

模式二：主 Agent + 子 Agent

主 Agent
  ├── 专家 A：调查
  ├── 专家 B：调查
  └── 专家 C：验证
   ↓
主 Agent 合并并负责最终答复

适用场景：主任务可以分成多个相对独立的子任务，最终需要统一交付。

主 Agent 不应该只派发“研究一下”，而应说明目标、范围、输入、输出、证据要求、禁止操作和截止时间。

模式三：交接 Handoff

分流 Agent → 退款 Agent → 用户

适用场景：专业 Agent 应接管后续交流，例如客服从一般咨询转向复杂退款处理。

这里的关键是控制权转移。交接后谁向用户回复、可用哪些工具、携带哪些历史，都必须明确。

模式四：Agent as Tool

主 Agent → 调用退款分析 Agent → 收到结果 → 主 Agent 回复

专业 Agent 像一个有边界的能力供主 Agent 调用；主 Agent 仍负责最终结果。

这与 Handoff 的差别不是“工具更简单”，而是最终对用户的控制权归属不同。OpenAI 的编排文档也用这一点区分两种模式。OpenAI：Orchestration and handoffs

模式五：流水线 Pipeline

提取需求 → 设计方案 → 实现 → 验证 → 报告

适用场景：步骤有明确先后依赖，上一阶段结果是下一阶段输入。

它不一定需要每一步都是 Agent。某些阶段可能用普通程序、测试工具或人工完成，更容易控制结果。

模式六：多方案 + 评审

方案 A ─┐
方案 B ─┼→ 对照证据与约束 → 选择 / 合并
方案 C ─┘

适用场景：架构方案、根因假设或复杂推理需要比较多个候选。

评审时应明确评价标准和证据，不能仅靠投票。涉及高风险决策时，多个模型的共识不能替代权威数据、实际测试和必要的人类判断。

六、编排的核心：让任务可以被执行、交接和验收

一个模糊委派：

帮我看看支付问题。

可能让三个 Agent 都重复搜索同一个日志。

更好的子任务契约包括：

任务：调查订单下降是否与支付渠道异常有关。

输入：
- 时间窗口：10:00–11:00 UTC
- 数据源：已授权的渠道指标与错误日志
- 关联标识：incident_42

范围：
- 检查成功率、超时率及不同渠道的变化
- 与前一可比窗口比较
- 不修改配置，不调用支付或退款写接口

输出：
- 已观察事实与来源
- 可能解释和反证
- 缺失数据
- 结论置信程度及原因

任务契约还应该包括截止时间和预算、允许的工具与访问范围、是否可以修改文件，以及失败、超时或无法获得数据时如何返回。

委派不是把目标重复一遍，而是让接收者知道自己负责什么、如何证明结果、何时停止。

七、通信：一条 Agent 消息应该包含什么？

如果 Agent A 只返回“支付没问题”，主 Agent 无法知道它看了哪些渠道、时间范围是否匹配、数据是否完整。

更有用的返回可以是：

{
  "task_id": "payment-check-1",
  "status": "partial",
  "findings": [
    {
      "claim": "渠道 A 的超时率在调查窗口上升",
      "evidence_id": "metrics-17",
      "source_time": "2026-10-30T10:45:00Z"
    }
  ],
  "limitations": ["渠道 B 的指标不可用"],
  "next_action": "结合部署时间线核对"
}

这个 JSON 是自定义通信格式示意，不是某个框架的固定协议。

有用的字段通常包括任务 ID、发送方、状态、事实与推测、来源、时间、证据位置、未完成事项和对外部操作的授权范围。

共享全部上下文，还是只发送必要内容？

全部广播便于共享，但会增加 Token 成本、干扰和敏感信息暴露；只发送摘要更高效，却可能丢失反例或约束。

一个折中方式是：

消息中传摘要 + 来源引用 + 必要约束
原始材料保存在有权限控制的证据存储中

主 Agent 需要时再检查原文。不要把一段摘要复制三次后，当成三个独立来源。

八、共享状态、记忆和检查点

多 Agent 系统可能同时拥有几种不同状态：

检查点不等于长期记忆。 它可以帮助一个任务恢复，但不自动意味着系统已经建立安全、可更新、跨任务可检索的知识系统。

共享状态还需要约定：哪些字段只允许一个 Agent 写、多个结果如何合并、是否允许覆盖已有证据、版本冲突如何检测、数据对谁可见以及什么时候过期。

例如，两个 Agent 同时修改“根因”字段，最后写入者覆盖前者，可能让一个有价值的反证消失。更好的设计是保留独立发现，由汇总阶段比较，而不是让它们争写一个自由文本字段。

九、并发与共享资源：多个 Agent 会互相踩踏

如果两个编码 Agent 同时修改同一个文件：Agent A 修改支付校验，Agent B 重构支付 API，即使两者各自通过测试，最终合并也可能出现冲突或覆盖。

处理方法取决于任务：

1. 优先拆分独立文件或独立模块。
2. 明确每个子任务的写入范围。
3. 使用隔离工作区、分支或补丁作为交付物。
4. 合并后执行跨模块验证。
5. 碰到强依赖的修改，改为顺序执行。

注意：工作区隔离也不会自动解决业务层冲突。例如两人分别改变同一 API 的字段语义，即使 Git 没有文本冲突，集成后仍可能不兼容。

共享数据库、浏览器会话、账户和外部 API 也可能产生类似问题。对于不可重复的写操作，必须由可信运行时控制权限、并发和幂等。

一项研究在特定并发协调基准中发现，多个模型即使能够单独推理，也可能在共享资源竞争时陷入死锁。该结果说明需要显式协调机制，但不能将其特定基准中的失败率直接套用到所有实际系统。DPBench 论文

十、多个 Agent 的安全边界

Agent 的名称和提示词不是权限系统。

如果一个研究 Agent 可以读取内部文档，也可以发送外部邮件，那么恶意文档可能试图诱导它把内容发送出去。多个 Agent 还可能通过交接，把不可信内容转述为看似可信的“同事指令”。

需要明确：

• 工具权限由运行时和服务端授予，不由模型自行声明。
• 子 Agent 的权限不应超过任务所需范围。
• 外部网页、文档、日志和其他 Agent 输出都可能包含不可信内容。
• 访问控制应绑定真实用户、租户和操作，不应只依赖消息里的身份字段。
• 发送消息、修改生产数据或执行交易等操作应遵循实际授权边界。
• 敏感数据的共享、日志和产物需要控制访问与保留时间。

审查 Agent 可以帮助发现问题，但不能作为唯一安全屏障。模型能够判断的内容，与权限系统能够强制执行的约束，需要共同设计。

十一、失败、超时和停止条件

停止条件不应该只依赖模型说“我完成了”。

一个受控系统通常需要明确：

任务结果已满足验收
或 达到轮次 / 时间 / 成本预算
或 缺少必要权限 / 数据
或 用户取消
或 发现不可继续的故障

同时，停止生成新动作，不代表已发出的外部操作自动撤销。若写请求结果未知，仍需要查询或对账。

十二、为什么多 Agent 不一定更快，也不一定更聪明？

总耗时可以粗略分解为：

任务分解
+ 最慢的必要子任务
+ 协调与等待
+ 合并与验证

总成本则包括所有 Agent 的模型调用、工具调用、数据读取、重试和人工复核。

常见的负收益来自：

• 多个 Agent 调查同一件事。
• 主 Agent 给出的任务过于模糊。
• 每个子 Agent 都重复读取整个仓库。
• 结果汇总时丢掉关键约束。
• 写入同一资源导致冲突。
• 多层 Agent 彼此等待或无限讨论。
• 多个模型共享同一错误数据源，形成虚假的一致结论。

有关 Agent 系统扩展的研究指出，协作效果与任务类型、工具使用和协调拓扑有关，增加 Agent 可能产生收益，也可能增加错误和开销。该结论来自研究中的具体基准，不是所有产品的固定规律。Towards a Science of Scaling Agent Systems

实际决策应当比较：同样质量目标下，多 Agent 是否在时间、成本、可靠性或可维护性方面优于单 Agent。

十三、Multi-Agent 的主要应用场景

以下是常见的设计方向，具体能力需要实际数据、权限和评估支持。

这些场景不是“多个 Agent 一定更好”的证据。合适的架构应从任务和约束出发。

十四、案例一：AI Coding 团队如何分工？

假设要修复一个登录页面在移动端的布局问题。

一个过度复杂的设计可能创建需求 Agent、架构 Agent、代码 Agent、CSS Agent、测试 Agent 和报告 Agent。对于一个小范围样式修改，协调成本很可能大于收益。

如果任务扩展为多个相互独立的问题，才可能有合理分工：

主 Agent：确认范围、协调和最终验收

Agent A：检查移动端布局与相关组件
Agent B：检查可访问性和键盘交互
Agent C：检查现有测试与回归风险

如果只允许一个人修改同一组件，其他 Agent 可以只读调查并提交建议。最终由一个责任方整合修改，运行检查并在浏览器验证。

关键不是有多少 Agent，而是每个任务是否独立、修改范围是否清楚、集成后是否真的检查了用户界面，以及未经验证的部分是否如实报告。

十五、案例二：构建多来源 RAG 研究系统

假设用户想了解某项政策变化对某类产品的影响。

flowchart TD
    U[用户问题] --> M[主 Agent：拆分问题]
    M --> A[政策 Agent：检索法规原文]
    M --> B[产品 Agent：检索产品文档]
    M --> C[历史 Agent：查找先前案例]
    A --> E[证据集合]
    B --> E
    C --> E
    E --> V[验证：版本、权限、冲突、缺失]
    V --> S[主 Agent：综合结论]
    S --> R[回答：来源与不确定性]

需要注意：

1. 每个 Agent 只能检索用户有权访问的来源。
2. 政策版本和生效时间必须匹配问题。
3. 同一文档被三个 Agent 引用，不是三份独立证据。
4. 来源冲突时，应说明冲突而不是多数投票。
5. 如果某项信息不存在或未能检索，应保留缺失状态。
6. 最终结论中的每个关键主张，都应能追溯到证据。

关于知识接入、召回、重排与评估，可参考：深入 RAG。

十六、案例三：市场研究与风险信息整理

一个面向市场研究的系统，可以把工作分为：

市场数据 Agent：获取已授权的价格与时间戳
事件 Agent：查找公开事件和发布时间
风险 Agent：检查数据是否缺失、过期或口径不同
报告 Agent：区分已观察事实、推测和不确定性

例如研究者想分析重大事件日前后的指数波动。多个 Agent 可以分别整理公开事件时间、历史行情和相关研究，再由报告 Agent 比较数据口径。

但系统需要避免把历史事件自动当作未来走势保证、把不同到期日的 IV 混成一个指标、把数据缺失显示成零、未经授权执行交易，或把多个 Agent 的一致意见当成交易信号的充分证据。

这只是设计示例，不代表某个现有交易产品采用了上述架构，也不构成投资建议。

一个可运行的并行编排骨架

下面用 Python 标准库模拟两条只读调查。它展示任务并行、独立超时、部分结果和汇总责任；并没有连接真实模型或外部 API，也不是完整 Agent 框架。

import asyncio


async def collect(name: str, delay: float) -> dict:
    await asyncio.sleep(delay)  # 模拟只读工具调用
    return {"agent": name, "status": "completed", "evidence": [name]}


async def run_one(name: str, delay: float, timeout: float) -> dict:
    try:
        return await asyncio.wait_for(collect(name, delay), timeout)
    except asyncio.TimeoutError:
        return {"agent": name, "status": "timeout", "evidence": []}
    except Exception:
        return {"agent": name, "status": "failed", "evidence": []}


async def orchestrate(timeout: float = 0.1) -> dict:
    results = await asyncio.gather(
        run_one("market-data", 0.01, timeout),
        run_one("event-data", 0.02, timeout),
    )
    complete = all(item["status"] == "completed" for item in results)
    return {"status": "completed" if complete else "partial", "results": results}


if __name__ == "__main__":
    print(asyncio.run(orchestrate()))

真实系统还需要可信身份、结构化来源、共享预算、持久化、可观测性和权限控制。取消本地协程不保证已经发往远端的操作被撤销；如果任务包含写操作，必须使用业务幂等和状态查询处理未知结果。

十七、MCP、A2A 与 Multi-Agent 的关系

这三个概念经常出现在同一个系统中，但解决不同问题。

例如：

主 Agent
   ↓ A2A 任务交接
远程研究 Agent
   ↓ MCP 或其他接口
搜索 / 数据 / 文件工具

这只是可能的组合，不代表所有 Multi-Agent 都需要使用 A2A，也不代表所有 MCP 工具背后都是一个独立 Agent。

协议可以提供连接、消息格式和能力发现，但不会自动解决授权、事实正确性、幂等或商业责任。具体字段和行为应按采用的协议版本检查。A2A 规范示例；MCP TypeScript SDK

十八、如何评估一个 Multi-Agent 系统？

不能只问“最后的回答看起来是否不错”。至少需要同时评估结果、过程、系统成本和故障恢复。

**结果质量：**任务是否完成？关键事实是否正确？是否遗漏约束？来源能否支持结论？缺失是否如实说明？

**协作过程：**是否把任务分给正确的 Agent？是否重复工作或不必要交接？冲突证据是否保留？子任务失败后，主 Agent 是否仍声称全部完成？

**系统指标：**总 Token、工具调用和资金成本；平均与 p95 延迟；并发数；超时、重试和共享资源冲突；部分完成时的用户体验。

**安全与恢复：**是否越权读取？是否重复产生副作用？取消后是否仍有未确认动作？检查点恢复是否导致重复执行？是否保留可审计证据链？

OpenAI 的 Agent 评估资料强调使用 trace 检查模型调用、工具、护栏和交接；最终答案与过程轨迹应结合评估。OpenAI：Evaluate agent workflows

对照实验必须公平

至少比较：

A：单 Agent + 所需工具
B：单 Agent + 更充分的时间或 Token 预算
C：Multi-Agent

比较时固定或报告模型、工具、数据、任务集、权限、总预算和并发限制。否则，多 Agent 因为消耗更多算力获得提升，不能证明提升完全来自协作架构。

使用真实任务及困难案例，记录失败分布，并将历史行为或答案泄漏纳入测试。需要外部副作用的任务，应在隔离环境或模拟服务中做故障注入。

十九、一个从零落地的顺序

1. 先实现可用的单 Agent。 明确任务、工具、约束、权限和完成标准，记录失败案例。
2. 找到具体瓶颈。 例如不同数据源需要独立权限，或多个互不依赖的调查需要并行。
3. 只拆出一个边界明确的子任务。 定义输入、工具、证据格式和超时策略。
4. 引入主 Agent 汇总。 保留来源、未完成项和冲突，不得把推测变成已验证事实。
5. 补上工程控制。 根据风险加入持久化、预算、权限、并发限制、幂等和监控。
6. 与基线比较。 在同一批任务上比较质量、成本与耗时；收益不明显时继续简化。
7. 从低风险任务逐步扩展。 用户授权、业务服务的权限和结果验证始终是独立要求。

二十、常见面试问题与回答思路

1. Multi-Agent 与单 Agent 调多个工具的区别是什么？

单 Agent 调多个工具，通常仍由一个 Agent Loop 管理决策和上下文。Multi-Agent 包含多个相对独立的工作单元，还需要协调任务、状态、交接与结果合并。两者的边界取决于运行时设计，不应只按工具数量判断。

2. 为什么多个 Agent 可能更好？

独立任务可以并行，不同子任务可以使用更聚焦的上下文和权限，也可以独立调查或交叉审查。但收益要扣除协调和验证成本，并通过与单 Agent 的公平对照确认。

3. Handoff 与 Agent as Tool 有什么区别？

Handoff 将后续某条工作路径的控制权交给专业 Agent；Agent as Tool 则让主 Agent 调用专家并继续负责最终答复。实际行为还取决于框架的历史传递和控制权实现。

4. 为什么三个 Agent 一致，不一定正确？

它们可能共享同一个错误来源、提示词或隐含假设，错误高度相关。应检查证据是否独立、来源是否权威，以及是否存在反证，而不只是数票。

5. 子 Agent 执行外部写入后超时怎么办？

超时不代表操作没有发生。应依据业务操作 ID、幂等契约和外部状态查询恢复；无法确认时保留 UNKNOWN 并对账，避免盲目重复执行。

6. 检查点是不是长期记忆？

不是。检查点主要用于恢复某次运行状态；长期记忆还需要决定什么可以保存、如何验证、更新、删除、检索和控制权限。

7. 如何判断要不要使用 Multi-Agent？

先看任务能否合理拆分、是否需要独立工具或上下文、协作收益是否大于调度与合并成本；再使用真实任务对照单 Agent 的质量、延迟与总成本。

结语

Multi-Agent 并不是把单个 Agent 复制几份，也不是让多个模型无限对话。它是一套围绕任务拆分、上下文、权限、通信和结果负责关系建立的协作机制。

当工作可以独立分解、需要不同工具或需要从多个方向验证时，多 Agent 可能带来价值。当任务简单、依赖严格顺序、共享状态冲突严重，或结果无法验证时，增加 Agent 也可能让系统更慢、更贵、更难排查。

真正成熟的 Multi-Agent 系统，不只是让 Agent 开始协作，还能回答：

它们为什么分工、看到什么、做了什么、如何证明结果，以及失败后怎样恢复。

参考资料

• OpenAI：Multi-agent：多 Agent 适用条件与权衡。
• OpenAI：Orchestration and handoffs：交接与 Agent as Tool。
• OpenAI：Evaluate agent workflows：轨迹与工作流评估。
• Anthropic：How we built our multi-agent research system：研究型主 Agent 与并行子 Agent 的经验。
• AutoGen：Teams：团队编排及单 Agent 与多 Agent 的选择。
• DPBench：共享资源并发协调的研究。
• Towards a Science of Scaling Agent Systems：协作拓扑与任务类型的研究。
• A2A 协议规范示例；MCP TypeScript SDK：Agent 通信与工具连接。

延伸阅读：理解 Agent Loop；深入 RAG；应用 SDD 研发模式。