38.多智能体系统真的更好吗

多智能体系统真的更好吗？角色拆分、协作与失控风险

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 38 篇

“让多个 Agent 协作”听起来很强大，但多一个 Agent 就多一套 Prompt、状态、工具权限和失败路径。多智能体的价值不在于数量，而在于角色边界是否清晰、协作成本是否低于收益。

一、什么情况下需要拆角色？

适合拆分的场景：

• 任务包含明显不同的专业能力；
• 每个角色使用不同工具和权限；
• 可以定义清晰的输入、输出和验收标准；
• 角色之间需要并行处理；
• 单个 Agent 的上下文和决策范围过大。

不适合拆分的场景：

• 任务本身只有一两个固定步骤；
• 角色之间需要频繁来回沟通；
• 没有独立的评估标准；
• 团队无法观测每个角色的行为。

二、常见协作模式

主管—专家

主管 Agent 分解任务，把子任务交给搜索、分析和写作 Agent，再汇总结果。

顺序流水线

研究 Agent → 审核 Agent → 写作 Agent → 引用检查 Agent

并行专家

多个 Agent 同时处理不同资料或角度，最后由评审 Agent 合并。

辩论或评审

一个 Agent 生成方案，另一个 Agent 找反例，最终由裁决节点决定是否通过。

三、角色定义要具体

每个 Agent 至少定义：

• 任务目标；
• 输入格式；
• 输出 Schema；
• 可用工具；
• 禁止行为；
• 结束条件；
• 失败处理方式。

{
  "role": "contract_reviewer",
  "input": {"contract_id": "string"},
  "output": {"risks": "array", "evidence": "array"},
  "tools": ["read_contract"],
  "side_effects": false
}

角色描述越模糊，协作越容易变成多个模型互相转发长文本。

生产环境还应为每个角色补充 owner、输入来源、证据要求、最大耗时、Token 预算、失败状态和可调用的下游角色。角色契约不是 Prompt 文案，而是控制器可以校验的接口；不符合契约的输出应在边界处被拒绝或转入修复节点。

四、共享状态应该放什么？

不要让每个 Agent 共享全部对话。共享状态应包含任务所需的最小事实：

state = {
    "task_id": "task-001",
    "question": "……",
    "research_results": [],
    "review_findings": [],
    "final_draft": None,
    "approved": False,
}

大段原文应通过文档 ID、引用 ID或对象存储地址传递，避免每次协作都重复消耗 Token。

共享状态最好采用类型化字段和受控写入：研究 Agent 只能追加研究结果，审核 Agent 只能追加审核意见，主管节点负责改变任务状态。对于关键流程，可把状态变更写成带 event_id、agent_id、version 和 trace_id 的事件，避免多个 Agent 同时覆盖同一个字段。

五、并行协作的收益和代价

并行可以降低总耗时：

搜索法规 ─┐
搜索合同 ─┼→ 汇总 Agent
查询业务 ─┘

但同时带来：

• 并发模型调用成本；
• 结果合并和去重；
• 某个分支超时；
• 结果相互矛盾；
• 共享资源限流。

并行任务需要设置超时、部分成功策略和最大并发数。

汇总节点要明确分支失败如何处理：法规检索超时是否允许用已有证据继续、某个专家返回空结果是否降低结论置信度、哪些缺失必须整体失败。不要把“部分成功”伪装成“全部完成”，最终结果应保留每个分支的状态和证据来源。

六、如何避免角色之间互相“踢皮球”？

为每个角色设置明确的交付契约：

研究 Agent 必须返回证据 ID
审核 Agent 必须返回风险等级和理由
写作 Agent 只能使用已确认材料

如果输出不符合 Schema，进入修复或人工处理，不要让下一个 Agent 猜测缺失字段。

七、失控风险有哪些？

协作循环

Agent A 把任务交给 B，B 又交回 A，持续消耗预算。

权限扩散

一个本来只读的 Agent 通过另一个拥有写权限的 Agent 间接执行危险操作。

信息污染

某个 Agent 的错误结论被多个 Agent 当成事实继续传播。

成本爆炸

角色数量、并行分支和重试次数叠加，Token 成本快速上升。

八、治理方法

• 最大 Agent 数量和最大步骤数；
• 每个角色独立工具白名单；
• 共享状态只允许受控字段写入；
• 重要结论必须附证据；
• 关键动作必须经过审批节点；
• 记录每个角色的输入、输出和调用成本；
• 对冲突结果进入裁决或人工复核。

裁决节点不能只按“多数票”选择答案。更稳妥的做法是比较证据等级、数据版本、适用范围和角色权限；无法消除冲突时，输出冲突本身并请求人工确认。每个角色还应单独记录耗时、Token、工具调用次数和失败原因，便于判断拆分是否真的带来收益。

九、什么时候一个 Agent 更好？

如果任务可以通过一个清晰的工作流完成，单 Agent 或确定性节点通常更容易：

• 测试；
• 调试；
• 估算成本；
• 控制权限；
• 解释失败原因。

多智能体应该由实际复杂度驱动，而不是为了展示“AI 感”而堆叠角色。

结语

多智能体系统的价值来自专业分工、并行处理和权限隔离，但它也会增加状态同步、成本、循环和安全风险。先定义角色契约和验收标准，再决定是否拆分，通常比先创建一群 Agent 更稳妥。

下一篇将处理 Agent 最常见的异常行为：为什么它会不断循环调用工具，以及如何设计终止条件。

参考资料

1. LangGraph 官方文档：Workflows and Agents
2. LangGraph 官方文档：Multi-agent systems
3. LangGraph 官方文档：Recursion Limit

本文为“码海寻道”原创技术文章。多智能体架构应通过任务完成率、延迟、成本和安全指标验证收益。