从 Skill、MCP 到 Plugin：深入理解 Codex、WorkBuddy 与大厂 Agent 插件体系

随着 AI Agent 从简单的聊天助手逐步演进为能够调用工具、执行复杂任务的智能系统，其能力扩展机制也在不断变化。

早期，我们通常通过 Prompt 定义 Agent 的行为，通过 Function Calling 接入业务接口，后来出现了 MCP、Skill、Subagent 等机制。如今，Codex、Claude Code、WorkBuddy 等产品又开始建设 Plugin 插件体系。

这不免让人产生疑问：已经有了 Skill 和 MCP，为什么还需要 Plugin？Plugin 究竟是一个新的执行框架，还是把现有能力重新包装了一遍？Agent、Hook、Command 等组件又是如何被纳入其中的？

要回答这些问题，我们不能只看某个产品的插件目录结构，而是需要从 Agent 能力组织方式的变化，以及插件系统与 Agent Runtime 的关系入手。

一、为什么 Agent 需要 Plugin？

先看一个常见的场景。

假设我们正在开发一个具备代码审查能力的 Agent，希望它能够读取 Git 仓库、检查代码质量、识别潜在风险，最后生成审查报告。

按照传统的扩展方式，我们可能需要分别完成以下工作：

• 编写 Skill，告诉 Agent 应该按照什么标准审查代码。
• 配置 MCP Server，让 Agent 能够访问 GitLab、SonarQube 等外部服务。
• 定义一个代码审查子 Agent，专门承担复杂分析任务。
• 配置 Hook，在 Agent 修改代码后自动执行检查。
• 编写对应的脚本、模板和配置文件。

这些机制本身并没有问题。真正的问题出现在能力复用和分发阶段。

例如，另一个项目也需要代码审查能力，开发人员可能需要重新复制 Skill、配置 MCP、注册 Agent，甚至重新处理工具权限和脚本依赖。

当一个团队只有几个 Agent 时，这种方式尚且可以接受。但当平台拥有几十个 Agent、上百个 Skill 和大量 MCP 工具时，分散管理很容易带来版本不一致、配置重复、依赖混乱、权限失控等问题。

Plugin 就是在这种背景下变得重要起来的。

Plugin 的核心价值，不是创造一种新的 Agent 执行能力，而是将已有的扩展能力组织成可安装、可复用、可分发、可管理的软件包。

这个设计理念其实并不陌生。

在传统软件领域，npm 通过 Package 管理 JavaScript 依赖，VS Code 通过 Extension 扩展编辑器能力，IDE 通过插件体系增加语言支持、调试器和开发工具。

Agent Plugin 沿用了类似的思路，只是扩展对象从传统的软件功能，转变成了面向大模型的工作流程、工具、子代理和事件处理能力。

二、Plugin、Skill、MCP、Agent 到底是什么关系？

理解 Plugin，首先需要把几个经常混用的概念区分开来。

概念	核心职责	解决的问题
Plugin	能力打包与分发	如何安装、共享、升级和管理能力
Skill	任务说明与执行知识	Agent 应该如何完成任务
MCP	外部能力连接协议	Agent 如何访问工具、资源和服务
Agent / Subagent	专门的任务执行主体	复杂任务交给谁执行
Hook	生命周期事件处理	某个事件发生时自动做什么
Command	显式调用入口	用户如何快捷启动某项能力
UI	交互式展示	用户如何查看、编辑和确认结果

这里最容易误解的地方是：Plugin、Skill、MCP 并不是传统面向对象意义上的继承关系。

Skill 不是 Plugin 的子类，MCP 也不是 Plugin 专属的协议。

Skill、MCP、Agent 都可以独立存在，而 Plugin 是将它们组合在一起的上层打包和管理机制。

可以用下面这张逻辑结构图来理解：

Agent Runtime │ Plugin Manager │ Plugin 能力扩展包 │ ┌──────────────┼──────────────┐ │ │ │ Skills MCP Servers Agents │ │ │ 工作流程 外部工具连接 子任务执行 │ │ │ └──────────────┼──────────────┘ │ Hooks / Commands │ 事件与调用入口

