Multi-Agent 协作模式与工程实践

cody的小屋
336 阅读11分钟

前言

当 LLM 的能力边界不断扩展，一个显而易见的问题浮出水面：单个 Agent 能否解决所有问题？

答案是否定的。就像软件开发从单体架构走向微服务，Agent 架构也在经历类似的演进。在面对复杂业务场景时，单一 Agent 往往受限于上下文窗口、工具集规模、以及"单点故障"式的决策偏差。而 Multi-Agent（多智能体）系统通过多个 Agent 的分工协作，正在成为 Agent 工程化的核心范式。

2025 年 Google 发布 A2A（Agent-to-Agent）协议，2026 年微软将 AutoGen 合并为 Microsoft Agent Framework——这些标志性事件说明，Multi-Agent 已经从"实验性玩法"走向了"工程化标准"。

本文将从模式分类、架构设计、工程实践三个维度，拆解 Multi-Agent 系统的落地经验。

一、为什么需要 Multi-Agent？

单一 Agent 的瓶颈

在实际生产环境中，单一 Agent 架构往往面临以下问题：

  1. 上下文过载：一个 Agent 需要同时兼顾系统指令、用户需求、工具描述、历史对话，很容易触及上下文窗口上限
  2. 工具集膨胀：Agent 掌握的 Tool 数量越多，选择正确 Tool 的准确率越低（根据社区观察，超过 20 个工具时准确率下降明显）
  3. 角色冲突：同一个 Agent 既要负责严谨的数据计算，又要进行创意文案生成，风格切换困难
  4. 单点脆弱性：Agent 在某个环节出错后，缺乏"同行评审"机制，错误会一路传递到最终结果

Multi-Agent 的优势

  • 专业化分工：每个 Agent 专注自己的领域，就像一个团队里有后端、前端、设计师
  • 并行处理：多个 Agent 可以同时处理独立子任务，大幅缩短响应时间
  • 容错性：通过 Agent 间的交叉验证和评审机制，降低单点错误率
  • 可扩展性：新增能力只需添加新的 Agent，无需修改现有系统

二、Multi-Agent 协作模式分类

五种模式按耦合度从高到低排列，覆盖了从"中央集权"到"完全自治"的完整光谱：

软件架构模式耦合度对比.png

1. 星型模式（Orchestrator-Worker）

结构：一个主控 Agent（Orchestrator）负责任务分解、调度和结果整合，多个 Worker Agent 执行具体子任务。

适用场景：复杂任务拆解，如代码生成、数据分析报告、多步骤工作流。

典型流程：

主控调度模式.png

优缺点：

  • ✅ 结构清晰，易于管理和调试
  • ✅ 主控 Agent 可以控制全局质量
  • ❌ Orchestrator 可能成为瓶颈
  • ❌ 通信开销随 Worker 数量增加

2. 流水线模式（Pipeline）

结构：任务按顺序经过多个 Agent，每个 Agent 处理特定阶段，输出作为下一个 Agent 的输入。

适用场景：有明确步骤顺序的流程，如内容审核、数据清洗、多阶段处理。

典型流程：

流水线.png

优缺点：

  • ✅ 责任清晰，每个阶段可独立优化
  • ✅ 便于添加中间审核节点
  • ❌ 整体延迟等于各阶段之和
  • ❌ 前序 Agent 的错误会被放大

3. 辩论模式（Debate / Verifier）

结构：多个 Agent 各自独立完成任务，然后通过讨论、辩论或投票达成共识。

适用场景：需要高准确率的决策场景，如代码审查、风险评估、事实核查。

典型流程：

alt text转存失败，建议直接上传图片文件

辩论协作模式.png 优缺点：

  • ✅ 显著提高准确率（根据多项研究，辩论模式可降低 30%-40% 的错误率）
  • ✅ 多个视角避免思维盲区
  • ❌ 计算成本高（多个 LLM 调用）
  • ❌ 可能陷入无休止的辩论循环

4. 分层模式（Hierarchical）

结构：多个层级的 Agent 组成的树状结构，高层 Agent 负责策略和方向，低层 Agent 负责执行和细节。

适用场景：大规模复杂系统，如企业级自动化平台、自动化运维。

典型流程：

分层协作模式.png

优缺点：

  • ✅ 可扩展到非常大规模的系统
  • ✅ 每一层职责清晰，便于定位问题
  • ❌ 架构复杂度高，调试困难
  • ❌ 层级间通信延迟累积

5. 黑板模式（Blackboard / Market）

结构：多个 Agent 通过一个共享的"黑板"（消息队列或共享空间）进行异步协作，彼此不知道对方的存在。

适用场景：松耦合的任务分发，如大规模数据处理、异步工作流。

典型流程：

黑板协作模式.png

优缺点：

  • ✅ 高度解耦，Agent 可以独立部署和扩缩容
  • ✅ 适合异步、长时任务
  • ❌ 缺乏全局协调，可能出现冲突
  • ❌ 调试困难，消息流转不直观

