作者：卢建晖

排版：Alan Wang

随着开发者工具迈入智能体 AI 时代，人们很容易陷入一种熟悉的习惯：当任务很重要时，就选择能力最强、通常也最昂贵的模型。

但实际的软件开发工作远比这复杂。解释一个函数、编辑 README、添加边界测试、调试跨模块竞态条件，以及审查身份验证逻辑，这些任务对推理能力、上下文、工具使用和可靠性的要求截然不同。如果每一轮交互都使用固定模型，要么会浪费时间和预算，要么会导致复杂任务得不到足够强的模型支持。

这正是 decision-ghc-router 项目的出发点：GitHub Copilot 继续负责执行任务，而决策路由器会在每一轮新的用户交互开始时，选择一个可靠性足够高且成本合理的模型。（这一设计也借鉴了 gargpratyush/jev-router，尤其是其按轮次进行路由、保留原生 CLI 行为，以及在工具调用的后续执行过程中固定模型的做法。）

我们的目标不是在 Copilot 之外再构建一个智能体，也不是用自定义聊天界面取代开发者熟悉的原生体验。GitHub Copilot CLI 和 VS Code 的 GitHub Copilot 扩展应当继续保留现有的身份验证、模型目录、工具、权限、会话和流式响应行为。路由器只增加一个简短、明确的决策步骤，然后便不再介入。

1. 首先明确一个区别：决策模型不等于模型路由器

在讨论具体实现之前，需要区分两个经常被混为一谈的概念。

决策模型：进行有界、结构化的判断

决策模型接收的提示不是“写一篇文章”，而是以下内容：

• 以文本或 JSON 表示的当前状态；

• 一个或多个有明确范围的问题；

• 明确的选项或评分标准。

它返回软件可以立即处理的类型化结果和概率，而不是自由形式的文本。例如：

• noul： 这次工具调用是否会触及生产数据？返回一个介于 0 和 1 之间的概率。

• choice： 这项任务应该使用 Fast、Balanced 还是 Strong 档位？返回选定的选项，以及每个选项对应的概率。

• score： 这次代码变更的风险有多高？返回一个有序评分及其概率分布。

因此，决策模型是一种快速、可校准的判断能力。它的用途不仅限于模型选择，还包括分类、排序、优先级划分、验证、智能体控制、安全筛查和 AI 评判。

模型路由器：将判断转化为执行

模型路由器是一种系统设计模式，而不是单个模型。一个可用于生产环境的路由器通常需要完成以下工作：

1. 发现当前登录账户实际可用的模型；

2. 排除不可用、没有价格信息、上下文容量不足或 API 不兼容的候选模型；

3. 构建最精简的路由状态；

4. 调用评分器。评分器可以是规则、基准测试表、LLM 分类器或决策模型；

5. 根据置信度、成本、延迟、安全要求和组织策略执行相应处理；

6. 选择具体模型并启动原生执行流程；

7. 在后续工具调用过程中固定所选模型；

8. 记录决策、估算结果和失败情况，以便审计和调优。

简而言之：

决策模型判断什么最合适。模型路由器则让这一判断变得可用、合规、可执行、可观测，并且能够在发生问题时恢复。

决策路由器并不会取代更完整的路由系统，而是为该系统提供一个专门、快速且便于设置阈值的评分引擎。

决策模型与模型路由器的区别

2. Microsoft-Decision-1：为什么它适合开发者工具路由

微软于 2026 年 10 月推出了 Microsoft-Decision-1。这是一款专门用于快速决策评分的模型，可通过 Microsoft Foundry 使用。与生成式 LLM 不同，它不会生成文章或书面推理链，而是针对文本或 JSON 做出聚焦的判断，并返回类型化的数值决策结果。

