Agent Plugins：Vercel/OpenAI/Microsoft 等联合推出 Agent 技能打包新标准

昨天我在 LinkedIn 上看到一篇帖子，介绍了一个打包 Agent Skills 和 MCP 服务器的新开放标准：Agent Plugins，由 Vercel、OpenAI、Microsoft、AWS、GitHub 和 Cursor 等厂商联合构建。

不瞒你说：一开始，我感到那种熟悉的胃部紧缩感。

其实，早在这之前我就已经感受到了第一波冲击——那是我读到 @lukeocodes 关于 MCP 向无状态转变的文章时。更早之前，我已经在 IRC-A（Internet Relay Chat for Agents）这个方向上探索了一个多月，而这个新标准出现时，再次触发了我的冒名顶替综合症。如果你也有过这种感觉，推荐你读一读 @sylwia-lask 的这篇文章。当我告诉她我当时的感受时，她给了我一些温暖的话，我一直记在心里。

我最初的想法是："怎么之前没人意识到这一点？"

然后一个更好的想法浮现了：也许人们现在开始看到了。也许我们中只是有些人更早一点注意到，agent 时代正在重蹈软件工程过去 20 年已经解决过的那些错误。

而这正是我想写这篇文章的原因：不是为了与 Agent Plugins 竞争，而是为了补充它。

Agent Plugins 解决了一个真实的问题：打包

这个新标准之所以重要，因为它直指一个非常具体的问题：可移植性。

如果每个 agent 客户端都要求作者以不同的方式重新组织相同的组件，整个生态就会变得重复且脆弱。为 Skills 和 MCP 服务器建立一种共享格式，才能为整个系统奠定一个干净的基础。这对构建者、客户端和整个生态都有益处。

但一旦 capabilities 被打包好，另一个问题就出现了。

问题不再是"我们如何交付这个 capability？"，而是"当一个 agent 发现并执行它时，我们如何管控接下来发生的事？"

这正是我一直纠结的层面。

困扰我整夜的问题

现在很多 multi-agent 系统仍然构建得像个紧耦合的图。我们硬编码流程、用 tool schemas 把 prompts 塞得过度复杂、给对话 agents 过多的权限，然后祈祷不要出什么岔子。

但生产系统不能靠祈祷来运行。

所以我一直在试图用 IRC-A 来回答这些问题：

• agent 如何在不把所有 API schema 都塞进 system prompt 的情况下发现正确的 capability？
• 我们如何用特定的参数组合在短时间内授权一次特定的执行？
• 我们如何对去中心化 agent 网络中发生的事进行审计和追踪？
• 我们如何确保 reasoning agent 永远不会直接接触数据库凭证？
• 我们如何隔离工具，使得 prompt injection 无法演变为横向移动？
• 我们如何在不重新部署整个编排器的情况下添加或移除 capabilities？

换句话说：Agent Plugins 标准化的是行李箱本身。IRC-A 则关注海关、登机牌，以及谁被允许打开货舱门。

IRC-A 架构概览

IRC-A 是我尝试将那些经过实战检验的老派软件工程思想引入 agent 时代的一次实践：Smalltalk 风格的消息传递、类 IRC 的逻辑通道、capability 池化、默认安全的 SDK 基类，以及严格的 reasoning 和执行分离。

从高层来看，架构是这样的：

Cognitive agents 是无状态的。 它们进行推理、委托和组合答案，但它们不拥有数据库驱动或长期凭证。

BFA Gateway 充当注册中心、治理层和语义海关。 它不携带业务负载；它注册身份、capabilities、通道，并签署短期授权。

Capabilities 以语义方式进行发现。 agent 不再把每个 tool schema 都塞进 prompt，而是向网关询问它需要什么，网关通过向量索引解析相关的 capabilities。

Logical channels 遮蔽了发现过程。 agent 甚至不应该看到其授权通道之外的 capabilities。

执行通过隔离的 MCP tool servers 进行。 只有执行层持有与核心数据库和企业 API 的物理连接。

授权使用短期的委托执行令牌。 网关生成短命的签名令牌；接收工具离线验证它们，拒绝任何超出范围的内容。

这正是我认为能够补充当前这一波浪潮的部分：更少的 prompt 膨胀、更少的耦合、更多的可审计性、更强的韧性，以及当问题出现时更小的爆炸半径。

我不想与 Vercel 竞争，我想与那个生态一起构建

作为一名阿根廷开发者，看到 Vercel 推动这个领域让我感到格外亲切。

Guillermo Rauch 也是阿根廷人。我不认识他，但如果我说我不希望这些信息最终能传到他耳中，那我就是在撒谎。不是因为我想说"我先做的"——那不重要。重要的是，越来越多的人开始看到同样的问题，这意味着时机终于成熟了。也因为如果再有一个来自南 GBA 的大规模解决方案，那将是非常棒的！

我相信 Agent Plugins 是可移植性方面的重要一步。我相信 IRC-A 可以是安全运行时治理的补充步骤。但 IRC-A 带来的最大价值是即插即用的 capability：新的 agents 和工具应该能够注册、被语义发现，并开始参与，而无需重新连接整个系统。我相信下一代的 agents 将同时需要：可移植的 capabilities 和受控的执行。

所以这就是我立下的旗帜。

我正在构建 SDK、框架、图表、白皮书，而现在来到了不舒服的部分：营销。挨家挨户。一条消息一条消息。在失业的状态下，一边做我的创业项目——这个解决方案就是为了解决在同一网络上连接 B2B agents 的问题而诞生的——一边拼命推进。

但我坚信这场对话必须进行。

如果你正在构建 agent 基础设施，我很希望听到你的反馈。如果你正在从事 MCP、agent 运行时、插件标准或安全执行边界方面的工作，我很乐意交流经验。如果这能引起 Agent Plugins 生态圈任何人的共鸣，那就更好了。