多智能体协作(Multi-Agent Collaboration):让 AI 分工完成复杂任务
多智能体协作,简单说就是:一个 AI 干不过来,就让多个 AI 按角色分工一起完成。
它真正要解决的是:复杂任务里同时需要调研、写作、审查、执行和决策时,不要让同一个 Agent 把所有角色都扛下来。
比如写一篇技术文章,可以拆成:
Researcher:查资料,整理事实和证据
Writer:基于资料写初稿
Critic:检查结构、证据和风险
Supervisor:决定下一步该谁处理这听起来很自然,就像公司里一个项目不会只靠一个人完成。
但要先记住一句话:
多智能体不是“更高级的单智能体”,而是“更复杂的协作系统”。它能解决复杂任务,也会带来更高成本、更长链路、更多错误传播风险。所以它不是默认选项。
这篇文章只回答一个问题:
什么时候值得用多智能体,以及怎样用最小工程结构把它落地。
一、什么时候需要多智能体
先看一个实用判断:
如果你能清楚说出每个 Agent 的职责、输入、输出和停止条件,才考虑多智能体。
如果只能说「让几个 AI 一起想想」,先别上。| 任务特征 | 是否适合 | 原因 |
|---|---|---|
| 需要不同能力 | 适合 | 调研、写作、审查、执行的判断标准不同 |
| 子任务可以并行 | 适合 | 多个 Worker 可同时处理独立部分 |
| 需要独立审查 | 适合 | 生成者和审查者分开,减少自我确认 |
| 有清楚的交接格式 | 适合 | 中间结果能被校验和复用 |
| 步骤少且稳定 | 不一定 | 提示词链更简单 |
| 单 Agent + 工具就能完成 | 不建议 | 多角色只会增加调度成本 |
| 子任务强依赖且每步易错 | 谨慎 | 错误会一路放大 |
| 说不清每个角色职责 | 不建议 | 角色边界不清会互相抢活 |
团队不是靠人数变强,而是靠职责、流程、交付物和检查机制变强。
二、最小协作模型
一个可控的多智能体系统至少包含四件事:拆任务、分角色、定协议、做检查。
1. 拆任务
拆成职责清楚、可以验收的部分。
写技术文章:
1. 搜集资料
2. 提炼观点
3. 写初稿
4. 审稿
5. 修改关键不是「拆得多」,而是每一块都能独立验收。
2. 分角色
角色必须写边界,尤其要写清楚不负责什么。
你是 Researcher。
你只负责整理事实、来源、案例和风险。
不要写完整文章。
不要给最终发布建议。3. 定协议
Agent 之间不要随便传自然语言。更稳的做法是固定输出结构。
{
"role": "researcher",
"status": "success",
"findings": ["..."],
"risks": ["..."],
"next_suggestion": "handoff_to_writer"
}4. 做检查
多智能体一定要有检查者。前一个 Agent 的错误如果没有被拦住,后面的 Agent 会把错误加工得更完整。
检查可以是另一个 Agent,也可以是 schema 校验、规则校验、测试、人工确认或成本阈值。
三、常见协作模式怎么选
多智能体不是一种形态,而是一组协作方式。新手默认从 Supervisor 或 Orchestrator-Worker 开始。
| 条件 | 推荐模式 | 不推荐模式 | 关键风险 | 必备控制 |
|---|---|---|---|---|
| 需要统一负责人调度 | Supervisor | Swarm | 负责人瓶颈 | 状态机 + 日志 |
| 子任务独立、可并行 | Orchestrator-Worker | 长 Pipeline | 汇总冲突 | Aggregator 冲突检测 |
| 步骤少且稳定 | Pipeline | 多角色团队 | 错误逐级传播 | 每步输出校验 |
| 需要观点碰撞 | Debate | 生产默认流程 | 成本高、难收敛 | 明确裁决者 |
| 大量自治探索 | Swarm | 新手项目 | 不可控 | 强约束环境和预算 |
多数生产场景里,3-5 个角色已经够用。
四、完整案例:自动写技术博客
假设目标是:
输入:主题
输出:一篇可以发布的技术博客初稿角色可以这样设计:
| 角色 | 输入 | 输出 | 不负责 |
|---|---|---|---|
| Researcher | 主题 | 事实、案例、参考资料、风险 | 写完整文章 |
| Writer | 研究材料 | 文章初稿 | 审查事实 |
| Critic | 初稿和标准 | 问题清单、发布建议 | 直接改稿 |
| Supervisor | 全部状态 | 下一步调度决定 | 代替专业角色工作 |
统一状态对象:
{
"topic": "提示词链",
"status": "researching",
"research": null,
"draft": null,
"review": null,
"revision_count": 0,
"errors": []
}数据流可以长这样:
重点不是角色名字,而是所有中间结果都回到统一状态里。
五、Supervisor 调度伪代码
下面这个伪代码重点展示状态、输出校验、最大返工次数和失败退出。
MAX_REVISIONS = 2
def run_blog_team(topic):
state = {
"topic": topic,
"status": "researching",
"revision_count": 0,
"errors": [],
}
while True:
next_agent = decide_next_agent(state)
if next_agent == "researcher":
output = researcher(state["topic"])
if not valid_research(output):
state["errors"].append("research_invalid_schema")
return fail_with_state(state)
state["research"] = output
state["status"] = "writing"
elif next_agent == "writer":
output = writer(state["topic"], state["research"], state.get("review"))
if not output.get("draft"):
state["errors"].append("draft_missing")
return fail_with_state(state)
state["draft"] = output["draft"]
state["status"] = "reviewing"
elif next_agent == "critic":
review = critic(state["draft"])
if not valid_review(review):
state["errors"].append("review_invalid_schema")
return fail_with_state(state)
state["review"] = review
if review["pass"]:
state["status"] = "done"
return state["draft"]
state["revision_count"] += 1
if state["revision_count"] > MAX_REVISIONS:
state["status"] = "needs_human_review"
return fail_with_state(state)
state["status"] = "writing"这段伪代码还少了队列、权限、成本控制和 trace,但它抓住了最小骨架:输入、校验、状态迁移和失败出口。
六、成本和风险
多智能体最容易被低估的是系统复杂度。
| 风险 | 发生原因 | 防护方式 |
|---|---|---|
| 复合错误 | 多个步骤串行,每一步都有误差 | 每步输出校验,关键节点人工确认 |
| 通信成本 | Agent 之间来回传上下文 | 固定输出 schema,只传必要字段 |
| 调试困难 | 不知道谁先出错 | 统一状态对象和 trace |
| 角色抢活 | 职责边界模糊 | 明确每个 Agent 不该做什么 |
| 无限返工 | Critic 一直提新问题 | 最大修改次数和停止条件 |
| 成本失控 | 并行任务、重试和长上下文叠加 | 预算上限、超时和降级策略 |
0.95^5 = 0.77 这类计算可以帮助理解复合错误:每一步看起来都有 95% 的可靠性,串 5 步以后整体成功率就会明显下降。
真实系统还会受到延迟、工具调用、重试、队列和上下文长度影响。最好记录输入、输出、耗时、重试次数和失败原因。
七、工程检查清单
| 检查项 | 问题 | 更稳的做法 |
|---|---|---|
| 角色边界 | Agent 互相抢活 | 写清负责和不负责 |
| 输出协议 | 自然语言交接太含糊 | JSON schema 或固定 Markdown |
| 统一状态 | 信息散落在对话里 | 所有中间结果写入 state |
| 停止条件 | 一直返工 | 最大轮数、最大成本、人工接管 |
| 冲突处理 | 多个 Worker 结论不一致 | Aggregator 给出取舍规则 |
| 日志 | 出错无法复盘 | 记录 agent、input、output、status |
如果只能先做一件事,我会先做统一状态。状态清楚了,系统才有调试和演进的入口。
八、和其他 Agent 模式的关系
| 模式 | 解决的问题 | 和多智能体怎么组合 |
|---|---|---|
| 路由 | 任务该给谁 | Supervisor 可以先路由 |
| 并行化 | 多个子任务同时做 | Worker 可并行执行 |
| 反思 | 谁负责检查 | Critic 是独立反思角色 |
| 规划 | 多步任务怎么排 | 计划可以拆给不同 Agent |
| 工具使用 | 执行真实动作 | 各角色可以调用不同工具 |
可以把多智能体理解成一个外壳:它把路由、并行、反思、规划和工具使用组织成协作系统。
九、一句话记住多智能体
多智能体协作不是「让一群 AI 自由发挥」,而是把复杂任务拆成角色、协议、状态和检查。
好的多智能体系统要能回答:
谁负责什么?
输出给谁?
格式是什么?
失败谁处理?
什么时候停下来?如果这五个问题答不上来,先别急着加 Agent。多智能体真正的价值,是让复杂任务变得可以分工、可以复盘、可以控制。