这两年一聊到复杂任务很多人的第一反应是上多 Agent——一个负责规划、一个负责检索、一个负责写代码、再来一个负责审查听起来分工明确、很美好。但真把多 Agent 系统跑起来之后相当一部分团队会发现它不仅没比单 Agent 强反而更慢、更贵、更难调。问题往往不出在多 Agent这个方向上而出在拆分的时机和编排的方式。这篇就把多 Agent 里几件容易踩的事捋一遍什么时候才真该拆拆了之后用哪种编排模式以及多 Agent 特有的几个陷阱怎么躲。先泼盆冷水你可能并不需要多 Agent多 Agent 不是免费的。每多一个 Agent就多一份上下文传递的开销、一处可能出错的接口、一段需要排查的链路。所以拆分之前先问一句单 Agent 配好工具是不是就够了一个朴素但好用的判断标准任务能用一个角色 一组工具覆盖 →单 Agent。比如客服、单领域问答、固定流程的数据处理硬拆成多 Agent 通常是负优化。任务里存在职责天然冲突或需要并行的部分 → 才考虑拆。典型的是写和审——让同一个 Agent 既写代码又挑自己代码的毛病效果往往不如一写一审两个独立角色又比如要同时检索十个数据源并行比串行省时间。记住一点拆分的收益来自职责隔离或并行而不是来自Agent 数量多本身。三种常见编排模式真要拆常见的编排结构就那么几种按控制流的形状区分。主管-工人Supervisor-Worker一个主管 Agent 负责拆解任务、分派给工人、汇总结果。控制流清晰最常用也最好调。代价是主管是单点——它判断错了全盘皆错。流水线PipelineAgent A 的输出是 Agent B 的输入串成一条线。适合阶段分明的任务如抽取 → 清洗 → 总结。缺点是上游错误会顺着管子流到下游且天然没法并行。黑板/共享状态Blackboard多个 Agent 读写同一块共享状态谁该干活由状态触发。灵活适合不确定执行顺序的场景但调试难度也最高——你得能还原当时这块黑板长什么样。黑板共享状态Agent1Agent2Agent3流水线抽取清洗总结主管-工人主管工人A工人B绝大多数业务场景从主管-工人起步是最稳的——它的控制流最接近人能直觉理解的方式。下面是主管路由的一段示意注意它做的核心其实是把任务路由到合适的工人并把结果收回来defsupervisor(task,workers,llm,max_rounds8):state{goal:task,results:[]}for_inrange(max_rounds):# 主管基于当前进展决定派给谁、或者收工planllm.route(goalstate[goal],progressstate[results],availablelist(workers.keys()))ifplan.actionFINISH:returnsynthesize(state[results])workerworkers[plan.assignee]# 关键只把这个工人需要的那部分上下文传过去sub_resultworker.run(plan.subtask,contextplan.context_slice)state[results].append({by:plan.assignee,out:sub_result})returnsynthesize(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 干好自己那摊业务上而不是反复造调度器和消息总线或者对私有化、合规有要求 → 用平台更省心这点上选国产平台往往更顺。无论自建还是用 AgentCore 这类平台多 Agent 系统稳不稳取决于编排这层做得扎不扎实而不是 Agent 数量堆得够不够多。小结多 Agent 不是越多越好关键是想清楚拆分的理由和编排的方式先确认真需要拆——收益来自职责隔离或并行不来自数量单 Agent 够用就别拆。选对编排模式——大多数场景从主管-工人起步最稳流水线适合阶段分明的任务黑板灵活但最难调。躲开三个特有陷阱——上下文用结构化消息传、每个交接点做校验、给全局套预算和轮数上限。把这三步走扎实多 Agent 才是真的在帮忙而不是在给你制造一个更难排查的分布式黑盒。