How we made GitHub Copilot CLI more selective about delegation

标题：我们如何让 GitHub Copilot CLI 在委派任务时更加谨慎

URL 来源：https://github.blog/ai-and-ml/how-we-made-github-copilot-cli-more-selective-about-delegation/

发布时间：2026-06-12T15:26:23-07:00

Markdown 内容： 在智能代理系统中，更多的委派并不总是更好。想象一下，你让 Copilot CLI 去完成一个简单的更改。它并没有直接处理，而是启动了一个辅助代理，搜索仓库、等待结果，从而导致延迟。本应一步完成的工作现在需要三步。虽然某些任务确实可以从专门的子代理中受益，例如探索一个不熟悉的仓库、检查代码的独立部分，或在主代理继续前进的同时运行一个长时间的命令，但委派并不是免费的。每一次交接都会增加协调开销、工具调用和等待时间。如果代理过于急于委派，这种“帮助”反而会成为摩擦。

我们最近对我们的智能代理框架进行了改进，称为更智能的子代理委派。这使得 Copilot CLI 更加谨慎，帮助主代理：

• 在它能够更快独立完成任务时保持专注。
• 在专门的子代理确实能带来实际优势时进行委派。
• 在任务真正独立时并行处理工作。

更智能的子代理委派现已全面部署到 Copilot CLI 的 100% 生产流量中。如果你想今天就开始使用，只需在终端中运行 /update 命令，将 GitHub Copilot CLI 更新到 1.0.42 或更高版本。

在一项生产 A/B 测试中，这项改进将每会话的工具失败率降低了 23%，其中包括搜索工具失败率降低了 27%，以及编辑工具失败率降低了 18%。它还使总用户等待时间在 P95 水平上提高了 5%，在 P75 水平上提高了 3%，且 没有质量退化。在这里，P95 表示接近最慢 5% 会话的等待时间，而 P75 表示接近典型会话较慢端的等待时间。这意味着更少的不必要的交接、更少的重复搜索、更少的容易失败的工具路径，以及在长时间编码任务中更少的等待。

在本文中，我们将介绍我们如何识别 Copilot CLI 中的不必要委派，我们做了哪些更改以使委派更加谨慎，以及我们如何通过离线评估和生产 A/B 测试验证这些更改。我们还将展示这些更改为何导致了更少的失败和更少的等待，并且对于日常使用 Copilot CLI 的开发人员来说，这会是什么样子。

_图 1. 示例：当主代理处于空闲状态时，子代理的工具调用失败。_

我们的目标：帮助开发人员在能够创造杠杆效应时使用子代理，在增加开销时避免使用子代理，并在任务确实能从独立执行中受益时并行处理工作。

从问题信号到上线改进

我们识别问题的方式也成为了我们解决问题的方式。我们没有将代理轨迹分析、产品更改、评估和发布作为独立的活动，而是将它们视为一个反馈循环：观察代理行为，隔离编排瓶颈，进行有针对性的更改，离线验证，在线测量，并且只有在端到端工作流程得到改善后才上线。

_图 2. 端到端改进循环：分析、更改、验证和上线。_

1. 分析：让 LLM 识别代理瓶颈

我们没有手动审查代理会话，而是使用 LLM 来分析完整的轨迹，识别编排在哪些地方有帮助，哪些地方增加了开销。该分析揭示了一个一致的模式：子代理有时被调用执行的任务已经很明确、显而易见，或者在交接时已经完全描述。

在这些情况下，子代理可能会花费时间重新搜索仓库，尽管主代理已经拥有足够的上下文可以直接采取行动。这明确了改进目标：将简单的发现和编辑任务保留在主代理中，而将子代理保留用于更广泛、跨领域或自然可并行的任务。

1. 更改：优化编排策略

在识别出瓶颈后，我们使用 LLM 来帮助将这一诊断转化为更选择性的编排策略。

Copilot CLI 应该直接处理专注的工作：查找文件，阅读它，进行有针对性的更改，并验证它。当工作需要独立的上下文、广泛的探索或并行执行时，委托才更有用。

在实践中，这意味着从最狭窄的有效路径开始，当复杂性或不确定性带来价值时升级，当任务再次变得专注时再回到较低的层级。子代理应被视为一种并行工具，而不是暂停按钮。当 Copilot 启动子代理时，主代理应继续在独立工作上取得进展，而不是仅仅等待结果。

当使用子代理时，交接也应具体：用户要求了什么，已经知道什么，子代理负责什么，以及主代理需要什么样的结果。

1. 验证：离线测试，确认在线结果，然后上线

在全面推广之前，我们通过自动生成的回归测试用例和现有基准测试验证了这一更改。这帮助我们确认了新的代理委托指南在不破坏子代理真正带来价值的案例的前提下，减少了可避免的开销。

