上篇说的“统一下发插件”,现在可以先回答一半了

上篇文章发出去之后，涨了 3 个粉丝。

数字不大，但对一个刚开始认真跑的公众号来说，够我开心一小会儿。更重要的是，它说明这个方向有人愿意看：不是单纯追新模型，而是看 AI 工具真的进工作流以后，会把哪些权限、成本和责任问题带出来。

所以今天不写长文，先兑现上篇埋下的一个小坑。

我当时说要看：

现在可以先回答一半了。

GitHub 6 月 5 日的更新，把 enterprise-managed plugins 扩到了 VS Code public preview。

它的核心不是很花哨：企业管理员把配置放到 .github-private/.github/copilot/settings.json，然后 VS Code 和 Copilot CLI 会自动拉取并应用。管理员可以指定插件市场，也可以指定用户登录 VS Code 或 Copilot CLI 时自动安装哪些插件。

这一步看起来像普通管理功能。

但放到 Agent 语境里，它意义很大。

以前的风险是：每个开发者自己找插件、自己接 MCP、自己配工具。A 同学接了 Jira，B 同学接了数据库，C 同学接了一个没人审过的内部脚本。短期很自由，长期就会变成一堆看不见的口子。

统一下发，至少把“口子在哪里”这件事从个人电脑拉回了企业配置。

这就是 Agent 进企业的第一道门。

不是模型够不够聪明。

是企业能不能说清楚：谁被允许装什么，默认启用什么，从哪里装，出了事去哪查。

真正麻烦的地方在后面。

VS Code 的企业 AI 设置文档里，已经把几类更硬的东西摆出来了：插件是否启用、插件 allowlist、额外 marketplace、严格 marketplace、MCP server 来源、私有 MCP registry、工具审批、terminal auto-approval、Agent sandbox、网络域名拦截。

这串词读起来很冷。

但翻译成人话就是：

这才是重点。

统一下发插件，只解决“大家从哪里拿工具”。还没完全解决“这些工具能碰什么、做到哪一步、谁来审批、出了事怎么追”。

我现在更确定一件事：企业里的 Agent 治理，不会只靠“装一个 Copilot”解决。

它会变成一张配置网。

一边是 GitHub / Copilot 的企业插件标准，把插件和市场拉进统一基线。

一边是 VS Code 的企业策略，把 MCP、工具审批、沙箱、网络访问这些执行层风险管起来。

中间还会有很多现实摩擦。比如社区里已经有人反馈过，插件安装和 MCP server runtime 配置之间可能存在衔接问题：插件文件在，但 MCP server 没有自动进入运行时配置，最后工具不可用。这个不一定代表企业托管插件本身不行，但它提醒我们：Agent 工具链不是“装上就完事”，它有安装、注册、启动、授权、审批、审计一整条链。

这条链里任何一环断了，体验就会变成：

或者更糟：

如果你是安全、平台工程、DevOps 或工程效率负责人，这事值得现在就看。

别等团队里已经散落一堆个人 MCP 配置，再回头补治理。那时候你要管的不是一个功能，而是一堆已经习惯了自由接工具的人。

如果你是做 AI 工具、MCP server、开发者平台的创业团队，也要看。

未来企业客户不会只问“你能接 Copilot 吗”。他们会问：能不能被统一下发？能不能被 allowlist？能不能关掉？能不能审计？能不能按工具粒度控制权限？

答不上来，就很难进主流程。

上篇我说，MCP server 列表越长，刹车系统越贵。

今天可以补一句：

Agent 真正进企业，不是从“会装更多插件”开始的。

是从“有人能统一装，也有人能统一关”开始的。