我们如何让 GitHub Copilot CLI 更审慎地委托任务

在智能代理系统中，过多的委托并不总是更好。想象一下，你让 Copilot CLI 做一个简单的更改，它却启动一个辅助代理去搜索仓库、等待结果，然后卡住。本来一个步骤就能完成的工作，现在需要三个步骤。虽然某些任务确实需要专业子代理的帮助——比如探索不熟悉的仓库、检查代码的独立区域，或者在主代理继续工作的同时运行一个长命令——但委托并非没有代价。每次交接都会增加协调开销、工具调用和等待时间。如果代理过于急切地委托，“帮助”反而可能变成摩擦。

我们最近发布了一项名为“更智能的子代理委托”的改进，使得 Copilot CLI 更加审慎。它帮助主代理在以下方面做出更好决策：当自己能更快完成任务时保持专注；当专业代理能创造真正价值时进行委托；当任务确实独立时并行化工作。

更智能的子代理委托现已推广到 100% 的 Copilot CLI 生产流量。如果你今天就想开始使用，只需在终端中运行 /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 的开发者意味着什么。

问题：委托强大但并非免费

子代理是代理型 CLI 中最重要的能力之一。它们让 Copilot 分解复杂工作、并行进行调查，并让主代理专注于协调最终答案。对于大型代码库和多步骤工程任务，这可能是缓慢线性工作流与高效并行工作流之间的区别。

但委托引入了自身的故障模式：

• 为简单任务进行不必要的交接，而主代理自己可以更快完成。
• 过度使用探索子代理，而交接时已包含足够上下文。
• 主代理和子代理之间重复或重叠的搜索。
• 顺序委托，主代理等待子代理，而不是将委托视为并行工作的机会。
• 易出错的子代理路径，包括过时的文件路径、移动的文件、不正确的相对路径和工作空间不匹配。

图 1 展示了子代理在工具调用失败而主代理空转的示例。

我们的目标是：帮助开发者在子代理能创造杠杆时使用它们，在它们增加开销时避免它们，并在任务确实受益于独立执行时并行化工作。

从问题信号到交付改进

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

图 2 展示了端到端改进循环：分析、更改、验证和发布。

1. 分析：让 LLM 识别委托瓶颈

我们没有手动审查代理会话，而是使用 LLM 分析完整的轨迹，识别协调何时有帮助、何时增加开销。该分析揭示了一个一致的模式：子代理有时被调用用于已经狭窄、明显或在交接中完全描述的任务。

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

2. 改变：优化协调策略

在识别瓶颈后，我们使用 LLM 帮助将该诊断转化为更审慎的协调策略。

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

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

当使用子代理时，交接也应具体：用户的要求、已知信息、子代理负责的内容以及主代理需要返回的结果类型。

3. 验证：离线测试，在线确认，然后发布

在广泛推广之前，我们使用自动生成的回归案例和现有基准验证了更改。这有助于确认新的委托指导减少了可避免的开销，而没有破坏子代理真正有价值的案例。

最后，我们进行了员工和公开 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 如何应用它们于你已经做的工作，比如读取文件、运行命令，以及从 issue 到 pull request 的推进。

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

下一步是让 Copilot CLI 在模型、代理、技能和工具方面更具适应性，这样开发者就不必决定任务是否需要更大的模型、专业的子代理或程序化技能。Copilot 应根据任务、仓库上下文、策略和预期结果做出决定。

我们将继续改进 Copilot CLI 的计划工作、协调子代理和测量端到端结果的方式。这包括更好地可见主代理和子代理行为、更深入地分析故障原因，以及更强大的协调质量代理指标。目标很简单：更少的等待、更少的可避免故障，以及每个代理会话中更有用的进展。

立即开始并分享反馈

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

已经尝试过？我们期待听到你的想法。通过 CLI 会话中的 /feedback 命令分享反馈，或在我们的公共仓库中提交 issue。

致谢

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