需要说明的是，这只是一张概念示意图，不代表所有厂商的 Plugin 都包含这些组件。插件实际支持什么，由宿主产品的扩展规范决定。

2.1 Skill：告诉 Agent 怎么做

Skill 通常以SKILL.md为核心，包含任务描述、执行步骤、参考资料、脚本和输出规范。

例如，我们定义一个 Agent 质量评测 Skill：

--- name: evaluate-agent description: 评估 Agent 执行质量，分析成功率与失败原因 --- # Agent Evaluation 当用户要求评估 Agent 时，按照以下流程执行： 1. 确定评测数据集与 Agent 版本。 2. 执行评测任务。 3. 统计任务成功率与工具调用失败率。 4. 分析失败轨迹并进行分类。 5. 生成结构化评测报告。 所有指标必须来自真实的执行结果。

Skill 的本质是一组可复用的任务知识与行为指导。

它能够告诉 Agent 何时执行、如何执行以及什么结果符合要求，但并不意味着所有具体能力都由 Skill 自己实现。

例如，Skill 可以要求读取评测数据集，但能否真正读取数据，取决于当前运行环境是否提供相应工具。

2.2 MCP：让 Agent 具备调用外部能力的接口

MCP（Model Context Protocol）解决的是 Agent 与外部服务之间的连接问题。

MCP 不只有 Tool，还包括 Resources、Prompts 等协议能力。在常见 Agent 产品中，最直接的应用是 Tool Calling。

例如，评测平台通过 MCP Server 提供三个工具：

evaluation-mcp-server ├── list_datasets ├── run_evaluation └── get_evaluation_report

Agent 可以通过 MCP Client 发现工具、理解参数 Schema，并发起调用。

MCP Server 负责访问真实的数据和服务，Skill 则负责指导模型如何使用这些工具完成评测流程。

因此，Skill 和 MCP 可以形成一种互补关系：

Skill 解决业务执行方法，MCP 解决外部能力访问。

当然，Skill 并不一定依赖 MCP。它也可以使用宿主已有的文件、搜索或命令工具。

2.3 Agent：提供专门的任务执行角色

当任务变得复杂时，仅靠一个主 Agent 不一定是最合适的选择。

例如，Agent 质量评测涉及测试集准备、批量执行、失败归因和报告生成。我们可以将失败归因交给一个专门的 Subagent。

在支持插件代理定义的产品中，可以通过 Markdown 文件描述它的角色：

--- name: failure-analyzer description: 分析 Agent 执行失败的根因 maxTurns: 10 --- 你是一名 Agent 评测专家。 负责分析执行轨迹，并识别： - 工具调用失败 - 任务规划失败 - 上下文缺失 - 最终结果不正确 所有结论必须关联实际执行证据。

但这里有一个关键区别。

Plugin 中包含的 Agent，通常只是 Agent Definition，而不是完整的 Agent Runtime。

Agent Definition 可以声明角色、指令、工具范围和执行配置，但创建执行实例、管理模型调用、上下文、任务状态和子代理生命周期，仍然由宿主 Runtime 负责。

换句话说，插件负责提供“可以使用什么类型的 Agent”，Runtime 负责“如何让这个 Agent 真正运行”。

而且，并不是所有 Plugin 规范都支持直接打包agents/。例如 CodeBuddy Code、Claude Code 支持此类定义，OpenAI 当前的公共可移植插件规范则主要围绕 Skill 与 MCP 组织能力。

2.4 Hook：将能力接入 Agent 生命周期

Skill 和 Tool 通常与模型的决策过程密切相关，Hook 则不一样。

Hook 是一种由运行时事件驱动的处理机制。

例如，CodeBuddy Code 支持在工具执行完成后触发PostToolUse事件，可以用来执行格式检查、安全校验等操作。

{"hooks":{"PostToolUse":[{"matcher":"Write|Edit","hooks":[{"type":"command","command":"${CODEBUDDY_PLUGIN_ROOT}/scripts/check.sh"}]}]}}

