Visual Studio 轻松连接模型，但代理可靠性仍需测试
Visual Studio 18.10 Insiders 可以将本地和托管模型连接到 Agent 模式，但一次实测表明，端点可用并不意味着编码工作可靠。
Microsoft 已将自带模型（Bring Your Own Model，BYOM）加入 Visual Studio 18.10 Insiders 的全新 Agent 体验。开发者可以连接 Microsoft Foundry、OpenAI、Anthropic 或 Ollama，然后在 Visual Studio 的模型选择器中选择已添加的模型。这让提供商配置变得更容易，但并不能证明每个可选模型都能可靠地检查代码仓库、调用工具、编辑文件并从失败中恢复。
BYOM 是连接层，而不是兼容性证书。可靠性取决于确切的 Visual Studio 构建版本、端点、模型修订版、工具能力、项目类型和任务集合。连接成功几乎无法说明这个完整组合在真实代理工作中会如何运行。
这种谨慎并非假设。在一次独立的动手测试中，一个通过 Ollama 连接的本地 Qwen3:4b 模型回答了基本的项目问题，却在 25 分钟后仍未完成一个小型编码任务。Claude Sonnet 4.6 在几秒内完成了同一项编辑和构建。一次测试不能给任何一个模型家族排名；但它确实说明，连接成功和可靠的编码代理是不同的结果。
Visual Studio BYOM 实际连接了什么
Microsoft 的8 月 24 日 BYOM 公告将这一预览功能放在 Visual Studio 18.10 Insiders 和新版 Agent（预览版）中，后者使用由 GitHub Copilot SDK 驱动的工具链。它默认在 Community、Professional 和 Enterprise 预览版中启用。模型选择器可以添加 Microsoft Foundry、OpenAI、Anthropic 和 Ollama 提供商；无论开发者是否登录 GitHub，这一流程都可运行。
“自带模型”并不意味着把模型权重文件导入 Visual Studio。IDE 将其代理工具链连接到提供商或端点。本地模型可以在 Ollama 等软件通过兼容端点提供服务时参与其中，而托管提供商通常需要使用其自己的凭据。
当前预览版还取代了旧版 Ask 和 Agent 模式中早先的 BYOM 体验。Microsoft 表示，之前添加的模型必须重新添加。较早的 Visual Studio 17.14 模型选择指南（英文）最后更新于 2025 年，描述了不同的提供商列表以及不同的 Business 和 Enterprise 限制，不应将其视为 18.10 预览版的权威依据。
| 预览层面 | 当前来源支持的内容 | 仍需验证的内容 |
|---|---|---|
| Visual Studio 版本 | 搭载新版 Agent（预览版）的 18.10 Insiders | 确切构建编号，以及更新是否改变了提供商行为 |
| 提供商 | Microsoft Foundry、OpenAI、Anthropic 和 Ollama | 每个端点暴露的可用模型和能力 |
| 代理能力 | 模型可以出现在 Agent 模型选择器中 | 团队任务中的工具使用、上下文处理、编辑、测试和恢复能力 |
| 兼容性 | Visual Studio 会显示一些模型能力信息 | Microsoft 明确不会认证每一种模型与提供商组合 |
| 企业控制 | BYOM 存在于 Professional 和 Enterprise 预览版中 | 禁用策略和集中式模型管理仍在计划中，当前尚不可用 |
这里还存在实时文档不一致。公告称 OpenAI 和 Ollama 支持自定义 URL。Microsoft 的 Insiders 发行说明于 8 月 25 日更新，却表示这些提供商的自定义端点支持仍在开发中。同一份说明记录了一个变化：Insiders 1 中添加的 Ollama 模型，在后端变更后必须在 Insiders 2 中重新添加。
这一冲突是预览版风险，不是可以略过的细节。应记录确切的构建版本并测试端点路径，而不是笼统地向团队承诺“18.10 支持自定义 URL”。
一次本地与托管模型测试暴露了真正的边界
Visual Studio Magazine 的动手测试使用了一个原生 .NET 10 Blazor 应用。Visual Studio 从本地 Ollama 服务器发现了七个模型，并在选择器中标示能力差异。测试者选择 Qwen3:4b，因为 Visual Studio 识别出它支持工具。
本地模型大体上识别出了项目，尽管它错误陈述了应用结构的部分内容。在第二项任务中——为示例计数器添加重置按钮——它读取了目标文件并开始使用 Agent 工具，却被指令、文件内容和工具结果弄得混乱。测试者在约 25 分钟后停止了运行，此时编辑尚未完成。
随后，Claude Sonnet 4.6 完成了同一项修改，成功构建项目，并根据报告消耗了 0.9 个 Copilot 额度。这次比较只涉及一个模型修订版、一个小型项目、一项任务、一台本地机器和一次托管运行。它没有控制硬件、上下文构建、推理设置或重复运行的方差。因此，它只支持一个狭窄的结论：本地端点可以工作，而该模型配置未能完成那项代理任务。
这正是团队需要测量的差距。代理工作不是普通聊天。模型必须解释工具模式，将用户目标与文件和工具输出分开，选择下一步行动，发现错误，并以可验证的结果停止。一个能准确总结代码的模型，在工具链加入多轮状态和工具反馈后仍可能失败。
同样的原则也适用于硬件配置。一个能装入内存的本地模型，仍可能对于预期工作流过慢或不够可靠；Qwen 本地部署分析解释了为什么必须把权重、上下文、运行时状态和任务验收放在一起测量。
模型选择器暴露的是选择，而不是等价能力
这次动手结果让区别变得具体：Visual Studio 能发现本地模型并暴露 Agent 工具，但该配置在大约 25 分钟后仍未完成小型编辑。端点兼容性是真实的；代理可靠性却不会因此自动出现。
一次任务不能给本地和托管模型排名，而且报告没有控制硬件、上下文构建、推理设置或重复运行的方差。但它说明了，模型选择器是评估的起点，而不是每个列出的模型都能以相同可靠性使用相同工具的证据。
预览治理仍不完整
Microsoft 部分地将 BYOM 介绍为使用获批模型和私有端点的方式。这可能改善控制，但当前预览版不会自动证明每个字节的去向。团队应核实提供商日志、端点身份验证、代码仓库索引、遥测、机密存储，以及仍处于所选模型路径之外的任何服务。
Microsoft 表示，用于为 Professional 和 Enterprise 用户禁用 BYOM 的 ADMX 策略计划随 18.10 正式可用版本推出。集中式模型配置、细粒度上下文和工具控制、更智能的兼容性检测，以及更深入的 Foundry 集成也都是未来工作。在这些控制发布并得到验证之前，出现在 Enterprise SKU 中不应与集中治理混为一谈。
缺少管理控制很重要，因为只有在所选端点、模型和策略保持可用时，提供商选择才是持久的。GitHub Copilot 模型退役分析（中文）展示了该目录如何快速变化，而产品名称却保持稳定。
选择是功能；可靠性才是部署决策
Visual Studio BYOM 降低了把本地部署或其他提供商放到同一个 Agent 界面之后的摩擦。这对实验、成本控制、专业化和数据边界选择都有价值。它也把更多模型和端点验证责任转移给开发者或组织。
下一步要关注的证据不是选择器中显示的模型数量，而是 Microsoft 是否弥合自定义端点文档缺口、发布承诺的管理控制、改进能力检测，以及重复的、针对具体构建版本的测试是否显示所选模型能够完成团队的真实工作，而不需要不安全或昂贵的恢复。