作者：Matt Nigh & Brian LaFlamme
排版：Alan Wang
/fleet允许 Copilot CLI 并行调度多个智能体。学习如何编写提示，将工作拆分到不同文件、声明依赖关系，并避免常见陷阱。
如果 GitHub Copilot CLI 能同时处理 5 个文件，而不是一次只能处理 1 个，会怎样？这正是 /fleet 的用武之地。
/fleet 是 Copilot CLI 中的一个斜杠命令，它使 Copilot 能够同时以并行方式调用多个子智能体。不同于按顺序逐个完成任务，现在 Copilot 背后有一个"编排器"，会将你的目标进行规划和拆解，分解为多个独立的工作项，并同时分派给多个智能体执行------可以在不同文件、代码库的不同位置同时进行。
想了解 /fleet 的工作原理，以及更重要的------如何高效使用它？我们一起来看看。
工作原理
当你使用 /fleet 并输入一个提示时，背后的编排器会：
-
将任务拆分为具有依赖关系的离散工作项
-
识别哪些任务可以并行执行，哪些必须等待
-
将独立任务作为后台子智能体同时分发执行
-
持续轮询任务完成情况，然后调度下一批任务
-
校验输出结果并整合最终产物
每个子智能体都有自己的上下文窗口，但共享同一个文件系统。它们之间不能直接通信，所有协调工作都由编排器完成。
可以把它理解为一个项目负责人：负责分配任务、跟进进度，并最终整合交付成果。
快速开始
通过发送 /fleet <YOUR OBJECTIVE PROMPT> 来启动 fleet 模式，例如：
python
/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ 就这么简单。编排器会根据你的目标自动判断哪些任务可以并行执行，并开始调度。
你也可以在终端中以非交互模式运行：
python
copilot -p "/fleet <YOUR TASK>" --no-ask-user由于非交互模式无法响应提示，因此必须添加 --no-ask-user 参数。现在我们来看看怎样才算一个好的提示词。
编写适合并行的提示
你的 /fleet 提示质量，直接决定了任务分配的效率。关键在于：为编排器提供足够清晰的结构，使其能够有效地拆解任务。
一个很好的方法是：明确交付物。将每个工作项映射到具体的产出，例如某个文件、测试套件或文档章节。模糊的提示往往会导致串行执行，因为编排器无法识别哪些部分是可以独立进行的。
例如，与其这样写：
/fleet Build the documentation
不如改为：
python
/fleet Create docs for the API module:
- docs/authentication.md covering token flow and examples
- docs/endpoints.md with request/response schemas for all REST endpoints
- docs/errors.md with error codes and troubleshooting steps
- docs/index.md linking to all three pages (depends on the others finishing first)第二种写法为编排器提供了 4 个清晰的交付物，其中 3 个可以并行执行，另 1 个依赖它们完成后再进行。
设定明确的边界
当子智能体清楚知道自己的职责范围从哪里开始、到哪里结束时，效果最佳。在编写提示时，应包含：
-
文件或模块边界：每个任务负责哪些目录或文件
-
约束条件：哪些内容不能修改（例如：不修改测试、不升级依赖）
-
验证标准：必须通过的检查，如代码规范（lint）、类型检查、测试等
下面是一个体现这些边界的提示示例：
python
/fleet Implement feature flags in three tracks:
1. API layer: add flag evaluation to src/api/middleware/ and include unit tests that look for successful flag evaluation and tests API endpoints
2. UI: wire toggle components in src/components/flags/ and introduce no new dependencies
3. Config: add flag definitions to config/features.yaml and validate against schema
Run independent tracks in parallel. No changes outside assigned directories. 在存在依赖关系时明确声明
如果某项工作依赖于另一项工作，请务必明确说明。编排器会将这些任务按顺序执行，同时将其余部分并行处理。例如：
python
/fleet Migrate the database layer:
1. Write new schema in migrations/005_users.sql
2. Update the ORM models in src/models/user.ts (depends on 1)
3. Update API handlers in src/api/users.ts (depends on 2)
4. Write integration tests in tests/users.test.ts (depends on 2)
Items 3 and 4 can run in parallel after item 2 completes. 为不同任务使用自定义智能体
你可以在 .github/agents/ 中定义专用智能体，并在 /fleet 提示中引用它们。每个智能体都可以指定自己的模型、工具和指令。需要注意的是，如果你没有明确指定使用哪个模型，这些智能体将默认使用当前的默认模型。
python
# .github/agents/technical-writer.md
---
name: technical-writer
description: Documentation specialist
model: claude-sonnet-4
tools: ["bash", "create", "edit", "view"]
---
You write clear, concise technical documentation. Follow the project style guide in /docs/styleguide.md. 然后在你的提示中引用该自定义智能体：
python
/fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes. 当不同任务需要不同能力时，这种方式非常有用，例如：复杂逻辑使用更强大的模型，而模板化的文档工作使用更轻量的模型。
如何验证子智能体是否已成功部署
观察编排器如何部署子智能体，这是学习如何编写高效并行化提示词的最快方式。
可以使用以下快速检查清单：
-
出现任务拆解：在开始执行之前，查看 Copilot 提供的执行计划，确认它是否将工作拆分为多个并行轨道，而不是单一的线性流程。
-
后台任务界面确认活动 ：任务开始后，运行
/tasks打开任务面板，检查正在运行的后台任务。 -
并行进度出现：更新日志中会显示多个不同任务轨道同时推进的状态。
如果 /fleet 看起来没有在并行执行，可以尝试停止 Copilot 的当前工作，并要求它进行更明确的任务拆解：
python
Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. 避免常见陷阱
Fleet 功能虽然强大，但有一些需要提前注意的"坑"。
文件分区
子智能体共享同一个文件系统，但没有文件锁机制。如果两个智能体同时写入同一个文件，那么最后完成的那个会"静默胜出"------不会报错、不会合并，只会直接覆盖前一个结果。
解决方法是在提示词中为每个智能体分配不同的文件。如果多个智能体需要共同贡献到同一个文件，可以考虑让它们先分别写入临时路径，最后再由编排器统一合并。或者，也可以为智能体设定明确的执行顺序。
保持提示自包含
子智能体无法看到编排器的对话历史。当编排器派发一个子智能体时，它只会传递一个提示词，但这个提示词必须包含子智能体所需的全部信息。如果你在会话早些时候已经收集了有用的上下文，请确保在 /fleet 提示中将其包含进去，或者引用子智能体可以读取的文件。
在执行过程中引导 Fleet
在任务分发之后，你仍然可以发送后续提示来引导编排器的行为：
-
Prioritize failing tests first, then complete remaining tasks. -
List active sub-agents and what each is currently doing. -
Mark done only when lint, type check, and all tests pass.
何时使用 /fleet（以及何时不使用）
当你的任务具有天然的并行性时，/fleet 会表现得非常出色------例如涉及多个文件、独立模块或可拆分职责的工作。它特别适用于：
-
同时跨多个文件进行重构
-
一次性为多个组件生成文档
-
实现跨 API、UI 和测试的功能
-
执行彼此不共享状态的独立代码修改
对于严格线性、单文件的任务，普通的 Copilot CLI 提示就更简单，也同样高效。由于 /fleet 会引入协调开销，只有在确实存在可分发的工作时才更具价值。
/fleet 最适合被当作一个"团队"来使用，而不是一个魔法工具。可以从小任务开始，选择那些输出明确、文件边界清晰、并且天然可以并行的工作。观察编排器如何拆解任务、在哪些地方有帮助、又在哪些地方产生阻碍。随着熟练度提升，你可以逐步扩展到更大的重构、多轨功能开发，或是文档与测试的并行生成。学习 /fleet 价值的最快方式，就是在真实工作中使用它，并根据实际效果不断调整你的提示词。