结论先说
GitHub Copilot CLI /fleet 适合一种场景：一个任务能拆成多个文件或多个独立方向同时推进，比如 API、UI、测试、文档分头走。它不是让所有提示词都变快的万能按钮。安全用法是：先明确文件归属，在提示词里声明依赖关系，跑完后由人做一次最终审查。如果两个子 Agent 需要改同一个文件，/fleet 通常不是正确起点。
GitHub 2026 年 4 月 1 日的发布有实际意义：它把并行子 Agent 变成了 Copilot CLI 的一等公民功能，而不再是团队自行搭建的临时方案。对开发者来说，问题不是多 Agent 编码听起来酷不酷，而是 /fleet 在什么条件下真的能省时间、同时不让代码库变得更难信任。
前置条件： 需要安装 GitHub Copilot CLI，并且拥有任意一个 Copilot 方案（Free、Pro、Pro+、Business 或 Enterprise）。运行 copilot --version 确认 CLI 可用。除了有效的 Copilot 订阅之外，不需要额外配置。
为什么现在值得写
2026-04-01，GitHub 发布了 Copilot CLI /fleet 的官方指南。新的信号是实操层面的：GitHub 开始明确告诉用户，围绕并行工作项、依赖关系和文件边界来组织提示词，而不是把多 Agent 执行当作一个隐藏的实现细节。
现实差距也很明显：很多开发者已经用 Copilot 做单线程的规划或编辑，但还没有一套清晰的规则来判断什么时候该并行。/fleet 提供了这个判断依据——前提是你把它当成任务编排，而不是自动驾驶。
本文聚焦一个窄目标：用 /fleet 让有明确边界的多文件工作更快完成，同时不引入静默覆盖风险或审查盲区。
/fleet 到底做了什么
根据 GitHub 2026-04-01 的官方博客，/fleet 是 Copilot CLI 的一个斜杠命令：一个编排器把你的目标拆成工作项，派发多个后台子 Agent，等待依赖完成，最后合成结果。
关键是它的执行模型：
- 每个子 Agent 有自己的上下文窗口
- 所有子 Agent 共享同一个文件系统
- 子 Agent 之间不直接通信
- 编排器决定哪些轨道可以并行、哪些必须等待
共享文件系统解释了好处和风险。好处很直接：独立文件可以同时推进。风险同样直接：共享文件会变成冲突点。
只在任务形状正确时使用 /fleet
适合的场景：
- 同时更新 API handler、测试文件和文档（分属不同文件）
- 批量生成多个页面的文档
- 重构一个功能，拆分在多个明确独立的模块中
- 对多个目录执行重复但互不依赖的编辑
不适合的场景：
- 单文件 bug 修复
- 问题本身还没搞清楚的任务
- 高风险迁移，每一步都会影响下一步的决策
- 两个以上 Agent 需要同时编辑同一个文件
一条简单规则：
如果你在开始之前无法给每个 Agent 分配清晰的文件归属，就先不要用 /fleet。
安全工作流一屏看完
| 步骤 | 做什么 | 为什么重要 |
|---|---|---|
| 1 | 按文件或目录定义输出 | 编排器需要具体的工作项 |
| 2 | 显式声明依赖关系 | 否则 Copilot 可能猜错顺序 |
| 3 | 设定边界和验证规则 | 限制漂移和隐性范围扩展 |
| 4 | 确认任务可拆分后再跑 /fleet |
线性工作加并行只会徒增开销 |
| 5 | 审查最终 diff 并运行真正的检查 | 并行输出仍然需要一个负责任的审查者 |
五步。刚好够让 /fleet 有用而不嘈杂。
第一步：提示词要映射到可交付物
GitHub 自己的示例说明了为什么模糊提示词效果差。"构建文档"不是一个好的 /fleet 提示词，因为编排器很难从中识别出独立的轨道。更好的提示词把每个任务映射到具体的文件、目录或测试目标。
可复制的示例：
/fleet Update the authentication docs in four tracks:
1. docs/authentication.md covering login flow and token refresh
2. docs/endpoints.md with request and response examples
3. docs/errors.md with auth-related error codes and fixes
4. docs/index.md linking the three pages above (depends on 1, 2, and 3)
Rules:
- no changes outside docs/
- preserve existing terminology from docs/styleguide.md
- mark done only when markdown lint passes
为什么这个可以工作：
- 每个轨道有可见的输出物
- 只有一个轨道依赖其他三个
- 编排器可以干净地并行前三项
- 验证规则是显式的
第二步：在追求速度之前先划清文件边界
GitHub 官方 /fleet 博文特别说明了一个警告：子 Agent 共享文件系统，没有文件锁。如果两个 Agent 写同一个文件，最后完成的那个会静默覆盖前一个。
这意味着提示词设计的核心技能不是"多要几个 Agent"，而是"减少写入目标的重叠"。
用这种写法：
/fleet Implement feature flags in three tracks:
1. API layer in src/api/middleware/ with unit tests
2. UI toggles in src/components/flags/
3. definitions in config/features.yaml
Constraints:
- no dependency changes
- no edits outside assigned directories
- report blockers before expanding scope
- run tests relevant to each track before marking done
在执行前分配归属，比宽泛地说"在整个应用里加 feature flag"更可靠。
第三步：用依赖关系只串行化必须等待的部分
并行执行只在任务图部分独立时才有价值。如果整个任务是线性的，/fleet 不会加速多少，只会多出一层编排开销。
一个好的迁移提示词长这样：
/fleet Migrate the user profile flow:
1. add the schema in migrations/008_profiles.sql
2. update src/models/profile.ts (depends on 1)
3. update src/api/profile.ts (depends on 2)
4. update tests/profile.test.ts (depends on 2)
Rules:
- do not change unrelated endpoints
- stop if the schema change requires a rollback plan
在这个例子里，第 3 和第 4 项可以在第 2 项完成后并行运行。这就是 /fleet 处理得好的那种部分并行。
第四步：了解两种关键的启动方式
GitHub 官方指南给出了两种基本启动方式：
交互模式
/fleet Refactor the auth module, update tests, and fix docs in docs/auth/
当你想在运行过程中检查分解方案并引导编排器时，交互模式更简单。
非交互模式
copilot -p "/fleet <YOUR TASK>" --no-ask-user
截至 2026-04-02，GitHub 官方 /fleet 公告明确说明，非交互模式必须加 --no-ask-user，因为此时没有提示-响应循环。
只在你的约束已经足够清晰、可以完全编码到提示词里时，才用非交互模式。如果你仍然需要协商，就留在交互模式。
第五步：像审查者而不是旁观者那样盯着运行
GitHub 建议检查分解是否真的发生了，并用 /tasks 查看后台工作。这很重要，因为并不是每次 /fleet 运行都会真正并行化。
要检查的事项：
- Copilot 是否在执行前把工作拆成了多个轨道？
- 不同轨道是否在同时推进？
- 各轨道是否负责不同的文件或目录？
- 是否有某个轨道因为你忘记声明的依赖关系而被阻塞？
如果运行看起来太线性，停下来用更结构化的提示词重试：
Decompose this into independent tracks first, then execute tracks in parallel.
Report each track separately with status, changed files, and blockers.
这种措辞比泛泛的"继续"能给你更好的审计线索。
第六步：只在拆分确实成立时才添加专业 Agent
GitHub 4 月 1 日的示例还展示了可以在 .github/agents/ 下定义 Agent 并把特定轨道路由给它们。当一个方向侧重文档而另一个侧重代码时，这很有用。
Agent 文件示例：
---
name: technical-writer
description: Documentation specialist
model: claude-sonnet-4
tools: ["bash", "create", "edit", "view"]
---
You write concise technical documentation.
Follow docs/styleguide.md.
然后可以这样提示：
/fleet Use @technical-writer.md for docs tasks and the default agent for code changes.
只有当任务拆分已经稳定时才值得做。如果边界仍然模糊，自定义 Agent 只会让流程更复杂，而不会解决核心问题。
最容易踩的坑
两个 Agent 改同一个文件
文件冲突是最明确的失败场景。GitHub 明确说没有文件锁。如果同一个文件对多个轨道都重要，用一个 Agent 处理，或者让子 Agent 写入临时文件，最后在一个受控步骤中合并。
提示词依赖聊天历史
子 Agent 看不到编排器的完整对话历史。如果某条关键规则只存在于聊天记录中，一个或多个轨道可能会漏掉。
解决方案：把真正的约束写在 /fleet 提示词本身里，或写在仓库中 Agent 可以读取的文件里。
任务实际上是线性的
如果每一步都依赖上一步，/fleet 不会加速多少，只会多出更多活动部件。
解决方案：先用普通的 Copilot CLI 任务跑一次，或者让 Copilot 先做规划再决定是否并行。
跳过最终审查因为"多个 Agent 已经检查过了"
并行执行不等于独立验证。它仍然是一次编排运行。
解决方案：审查 diff，运行真正的检查，在合并前保留一个人工批准环节。
面向真实仓库的提示词模板
当你需要一个已经内置了护栏的起点时，用这个：
/fleet Complete this task in parallel only where work is independent.
Objective:
[describe the outcome]
Tracks:
1. [file or directory owner + output]
2. [file or directory owner + output]
3. [file or directory owner + output]
Dependencies:
- [track 3 depends on track 1]
- [track 2 can run immediately]
Constraints:
- no edits outside assigned files unless blocked
- no dependency upgrades
- preserve public API names unless explicitly requested
- list blockers before expanding scope
Validation:
- run [tests/lint/typecheck]
- report changed files per track
- mark done only when all listed checks pass
这个模板同时做三件事：告诉 Copilot 构建什么、不碰什么、以及什么算完成。
常见问题
/fleet 比普通 Copilot CLI 提示词更好吗？
只在任务有真正的并行结构时。单文件工作或高度耦合的重构，普通 Copilot CLI 提示词更简单。关于多 Agent 工作流的更广泛视角和适用场景判断，可以参考我们的 AI Agent 实用指南。
需要在 .github/agents/ 里定义自定义 Agent 才能用好 /fleet 吗？
不需要。清晰的文件边界比自定义 Agent 重要得多。只在基础工作流已经跑通后再添加专业 Agent。
哪些 GitHub Copilot 方案包含 Copilot CLI？
截至 2026-04-02，GitHub 官方 Copilot CLI 和方案页面显示，Copilot CLI 包含在 Free、Pro、Pro+、Business 和 Enterprise 所有方案中。GitHub 当前的个人方案页面显示 Pro 每用户每月 $10，Pro+ 每用户每月 $39。
结论
GitHub Copilot CLI /fleet 在你已经知道怎么拆分工作时才有用。优势不来自"更多 Agent"，而来自更清晰的分解。
如果你按文件定义交付物、声明依赖关系、保留一次最终审查，/fleet 可以缩短有明确边界的多文件工作的时间。如果你的任务仍然依赖猜测、共享文件或隐性上下文，并行化就不是正确的优化方向。
验证说明
2026-04-02 基于官方 GitHub 来源验证：
- 官方 /fleet 指南：GitHub 博客，Matt Nigh 和 Brian LaFlamme 撰写的"Run multiple agents at once with /fleet in Copilot CLI"（发布于 2026-04-01），确认了编排器模型、共享文件系统（无文件锁）、
/tasks检查、--no-ask-user非交互模式以及.github/agents/自定义 Agent。 来源：https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/ - Copilot 定价：GitHub Copilot 方案页面列出 Free（$0）、Pro（$10/用户/月）和 Pro+（$39/用户/月）。Copilot CLI 包含在所有方案中，包括 Free。
来源：
https://github.com/features/copilot/plans
2026-04-02 验证。话题触发通过共享 news-pipeline 数据库检查，基于 GitHub 博客 2026-04-01 发布的文章：https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/。针对该官方博文验证了 /fleet 的关键行为、提示词模式、依赖示例、.github/agents/ 用法、/tasks 检查、共享文件系统警告以及非交互模式 copilot -p "/fleet <YOUR TASK>" --no-ask-user 的用法。针对 GitHub 官方 Copilot CLI 和方案页面在 2026-04-02 验证了 Copilot CLI 的可用性和当前方案信息：https://github.com/features/copilot/cli 和 https://github.com/features/copilot/plans。