SDK Fleet 并行协作

Fleet 让一个父会话分解工作，通过 runtime 的 task 机制并行派发多个 subagent，再合并结果。适合按文件、包或独立研究主题拆分；如果后一步必须等前一步结果，或多个任务会同时改同一文件，应先明确依赖和合并责任。

启动 Fleet

当前入口位于生成的会话 RPC 中，属于实验性能力。依赖它的应用应固定相匹配的 SDK 和 CLI runtime 版本：

const result = await session.rpc.fleet.start({
  prompt: "Review each independent package, then combine the findings.",
});
if (result.started) {
  console.log("Fleet mode started");
}

协议方法名是 session.fleet.start，可选 prompt 会与 runtime 的 Fleet 协调指令组合。官方专题核实了 TypeScript、Python、Go、.NET、Rust 的原生绑定；该分支未发现 Java 对应绑定，不能据此补写 Java 调用。

Plan UI 也可在用户批准计划后返回退出动作 autopilot_fleet。其余动作包括 exit_only、interactive、autopilot；单个自主工作者使用 autopilot，不应把它与并行 Fleet 当作同义词。

用显式任务状态协调

官方 runtime 指导使用 SQL todos 保存共同协调状态：todos 包含 id、title、description、status，todo_deps 记录 todo_id 与 depends_on。状态通常从 pending 进入 in_progress，最后为 done 或 blocked。

每个工作者认领一个依赖已经完成的任务，只修改自己的范围，把结果写入约定输出，再更新状态。父代理负责寻找就绪任务、处理阻塞并验证组合结果。

这是一种官方介绍的协调模式，但 SQL 表是否构成稳定的 SDK 扩展契约仍未明确。应用不能只因看到示例表名就假定可以直接操作任意版本 runtime 的内部数据库，也不应把普通查询当成并发认领的原子保证。

提供完整任务上下文

派发时给出文件路径、任务目标、约束、验证方式和预期返回内容；官方提醒子代理调用之间不保留可依赖的共享思考状态。让每个工作者报告修改、验证和未解决问题，再由父代理检查不同工作者的假设是否一致。

并行任务应各有明确负责人。只派发一个后台子任务通常没有并行收益，可使用同步子代理；需要串行验证的环节也应保留为依赖步骤。

通过会话事件观察生命周期

使用 subagent.started、subagent.completed、subagent.failed 等事件展示进展，并处理失败，不把 started 当作完成。

runtime 的 Hooks 名称包括 preToolUse、postToolUse、subagentStart、subagentStop；Fleet 专题引用的 runtime 更新记录已修复子代理工具的这些 Hooks。但该专题没有在公共 SDK 中确认专门的 subagentStart/subagentStop 回调，SDK 消费者应使用已暴露的会话事件，不能根据 runtime Hook 名字自行拼出回调 API。

插件工作者与限制

插件中的代理可以按 task(agent_type=...) 调度，例如让不同任务使用同一 security-review 工作者类型。插件加载入口见SDK 插件目录；Fleet 专题的启动参数说明比插件专门参考更窄，具体能力应按匹配版本核对。

Fleet 不保证并行修改天然一致，也不消除父代理最终审阅。重叠文件、相互依赖的结论、实验性绑定和内部协调存储都是集成时需要明确处理的边界。