微软将这款模型描述为基于 Qwen3.5-9B 进行后训练的模型，专为针对固定选项的单次评分而设计。微软公布的结果显示，在涵盖近 15 万个训练过程中未见过的问题、共涉及 36 项基准测试的对比中，该模型取得了最高准确率；其中位延迟（P50）约比 GPT-6 Sol 快 35 倍；在八种扰动类型下，平均决策翻转率为 1.3%。在发布时，微软公布的输入价格为每百万 Token 0.042 美元，输出 Token 不收费。由于价格会动态调整，实际部署时应以 Microsoft Foundry 当前列出的价格为准。这些数据来自微软公布的基准测试结果，不能替代针对团队自身开发任务开展的评估。

Microsoft-Decision-1 提供三种问题类型，非常适合用于 AI 控制平面：

• noul： 用于二元判断，例如“是否允许自动执行这条命令？”

• choice： 用于有限选项的路由，例如“本轮任务应该使用哪个模型档位？”

• score： 用于有序评分，例如“此次变更的风险有多严重？”

为什么不使用小型 LLM 分类器？

这同样是一种合理的架构选择。许多模型路由器都会让轻量级 LLM 将任务分类为简单、中等或困难。GitHub Agentic Workflows 的实验性模型路由功能，也会先对任务进行分类，再通过预先编译的路由表，对允许使用的模型与推理强度组合进行排序。

不过，对于开发者工具而言，专门的决策模型具有四项优势：

• 输出范围明确。 路由器需要的是标签和概率，而不是具有说服力的长篇文本。

• 延迟可预测。 在智能体工作流中，每一次串行调用控制平面都会增加额外成本。

• 置信度可直接用于策略判断。 如果最高概率低于 0.65，本地策略可以避免降级，保留当前模型，或要求用户手动选择。

• 便于组合治理能力。 一次结构化请求就可以同时评估模型档位、操作风险和是否需要人工审查。

Copilot 路由中的一个概念性 choice 请求

下面是一个简化的伪数据示例，并非仓库中的实际源代码，同时省略了部署和身份验证细节：

{
  "state": {
    "task": "Fix intermittent failures in the authentication integration tests,
    "estimatedContextTokens": 18000,
    "toolUseExpected": true,
    "workspaceScope": "multi-file",
    "latencyPreference": "balanced"
  },
  "questions": {
    "model_tier": {
      "type": "choice",
      "instructions": "Choose the least expensive tier likely to complete the task reliably in one pass.",
      "criteria": {
        "fast": "Simple explanation, formatting, lookup, or small deterministic edit",
        "balanced": "Normal coding, tests, debugging, or limited multi-file work",
        "strong": "Ambiguous architecture, security, difficult debugging, or broad multi-file reasoning"
      }
    }
  }
}

响应会指出所选档位，并为每个档位分配一个概率。随后，路由器会将这个抽象选项映射为当前 GitHub 账户确实有权使用的具体模型。

这一分工非常重要：决策模型不应假设用户拥有或能够访问某个特定模型。真正的依据应当是账户的模型目录。

3. decision-ghc-router 的应用场景与参考架构

这套架构包含两个宿主环境，但使用同一套决策模型。

3.1 GitHub Copilot CLI：将路由器集成到原生 /model 菜单

在公开的前身实现中，用户级扩展会向 GitHub Copilot CLI 原生的 /model 菜单添加一个路由器选项。用户可以选择路由器，也可以直接选择某个具体模型：

• 选择 Decision Router： 对每一轮新的用户交互进行路由。

• 选择具体模型： 跳过路由，恢复原生的固定模型行为。

• 继续执行工具调用： 保留本轮已选定的模型，不再重新分类。

• 明确指定模型： 以用户明确提出的模型要求为准。

CLI 路径通过一个监听在随机端口 127.0.0.1 上的代理，将路由器作为临时提供方暴露出来，同时保留 Copilot 的身份验证、会话、工具、权限和流式响应行为。GitHub 凭证应仅保存在内存中，并且只用于向 GitHub 发送 HTTPS 请求。本地代理使用独立的随机凭证。GitHub 凭证不得写入日志，也不得发送给决策 API。

这是我最重视的设计原则：

