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. 分析：让 LLM 识别委派瓶颈

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

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

2. 修改：优化编排策略

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

Copilot CLI 应直接处理聚焦的工作：找到文件、读取它、进行有针对性的修改并验证。当工作需要独立上下文、广泛探索或并行执行时，委派才更有用。

在实践中，这意味着从最窄的有效路径开始，当复杂性或不确定性带来价值时再升级，而当任务重新变得聚焦时则回退。子智能体应被视为一种并行化工具，而不是暂停按钮。当 Copilot 启动一个子智能体时，主智能体应继续在独立工作上取得进展，而不是单纯等待结果。

当使用子智能体时，交接也应当具体明确：用户提出了什么请求、已经知道什么、子智能体负责什么，以及主智能体需要拿回什么样的结果。

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

在大范围推广之前，我们通过自动生成的回归用例和现有基准测试验证了这一变更。这有助于确认新的委派指导减少了可避免的开销，同时没有破坏子智能体确实能带来价值的那些场景。

最后，我们依次进行了内部员工和公开的 A/B 测试，然后分析了生产环境中的各项指标，涵盖可靠性、响应速度、子智能体工作量和质量。这些收益并非主要来自让单次 LLM 调用变得更快。相反，它通过避免不必要的子智能体路径以及降低每位用户的子智能体工作量，减少了编排开销。

这一端到端流程让我们能够从问题信号推进到已发布的改进，同时保持用户体验稳定：更少可避免的交接、更少易出错的工具路径，并且没有质量回退。

成果

在将更智能的子智能体委派机制推向生产流量后，我们在可靠性和响应性方面看到了可量化的百分比提升（表 1）：

这些结果表明，即便可见的功能界面没有变化，更好的编排也能改善开发者体验。通过教会 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、实验、人工评估和产品团队之间的协作。感谢每一位帮助发现问题、设计流程、验证结果并将改进推向生产环境的人。