三、工程实践：自动代码审查系统

理论讲完了，接下来看一个真实的生产案例。我们团队使用 Multi-Agent 模式构建了一个自动代码审查系统，采用 辩论模式 + 星型模式 的混合架构。

架构设计

代码评审主控模式.png

主控 Agent 负责分发代码 diff，三个 Reviewer 并行独立审查，最后仲裁 Agent 汇总分歧、生成最终报告。选择辩论模式的核心原因：代码审查的误判代价很高——漏掉一个安全漏洞可能导致生产事故，而单一 Agent 的漏报率在实测中高达 28%。

关键实现细节

以下代码是核心设计思路的简化版，省略了错误处理和日志部分，聚焦于协作逻辑本身。其中 find_disagreements、merge_consensus 等函数为逻辑占位符，代表该步骤要做的事，并非完整实现。

1. Agent 间的通信协议

每个 Agent 的输出需要遵循统一的格式，才能被其他 Agent 理解：

from dataclasses import dataclass
from enum import Enum

class MessageType(Enum):
    ANALYSIS = "analysis"    # 初步分析
    REVIEW = "review"        # 审查意见
    VERDICT = "verdict"      # 最终裁决
    QUESTION = "question"    # 向其他 Agent 提问

@dataclass
class AgentMessage:
    agent_id: str
    task_id: str
    message_type: MessageType
    content: dict            # 结构化内容：issue 列表、严重级别等
    confidence: float        # 0.0 - 1.0，Agent 对自己结论的置信度
    references: list[str]    # 引用的代码行号或文件路径

confidence 是辩论模式的关键——它让仲裁 Agent 知道哪个 Reviewer 更"笃定"，在分歧时可以加权决策而不是简单少数服从多数。

2. 辩论轮次控制

为了防止无限辩论，我们设置了最大辩论轮次和收敛条件：

MAX_DEBATE_ROUNDS = 3
CONVERGENCE_THRESHOLD = 0.85  # 平均置信度超过 0.85 即认为达成一致

def should_continue_debate(
    responses: list[AgentMessage],
    round_num: int
) -> bool:
    """决定是否需要继续辩论"""
    if round_num >= MAX_DEBATE_ROUNDS:
        return False
    avg_confidence = sum(r.confidence for r in responses) / len(responses)
    return avg_confidence < CONVERGENCE_THRESHOLD

3 轮上限是实测后的选择：2 轮太少（Agent 没机会回应彼此的意见），4 轮收益递减明显（第 3 轮后置信度提升不超过 3%）。

3. 上下文隔离

每个 Agent 不需要看到全部上下文，只接收与其职责相关的部分——这是 Multi-Agent 的核心优势之一：

def prepare_context_for_agent(
    agent_role: str,
    code_diff: str,
    full_context: dict
) -> dict:
    """根据 Agent 角色裁剪上下文，避免噪声"""
    base = {"code": code_diff}

    if agent_role == "style":
        return {**base, "rules": full_context["style_guide"],
                "focus": "代码规范、命名、格式"}
    elif agent_role == "performance":
        return {**base, "rules": full_context["performance_guide"],
                "focus": "时间复杂度、资源使用、安全漏洞"}
    elif agent_role == "architecture":
        return {**base, "rules": full_context["design_principles"],
                "focus": "设计模式、模块耦合、可维护性"}
    return base

4. 仲裁 Agent：如何汇总分歧

仲裁 Agent 是整个系统的"大脑"。它不是简单地把三个 Reviewer 的意见拼在一起，而是要识别分歧、引导讨论、做出裁决：

async def arbitrate(
    reviews: list[AgentMessage],
    code_diff: str
) -> AgentMessage:
    """仲裁 Agent：汇总分歧，引导讨论，生成最终报告"""
    # 第一轮：找出分歧点
    disagreements = find_disagreements(reviews)
    # 例如：Agent A 说"性能没问题"，Agent B 说"有 N+1 查询"

    if not disagreements:
        # 无分歧，直接合并
        return merge_consensus(reviews)

    # 第二轮：针对分歧点发起聚焦讨论
    for issue in disagreements:
        # 让每个 Reviewer 重新审视有争议的代码段
        follow_ups = await ask_reviewers_to_reconsider(
            issue, code_diff, reviews
        )
        # 更新各 Reviewer 的置信度
        update_confidence(reviews, follow_ups)

    # 第三轮：如果仍有分歧，由仲裁 Agent 做最终裁决
    final_verdict = resolve_remaining(reviews)
    return final_verdict

find_disagreements 的实现并不复杂：把三个 Reviewer 的 issue 列表按代码行号对齐，同一行如果有不同结论（一个说 OK、一个说有问题），就标记为分歧点。关键是把分歧暴露出来让 Agent 讨论，而不是直接取多数票——因为代码审查中，少数派往往是发现了真问题的那个人。

