Visual Studio的自带模型接入更新，最需要关注的是迁移与能力边界：模型能返回文本，不等于原来的代理工作流仍可用。验收时应分别确认模型连接、代理模式和任务所需工具，再用同一项小任务比较升级前后。

这是对九月更新的补发解读，不是今天刚发布的新功能。线索来自Google News中的9月30日报道，事实以微软9月29日公告为准。Read in English。

变化发生在接入工作流，不只是模型菜单

微软说明，BYOM仍是预览功能；这次迁移要求使用新的Agent（Preview），旧Ask和Agent中的BYOM路径不再支持，已有Ollama模型需重新添加。公告也明确：并非每个模型都支持全部Agent Mode能力。

新的代理并非九月首次出现。微软的7月28日公告已介绍基于GitHub Copilot SDK的Agent（Preview）。因此，九月应理解为BYOM接入路径的迁移，不能把模型选择器有新入口，写成代理能力从无到有。

这一区别影响排错顺序。如果升级后旧配置失效，首先核对所选模式与注册路径是否还受支持，再检查连接信息。直接更换模型，可能暂时改变现象，却没有解释失败究竟发生在配置迁移、代理兼容还是任务依赖上。

把“可以用”拆成三项可观察结果

下面的三层划分是本文提出的验收方法，不是对Visual Studio内部架构的逆向结论。第一层是模型连接：发出一个小请求，检查响应，并核对界面可见的模型标识。标识与输出是验收记录的一部分，不能凭回答流畅就独立证明路由正确。第二层是代理任务：给出范围明确的代码修改，让代理按照预期发现上下文、提出变更并交回结果。第三层是工具与上下文：任务需要仓库讨论、依赖信息或其他外部内容时，确认相应输入实际可取得。

三项结果可以不同。第一项通过，只能支持“这次请求得到了回复”；它没有验证代理使用了哪些能力。第二项在本地小项目上通过，也没有证明外部系统的上下文已可访问。把三种观察写在一条“已接通”后面，会让下一位排错的人重新猜测测试覆盖了什么。

反过来，工具入口没有满足任务要求，也不足以说明模型不会写代码。为了区分这两种情况，可以把必要上下文直接作为一个小而完整的输入，先验证模型是否能理解，再单独验证工作流是否取得了原本缺失的信息。这是定位方法，不是建议把真实私有仓库内容随意发往其他服务。

一个能复用的迁移样例

可以新建一个不含业务数据的小项目，只保留一个整数求和函数和三项确定的测试：[]→0、[2,3]→5、[-3,1]→-2。任务说明写成“只修正求和函数，使这三项测试通过，不增加依赖”。示例的价值在于改动范围和结果容易检查，而不是让模型处理一道难题。

先要求代理解释预期行为，再让它提出最小改动，最后由项目自身的测试确认结果。分别保存改动差异、测试输出和代理实际引用的文件。如果它只是说“已经通过”，却没有可核对输出，就把结果记为未验证，而不是替它补上成功状态。

升级前后保持项目、任务文本和测试相同，逐次更改一个因素。先完成受支持模式与模型注册的迁移，再比较同一模型的行为；若同时更新IDE、更换模型和加入工具，最终成功也无法告诉你是哪一项改变起作用。这样的对照不能衡量普遍模型质量，但能让迁移排错有可追溯的起点。

本文没有运行这项Visual Studio验收，也没有把它写成产品实测。这里给出的是一个可由读者执行的任务规格，尚未提供对应项目或运行结果。具体代码语言、项目测试命令和断言方式，应使用团队已有约定；无需为了这个示例另接一种模型或安装额外工具。

四种现象，各自指向不同的下一步

表中的下一步都是诊断建议，不是对错误原因的自动判定。连接失败可能涉及多种配置；能力提示也可能只针对当前模型与当前任务。记录提示原文时去掉凭据与私人数据，保留模式名称、模型标识和发生阶段，通常比只写“Copilot坏了”更有用。

若两次测试的结果不一致，先问是否比较了同一个条件。一次用直接提供的文件片段，另一次依赖代理自行查找整个项目，两次上下文并不相同。一次要求解释，另一次要求修改并执行测试，也不是同一难度的任务。把这些差别写清楚，才能决定应该调查连接、上下文还是执行步骤。

模型选择与工具资格分别核对

九月公告同时说明：BYOM可在未登录GitHub的情况下使用，但其中的NuGet自动修复工作流另需GitHub Copilot登录与NuGet MCP。把前一句推广成所有附带工作流都无需登录，会漏掉功能自己的前提。相关事实见同一公告的NuGet章节。

实际意义是，迁移清单应按任务列依赖，而不是只列供应商。对于“解释一段代码”，任务可能不需要外部仓库信息；对于“依据某个PR的讨论修改实现”，缺少讨论就可能使回答建立在不完整前提上。测试前把所需输入写出来，测试后核对这些输入是否真的出现，不能仅凭最终回答流畅就推断证据完整。

同样，不应把选择Ollama推导为整个代理会话的每个组成部分都在本机运行。模型端点的位置，与IDE、代理、工具连接各自发生什么，是不同的问题。对数据流有具体要求时，应逐项核实实际配置；本次公告没有给出足以证明整套工作流完全离线的证据，本文也没有测试它。

个人试验可以从小项目开始；团队迁移则可以把相同验收规格交给不同机器运行，比较差异。本文不据此承诺某个模型更可靠、更便宜，或更适合某类代码库。

若你还要检查依赖下载链路的覆盖范围，可以继续读GitHub包防火墙的启用与实际覆盖。它讨论的是另一类工具，不是本文的BYOM接入步骤。

何时值得迁移，何时先保留验证环境

预览期间可以把试验放在独立的小项目中，保存当前版本、注册信息的非敏感部分及验收结果，避免把“我记得以前可以”作为唯一基线。这里的保存不是让你导出密钥；有用的是能够复述测试条件和观察结果，而不是把账户信息混进记录。

通过小项目也不是全量迁移的充分条件。下一步应挑选一个真实但范围有限、结果可检查的任务，继续核对实际差异与测试。一次成功说明这次配置完成了这次任务，不证明未来所有代理能力都已兼容。

来源、边界与补发日期

Google News线索对应Visual Studio Magazine，2026年9月30日；产品事实来自微软9月29日更新说明与7月28日代理说明，均早于原计划时段。两幅图、分层验收方法、现象表和任务规格为本文原创分析，不使用报道配图或长段引文。

未执行Visual Studio、Ollama或MCP集成测试，未测量延迟、费用与任务成功率。文章保留2026年10月23日07:00（北京时间）日期，实际于2026年10月25日补发。