在Copilot CLI中使用/fleet同时运行多个代理

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

/fleet 是 Copilot CLI 中的一个斜杠命令，它使 Copilot 能够同时与多个子代理并行工作。与顺序处理任务不同，Copilot 现在拥有一个幕后协调器，该协调器会规划并将你的目标分解为独立的工作项，然后调度多个代理同时执行它们。在不同文件上，在代码库的不同部分，同时进行。

想了解 /fleet 的工作原理，以及更重要的是如何高效使用它吗？让我们深入探讨。

工作原理

当你使用提示运行 /fleet 时，幕后协调器会：

• 将任务分解为具有依赖关系的离散工作项。
• 识别哪些项可以并行运行，哪些必须等待。
• 同时将独立项作为后台子代理调度。
• 轮询完成状态，然后调度下一波。
• 验证输出并合成最终工件。

每个子代理都有自己的上下文窗口，但共享相同的文件系统。它们不能直接相互通信；只有协调器进行协调。

可以将其视为项目负责人，将工作分配给团队，检查进度并组装最终交付物。

入门

通过发送 /fleet 启动舰队模式。例如：

/fleet 重构 auth 模块，更新测试，并修复 docs/auth/ 文件夹中的相关文档。

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

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

copilot -p "/fleet " --no-ask-user

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

编写可良好并行化的提示

/fleet 提示的质量决定了工作分配的有效性。关键在于给协调器足够的结构来清晰地分解任务。

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

例如，与其使用：/fleet 构建文档，不如尝试：

/fleet 为 API 模块创建文档：

• docs/authentication.md 涵盖令牌流程和示例
• docs/endpoints.md 包含所有 REST 端点的请求/响应模式
• docs/errors.md 包含错误代码和故障排除步骤
• docs/index.md 链接到所有三个页面（依赖于其他页面完成）

第二个提示给了协调器四个不同的交付物，其中三个可以并行运行，一个依赖于它们。

设置明确边界

当子代理确切知道其范围的起点和终点时，它们的工作效果最佳。编写提示时，包括：

• 文件或模块边界：每个轨道负责的目录或文件
• 约束：不要触碰的内容（例如，不修改测试，不升级依赖）
• 验证标准：必须通过的 lint、类型检查、测试

以下是一个展示这些边界的提示：

/fleet 在三个轨道中实现功能标志：

1. API 层：在 src/api/middleware/ 中添加标志评估，并包含检查标志评估成功和测试 API 端点的单元测试
2. UI：在 src/components/flags/ 中连接切换组件，不引入新依赖
3. 配置：在 config/features.yaml 中添加标志定义，并根据模式验证

独立轨道并行运行。不修改指定目录之外的内容。

存在依赖时声明它们

如果一项工作依赖于另一项，请说明。协调器会序列化这些项，并并行化其余项。例如：

/fleet 迁移数据库层：

1. 在 migrations/005_users.sql 中编写新模式
2. 更新 src/models/user.ts 中的 ORM 模型（依赖于 1）
3. 更新 src/api/users.ts 中的 API 处理程序（依赖于 2）
4. 在 tests/users.test.ts 中编写集成测试（依赖于 2）

项目 3 和 4 可以在项目 2 完成后并行运行。

为不同作业使用自定义代理

你可以在 .github/agents/ 中定义专门的代理，并在 /fleet 提示中引用它们。每个代理可以指定自己的模型、工具和指令。请注意，如果不指定使用哪个模型，代理将使用当前的默认模型。

.github/agents/technical-writer.md

--- name: technical-writer description: 文档专家 model: claude-sonnet-4 tools: ["bash", "create", "edit", "view"] --- 你编写清晰简洁的技术文档。遵循 /docs/styleguide.md 中的项目风格指南。

然后在提示中引用自定义代理：

/fleet 对所有文档任务使用 @technical-writer.md 作为代理，对代码更改使用默认代理。

当不同轨道需要不同优势时，这很有用，例如为复杂逻辑使用更重的模型，为样板文档使用更轻的模型。

如何验证子代理正在部署

观察协调器如何部署子代理，这是学习如何编写良好并行化提示的最快方式。

使用此快速检查清单：

• 分解出现：在开始工作之前，查看 Copilot 与你共享的计划，看它是否将工作分解为多个轨道，而不是一个长的线性计划。
• 后台任务 UI 确认活动：一旦开始工作，运行 /tasks 打开任务对话框并检查正在运行的后台任务。
• 并行进度出现：更新引用同时移动的独立轨道。

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

首先将此项分解为独立轨道，然后并行执行轨道。分别报告每个轨道的状态和阻碍。

避免常见陷阱

Fleet 很强大，但一些陷阱值得事先了解。

分区文件 子代理共享没有文件锁定的文件系统。如果两个代理写入同一文件，最后完成的代理获胜——静默地。没有错误，没有合并，只是覆盖。

解决方法是提示中为每个代理分配不同的文件。如果多个代理需要贡献同一个文件，考虑让每个代理写入临时路径，让协调器在最后合并它们。或者为代理设置显式顺序。

保持提示自包含 子代理看不到协调器的对话历史。当协调器调度子代理时，它会传递一个提示，但该提示需要包含子代理所需的一切。如果你已经在会话早期收集了有用的上下文，确保你的 /fleet 提示包含它（或引用子代理可以读取的文件）。

引导进行中的舰队 调度后，你可以发送后续提示来指导协调器：

• 首先优先处理失败的测试，然后完成剩余任务。
• 列出活动子代理以及每个子代理当前正在做什么。
• 仅在 lint、类型检查以及所有测试通过时标记完成。

何时使用 /fleet（以及何时不使用）

/fleet 在你的任务具有自然并行性时表现出色——多个文件、独立模块或可分离的关注点。它特别适用于：

• 同时跨多个文件重构。
• 一次为多个组件生成文档。
• 实现跨越 API、UI 和测试的功能。
• 运行不共享状态的独立代码修改。

对于严格的线性、单文件工作，常规的 Copilot CLI 提示更简单且同样快速。Fleet 增加了协调开销，因此当有真正的工作要分配时才值得使用。

/fleet 在你将其视为团队而非魔术技巧时最有用。从小处着手。选择具有清晰输出、干净文件边界和明显并行性的任务。观察协调器如何分解工作，哪里有帮助，哪里会碍事。随着你越来越熟练，将其推向更大的重构、多轨道功能或并行文档和测试。了解 /fleet 何时值得的最快方法是将其用于实际工作，并根据所见调整提示。

开始使用 GitHub Copilot CLI >