SchemaX协议是一等公民
RSSGitHub
← Blog

第5章：构建 SubAgent

把任务拆成子问题，交给更细分的 Agent 单元去执行。

AI Agent

从零构建理解Agent-05：SubAgent 的第一步，从必要性到最小闭环

这一节不追求“多智能体炫技”，只做一件事：

  • 讲清楚为什么要引入 SubAgent
  • 给出可落地的最小闭环
  • 明确第一版边界

第一部分：为什么需要 SubAgent？

第4章解决的是“Agent 怎么和外界交互”。 第5章要解决的是另一个工程问题：

当任务复杂度上来后，如何控制上下文噪声、工具失控和执行链路膨胀。

单 Agent 在小任务里足够好用，但在长链路任务里会暴露三个问题：

  1. 上下文污染
  2. 工具调用膨胀
  3. 主目标被局部任务拖偏

1.1 上下文污染

用户只问一句：“这个项目用什么测试框架？” 主 Agent 可能做很多中间动作：读文件、搜索、跑命令、重试。

如果这些细节都长期留在父会话，后续问题会越来越“重”。 问题不在模型本身，而在上下文里混入了大量一次性噪声。

1.2 工具调用膨胀

局部任务常常需要试错。如果全都在父链路里执行，失败、重试、候选路径这些细节会占用父会话带宽，影响后续判断。

1.3 目标漂移

父 Agent 负责“主问题的完成”。 但局部任务（例如“找配置文件并确认版本”）会把推理注意力吸走。

SubAgent 的价值不是“更聪明”，而是“把局部复杂度隔离出去”。

一句话：

SubAgent 是父 Agent 的局部任务隔离器，不是新的主流程控制器。

第二部分：既然需要 SubAgent，最小闭环是什么？

如果只保留最小可用能力，闭环只需要 4 步：

Parent agent
  |
  | 1. 决定把一个局部任务外包出去
  v
Subagent
  |
  | 2. 在自己的上下文里读文件 / 搜索 / 执行工具
  v
Summary
  |
  | 3. 只把最终摘要或结果带回父智能体
  v
Parent agent continues

2.1 作为工具暴露，而不是写死分支

主 Agent 不应该被硬编码成“遇到 X 必须走子代理”。 更稳妥的方式是把 SubAgent 暴露为标准工具 SubTask，让模型在推理中自主选择是否调用。

最小参数：

parameters: {
  task: string,
  contextMessages: string[],
  allowedTools: string[]
}

三项参数对应三项控制：

  1. task：限定子任务目标，降低目标漂移
  2. contextMessages：只给必要上下文，保证干净启动
  3. allowedTools：限制执行边界，避免工具失控

2.2 最小闭环的验收标准

  1. 主 Agent 能调用 SubTask
  2. 子 Agent 使用新上下文执行（不是继承父历史）
  3. 子 Agent 只能使用过滤后的工具
  4. 子 Agent 返回摘要结果，不返回完整 transcript

结论：

最小闭环不是“能调子代理”，而是“能调、可控、可收敛”。

第三部分：闭环之后，边界要先想清楚什么？

3.1 上下文是否隔离

必须回答：子 Agent 是“新消息启动”，还是“继承父历史”？

第1版建议：

  1. 子 Agent 只接收 contextMessages + task
  2. 默认不继承父会话全量 messages
  3. 返回给父 Agent 的只有摘要结果

3.2 SubAgent 是主动还是被动调用

有两种模式：

  1. 被动：仅用户明确要求时调用
  2. 主动：主 Agent 自主判断何时调用

第1版建议：

  • 采用“主 Agent 主动决策 + 工具化调用”的模式
  • 但保持触发条件保守，避免“能用就调用”

3.3 是否允许无限递归调用

如果子 Agent 还能再调 SubTask，会带来递归深度失控风险。

第1版建议：

  1. 子工具白名单中默认不包含 SubTask
  2. 若未来开放递归，必须加 maxDepth 与超时预算

3.4 Parent 与 SubAgent 的协议是什么

第1版可以用一个最小协议：

输入协议（Parent -> SubAgent）：

  1. task：这次子任务要完成什么
  2. contextMessages：必须背景，不超过固定条数或字符
  3. allowedTools：允许的工具集合

输出协议（SubAgent -> Parent）：

  1. summary：3-6 行摘要
  2. key_facts：关键事实列表（可选）
  3. status：success / failed

如果暂时不做结构化对象，至少保证返回文本里有：

  1. 做了什么
  2. 关键信息
  3. 结论/失败原因

3.5 子任务完成后，父 Agent 到底拿什么继续推理

核心原则：

  • 父 Agent 拿“结论层信息”，不拿“过程层噪声”

也就是：

  1. 拿摘要
  2. 必要时拿证据片段（短）
  3. 不回灌完整工具调用流水

第四部分：扩展思考（从 SubAgent 走向 Multi-Agent）

这一节其实已经触到 multi-agent 的设计入口：

  1. 任务分解：谁负责分解，按什么粒度分解
  2. 调度策略：串行还是并行，何时合并结果
  3. 共享记忆：子代理是否共享记忆池，如何做隔离
  4. 失败恢复：子任务失败后是重试、降级，还是换代理
  5. 评估体系：如何评估“多代理比单代理更好”

建议阅读（按优先级）

  1. ReAct（Yao et al., 2022） : 理解“推理-行动”闭环，是工具型 Agent 的基础。

  2. Toolformer（Schick et al., 2023） : 理解模型如何学习何时调用工具。

  3. HuggingGPT（Shen et al., 2023） : 经典“控制器 + 专家模型”多代理雏形。

  4. MetaGPT（2023） : 角色化多代理协作的工程化尝试。

  5. AutoGen（Microsoft, 2023） : 会话型多代理框架，适合看代理间通信模式。

  6. CAMEL（Li et al., 2023） : role-playing 方式的多代理协作与对齐问题。

  7. OpenAI Agents SDK 文档（最新） : 从“概念”落回“可实现 API 边界”的关键参考。

本节小结

第5章第一部分到第四部分，可以收敛成一句话：

SubAgent 的核心不是“多一个 Agent”，而是“把局部复杂度隔离成可控闭环，并用清晰协议接回主链路”。

下一节可以继续：

  1. 什么时候触发 SubTask（触发策略）
  2. 什么时候不该触发（反例）
  3. 如何把摘要升级为结构化返回（JSON schema）