先这样答
多智能体系统就是把一个复杂任务交给多个 Agent 分工完成：每个 Agent 有自己的角色定义、自己的工具集、自己的上下文窗口，通过消息传递协作——比如写代码的 Agent、审代码的 Agent、管部署的 Agent，各自盯着自己那段，互相递结果。
先回答「什么时候需要」，比讲概念更重要。拆多 Agent 的正当理由有三个。一是上下文放不下：一个任务要读的资料、要调的工具太多，塞进一个窗口既挤爆又互相干扰，拆开后每个工位只装自己需要的东西。二是职责冲突：让一个 Agent 又写代码又审代码，它审自己写的东西时很难客观，分给两个 Agent，各自的角色提示词更纯粹。三是专业隔离：不同环节需要不同的工具权限和不同的模型档位，拆开后各自配置，安全边界和成本都更合理。
对应的反面同样要讲：多数任务不需要多 Agent。多 Agent 引入通信成本、状态同步问题、错误传播链，单 Agent 能解决的场景上多 Agent 是自找麻烦。一个实用的自检问题：拆开是为了「各自拿到干净的上下文和明确的职责」，还是仅仅因为「听起来更厉害」？答案经常是前者不成立。
面试官会怎么追问
- 多 Agent 一定要用专门框架吗？ 不一定。两个 Agent 一问一答的简单协作，几十行代码就够；框架（LangGraph、AutoGen 等）的价值在复杂编排、状态管理和断点恢复，任务复杂度到了再上。
- Agent 之间怎么分工最常见？ 按流程阶段分（写/审/测）、按专业领域分（检索/分析/写作）、按对象分（每个数据源一个 Agent），前两种最常见。
- 拆多了会怎样？ 每次交接都是信息损耗，链路越长累积越多；错误在链路上传播放大；成本轮次也涨。所以拆分粒度宁粗勿细，粗了还能再拆，细了合回来很痛。
回答的坑
- 把 Multi-Agent 说成必须的先进架构。能不能讲清「什么时候不该拆」，才是这道题的区分度。
- 只讲协作不讲代价。通信损耗和错误传播不提，说明没维护过真实的分布式 Agent 系统。
—— 本题完 ——