多智能体协作(Multi-Agent Collaboration):让 AI 分工完成复杂任务

多智能体协作,简单说就是:一个 AI 干不过来,就让多个 AI 按角色分工一起完成。

它真正要解决的是:复杂任务里同时需要调研、写作、审查、执行和决策时,不要让同一个 Agent 把所有角色都扛下来。

比如写一篇技术文章,可以拆成:

Researcher:查资料,整理事实和证据
Writer:基于资料写初稿
Critic:检查结构、证据和风险
Supervisor:决定下一步该谁处理

这听起来很自然,就像公司里一个项目不会只靠一个人完成。

但要先记住一句话:

多智能体不是“更高级的单智能体”,而是“更复杂的协作系统”。

它能解决复杂任务,也会带来更高成本、更长链路、更多错误传播风险。所以它不是默认选项。

这篇文章只回答一个问题:

什么时候值得用多智能体,以及怎样用最小工程结构把它落地。

一、什么时候需要多智能体

先看一个实用判断:

如果你能清楚说出每个 Agent 的职责、输入、输出和停止条件,才考虑多智能体。
如果只能说「让几个 AI 一起想想」,先别上。
任务特征是否适合原因
需要不同能力适合调研、写作、审查、执行的判断标准不同
子任务可以并行适合多个 Worker 可同时处理独立部分
需要独立审查适合生成者和审查者分开,减少自我确认
有清楚的交接格式适合中间结果能被校验和复用
步骤少且稳定不一定提示词链更简单
单 Agent + 工具就能完成不建议多角色只会增加调度成本
子任务强依赖且每步易错谨慎错误会一路放大
说不清每个角色职责不建议角色边界不清会互相抢活

团队不是靠人数变强,而是靠职责、流程、交付物和检查机制变强。

二、最小协作模型

一个可控的多智能体系统至少包含四件事:拆任务、分角色、定协议、做检查。

流程图画布 · 115%
Mermaid 流程图加载中...

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 开始。

条件推荐模式不推荐模式关键风险必备控制
需要统一负责人调度SupervisorSwarm负责人瓶颈状态机 + 日志
子任务独立、可并行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": []
}

数据流可以长这样:

流程图画布 · 115%
Mermaid 流程图加载中...

重点不是角色名字,而是所有中间结果都回到统一状态里。

五、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。多智能体真正的价值,是让复杂任务变得可以分工、可以复盘、可以控制。