夜雨聆风点击蓝字
“摘要： MCP 让 Agent 连接工具，ACP 让 Agent 连接 IDE，Agent Plugins 则让能力可以被打包和迁移。三个容易混淆的概念，正在共同拼出 AI 编程工具的新基础设施。
如果你同时用过几款 AI 编程工具，大概率见过这样的场面：
同一个数据库工具，要在不同客户端里配置几遍；同一套团队规范，要分别改写成不同 Agent 能理解的格式；换一个编辑器，原来的自动化流程可能就要重新搭建；换一个 Agent，又得重新授权、重新装插件、重新解释项目背景。
模型越来越强，开发体验却仍然像早年的手机充电接口——每家都有自己的插头。
2026 年 8 月，一项看似不算轰动的更新，正在改变这件事。
GitHub 宣布，Agent Plugins 1.0 已在 VS Code、Copilot CLI、GitHub Copilot SDK 和 Copilot App 中正式可用。一份插件，可以同时携带 Agent Skills 和 MCP Server 配置，被多个兼容客户端识别和加载。
与此同时，JetBrains 正在通过 ACP（Agent Client Protocol），让不同编程 Agent 接入同一个 IDE；而已经被开发者广泛讨论的 MCP（Model Context Protocol），则继续负责把 Agent 与数据库、搜索、文件、设计工具和业务系统连接起来。
这三个名字经常出现在同一篇新闻里，也最容易被混为一谈。
但它们并不是竞争关系，更不是三选一。
MCP、ACP 和 Agent Plugins，分别在解决 AI 编程生态中的三个不同问题：工具怎么接、Agent 怎么换、能力怎么带走。
真正的瓶颈，已经不只是模型能力
过去两年，AI 编程工具的主要卖点几乎都围绕模型展开：上下文窗口更长、生成速度更快、推理能力更强、修复 Bug 的成功率更高。
但当 Agent 真正进入日常开发，团队很快会发现，模型只是系统的一部分。
一个可用的编程 Agent，至少还需要：
读取仓库、文档、数据库和监控系统； 在 IDE 中展示计划、修改文件和请求权限； 理解团队的编码规范、发布流程与故障预案； 安装工具、保存配置并在不同项目间复用； 接受企业侧的审计、授权和风险控制。
问题也随之发生变化。
以前大家问的是：“哪个模型更聪明？”
现在更现实的问题是：
“我能不能在不重做全部集成的情况下，更换模型、更换 Agent，甚至更换 IDE？
如果答案是否定的，那么每一次工具升级，都会带来一轮新的迁移成本。
协议的价值，就出现在这里。
三个概念，一次讲清
先记住最简洁的版本：
“MCP：让 Agent 找到并使用外部能力。
ACP：让编辑器能够接入和更换编程 Agent。
Agent Plugins：把可复用能力装进一个标准软件包。
它们对应的，其实是三种不同的“连接”。
MCP：连接 Agent 与外部世界
MCP 的全称是 Model Context Protocol。
它定义了一种开放方式，让 AI 应用连接外部数据、工具和工作流。例如：
读取本地文件或代码仓库； 查询数据库和内部知识库； 调用搜索、计算、设计或部署工具； 访问日历、项目管理系统和业务 API。
从架构上看，MCP 关心的是：Agent 可以使用哪些外部能力，以及如何发现和调用这些能力。
它不负责决定你使用哪个 IDE，也不负责把某个完整插件发布到多个客户端。
换句话说，MCP 更像一套标准化的“工具插座”。
ACP：连接编辑器与编程 Agent
ACP 的全称是 Agent Client Protocol，由 JetBrains 与 Zed 推动。
它要解决的是另一个问题：过去，每一个编辑器和每一个编程 Agent 之间，都需要单独开发集成。
假设市场上有 5 个编辑器、8 个 Agent，理论上可能形成大量两两适配关系。编辑器要理解不同 Agent 的接口，Agent 也要适配不同编辑器的交互方式。
ACP 在两者之间增加了一份共同契约。
在本地场景中，编辑器可以启动 Agent 子进程，通过基于标准输入输出的 JSON-RPC 通信；计划、进度、文件操作、权限请求和 Diff 等结果，再以编辑器能够理解的方式返回。
因此，ACP 常被称为编程 Agent 领域的“LSP 时刻”。
LSP 让编辑器不必为每种编程语言重复开发语言服务；ACP 想做的，则是让编辑器不必为每个 Agent 重写一套接入层。
Agent Plugins：连接能力与分发
即使工具能通过 MCP 调用、Agent 能通过 ACP 接入 IDE，还有一个问题没有解决：
团队积累下来的能力，怎样被完整地交付给别人？
Agent Plugins 1.0 提供的是一种开放、厂商中立的可移植软件包格式。
一个标准插件目录可以包含：
my-plugin/
├── plugin.json # 插件身份、版本与元数据
├── skills/ # Agent 的领域知识与操作流程
│ └── deploy/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json # MCP Server 的连接配置
└── com.example.client/ # 特定客户端的扩展能力
这里最关键的，不是多了一个配置文件，而是确立了一个共同的“最小可移植层”。
插件作者可以把通用部分放在标准目录中；某个客户端独有的命令、Hook 或界面能力，则放入反向域名命名空间。兼容客户端读取自己支持的部分，忽略不认识的扩展。
于是，同一份能力不再需要为每个 Agent 客户端重新打包。
三者放在一起，实际会怎样工作？
假设公司想做一个“线上故障处理 Agent”。
它需要查看代码仓库、查询监控指标、读取值班手册，必要时创建修复分支，并把每一步操作展示给开发者确认。
完整链路可能是这样的：
第一步：通过 ACP 接入 IDE。
开发者仍然待在熟悉的编辑器里。IDE 负责展示 Agent 的计划、进度、文件修改和授权请求。团队以后更换 Agent，不必同时更换整个开发界面。
第二步：通过 MCP 使用工具。
Agent 调用代码仓库、可观测平台和内部知识库。每个外部系统不再为每种 Agent 单独开发连接方式。
第三步：通过 Agent Plugins 交付能力。
插件包中携带故障排查 Skill、脚本、参考文档和 MCP 配置。开发者安装一次，兼容客户端即可发现其中的通用组件。
这时，模型仍然重要，但模型不再等于整个产品。
真正可复用的是一整套组合：
“模型推理能力 × Agent 执行框架 × 工具连接 × 团队知识 × 客户端体验
协议把这些部分的边界切开，允许它们独立演进。
为什么说这是 AI 编程工具的“USB-C 时刻”？
真正改变行业的标准，往往并不直接创造新能力，而是降低已有能力的组合成本。
USB-C 没有发明存储、显示器或电源，但它让大量设备可以围绕同一个接口协作。AI Agent 协议栈正在发生类似变化。
第一，Agent 的更换成本会下降
当 IDE 与 Agent 之间存在统一接口，开发者选择 Agent 时，不必把编辑器、审查习惯和项目配置一起更换。
未来团队可能根据任务路由 Agent：一个擅长大型重构，一个擅长前端还原，一个负责安全审查，另一个运行在企业内网。
选择的单位，将从“某个模型”扩大为“模型加执行框架”。
第二，团队知识开始成为可迁移资产
过去，很多所谓的 Agent 最佳实践，只存在于某个人的提示词、某个客户端的规则文件，或者一段无人敢动的脚本中。
当 Skill、脚本、参考资料和工具配置进入可识别的目录结构，团队知识才真正具备版本控制、评审、复用和分发的条件。
这可能比单次生成更快的代码更有长期价值。
第三，企业治理有了更清晰的对象
过去企业往往只能粗粒度地决定“允许不允许某个 AI 工具”。
插件化之后，治理对象可以继续细化：允许哪些插件、连接哪些 MCP Server、执行哪些命令、访问哪些目录、由谁发布和审核。
AI 治理因此可能从“管账号”，转向“管能力包与权限边界”。
但标准化，不等于自动安全
这是理解 Agent Plugins 1.0 时最需要保持清醒的地方。
标准格式解决的是兼容性，不会天然消除供应链风险。
Agent Plugins 规范要求插件内的路径不能逃逸出插件根目录，也明确要求插件不得把凭据写入公开的环境变量配置或 HTTP Header 配置中。这些约束能够减少一部分明显风险。
但规范同时指出：路径约束并不等于对插件子进程进行沙箱隔离。
一个插件如果携带可执行脚本或 MCP Server，最终能访问什么，仍取决于客户端的权限模型、操作系统隔离、用户授权和企业策略。
因此，团队不能因为看到“符合 1.0 规范”，就直接把插件视为可信软件。
至少还应检查：
插件来自哪个仓库和发布者； 安装时会启动哪些本地进程； MCP Server 会连接哪些远端地址； 脚本能够读取和修改哪些目录； 凭据由谁保管，权限能否最小化； 更新是否可追踪、可回滚、可审计。
未来 Agent 插件市场真正的竞争壁垒，可能不是“插件数量”，而是可信发布、签名验证、权限声明和隔离执行。
开发者现在可以做什么？
如果你是个人开发者，不必立刻追逐所有新协议。可以先把自己的 Agent 配置分成三类：
哪些是工具连接，例如数据库、浏览器、Git 和设计平台； 哪些是可复用知识，例如编码规范、测试流程和发布手册； 哪些是特定客户端能力，例如专属命令、Hook 和界面操作。
这一步能帮助你判断，哪些能力应该迁移到 MCP、Skill 或插件包中。
如果你是插件或工具作者，现在值得优先考虑：
能否把通用能力放进标准的 skills/与mcp.json；客户端专属功能能否收敛到独立命名空间； 安装失败、鉴权失败和单个 MCP Server 失效时，其他能力能否继续工作； 是否提供清晰的权限、网络连接和凭据说明。
如果你负责企业研发平台，则应该开始建立插件准入机制，而不是等开发者大规模安装后再补治理：
维护内部允许的插件与 MCP Server 清单； 对插件版本和来源做锁定； 默认采用最小权限； 记录 Agent 的工具调用与关键修改； 为敏感操作保留人工确认。
结语
AI 编程的上半场，大家争论的是谁的模型更强。
下半场，决定体验的可能是另一组更朴素的问题：能力能不能带走、工具能不能复用、Agent 能不能替换、权限能不能管住。
协议并不性感，也很少像新模型一样制造刷屏时刻。
但一个生态真正开始繁荣，往往不是因为又多了一座孤岛，而是因为岛屿之间终于出现了桥。
MCP、ACP 与 Agent Plugins 还远未解决所有问题，Agent Plugins 1.0 的规范状态也仍在继续演进。可它们已经给出了一个足够清晰的方向：
“未来的 AI 编程能力，不应该被锁死在某个模型、某个编辑器或某个客户端里。
当接口趋于统一，开发者真正拥有的，就不再只是一个 AI 工具账号，而是一套可以组合、迁移和持续积累的工程能力。
