我们如何让GitHub Copilot CLI更审慎地选择委托

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

我们最近对我们的智能体框架进行了一项改进，称为更智能的子 agent 委派。这通过帮助主 agent 使 Copilot CLI 更具选择性：当它可以自行更快推进时保持专注；当专家能创造真正杠杆时进行委派；当任务真正独立时并行化工作。更智能的子 agent 委派现已推广到 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 的开发者意味着什么。

问题：委派很强大，但并非没有代价

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

但委派引入了自身的失败模式：

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

图 1. 示例：主 agent 空闲时子 agent 的工具调用失败。

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

从问题信号到发布改进

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

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

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

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

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

2. 更改：优化编排策略

在识别瓶颈后，我们使用 LLM 帮助将该诊断转化为更具选择性的编排策略。Copilot CLI 应直接处理聚焦的工作：查找文件、读取它、进行针对性更改并验证。当工作需要独立上下文、广泛探索或并行执行时，委派更有用。在实践中，这意味着从最窄的有效路径开始，当复杂性或不确定性创造价值时升级，当任务再次变得聚焦时降级。子 agent 应被视为并行工具，而不是暂停按钮。当 Copilot 启动子 agent 时，主 agent 应继续在独立工作上取得进展，而不是简单地等待结果。当使用子 agent 时，交接也应具体：用户要求了什么，已知了什么，子 agent 负责什么，以及主 agent 需要什么样的结果。

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

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

最后，我们进行了内部和公开 A/B 测试，然后分析了可靠性、响应性、子 agent 工作负载和质量方面的生产指标。收益主要不是来自使单个 LLM 调用更快。相反，它通过避免不必要的子 agent 路径和降低每个用户的子 agent 工作负载，减少了编排开销。

这个端到端过程使我们能够从问题信号到发布改进，同时保持用户体验稳定：更少的可避免交接、更少的易失败工具路径，且没有质量回退。

成果

在将更智能的子 agent 委派推广到生产流量后，我们在可靠性和响应性方面看到了可衡量的百分比改进（表 1）：

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

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

指标	与对照组的变化	解读
失败的原始子 agent 搜索调用	降低 15%	可靠性——更少的易失败子 agent 搜索路径
每个用户的平均子 agent LLM 持续时间	降低 12%	响应性——每个用户的编排开销减少
每个用户的 P95 子 agent LLM 持续时间	降低 18%	响应性——最坏情况下的子 agent 开销改善

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

这些结果表明，即使可见的功能表面没有变化，更好的编排也能改善开发者体验。通过教导 Copilot CLI 何时委派、何时不委派以及如何并行化正确的工作，我们减少了 agent 循环本身的摩擦。

这就是 GitHub Copilot 作为系统的力量：体验变得更好，不是因为开发者有更多开关需要管理，而是因为 Copilot 在幕后更好地分配模型、工具和子 agent。

这对今天的开发者有何益处

对于使用 Copilot CLI 的开发者来说，这应该感觉像更流畅的日常体验。直接的任务更可能被直接处理，复杂的任务在增加价值时仍会获得专家帮助，长时间运行的会话会以更少的不必要等待继续推进。在实践中，Copilot CLI 变得更高效、更少噪音，而无需开发者改变工作方式。

这一变化有意在幕后进行。你的工作流程保持不变，但 Copilot CLI 能更好地协调工作：更少的不必要交接、更少的重复搜索工作、更少的失败工具路径，以及在长时间运行或多步骤任务上更快的进展。

下一步

这项工作是我们更大目标的一步，即改进 Copilot CLI 如何在整个工作流中选择正确的模型、agent 和工具。虽然拥有更多 agent 和模型扩展了 Copilot 的能力，但对开发者的价值取决于 Copilot 如何将它们应用于他们已经在做的工作，比如读取文件、运行命令，以及从 issue 转向 pull request。

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

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

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

立即开始并分享反馈

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

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

致谢

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

这篇文章《我们如何让 GitHub Copilot CLI 在委派方面更具选择性》最初出现在 GitHub 博客上。