本地模型接入 Copilot Fusion 并不代表 GitHub Copilot 已经变成纯离线的 AI 编码 Agent。
GitHub 在 2026 年 10 月 28 日公布了一项实验预览功能，允许 Copilot Fusion 将符合条件的本地模型纳入智能路由范围，在本地模型和云端模型之间动态分配任务。官方同时明确，路由决策依然在云端完成。
Copilot Fusion 是 GitHub Copilot 提供的模型路由与任务协调机制。它会根据请求内容和可用模型条件，在不同模型之间做出选择，并将模型输出接入后续编码流程。这项机制解决的是任务交给哪个模型处理的问题，不代表整个编码工作流都运行在本地设备上。
模型运行在本地，与整个编码任务完全脱离网络，是两个截然不同的概念。前者已经得到官方确认，后者则需要结合具体的配置环境进行验证。对于使用 AI 辅助开发的程序员，评估这项功能时需要厘清三个问题，谁负责选择模型，哪个模型负责推理，以及工具执行时访问了哪些资源。只有把这三个环节拆开，才能准确判断断网后哪些流程能继续运行，哪些代码数据可能离开本地设备，以及引入本地模型是否真正降低了开发成本。
本地模型接入后，为什么离线 Agent 还没到来？
因为接口打通、模型被发现与参与自动路由属于三种不同的权限，且不同客户端的本地支持能力存在明显差异。
这次更新首先落地在 Copilot CLI。在 Windows、macOS 和 Linux 系统上，Copilot CLI 均支持配置本地模型。开发者需要自行准备模型文件和推理运行环境，通过本地的 OpenAI 兼容接口（OpenAI-compatible 服务）完成接入。配置完成后，还需要在设置中启用实验性本地路由，并在 Copilot Fusion 中选择 Standard 模式，符合条件的本地模型才有机会参与自动分配。
在实际配置中，本地服务能够连接，只代表网络接口打通。模型能够被 Copilot 发现，只代表它出现在配置文件或模型列表中。模型最终能否参与 Copilot Fusion 的自动路由，完全取决于产品入口、模型白名单资格（例如官方提及的 MAI Code 1.1 Flash 和 Qwen3.8 Flash Next）以及当前账号的功能权限。不能因为某个本地模型提供了兼容接口，就直接认定它会被 Fusion 自动调用。
Copilot 桌面端（Copilot app）的机制又有所不同。虽然它支持通过自带密钥（BYOK）连接并手动选择兼容的本地模型，但目前的智能路由仅支持由 Windows ML 托管的模型。在桌面端能够手动选中某个本地模型，不代表 Fusion 会在自动路由时选中它。
以下是两个客户端在本地模型支持上的具体差异对比。
| 评估维度 | Copilot CLI | Copilot app (桌面端) |
|---|---|---|
| 操作系统 支持 | Windows、macOS、Linux | 依赖桌面端具体系统版本与设置 |
| 本地模型接入方式 | 开发者自行部署模型与 OpenAI 兼容服务 | 支持通过 BYOK 直接连接兼容模型 |
| Fusion 自动路由条件 | 需开启实验性本地路由、选 Standard 模式且模型符合官方资格 | 目前智能路由仅支持由 Windows ML 托管的模型 |
| 能力边界 | 接口打通不等于自动路由 | 手动可选不等于自动路由 |
这项功能目前处于实验预览阶段。在投入实际开发前，建议逐一核对客户端版本、账户订阅等级、操作系统、所在地区以及官方文档中的最新支持列表。
模型装在电脑里，任务流是如何运转的？
一次完整的 AI 编码任务至少包含云端路由、模型推理和工具执行三个独立环节，本地模型只接管了推理环节。
在日常开发中，让 AI 修改一个日期格式化函数、补充单元测试并运行测试命令，前端界面通常只展示一个输入框，后台实际上在路由、推理和工具执行三个模块之间反复循环。
-
云端路由负责选择模型。 Copilot Fusion 会根据自身的评估机制，在符合条件的本地模型和云端模型之间做出权衡。此次更新开放的是将本地模型纳入备选池，并没有把路由器本身搬到本地电脑上。官方已经明确，路由决策依然在云端服务器完成。
-
模型推理负责生成代码和回答。 如果云端路由将请求分配给本地模型，代码生成计算就在本机硬件上完成。如果请求被分配给云端模型，计算就会在云端完成。本地推理仅界定了模型计算发生的位置，不能代表整场交互都在本地闭环。
-
工具执行负责真正修改项目。 读取本地文件、写入代码修改、拉起终端运行测试，都需要由具体的工具（Tool Execution）来落地。模型在文本层面提出运行测试的建议，与系统真正启动测试命令，是两个独立的动作。工具在执行时可能只读写本地文件，也可能去连接远程代码仓库、拉取第三方软件包或请求外部网络接口。
因此，一次 AI 编码任务的真实路径是，云端路由选择模型，本地或云端模型完成推理计算，最后由工具对项目执行实质操作。这也是评估本地 AI 编码工具时最容易产生混淆的地方。模型在哪里运行，只回答了推理位置。谁在选择模型，工具访问了什么，必须分别确认。
断网以后，编码任务会停在哪一步？
断网后任务能否继续，取决于调用方式是直连本地服务、客户端手动指定，还是依赖 Copilot Fusion 自动路由。
要弄清断网后的边界，需要将使用方式拆解来看。如果跳过客户端，直接向本地推理服务发送请求，可以验证本机服务在无外网环境下能否正常处理输入，但这只能证明底层的模型服务具备离线运行能力。如果在 Copilot 客户端中手动指定本地模型，则需要观察账号认证、会话状态管理和其他外围服务是否强制依赖网络。如果使用的是 Copilot Fusion 自动路由，云端路由就成了绕不开的关卡。官方已经确认，即便本地模型参与推理，也不会让 Fusion 会话变成完全离线状态。
在没有进行针对性断网实测前，有几个具体的工程表现需要留出求证空间，避免直接下定论。
-
断网瞬间已经发起的请求能否顺利跑完。
-
云端路由请求失败后，终端是否会返回清晰的错误码或触发降级策略。
-
当本地推理服务依然存活时，本地工具链能否继续执行未完成的步骤。
-
网络恢复后，中断的任务能否从断点处继续，还是必须重新发起。
这些表现都会受到客户端版本、配置参数、任务复杂度和工具依赖的直接影响。更稳妥的工程验证做法，是搭建一个包含虚构数据的隔离小项目，固定提示词，分别在以下三种场景下跑通流程。
-
外网正常连接，且本地推理服务开启。
-
外网正常连接，但手动关闭本地推理服务。
-
物理断开外网，但保持本地推理服务正常开启。
通过对比这三组实验的报错位置，就能精准定位网络依赖究竟卡在路由、推理还是工具执行环节。
使用本地模型能保证代码隐私和降低成本吗？
本地模型只能确保部分推理计算留在设备内，无法单方面保证整场会话的数据不上传，也无法直接等同于使用成本下降。
代码隐私的数据流边界
许多团队引入本地模型是为了满足数据合规与隐私保护，但隐私边界不能只看模型权重文件是否存放在本地硬盘里。一次完整的编码任务包含了提示词、项目上下文、代码文件内容、工具执行返回结果以及诊断日志。哪些字段会打包进云端路由请求，哪些内容纯粹由本地模型消化，哪些遥测信息会写入云端日志，都需要逐项排查。
目前能够确定的是，Copilot Fusion 的路由决策在云端完成。由于官方公告尚未完整披露每次路由请求的具体数据结构（Payload），技术团队既不能断言完整代码一定会被上传，也不能盲目声称云端只接收不含代码的纯元数据。此外，工具执行阶段（如安装依赖包、调用外部 API 测试、读写远程 Git 仓库）也会产生额外的数据外发。对于有严格保密要求的项目，在确认哪些输入发往云端、路由日志保留哪些信息、工具是否访问外部服务这三件事之前，不宜将本地模型直接当作绝对的隐私隔离方案。
算力与综合使用成本的核算
引入本地算力后，软件使用成本未必会直线下降。开发团队的综合成本至少包含三部分，Copilot 的基础订阅费用、云端模型的调用配额消耗，以及本地设备运行大模型所付出的硬件折旧、显存占用与环境维护精力。
如果一个任务由本地模型接管，它是否还会扣除 Copilot 的某种对话配额，取决于官方实际的计费规则。如果任务在多轮对话中途被动态切换回云端模型，云端调用的计费方式也需要核实。同时，本地模型的效率不能只看单次字符生成的速度，模型冷启动加载、长上下文预处理、工具调用耗时以及代码修改错误导致的返工，都会拉长完整任务的交付时间。
在没有同条件测试和账单记录支撑时，建议记录一次任务从发起至交付的全链路指标，包括首次响应耗时、代码修改准确率、单测通过率、模型切换次数、云端配额消耗量以及人工介入频次，以此评估真实的投入产出比。
如何用隔离环境与 ServBay 验证本地模型边界？
搭建一个不涉及真实业务代码的迷你项目，配合 ServBay 等本地开发环境管理工具，可以低成本复现并验证上述所有边界。
在动手验证前，需要注意工具链的定位。
以 ServBay 为例，它与本地模型工作流存在良好的互补性，可以作为本地服务和开发环境的集成演示平台，帮助开发者快速准备本地 OpenAI 兼容接口、模型运行环境或隔离的测试项目。
将 ServBay 作为AI 开发工具的底座更为准确，测试通过后，可以顺势整理出一份本地 Agent 数据流检查表，用来记录模型状态、路由响应、工具调用和网络报错。
具体的验证不需要动用真实的业务代码仓库。开发者可以新建一个只包含虚构数据的小项目，固定好 Copilot CLI 版本、本地模型（如 MAI Code 1.1 Flash 或 Qwen3.8 Flash Next）以及推理服务配置。接着，下达一个标准指令，让 AI 修改项目里的日期处理函数、补充单元测试并自动执行测试命令。
在测试过程中，依次切换前文提到的联网与断网状态，重点观察并记录五个节点，本地模型服务端是否收到请求日志、云端路由是否放行、工具能否正常读写本地文件、测试脚本是否被成功拉起，以及报错信息究竟卡在哪个阶段。测试时需注意区分本地服务关闭和外网断开，前者主要用来检验客户端对本地推理服务的容错机制，后者则是检验云端路由和外围工具的网络依赖。此外，测试全过程不要使用真实的 API 密钥、私有业务代码或生产环境数据，在公开测试日志和截图前，务必抹除账号令牌（Token）和本地绝对路径。
如何全面评估本地 AI 编码工具？
Copilot Fusion 此次更新，正式将本地模型纳入了智能路由的讨论范畴。它带来的技术变化非常明确，Copilot CLI 支持在主流操作系统上配置本地模型并接入兼容服务，Copilot 桌面端也支持部分本地模型的连接与选择。同时，技术边界依然清晰，路由决策留在云端，本地推理不会自动将编码会话转化为离线 Agent，通过 BYOK 发现模型也不代表该模型具备自动路由资格。
评估任何宣称支持本地模型的 AI 编码工具，不能只看模型权重有没有跑在本地电脑上。技术团队需要顺着任务链路，去追踪谁在背后选择模型，哪些步骤必须联网，工具在后台访问了哪些资源，以及配额与费用如何核算。把整条任务链在隔离环境中跑通一遍，本地推理、云端路由与工具执行之间的真实关系才会一目了然。