最后，我们通过员工和公众的A/B测试进行验证，然后分析了生产环境中的指标，包括可靠性、响应性、子代理工作负载和质量。这些改进并非主要来自于加快单个LLM调用的速度。相反，它通过避免不必要的子代理路径并降低每个用户的子代理工作负载，减少了协调开销。

这一端到端的过程使我们能够从问题信号过渡到已部署的改进，同时保持用户体验的稳定：更少的可避免的交接，更少的容易失败的工具路径，以及没有质量退化。

成果

在将更智能的子代理委托功能部署到生产流量后，我们在可靠性和响应性方面看到了可衡量的百分比提升（表1）：

| 维度 | 指标 | 变化 | | --- | --- | --- | | 可靠性 | 每会话工具失败次数 | 降低23% | | 可靠性 | 搜索工具失败次数 | 降低27% | | 可靠性 | 编辑工具失败次数 | 降低18% | | 响应性 | P95用户等待总时间 | 降低5% | | 响应性 | P75用户等待总时间 | 降低3% | | 质量 | 质量指标 | 无退化 |

表1. 生产A/B测试结果

| 指标 | 与对照组的差异 | 解释 | | --- | --- | --- | | 失败的原始子代理搜索调用 | 降低15% | 可靠性 – 更少的容易失败的子代理搜索路径。 | | 每用户平均子代理LLM持续时间 | 降低12% | 响应性 – 每用户减少的协调开销。 | | 每用户P95子代理LLM持续时间 | 降低18% | 响应性 – 更好的最坏情况子代理开销。 |

表2. A/B测试结果背后的方向性代理轨迹分析

这些结果表明，即使可见的功能表面没有变化，更好的协调也可以改善开发人员的体验。通过教会Copilot CLI何时委托、何时不委托以及如何并行处理正确的工作，我们减少了代理循环本身的摩擦。

这就是GitHub Copilot作为系统的力量：体验的提升不是因为开发人员被给予了更多的开关来管理，而是因为Copilot在幕后更好地分配了模型、工具和子代理。

对开发人员的当前好处

对于使用Copilot CLI的开发人员来说，这应该会带来更流畅的日常体验。简单的任务更有可能直接处理，复杂任务在确实有价值时仍能获得专家帮助，长时间的会话也能更顺利地进行，减少不必要的等待。实际上，Copilot CLI变得更加高效且不那么嘈杂，而无需开发人员改变工作方式。

这一更改是特意在幕后进行的。您的工作流程保持不变，但Copilot CLI在协调工作方面表现得更好：更少的不必要的交接，更少的重复搜索工作，更少的失败工具路径，以及在长时间或多步骤任务上的更快进展。

下一步是什么

这项工作是我们更大目标的一部分，即改进 Copilot CLI 在工作流程中选择合适模型、代理和工具的方式。虽然拥有更多代理和模型可以扩展 Copilot 的功能，但对开发人员的价值取决于 Copilot 在他们正在进行的工作（如阅读文件、运行命令、从问题转向拉取请求）中应用这些功能的效果。

随着任务变得越来越复杂，这种协调工作的质量变得越来越重要。最好的系统不是委托最多任务的系统，而是知道何时直接行动、何时委托任务、以及如何在不增加摩擦的情况下推动工作进展的系统。

下一步是使 Copilot CLI 在模型、代理、技能和工具之间更加适应，这样开发人员就不需要决定某个任务是否需要更大的模型、专家子代理或过程技能。Copilot 应该根据任务本身、仓库上下文、策略和预期结果来做出这个决定。

我们将继续改进 Copilot CLI 如何规划工作、协调子代理以及衡量端到端的结果。这包括对主代理和子代理行为的更好可见性、对失败原因的深入分析，以及对协调质量的更强代理指标。目标很简单：减少等待时间，减少可避免的失败，并从每次代理会话中获得更多的有用进展。

立即开始并分享反馈

通过在终端中运行 /update 命令，将 GitHub Copilot CLI 更新到 1.0.42 或更高版本。

已经尝试过了吗？我们很乐意听到你的想法。在 CLI 会话中使用 /feedback 命令分享反馈，或在 我们的公共仓库 中提交问题。

致谢

更智能的子代理委托功能得益于 Code|AI、Copilot CLI、实验、人工评估和产品团队之间的协作。感谢所有帮助识别问题、设计流程、验证结果并将改进部署到生产环境的人。

作者

微软 Code | AI 首席应用科学家。我是技术负责人，通过数据驱动的分析推动以产品为导向的 AI 研究，以提升 GitHub Copilot CLI 的体验。

微软 Code | AI 首席应用科学经理。我领导一个应用研究团队，专注于通过智能代码模型和代码代理提高开发人员的生产力。我们的团队还通过将研究创新应用到产品中，优化 Copilot 的体验。