Agent Plugins 1.0 详解：跨 AI 智能体的技能与 MCP 服务器的便携标准

简介

GPT-5 于 2025 年 8 月 7 日发布一年后，AI 智能体生态系统中一项新的互操作性工作正在成形。

AIBase 于 2026 年 8 月 7 日报道，Agent Plugins 1.0 已作为可复用智能体组件的可移植打包标准发布。

目标很明确：开发者不应为每个智能体客户端分别重建相同的技能或 MCP 集成。

如今，许多 AI 客户端支持类似的构建模块，但组织方式各不相同。在一个环境中可用的插件，可能需要重新调整其目录结构、清单文件、MCP 配置或客户端特定的元数据，才能被另一个环境加载。

Agent Plugins 试图定义一个小的公共层。

一个可移植的插件可以打包：

• 智能体技能（Agent Skills）
• MCP 服务器
• 基本插件元数据
• 可选的客户端特定扩展

兼容的客户端可以在可预测的位置发现这些组件。

该标准有意不试图定义所有内容。

安装、市场、分发、权限、认证、用户体验以及客户端特定功能仍由各客户端自行掌控。

这个边界很重要。Agent Plugins 不是一个让所有智能体行为一致的通用运行时。它只是针对现实中可移植的部分定义的一种共享打包格式。

还有一个重要的治理细节可能被头条新闻所掩盖。

尽管 OpenAI 参与了这个项目并在 ChatGPT 和 Codex 中支持插件，但 Agent Plugins 被其官方项目定位为开放、厂商中立、社区治理的规范。其初始核心维护者团队包括与 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 相关的贡献者。

问题始于碎片化。

AI 智能体客户端越来越普遍地支持相同的通用扩展概念：

• 可复用的指令
• 技能
• MCP 工具
• 钩子（Hooks）
• 命令
• 应用
• 智能体定义
• 客户端特定配置

但打包格式并不总是可以互换的。

开发者可能创建了一个有用的能力——例如部署工作流、数据库检查器、文档助手或分析工具——然后发现每个客户端期望的目录结构都略有不同。

底层能力可能是相同的。

但打包方式不同。

这就产生了多种形式的重复工作：

1. 将同一技能复制到多个客户端特定的目录中。
2. 将 MCP 配置改写为不同的模式。
3. 维护多个清单文件。
4. 保持多个插件包同步。
5. 编写不同的安装流程文档。
6. 在不同环境中反复测试同一组件。

Agent Plugins 定义了一个共同的互操作性底线，使可复用的核心可以存在于一个可预测的结构中。

简化后的思路如下：

一个可复用的插件包
↓
共享的可移植组件
↓
技能 +

MCP 服务器
↓
多个兼容的智能体客户端

客户端仍然决定插件如何安装、展示、授权和执行。

Agent 插件 1.0 已发布，但规范仍标记为“工作草案”

官方项目目前将 Agent 插件规范 1.0.0 标识为已发布版本。

同时，规范性规范页面将其状态标注为：

工作草案

这两个事实并不矛盾。

版本 1.0.0 定义了当前可移植的契约及其规范模式。

“工作草案”标签表示该项目仍在积极开发和治理中，而不是一个冻结的、不会再有演进的标准机构规范。

开发者今天就可以基于 1.0.0 版本进行开发。

他们仍然应该认真对待版本声明和模式兼容性，因为未来的规范版本可能会引入新的契约。

可移植插件结构

最大的实际好处是可预测性。

可移植插件是一个目录。

它至少包含：

plugin.json

它还可以包含技能、MCP 配置和客户端特定的扩展。

一个代表性的包结构如下：

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
└── hooks/

核心可移植位置是固定的。

1.0 版本精确地定义了两种可移植组件类型：

1. 智能体技能
2. MCP 服务器

其他概念——如命令、钩子、自定义智能体、规则或 LSP 集成——仍然可以存在，但它们不属于可移植 v1 核心的一部分，除非客户端将它们实现为扩展。

plugin.json：必需的清单文件

每个符合规范的 Agent 插件必须包含根级别的：

plugin.json

清单文件标识插件并声明其所针对的规范版本。

一个最小示例是：

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "research-tools"
}

两个必需字段是：

v1 清单还可以包含元数据，例如：

