考察点
Claude Code 的 subagent、各家 Deep Research 产品的「主研究员 + 子研究员」架构让这题升温很快。面试官想确认你理解子 Agent 的本质——不是为了「分工拟人化」，而是解决上下文窗口的隔离和并行问题，以及知道拆子 Agent 的代价。
参考答案
子 Agent 解决的真问题：上下文隔离
很多人以为子 Agent 是「模拟一个团队」，这是表象。本质问题是上下文窗口：主 Agent 跑一个复杂任务，如果所有中间过程（几十次搜索的结果、几万行日志、几百个文件的内容）都堆在主上下文里，三件事会发生——窗口撑爆、注意力被无关信息稀释（中间信息把最初的目标顶没了）、token 账单爆炸。
子 Agent 的解法：把「脏活」派出去。子 Agent 有独立的上下文窗口，在自己的窗口里随便折腾——搜二十次、读十个文件、试错五轮——最后只把压缩后的结论（几百字）返回给主 Agent。主上下文始终干净。Claude Code 文档里说得很直白：subagent 的首要价值就是 context isolation，其次才是并行和专精 prompt。
什么时候拆，什么时候不拆
该拆的信号：
- 子任务的中间产出量大但结论量小。典型如「在整个代码库里找所有调用这个废弃 API 的地方」——过程可能 grep 几百个文件，结论就是一个清单。
- 多个子任务互不依赖，可以并行。Deep Research 类产品同时派 5-10 个子 Agent 各查一个子问题，端到端时间从十几分钟压到两三分钟。
- 子任务需要专门的知识/prompt，混在主 Agent 里会稀释主任务。比如「安全审查」子 Agent 带一套专门的安全 checklist。
不该拆的情况：
- 子任务之间强耦合、需要频繁共享中间状态——拆开之后通信成本比省下的上下文还贵。
- 任务本身就小，单 Agent 十步以内能搞定。拆子 Agent 有固定开销（每个子 Agent 要重新建立上下文、重新理解任务），小任务拆完反而更慢更贵。
- 简单线性流程，用 Workflow 节点更便宜。
设计要点
1. 任务契约要自包含。 子 Agent 看不到主 Agent 的上下文，派活时必须把完成任务所需的全部背景写进指令里：目标、约束、产出格式、 deadline（步数上限）。「调查一下 X」这种指令必死，「调查 X 在 v2.3 之后的行为变化，输出 300 字内结论 + 引用来源」才合格。
2. 结果协议要结构化。 规定子 Agent 返回的格式：结论、关键证据（引用而不是全文）、置信度、未完成事项。禁止返回过程轨迹——那是子 Agent 自己的日志，不是给主 Agent 的。
3. 调度要有成本意识。 每拆一个子 Agent，代价是：一份新的系统 prompt 开销 + 独立的 LLM 调用链 + 结果汇总的调用。Anthropic 披露其多 Agent 研究系统 token 消耗约为普通聊天的 15 倍量级，大头就在子 Agent 的扩张上。所以主 Agent 的调度 prompt 里要明确「能自己三步内解决的不要派子 Agent」。
4. 失败要有归宿。 子 Agent 超时/步数耗尽/返回不合规结果，主 Agent 要能感知并决策：重派、自己接手、还是放弃该支线。别让子 Agent 的失败无声消失。
和多 Agent 系统的关系
子 Agent 是 Multi-Agent 的一个特化形态：星型拓扑、生命周期随任务、上下文隔离、结果单向回传。它比通用的对等协作简单得多，可控性好得多，也是目前生产环境验证最充分的多 Agent 形态。如果你的需求用子 Agent 就能覆盖，就别去碰对等的 Multi-Agent 协作。
可能的追问
- 「子 Agent 之间能互相通信吗？」 主流设计是不能（星型拓扑），通信都经过主 Agent 中转。开放互相通信会引入路由和循环问题，复杂度陡增，收益通常不值。
- 「子 Agent 的结果压缩怎么做？」 硬约束输出格式（结论 + 引用 + 字数上限），必要时主 Agent 端再做一次摘要；关键原始数据写共享存储，只回传句柄。
- 「并行子 Agent 的结果冲突了怎么办？」 主 Agent 负责仲裁：按证据质量、来源时效性裁决，或把冲突如实呈现在最终结果里，不强行合并。