当满足匹配条件时，Runtime 会触发对应的 Hook，而不需要模型每次都主动决定调用。

因此，Skill 和 Hook 的定位存在明显差异：前者主要描述任务工作流，后者将操作绑定到明确的系统事件。

对于安全校验、格式检查、执行审计等场景，Hook 往往比单纯依赖 Prompt 更合适。不过，真正的权限控制仍应由 Runtime 和后端服务实施。

三、Codex、Claude Code 和 WorkBuddy 的 Plugin 体系

虽然这些产品都使用 Plugin 的概念，但具体设计存在差异。理解这些差异，有助于区分通用的插件架构与产品专属的扩展规范。

3.1 OpenAI Codex：强调可移植的能力打包

OpenAI 当前的插件体系，核心是将 Skill、MCP Server 及可选 UI 组织成一个可安装的能力包。

官方推荐的新可移植格式采用如下结构：

agent-eval-plugin/ ├── plugin.json ├── skills/ │ ├── evaluate-agent/ │ │ └── SKILL.md │ └── analyze-failures/ │ └── SKILL.md ├── mcp.json └── assets/

其中，plugin.json负责声明插件身份和元数据：

{"$schema":"https://agent-plugins.org/schemas/1.0.0/plugin.schema.json","name":"agent-eval-plugin","version":"1.0.0","description":"Reusable Agent evaluation workflows"}

如果插件需要接入远程评测服务，可以通过mcp.json进行配置：

{"$schema":"https://agent-plugins.org/schemas/1.0.0/mcp.schema.json","mcpServers":{"eval-service":{"type":"streamable-http","url":"https://eval.example.com/mcp"}}}

这里的 URL 只是示例，需要自行部署对应的 MCP Server。

值得注意的是，插件包通常保存的是 MCP Server 的连接配置，而不一定包含 MCP Server 本身的全部业务实现。

服务可以运行在独立基础设施上，由多个 Agent 产品复用。

此外，Codex 仍兼容已有的.codex-plugin/plugin.json格式。当前@plugin-creator脚手架主要使用这种兼容布局，其中.mcp.json与新可移植格式的mcp.json还存在 Schema 差异，不能直接重命名替换。

从架构角度来看，Codex 的设计重点在于两个方面。

首先是Progressive Disclosure（渐进式披露）。Skill 可以先向模型提供名称和描述，在确实需要执行相关任务时再加载完整指令与辅助资源，避免将大量 Skill 内容无差别塞入上下文。

其次是统一的插件发布与分发机制。插件可以通过本地、仓库级 Marketplace 进行测试和团队共享，也可以按发布要求进入面向 ChatGPT 与 Codex 的公共插件目录。

需要特别区分的是，公共插件的能力会受到具体宿主环境限制。例如 OpenAI 的生命周期 Hook 支持有单独的安装与安全要求，不能认为所有通过公共目录安装的插件都能任意执行本地脚本。

3.2 Claude Code：更加丰富的组件式扩展

Claude Code 的 Plugin 是一个包含多种组件的目录。

典型结构如下：

my-plugin/ ├── .claude-plugin/ │ └── plugin.json ├── skills/ ├── agents/ ├── commands/ ├── hooks/ │ └── hooks.json ├── .mcp.json └── .lsp.json

与 OpenAI 当前主要围绕 Skill 和 MCP 的可移植规范相比，Claude Code 在插件级明确支持子代理定义、Hooks、命令等能力。

例如，插件可以提供一个代码审查 Agent，让主 Agent 在复杂任务中进行委派；还可以注册 Hooks，在文件修改、工具调用等生命周期节点执行特定逻辑。

因此，Claude Code 的插件体系不仅解决能力分发，还直接参与 Runtime 的能力扩展。

不过，即使插件提供了子 Agent 的定义，具体的子代理创建、上下文维护和任务执行仍由 Claude Code 的运行时实现。

3.3 WorkBuddy / CodeBuddy：关注插件装载与运行时状态