version
description
author
homepage
repository
license
keywords
extensions

该模式刻意保持封闭。

客户端特定的元数据不应作为任意顶层字段添加。

相反，特定于供应商的数据应放在：

"extensions": {
"com.example.client": {
"setting": true
}
}

这可以防止每个客户端静默地向共享清单中添加不兼容的字段。

插件名称遵循可预测的格式

v1 规范将插件名称限制为较小的可移植字符集。

名称可以包含：

小写字母
数字
连字符
句点

示例：

research-tools
acme.analytics
deploy3

名称不能以标点符号开头或结尾，不能包含大写字母，也不能使用重复的 -- 或 ..。

目标并非追求风格化。

可预测的命名可以减少解析歧义，并使包更容易在不同客户端和市场中建立索引。

skills/：可复用的代理技能

技能位于固定的：

skills/

目录下。

每个包含 SKILL.md 文件的直接子目录被视为一个技能。

示例：

skills/
└── deploy/
├── SKILL.md
├── scripts/
│   └── rollback.sh
└── references/
└── runbook.md

代理插件并未重新定义技能的工作方式。

相反，它将这一格式委托给独立的 代理技能 规范。

这种分离保持了职责的清晰：

代理技能
→ 定义技能本身

代理插件
→ 定义技能在可移植插件中的存放位置

兼容的客户端无需插件作者为该客户端编写新的发现规则即可发现技能。

如果某个技能无效，规范规定客户端应跳过该技能并继续加载其他有效组件，而不必拒绝整个包。

这种故障隔离是设计中的有意安排。

mcp.json：可移植的 MCP 服务器配置

第二种可移植组件类型是 MCP。

代理插件并未取代 模型上下文协议。

MCP 继续定义客户端与服务器之间的通信方式。

代理插件标准化了用于将 MCP 连接与插件打包的配置文件。

该文件始终位于插件根目录下的：

mcp.json

一个简化的示例如下：

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"local-tools": {
"type": "stdio",
"command": "./bin/server"
},
"remote-tools": {
"type": "streamable-http",
"url": "https://example.com/mcp"
}
}
}

MCP 架构版本必须与 plugin.json 中声明的代理插件版本匹配。

如果版本不匹配，MCP 配置可能会被拒绝，而其他独立有效的组件将继续加载。

支持的 MCP 传输方式

代理插件 v1 支持三种 MCP 传输类型：

通过代理插件支持 MCP 的客户端必须至少支持以下一种：

stdio
streamable-http

建议同时支持两者。

传统 SSE 为可选支持。

官方兼容客户端页面目前列出了多个主流客户端的支持情况。

支持情况可能发生变化，因此开发者应查看实时兼容性页面以确认最新信息。

而不是假设每个客户端都实现每种传输方式。

${PLUGIN_ROOT} 和 ${PLUGIN_DATA}

可移植的本地 MCP 进程需要一种可靠的方式来引用文件。

Agent 插件定义了两个由客户端提供的变量：

${PLUGIN_ROOT}
${PLUGIN_DATA}

PLUGIN_ROOT 标识已安装的插件目录。

PLUGIN_DATA 标识该插件可写的、由客户端管理的持久数据。

例如：

{
"type": "stdio",
"command": "./bin/validator",
"args": ["--data", "${PLUGIN_DATA}/validator"],
"env": {
"CONFIG": "${PLUGIN_ROOT}/config.json"
},
"cwd": "${PLUGIN_ROOT}"
}

这种区分解决了一个常见的打包问题。

插件代码和捆绑的资源可能会在更新时被替换。

持久的运行时数据不一定需要存放在那个可替换的包目录中。

因此，客户端拥有一个专用的数据位置。

包隔离是标准的一部分

可移植性还要求可预测的安全边界。

插件包提供的文件必须解析在插件根目录之内。

插件相对路径应以：

./

开头，并在文件系统解析后保持在包内。

例如：

./bin/server

是一个有效的插件相对可执行文件。

尝试通过：

../

逃逸的路径不是有效的可移植包路径。

该规范还要求客户端考虑诸如以下文件系统机制：

• 符号链接
• 联接点
• 重解析点

打包的路径不得逃逸解析后的插件根目录。

这可以防止插件包声称机器上其他位置的任意文件是其可移植包的一部分。

