kimichat 中文文档 下载 App

300 个子智能体怎么并行——主 Agent 调度机制详解

为什么是 300

300 不是一个随意的数字——它是经过实际测试的平衡点：

300 是"单次任务足够覆盖大部分并行需求 + 调度开销合理"的上限。对于绝大多数任务，主 Agent 不会真的用完 300 个，而是按需要动态创建——可能用 50 个、可能用 200 个、只有真的需要才顶到 300。

主 Agent 调度的四阶段

阶段 1：规划 → 阶段 2：创建与分配 → 阶段 3：监控与协调 → 阶段 4：汇总与验证

阶段 1：规划（主 Agent 独立完成）

主 Agent 先自己思考：

  1. 用户的目标是什么？
  2. 这个目标可以拆成多少个可并行的子任务？
  3. 每个子任务需要什么输入上下文？
  4. 子任务之间有什么依赖关系（A 的输出是 B 的输入）？
  5. 预估总共需要多少个子 Agent？

关键：主 Agent 在规划时会主动控制并行度——如果 30 个子 Agent 足够，就只创建 30 个。不会为了"用满额度"而浪费资源。

阶段 2：创建子 Agent 与分配

主 Agent 为每个子 Agent：

  1. 分配唯一 ID
  2. 下发任务说明：这是你要做的事，目标是 X
  3. 注入必要上下文：前序子 Agent 的结果、用户给的参考资料、全局约束
  4. 启动执行

上下文注入

子 Agent 拿到的上下文不是整个对话历史——主 Agent 会根据子任务的需要，裁剪和压缩上下文，传递最必要的信息。这既节省了 token，又让子 Agent 聚焦自己的任务。

阶段 3：监控与协调

主 Agent 在所有子 Agent 执行过程中：

阶段 4：汇总与验证

所有子 Agent（或关键子 Agent）完成后：

  1. 收集所有输出
  2. 去重合并：多个子 Agent 搜到相同信息 → 合并为一条
  3. 交叉验证：子 Agent A 和 B 的结果冲突 → 标记并处理
  4. 格式化：按最终交付物的格式整理
  5. 生成最终交付物

子 Agent 的独立能力

每个子 Agent 不是一个"工具函数"——它本身就是一个小的 Kimi Agent：

这意味着子 Agent 不是机械地执行主 Agent 给的指令，而是可以灵活应对子任务中的变化。

实际运行示例

任务：全行业 AI 芯片竞品矩阵

主 Agent 规划

目标：生成 2025 年 AI 芯片行业竞品矩阵

拆解为以下可并行子任务：

  1. 搜索 NVIDIA 产品线（子 Agent 1）
  2. 搜索 AMD 产品线（子 Agent 2）
  3. 搜索 Intel 产品线（子 Agent 3）
  4. 搜索 Google TPU（子 Agent 4）
  5. 搜索 AWS Trainium / Inferentia（子 Agent 5）
  6. 搜索国产厂商（华为 / 海光 / 寒武纪 / 壁仞，每个一个子 Agent：6~9）
  7. 搜索最新融资和市场动态（子 Agent 10）
  8. 交叉验证前 10 个的结果（子 Agent 11~15，每个交叉验证 2~3 个主搜索结果）

总共需要约 15 个子 Agent，远低于 300 上限。

并行执行

15 个子 Agent 同时启动，各自搜索不同对象。每个子 Agent 内部还可能进一步调用搜索工具。

汇总

15 个子 Agent 完成后，主 Agent 收集所有结果 → 交叉验证子 Agent 11~15 的冲突检测结果 → 整理成矩阵 → 生成 Excel → 生成 Markdown 报告。

为什么不是 4.5× 并行 300 次

理论上 300 个并行子 Agent 应该是 300× 加速，但实际是 4.5×，原因：

  1. 主 Agent 开销：规划 + 协调 + 汇总本身需要时间（这部分不能并行）
  2. 串行依赖：有些子任务有依赖关系（B 要等 A 的输出）
  3. 外部限制：搜索 API 可能限流、数据源有访问速度
  4. 上下文传递：主 Agent 给每个子 Agent 注入上下文需要时间

4.5× 是相对于同样复杂度的单 Agent 任务的观测值。对于"上千条数据、数十来源"的任务，实际体验会好于这个数字（因为单 Agent 可能超时或中途放弃）。

继续阅读