从一个 Agent 到一支 AI 开发团队：GitHub Copilot CLI '/fleet' 实战

文章主旨：GitHub Copilot CLI 的 /fleet 功能通过将复杂任务拆解为可并行的子任务、由主 Agent 编排调度，从而提升开发效率，但其真正价值取决于任务依赖图的设计与合理使用，开发者应成为任务设计者而非逐项执行者。

关键要点：

• /fleet 将复杂请求拆成较小任务并并行运行，主 Agent 转为编排者，负责拆解、调度、汇总与验证。
• 并行效率不取决于 Agent 数量，而取决于任务依赖图中是否存在足够宽的并行层；串行依赖过重时无法通过增加 Agent 加速。
• 推荐“先 Plan 后 Fleet”：提前明确交付物、任务独立性、依赖关系、文件边界与验收标准，才能安全并行。
• 最大风险是多个 subagent 同时修改同一文件，因此应遵循“单一文件所有者”原则，公共文件留给主 Agent 统一集成。
• Fleet 更适合跨模块重构、前后端并行开发、多文档更新等任务；严格串行、单文件、小规模任务用普通单 Agent 更合适。

内容结构：

视频里发生了什么

演示以 PRD 和架构文档为起点，构建 FeedHub RSS 阅读器。先进入 Plan 模式，将工程拆成 22 个任务、30 条依赖关系；确认计划后输入 /fleet，主 Agent 将无依赖的前后端 scaffold 任务并行派发给 subagent，随完成逐批解锁后续任务，最后汇总并验证：41 个后端测试通过，前端成功构建。

/fleet 如何工作

按官方说明，Fleet 拆解目标、判断并行与等待关系、派发后台 subagent、轮询调度、验证合成。每个 subagent 有独立上下文窗口，共享文件系统，不能直接交流，由主 Agent 协调。其价值取决于任务依赖图的并行层宽度。

真正的瓶颈是任务图，而不是模型速度

十小时串行任务交给十个 Agent 不会自动缩短到一小时。适合并行的计划通常有三类结构：按技术层拆分、按模块拆分、按工作类型拆分。拆分时需警惕“看似独立，实际共享状态”的协调点，应把 API contract、公共类型等提取为前置任务。

为什么建议先 Plan，再 Fleet

Plan 的作用是确认交付物、任务独立性、依赖关系和集成验收。官方推荐流程是先用 Plan 模式制定计划，再选择 Autopilot + /fleet。/fleet 解决“谁能同时做什么”，Autopilot 解决“是否需要用户逐步确认”，两者可组合也可独立使用。

怎样写好 Fleet Prompt

有效 Prompt 应明确四件事：交付物、文件边界、依赖关系、验收标准。原文给出示例，并强调应让 subagent 读取相关文档；由于 subagent 看不到主 Agent 的完整对话历史，任务必须自包含或引用可读取的上下文文件。“实现功能”缺乏可验证结果，完成标准应具体到文件、命令、用户路径和待报告风险。

最大风险：多个 Agent 同时写一个文件

subagent 共享文件系统但没有文件锁，同时修改同一文件可能静默覆盖。应遵循“单一文件所有者”原则，按目录或文件划分责任，公共文件留给主 Agent 集成。

如何观察和干预

使用 /tasks 查看后台任务，支持选择、查看详情、终止、清理等操作。执行中可继续指挥主 Agent。观察 Fleet 时可检查三个信号：计划是否拆成多条工作线、是否同时出现多个后台 subagent、进度更新是否来自不同模块。若只有一条长任务持续运行，说明目标模糊或依赖过重，应暂停并要求重新拆分独立 tracks。

什么时候不该使用 /fleet

原文给出反例：添加网站 URL 时无法输入，问题定位到单文件中的 effect 依赖项。此类目标集中、范围小、串行调查路径的任务，普通单 Agent 更合适。Fleet 有协调成本，只有存在真实并行工作时才值得使用；更多 subagent 也会消耗更多 Credits。

最后

实践建议：从 3～5 条自然工作线开始，先 Plan 列出任务、依赖、文件所有者和预期产物；人工检查文件冲突和公共接口；在 Prompt 中写明禁止修改范围与依赖顺序；设置统一质量门禁；用 /tasks 验证并行；最后检查 diff、运行产品，重点验证跨模块连接处。最终验收应关注“用户是否能完成关键路径”，而不只是“代码是否生成”。

文章总结：本文通过 FeedHub 演示全面展示了 /fleet 的能力与边界，强调多 Agent 并行开发的关键在于任务设计与组织协调，而不是单纯增加 Agent 数量；开发者应从逐项执行者转变为任务设计者和质量负责人，并始终将最终人工验收作为不可或缺的一环。