腾讯 WorkBuddy 面向桌面 Agent 工作场景，提供 Skills、MCP 等能力扩展入口。其关联产品 CodeBuddy Code 则公开了更加完整的插件开发与运行机制。

以 CodeBuddy Code 的公开插件规范为例，一个插件可以包含：

audit-plugin/ ├── .codebuddy-plugin/ │ └── plugin.json ├── skills/ │ └── risk-analysis/ │ └── SKILL.md ├── agents/ │ └── risk-analyzer.md ├── commands/ │ └── analyze.md ├── hooks/ │ └── hooks.json ├── .mcp.json ├── .lsp.json └── settings.json

这些组件都位于插件根目录，只有对应的元数据文件位于.codebuddy-plugin/中。CodeBuddy Code 也对部分 Claude 和 WorkBuddy 风格的插件清单提供兼容支持。

其中，commands/提供显式入口，例如/audit-plugin:analyze；agents/提供可被调用的子代理定义；.lsp.json则用于注册语言服务器。

CodeBuddy Code 的另一个值得研究的地方，是其插件缓存与 Runtime 加载机制。

根据公开文档，它采用了cache-first的首轮插件投影策略：运行时优先读取启用状态、安装注册表和本地版本化缓存，而不是每次启动都同步访问远程 Marketplace。

随后由协调机制处理市场同步、依赖补齐、状态修复和必要的组件刷新。

这种方式避免了每次 Agent 启动都依赖远程插件源，也为插件版本升级、运行时热更新和长会话稳定性提供了更好的基础。

需要注意，WorkBuddy 桌面端和 CodeBuddy Code CLI 的功能入口、加载行为与支持范围并不一定完全一致，不能直接把 CLI 文档中的所有机制视为桌面产品的内部实现。

3.4 Microsoft Copilot：更偏向企业 Action 扩展

微软的 Plugin 体系又有所不同。

在 Microsoft 365 Copilot 中，插件可以为声明式 Agent 提供 MCP 或 REST API 操作能力。

例如，一个企业采购 Agent 可以通过 Plugin 调用供应商查询接口、审批接口和订单创建接口。

这种插件更接近Action Plugin：通过 Manifest、MCP Tool 或 OpenAPI Schema 描述外部操作，再由 Agent 根据任务需要选择使用。

微软还支持从 MCP Server 动态发现工具，并允许开发者在部分场景下固定工具集合。

因此，虽然都叫 Plugin，微软的技术 Action Plugin 与 Claude Code 的多组件插件包并不是完全相同的抽象。

3.5 横向比较

维度	Codex	Claude Code	CodeBuddy Code
Skill	支持	支持	支持
MCP	支持	支持	支持
插件级子 Agent 定义	非公共可移植规范的统一组件	支持	支持
Commands	非公共可移植规范的统一组件	支持	支持
Hooks	支持，具有环境与发布限制	支持	支持
LSP 配置	非公共可移植规范的统一组件	支持	支持
Marketplace	支持	支持	支持
主要特点	能力打包与跨产品分发	丰富的运行时组件扩展	组件扩展、缓存与状态协调

这些差异说明了一个事实：目前 Plugin 还不是所有 Agent 平台完全统一的技术标准，而是一类具有共同设计思想、但各家实现不同的能力扩展体系。

Skill 和 MCP 的标准化程度相对更高，而 Agent 定义、Hook、Command、UI 等能力，通常仍需要按具体宿主进行适配。

四、大厂 Agent Plugin 系统的整体架构

了解了插件的组成后，我们进一步考虑一个问题：当用户安装一个 Plugin 时，系统内部究竟发生了什么？

这里可以参考传统云平台的设计，将 Plugin 体系划分为控制面与执行面。

4.1 控制面：负责插件生命周期管理

控制面不直接承担模型推理，它主要负责插件的发现、安装、版本管理、权限配置和状态维护。

Plugin Control Plane │ Marketplace │ Plugin Registry │ Plugin Manager │ ┌───────────────┼───────────────┐ │ │ │ 安装与更新 版本与依赖 权限与策略 │ │ │ └───────────────┼───────────────┘ │ Plugin Artifact + Installation

