AI 生态热点：GitHub 把 custom agent、skills 和 MCP 治理一起推到 Visual Studio 后，Windows 团队终于能把 IDE 接成执行面
按北京时间 2026 年 4 月 5 日 回看最近几天的 AI 开发生态更新，我最想单独拎出来的，是 Visual Studio 这轮 agent 能力开始成套了。
时间点很清楚：
- 2026-03-31
Microsoft 发布 Visual Studio March Update – Build Your Own Custom Agents - 2026-04-02
GitHub 发布 GitHub Copilot in Visual Studio March update
单看每条都像功能补充：
custom agentagent skillsfind_symbol- GitHub 管的
MCP allowlist - profiling、Perf Tips、NuGet 漏洞修复里的 Copilot 助手
拼起来看，味道就不一样了。
GitHub 和 Microsoft 正在把 Visual Studio 里的 Copilot，从“会聊天的 IDE 助手”往“能带着团队规则、代码结构、工具权限和诊断上下文一起干活的执行面”推。
这对 Windows 和 .NET 团队尤其重要。
因为这批团队过去最尴尬的地方，一直集中在三个断层：
- 终端 agent 很强，但离 Visual Studio 原生调试流太远
- Web 端 coding agent 能做 PR，却吃不到本地 IDE 的深诊断能力
- 聊天型 Copilot 在复杂仓库里经常只看得到文本，看不到真正的工程结构
这轮更新，开始补的是这三个断层。
1. 这几天到底补了什么
1) custom agent 终于不只是 GitHub.com 上的概念
Visual Studio March Update 里最关键的一条，是 custom agents 直接进入 IDE。
Microsoft 给出的路径非常明确：
- agent profile 用
.agent.md文件定义 - 放到仓库里的
.github/agents/ - agent 可以绑定提示词、工具、模型偏好和 MCP 连接
这件事的意义不在文件格式。
关键在于：
团队现在可以把“这类任务应该怎么做”固化成 repo 内可审阅的 agent 配置，不再需要每个人在聊天框里各写一套 prompt。
对平台团队来说，这相当于把 agent 行为的一部分拉回了版本管理。
2) skills 开始承担可复用任务颗粒度
GitHub 文档和 Microsoft 的更新说明都把 agent skills 放进了同一轮叙事里。
GitHub 官方文档已经把 skills 定义得很清楚：
- 它是 instructions、scripts、resources 的目录
- 可以放在
.github/skills或用户目录 - 命中场景时由 agent 按需加载
这一步特别关键。
因为 custom agent 负责的是“角色”和“默认行为”，skills 负责的是“某类任务的可复用能力包”。
这两个东西一起进 IDE，团队才有机会把 agent 从“一套总提示词”拆成：
- 角色配置
- 任务技能
- 仓库上下文
这已经很接近真正能运营的 agent 体系了。
3) find_symbol 让 agent 少靠猜，多靠代码结构
March Update 里另一个很硬的点，是 find_symbol。
Microsoft 的描述非常直白：agent 不再只是搜文本，它开始能拿到语言级 symbol 信息、引用位置、声明和作用域。
支持的语言里有：
- C++
- C#
- Razor
- TypeScript
这对 Visual Studio 用户是个很现实的改动。
因为很多 .NET 老仓库、桌面应用和多项目解决方案，真正难的是下面这些事：
- 找对符号
- 找全调用点
- 别在跨项目改动里漏一半
有了 find_symbol，agent 至少开始拥有“看结构”的能力，不再只能靠文件名和字符串匹配硬猜。
4) MCP 治理开始有组织级边界
这轮更新里我最在意的，是 Enterprise MCP governance。
Microsoft 明确写了：
- Visual Studio 里的 MCP server 使用会遵守 GitHub 上配置的 allowlist policy
- 组织管理员可以规定哪些 MCP server 被允许连接
- 未获批准的 server 会被拦住
这一步很关键，因为很多团队现在最大的顾虑集中在三件事：
- 谁能接
- 能接哪些 server
- 哪些 server 会处理敏感代码和数据
当 allowlist 进入组织级治理，MCP 才有机会从个人实验功能变成企业可接受的默认能力。
5) profiling、安全修复也被放进了 agent 工作面
这轮 Visual Studio 更新还顺手把几类很像“执行面工具”的能力一起推进了：
- 在 Test Explorer 里直接
Profile with Copilot - 调试时用 Perf Tips 和 Copilot 联动分析热点
- 在 Solution Explorer 里用 Copilot 辅助修复 NuGet 漏洞
这些功能单拆出来不稀奇。
放在一起看，信号是：
Visual Studio 不满足于让 agent 停留在写代码，它开始让 agent 接触诊断、性能和依赖安全这些真正会进交付流程的事情。
2. 为什么这轮更新对 Windows 团队特别重要
如果你主要在 VS Code、CLI 或浏览器里工作，这轮更新看上去只是 Visual Studio 补课。
对 Windows 和 .NET 团队，它更像补断点。
因为过去一段时间，agent 生态最活跃的地方主要在：
- 终端
- Web 端 coding agent
- 轻量编辑器
而 Visual Studio 团队最核心的工作流往往还绑着这些东西：
- solution 级项目结构
- 调试器
- profiler
- Test Explorer
- NuGet 和依赖图
只靠聊天框，很难把这些能力真的串起来。
这次 custom agent、skills、find_symbol、MCP allowlist 和诊断能力一起推进，带来的变化是：
- 团队规则可以落到仓库里的 agent/profile 文件
- 可复用操作可以落到 skills
- 结构化代码理解开始比文本检索更可信
- 外部工具接入开始有组织级审批边界
- agent 能碰到更接近交付的问题，而不只是代码片段
这就是我说的“把 IDE 接成执行面”。
它不只是更顺手。
它是在补 agent 真正进入 Windows 研发流前必须有的那层工程骨架。
3. 哪些团队现在就该跟
我觉得下面几类团队值得尽快试：
- 维护大型 C# / C++ solution 的团队
- 已经在仓库里沉淀规范、脚本和内部文档的团队
- 对 MCP 有兴趣，但必须先做组织级 allowlist 的团队
- 想把 profiling、调试、依赖修复和代码生成放进同一轮协作的团队
尤其是第二类。
如果你的团队已经有：
- repo 内规则
- checklist
- 诊断脚本
- 常见修复流程
那把它们拆成 custom agent + skills，会比继续把这些知识散落在 wiki 和群消息里稳得多。
4. 哪些团队不用急着全量切
也有一些场景，我不建议立刻 All in：
- 主要开发面不在 Visual Studio，团队语言栈又很分散
- 你们对 preview feature 的容忍度很低
- 组织里还没统一 GitHub Copilot、MCP 和外部工具权限策略
- 你们当前最需要的是大规模异步改仓，而不是 IDE 内联动诊断
这些团队先观望没问题。
因为这轮更新补的是“可运营的 IDE agent 基础设施”，不是“所有开发团队今天就必须迁移的唯一入口”。
5. 冷静一点看，这里面还有几条边界
1) custom agent 和 skills 有了，不代表平台差异消失了
GitHub 文档自己也提醒了，不同平台上的工具名和支持范围会有差异。
这意味着：
- 你在 GitHub.com 上能跑的 agent 配置
- 在 Visual Studio 里能不能原样跑
还是要单独验。
别把一份 .agent.md 当成全平台万能配置。
2) allowlist 解决的是“能不能接”，不是“接了以后怎么控数据”
组织级 MCP allowlist 很重要，但它解决的是准入边界。
它没有替你解决：
- 敏感数据最小化
- tool output 保留多久
- 哪些 prompt / context 该脱敏
这些治理还得自己补。
3) IDE 执行面越强，误操作半径也会更大
当 agent 同时拿到：
- repo 规则
- symbol 级导航
- 调试和 profiling 上下文
- MCP 工具
它的帮助会更强，误改的半径也会更大。
所以 rollout 最好还是分层，不要一上来就把所有工具都开满。
6. 我会怎么落地这一轮能力
如果是一个中型 .NET 团队，我会按这个顺序落：
- 先在一个低风险仓库里建
.github/agents/，做 1 到 2 个 custom agent - 把最稳定、最重复的流程先抽成
.github/skills/ - 只给 agent 开必要的 MCP server，并走组织级 allowlist
- 先把
find_symbol用在重命名、引用收敛和局部重构 - profiling、Perf Tips、NuGet 漏洞修复先在试点团队开
- 每两周复盘一次：哪些 agent/profile 被用、哪些 skills 真有复用价值、哪些工具权限过宽
回滚思路也很直接：
- 关掉高风险 MCP server
- 先撤掉用得少的 custom agent
- 保留 skills 和低风险 symbol 导航能力
这样退得比较平滑，不会把整套体验一起拉黑。
7. 如果你不在 Visual Studio 生态，更稳的第三方承接方案是什么
这里给一个我自己的工程判断。
如果你的团队：
- 语言栈更杂
- 日常开发更依赖终端和轻量编辑器
- 对异步多 agent 并行和跨仓库自动化更敏感
那更稳的第三方承接方案，通常还是：
VS Code或Cursor这类更快接入 agent 工作流的编辑器- 配合 repo 内 instructions / skills
- 再把重活交给
Copilot CLI、Codex、Claude Code这类终端 agent
它更适合：
- polyglot 团队
- 平台组
- 需要跨仓库批量自动化的团队
它不太适合：
- 研发主阵地还在 Visual Studio solution / debugger / profiler 里的团队
- 强依赖 C#、C++、Razor 和原生诊断流的团队
所以这轮更新最受益的，不是所有人。
它最像是 GitHub 和 Microsoft 在对一类长期被“终端 agent 热潮”压住的团队说：
IDE 里的 agent 也开始有组织边界和执行骨架了。
8. 这条生态更新最该记住什么
这轮变化最重要的地方，不在于 Visual Studio 里多了多少 AI 按钮。
真正值得记住的是这组组合：
- custom agent
- skills
find_symbol- GitHub 管理的 MCP allowlist
- profiling / debugging / security 辅助
这五块一旦开始协同，Visual Studio 里的 Copilot 就不再只是“问答入口”。
它开始更像一个能被团队治理、能吃仓库规则、能接外部工具、还能碰到真实诊断数据的执行工作面。
如果你们本来就在 Windows 和 .NET 栈里做 AI 辅助开发，这轮最值得先做的，是把下面三块先搭起来：
- agent profile
- skill 目录
- MCP 准入策略
先搭起来。