然而，这并不是一个完整的沙箱。

该规范明确区分了包隔离和运行时进程隔离。

启动的 MCP 服务器可能仍然需要额外的操作系统、容器、客户端或工作区级别的安全控制。

Agent 插件不定义可移植的机密信息

另一个有用的安全选择是标准拒绝做什么。

Agent 插件 v1 不定义通用的凭证格式。

插件不应将机密信息嵌入到：

• MCP headers
• 环境变量值
• 可移植包元数据中

认证发现、用户交互、OAuth 和凭证存储仍然由客户端管理。

这避免了创建一种插件格式，使开发者意外地在可移植目录中附带可重复使用的凭证。

这也意味着两个客户端可以加载同一个插件，但呈现不同的认证体验。

这是有意为之。

客户端扩展在不妨碍创新的前提下保持可移植性

一个试图过早标准化所有功能的标准通常会变得庞大或不切实际。

Agent 插件使用反向域名扩展命名空间来实现客户端特定的行为。

示例：

com.example.client/

或：

{
"extensions": {
"com.example.client": {
"feature": true
}
}
}

理解该命名空间的客户端可以使用它。

其他客户端会忽略它。

这创建了两个层次：

可移植核心
+
可选的客户端特定功能

便携式核心保持可预测性，而各个产品仍可进行创新。

客户端可以使用其扩展区域来实现以下功能：

• 钩子
• UI 配置
• 命令
• 附加元数据
• 特定产品的自动化

这些文件不会因为某个客户端支持它们就成为共享 v1 契约的一部分。

为什么钩子在 v1 中不可移植

AIBase 文章将钩子作为客户端特定扩展行为的一个示例提及。

这是一个重要的细微差别。

钩子不是两种标准化 Agent Plugins v1 组件类型之一。

官方 v1 设计有意将便携式核心限制为 Skills 和 MCP。

为什么？

因为 Skills 和 MCP 已经拥有强大的跨客户端定义。

钩子、命令、自定义代理、规则及相关组件在不同产品之间仍然存在显著差异。

过早地将它们标准化可能会创造出一种“通用”格式，而实际上没有任何真实客户端能够正确实现它。

该项目将这些能力留给客户端扩展命名空间，直到更强大的互操作性出现。

分发和安装被有意排除在范围之外

Agent Plugins 对包本身进行了标准化。

它没有定义单一的全局插件商店。

以下内容仍由客户端控制：

• 用户如何发现插件
• 插件是否来自市场
• 如何下载
• 安装策略
• 更新策略
• 工作区审批
• 用户认证
• 权限
• UI
• 执行确认
• 应用访问
• 企业治理

这就是为什么便携式 Agent Plugin 更接近共享包契约而非 App Store 规范。

两个客户端可以加载相同的便携式组件，同时提供完全不同的安装和安全体验。

OpenAI 自身的插件系统比便携式 v1 核心更广泛

OpenAI 目前将 ChatGPT 和 Codex 中的插件描述为打包的工作流能力。

一个 OpenAI 插件可以包含：

• Skills
• Apps
• 应用模板
• 外部数据和操作

OpenAI 工作区管理员可以独立于底层应用的权限来控制插件安装。

该 OpenAI 产品模型比最小的 Agent Plugins v1 标准更广泛。

便携式标准目前专注于：

Skills
+
MCP 服务器

OpenAI 仍可围绕该便携式核心支持额外的产品特定概念。

这正是该标准将互操作性与客户端体验分开的原因。

一个最小的 Agent Plugin 教程

最小的实用插件可以包含一个技能。

第 1 步：创建目录

hello-plugin/
├── plugin.json
└── skills/
└── greet/
└── SKILL.md

第 2 步：添加 plugin.json

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "hello-plugin",
"version": "1.0.0",
"description": "一个最小的便携式问候插件。"
}

第 3 步：添加技能

创建：

skills/greet/SKILL.md

使用标准的 Agent Skill 定义。

一个简洁的示例：

---
name: greet
description: 问候用户并提供帮助。
---

简短问候用户，并询问如何提供

帮助。

第4步：仅在需要时添加MCP

如果插件需要工具，请添加：

mcp.json

插件不需要仅仅为了有效性而提供一个空的MCP配置。

缺少可选的组件位置不会被视为错误。

