个人知识库

Multi-Agent 系统

19分钟阅读

Multi-Agent 系统

多个 AI Agent 协同工作完成复杂任务的系统架构

简介

Multi-Agent 系统是指多个 AI Agent 按照特定的协同模式共同完成任务的架构。与单一 Agent 独立完成所有工作不同，Multi-Agent 系统将复杂任务拆解为多个子任务，每个 Agent 负责一个专门的职责，通过协同配合达成最终目标。

这种架构特别适合规则驱动的业务流程——当任务可以明确拆解为多个步骤，每个步骤有明确的输入输出和处理规则时，Multi-Agent 系统比单一全能 Agent 更清晰、更可维护、更易测试。

关键信息

  • 类型：架构模式 / 协同机制
  • 领域：AI Agent / 工作流自动化 / 系统设计
  • 核心价值：职责分离、可测试性、可维护性
  • 典型协同模式：顺序管道、并行处理、层次委托
  • 相关概念：AI Agent 智能体、顺序管道、Agent 技能、Claude Code

核心特性

1. 职责分离（Separation of Concerns）

每个 Agent 只负责一个明确的子任务，有清晰的”做什么”和”不做什么”边界。

典型案例（会计管道）：

  • Agent 1（数据准备）：只标准化格式，不分类
  • Agent 2（分类）：只分类，不验证数据质量
  • Agent 3（对账）：只标记差异，不修改数据
  • Agent 4（报告）：只聚合数字，不做解读
  • Agent 5（洞察）：只解读数据，不修改报告

这种严格的职责边界使得：

  • 每个 Agent 可独立开发和测试
  • 系统出问题时可快速定位责任环节
  • 单个 Agent 可替换而不影响其他部分

2. 数据流转机制

Agent 之间通过标准化的数据格式传递信息，前一个 Agent 的输出是后一个 Agent 的输入。

常见流转方式：

  • 共享文件夹：Agent 写入/读取共享目录中的文件（如 data/cleaned/、data/categorized/）
  • 消息队列：通过消息中间件传递结构化数据
  • 数据库：Agent 读写共享数据库表
  • API 调用：Agent 之间通过 RESTful API 传递 JSON 数据

会计管道案例中采用共享文件夹模式，每个 Agent 从 data/ 读取输入并写入新的输出文件。

3. 协同模式

顺序管道（Sequential Pipeline）：

  • Agent 按固定顺序执行：A → B → C → D → E
  • 每个 Agent 只在前置 Agent 完成后启动
  • 适合有明确先后依赖关系的流程（数据必须先清洗再分类）

并行处理（Parallel Processing）：

  • 多个 Agent 同时处理不同数据分片
  • 适合无依赖关系的批量任务（同时分析 100 个客户的财务报表）

层次委托（Hierarchical Delegation）：

  • 主 Agent 负责任务分解和协调
  • 子 Agent 负责执行具体任务
  • 适合复杂决策需要中央调度的场景（参考 2026-05-27-woshipm-ai-ecommerce-kol-agent 的 Agent + Skills 分层架构）

4. 规则驱动适配性

Multi-Agent 系统特别适合以下场景：

  • 有明确规则：每个步骤的处理逻辑可以用规则描述
  • 有清晰结构：输入输出格式标准化
  • 有固定顺序：步骤之间有明确的先后依赖

典型适用领域：

  • 会计和财务处理（分类、对账、报告、分析）
  • 数据处理管道（采集、清洗、转换、加载）
  • 审批流程自动化（申请、审核、分派、归档）
  • 内容生产流程（素材收集、编辑、审核、发布）

不同素材中的观点

来自 2026-06-03-claude-code-multi-agent-accounting：

  • 顺序管道是 Multi-Agent 的经典形态：5 个 Agent（数据准备→分类→对账→报告→洞察）严格按顺序执行，每个 Agent 通过共享 data/ 文件夹传递数据。这种设计使得会计流程从原始银行对账单到业务洞察实现了端到端自动化
  • 职责边界清晰才能避免混乱：每个 Agent 有明确的”只做什么”和”不做什么”——数据准备 Agent 只清洗不分类，对账 Agent 只标记差异不修改数据，报告 Agent 只聚合数字不做解读。职责边界的严格定义是 Multi-Agent 系统可维护性的基础
  • 逐个构建+测试是正确开发流程：不要一次性构建 5 个 Agent 后再测试整个系统，而是 Agent 1 → 测试 → Agent 2 → 测试 → … 的渐进式构建。这避免了在系统末端才发现前置 Agent 的问题，大幅降低调试复杂度
  • 项目基础先于代码：在写任何 Agent 之前先建立 4 个基础文件——data/ 文件夹（共享工作区）、CLAUDE.md（项目真相源）、Claude Skills 最佳实践指南（600 行规范）、Agent 详细规格文档（每个 Agent 的角色/输入/输出/规则）。这些基础决定了系统能否顺利协同，比单个 Agent 的代码质量更重要
  • 规则驱动场景的天然适配性：会计流程的每个步骤都是规则驱动（分类按规则、匹配按规则、汇总按规则），规则+结构+顺序正是 Multi-Agent 系统擅长的场景。任何有明确规则、步骤、数据流转的业务流程都可以参考这个架构