这里有两个 Registry 概念容易混淆。

Plugin Registry记录的是插件级元数据，例如插件名称、版本、发布来源、依赖、安装包位置等。

而稍后提到的Capability Registry，记录的是 Plugin 内部贡献给 Agent 的具体能力。

一个插件版本可能包含三个 Skill、十个 MCP Tool 和两个子 Agent 定义。Plugin Registry 只需要知道这个插件包是什么，Capability Registry 则需要知道它具体提供了哪些能力。

4.2 执行面：负责能力加载和任务执行

执行面的核心是将 Plugin 提供的组件转换为 Agent Runtime 能识别和使用的能力。

Plugin Artifact │ Plugin Loader │ Capability Registry │ ┌──────────────────┼──────────────────┐ │ │ │ Skill Registry Tool Registry Agent Registry │ │ │ Skill Loader MCP Client Subagent Factory │ │ │ └──────────────────┼──────────────────┘ │ Agent Runtime │ Planning / Tool Execution Delegation / State Management │ Execution Layer │ MCP Server / API / Sandbox

这张图是综合各家公开能力抽象出的参考架构，并不是某家厂商公布的内部源码结构。

在这种架构中，Plugin Loader 负责解析插件包与构建能力注册信息，Capability Registry 负责提供当前可用的能力视图，Agent Runtime 则根据具体任务决定是否以及如何使用它们。

尤其要强调：Plugin Manager 不应该成为每一次 Tool Calling 的同步中转服务。

插件管理主要发生在安装、更新和加载阶段。任务执行时，Agent Runtime 应直接通过 Tool Gateway 或 MCP Client 调用已经注册的工具。

这样才能避免插件管理系统成为推理与工具执行的性能瓶颈。

五、Plugin 从安装到执行的完整生命周期

我们可以用一个智能审计插件来说明实际流程。

假设企业发布了一个audit-risk-plugin，它包含合同风险识别 Skill、采购数据 MCP Server、风险分析子 Agent 和必要的检查 Hook。

5.1 安装阶段：从插件包到能力注册

当用户在插件市场安装audit-risk-plugin@1.0.0时，系统首先解析插件来源和元数据，然后执行安装校验、依赖处理与必要的授权流程。

插件安装成功之后，安装管理器记录插件版本、作用域、启用状态及其 Artifact 位置。

随后 Plugin Loader 读取 Manifest，并依据宿主规范发现 Skill、MCP、Agent、Hook 等组件。

这些组件经过适配与校验后，进入相应的 Capability Registry。

整个过程可以概括为：

选择插件 ↓ 解析 Manifest ↓ 检查来源、依赖与权限 ↓ 安装版本化插件包 ↓ 保存 Installation State ↓ Plugin Loader 发现组件 ↓ 注册 Skill / MCP / Agent / Hook ↓ 构建 Agent Runtime 能力视图

这里必须区分安装与启用。

安装代表系统已经准备好了插件包及其依赖；启用代表当前作用域允许使用插件能力。具体操作是否会自动完成后续物化和加载，取决于宿主产品的状态管理机制。

安装不代表所有能力已经获得业务访问授权，MCP Server 也可能还需要 OAuth、Token 或其他身份认证。

5.2 运行阶段：Agent 如何使用插件？

用户输入：

“帮我分析这批供应商采购合同是否存在异常。”

Agent Runtime 获取当前允许使用的能力集合，模型根据 Skill 描述和任务上下文，判断是否需要合同风险分析能力。

如果匹配，系统按需加载对应 Skill 的详细内容。

Skill 指导 Agent 查询合同、供应商、采购记录和交易明细。此时 Agent Runtime 通过 MCP Client 调用已经注册的工具，获取实际业务数据。

如果需要进一步对异常进行归因，并且宿主支持对应子 Agent，Runtime 可以创建风险分析子代理，让它在受控的工具和上下文范围内完成专项分析。

最终由主 Agent 汇总证据，生成分析报告。

这条执行链路可以表示为：

