多智能体不是一个「更高级」的形态，它是一笔交易：你用「拆开」换每个 Agent 脑子更小、更专一，代价是多出来的协调成本。所以判断标准只有一条——单个 Agent 是否已经因为工具太多、指令太杂而开始出错。没到这个程度就拆，是把分布式系统的复杂度硬套在简单问题上。
判断放开头：先有「一个 Agent 管不过来」的事实，再谈多智能体，顺序不能反。
什么时候拆
一个 Agent 管不过来的信号很具体：工具列表超过十几个，系统提示词里塞满了互相打架的指令，同一个词在不同场景下有不同含义。比如一个客服 Agent 既要查订单又要诊断技术故障，它手里同时有订单库和日志库两套工具，prompt 里「查一下」这三个字到底指哪个，模型自己都含糊。
这时候拆，收益才大于成本。拆的依据是领域边界，不是流程步骤：把「查订单」和「排障」拆成两个 Agent，各自只拿自己域的工具和指令。领域边界清晰，Agent 之间的接口才清晰；按流程步骤硬拆，拆出来的每个 Agent 都缺上下文，协调成本反而更高。
角色与路由
拆开之后多出来的那个问题，就是消息路由：用户一句话进来，谁来决定派给哪个 Agent。主流做法分集中式调度和点对点两种。绝大多数业务系统从集中式调度起步就够了：一个 supervisor（监督者）做纯分类，把请求派给对应 worker（执行者），worker 干完把结果交回来。
这里的关键是路由和干活分开。路由用一个很小的模型、把温度压到接近 0，只做意图识别，不碰工具、不碰数据；真正的业务逻辑放在 worker 里，可以用更强也更贵的模型。路由快、便宜、结果可复现，worker 专、贵、能力强，两层各管各的。
路由之外，消息本身也要有结构。每次 Agent 之间的传递，最好带上发送方、消息类型、关联 id 三样，不然出问题时你连「这条消息是谁发的、回给谁」都查不清。可观测从第一天就要做：每条消息、每次路由决策、每个 worker 的耗时和成败都记下来。多智能体最难的不是写 Agent，是出了事之后定位——没有这些日志，超过四五个 Agent 之后排查基本靠猜。
一个最小实现
下面是一个 supervisor 加两个 worker 的最小路由，不依赖任何框架，逻辑一眼能看完：
# router.py —— supervisor 分类 + worker 分域处理
def classify(query: str) -> str:
if any(k in query for k in ("订单", "退款", "支付")):
return "billing"
if any(k in query for k in ("报错", "崩溃", "日志")):
return "support"
return "general"
def handle_billing(query: str) -> str:
# 这里接订单查询工具，只暴露 billing 域的数据
return f"[billing] 已按订单域处理：{query}"
def handle_support(query: str) -> str:
return f"[support] 已转技术支持域处理：{query}"
def run(query: str) -> str:
route = classify(query)
return {
"billing": handle_billing,
"support": handle_support,
}.get(route, lambda q: f"[general] 直接回答：{q}")(query)
真实系统里，classify 换成一个小模型的 function calling，worker 换成各自独立的 Agent 实例，中间这条消息就是「路由」的全部含义。先把这一层写清楚、跑稳定，再往上加 Agent 数量，否则后面每加一个 Agent，协调逻辑都是乱的。
几个必踩的坑
第一是循环委派。如果 worker 之间还能互相派活，两个配错的 Agent 可能把同一个请求来回踢，直到预算烧完。解法是给委派设最大深度和超时，超了就升级到 supervisor 兜底，supervisor 保留最终拍板权。
第二是共享状态竞争。多个 Agent 同时读写同一份共享记忆或队列，没有版本控制就会读到过期上下文。解法是用追加写、按时间排序，关键状态改动走一个简单的共识，别让 Agent 各写各的。
第三是成本失控。单个 Agent 重试一次是可预期的，十个 Agent 各自重试，成本按指数放大。每个 Agent 单独设预算和硬超时，整条会话再设一个总上限，别让分布式重试把账单打爆。
第四是过度拆分。把每个微小步骤都拆成一个 Agent，协调开销比实际产出还大。角色要足够粗粒度，把相近能力归到同一个 Agent 里，让它内部处理复杂度，而不是每步都做一次跨 Agent 交接。
值不值得上
多智能体的收益在于「每个 Agent 足够小、足够专、边界足够清」，代价是引入路由、状态和观测三块新负担。如果你的单个 Agent 还没到工具爆炸、指令打架的程度，先别拆——把 prompt 写清楚、工具收敛一下，往往比上多智能体便宜得多。真到了拆的时候，从 supervisor 加两个 worker 开始，先把消息路由写稳，再谈别的。