Signal #36：Coding Agent 正在接管模型选择与组合

用 AI 写代码时，除了把需求讲清楚、检查生成的代码，我们还会遇到一个选择：用哪个模型。

处理简单修改，我们可能更在意响应速度；面对复杂问题，则愿意多花一些时间，换取更充分的分析。任务推进不顺利时，还会考虑换个模型再试，或请另一个模型检查已有结果。这些选择需要人根据任务的进展不断调整。

10 月 28 日，GitHub Copilot Fusion 正式可用。它把模型选择与多模型协作放进同一个入口：用户选择投入强度，具体用哪些模型、是否升级、是否安排其他模型评审，由系统按任务决定。

本期关注的就是这项变化：Coding Agent 正在承担一部分原本需要人手动安排的模型选择与协作。

选择一个模型，通常意味着接下来的工作主要交给它完成。Fusion 还要做另一层选择：这次请求适合怎样的执行方式。

GitHub 的发布说明与官方文档介绍了三类模式。

这三种模式分别改变了模型数量、执行顺序和结果如何被检查。“这次用什么模型”因而包含了更多决策：要不要先尝试一次，什么时候增加投入，评审是否值得多花一次调用。

自动模型选择和多模型协作已有先例。GitHub 在 9 月的 HydraFusion 研究预览中，就公开了这三类模式。本周的增量，是它与已有自动选模型能力合并，正式进入 Copilot 产品。

把这些安排交给工具，可以减少使用者逐步切换模型的操作。与此同时，决定任务效果的因素也多了一层：系统选中的执行方式是否适合当前任务。

例如，一个模型已经找准问题并改好了大部分代码，此时追加评审可能有用；如果问题来自需求缺失，换一个更强模型也未必能补齐依据。这是对执行策略的工程判断，具体表现需要用任务结果验证。

模型协作还会碰到工作区状态。Fusion 文档提醒：如果系统丢弃一份初稿，它已经在工作区中做出的文件修改不会自动撤销，提交前仍需检查改动。

丢弃一份回答，与撤销它做过的操作，是两件事。 一个 Agent 可以在对话里给出经过修订的最终答案，文件却可能保留前一次尝试留下的改动。因此，评价模型协作时，也需要检查最终代码是否一致、尝试之间有没有相互干扰。

对使用者而言，可以减少手动安排；对工具建设者而言，模型选择需要和上下文交接、文件修改、失败处理一起设计。

同样在 10 月 28 日，Vercel 发布了 Virtual Models。它处理的是另一件事：应用和 Agent 应该怎样引用、更新模型配置。

例如，应用调用一个按任务命名的固定 ID，具体模型和回退规则保存在网关。团队调整背后的配置后，使用该 ID 的调用会采用新配置，无需逐个修改应用代码或重新部署。

图 2：Fusion 按任务选择执行方式；Virtual Models 由团队集中管理模型配置。两者分别对应请求执行与共享配置。

两类能力可以分别理解：Fusion 负责一次请求采用哪些模型、怎样执行；Virtual Models 让多个调用方复用团队维护的模型配置。集中配置本身，并不能证明系统会判断一个初稿是否合格，也不等同于自动安排交叉评审。

它们在不同位置减少了使用者和应用代码直接管理模型的工作。模型使用方式由此可以被单独调整，而应用继续面向相对稳定的任务入口。

配置改起来容易，行为兼容仍需验证。Vercel 在发布说明中建议：更换生产模型之前，先通过候选 ID 运行评测，并保留切回原配置的路径。

当一个 Agent 可以自行选择和组合模型，“这个工具用了什么模型”就只能解释一部分表现。同样的模型池，也可能因为升级时机、评审方式和上下文交接不同，产生不同结果。

对团队来说，可以从自己的真实任务中选择一组案例，把固定使用某个模型，与自动选择或多模型协作放在相近条件下比较。下面几项尤其值得记录：

这些是本文建议采用的比较方法，不能由产品正式可用直接推导出它已经在所有研发场景中胜出。自动选择可能节省手工操作，追加调用也可能增加等待和费用，最终仍要看任务有没有更可靠地完成。

本周值得继续跟踪的是，Coding Agent 能否逐步承担“怎样使用模型”这部分工作。当我们选择一个 Agent 产品时，选择的也可能是一套模型使用策略。 它能否在合适的时候直接完成、增加投入或引入评审，会成为影响工具表现的一项因素。