在智能体系统中，更多的委派并不总是更好。想象一下，你让 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 的开发者来说意味着什么。
问题所在：委派功能强大，但并非没有代价
子智能体是智能体化命令行界面中最关键的能力之一。它们让 Copilot 能够分解复杂工作、并行开展调查，并让主智能体专注于协调最终答案。对于大型代码库和多步骤工程任务而言，这可能是缓慢线性工作流与高效并行工作流之间的分水岭。
但任务委派也引入了自身的故障模式：
- 对于主智能体本可更快独立完成的简单任务，进行了不必要的交接。
- 当交接信息已包含足够上下文时，过度使用探索性子智能体。
- 主智能体与子智能体之间出现重复或重叠的搜索。
- 顺序委派，即主智能体等待子智能体完成，而非将委派视为并行工作的机会。
- 易出故障的子智能体路径，包括过时的文件路径、已移动的文件、错误的相对路径以及工作区不匹配。
我们的目标：帮助开发者在子智能体能创造杠杆效应时使用它们，在它们增加开销时避免使用，并在任务确实受益于独立执行时实现工作并行化。
从问题信号到已上线的改进
我们识别问题的方式，最终也成了我们解决问题的方式。我们没有将智能体轨迹分析、产品变更、评估和发布视为独立活动，而是将它们整合为一个反馈循环：观察智能体行为，定位编排瓶颈，进行针对性修改，离线验证，在线测量，只有当端到端工作流得到改善后才发布上线。
1. 分析：让大语言模型识别委派瓶颈
我们没有手动审查智能体会话，而是使用大语言模型分析完整轨迹，识别编排在哪些方面发挥了作用，又在哪些方面增加了开销。该分析揭示了一个一致的模式：子智能体有时会被调用来处理那些本就范围狭窄、显而易见或已在交接信息中完整描述的任务。
在这些情况下，即使主智能体已经拥有足够的上下文可以直接行动，子智能体仍可能花费时间重新搜索代码仓库。这明确了改进目标：将简单的发现和编辑任务保留在主智能体中，而将子智能体用于更广泛、跨领域或天然可并行化的工作。
2. 变更：优化编排策略
在识别出瓶颈后，我们利用大语言模型帮助将该诊断转化为更具选择性的编排策略。
Copilot CLI 应直接处理聚焦的工作：查找文件、读取文件、进行有针对性的修改并验证。当工作需要独立的上下文、广泛的探索或并行执行时，委派任务才更有用。
在实践中，这意味着从最窄的有效路径开始，当复杂性或不确定性创造价值时进行升级，当任务再次变得聚焦时则降级。子智能体应被视为一种并行工具，而非暂停按钮。当 Copilot 启动一个子智能体时，主智能体应继续在独立工作上取得进展，而不是简单地等待结果。
当使用子智能体时，交接也应该是具体的：用户的要求是什么、已知信息是什么、子智能体负责什么、以及主智能体需要返回什么样的结果。
3. 验证：离线测试，在线确认，然后发布
在广泛发布之前，我们通过自动生成的回归测试用例和现有基准验证了这项变更。这有助于确认新的委派指导减少了可避免的开销，同时没有破坏子智能体真正能带来价值的场景。
最后，我们进行了内部员工和公开的 A/B 测试，然后分析了包括可靠性、响应性、子智能体工作负载和质量在内的生产指标。性能提升主要并非来自让单个大语言模型调用变得更快。相反，它通过避免不必要的子智能体路径并降低每个用户的子智能体工作负载，减少了编排开销。
这个端到端流程使我们能够从发现问题信号到交付改进，同时保持用户体验稳定：更少的可避免交接、更少的易出错工具路径，并且没有质量回退。
成果
在将更智能的子智能体委派功能部署到生产流量后，我们在可靠性和响应性方面看到了可衡量的百分比提升（表 1）：
| 维度 | 指标 | 变化量 |
|---|---|---|
| 可靠性 | 每次会话的工具失败次数 | 降低 23% |
| 可靠性 | 搜索工具失败次数 | 降低 27% |
| 可靠性 | 编辑工具失败次数 | 降低 18% |
| 响应性 | P95 用户总等待时间 | 降低 5% |
| 响应性 | P75 用户总等待时间 | 降低 3% |
| 质量 | 质量指标 | 无退化 |
| 指标 | 与对照组的变化量 | 解读 |
|---|---|---|
| 失败的原始子智能体搜索调用 | 降低 15% | 可靠性——减少了容易失败的子智能体搜索路径。 |
| 每位用户的平均子智能体 LLM 耗时 | 降低 12% | 响应性——降低了每位用户的编排开销。 |
| 每位用户的 P95 子智能体 LLM 耗时 | 降低 18% | 响应性——改善了最差情况下的子智能体开销。 |
这些结果表明，即使可见的功能界面没有变化，更好的编排也能改善开发者体验。通过教会 Copilot CLI 何时委派、何时不委派以及如何并行处理正确的工作，我们减少了智能体循环本身中的摩擦。
这就是 GitHub Copilot 作为一个系统的力量所在：体验变得更好，不是因为开发者需要管理更多开关，而是因为 Copilot 在幕后能更好地分配模型、工具和子智能体。
这对今天的开发者有何益处
对于使用 Copilot CLI 的开发者来说，这应该会带来更顺畅的日常体验。简单的任务更有可能被直接处理，复杂的任务在需要时仍能获得专业帮助，而长时间运行的会话也能持续推进，减少不必要的等待。在实践中，Copilot CLI 变得更高效、更少干扰，且无需开发者改变工作方式。
这一变化有意设计在幕后。你的工作流程保持不变，但 Copilot CLI 能更好地协调工作：更少不必要的交接、更少重复的搜索工作、更少的失败工具路径，以及在长时间运行或多步骤任务上更快的进展。
下一步计划
这项工作是我们更大目标的一部分，即改进 Copilot CLI 如何在你的工作流程中选择合适的模型、智能体和工具。虽然拥有更多可用的智能体和模型能扩展 Copilot 的能力，但对开发者的价值取决于 Copilot 能否将其很好地应用于他们已经在做的工作中，例如读取文件、运行命令，以及从 issue 推进到拉取请求。
随着任务变得越来越复杂，这种编排的质量就愈发重要。最好的系统不是委派最多的系统，而是知道何时直接行动、何时委派，以及如何在不增加摩擦的情况下保持工作推进的系统。
下一步是让 Copilot CLI 在模型、智能体、技能和工具之间更具适应性，这样开发者就不必自行判断某个任务是需要更大的模型、专门的子智能体，还是程序性技能。Copilot 应根据任务、仓库上下文、策略和预期结果来做出这一决定。
我们将持续改进 Copilot CLI 规划工作、协调子智能体以及衡量端到端结果的方式。这包括更好地洞察主智能体和子智能体的行为、更深入地分析失败原因，以及更强大的编排质量代理指标。目标很简单：减少等待，减少可避免的失败，并从每次智能体会话中取得更多有价值的进展。
立即开始使用并分享反馈
通过在终端中运行 `/update` 命令，将 GitHub Copilot CLI 更新至 1.0.42 或更高版本。
已经试过了？我们很想听听你的想法。在 CLI 会话中使用 `/feedback` 命令分享反馈，或在我们的公共仓库中提交 issue。
致谢
更智能的子智能体委派功能得益于 Code|AI、Copilot CLI、实验、人工评估和产品团队之间的协作。感谢每一位帮助识别问题、设计流程、验证结果并将改进成果交付到生产环境的人。