先这样答
我的选型立场很明确：从单 Agent 起步，多 Agent 是应对复杂度的手段，不是架构上的追求。理由是多 Agent 的每一项好处都附带系统性代价：隔离上下文换来的是交接损耗，职责分离换来的是通信协议，专业分工换来的是运维面翻倍。没有对应收益时，这些代价全是净亏。
什么时候该拆？我盯三个信号。信号一，上下文瓶颈：单窗口里塞了检索资料、多工具结果、长对话，模型开始丢细节、混淆指令。注意要先确认是上下文工程没做好（该压缩的没压缩），真撑不下去了才拆。信号二，职责污染：一个 Agent 身上叠了太多角色，写代码的同时要审自己的代码，分析数据的同时要负责对外沟通，角色提示词越长越失焦。信号三，隔离需求：不同环节需要不同的工具权限（能读生产库的不能同时能写）或不同的成本档位（简单提取用小模型，复杂推理用大模型）。
拆的时候有两条经验。先粗后细：先拆成两三个大块（比如「调研」和「执行」），跑顺了再考虑细拆；一上来五个 Agent 的系统多半会败在协调成本。接口先行：拆分前先写清楚两个 Agent 之间的交接契约：输入什么、输出什么、验收标准是什么，契约写不出来说明这个拆分还没想清楚。
最后补一个判断技巧：把单 Agent 的痛点列出来，逐条问「多 Agent 能解决吗」。能指着具体痛点说清收益的，拆；只说「多 Agent 更强大」的，不拆。
面试官会怎么追问
- 拆完发现更乱了怎么办？ 有回滚预案：Agent 间的接口本来就是结构化消息，把两个 Agent 合并回一个，等于把两段提示词拼回来，接口层不用大动。这也是「接口先行」的另一层意义。
- 有没有必须多 Agent 的场景？ 有两类接近必须：一是工具权限天然互斥的安全隔离场景；二是物理上跨系统的协作，不同团队的 Agent 通过协议协作，本来就不可能合成一个。
- 单 Agent 的上下文优化和多 Agent 怎么权衡？ 先做便宜的：压缩、裁剪、状态外置能解决就不拆；这些手段做到头还有缺口，才用拆分换干净的上下文。
回答的坑
- 把「人多力量大」当选型理由。多 Agent 的动机是上下文、职责、权限三个工程问题，不是算力叠加。
- 没有回滚思路。拆分是可逆的架构决策才敢做，这一点说出来很加分。
—— 本题完 ——