User Request │ ▼ Agent Runtime │ ▼ Skill Selection │ ▼ Load Skill Instructions │ ▼ Tool Planning │ ▼ MCP Client ──────► Business MCP Server │ │ │ 查询真实业务数据 │ │ ◄───────────────────────┘ │ ▼ Optional Subagent │ ▼ Result Aggregation │ ▼ Final Response

值得注意的是，Skill 的选择通常存在模型判断环节，因此并不是严格确定性的关键词路由。

但工具权限检查、参数校验、危险操作确认等机制，应由执行系统保证，而不能仅靠 Skill 中的一段自然语言说明。

5.3 插件升级与正在执行的 Agent 怎么办？

这是 Plugin 系统工程化过程中容易被忽略的问题。

假设用户正在执行一个长期审计任务，运行到一半时，管理员将插件从1.0.0升级到1.1.0。

新版本可能改变 Skill 指令、Tool Schema，甚至调整业务规则。

如果正在执行的 Agent 立即使用了新版本，就有可能出现前后行为不一致的问题。

因此，生产环境通常需要考虑插件版本绑定与执行快照。

一种推荐方式是：Agent Run 创建时记录其有效插件版本，执行期间使用对应能力定义。插件升级后，新任务使用新版本，已有任务保留原有版本。

对于持续数小时甚至数天的 Agent 任务，还需要考虑旧 MCP Tool 的兼容窗口，以及远程服务升级是否破坏了已有调用协议。

CodeBuddy Code 公开文档中使用版本化插件缓存和运行时状态协调机制，为这类问题提供了一个很有参考价值的实现方向。

六、如果自己开发 Plugin 平台，应该如何设计？

理解大厂设计后，我们可以进一步抽象一套适用于企业级 Agent 平台的 Plugin 架构。

我认为不需要一开始就照搬完整的插件市场，而应该首先实现插件与能力注册中心的解耦。

6.1 核心模块划分

建议至少区分以下逻辑模块：

模块	职责
Plugin Registry	管理插件身份、版本、来源和元数据
Plugin Manager	安装、卸载、启停、更新与依赖处理
Plugin Loader	解析插件包并发现组件
Capability Registry	统一注册 Skill、Tool、Agent、Hook
Tool Gateway	MCP 连接、工具执行、鉴权、超时与审计
Policy & Observability	权限控制、租户隔离、日志、Trace 和运行快照

这六个模块并不意味着需要建设六个微服务。

对于初期平台，Plugin Manager、Loader 和 Registry 完全可以放在同一个服务里，避免引入过早的分布式复杂度。

真正需要独立部署的，往往是具有独立运行负载、鉴权边界或资源要求的业务 MCP Server。

6.2 建立清晰的数据模型

插件系统至少需要区分插件定义、插件安装状态、能力定义与执行快照。

以 TypeScript 为例，可以设计如下模型：

// 插件版本定义interfacePlugin{id:string;version:string;manifest:Record<string,unknown>;artifactUri:string;}// 租户插件安装状态interfacePluginInstallation{tenantId:string;pluginId:string;version:string;enabled:boolean;}// 插件贡献的能力interfaceCapability{id:string;pluginId:string;pluginVersion:string;type:"skill"|"tool"|"agent"|"hook";name:string;}// Agent Run 使用的插件快照interfaceRunPluginSnapshot{runId:string;plugins:Array<{pluginId:string;version:string;}>;}

这是一个简化的数据模型。实际落地还需要考虑依赖锁、Artifact 摘要、Schema 版本、租户授权、MCP 服务端版本和运行时兼容信息。

PluginInstallation解决的是“某个租户目前启用了哪些插件”。

RunPluginSnapshot解决的是“某次 Agent 执行究竟使用了哪些插件版本”。

二者不能混为一谈。插件当前版本可能已经更新，但历史任务仍然需要能够追溯当时的能力定义。

6.3 Capability Registry 应该是核心抽象

如果一个平台已经具备 Skill、Tool 和 Subagent 功能，那么不建议让 Plugin 再实现一套完全独立的执行流程。

