Agent SDK 中的多代理系统遵循一个清晰的模式：协调者决定需要做什么，子代理做实际的活。协调者有 Task 工具用于委派，子代理有角色专属的工具用于执行。
AgentDefinition：子代理的蓝图
子代理通过 AgentDefinition 对象定义，有三个关键字段：
description— 说明这个 agent 的用途。协调者读这个来决定哪个子代理适合当前任务。system_prompt— 角色专属的行为指令。研究 agent 和分析 agent 的指令不一样。allowed_tools— 能力限制。研究者拿到 WebSearch + Read，分析者拿到 Read + Grep。每个子代理只有它需要的工具。
子代理不继承协调者的配置。每个 AgentDefinition 独立指定自己的 system_prompt 和 allowed_tools。这是有意为之——角色专属的专业化需要角色专属的配置。
Task 工具：委派怎么运作
协调者的 allowed_tools 里必须有 "Task" 才能派生子代理。没有 Task，即使提供了 AgentDefinition，协调者也无法委派。
模式如下：
- 协调者有
allowed_tools=["Task", ...]和一组 AgentDefinition - 协调者分析传入的请求
- 协调者用 Task 工具把子任务委派给合适的子代理
- 子代理用自己的工具执行并返回结果
- 协调者综合结果
为什么要限制子代理的工具？
给每个子代理所有工具就失去了意义。如果研究者和分析者都有 WebSearch + Read + Grep，它们的角色之间就没有结构性边界。研究者可能开始分析而不是搜索，分析者可能开始搜索而不是分析。
工具限制强制执行角色边界。研究者做不了详细的代码分析，因为它没有 Grep。分析者做不了网页搜索，因为它没有 WebSearch。这是结构性的专业化，不是模型可能忽略的基于 prompt 的建议。
协调者 vs 子代理：结构性差异
协调者通过 Task 工具进行编排——它决定需要做什么、谁来做。子代理通过角色专属工具执行——它们做专业的活。同一个模型可以驱动两者，但工具配置让它们的角色有了根本性差异。
协调者不需要”更强大的”模型。差异在于配置（Task 工具 vs 专属工具），不在模型能力。
一句话总结： 子代理通过 AgentDefinition 定义，有自己的 system_prompt 和 allowed_tools——协调者需要 Task 工具才能委派，每个子代理只拿到其角色所需的工具。