第5步：在兼容的客户端中测试

在你打算支持的每个客户端中测试这个可移植核心。

不要假设“兼容Agent插件”意味着所有组件和传输方式都已实现。

客户端可以增量式地采用组件。

带本地MCP服务器的示例插件

一个更有用的包可能看起来像这样：

reporting-plugin/
├── plugin.json
├── skills/
│   └── weekly-report/
│       └── SKILL.md
├── mcp.json
└── bin/
└── reporting-server

清单：

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reporting-plugin",
"version": "1.0.0",
"description": "可移植的报表工作流程和工具。"
}

MCP配置：

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"reporting": {
"type": "stdio",
"command": "./bin/reporting-server",
"cwd": "${PLUGIN_ROOT}"
}
}
}

符合规范的客户端可以发现：

• 插件身份
• weekly-report技能
• reporting MCP服务器

而无需作者将这些可移植组件为每个客户端放置在完全不同的结构中。

错误隔离使插件更具弹性

规范中一个深思熟虑的部分是，许多组件故障是局部性的，而非灾难性的。

示例：

• 一个无效的技能可以被跳过，而其他技能继续加载。
• 一个无效的MCP服务器条目不一定禁用所有服务器。
• 失败的MCP连接不应阻止独立的技能加载。
• 客户端可以忽略不支持的组件类型。

这在真实的跨客户端生态系统中非常重要。

一个插件可以提供：

技能A
技能B
MCP服务器A
MCP服务器B
客户端扩展

如果某个客户端不支持特定的传输方式，在可能的情况下，有用的可移植其余部分仍应能工作。

否则，互操作性将变得脆弱：一个不支持的可选功能就会禁用整个插件。

符合规范的客户端可以增量式地采用标准

客户端不需要实现v1中的每一个功能。

仅支持技能的客户端只要正确加载清单并实现相关的技能行为，仍然可以符合规范。

支持MCP的客户端必须满足适用的传输规则。

这种增量模式降低了采用门槛。

较小的客户端可以从以下开始：

plugin.json
+
skills/

之后再添加MCP。

较大的客户端可以实现完整的可移植核心，加上自己的扩展命名空间。

该项目由社区治理，而非单一供应商控制

AIBase的头条将OpenAI描述为引入Agent插件的机构。

OpenAI显然是重要的参与者。

官方治理文件使所有权模型更加广泛。

Agent插件自称是一个社区治理、供应商中立的项目。

其技术指导委员会由个人组成。

核心维护者席位而非预留的企业席位。

章程规定：

• 任何单一供应商不得控制核心维护者席位的多数。
• 技术提案和讨论都是公开的。
• 项目参与按照文档规定的规则开放。
• 规范和文档材料默认使用 CC BY 4.0。
• 模式、代码和软件材料默认使用 Apache 2.0。

项目主页目前列出的初始核心维护者代表来自：

• Amazon
• Cursor
• Microsoft
• OpenAI
• Vercel

这种多供应商结构至关重要，因为当相互竞争的客户端都有参与途径时，互操作性标准才更具可信度。

该标准已拥有多个兼容客户端

官方兼容性页面目前列出了：

• VS Code
• Cursor
• GitHub Copilot
• ChatGPT & Codex
• Kiro

这比一个仅由原始作者支持的标准拥有更坚实的基础。

支持矩阵仍不完全一致。

例如，当前页面列出了多个客户端的传统 SSE 支持，而 ChatGPT & Codex 目前列出的是 stdio 和 Streamable HTTP。

重要的成果是，该包格式已经跨越了供应商边界。

插件作者现在可以面向共享核心进行开发，而不必假设每个代理环境都是完全独立的生态系统。

随着代理成为长期运行系统，这一点变得更加重要

当代理执行实际工作时，插件碎片化问题会更加突出。

一个简单的聊天机器人可以依靠少量固定的工具列表存活。

一个严肃的代理可能需要：

• 公司特定流程
• 数据库访问
• 浏览器自动化
• 部署工具
• 安全检查
• 文档工作流
• 可复用的领域指令
• 专用脚本
• 多个 MCP 服务

随着这些组件的增加，可移植性成为基础设施。

如果没有共享的打包方式，每家公司都面临维护这样一个矩阵的风险：

能力 × 代理客户端 × 版本 × 平台

