AI 生态热点：GitHub 给 Copilot CLI 加上 /fleet 后，终端 Agent 开始正式吃并行工程流了
按北京时间 2026 年 4 月 2 日 回看最近 48 小时，AI 开发者生态里最值得单拎出来聊的一条，是 GitHub 把 Copilot CLI 的工作方式往前推了一截。
GitHub 官方博客在 2026-04-01 发布了 /fleet，官方文档同一天也补了“Parallel task execution”说明。
这条命令的表面描述很简单：
把复杂任务拆成更小的子任务，并行交给多个 subagents 去做。
但如果你最近一直在用终端 agent，会知道真正的变化没这么轻。
以前终端 agent 更像“一个会跑命令的线程”。
现在 GitHub 直接把 orchestrator 摆上来了：
- 主代理先拆 plan
- 再判断依赖
- 把可并行的部分同时派出去
- 回收结果后继续下一波
也就是说，终端里的 agent 开始不只负责“执行”，还开始负责“编排”。
1. 这次更新到底更新了什么
先看 GitHub 官方给出的核心定义。
博客原文写得很直白：/fleet 会让 Copilot CLI “dispatch multiple agents in parallel”，背后有一个 orchestrator 负责把目标拆成独立 work items，再分批派发。
文档版描述更工程一点：
/fleet接收一份实现计划- 主代理判断哪些子任务彼此独立
- 子任务交给 subagents 并行执行
- 主代理负责依赖管理、汇总和后续调度
几个细节很关键。
1) 它不只是“多开几个线程”
GitHub 文档明确说了，/fleet 适合的是可以拆成独立子任务的工作。
如果任务天然强顺序，开 /fleet 并不会带来太多收益。
这意味着 GitHub 没把它做成“无脑加速按钮”。
它把“能不能拆”这件事摆到了显式层。
2) subagents 有各自独立的上下文窗
这点很重要。
文档写明，每个 subagent 都有自己的 context window，和主代理、其他 subagents 分开。
这会直接改变 prompt 写法：
- 你不能再只写一句大而空的目标
- 你得把目录边界、依赖关系、产物要求写清楚
- 你得接受“编排质量”开始决定最终效果
3) 它默认会优先考虑成本
GitHub 文档还提了一条很实在的规则：
默认情况下，subagents 用的是 low-cost model。
如果某个子任务要更强模型，你可以在 prompt 里显式指定 GPT-5.3-Codex 或 Claude Opus 4.5，也可以通过自定义 agent profile 去约束。
这件事说明 GitHub 已经开始认真碰“编排质量和调用成本怎么一起算”。
2. 终端工作流为什么会被它改掉
我觉得 /fleet 真正会改的，是开发者看待终端 agent 的方式。
过去一段时间，很多团队已经在做三件事：
- 让 agent 写代码
- 让 agent 跑测试
- 让 agent 顺着提示一步一步改
但这套用法有个明显上限：
任务一旦跨目录、跨职责、跨验证链，单线程 agent 很容易越写越慢。
GitHub 这次给出的，其实是一种新的分工方式：
- 主代理负责拆解
- 子代理负责各自负责的局部目标
- 再由主代理统一收口
这会把终端 agent 从“会执行命令的对话窗”推向“轻量调度器”。
这也是为什么 GitHub 文档专门把 /fleet 和 autopilot mode 分开写。
官方说得很清楚：
autopilot负责让 Copilot 持续自主工作/fleet负责让任务并行化
两者可以一起用，但不是一回事。
这条边界很关键。
它提醒团队别把“自动跑得更久”和“自动拆得更好”混成一个概念。
3. 谁现在就该跟进，谁先别急
适合现在就跟进的人
- 已经在用 Copilot CLI，而且任务经常跨多个目录和模块
- 仓库边界相对清晰，能把 API、UI、配置、测试拆开
- 团队已经习惯先写 plan，再让 agent 开干
- 你愿意接受为了更快交付，多花一点 premium requests
先别急的人
- 任务本身很线性，拆不开
- 仓库耦合重，任何修改都要频繁回看全局
- 团队还没有形成目录责任边界
- 你对成本波动、输出一致性、验证链还没有准备
GitHub 文档自己也提醒了一个现实问题：
每个 subagent 都会独立和模型交互，所以 premium requests 可能明显上升。
如果团队现在连“什么时候该用单线程 agent，什么时候该用并行 agent”都没定义好，开 /fleet 很容易先得到账单惊喜。
4. 最值得抄的是它逼你把计划写实
/fleet 其实在反向教育团队一件事：
计划写得不清，终端里的多代理编排就不会稳。
GitHub 官方博客给的示例很有代表性。
它不是说“去实现一个 feature”，而是把任务直接拆到：
- API middleware
- UI toggle component
- config/schema
- docs/summary
并且把“哪些目录能动、哪些依赖先后执行”写清楚。
这会逼着团队从“写一个大目标”转到“写一份可派发的实现单”。
我觉得这比功能本身更值得看。
因为以后真正影响 agent 成功率的，不只看模型，也看你有没有把工程任务写成机器能稳定分工的形状。
5. 一套更稳的落地顺序
如果你准备在团队里试 /fleet，我建议按下面的顺序来。
1) 先选天然可拆的任务
别拿强顺序迁移、核心链路重构做第一枪。
优先选这些：
- 新 feature 的测试补齐
- 多目录但弱依赖的 refactor
- API、UI、config 可以平行推进的需求
2) 先把任务边界写进 prompt
至少写清：
- 每条子任务能改哪些目录
- 哪些步骤可以并行
- 哪些步骤必须等前置完成
- 最终验收产物是什么
3) 把验证放回主代理收口
并行子任务会让产出更快，但也更容易出现风格漂移和集成缝隙。
所以最终的 lint、test、integration check，最好由主代理统一收口，不要让每个 subagent 各自宣称“我这里没问题”。
4) 先做一层成本闸门
把下面两件事先定死：
- 哪些任务允许使用更贵模型
- 哪些目录或任务类型禁止直接上
/fleet
否则并行能力一旦好用，团队很容易把本来单线程就够的事也都塞进去。
6. 风险、边界和回滚思路
这条功能很新，风险点也很明确。
风险 1：任务拆得烂，反而更慢
如果 plan 没写清依赖，主代理会花很多时间在重排、返工和收口上。
风险 2：成本比你预期高
GitHub 官方文档已经提醒，subagents 会带来更多 LLM interactions。
这不是附带说明，而是治理重点。
风险 3：输出一致性下降
不同 subagents 拿着不同上下文独立行动，最后风格、命名、接口细节可能不一致。
回滚思路
很简单，别一开始把 /fleet 当默认模式。
- 先保留单代理工作流
- 只给特定任务类型开
/fleet - 对效果差的任务，直接退回 plan mode + 单代理执行
并行不是信仰。
拆不动，就别硬拆。
7. 如果你在选平台，当前更值得对比的第三方方案
如果你关心的不是某个命令，而是“终端并行 agent 平台到底怎么选”，那 /fleet 现在至少要和两个第三方方案一起看。
方案一：OpenAI Codex app
OpenAI 在 2026-02-02 发布 Codex app 时，官方定位就是“a command center for agents”，支持 multiple agents、parallel work、worktrees 和长期后台 Automations。
它更适合：
- 想集中监督多个长任务
- 想要 app、CLI、IDE 共享上下文
- 想把并行执行和 review queue 放在一个界面里
它不太适合：
- 团队强依赖纯终端体验
- 想把编排能力完全收在 GitHub/Copilot 体系里
方案二：Claude Code
Anthropic 的 Claude Code 现在已经支持 project-level subagents、hooks、permissions deny、plugin/MCP 配置。
它更适合偏本地优先、策略优先、需要把 repo 级治理规则钉进终端工作流的团队。
它更适合：
- 需要强 repo-local 控制
- 想把 hooks、permissions、MCP 管理放进同一套设置
- 终端和本地脚本链路很重
它不太适合：
- 只想开箱即用做 GitHub 原生并行编排
- 不想自己管太多本地策略和运行时细节
如果你的主阵地已经在 GitHub，/fleet 的进入门槛会更低。
如果你要的是更重的多 agent 监督台，Codex app 现在还是更像“控制台”而不是“命令扩展”。
如果你优先关心本地治理和可插拔性，Claude Code 仍然更有吸引力。
8. 这条更新为什么值得记一笔
我更在意的不是 /fleet 这条命令会不会立刻替代大家现在的终端用法。
我在意的是，GitHub 终于把一个之前大家都在私下摸索的事实写成产品能力了：
以后真正高价值的 agent 工作流，不会只比谁更会写代码，还会比谁更会拆任务、管依赖、控成本、收结果。
这件事一旦进入官方产品层，终端 agent 就不再只是“提问和执行”的界面了。
它开始变成一层轻量编排面。
这条线，后面大概率只会越走越深。