路由器改变的是模型的选择方式，而不是 Copilot 的工作方式。

3.2 VS Code 和 VS Code Insiders：接入聊天模型选择器

编辑器集成采用独立扩展。它会在 VS Code Chat 的模型选择器中注册 decision-router，并通过公开的 Language Model API，发现当前登录该编辑器的账户可以使用的 Copilot 模型。

这里的隐私边界是有意设计的：

• 决策模型接收明确提取出的任务内容，或者由用户输入、仅用于路由的摘要。

• 如果无法从编辑器上下文中可靠地提取任务，扩展就不应自动上传附件、源代码文件或完整对话。

• 被选中的 Copilot 模型仍会接收完整对话、工具定义和工作区上下文。

• VS Code 负责调用原生工具，而工具调用 ID 用于保持模型的一致性。

简而言之：决策阶段尽可能减少数据，执行阶段则尽可能提供完整上下文。

3.3 每轮新用户交互的七个步骤

1. 通过原生 Copilot CLI 或 VS Code Chat 接收任务。

2. 根据账户模型目录、价格、上下文能力和 API 兼容性发现候选模型。

3. 使用满足需求的最少任务摘要和有限选项构建路由状态。

4. 调用 Microsoft-Decision-1，获取各个选项的概率。

5. 根据置信度、成本、兼容性和手动覆盖设置执行本地策略。

6. 使用选定的模型、现有工具、权限、会话和流式响应机制进行原生执行。

7. 在后续工具调用过程中固定并追踪模型，同时记录决策和成本估算。

3.4 为什么不在每次工具调用后都重新路由？

假设模型运行测试、读取失败输出，然后修改代码。如果路由器在每次收到工具结果后都重新选择模型，就可能出现以下问题：

• 提示缓存的收益可能消失，从而增加总成本；

• 新模型可能以不同方式理解此前的工具调用；

• 调试过程会变得更难复现和审计。

因此，我保留了 jev-router 最有价值的设计思想之一：**在每轮新的用户交互开始时做出一次决策，然后在由此产生的整条工具调用链中固定该模型。**主对话和子智能体应分别固定各自的模型。

4. 主要技术与框架

根据公开前身项目中可以验证的机制，以及本文介绍的 Microsoft-Decision-1 演进方向，整个项目可以划分为以下几个层次。

Node.js 和 ESM 模块

核心路由器使用 Node.js 和 .mjs 模块处理以下工作：

• CLI 启动和参数转发；

• 模型目录与价格适配；

• 本地 HTTP 代理；

• 配置和环境变量；

• 决策 API 调用；

• 策略、错误处理和遥测。

公开的前身项目要求 Node.js 版本为 22.16 或更高版本，并使用微软的 npm 软件包源获取相关依赖。

GitHub Copilot CLI 扩展接口

CLI 集成依赖实验性的扩展接口，将路由器注册为原生模型选项。它会显式启用提供方端点接口，并从当前活动会话中获取模型目录、运行时推理端点和身份验证信息。

以下三条规则至关重要：

• 不要修改用户的全局默认模型。

• 不要自动授予 Shell 或其他工具的执行权限。

• 如果初始化失败，应明确报告错误，而不是假装路由成功。

本地回环代理

回环代理负责在保留原生 CLI 行为的同时适配路由器：

• 仅监听 127.0.0.1；

• 使用随机端口和随机本地凭证；

• 将路由器的选择映射到实际的 Copilot 执行模型；

• 保留流式响应、工具调用、会话和权限提示；

• 绝不额外创建一个隐藏的智能体循环。

VS Code 扩展 API

编辑器扩展通过以下接口发现当前可用的候选模型：

vscode.lm.selectChatModels({ vendor: "copilot" })

扩展以 VSIX 格式打包。CLI 和编辑器是彼此独立的宿主，可能使用不同的 GitHub 账户，并拥有不同的模型使用权限。因此，候选模型的发现必须根据宿主环境、当前会话和实际情况动态进行，而不能依赖硬编码的模型 ID 列表。