来自 2026-06-17-ai-agent-工程完全指南：

  • Multi-Agent 的最大误区是按人类组织结构拆分：Anthropic 工程博客明确指出，按人类分工方式（规划 Agent、编码 Agent、测试 Agent、审查 Agent）是最低效方式。写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案，Agent 间反复解释背景消耗的 Token 甚至超过真正干活的 Token
  • 正确拆分原则是以上下文为中心：只有当两个任务的上下文可真正隔离时，拆分才有意义。判断标准不是”人类怎么分工”，而是”这两个任务是否需要共享决策历史”。如果不需要共享 → 可拆分；如果需要 → 保持单 Agent，用 Workflow 管理内部流程
  • 分布式单体反模式：按组织结构拆分但上下文高度耦合的多 Agent 系统，本质上是分布式单体——表面上多个独立 Agent，实际上任何一个都无法独立工作，修改一个需要同步修改其他所有

来自 2026-07-01-woshipm-multi-agent-coding-pipeline（多智能体协作放大 Coding Agent）：

  • 多智能体的价值不是”能干活”而是”可验证地交付”：到了 Claude Code、Codex 阶段，问题已经不是 Agent 能不能写代码，而是如何让它在复杂任务里不迷路、不污染上下文、不反复犯错，并交付一份可验证的结果。单 Agent 做复杂任务会暴露五大问题：上下文越来越脏、角色混在一起（自己证明自己正确）、长任务后期质量下降、失败后缺少责任边界、最终结果缺少证据
  • 动态子智能体生成优于预设固定角色：不要提前写死 planner/developer/tester/reviewer，而是建立一套”动态子智能体生成规范”——主会话作为 coordinator 按任务边界临时生成 子智能体 Brief。子智能体类型按职责划分：调查型（只读）、实现型（只改指定文件）、测试型（只跑测试）、审查型（只审不改）、UI 验证型（只启动页面截图）、文档型
  • 受控流水线的铁律：子智能体不决定下一步召唤谁：子智能体完成后只返回状态和结果地址，下一步由主智能体判断。否则会失控成”Agent 继续召唤 Agent”，上下文、成本、任务边界全部失控
  • 失败修复规则：谁实现谁优先修，谁发现谁复验：实现 Agent 拥有开发上下文，修复效率高；测试 Agent 知道问题是什么，复验更准确。重试上限 2-3 轮，超限生成 blocked 报告而非无限烧 token
  • Codex vs Claude Code 的多智能体适配差异：Codex 更适合在明确要求时使用 subagent workflows（拆任务给多个专门 Agent 并汇总）；Claude Code 可通过自定义 subagents、skills、权限限制、hooks 构建更细的任务型工作流。方案本质是”给现有顶尖 Coding Agent 加一套可复用的工程协作规范”，而非重新发明 Agent 平台

来自 2026-07-17-woshipm-claude-cowork-agent-workflow（Anthropic 营销运营）：

  • 层次委托的生产形态：Dispatcher 只轮询/分优先级/盖时间戳/路由，不执行业务；五个专家 Skill 各管 CRM、落地页、审批、数据导入等，可独立升级——这是「调度中枢 + 手脚」在营销活动场景的完整实现
  • 零上下文审计实例是关键设计：Audit Agent 必须是全新 session，像真实用户注册并查确认邮件；共享建设上下文会让 Agent 跳过验证。Manager Agent 则负责事后诊断「刚才哪里出了问题」，把查 log 外包给独立实例
  • 与顺序管道互补：会计管道是固定 A→B→C；活动流水线是请求驱动的路由 + 按需专家 + 独立验收，更贴近异步工单系统

来自 2026-07-19-youtube-codex-ai-marketing-team：

  • Codex 版营销团队验证了「五专家 + 一个编排者」的层次委托样板：research、content strategy、creative copy、data analysis 四个专家 Agent 分别产出 deck/doc、内容日历、文案和 KPI dashboard，campaign manager 读取 task manifest 与 summary 文件统一验收。
  • 共享状态从 CLAUDE.md 扩展为 agent.md + brand.md + /output 目录：agent.md 写系统架构、依赖、目录、命名和编排规则；brand.md 写品牌语气、定位、受众和 KPI；各 Agent 通过独立子目录和文件路径交接，不靠同一对话上下文硬记。
  • QA 是 Multi-Agent 系统的最后一环：campaign manager 不只汇总结果，还确认 12 个交付物存在、发现命名不一致、列出 banned words candidates，并把 Playwright 403 记为 known gap。这说明多智能体交付不能只看并行产出，更要看能否把失败、风险和人工决策点结构化暴露。

