多智能体协作（Multi-Agent）实战：什么时候上、怎么避坑

很多企业一上来就想做多智能体系统——"调度员 Agent + 销售 Agent + 客服 Agent + 财务 Agent"。听上去性感，但 80% 的场景用单 Agent + 工具调用就能搞定，多 Agent 反而把成本和故障面拉大。下面讲清边界。

一、什么时候必须 Multi-Agent

• 角色边界明确：需要不同 prompt、不同工具集、不同权限的多个角色独立工作
• 需要并发：研究 + 写作 + 校对，三个步骤可以并行加速
• 需要相互审查：一个生成、一个评审，提升输出可靠性
• 长链路任务：10 步以上的复杂工作流，单 Agent 上下文撑不住

二、什么时候不要上 Multi-Agent

• 问答类场景（一个 RAG Agent 足够）
• 简单的工具串联（Function Calling 比 Multi-Agent 便宜得多）
• 团队还没把单 Agent 跑稳定（先把基础打牢）

三、三种典型架构

1. 编排者–执行者（Orchestrator-Worker）

一个 Orchestrator 负责拆解任务、分发子任务给若干 Worker。适合销售线索研究、深度报告生成。

2. 团队协作（Team / Group Chat）

多个 Agent 围绕一个目标轮流发言，自带相互审查机制。适合产品创意、风险评估。

3. 流水线（Pipeline）

固定顺序：Agent A → Agent B → Agent C，每一步输出作为下一步输入。适合内容生产线（研究 → 写作 → 校对 → 排版）。

四、5 条避坑清单

1. 不要让 Agent 自由对话不止：设硬上限轮次，否则它们会死循环互相礼貌
2. 状态要持久化：每一步的产出必须落库，不要全靠 in-memory 上下文
3. 工具权限严格分级：读 Agent 不能拿写权限，写 Agent 不能拿删权限
4. 必须有 Human-in-the-loop 节点：关键决策点强制人工确认
5. 可观测性是命门：每个 Agent 的输入输出、token 消耗、失败原因都要可看可查

五、艾景特的多智能体基建实践

艾景特科技自研的智能体基建（Agent infrastructure）把上述能力作为默认组件提供：状态机、工具注册中心、权限矩阵、可观测性 Dashboard、灰度切换。客户不必从 LangGraph / AutoGen / CrewAI 中三选一再自己拼装，开箱即用。