单 agent 够用时，别急着拆成多智能体

[林小北]

先看任务有没有并行价值。客服问答大部分是短链路，拆四个角色以后延迟和出错点都上来了。

[melo]

我这边踩过。多 agent 不是自动变聪明，是把协调成本显式化。没有评测集时，看起来像架构升级，实际是更难定位谁错。

[半截薯条]

但也不能一刀切。我做合同审核时，单 agent 会一边找条款一边下结论，容易把证据和判断混在一起。拆资料员和审校员后，至少能强制引用来源。

[阿航]

这个例子成立。关键不是“多个智能体”，是“边界让错误更容易被发现”。如果拆完还是共用同一段 prompt，没意义。

[qwer_asdf]

我觉得很多团队把 tool call 当多 agent 讲。一个 agent 调 search、db、browser，不等于多智能体。

[小蓝]

是的。多 agent 至少要有角色状态、责任边界、交接内容，不然只是函数名比较多。

[不想写周报]

我们内部最后定了个粗规则：单步工具链先单 agent，跨资料源、跨人审、跨权限域再考虑多 agent。

[Grace]

还有上下文污染问题。单 agent 做长任务，前面探索失败的信息会一直跟着它。拆子任务有时能把噪音隔开。

[小吴]

但拆开后另一个问题来了，子 agent 不知道全局约束。资料员为了召回会塞一堆边缘材料，主控反而更乱。

[oneMoreTry]

我们给资料员输出加了格式：事实、来源、置信度、未覆盖问题。别让它写建议。

[陈一]

审校员也不能只是“请检查”。要给它失败清单，比如未引用、越权建议、把猜测当事实、没有说明不确定性。

[latte404]

ReAct 那类思路更像单 agent 内部的思考和行动交替，不等于说生产里必须多角色化。

[林小北]

总结成一句：先证明单 agent 的错误类型不可接受，再用拆分去卡住错误，不是为了赶时髦。

[小周]

收到。我先拿 50 条真实客服问题做单 agent 基线，记录错因，再看哪些错因适合拆角色。