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

我们最近改进了一个智能体编排框架，名为更智能的子智能体委托。这项改进通过帮助主智能体，让 Copilot CLI 变得更具有选择性：

• 当自己能更快推进时保持专注。
• 当专业智能体能创造真正的杠杆效应时进行委托。
• 当任务真正独立时并行处理工作。

更智能的子智能体委托目前已全面上线到 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 的开发者来说意味着什么。

问题：委托虽强大，但并非没有代价

子代理是智能体命令行界面中最关键的能力之一。它们让 Copilot 能够分解复杂工作、并行执行调研，并让主智能体专注于协调最终答案。对于大型代码库和多步骤工程任务来说，这决定了工作流是缓慢线性的，还是高效并行的。

但委托机制也引入了自身的失败模式：

• 对于主智能体自己就能更快完成的简单任务，却进行了不必要的移交。
• 当移交已经包含足够上下文时，过度使用探索性子代理。
• 主智能体与子代理之间出现重复或重叠的搜索。
• 串行委托：主智能体等待一个子代理完成任务，而没有将委托视为并行工作的机会。
• 容易出错的子代理路径，包括过时的文件路径、被移动的文件、错误的相对路径以及工作区不匹配。

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

从问题信号到交付的改进

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

1. 分析：让大语言模型识别委托瓶颈

我们没有手动审查智能体会话，而是使用大语言模型分析完整轨迹，找出编排在哪里起到了帮助作用，在哪里增加了额外开销。分析揭示了一个一致的模式：子代理有时会被调用去执行那些本已范围狭窄、显而易见或在移交时已被完整描述的任务。

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

2. 变更：优化编排策略

在识别出瓶颈后，我们利用大语言模型帮助将该诊断转化为更具选择性的编排策略。

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

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

使用子智能体时，交接也应具体明确：用户的要求是什么、已知信息有哪些、子智能体负责什么、主智能体需要返回什么样的结果。

3. 验证：线下测试、线上确认，然后上线

在广泛推出之前，我们通过自动生成的回归用例和现有基准验证了该变更。这有助于确认新的委派指导减少了可避免的开销，同时没有破坏子智能体真正有价值的场景。

最后，我们进行了内部员工和公开 A/B 测试，然后分析了可靠性、响应速度、子智能体负载和质量方面的生产指标。提升并非主要来自单个大语言模型调用的加速。相反，它通过避免不必要的子智能体路径和降低每个用户的子智能体负载来减少编排开销。

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

成果

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

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

指标	与对照组的变化量	解读
原始子智能体搜索调用失败	减少15%	可靠性——减少易失败的子智能体搜索路径。
每位用户平均子智能体大语言模型耗时	降低12%	响应性——降低每位用户协调开销。
每位用户子智能体大语言模型耗时（P95）	降低18%	响应性——改善最差情况下的子智能体开销。

这些结果表明，即使可见的功能表面没有变化，更优的协调也能改善开发者体验。通过教会 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、实验、人工评估和产品团队的协作。感谢所有帮助识别问题、设计流程、验证结果并将改进部署到生产环境的人。

文章《我们如何让 GitHub Copilot CLI 在委托时更具选择性》最初发表在 The GitHub Blog 上。