主管与子 Agent：任务委派与结果验收

主管模式由一个 Agent 负责整体任务，把其中一部分委派给子 Agent，收到结果后继续决定下一步。主管可以根据新发现增加、缩小或调整子任务；子 Agent 在自己的上下文中调用工具，完成交付后把控制权交回主管。这种结构也称为 Supervisor 或 Orchestrator-Workers。

例如，用户要求比较 A、B、C 三款手机的续航、售价和售后。主管可以分别委派三个资料查询任务，自己保留比较口径和最终回答的责任。如果 B 的售后资料不完整，再为 B 发起一次有范围的补查。

这里有两层执行循环：主管决定“接下来委派什么、已有结果够不够”，子 Agent 决定“为了完成这一项，现在查哪个页面、调用哪个工具”。它们可以使用相同的模型；分开的任务范围和运行上下文让两层循环各自处理不同的问题。

把一个 Agent 当作工具调用

普通工具收到参数后执行一段程序。子 Agent 工具收到任务后，会启动自己的模型与工具调用循环，最后返回一份结果。对主管而言，它仍然是一次带输入和输出的工具调用，但运行时间、内部步骤和费用可能远多于普通函数。

用户请求
   ↓
主管读取目标与已有结果
   ↓
决定调用 research_product，填写型号与查询要求
   ↓
执行程序校验参数和可用预算，启动子 Agent
   ↓
子 Agent：读任务 → 查询 → 读结果 → 补充查询 → 返回资料
   ↓
主管验收资料 → 继续委派、要求补查，或生成最终回答

research_product 可以暴露成一个专用工具，也可以通过统一的委派工具选择已登记的执行者。执行程序需要限定可选 Agent 和工具权限，不能直接运行模型临时编造的 Agent 名称或工具代码。

子 Agent 返回以后，主管仍负责这一轮用户交互。若让另一个 Agent 接管后续对话，则属于Handoff，控制流程与这里不同。

先统一比较口径，再分派查询

三个子 Agent 各查一款手机时，需要使用一致的比较条件。若 A 查到的是指定版本，B 查到的是旧款；一方使用厂商视频播放时长，另一方使用第三方混合使用测试，这些资料就无法直接排成同一张“续航排名”。

主管先把用户要求整理成共同输入：

项目	子任务需要遵守的要求
产品	确认完整型号、销售地区和存储版本
售价	记录所查渠道、查询时间及优惠条件
续航	保留测试来源与测试条件；不同条件的结果分别列出
售后	查对应销售地区的保修范围、期限和服务入口
交付	返回已确认资料、来源定位和仍缺少的字段

接下来才为 A、B、C 分别创建子任务。以 B 为例，应用可以约定这样的输入：

{
  "task_id": "research-B",
  "agent": "product_researcher",
  "goal": "收集手机 B 的售价、续航和售后资料",
  "scope": {
    "model": "B",
    "storage": "256 GB",
    "region": "中国大陆"
  },
  "requirements": [
    "价格附渠道、查询时间和优惠条件",
    "续航附测试来源及条件",
    "售后资料须对应指定销售地区"
  ],
  "deliverable": "资料条目、来源定位、未确认字段",
  "max_tool_calls": 6
}

task_id 用来关联派发记录和返回结果，max_tool_calls 由执行程序检查。把数字写进提示词只能提醒模型，无法阻止它超过限制。更完整的任务字段与上下文组织，见任务契约与上下文交接。

主管不需要把其他两款手机的全部查询历史发给 B 的子 Agent，但必须传递影响比较的共同条件。如果查询途中用户改变地区或版本，主管要更新相关任务，已有资料也要检查是否仍适用。

从返回结果走到验收与补查

子 Agent 完成一轮运行，只说明它已经停止调用工具，不能据此判断用户要求全部满足。主管要将返回内容对照任务要求，检查每项资料能否用于比较。

假设三个任务按以下过程返回：

当前结果	主管检查到的问题	接下来的动作
A 的资料齐全	价格与参数对应同一配置，来源可定位	接收结果，保留引用
B 返回了价格和续航，保修资料来自其他地区	售后信息不适用于指定销售地区	保留已验证部分，只补查售后
C 的续航数字来自另一套测试	数字本身可用，但不能与 A、B 直接排名	保留测试条件，分别呈现，不要求子 Agent 改出一个可比数字

给 B 的补查应直接指出缺口：

保留已提交的价格和续航资料。当前保修来源适用于其他地区，请查询中国大陆销售版本的保修说明，返回对应条款和来源；未找到时明确说明，最多再使用两次查询。

这比“资料不够好，再查一下”更容易收敛。补查有明确对象，不必让子 Agent 重做已经完成的全部工作。补查结果还要关联原任务，主管才能知道它补齐了哪个字段。

如果仍未找到 B 的售后资料，最终对比表可以把该项标为未确认，说明因此无法完成售后比较。主管不应根据另一地区的制度替 B 补出答案，也不能仅凭子 Agent 写了一句“已核实”就接受结论。

验收适合拆成两部分：字段是否齐全、型号是否一致、链接是否存在，可以由程序先检查；来源能否支持结论、两组续航条件能否比较，需要回到证据判断。模型可以辅助后者，但不能替代原始资料。

主管维护任务记录，子 Agent 交付自己的结果

主管需要持续看到每项任务的范围、当前状态、交付物和未解决问题，否则容易重复派发已经完成的工作。子 Agent 通常只需要自己的任务上下文；每个执行者都读全局聊天历史，会重复消耗上下文，也容易把其他任务的判断当成自己的事实。

主管任务记录
  research-A：已验收 → A 的资料与来源
  research-B：待补查 → 保留价格、续航；缺少适用地区的保修依据
  research-C：已验收 → 续航测试口径不同，汇总时分别呈现

子 Agent B 的输入
  B 的型号与地区 + 已保留的资料 + 本次售后补查要求

记录中的“已验收”表示产物符合该子任务的要求，未必表示产品符合用户偏好。例如，查明某项服务不在保修范围内，也可以完成查询任务。把业务结果和执行状态分开，主管才能据此继续比较。

子 Agent 可以返回建议，任务状态和最终答案应通过约定的写入路径更新。多个执行者直接覆盖同一个全局记录时，会出现结果丢失或旧结论覆盖新结论，具体见共享状态与黑板协作。上下文隔离也不自动限制工具权限，执行程序仍要按子任务授予访问范围。

动态委派的收益与代价

主管模式适合任务范围会随查询结果变化、各子问题又能独立交付的工作。例如，发现某款手机售后资料缺失后，临时增加地区核查，比预先枚举所有补查路径更方便。

如果 A、B、C 的信息都能从一个结构化接口中直接读到，普通工具批量查询就足够。把一次确定的价格换算也包装成 Agent，会增加不必要的模型调用。子任务需要选择信息源、处理不完整资料或决定下一步动作时，再考虑为它提供独立运行循环。

主管还可能成为瓶颈。它既要阅读多份产物，又要判断缺口；分得太细，时间会花在反复传递上下文和验收上。可以先按“完成一个有意义的交付物”划分任务，再由子 Agent 处理内部工具步骤。相互独立的子任务可并行执行，有先后关系的部分则要保留依赖。

运行边界包括允许的委派次数、子任务预算和总截止时间。预算耗尽时，主管应交付已验证结果及缺失项，不能持续换一个执行者重做同一问题。超时、重试和取消的具体状态转换见子任务生命周期与失败恢复。

参考：Anthropic：Building effective agents，Orchestrator-workers；OpenAI Agents SDK：Agents as tools。