随着 AI Agent 的快速发展单一 Agent 已经难以完成复杂任务。越来越多的 AI 系统开始采用 Multi-Agent多智能体架构通过多个专职 Agent 协同完成复杂任务。从 ChatGPT 的 Tool Use、Cursor 的多工具协同、Claude Code 的自主编程到 Devin 的全自动开发、OpenAI Swarm 的多智能体框架——这些系统的核心能力之一就是Agent 协作模式其二就是上下文工程后面我会在单开一篇文章讲解。本文将系统介绍当前主流的 10 种 Multi-Agent 协作模式深入分析各自的优缺点与适用边界。模式强项短板通俗解释Router快速分流、低成本路由错则错像客服前台把问题分给对应部门问技术→技术组问财务→财务组Planner-Executor长链路可控依赖规划质量像项目经理先列步骤再让员工一步步执行先计划→再干活cursor、cc就包含这种方式Manager-Worker大任务并行管理汇总开销像一个老板带多个员工同时干活最后老板汇总结果Swarm创意/探索发散难收敛像一群人头脑风暴点子很多但容易跑偏收不住Blackboard异步接力/增量状态一致性难像一块公共白板谁路过都能写点东西大家接力完善Pipeline稳定标准化不灵活像流水线工厂每一步固定流程一步做完再到下一步Debate/Critic高可靠/低风险成本高像辩论赛一个人提方案其他人挑错最后裁判决定Voting稳健性成本随 N 增像投票多个人给答案选最多人认同的Auction资源优化调度估价难像竞标谁觉得自己最合适、报价最好就接任务Tool编排企业工具落地编排复杂像自动化流水把不同工具串起来查数据→分析→发报告一、为什么需要 Multi-Agent1.1 单一 Agent 的典型工作流用户问题 → 单一 Agent → 调用工具 → 返回结果看起来简洁但当任务复杂度上升时这种模式会迅速崩塌。1.2 单一 Agent 的三大瓶颈瓶颈一任务复杂度限制一个 Agent 很难同时具备以下能力并做到都擅长能力示例数据查询写 SQL 查 BigQuery搜索调用 Google Search API编程生成并执行 Python 代码文件处理读写 CSV、Excel网页浏览爬取并解析网页内容当所有能力堆在一个 Agent 上模型需要在每次推理时从海量能力中选择正确的路径错误率会随能力数量指数增长。瓶颈二Prompt 复杂度爆炸如果把所有能力写在一个 System Prompt 里System Prompt 角色定义 SQL 语法规则 搜索工具说明 代码执行规范 数据分析指南 ...Prompt 长度可能达到数千甚至上万 token导致模型注意力分散指令遵循能力下降不同领域的指令互相干扰每次调用都消耗大量 token成本飙升瓶颈三上下文污染多个任务共享同一个对话上下文会导致推理错误前一个任务的中间结果干扰后续推理Token 浪费无关信息占据宝贵的上下文窗口幻觉加剧上下文中的噪声信息增多模型更容易胡说八道1.3 Multi-Agent 的核心思想复杂任务 → 任务拆分 → 多个专职 Agent → 协同完成 → 整合结果本质就是软件工程中的关注点分离Separation of Concerns——每个 Agent 只做一件事把一件事做好。二、10种 Multi-Agent协作模式详解1 Router / Dispatcher路由分发架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────┐ │ Router │ ← 仅负责分类/分流不做深推理 └────┬────┘ │ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Agent │ │Agent │ │Agent │ ← 并行执行或路由到其中一个 │ A │ │ B │ │ C │ └──┬───┘ └──┬───┘ └──┬───┘ │ │ │ └────────┼────────┘ ▼ ┌─────────────┐ │ Synthesizer │ ← 合并/统一口径/结构化输出 └─────────────┘执行流程示例用户“VitaWord 收入下降了获客花费有变化吗”Router 判断需要monetization_agent收入/转化 acquisition_agent获客/投放两个 Agent 并行查询/分析互不干扰Synthesizer 合并结论收入变化 CAC/CPA 变化 可能原因 建议返回综合回答优缺点维度优点缺点结构复杂度简单易工程化路由规则/分类器需要持续维护成本/延迟通常低可只调用必要 agent路由错会导致整体跑偏适配任务领域明确的请求跨领域长链路任务不够强需叠加 Planner2 Planner–Executor规划–执行架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Planner │ ← 拆解步骤/依赖/验收标准 └────┬─────┘ ▼ ┌────────────────┐ │ Task / Step List│ ← 计划可迭代更新 └────┬───────────┘ ▼ ┌───────────────┐ │ Executor(s) │ ← 执行每一步工具/检索/代码/SQL └────┬──────────┘ ▼ ┌───────────────┐ │ Verifier/QA │ ← 每步校验失败触发重试/重规划 └────┬──────────┘ ▼ ┌───────────────┐ │ Final Answer │ └───────────────┘执行流程示例用户“帮我定位 VitaWord 收入下降的原因并给出本周可执行的改进动作。”Planner 拆解拉取收入分解订阅/广告/内购对比上周/上月分渠道获客成本变化漏斗曝光→点击→注册→付费定位形成动作清单Executor 执行每一步跑 SQL/查报表/调用分析工具Verifier 校验数据口径一致、时间窗一致、是否缺失关键维度汇总输出原因排序 证据 预计影响 行动项优缺点维度优点缺点可控性强有计划、验收、可回放计划质量决定上限适配任务长链路、多步骤、可验证任务状态管理/重规划逻辑带来工程复杂度成本可按步骤精细化预算步骤多时调用成本上升3 Manager–Worker / Hierarchical经理–工人/层级委派架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Manager │ ← 拆分子任务、分配负责人、设定交付物 └────┬─────┘ │ ┌───────┼────────┐ ▼ ▼ ▼ ┌────────┐┌────────┐┌────────┐ │Worker A││Worker B││Worker C│ ← 并行交付子结果 └───┬────┘└───┬────┘└───┬────┘ └──────┬───────┬────┘ ▼ ┌──────────┐ │ Manager │ ← 汇总/冲突消解/二次分派 └────┬─────┘ ▼ ┌───────────┐ │ Deliverable│ └───────────┘执行流程示例用户“做一份 VitaWord 本月经营复盘收入、获客、留存、竞品并给建议。”Manager 拆分收入分析A、投放与获客成本B、留存与漏斗C、竞品调研DWorkers 并行产出各自跑数/检索/总结Manager 汇总统一口径、消解矛盾、形成一份复盘报告输出最终文档优缺点维度优点缺点并行与扩展强适合大任务拆小并行管理/汇总开销大质量控制Manager 可制定交付标准信息在层级中可能失真适配任务项目式交付、报告/方案需要清晰的子任务边界与接口4 Swarm / Team-of-Peers对等群体协作架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────────────┐ │ Shared Chat Room │ ← 对等讨论空间 └───┬─────┬───────┘ ▼ ▼ ┌────────┐ ┌────────┐ │Agent A │↔│Agent B │ ← 互相质疑/补充/修正 └────────┘ └────────┘ ↕ ↕ ┌────────┐ ┌────────┐ │Agent C │↔ │Agent D │ └────────┘ └────────┘ ▼ ┌──────────┐ │ Aggregator│ ← 提炼共识/输出 └──────────┘执行流程示例用户“我们该如何解释 VitaWord 收入下滑给出 5 个可能假设与验证路径。”Agent A提出定价/续费下降、Agent B提出投放质量下降、Agent C提出渠道政策变化、Agent D提出产品体验导致留存下降互相挑战要求证据/可验证指标Aggregator 汇总输出假设清单 每条所需数据与验证 SQL/报表优缺点维度优点缺点创造性强适合发散探索易跑题发散难收敛鲁棒性不依赖单点成本和时延通常较高适配任务头脑风暴、假设生成不适合严格流程/强一致交付5 Blackboard黑板系统/共享工作台架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────────┐ │ Blackboard │ ← 共享任务池/证据/中间产物/状态 └───┬─────┬────┘ │ │ ┌─────▼─┐ ┌─▼─────┐ │Agent A│ │Agent B│ ← 订阅/触发/认领任务 └──┬────┘ └──┬────┘ │ write │ write └─────┬─────┘ ▼ ┌─────────────┐ │ Blackboard │ └─────┬───────┘ ▼ ┌─────────────┐ │ Publisher │ ← 汇总发布/对外输出 └─────────────┘执行流程示例用户“持续监控 VitaWord 收入与获客发现异常自动生成日报。”黑板写入每日任务拉数、同比环比、异常检测、原因归因Agent A认领收入分解、Agent B认领投放成本、Agent C认领异常检测结果持续写回黑板带版本与时间窗Publisher每天固定时间读取黑板生成日报并发布优缺点维度优点缺点解耦与并发强适合异步协作状态/版本/冲突处理复杂可持续运行很适合长期任务与增量产出需要任务认领、锁、幂等等机制适配任务持续监控、流水线、增量构建对即时一次性问答略重6 Pipeline固定流水线架构┌──────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ User │→ │Agent A │→ │Agent B │→ │Agent C │→ │ Output │ └──────┘ │(提纲) │ │(写作) │ │(润色) │ └────────┘ └────────┘ └────────┘ └────────┘执行流程示例用户“写一篇 VitaWord 收入复盘博客。”A生成大纲与章节B按大纲写正文C润色、统一术语、补充结论与行动项输出最终文章优缺点维度优点缺点稳定性很稳定、易监控不够灵活异常分支难处理质量可通过质量门逐段把控上游错误会累积传播适配任务标准化生产流程需要临时探索/重规划时不适配7 Debate / Critic–Judge辩论/评审裁决架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Proposer │ ← 生成候选答案/方案 └────┬─────┘ ▼ ┌────────────────┐ │ Critics (N个) │ ← 找错误事实/逻辑/合规/风险 └────┬───────────┘ ▼ ┌──────────┐ │ Judge │ ← 选择/融合/要求改写 └────┬─────┘ ▼ ┌──────────┐ │ Final │ └──────────┘执行流程示例用户“对外发布解释 VitaWord 收入下降原因并给投资人说明。”Proposer出一版对外口径Critic1事实查数据口径Critic2PR检查措辞风险Critic3法务检查合规Judge融合并要求 Proposer 按修改意见重写输出可发布版本优缺点维度优点缺点可靠性高能显著降低幻觉/不当表述成本高链路更长风险控制强适合对外/合规Judge 标准不清会来回拉扯适配任务高风险输出、关键决策材料低价值/即时响应不划算8 Voting / Ensemble投票/集成架构┌──────┐ │ User │ └──┬───┘ ▼ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Agent1│ │Agent2│ │Agent3│ ← 独立求解/互不看对方 └──┬───┘ └──┬───┘ └──┬───┘ └────────┼────────┘ ▼ ┌─────────────┐ │ Aggregator │ ← 投票/加权/一致性选择 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“VitaWord 收入下降更可能是价格、留存还是获客给出判断。”3 个 agent 独立分析各自使用不同提示/不同证据优先级Aggregator以证据充分性一致性投票/加权输出最可能因素与证据列表优缺点维度优点缺点稳健性强减少单点失误成本随 agent 数量上升实现难度中等融合策略不当会多数不等于正确适配任务可比较、可验证的问题开放式创作类收益有限9 Auction / Market竞价/市场式调度架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Auctioneer│ ← 发布任务/收集报价 └────┬─────┘ ▼ ┌────────┼────────┐ ▼ ▼ ▼ ┌────────┐┌────────┐┌────────┐ │Agent A ││Agent B ││Agent C │ ← 报价成本/时延/置信度 └──┬─────┘└──┬─────┘└──┬─────┘ └────────┼──────────┘ ▼ ┌─────────────┐ │ Winner Agent │ ← 中标执行 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“拉取并分析 VitaWord 各渠道 CAC 变化要求 2 分钟内返回。”Auctioneer发布任务带 SLA2 分钟Agent A快但粗报价低时延、低成本Agent B慢但准报价高Agent C平衡选择满足 SLA 的最优组合比如 C 或 A中标 agent 执行并返回优缺点维度优点缺点资源优化能显式平衡成本/时延/质量报价/置信度评估难扩展性高适合大规模任务工程实现复杂调度、信用体系适配任务平台级调度、批任务小系统/小规模不一定值当10 Tool-Orchestration工具编排型多 Agent架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────────────┐ │ Orchestrator Agent│ ← 决策调用哪个工具agent、何时停止 └───┬───────┬──────┘ ▼ ▼ ┌──────────┐ ┌──────────┐ │SearchAgent│ │SQLAgent │ ← 各自封装工具能力 └────┬─────┘ └────┬─────┘ ▼ ▼ ┌──────────┐ ┌──────────┐ │Web/Docs │ │DB/Warehouse│ └──────────┘ └──────────┘ \ / ▼ ▼ ┌─────────────┐ │ Synthesizer │ ← 整理引用/证据/格式 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“VitaWord 收入下降帮我拉取关键指标并给出归因。”Orchestrator先调用SQLAgent拉收入分解与漏斗再调用SearchAgent查近期活动/版本/渠道政策变更证据Synthesizer汇总数据证据 文字归因 建议返回结果带引用与口径说明优缺点维度优点缺点工程落地强权限、审计、观测清晰可能退化成单体 orchestrator可控性可精细化限制工具权限与数据范围编排逻辑与状态机复杂适配任务企业助手、带工具的复杂任务纯聊天类收益不明显在大规模系统中也会采用多种模式的混合架构就像现代软件系统不会只用一种设计模式一样。关键不在于选择最好的模式而在于根据实际业务场景选择最合适的组合。
Multi-Agent 架构全景：10 种协作模式深度解析
发布时间：2026/5/27 0:07:09
随着 AI Agent 的快速发展单一 Agent 已经难以完成复杂任务。越来越多的 AI 系统开始采用 Multi-Agent多智能体架构通过多个专职 Agent 协同完成复杂任务。从 ChatGPT 的 Tool Use、Cursor 的多工具协同、Claude Code 的自主编程到 Devin 的全自动开发、OpenAI Swarm 的多智能体框架——这些系统的核心能力之一就是Agent 协作模式其二就是上下文工程后面我会在单开一篇文章讲解。本文将系统介绍当前主流的 10 种 Multi-Agent 协作模式深入分析各自的优缺点与适用边界。模式强项短板通俗解释Router快速分流、低成本路由错则错像客服前台把问题分给对应部门问技术→技术组问财务→财务组Planner-Executor长链路可控依赖规划质量像项目经理先列步骤再让员工一步步执行先计划→再干活cursor、cc就包含这种方式Manager-Worker大任务并行管理汇总开销像一个老板带多个员工同时干活最后老板汇总结果Swarm创意/探索发散难收敛像一群人头脑风暴点子很多但容易跑偏收不住Blackboard异步接力/增量状态一致性难像一块公共白板谁路过都能写点东西大家接力完善Pipeline稳定标准化不灵活像流水线工厂每一步固定流程一步做完再到下一步Debate/Critic高可靠/低风险成本高像辩论赛一个人提方案其他人挑错最后裁判决定Voting稳健性成本随 N 增像投票多个人给答案选最多人认同的Auction资源优化调度估价难像竞标谁觉得自己最合适、报价最好就接任务Tool编排企业工具落地编排复杂像自动化流水把不同工具串起来查数据→分析→发报告一、为什么需要 Multi-Agent1.1 单一 Agent 的典型工作流用户问题 → 单一 Agent → 调用工具 → 返回结果看起来简洁但当任务复杂度上升时这种模式会迅速崩塌。1.2 单一 Agent 的三大瓶颈瓶颈一任务复杂度限制一个 Agent 很难同时具备以下能力并做到都擅长能力示例数据查询写 SQL 查 BigQuery搜索调用 Google Search API编程生成并执行 Python 代码文件处理读写 CSV、Excel网页浏览爬取并解析网页内容当所有能力堆在一个 Agent 上模型需要在每次推理时从海量能力中选择正确的路径错误率会随能力数量指数增长。瓶颈二Prompt 复杂度爆炸如果把所有能力写在一个 System Prompt 里System Prompt 角色定义 SQL 语法规则 搜索工具说明 代码执行规范 数据分析指南 ...Prompt 长度可能达到数千甚至上万 token导致模型注意力分散指令遵循能力下降不同领域的指令互相干扰每次调用都消耗大量 token成本飙升瓶颈三上下文污染多个任务共享同一个对话上下文会导致推理错误前一个任务的中间结果干扰后续推理Token 浪费无关信息占据宝贵的上下文窗口幻觉加剧上下文中的噪声信息增多模型更容易胡说八道1.3 Multi-Agent 的核心思想复杂任务 → 任务拆分 → 多个专职 Agent → 协同完成 → 整合结果本质就是软件工程中的关注点分离Separation of Concerns——每个 Agent 只做一件事把一件事做好。二、10种 Multi-Agent协作模式详解1 Router / Dispatcher路由分发架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────┐ │ Router │ ← 仅负责分类/分流不做深推理 └────┬────┘ │ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Agent │ │Agent │ │Agent │ ← 并行执行或路由到其中一个 │ A │ │ B │ │ C │ └──┬───┘ └──┬───┘ └──┬───┘ │ │ │ └────────┼────────┘ ▼ ┌─────────────┐ │ Synthesizer │ ← 合并/统一口径/结构化输出 └─────────────┘执行流程示例用户“VitaWord 收入下降了获客花费有变化吗”Router 判断需要monetization_agent收入/转化 acquisition_agent获客/投放两个 Agent 并行查询/分析互不干扰Synthesizer 合并结论收入变化 CAC/CPA 变化 可能原因 建议返回综合回答优缺点维度优点缺点结构复杂度简单易工程化路由规则/分类器需要持续维护成本/延迟通常低可只调用必要 agent路由错会导致整体跑偏适配任务领域明确的请求跨领域长链路任务不够强需叠加 Planner2 Planner–Executor规划–执行架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Planner │ ← 拆解步骤/依赖/验收标准 └────┬─────┘ ▼ ┌────────────────┐ │ Task / Step List│ ← 计划可迭代更新 └────┬───────────┘ ▼ ┌───────────────┐ │ Executor(s) │ ← 执行每一步工具/检索/代码/SQL └────┬──────────┘ ▼ ┌───────────────┐ │ Verifier/QA │ ← 每步校验失败触发重试/重规划 └────┬──────────┘ ▼ ┌───────────────┐ │ Final Answer │ └───────────────┘执行流程示例用户“帮我定位 VitaWord 收入下降的原因并给出本周可执行的改进动作。”Planner 拆解拉取收入分解订阅/广告/内购对比上周/上月分渠道获客成本变化漏斗曝光→点击→注册→付费定位形成动作清单Executor 执行每一步跑 SQL/查报表/调用分析工具Verifier 校验数据口径一致、时间窗一致、是否缺失关键维度汇总输出原因排序 证据 预计影响 行动项优缺点维度优点缺点可控性强有计划、验收、可回放计划质量决定上限适配任务长链路、多步骤、可验证任务状态管理/重规划逻辑带来工程复杂度成本可按步骤精细化预算步骤多时调用成本上升3 Manager–Worker / Hierarchical经理–工人/层级委派架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Manager │ ← 拆分子任务、分配负责人、设定交付物 └────┬─────┘ │ ┌───────┼────────┐ ▼ ▼ ▼ ┌────────┐┌────────┐┌────────┐ │Worker A││Worker B││Worker C│ ← 并行交付子结果 └───┬────┘└───┬────┘└───┬────┘ └──────┬───────┬────┘ ▼ ┌──────────┐ │ Manager │ ← 汇总/冲突消解/二次分派 └────┬─────┘ ▼ ┌───────────┐ │ Deliverable│ └───────────┘执行流程示例用户“做一份 VitaWord 本月经营复盘收入、获客、留存、竞品并给建议。”Manager 拆分收入分析A、投放与获客成本B、留存与漏斗C、竞品调研DWorkers 并行产出各自跑数/检索/总结Manager 汇总统一口径、消解矛盾、形成一份复盘报告输出最终文档优缺点维度优点缺点并行与扩展强适合大任务拆小并行管理/汇总开销大质量控制Manager 可制定交付标准信息在层级中可能失真适配任务项目式交付、报告/方案需要清晰的子任务边界与接口4 Swarm / Team-of-Peers对等群体协作架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────────────┐ │ Shared Chat Room │ ← 对等讨论空间 └───┬─────┬───────┘ ▼ ▼ ┌────────┐ ┌────────┐ │Agent A │↔│Agent B │ ← 互相质疑/补充/修正 └────────┘ └────────┘ ↕ ↕ ┌────────┐ ┌────────┐ │Agent C │↔ │Agent D │ └────────┘ └────────┘ ▼ ┌──────────┐ │ Aggregator│ ← 提炼共识/输出 └──────────┘执行流程示例用户“我们该如何解释 VitaWord 收入下滑给出 5 个可能假设与验证路径。”Agent A提出定价/续费下降、Agent B提出投放质量下降、Agent C提出渠道政策变化、Agent D提出产品体验导致留存下降互相挑战要求证据/可验证指标Aggregator 汇总输出假设清单 每条所需数据与验证 SQL/报表优缺点维度优点缺点创造性强适合发散探索易跑题发散难收敛鲁棒性不依赖单点成本和时延通常较高适配任务头脑风暴、假设生成不适合严格流程/强一致交付5 Blackboard黑板系统/共享工作台架构┌──────┐ │ User │ └──┬───┘ ▼ ┌─────────────┐ │ Blackboard │ ← 共享任务池/证据/中间产物/状态 └───┬─────┬────┘ │ │ ┌─────▼─┐ ┌─▼─────┐ │Agent A│ │Agent B│ ← 订阅/触发/认领任务 └──┬────┘ └──┬────┘ │ write │ write └─────┬─────┘ ▼ ┌─────────────┐ │ Blackboard │ └─────┬───────┘ ▼ ┌─────────────┐ │ Publisher │ ← 汇总发布/对外输出 └─────────────┘执行流程示例用户“持续监控 VitaWord 收入与获客发现异常自动生成日报。”黑板写入每日任务拉数、同比环比、异常检测、原因归因Agent A认领收入分解、Agent B认领投放成本、Agent C认领异常检测结果持续写回黑板带版本与时间窗Publisher每天固定时间读取黑板生成日报并发布优缺点维度优点缺点解耦与并发强适合异步协作状态/版本/冲突处理复杂可持续运行很适合长期任务与增量产出需要任务认领、锁、幂等等机制适配任务持续监控、流水线、增量构建对即时一次性问答略重6 Pipeline固定流水线架构┌──────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ User │→ │Agent A │→ │Agent B │→ │Agent C │→ │ Output │ └──────┘ │(提纲) │ │(写作) │ │(润色) │ └────────┘ └────────┘ └────────┘ └────────┘执行流程示例用户“写一篇 VitaWord 收入复盘博客。”A生成大纲与章节B按大纲写正文C润色、统一术语、补充结论与行动项输出最终文章优缺点维度优点缺点稳定性很稳定、易监控不够灵活异常分支难处理质量可通过质量门逐段把控上游错误会累积传播适配任务标准化生产流程需要临时探索/重规划时不适配7 Debate / Critic–Judge辩论/评审裁决架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Proposer │ ← 生成候选答案/方案 └────┬─────┘ ▼ ┌────────────────┐ │ Critics (N个) │ ← 找错误事实/逻辑/合规/风险 └────┬───────────┘ ▼ ┌──────────┐ │ Judge │ ← 选择/融合/要求改写 └────┬─────┘ ▼ ┌──────────┐ │ Final │ └──────────┘执行流程示例用户“对外发布解释 VitaWord 收入下降原因并给投资人说明。”Proposer出一版对外口径Critic1事实查数据口径Critic2PR检查措辞风险Critic3法务检查合规Judge融合并要求 Proposer 按修改意见重写输出可发布版本优缺点维度优点缺点可靠性高能显著降低幻觉/不当表述成本高链路更长风险控制强适合对外/合规Judge 标准不清会来回拉扯适配任务高风险输出、关键决策材料低价值/即时响应不划算8 Voting / Ensemble投票/集成架构┌──────┐ │ User │ └──┬───┘ ▼ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Agent1│ │Agent2│ │Agent3│ ← 独立求解/互不看对方 └──┬───┘ └──┬───┘ └──┬───┘ └────────┼────────┘ ▼ ┌─────────────┐ │ Aggregator │ ← 投票/加权/一致性选择 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“VitaWord 收入下降更可能是价格、留存还是获客给出判断。”3 个 agent 独立分析各自使用不同提示/不同证据优先级Aggregator以证据充分性一致性投票/加权输出最可能因素与证据列表优缺点维度优点缺点稳健性强减少单点失误成本随 agent 数量上升实现难度中等融合策略不当会多数不等于正确适配任务可比较、可验证的问题开放式创作类收益有限9 Auction / Market竞价/市场式调度架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────┐ │ Auctioneer│ ← 发布任务/收集报价 └────┬─────┘ ▼ ┌────────┼────────┐ ▼ ▼ ▼ ┌────────┐┌────────┐┌────────┐ │Agent A ││Agent B ││Agent C │ ← 报价成本/时延/置信度 └──┬─────┘└──┬─────┘└──┬─────┘ └────────┼──────────┘ ▼ ┌─────────────┐ │ Winner Agent │ ← 中标执行 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“拉取并分析 VitaWord 各渠道 CAC 变化要求 2 分钟内返回。”Auctioneer发布任务带 SLA2 分钟Agent A快但粗报价低时延、低成本Agent B慢但准报价高Agent C平衡选择满足 SLA 的最优组合比如 C 或 A中标 agent 执行并返回优缺点维度优点缺点资源优化能显式平衡成本/时延/质量报价/置信度评估难扩展性高适合大规模任务工程实现复杂调度、信用体系适配任务平台级调度、批任务小系统/小规模不一定值当10 Tool-Orchestration工具编排型多 Agent架构┌──────┐ │ User │ └──┬───┘ ▼ ┌──────────────────┐ │ Orchestrator Agent│ ← 决策调用哪个工具agent、何时停止 └───┬───────┬──────┘ ▼ ▼ ┌──────────┐ ┌──────────┐ │SearchAgent│ │SQLAgent │ ← 各自封装工具能力 └────┬─────┘ └────┬─────┘ ▼ ▼ ┌──────────┐ ┌──────────┐ │Web/Docs │ │DB/Warehouse│ └──────────┘ └──────────┘ \ / ▼ ▼ ┌─────────────┐ │ Synthesizer │ ← 整理引用/证据/格式 └─────────────┘ ▼ ┌────────┐ │ Output │ └────────┘执行流程示例用户“VitaWord 收入下降帮我拉取关键指标并给出归因。”Orchestrator先调用SQLAgent拉收入分解与漏斗再调用SearchAgent查近期活动/版本/渠道政策变更证据Synthesizer汇总数据证据 文字归因 建议返回结果带引用与口径说明优缺点维度优点缺点工程落地强权限、审计、观测清晰可能退化成单体 orchestrator可控性可精细化限制工具权限与数据范围编排逻辑与状态机复杂适配任务企业助手、带工具的复杂任务纯聊天类收益不明显在大规模系统中也会采用多种模式的混合架构就像现代软件系统不会只用一种设计模式一样。关键不在于选择最好的模式而在于根据实际业务场景选择最合适的组合。