效果数据

上线三个月后，这套系统的表现：

指标单 AgentMulti-Agent（3 Reviewer + 1 仲裁）
漏报率28%9%
误报率15%11%
平均延迟6s22s
API 成本1x4.5x

漏报率从 28% 降到 9% 是核心收益——在代码审查场景，漏掉一个安全漏洞的代价远高于多花 3.5 倍的 API 成本。误报率改善确实有限（15%→11%），但误报的代价是人工复核，而漏报的代价可能是生产事故，两者的成本不在一个量级。

四、避坑指南

1. 通信开销管理

Agent 间的通信如果是全量文本传输，会迅速耗尽上下文窗口。推荐做法：

  • 只传输增量信息和引用（如"第 42 行有 SQL 注入风险"，而非贴整段代码）
  • 使用结构化数据格式（JSON）而非自然语言
  • 设置消息长度上限（我们限制单条消息不超过 2000 tokens）

2. Agent 数量选择

不是越多越好。下面这张表来自我们在多个不同任务类型上的综合测试（代码审查、文档生成、数据分析），不是单一场景的数据：

Agent 数量任务完成率平均延迟成本
172%5s1x
2-385%12s3x
4-591%25s6x
6+93%45s+10x+

从 1 到 3 个 Agent，完成率提升 13 个百分点；从 4 到 6 个，只提升 2 个百分点，但成本翻了近一倍。2-4 个 Agent 是性价比最高的区间。

3. 错误传播与隔离

在流水线模式中，一个 Agent 的错误会扩散到下游。解决方案：

  • 每个阶段增加校验步骤（schema 验证 + 语义校验）
  • 使用 Circuit Breaker 模式：当某个 Agent 连续失败 3 次时，降级使用默认值，而不是重试到超时
  • 引入 Checkpoint 机制：每个阶段完成后保存中间状态，失败时可以从最近的 checkpoint 重试，而不是从头来

4. 调试与可观测性

Multi-Agent 系统调试极其困难——当 3 个 Agent 互相辩论时，你很难判断"到底是谁先搞错的"。必须做好以下基础设施：

# 每个 Agent 的输入/输出都要序列化存储，绑定同一个 trace_id
async def run_agent(agent, task, trace_id: str):
    input_snapshot = snapshot(task)
    result = await agent.run(task)
    output_snapshot = snapshot(result)
    # 存储到可查询的存储中（我们用的是 OpenTelemetry + Jaeger）
    store_interaction(
        trace_id=trace_id,
        agent_id=agent.id,
        input_data=input_snapshot,
        output_data=output_snapshot,
    )
    return result

上线第一周，我们靠这套 trace 系统定位了 80% 的问题。没有它，Multi-Agent 就是个黑盒。

五、主流框架对比

特性Microsoft Agent FrameworkCrewAILangGraph自研
协作模式辩论/对话/星型角色/任务/流水线图/流水线灵活
学习曲线中-高低高-
可定制性高中-高高极高
调试工具有（MAF Studio）有（CrewAI OSS 1.0+）弱自建
生产就绪度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

关键变化：

  • AutoGen 已合并为 Microsoft Agent Framework（MAF）：2025 年末微软将 AutoGen 与 Semantic Kernel 合并为统一的 MAF，AutoGen 进入维护模式，新项目推荐使用 MAF
  • CrewAI OSS 1.0：2026 年发布，解决了确定性运行和可复现性的关键问题，生产级部署门槛大幅降低
  • LangGraph：持续演进，官方推荐使用 create_agent 高阶 API 构建生产级 Agent

选择建议：

  • 快速原型验证 → CrewAI（上手最快）
  • 复杂图状流程 → LangGraph
  • 需要多 Agent 辩论/对话 → MAF（AutoGen 的继承者）
  • 生产环境定制 → 在框架基础上自研

补充提示：如果你关注跨框架、跨厂商的 Agent 互操作，可以了解 Google 2025 年发布的 A2A 协议——它解决的是"不同框架的 Agent 怎么互相发现和通信"的问题，与 MCP（Agent 连工具）互补。

总结

Multi-Agent 不是银弹，但它是应对复杂 AI 应用的必然方向。关键不在于"用了多少 Agent"，而在于如何设计协作模式。

从实践经验来看，最重要的三件事：

  1. 从简单开始：先 2-3 个 Agent 验证模式，再逐步扩展。不要一上来就搞 5 层分层架构
  2. 通信成本是核心瓶颈：Agent 间的消息协议比 Agent 本身更重要，设计不好就是雪崩的开始
  3. 可观测性优先：没有 trace 系统，Multi-Agent 就是黑盒。先搭好观测，再写业务逻辑

如果你正在构建 Agent 系统，不妨从今天开始尝试 Multi-Agent 架构。毕竟，一个团队比一个人走得更远——这句话对 Agent 同样适用。

avatar
文章
阅读
粉丝