Agent Plugins 1.0 是一项开放、中立于供应商的标准，它将 AI 智能体的各项能力（技能、MCP 服务器、命令和规则）打包成一个可安装的插件，您只需构建一次，就能在不同工具中运行，而不必为每个工具重新构建。2026年8月，GitHub 宣布在 VS Code、Copilot CLI、Copilot 应用及其 SDK 中全面支持该标准，覆盖所有 Copilot 套餐。对企业主而言，最直接的意义是：您为团队定制 AI 工具所投入的时间和资金，不再被单一平台所绑架。

它究竟解决了什么问题？

过去两年里，AI 工具已经从一个聊天框演变为能够读取您的文件、调用您的系统并执行实际步骤的智能体。要为您的公司定制这些智能体，您需要给它们三样东西：说明您业务如何运作的书面指令、通过 MCP 服务器与内部系统的连接，以及防止它们越权的规则。

问题在于，每个工具都要求用自己的格式来提供这一切。您的团队为某个工具编写了定制内容，一年后公司决定换用更快或更便宜的工具，却发现全部成果都无法移植，必须重写。这不仅仅是技术上的麻烦，而是每次更换供应商都会重复发生的真实成本，也正是许多企业因担心白费力气而推迟认真定制的原因。

一个插件在实践中包含什么？

按照该标准制作的单个软件包形式简单、定义清晰，由以下部分组成：

  • 一个 plugin.json 清单文件，记录插件名称和版本号，正是它让更新和追踪成为可能。
  • 一个技能文件夹，存放书面指令，告诉智能体如何按照您希望的方式完成公司中的某项重复性任务。
  • 一个 mcp.json 文件，定义将智能体连接到您实际系统的 MCP 服务器：库存、客户数据库、计费。
  • 特定工具的扩展，放在单独的命名空间中，这样即使某个供应商加入了自己的功能，共享部分依然可以移植。

把共享部分与供应商特定部分分开，是这一设计中最聪明的地方：它既不妨碍任何供应商凭借自有功能形成差异，也不会在您日后改变主意时迫使您失去一切。

为什么企业主也应该关心，而不只是开发人员？

真正的区别在于治理。该标准以开放许可证公开开发，并由一个技术指导委员会监督，成员包括来自 Amazon、Microsoft、OpenAI、Cursor 和 Vercel 的代表。当彼此竞争的公司就同一种格式达成一致时，这表明该格式的生命力将超越单个产品周期，而不是某一方试图锁定自己客户的手段。

这一点很重要，因为如今采用 AI 的最大风险不是技术风险，而是合同风险。您今天选择的供应商可能会涨价、停止您所依赖的服务，或者质量发生变化。开放标准无法消除这些风险，但能降低您的退出成本，而低退出成本正是您手中最有力的谈判筹码。

这对沙特阿拉伯的企业意味着什么？

随着2026年被定为沙特王国的“人工智能年”，许多企业在经历多年的演示之后，进入了认真试验的阶段。我们反复看到的情形是：一家公司为团队购买了订阅，却没有做任何定制，最终得到的是一个通用助手，它对世界无所不知，对公司自己的系统却一无所知。真正的价值来自定制，而不是订阅。

有了可移植的标准，定制决策的风险大大降低。企业可以编写一个内部插件来说明自己的审批流程，把智能体连接到自己的计费或订单管理系统，并分发给整个团队，同时确信即使明年换用其他工具，这笔投资依然有效。

但请注意一个要点：软件包可以移植，并不意味着访问您的数据就变得合规。任何将智能体连接到您内部系统的插件，仍然受《个人数据保护法》（PDPL）约束，您必须准确界定智能体能读取和不能读取的内容，并将其记录在案。

本周即可开始的实用步骤

  • 盘点现有的定制内容。写下团队在指令、连接和规则方面实际构建了什么，并确定每个部分目前存放在哪里。
  • 从一项重复性任务开始。不要一次性全部转换；挑选一个明显耗时的日常流程，把它打包成一个插件。
  • 在分发之前设置权限。Business 和 Enterprise 套餐提供集中设置，可控制允许使用哪些插件以及来自哪些经批准的来源。请在使用范围扩大之前完成配置，而不是之后。
  • 记录哪些可以移植、哪些不能。共享部分可以在工具之间迁移；特定工具的扩展则未必。在以可移植性为基础作出承诺之前，先弄清它的边界。

总而言之，整个行业正从各种格式相互竞争的混乱局面走向一种共享格式，而正是在这个阶段，投资 AI 定制成为一项经过权衡的决策，而不是一场赌博。在 Origami，我们构建这类插件以及与客户实际系统的连接，并从一开始就进行设计，让所有权和灵活性留在客户手中，而不是供应商手中。

参考来源