Visual Studio Copilot 九月更新公布，IDE 工作流有哪些调整

Visual Studio Copilot 的这次更新，重点不是再增加一个聊天按钮，而是把代码评审、模型选择和依赖修复分别接到 IDE 里原本就存在的工作节点。GitHub 在 2026 年 10 月 22 日发布的更新说明里，列出了三项变化：Git agent 可以探索 Pull Request，BYOM（Bring Your Own Model）迁移到 New Agent（Preview），NuGet Audit 警告可以从 Error List 直接触发 Agent 修复。

如果你准备在团队里试用，建议按“先评审、再模型、后依赖修复”的顺序推进。每一步都要先确认 MCP、登录和预览功能等前置条件，再让 Copilot 修改文件。

官方入口：https://visualstudio.microsoft.com/

更新公告：https://github.blog/changelog/2026-10-22-github-copilot-in-visual-studio-september-update-2/

这次更新实际改变了什么

可以把三项能力理解为三条不同的工作流：

这张表也是采用顺序的依据：PR 探索主要影响上下文获取，BYOM 影响模型入口，NuGet 修复则会触及依赖文件。三者不要一次性在所有项目里同时打开。

Pull Request 探索进入聊天后，代码评审怎么走

Git agent 的变化，解决的是“评审上下文散落在多个地方”的问题。GitHub 官方说明称，用户可以在 GitHub Copilot Chat 中选择 Git agent，再从 Git Repository 窗口附加一个 Pull Request；生成的摘要会带有可导航到评论和文件的链接。

1. 打开 Visual Studio 中的 GitHub Copilot Chat，确认可以选择 Git agent。
2. 在 Git Repository 窗口找到目标 Pull Request，把它作为当前聊天上下文附加进去。
3. 先要求 Copilot 按“变更目的、风险点、待确认文件”整理摘要，再逐条打开评论和文件。
4. 如果没有上下文结果，先检查 Git 提供商的 MCP server 是否已连接；公告明确支持 GitHub 和 Azure DevOps。

试用时不要一上来就让 Agent 改代码。先让它只做摘要和定位，确认它引用的是本次 PR 的文件与评论，再把修改限制在一个分支里。这样可以把“上下文没有接上”和“建议本身不可靠”区分开。

BYOM 迁移最容易漏掉哪一步

BYOM 仍然是预览能力，但这次的入口发生了明确变化：它要求使用新的 New Agent（Preview）运行。官方更新说明特别指出，原来的 Ask 和 Agent 模式不再支持 BYOM，升级后以前配置的 Ollama 模型需要重新添加。

支持的提供商包括 Microsoft Foundry、OpenAI、Anthropic 和 Ollama。它的好处是团队可以把模型部署选择留在自己的配置边界内；代价是模型入口、登录方式和权限检查不能再照搬旧的 Ask/Agent 操作习惯。

1. 先在一台非关键开发机上确认 New Agent（Preview）可用。
2. 逐一记录原 BYOM 提供商、模型名称和连接方式，不要把旧配置文件直接当作迁移成功的证据。
3. 如果使用 Ollama，升级后重新添加模型，再用一个只读任务确认 Agent 能返回结果。
4. 最后再把团队常用模型接入共享工作流，并明确哪些代码可以发送到对应部署。

这里的关键不是“能不能接上模型”，而是升级后旧入口是否仍然有效。把模型重新添加、只读试跑和权限确认放在修改任务之前，能减少把迁移问题误判成模型质量问题。

NuGet 漏洞修复会怎样进入 Error List

如果项目启用了 NuGet Audit，Error List 中的漏洞警告现在可以出现 fixer action。点击后会打开 GitHub Copilot Chat 的 Agent 模式，并通过 NuGet MCP server 请求 Copilot 处理易受影响的包。

这条路径的前置条件比普通代码解释更多：需要登录 GitHub Copilot，并在 Copilot Chat 的工具菜单里启用 NuGet MCP server。缺少其中任意一项，错误列表仍然可以显示警告，但不能把它顺利交给 Agent。

1. 先记录 Error List 中的包名、当前版本和项目文件位置。
2. 在 Copilot Chat 工具菜单中启用 NuGet MCP，并确认当前账号已登录 GitHub Copilot。
3. 使用 fixer action 生成修复建议，优先查看它准备修改的项目文件和依赖锁定关系。
4. 在分支中检查差异、运行现有测试，再决定是否提交升级。

Agent 的作用是缩短“从告警到候选修复”的路径，不等于自动批准依赖升级。尤其是传递依赖、目标框架和源兼容性，仍应由项目维护者确认。

和旧工作流相比，团队应该先改哪一处

最小试点可以只选一个仓库、一个评审人和一个非关键依赖升级任务。每次只启用一项能力，记录它节省的是上下文整理时间、配置切换时间，还是依赖排查时间。

采用前要记住的四个风险

• 预览边界：BYOM 仍是 Preview，团队流程不应把它当作不可变的长期接口。
• 入口变化：旧 Ask 和 Agent 模式不再支持 BYOM，升级后必须按 New Agent 重新整理操作说明。
• MCP 依赖：PR 探索和 NuGet 修复都依赖对应 MCP server，连接状态应写进试点清单。
• 修改责任：Copilot 可以给出摘要或修复建议，但 PR 差异、依赖变更和测试结果仍由开发者确认。

相关问题

Git agent 支持哪些 Git 提供商？

本次官方更新说明明确提到 GitHub 和 Azure DevOps，并要求连接对应的 Git 提供商 MCP servers。

BYOM 升级后为什么找不到旧的 Ollama 模型？

公告说明旧 Ask 和 Agent 模式不再支持 BYOM，之前配置的 Ollama 模型需要重新添加到新的 Agent 入口。

NuGet 警告出现后能不能直接让 Agent 改项目？

可以从 Error List 的 fixer action 发起，但先登录 GitHub Copilot、启用 NuGet MCP，并在分支中检查依赖差异和测试结果。

总的来说，这次更新把 Copilot 从“聊天里的代码建议”向“IDE 工作节点上的协作入口”推进了一步。最稳妥的顺序仍是先用 Git agent 整理 PR 上下文，再验证 BYOM 迁移，最后把 NuGet 修复接入依赖维护流程。