Microsoft Foundry 和决策 API

Microsoft-Decision-1 可以通过 Microsoft Foundry 部署，使用 GlobalStandard，或者在指定区域使用 DataZoneStandard。身份验证可以采用 Microsoft Entra ID（推荐）或 API 密钥。

在这套架构中，决策 API 只负责对选项进行评分：

• 输入： 最精简的任务状态、有限的候选选项和明确的评估标准。

• 输出： 选定的选项、各选项的概率以及用量信息。

• 不负责： GitHub 凭证、开发者工具、完整工作区访问权限或代码执行。

这种分离让决策平面和执行平面能够独立进行治理。

模型目录、价格与能力适配器

公开的前身项目会从当前登录的账户中发现模型，而不是将模型列表硬编码。在进行评分之前，路由器应排除以下候选项：

• 自动选择、隐藏、禁用或尚未配置的模型；

• 没有可用价格信息的模型；

• 输入上下文容量不足的模型；

• 与宿主环境所使用的 API 协议不兼容的模型；

• 受到管理员策略限制的模型。

成本估算可以用于模型排序和向用户提供反馈，但不等于最终账单。促销活动、缓存折扣、隐藏上下文、重试和后续工具调用轮次都会影响实际费用。最终计费仍以 GitHub Billing 为准。

5. 我从 jev-router 借鉴了什么，又做出了哪些改变

gargpratyush/jev-router 的价值并不只是“简单任务使用小模型”。它将路由机制融入开发者熟悉的 CLI，同时保留原生行为。

我保留的设计包括：

• 每轮新的用户交互只进行一次路由决策；

• 在原生模型选择器中提供专门的路由器选项；

• 用户选择具体模型后，暂停自动路由；

• 将 Fast、Balanced、Strong 和 Long 等抽象档位映射为宿主环境对应的模型；

• 在本轮后续工具调用过程中，继续使用本轮开始时选定的模型档位；

• 优先遵循用户明确提出的模型要求；

• 置信度较低时，不应贸然降级模型；

• 处理较长的对话时，必须考虑缓存和迁移成本；

• 提供解释信息，说明为什么选择某个模型档位。

decision-ghc-router 的演进版本以 Microsoft-Decision-1 取代外部的 JEV/System One 评分器，并重点强化了五个方面：

1. 将概率作为一等信号。 策略可以根据概率阈值决定是否接受结果，而不是盲目采纳模型给出的标签。

2. 候选选项来自真实模型目录。 Decision-1 只能从已经通过资格筛选的候选项中进行选择。

3. 最终决策由本地策略控制。 组织规则、兼容性要求和手动覆盖仍由确定性的逻辑处理。

4. 决策模型可以复用。 一次结构化调用还可以评估操作风险，以及是否需要人工审查。

5. 明确区分本地与云端的职责。 云端评分过程与凭证管理、实际执行相互隔离。

6. 典型应用场景

A. 快速解释与小型编辑

“解释这个正则表达式”“将这段笔记整理成表格”或“为现有函数添加一个空值测试”。

路由器通常可以选择 Fast 档位。目标并不是选择能力最弱的模型，而是选择最经济、且有可能通过单次执行可靠完成任务的模型。

B. 常规开发与调试

“修复失败的测试”“在不改变 API 的前提下重构这个模块”或“根据堆栈跟踪定位错误”。

这些任务需要阅读代码、使用工具并进行中等程度的推理，因此通常适合 Balanced 档位。

C. 安全、架构与大范围多文件推理

“检查这个 OAuth 回调是否存在状态混淆问题”“设计跨区域故障转移方案”或“找出多个服务之间的竞态条件”。

即使成本更高，路由器也应选择 Strong 档位。路由优化的目标是“在可靠完成任务的前提下尽可能经济”，而不是“永远选择更便宜的模型”。

D. 长上下文与大型代码仓库