可移植的包格式可以减少该矩阵的一个维度。

它并不能消除客户端特有的工作。

但它可以减少保持可复用核心同步所需的重复工作量。

代理插件、MCP 和 Agent Skills 解决不同的问题

这三个概念相互关联，但不应混为一谈。

一个有用的心智模型是：

Skill
= 代理应该知道什么或应该如何工作

MCP
= 代理如何连接到外部能力

Agent Plugin
= 如何将这些可复用部分打包以供兼容客户端使用

因此，Agent Plugins 是现有组件标准**之上**的一个层，而非其替代品。

Agent Plugins 不解决什么

该标准的范围刻意保持狭窄。

它并不解决所有跨代理兼容性问题。

它不标准化模型

同一个插件在被不同模型加载时，行为可能不同。

它不标准化

权限界面

一个客户端可能在操作前要求确认，而另一个客户端则使用工作区级策略。

它不标准化身份验证

OAuth 和凭据存储仍由客户端自行管理。

它不保证每种 MCP 传输方式

客户端可以实现不同的子集。

它在 v1 中不标准化钩子或命令

这些仍是客户端特有的。

它不创建统一的市场

分发仍不在核心规范范围内。

它不隔离 MCP 进程

包路径的包含并不等同于运行时隔离。

它不保证相同的行为

可移植性意味着客户端可以根据共享契约发现并加载组件。这并不意味着每个代理运行时都会以完全相同的方式推理或调用该组件。

插件作者的安全注意事项

可移植插件可以扩大分发范围。

这也增加了安全默认设置的重要性。

不要嵌入机密

避免在以下位置存放凭据：

plugin.json
mcp.json 头
mcp.json 环境变量值
打包的文件

使用客户端管理的身份验证。

保持包路径受控

不要依赖跳出插件根目录来访问任意主机文件。

将本地 MCP 服务器视为可执行代码

stdio 服务器可以启动进程。

用户和企业管理员应当了解他们正在安装什么。

最小化所需权限

只需要读取访问权限的插件不应要求写入操作。

记录外部服务

远程 MCP 服务器应有明确的所有权、隐私和数据使用政策。

谨慎进行版本管理

即使目录结构仍然有效，服务器行为的变化也可能导致破坏性变更。

开发者现在应该做什么

第 1 步：分离可移植部分和客户端特有部分

确定当前插件中哪些部分真正可复用：

技能
MCP 服务器
共享元数据

将仅限客户端的行为移至相应的扩展命名空间。

第 2 步：添加带版本号的模式

在 plugin.json 中明确声明 Agent Plugins 1.0.0。

第 3 步：规范技能放置位置

将可移植的 Agent 技能放在：

skills//SKILL.md

第 4 步：规范 MCP 配置

使用根级：

mcp.json

而不是仅依赖客户端原生的配置文件。

第 5 步：移除可移植的机密信息

将凭据转移到各客户端的身份验证系统中。

第 6 步：在多个客户端中测试包

互操作性应当被证明，而非被假设。

第 7 步：跟踪规范更新

由于当前规范仍标记为工作草案，请关注项目仓库、讨论、模式及兼容性页面的变更。

已确认的内容和需要细化的内容

stdio 和 Streamable HTTP 是标准的 MCP 传输类型 | 已确认 |
| 旧版 SSE 已被识别，但对于客户端是可选的 | 已确认 |
| 客户端特定扩展使用反向域名命名空间 | 已确认 |
| 分发、安装、权限和用户体验已标准化 | 否；有意不在范围内 |
| 钩子是便携式 Agent Plugins v1 组件 | 否；它们可以是客户端扩展 |
| OpenAI 独家拥有或管理 Agent Plugins | 否 |
| 该项目是供应商中立的，并由社区治理 | 官方治理已确认 |
| 版本 1.0.0 是完全冻结的最终标准 | 否；规范页面目前显示为工作草案 |
| 每个兼容客户端都支持每个组件和 MCP 传输 | 否 |
| ChatGPT、Codex、VS Code、Cursor、GitHub Copilot 和 Kiro 被列为兼容 | 当前兼容性页面已确认 |

常见问题

什么是 Agent Plugins 1.0？

