多 Agent 架构取舍：客服场景为什么不用多 Agent
面试高频追问：你做了智能客服，为什么不用多 Agent 架构？ 项目背景：mewhelp 电商智能客服（Workflow 编排 + 单主力 Agent） 适用面次：二面深度 / 三面综合（架构权衡类）
一句话结论（先抛这个）
多 Agent 划算的场景主要就三类；而客服一次会话只有一个用户、一条主线，拆开反而上下文不共享、token 翻倍、响应变慢 —— 客服偏偏最在意首句响应速度。 所以 mewhelp 用 Workflow 把流程和硬约束固化下来，中间收敛到一个主力 Agent；分工也做了，但用确定性节点实现，更可控也更好排查。
一、多 Agent 真正划算的三类场景
| 场景 | 判断依据 | 典型例子 |
|---|---|---|
| 子任务能并行跑 | 拆开后能同时推进，直接缩短总耗时 | 深度调研：多路检索并行 |
| 子任务上下文太脏，要隔离 | 子任务产生的中间内容会污染主上下文 | 编程 Agent：大量代码 / 报错堆栈塞进主上下文 |
| 角色差异大到一份 prompt 装不下 | 不同角色需要不同的 system prompt 与工具集 | 调研 Agent vs 编程 Agent |
记忆口诀：并行、隔离、角色差异 —— 三条至少占一条，拆才划算。
二、客服场景为什么不适合拆
- 一次会话就一个用户，只有一条主线 —— 前后决策必须保持一致。
- 拆开后上下文不共享 —— 容易出现前后口径不一致（A agent 承诺的，B agent 不认账）。
- token 翻倍 —— 每个 Agent 各自携带上下文，成本直接上升。
- 响应变慢 —— 多跳调度增加延迟；而客服场景最在意首句响应速度（首句慢 = 体验崩）。
三、我们的做法（mewhelp）
| 设计点 | 具体实现 |
|---|---|
| 流程与硬约束 | 用 Workflow 固化下来，不靠模型自由发挥 |
| 执行主体 | 中间收敛到一个主力 Agent |
| 分工 | 意图识别、分流、退款取单 —— 都做了 |
关键对比：
- 在多 Agent 架构里，这些分工会做成 「路由 Agent + 几个专家 Agent」。
- 我们用确定性节点实现 —— 更可控、更好排查（出问题能直接定位到节点，不用猜是哪个 Agent 的决策）。
四、追问预案：什么时候会上多 Agent？
面试官若追问"那你什么时候会用多 Agent"，答 handoff（会话交接）：
- 分诊判定是退款 → 就把整个会话交给专门的退款 Agent；
- 它有自己的 prompt 和工具集；
- 只是现在这个规模还用不着。
这句话的得分点：既证明了你懂多 Agent 的演进方向，又体现了按规模决策、不为了架构而架构的工程判断力。
五、加分延伸（可选补充）
- 判断标准不是"能不能拆"，而是"拆的收益是否大于成本"： 并行收益 / 隔离收益 vs token 翻倍 + 延迟增加 + 一致性风险。
- 演进路径（体现架构演进思维）：
Workflow 确定性节点→单点 handoff→真正多 Agent，按需升级，不做过度设计。
六、避坑提醒
- 别说"多 Agent 不好" —— 要说"当前场景不划算"，体现的是权衡而非否定。
- 别说"我们没做分工" —— 分工做了，只是用确定性节点而非 Agent 实现，这是加分项。
- 被追问性能数据时不要编数字；真实数字需从项目监控中取，没取到就如实说"以监控数据为准，我这边暂未带具体值"。
关联笔记：22多Agent场景边界与部署模式-串行与层级分发（正向补全：本篇讲"为什么不用"，22 号讲"什么时候用、用了怎么部署"）