更合理的方案是让 Plugin Loader 把能力注册到已有的 Registry。

例如：

interfaceCapabilityRegistries{skills:SkillRegistry;tools:ToolRegistry;agents:AgentRegistry;hooks:HookRegistry;}

Plugin Loader 只负责把外部插件包转换为运行时能够理解的定义。

真正的 Skill 选择、Tool 调用和子 Agent 创建，仍然复用原来的 Agent Runtime。

这样一来，插件系统只是增加了一种能力来源，而不是重建整套 Agent 执行框架。

这是我认为自研 Plugin 系统最关键的架构原则。

6.4 插件能力需要按需加载

随着插件数量增加，Runtime 不可能每次都把所有 Skill 正文、Tool Schema 和 Agent 指令放入模型上下文。

应当将插件的安装、能力注册和上下文注入区分开。

安装阶段完成 Plugin 元数据、组件路径和能力索引的准备。

会话启动时，根据用户、租户、Agent 配置和权限形成可用能力集合。

任务执行时，再根据模型选择和显式调用，加载必要的 Skill 正文、工具定义与辅助资源。

Tool Schema 也可以结合宿主支持的延迟加载或工具检索机制进行优化，避免一次暴露大量低相关性工具。

这里的关键不只是减少 Token，还包括降低模型面对过多能力时的选择混乱。

6.5 安全治理不能交给 Skill

Plugin 允许第三方或其他团队提供能力，也意味着系统的信任边界被扩大。

例如，某个插件包含一个删除采购合同的 MCP Tool。

不能因为这个插件已经安装，就直接允许所有 Agent 调用该工具。

在生产环境中，至少需要分别处理插件安装权限、工具调用权限、真实业务资源权限和执行环境权限。

MCP Server 应在服务端验证用户或服务身份、业务资源范围和具体操作权限。对于高风险写入操作，还应结合人工确认、审计日志和必要的幂等机制。

插件自身携带的脚本和 Hook 也需要单独考虑执行隔离、文件访问、网络访问和凭证管理。

Plugin 可以声明能力，但不能自行决定它拥有多大的权限。

6.6 可观测性与版本治理

当插件生态扩大之后，排查问题往往比实现插件功能更困难。

例如一次 Agent 执行失败，我们至少需要能够定位：

• 本次执行启用了哪个插件及其版本。
• 模型最终选择了哪个 Skill。
• Skill 是否正确加载。
• 哪个 MCP Tool 被调用，参数和结果是什么。
• 是否发生子 Agent 委派。
• 是否触发 Hook，是否发生权限拒绝或执行异常。

这些信息最好统一关联到 Agent Run ID、Trace ID 和 Plugin Version。

如果缺少这些记录，插件越多，Agent 系统就越容易演变成难以维护的黑盒。

七、Plugin 应该如何逐步建设？

对于已经有 Agent Runtime、Skill 和 MCP 能力的平台，我不建议一开始就建设完整 Marketplace。

更合适的路径是逐步演进。

第一阶段：Skill + MCP 插件化。

首先支持 Manifest、插件版本、安装启停和组件发现，让一个插件包可以向平台贡献多个 Skill 和 MCP Tool。这一阶段重点解决能力复用与统一分发问题。

第二阶段：引入 Agent、Hook 等组件扩展。

如果平台确实有 Subagent Runtime，再允许插件贡献子 Agent 定义；如果 Runtime 已有明确的生命周期事件体系，再引入 Hook。

不要为了模仿某个产品的目录格式，先建设一套尚无实际场景支撑的子代理或事件机制。

第三阶段：完善企业级插件治理。

当插件数量达到一定规模，再建设 Marketplace、依赖锁定、灰度发布、版本兼容、租户权限、审核与可观测能力。

另外，建议优先保持 Skill 和 MCP 的独立性。

对于 Codex、Claude Code 和 CodeBuddy 不同的插件格式，可以通过 Adapter 适配，而不是让核心业务能力直接依赖其中某一种 Manifest。