Agent Plugins 1.0 是一种开放、供应商中立的包格式，用于可重用的 AI 代理扩展。它标准化了如何将 Agent Skills 和 MCP 服务器配置放置在可移植的插件目录中。

Agent Plugins 是仅限 OpenAI 的标准吗？

不是。OpenAI 参与该项目，并在 ChatGPT 和 Codex 中支持该格式，但官方项目由社区治理且供应商中立。其初始核心维护者团队包括来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的相关人员。

Agent Plugin 需要哪些文件？

每个插件都需要一个根目录下的 plugin.json。技能可以存储在 skills/ 下，而 MCP 服务器可以在根目录的 mcp.json 中描述；客户端特定功能可以使用带命名空间的扩展。

Agent Plugins 会取代 MCP 吗？

不会。MCP 仍然定义客户端与 MCP 服务器之间使用的协议。Agent Plugins 定义了一种可移植的方式，将 MCP 服务器配置与其他可重用的代理组件一起打包。

钩子是 Agent Plugins 1.0 的一部分吗？

不是作为可移植的核心组件。版本 1 标准化了技能和 MCP 服务器；在支持的情况下，钩子可以通过客户端特定的扩展命名空间来实现。

哪些客户端支持 Agent Plugins？

官方兼容性页面目前列出了 VS Code、Cursor、GitHub Copilot、ChatGPT 和 Codex 以及 Kiro。它们支持的 MCP 传输方式不同，因此作者应查看实时兼容性矩阵。

一个 Agent Plugin 在每个客户端中的行为是否完全相同？

不是。该标准涵盖包发现和可移植组件，而不涉及模型、权限界面、身份验证流程、市场或客户端特定的运行时行为。插件可以具有可移植性，但不一定产生完全相同的执行行为。

Agent Plugins 1.0 被视为最终版本吗？

版本 1.0.0 是当前发布的版本，并提供了规范的架构。规范性规范页面目前将项目状态标注为“工作草案”，因此开发者应继续关注公开的治理和版本管理流程。

相关工具

• Agent Plugins：可移植 Agent Plugins 包格式的官方文档网站。
• Agent Skills：用于可重用技能的开放性规范。

Agent 插件内的组件。

• 模型上下文协议：MCP 客户端和通过 mcp.json 打包的服务器所使用的协议。
• ChatGPT 插件：OpenAI 当前用于 ChatGPT 和 Codex 工作流的插件系统。
• VS Code Agent 插件：微软关于在 VS Code 中加载 Agent 插件的文档。
• GitHub Copilot 插件：GitHub 关于插件包和 Open Plugin Spec 支持的文档。

相关链接

• Agent 插件规范 1.0.0：当前可移植格式的完整规范性契约。
• 构建 Agent 插件：官方最小插件教程和包布局指南。
• 兼容客户端：VS Code、Cursor、GitHub Copilot、ChatGPT 与 Codex 以及 Kiro 的当前支持矩阵。
• Agent 插件规范仓库：公共模式、治理、问题、讨论和规范源代码。
• Agent 插件治理：社区治理章程和供应商中立规则。
• Agent 插件许可：规范、文档、模式和代码的许可条款。
• ChatGPT 和 Codex 中的 OpenAI 插件：OpenAI 对插件、应用、技能和工作区控件的产品级解释。

总结

Agent 插件 1.0 解决了日益增长的 Agent 生态系统中的一个实际问题：开发者不得不为每个客户端以不同的方式重复打包相同的技能和 MCP 集成。

该规范定义了一个精简的可移植核心——必需的 plugin.json、skills/ 目录下的技能、mcp.json 中的 MCP 配置、包包含规则、版本化模式以及带命名空间的客户端扩展。分发、市场、权限、身份验证和界面仍由客户端控制。

该项目已列出了多个主要 Agent 客户端的支持，包括 VS Code、Cursor、GitHub Copilot、ChatGPT 与 Codex 以及 Kiro。这意味着它不仅仅是一个 OpenAI 专属的插件格式，尽管 OpenAI 是参与维护方之一。

版本 1.0.0 是当前发布的契约，而规范页面仍将其标注为工作草案。开发者现在即可采用，但应关注公开的治理和版本化流程。

主要转变很简单：开发者不再需要为每个平台重写相同的 Agent 扩展，而是可以开始将技能和 MCP 集成视为具有统一包结构的可移植组件。