如何使用任务控制编排代理

Source: GitHub Blog

我们最近推出了 Agent HQ 的任务控制中心，这是一个用于管理 GitHub Copilot 编码代理任务的统一界面。

现在，你可以在多个仓库中为 Copilot 分配任务，选择自定义代理，实时查看会话日志，在运行中进行干预（暂停、细化或重新启动），并直接跳转到生成的 Pull Request——所有操作都在同一个地方完成。无需在不同页面之间来回切换查看状态、理由和变更，任务控制中心将分配、监督和审查集中在一起。

拥有工具是一回事，如何高效使用它是另一回事。本指南将展示如何编排多个代理、何时介入以及如何高效审查它们的工作。擅长编排代理意味着在同一时间内完成并行工作，阻止日志出现偏差、测试失败或范围蔓延时及时介入。

思维模型的转变

从顺序到并行

如果你已经习惯一次只使用一个代理，你会知道这本质上是顺序的。你提交提示，等待响应，审查结果，进行调整，然后进入下一个任务。

任务控制中心改变了这一点。你可以在几分钟内启动多个任务——无论是同一个仓库还是多个仓库。以前，你需要在不同仓库中打开各自的 Issue 并分别为 Copilot 分配任务。现在，你只需在一个地方输入提示，Copilot 编码代理就会在所有仓库中工作。

需要注意的权衡是：每个任务不再只需要 30 秒到几分钟完成，代理可能会在草稿上花费几分钟到一小时。但你不再只是等待，而是在进行编排。

何时保持顺序

并非所有工作都适合并行。当以下情况出现时，请使用顺序工作流：

• 任务之间有依赖关系
• 你在探索不熟悉的领域
• 复杂问题需要在步骤之间验证假设

在同一个仓库中分配多个任务时，需要考虑重叠。并行工作的代理如果修改同一文件，可能会产生合并冲突。请慎重划分工作范围。

通常适合并行运行的任务包括：

• 调研工作（查找功能标记、配置选项）
• 分析（日志分析、性能剖析）
• 文档生成
• 安全审查
• 在不同模块或组件中的工作

入门技巧

转变很简单：你从等待单个运行，转为监督多个并行进行的任务，在测试失败、范围漂移或意图不明确时介入并提供指导，以节省时间。

编写带上下文的清晰提示

具体性很重要。请精准描述任务。良好的上下文仍然是获得好结果的关键。

有帮助的上下文包括：

• 展示问题的截图
• 说明你想要的模式的代码片段
• 指向相关文档或示例的链接

弱提示： “修复认证错误。”

强提示：

用户在活动 30 分钟后报告 “Invalid token” 错误。JWT 令牌在 `auth.config.js` 中设置为 1 小时过期。调查令牌为何提前失效并修复验证逻辑。在 `api-gateway` 仓库中创建 Pull Request。

使用自定义代理保持一致性

任务控制中心允许你选择使用来自所选仓库的 agents.md 文件的自定义代理。这些文件为你的代理提供角色设定和预写的上下文，免去每次都要提供相同示例或指令的负担。

如果你管理的仓库中团队经常使用代理，考虑创建针对常见工作流的 agents.md 文件。这样可以在任务之间保持一致性，减少每次编写详细提示的认知负荷。

编写好提示并选择自定义代理（如适用）后，启动任务。你的代理会立即开始工作。

主动编排的技巧

你现在是代理的指挥家。每个任务可能需要一分钟到一小时，取决于复杂度。你有两种选择：实时观察代理工作以便随时介入，或离开后等它们完成再回来。

读取信号

以下常见指示表明你的代理走偏了，需要额外指导：

• 测试、集成或获取失败——代理无法获取依赖、认证失败，或单元测试反复出错。
• 意外生成文件——在 diff 中出现超出范围的文件，或代理修改了共享配置。
• 超出请求范围的工作——代理开始重构相邻代码或“改进”你未要求的内容。
• 误解你的意图——会话日志显示代理对提示的解释与你的预期不符。
• 循环行为——代理多次尝试同一失败方法而未作调整。

发现问题后，评估其严重程度。该失败的测试是否关键？该集成点对当前任务是否重要？会话日志通常在行动前展示意图，给你提供介入的机会。

引导的艺术

当需要重新指引代理时，请具体说明。解释为何要重新指引以及希望它如何继续。

糟糕的引导： “这看起来不对。”

好的引导：

不要修改 `database.js`——该文件在多个服务之间共享。请改为在 `api/config/db-pool.js` 中添加连接池配置。这样可以将更改限制在 API 层。

时机很关键。若在五分钟内捕捉到问题，可能会节省一小时的无效工作。不要等代理完成后才提供反馈。

你也可以在任务进行中止掉代理并给出更精细的指令。重新启动并提供更好的方向往往比让偏离的代理继续工作更快。

为什么会话日志重要

会话日志展示推理过程，而不仅仅是行为本身。它们在代码生成成为 Pull Request 之前就能暴露误解，并帮助你改进未来的提示和编排实践。当 Copilot 说 “我要重构整个认证系统” 时，就是你需要介入的信号。

审查阶段的技巧

当代理完成任务后，你会得到需要审查的 Pull Request。以下是高效审查的做法。

• 会话日志——了解代理做了什么以及为什么。先在合并代码前发现推理错误。代理是否误解了你的意图？是否做了错误的假设？
• 变更文件——审查实际代码改动。重点关注：
  • 你未预期被修改的文件
  • 触及共享、风险或关键代码路径的更改
  • 与团队标准/实践不符的模式
  • 缺失的边界情况处理
• 检查结果——确认测试通过（单元测试、Playwright、CI/CD 等）。检查失败时，不要直接重新启动代理。先调查原因。测试失败可能表明代理误解了需求，而不仅仅是写出了有 bug 的代码。

这种模式让你获得完整视图：意图、实现和验证。

让 Copilot 自己审查其工作

任务完成后，向它询问：

• “我遗漏了哪些边界情况？”
• “哪些测试覆盖不完整？”
• “我该如何修复这个失败的测试？”

Copilot 往往能自行发现工作中的缺口，帮你节省时间并提升最终结果。把它当作愿意解释自己推理的初级开发者来对待。

批量处理相似审查

使用代理生成代码相对直接。审查这些代码——确保符合标准、实现需求且团队能够维护——仍然需要人工判断。

通过将相似的工作聚合在一起可以提升审查效率。例如，一次性审查所有 API 变更；另一次审查所有文档改动。你的审查流程因此更加结构化且高效。