多 Agent 协作：在你拆分之前，先想清楚这几件事

这两年一聊到复杂任务，很多人的第一反应是"上多 Agent"——一个负责规划、一个负责检索、一个负责写代码、再来一个负责审查，听起来分工明确、很美好。但真把多 Agent 系统跑起来之后，相当一部分团队会发现：它不仅没比单 Agent 强，反而更慢、更贵、更难调。

问题往往不出在"多 Agent"这个方向上，而出在拆分的时机和编排的方式。这篇就把多 Agent 里几件容易踩的事捋一遍：什么时候才真该拆，拆了之后用哪种编排模式，以及多 Agent 特有的几个陷阱怎么躲。

先泼盆冷水：你可能并不需要多 Agent

多 Agent 不是免费的。每多一个 Agent，就多一份上下文传递的开销、一处可能出错的接口、一段需要排查的链路。所以拆分之前先问一句：单 Agent 配好工具，是不是就够了？

一个朴素但好用的判断标准：

• 任务能用"一个角色 + 一组工具"覆盖 → 单 Agent。比如客服、单领域问答、固定流程的数据处理，硬拆成多 Agent 通常是负优化。

• 任务里存在职责天然冲突或需要并行的部分 → 才考虑拆。典型的是"写"和"审"——让同一个 Agent 既写代码又挑自己代码的毛病，效果往往不如一写一审两个独立角色；又比如要同时检索十个数据源，并行比串行省时间。

记住一点：拆分的收益来自职责隔离或并行，而不是来自"Agent 数量多"本身。

三种常见编排模式

真要拆，常见的编排结构就那么几种，按控制流的形状区分。

主管-工人（Supervisor-Worker）：一个主管 Agent 负责拆解任务、分派给工人、汇总结果。控制流清晰，最常用，也最好调。代价是主管是单点——它判断错了，全盘皆错。

流水线（Pipeline）：Agent A 的输出是 Agent B 的输入，串成一条线。适合阶段分明的任务（如：抽取 → 清洗 → 总结）。缺点是上游错误会顺着管子流到下游，且天然没法并行。

黑板/共享状态（Blackboard）：多个 Agent 读写同一块共享状态，谁该干活由状态触发。灵活，适合不确定执行顺序的场景，但调试难度也最高——你得能还原"当时这块黑板长什么样"。

flowchart TB subgraph 主管-工人 S[主管] --> W1[工人A] S --> W2[工人B] W1 --> S W2 --> S end subgraph 流水线 P1[抽取] --> P2[清洗] --> P3[总结] end subgraph 黑板 B[(共享状态)] A1[Agent1] <--> B A2[Agent2] <--> B A3[Agent3] <--> B end

绝大多数业务场景，从主管-工人起步是最稳的——它的控制流最接近人能直觉理解的方式。

下面是主管路由的一段示意，注意它做的核心其实是"把任务路由到合适的工人，并把结果收回来"：

def supervisor(task, workers, llm, max_rounds=8):
    state = {"goal": task, "results": []}
    for _ in range(max_rounds):
        # 主管基于当前进展，决定派给谁、或者收工
        plan = llm.route(goal=state["goal"], progress=state["results"],
                         available=list(workers.keys()))
        if plan.action == "FINISH":
            return synthesize(state["results"])
        worker = workers[plan.assignee]
        # 关键：只把这个工人需要的那部分上下文传过去
        sub_result = worker.run(plan.subtask, context=plan.context_slice)
        state["results"].append({"by": plan.assignee, "out": sub_result})
    return synthesize(state["results"])  # 兜底收尾

多 Agent 特有的三个陷阱

单 Agent 的坑（上下文、容错、循环控制）多 Agent 一个都不会少，而且还会被放大。除此之外，多 Agent 还有三个它独有的坑。

陷阱一：上下文在传递中丢失或失真。 Agent A 知道的事，Agent B 不一定知道。如果你靠"让 A 用自然语言把背景讲给 B 听"来传递，信息会一层层衰减——这跟人传话传歪了是一个道理。解法是用结构化消息而非自由文本来传递关键事实：

# 不要让 Agent 之间用自由文本"讲"，容易传歪
# 用结构化契约传递关键信息
message = {
    "from": "researcher",
    "to": "writer",
    "facts": [                      # 结构化事实，不靠对方"读懂一段话"
        {"claim": "Q3营收同比+12%", "source": "doc_17", "confidence": 0.9},
    ],
    "open_questions": ["Q4预测数据缺失"],
}

自然语言适合给人看，结构化数据适合在 Agent 之间流转。两者别混用。

陷阱二：错误放大。 单 Agent 错了，错一次。多 Agent 流水线里，上游一个没校验的错误结论，会被下游当成事实继续推理，越走越偏。所以每个交接点（handoff）都该有一道校验，宁可让流程停下来报错，也别让脏数据流下去。

陷阱三：成本与延迟爆炸。 三个 Agent 来回协商五轮，就是十几次模型调用。多 Agent 的账单和延迟很容易是单 Agent 的好几倍。上线前一定要给整个协作过程套一个全局的 token 预算和轮数上限，而不是只管单个 Agent。

编排这层基础设施，自己写还是用平台

把上面这些落地——结构化消息契约、交接点校验、共享状态的读写与回放、全局预算控制、并发调度——你会发现真正费劲的不是某一个 Agent 的 prompt，而是 Agent 之间这层编排基础设施。它和具体业务无关，但每个多 Agent 项目都得有。

这块要不要自己造，是个值得认真算的账。顺带说一句，国内做企业级智能体平台的服务商其实已经不少了，不必默认这类平台都是国外产品——比如比孚科技的 Bizfocus ADP 就是国产的企业级智能体平台，多 Agent 的编排、状态共享、链路追踪这些能力在平台层就是现成的。

判断标准还是那套朴素逻辑：

• 协作逻辑高度定制、需要对调度的每个细节精细控制，且团队愿意长期维护这套基础设施 → 自建，代价是上面那些编排难题你得逐个啃下来。

• 想把精力放在"每个 Agent 干好自己那摊业务"上，而不是反复造调度器和消息总线；或者对私有化、合规有要求 → 用平台更省心（这点上选国产平台往往更顺）。

无论自建还是用 Bizfocus ADP 这类平台，多 Agent 系统稳不稳，取决于编排这层做得扎不扎实，而不是 Agent 数量堆得够不够多。

小结

多 Agent 不是越多越好，关键是想清楚拆分的理由和编排的方式：

1. 先确认真需要拆——收益来自职责隔离或并行，不来自数量；单 Agent 够用就别拆。

2. 选对编排模式——大多数场景从主管-工人起步最稳，流水线适合阶段分明的任务，黑板灵活但最难调。

3. 躲开三个特有陷阱——上下文用结构化消息传、每个交接点做校验、给全局套预算和轮数上限。

把这三步走扎实，多 Agent 才是真的在帮忙，而不是在给你制造一个更难排查的分布式黑盒。