Copilot CLI 用 /fleet 并行运行多个智能体

如果 GitHub Copilot CLI 能同时处理五个文件，而不是一个，会怎样？这就是 /fleet 的用武之地。

/fleet 是 Copilot CLI 中的一个斜杠命令，它能让 Copilot 同时并行运行多个子智能体（Subagents）。Copilot 现在有了一个幕后的编排器（Orchestrator），它会规划你的目标，将其分解成独立的工作项，然后同时调度多个智能体去执行。在不同的文件中，在代码库的不同部分，同时进行。

想了解更多 /fleet 的工作原理，更重要的是，如何最高效地使用它？我们开始吧。

工作原理

当你运行 /fleet 并附带一个提示词时，幕后的编排器会：

1. 将你的任务分解成具有依赖关系的独立工作项。
2. 识别哪些项目可以并行运行，哪些必须等待。
3. 将独立项目作为后台子智能体同时调度。
4. 轮询完成状态，然后调度下一波任务。
5. 验证输出并合成最终产物。

每个子智能体都有自己的上下文窗口（Context Window），但共享同一个文件系统。它们不能直接相互通信；只有编排器负责协调。

可以把它想象成一个项目负责人，把工作分配给团队，检查进度，并组装最终交付物。

开始使用

通过发送 /fleet <你的目标提示词> 来启动舰队模式。例如：

/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/

就这样。编排器接收你的目标，找出可以并行化的部分，然后开始调度。

你也可以在终端中以非交互方式运行它：

copilot -p "/fleet <你的任务>" --no-ask-user

--no-ask-user 标志在非交互模式下是必需的，因为无法响应提示。现在，让我们看看什么才是好的提示词。

编写易于并行化的提示词

你的 /fleet 提示词的质量决定了工作分配的效率。关键在于给编排器足够的结构，以便清晰地分解你的任务。

一个好的方法是明确交付物。将每个工作项映射到一个具体的产物，比如一个文件、一个测试套件或一段文档。模糊的提示词会导致顺序执行，因为编排器无法识别独立的部分。

例如，与其写：/fleet Build the documentation，不如试试：

/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)

第二个提示词给了编排器四个不同的交付物，其中三个可以并行运行，一个依赖于其他三个完成。

设定明确的边界

当子智能体确切知道其工作范围从哪里开始、到哪里结束时，它们的工作效果最好。编写提示词时请包含：

• 文件或模块边界：每个任务负责哪些目录或文件
• 约束条件：不要改动什么（例如，不改动测试，不升级依赖）
• 验证标准：必须通过的代码检查、类型检查、测试

下面是一个展示这些边界的提示词示例：

/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.

声明存在的依赖关系

如果一个工作项依赖于另一个，请明确说明。编排器会将这些项目串行化，并并行化其余部分。例如：

/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 提示词中引用它们。每个智能体可以指定自己的模型、工具和指令。请注意，如果你不指定使用哪个模型，智能体将使用当前的默认模型。

# .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.

然后在你的提示词中引用这个自定义智能体：

/fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes.

当不同任务需要不同的优势时，这很有用，比如用更强大的模型处理复杂逻辑，用更轻量的模型处理样板文档。

如何验证子智能体正在部署

观察编排器如何部署子智能体，这是学习编写易于并行化提示词的最快方法。

使用这个快速检查清单：

• 出现分解计划：在开始工作之前，查看 Copilot 与你分享的计划，看它是否将工作分解成多个任务，而不是一个长的线性计划。
• 后台任务界面确认活动：一旦开始工作，运行 /tasks 打开任务对话框，检查正在运行的后台任务。
• 出现并行进度：更新信息会显示不同任务同时推进。

如果舰队似乎没有并行化，可以尝试停止 Copilot 的工作，并要求明确的分解：

Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers.

避免常见陷阱

舰队功能强大，但有几个需要注意的地方。

划分你的文件

子智能体共享一个文件系统，但没有文件锁。如果两个智能体写入同一个文件，最后完成的那个会胜出——悄无声息地覆盖。没有错误，没有合并，只是覆盖。

解决办法是在你的提示词中为每个智能体分配不同的文件。如果多个智能体需要贡献到同一个文件，可以考虑让每个智能体写入一个临时路径，然后让编排器在最后合并它们。或者为智能体设定明确的执行顺序。

保持提示词自包含

子智能体看不到编排器的对话历史。当编排器调度一个子智能体时，它会传递一个提示词，但这个提示词需要包含子智能体所需的一切。如果你已经在之前的会话中收集了有用的上下文，请确保你的 /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 何时能带来回报的最快方法，是在实际工作中尝试它，并根据你看到的情况调整你的提示词。