来自 2026-07-25-woshipm-loop-graphai：

  • 组织图 vs 任务运行图：长期组织图固定「谁长期负责什么能力」（少改）；任务运行图按工单临时生成「这次怎么拆、怎么并行、哪里等人」。这给 Multi-Agent 设计提供命名：agent.md 类文件偏组织图，单次 brief/工单偏任务运行图
  • 权限图与验收图是一等公民：哪些节点能写文件/联网/提交、哪些结果必须测试或人工确认——不只是角色列表
  • 与单 Loop 的边界：多 Agent 不是默认正确；单目标可逼近时用 Loop Engineering 更稳；需要多依赖与多回退时才用 Graph 工程 把协作拓扑画清

来自 2026-07-26-youtube-fable5-one-prompt-business（Fable 5 一 prompt 搭公司）：

  • 编排者 / 工人分离是成本铁律：主会话 Fable 5 只做 plan · delegate · review（约 50 万 token），全部 sub-agent 走 Opus/Sonnet；作者估计工人也用 Fable 会贵约 100×。这与「Fable 做重型编排、便宜模型做量」矩阵一致，并给出可引用的实测数字
  • Tournament + advocate/skeptic 是选题决策图，不是部门拆分：10 research agents 并行扫源 → 35 raw → 18 candidates 全量独立 re-fetch 验证 → 5 judge persona 六维打分 → top4 各配 advocate+skeptic → 3 名新裁判 3:0 选出 chargeback 赛道。这是「上下文可隔离的并行探索 + 中央裁决」，符合「以上下文为中心拆分」而非按人类岗位硬拆
  • Red team 作为交付前强制节点：6 skeptic 攻击，0 kill / 38 attacks ruled，修复回写 plan 与站点并产出 honesty artifacts——Multi-Agent 的最后一环不只是汇总，更是对抗证伪与诚实记录
  • Orchestration 指令要写「地板不是天花板」：显式要求 fan-out、tournament、adversarial verify、completeness critic，同时允许模型按工作形状设计新编排；避免把多智能体锁成唯一流水线教条

实用信息

设计 Multi-Agent 系统的步骤

  1. 识别任务是否适合 Multi-Agent：

    • 任务能否拆解为 3 个以上明确的子步骤？
    • 每个子步骤的输入输出能否标准化？
    • 是否存在明确的规则或处理逻辑？

  2. 划分 Agent 职责边界：

    • 为每个 Agent 写清楚”只做什么”和”不做什么”
    • 确保职责不重叠、不遗漏
    • 每个 Agent 应该可以独立测试

  3. 定义数据流转格式：

    • 标准化每个 Agent 的输入输出格式（JSON、CSV、Markdown）
    • 设计共享数据存储机制（文件夹、数据库、消息队列）
    • 明确数据的命名规范和目录结构

  4. 选择协同模式：

    • 有先后依赖？→ 顺序管道
    • 可并行处理？→ 并行模式
    • 需要中央调度？→ 层次委托

  5. 逐个构建和测试：

    • 先构建第一个 Agent，用真实数据测试
    • 再构建第二个 Agent，测试与第一个的集成
    • 逐步添加 Agent，每次都验证端到端流程

  6. 建立项目基础文件：

    • CLAUDE.md 或 README.md：记录系统架构、每个 Agent 的职责、数据流转规则
    • Agent 规格文档：每个 Agent 的详细定义（输入、输出、规则、示例）
    • 测试数据集：准备典型的输入数据用于端到端测试

常见工具和框架

  • Claude Code：通过自定义 Skill 构建 Multi-Agent 系统（参考 2026-06-03-claude-code-multi-agent-accounting）
  • LangGraph：专门用于构建 Multi-Agent 工作流的框架
  • AutoGen：微软开源的 Multi-Agent 对话框架
  • CrewAI：面向角色分工的 Multi-Agent 协同框架

注意事项/避坑指南

  1. 不要为了 Multi-Agent 而 Multi-Agent：如果任务简单（3 步以内）或规则不明确，单一 Agent 可能更合适
  2. 职责边界必须写在文档里：不要只在脑海中区分职责，必须显式记录”Agent A 不做 X，这是 Agent B 的职责”
  3. 数据格式标准化是关键：Agent 之间的数据格式不一致会导致集成困难，提前设计好 schema
  4. 避免 Agent 之间的隐式依赖：Agent B 不应该依赖 Agent A 的实现细节，只能依赖 Agent A 的输出格式
  5. 测试要覆盖边界情况：空数据、异常格式、部分缺失字段——每个 Agent 都要测试这些情况的处理
  6. 监控和日志很重要：Multi-Agent 系统出问题时需要快速定位是哪个 Agent 的问题，日志和监控不可少

相关页面

关系图谱

快速导航

反向链接