如果某个候选模型无法容纳预计输入的上下文长度，就必须在评分之前将其排除。对于已经很长的对话，路由器还应避免贸然降级，因为缓存收益损失或上下文迁移所产生的成本，可能超过模型价格下降带来的节省。

E. 组织策略与风险控制

同一次决策 API 请求还可以包含额外的 noul 或 score 问题，例如：

• 这项任务是否涉及生产数据？

• 拟执行的命令是否具有破坏性？

• 这次变更的安全风险等级是多少？

• 是否应该将执行交由人工审核？

到了这一步，路由器就不再只是一个成本优化器，而是成为智能体的轻量级控制平面。

7. 我会在生产环境中保留的策略

评分之前先进行确定性筛选

账户使用权限、API 兼容性、上下文限制和管理员约束都属于客观事实，不应让决策模型猜测。

置信度低时，不要自动降级

如果最高概率低于经过校准的阈值，路由器可以：

• 保留当前模型；

• 将自动切换的最高档位限制为 Balanced；

• 请求用户手动选择；

• 将高风险任务交给 Strong 模型或人工审核。

阈值必须根据目标环境中的已标注任务进行校准，而不能直接照搬示例中的数值。

用户的明确意图优先于自动路由

如果用户说“使用 Strong 模型”，或者直接在选择器中选择了某个具体模型，路由器就应立即让出控制权。

绝不静默替换

如果凭证缺失、决策 API 超时、价格未知或上下文不足，系统都应明确报告当前状态。至于遇到问题时应该继续执行、停止执行，还是保留当前模型，必须由宿主环境或组织策略有意决定，不能临时猜测。

默认记录决策，而不是记录每一条提示词

有价值的遥测数据包括：

• 匿名化的会话 ID 和轮次 ID；

• 候选模型及其被排除的原因；

• 选定的档位、各选项的概率和策略覆盖记录；

• 输入、输出和单轮成本估算；

• 任务完成、重试和手动重新选择模型的结果。

默认情况下，应排除完整提示词、源代码和工具执行结果；如果确实需要记录，则必须遵循明确的数据保留和数据处理策略。

根据任务成功率评估路由器，而不是只看请求成本

更有意义的指标包括：

• 首次执行完成率；

• 任务总完成时间；

• 包含重试和工具调用轮次在内的总成本；

• 用户手动切换模型的频率；

• 低置信度决策和错误路由的比例；

• 安全与策略违规情况。

8. 为什么这一思路的意义不止于一个代码仓库

从开发者布道的角度来看，决策路由器不仅仅是一个节省 Token 的工具。它展示了智能体工程中一种更清晰的职责划分：

• 生成式模型负责理解、推理、编写代码和调用工具。

• 决策模型负责快速、结构化且基于概率的判断。

• 路由器和策略引擎负责将这些判断置于真实的账户权限、预算、兼容性和治理约束之中。

• 开发者工具宿主继续掌控身份、权限、上下文和执行过程。

未来的 AI 开发者工具不会再被绑定到某一个“默认的大模型”。它们将管理由多个模型组成的模型组合，这些模型在速度、成本、上下文容量和能力方面各有不同。真正的差异化优势，将不再仅仅取决于一个产品接入了哪个模型，而在于：

它能否在恰当的时机选择恰当的模型，以可解释、可治理的方式完成这一过程，同时不破坏开发者的使用体验？

这正是我为 GitHub Copilot CLI 和 VS Code 的 GitHub Copilot 扩展引入决策路由器的原因。

GitHub Copilot 继续负责执行。Microsoft-Decision-1 负责快速判断。本地路由器则将这一判断转化为可实际使用的工程决策。

参考资料

• decision-ghc-router

• jev-ghc-router

• gargpratyush/jev-router

• Microsoft-Decision-1：用于快速决策的模型

• 在 Microsoft Foundry 中部署和使用 Microsoft-Decision-1

• GitHub Agentic Workflows——模型路由

• GitHub Copilot 模型计费与定价