多 Agent 系统怎么拆分角色？什么时候不该用多 Agent？
面试怎么回答
多 Agent 的收益主要是上下文隔离、并行、权限隔离和专门化，代价是成本延迟更高、交接时信息丢失、错误会传播、调试更难。所以我会先用单 Agent 做基线，只有当上下文明显过长、任务可以拆成独立子任务并行，或者需要不同权限隔离时才拆。常见拆法是编排者加执行者、固定流水线、生成加审查。线性的、上下文高度相关的任务，比如逐步排查一个失败任务，我更倾向单 Agent。拆了之后交接内容要结构化，每个子 Agent 的输出要可校验，全链路要有 Trace。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
「多 Agent」听起来很高级：一个负责规划，一个负责写 SQL，一个负责检查，一个负责写报告。但很多团队做完发现，多 Agent 比单 Agent 更慢、更贵、更难排查。面试官问这题，想听的是你对多 Agent 收益和代价的判断。
多 Agent 的真正收益
- 上下文隔离：每个子 Agent 只看和自己任务相关的信息，上下文更短、更聚焦；
- 并行：调研类任务可以同时让几个子 Agent 查不同方向，再汇总；
- 职责和权限隔离：写 SQL 的 Agent 只有只读权限，发布报告的 Agent 只能写指定位置；
- 专门化：不同子 Agent 可以用不同的提示词、工具，甚至不同的模型。
多 Agent 的代价
- 成本和延迟：调用次数成倍增加，每次交接都要重新组织上下文；
- 信息丢失：A 交给 B 的只是摘要，B 不知道 A 当时为什么这样决定；
- 错误传播：上游 Agent 的一个错误，下游会在它的基础上继续做；
- 难调试：失败时要看多条调用链，才能定位是哪一环出了问题。
常见的拆分方式
- 编排者 + 执行者：主 Agent 拆任务、分派、汇总，子 Agent 执行具体任务。适合可以拆成独立子任务的场景；
- 流水线：按固定顺序交接，比如「理解需求 → 生成 SQL → 校验 → 生成结论」，其实更像 Workflow；
- 生成 + 审查：一个生成，一个按规则检查，检查不通过就打回。
什么时候不该用多 Agent
- 任务本身是线性的、上下文高度相关，比如一步步排查一个任务失败；
- 单 Agent 加上合适的工具就能完成；
- 对延迟和成本敏感的在线场景。
一个经验法则：先用单 Agent 做出基线，确认瓶颈确实是上下文太长或任务可以并行，再拆。
拆了之后要注意
- 交接内容结构化：任务目标、已知事实、约束、期望的输出格式；
- 每个子 Agent 的输出要可校验；
- 全链路 Trace，能看到每个子 Agent 的输入输出和耗时。