一个 Agent 已经够吵了，GitHub 还想让五个一起上：Copilot CLI 的 /fleet 到底在卖什么药？
/fleet 是 GitHub Copilot CLI 里一个把任务拆给多个子 Agent 并行执行的新命令。 它的重点不是单纯“更快”，而是 AI 编程工具终于不再装自己是一个万能实习生，而是开始明牌：它更像一个会拆任务、排依赖、盯交付的项目协调器。
如果你最近已经被各种 AI coding agent 轰炸得有点麻，那 GitHub 这次的新东西依然值得看。因为它踩中的不是模型参数，而是一个更现实的问题：当代码工作天然就能拆成好几条线时，为什么还要让一个 Agent 在那儿单线程磨？
它想解决的，其实是“AI 单兵作战太像堵车”
GitHub 的说法很直接：/fleet 会把一个大任务拆成多个 work items，判断哪些能并行、哪些必须等前置任务完成，然后把这些事情分发给后台子 Agent 去同时做。比如：
- 一个去改 API 逻辑
- 一个去补测试
- 一个去写文档
- 最后再由编排层汇总结果
这套思路听上去很像你在带几个实习生干活。区别是现在，AI 工具终于开始承认自己需要“项目管理层”了。
真正的看点，不是并行，而是任务拆分变成产品能力
过去很多 AI 编程工具都在卖“我能写代码”。但写代码从来不是最难的部分。真正折磨人的，是这些问题：
- 哪些文件可以同时动
- 哪些改动有先后依赖
- 谁来保证别两个 Agent 把同一个文件互相覆盖
- 最后谁来验收测试、类型检查和交付物
/fleet 其实是在回答这些问题。它说明现在的竞争点，已经从“谁能补全一段函数”慢慢转向“谁能像团队 lead 一样组织多条工作流”。
这件事我觉得挺关键。因为开发者真正愿意付费的，通常不是一个更会聊天的 AI，而是一个能少占你注意力、少让你来回盯进度的系统。
但这玩意儿也不是开了就无敌
GitHub 自己也写得很诚实：多个子 Agent 共享同一个文件系统，而且没有文件锁。如果你让两个 Agent 同时写一个文件，最后很可能是谁晚写完谁覆盖前面的结果，安静地翻车。
所以它并不是“自动多开，爽完就行”，而是很吃提示词设计：
- 交付物要明确到文件级
- 依赖关系要说清楚
- 边界要划死，别让不同轨道乱窜
- 验收标准要写明，比如 lint、type check、tests 全过
换句话说，多 Agent 时代没有消灭 prompt engineering，只是把它升级成了任务架构设计。
这对普通开发者意味着什么？
我觉得可以先记住一句话：以后 AI coding 的核心门槛，可能不是“会不会写”，而是“会不会拆”。
如果一个团队已经能把需求拆成稳定的小块，那多 Agent 会非常香；如果需求本身就含糊、文件边界一团糟，那你只是把混乱并行化，事故还会更快发生。
所以 /fleet 最值得关注的地方，不是 GitHub 又多了一个 slash command，而是它释放了一个很明显的信号：
AI 编程工具正在从“副驾驶”变成“调度台”。
后面谁能把任务拆得更准、把依赖管得更稳、把验收闭环做得更像样，谁才更接近真正的生产力工具。至于那些还停留在“你说一句我改一段”的 agent，接下来可能真要开始显得有点原始了。
你可能还想看
如果你已经在用各种 coding agent，接下来最该练的也许不是“怎么让它更聪明”，而是：怎么把工作拆到让多个 Agent 同时干还不打架。