例如，核心的评测服务始终通过标准 MCP 对外提供工具，Skill 保持相对独立的目录和内容，再由不同的宿主适配层处理插件包结构、Agent 定义和 Hook 配置。

这样才能降低对某一家 Agent 产品的技术绑定。

八、关于 Plugin 的几个常见误区

理解到这里，有几个容易出现的误区就比较容易澄清了。

Plugin 不是新的 Agent 执行框架。它主要解决能力打包、扩展和管理，实际推理与任务执行仍然由 Agent Runtime 完成。

Plugin 不一定比 Skill 更强大。如果只需要复用一套操作流程，单独使用 Skill 就足够了；当需要团队分发、多能力组合或统一版本管理时，Plugin 才更有价值。

Plugin 不必须同时包含 Skill、MCP 和 Agent。Skills-only、MCP-only 或二者组合都可以是合理的插件形态，关键是宿主是否支持。

Plugin 中包含 Agent 定义，不代表 Plugin 自带 Agent Runtime。子代理的生命周期、模型调用、工具执行、任务调度和上下文隔离，仍然需要宿主实现。

Plugin 也不是所有厂商完全通用的格式。尽管 Skill 与 MCP 相对容易复用，但 Manifest、Agent Definition、Hooks、Commands 等组件仍然存在产品差异。

Plugin 安装成功不代表可以直接访问所有系统。插件启用、工具连接、身份认证与业务授权是需要分别处理的问题。

这些边界如果在设计初期没有明确，很容易让 Plugin 从一个轻量的能力包管理机制，逐渐演变成与 Agent Runtime 强耦合的复杂系统。

九、总结：Plugin 是 Agent 平台化的重要一步

回顾整个发展过程，Agent 能力扩展机制其实经历了一个很自然的演进：

Prompt ↓ Function Calling ↓ MCP：标准化外部能力连接 ↓ Skill：结构化复用任务知识 ↓ Subagent / Hook：扩展执行组织方式 ↓ Plugin：统一打包、分发与管理 ↓ Marketplace：形成可治理的能力生态

这不是严格的技术替代顺序，也不代表后面的机制一定覆盖前面的能力，而是展示 Agent 系统逐步平台化的一条演进思路。

对于个人开发者而言，Plugin 的价值可能只是将几个常用 Skill 和 MCP 打包，在不同项目中快速安装。

但对于企业级 Agent 平台而言，Plugin 的价值远不止于此。

它让 Agent 的能力不再完全依赖主系统的代码发布，而是能够以独立的软件扩展单元进行开发、分发、安装和治理。

平台可以逐步形成插件市场、统一能力注册、版本管理、权限控制和执行审计等机制，让不同团队围绕同一个 Agent Runtime 构建可复用的业务能力。

因此，研究 Codex、Claude Code 和 WorkBuddy 的 Plugin 体系，真正值得关注的并不是某个目录叫skills/还是agents/，也不是plugin.json多支持了几个字段。

更重要的是理解：

如何将能力的开发、分发与管理，从 Agent Runtime 的具体执行逻辑中解耦出来。

Plugin Manager 负责管理能力，Capability Registry 负责组织能力，Agent Runtime 负责执行能力。

当这三个部分的边界足够清晰时，Skill、MCP、Agent、Hook 甚至未来新的能力类型，都可以在不推翻核心 Runtime 的前提下持续扩展。

这才是 Plugin 体系对于 Agent 平台工程化最重要的意义。

---

参考资料

1. OpenAI — Plugin Architecture
2. OpenAI — Package Your Plugin
3. Claude Code — Plugins Overview
4. Claude Code — Plugin Manifest Reference
5. CodeBuddy Code — 创建插件
6. CodeBuddy Code — 插件 API 参考
7. CodeBuddy Code — Plugin Marketplaces
8. Microsoft Learn — Plugins for Microsoft 365 Copilot
9. SegmentFault — Codex 插件开发实战

说明：本文基于截至 2026 年 10 月公开可查的技术文档整理。架构图与数据模型属于基于公开机制形成的工程设计抽象，不代表厂商披露的内部实现。