作者：Pingping Lin & Yu Hu
排版：Alan Wang
更优的智能体编排、更少的任务交接、更快的执行进展------无需新增任何配置或开关。
在智能体系统中，更多的委派并不一定意味着更好。设想一下，你让 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 的体验中。
问题：委派能力很强，但并非没有代价
子智能体是 Agentic CLI 最重要的能力之一。它们能够帮助 Copilot 拆解复杂任务、并行开展调查，并让主智能体专注于协调最终答案。对于大型代码库和多步骤的软件工程任务来说，这种能力可以让工作流从缓慢的串行执行变成高效的并行执行。
但委派也会引入自身的失败模式：
-
对于本可以由主智能体更快完成的简单任务，仍然发生了不必要的任务交接。
-
在任务交接已经包含足够上下文的情况下，仍然过度使用探索型子智能体。
-
主智能体与子智能体之间重复或重叠地执行搜索。
-
顺序式委派，即主智能体等待子智能体完成，而没有将委派视为开展并行工作的机会。
-
容易失败的子智能体执行路径，包括过期的文件路径、已移动的文件、错误的相对路径以及工作区不匹配等问题。
我们的目标是：在子智能体能够真正带来价值时帮助开发者使用它们，在它们只会增加额外开销时避免使用，并且仅在任务确实能够独立执行时实现并行化。
从问题信号到正式发布的改进
我们发现问题的方式，也成为了解决问题的方式。我们没有将智能体轨迹分析、产品改进、评估和发布视为彼此独立的工作，而是将它们作为同一个反馈闭环：观察智能体行为，定位智能体编排中的瓶颈，进行有针对性的改进，通过离线评估进行验证，再通过线上评估进行衡量，只有当整个端到端工作流得到改善后才正式发布。
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% | 响应速度------每位用户的智能体编排开销进一步降低。 |
| 每位用户的子智能体 LLM P95 执行时长 | 降低 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 或更高版本，即可立即体验这一改进。
如果你已经体验过，我们非常希望听到你的反馈。你可以在 Copilot CLI 会话中使用 /feedback 命令提交反馈，或者前往我们的公开代码仓库提交 Issue。
致谢
更智能的子智能体委派的实现，离不开 Code|AI、Copilot CLI、实验平台、人工评估以及产品团队之间的紧密协作。感谢所有参与其中的同事，帮助我们发现问题、设计优化方案、验证改进效果，并最终将这一能力成功发布到生产环境。