作者：Nick McKenna & Bartek Perz
排版：Alan Wang
了解 Rubber Duck 如何为 GitHub Copilot CLI 带来不同的思路与视角。
当你让一个编码智能体构建数据管道时，它未必会采用最优结构。但如果在执行方案之前，让它先获得"第二视角"呢？
今天，在 GitHub Copilot CLI 中，我们以实验模式 引入 Rubber Duck。它利用来自不同 AI 模型家族的第二个模型，作为独立评审者，在关键时刻对智能体的计划与执行进行评估与反馈。
为了捕捉不同类型的错误，引入不同视角至关重要。我们的评估显示，Claude Sonnet + Rubber Duck 能弥补 Sonnet 与 Opus 之间 74.7% 的性能差距，在处理复杂的多文件、长流程任务时表现更佳。你可以通过在 Copilot CLI 中使用 /experimental 来启用 Rubber Duck 及其他实验特性。
问题：自信的错误会被不断放大
当前的编码智能体通常遵循一个清晰的循环：分析任务 → 制定计划 → 实现 → 测试 → 迭代。这一流程强大且高效，但也存在盲点。早期（尤其是规划阶段）的决策，会成为后续所有工作的基础。一旦存在假设偏差或效率问题，就会逐步演变为依赖，等你发现时，往往已经不只是修复一个小错误那么简单。
运用自我反思机制，让智能体在推进任务前先审视自身的输出内容，是一种经过验证的有效方法。然而，模型对自身工作成果进行审核时，仍会受限于其自身的训练偏差：相同的数据来源、相同的训练方法，也意味着相同的盲点仍然存在。
Rubber Duck：引入第二种视角
Rubber Duck 是一个专注于评审的智能体，由与你当前 Copilot 会话"互补"的模型驱动。例如，当你选择 Claude 作为主调度模型时，Rubber Duck 会使用 GPT-5.4。在我们对 Rubber Duck 进行试验的同时，也在为编排器和 Rubber Duck 本身探索其他模型系列。Rubber Duck 的职责是核查主智能体的工作，并输出一份简短且高价值的问题清单，包括：
-
主智能体可能忽略的细节
-
值得质疑的假设
-
需要考虑的边界情况
何时跨模型评审最有效？
我们在开源代码库中选取了规模庞大、难度较高且源自真实场景的编程问题，构建了 SWE-Bench Pro 基准测试集，并基于该数据集对 Rubber Duck 进行了评估。结果如下：
Claude Sonnet 4.6 搭配运行 GPT-5.4 的 Rubber Duck，其解决率接近单独运行的 Claude Opus 4.6，填补了 Sonnet 与 Opus 之间 74.7% 的性能差距。
我们发现，Rubber Duck 在处理复杂难题时助力更为显著，这类问题涉及 3 个以上文件，通常需要 70 个以上步骤才能解决。在这类问题上，Sonnet 搭配 Rubber Duck 的表现比 Sonnet 基准模型高出 3.8%；而在三次测试中筛选出的最难问题上，这一优势提升至 4.8%。以下是 Rubber Duck 所发现问题的几个示例：
-
架构问题（OpenLibrary / 异步调度器）：Rubber Duck 发现所设计的调度器在启动后会立即退出，导致没有任何任务被执行；即便修复该问题，其中一个被调度的任务本身也是一个无限循环。
-
**单行代码引发的严重漏洞（OpenLibrary / Solr）**Rubber Duck 发现一个循环在每次迭代时都会悄无声息地覆盖同一个
dict键，导致四个 Solr 分面类别中有三个在每次搜索查询中被丢弃，且没有任何错误提示。 -
跨文件冲突（NodeBB / 邮件确认）：Rubber Duck 发现有三个文件都在读取同一个 Redis 键，而新代码已经不再向该键写入数据，导致确认界面和清理流程在部署后会悄然失效。
Rubber Duck 何时触发？
GitHub Copilot 可以自动调用 Rubber Duck，既可以主动触发，也可以在需要时被动触发；同时，用户也可以在任意时刻手动发起评审，让其对结果进行检查和优化。
对于复杂任务，GitHub Copilot 通常会在"反馈价值最高"的关键节点自动请求评审：
-
制定计划之后：这是最关键的阶段，因为尽早发现不合理的决策，可以避免后续错误不断放大
-
完成复杂实现之后：此时通过"第二双眼睛"审查复杂代码，有助于发现边界情况问题
-
编写测试之后、执行测试之前：可以提前发现测试覆盖不足或断言错误，避免误以为"一切正常"
当智能体陷入循环或无法继续推进时，也会被动触发评审，通过咨询 Rubber Duck 来打破僵局。
作为用户，你可以在任何时候请求评审。Copilot 会调用 Rubber Duck，对反馈进行分析，并清晰展示修改内容及其原因。
在设计上，我们刻意让 Rubber Duck 低频但高价值地介入，只在最关键的时刻提供帮助，而不会打断整体工作流。对于技术细节感兴趣的用户：Rubber Duck 是通过 Copilot 现有的任务工具机制调用的，与其他子智能体使用相同的基础设施。
目前，Rubber Duck 已支持在模型选择器中作为"主调度模型"的所有 Claude 系列模型（Opus、Sonnet 和 Haiku）。同时，我们也在探索更多模型组合，例如让 GPT-5.4 作为主模型时的搭配方案。
开始使用
Rubber Duck 现已以实验模式提供。
要开始使用，只需安装 GitHub Copilot CLI，并运行 /experimental 命令。当你在模型选择器中选择任意 Claude 模型，并且已开通 GPT-5.4 权限时，即可使用 Rubber Duck。你将通过两种方式看到评审结果：
-
自动触发：当 Copilot 判断某个关键节点需要"第二视角"时，例如在制定计划后、完成复杂实现后或编写测试后
-
按需触发：在任何时候，你都可以让 Copilot 对其工作进行评审，它会调用 Rubber Duck，整合反馈，并清晰展示具体改动内容
Rubber Duck 最适合的使用场景：
-
复杂重构与架构调整
-
高风险任务（错误代价较高）
-
确保测试覆盖的完整性
-
在执行方案前获取"第二意见"
GitHub Copilot CLI 中的 Rubber Duck 现已开放实验模式，欢迎在社区讨论中分享你的使用反馈。