Skip to main content

006-2-Subagents

心智模型​

子代理模式通过一个中央主管 Agent 将其他 Agent 作为工具进行调用，所有路由和对话记忆均由主管掌握，子代理本身无状态。这种设计提供了强大的上下文隔离——每个子代理在干净的上下文窗口中被调用，避免主对话上下文膨胀。主管可并行调用多个子代理，子代理通常不直接与用户交互。

二级标题及内容​

  • 【关键特征】Key characteristics 集中控制（所有路由经主管）、子代理作为工具、可并行执行。注意：主管不同于路由，它是保持对话上下文的完整 Agent，而非单次分类步骤。

  • 【使用时机】When to use 适用于多个不同领域（如日历、邮件、CRM）、子代理无需直接与用户对话、需集中工作流控制的场景。简单情况优先用单 Agent。

  • 【基础实现】Basic implementation 核心是将子代理封装为工具：创建子代理 → 用 @tool 包装成工具函数 → 传给主 Agent。子代理接收查询，返回最终消息内容。

  • 【设计决策】Design decisions

    • 同步与异步：同步等待结果（简单但阻塞），异步后台执行（用户可继续对话）。
    • 工具模式：每个代理一个工具（细粒度控制）vs 单个调度工具（适合多团队，约定优于配置）。
    • 子代理规格：通过系统提示枚举、枚举约束或基于工具的发现方式来让主管知晓可用子代理。
    • 子代理输入：可通过 ToolRuntime 和自定义 State 控制子代理收到什么上下文。
    • 子代理输出：可通过提示指定返回格式，或用 Command 在代码中调整返回值。

  • 【检查点与状态检查】Checkpointing and state inspection 子代理默认使用继承的检查器（每次调用开始时为干净状态，支持中断，安全并行）。若需跨调用保持持久历史，可编译为 checkpointer=True。因子代理在工具函数内调用，LangGraph 无法静态发现它们，get_state 不会返回子代理状态。

最佳实践​

  • 工具描述是路由关键：子代理的名称和描述决定了主管何时调用它，应清晰、以行动为导向、明确适用场景。
  • 异步处理耗时任务：对于合同审查、数据批发等长时间任务，用后台执行模式保持对话的响应性。
  • 上下文隔离是核心价值：即使子代理与主管能力相同，通过子代理模式调用仍可在独立窗口执行多步任务，仅返回摘要，避免主线程臃肿。
  • 用调度工具支持多团队：当子代理数量多或由不同团队维护时，单调度工具 + 工具发现模式更易扩展。
  • 提醒子代理输出完整结果：主管只看到子代理的最终输出，应在提示中明确要求子代理将工具调用结果等包含在最终回复中。