Agent Plugin Marketplace：Skills＋MCP 一键安装、分发、签名与企业管理完整平台

摘要：Agent 插件市场不是把 Skills 和 MCP Server 放进一个搜索框。企业真正要解决的是“谁发布、包从哪里来、要求什么权限、谁批准、装到哪一台机器、出问题怎样停用和回滚”。本文用一个可离线运行的参考项目，把 Skills 与 MCP 元数据放进同一治理目录，演示 Ed25519 签名、哈希与包结构校验、人工审批、隔离安装和审计记录，同时说明生产平台还需要身份系统、构建证明、沙箱和各主机适配。

核心结论：先把信任链做完整，再谈一键安装

Agent Plugin Marketplace 可以分为三个平面。发现平面记录插件名称、版本、发布者、能力和安装说明；控制平面执行来源核验、审批、权限策略、分发、版本锁定与撤回；运行平面才由具体 Agent 主机加载 Skill 或连接 MCP Server。三者拆开后，“一键安装”不再是拿到 ZIP 就解压并执行，而是在管理员认可的版本和目标环境中，完成可核验的安装动作。本文的项目只实现离线参考控制平面：上传本地包，校验签名和文件安全，审核通过后解压到隔离存储，并保留回滚指针。它不会自动修改 Codex、Claude、ChatGPT 或其他主机配置，也不会启动任何 MCP Server。

官方事实要先分开。Agent Skills 规范把一个 Skill 定义为含有 SKILL.md 的目录，文件顶部有 YAML frontmatter，至少有 name 和 description，目录还可以包含 scripts、references、assets。MCP 是 AI 应用连接外部系统的协议；官方 MCP Registry 当前主要存公开服务器的元数据和安装配置，仍处于 preview，不能把它理解为企业私有插件仓库或运行时安全审查服务。Sigstore 的 Cosign 能为文件签名和验证，GitHub Artifact Attestations 能提供构建来源证明。这些能力之间没有“装上就自动可信”的官方承诺，企业需要自己定义可信发布者、身份、审查与部署策略。以上是官方资料；本文的产品架构和演示流程是 AI Stack Nav 的设计与本地测试。

背景：为什么 Skills 与 MCP 需要统一治理

Skills 主要告诉 Agent 如何执行某类任务，可能附带脚本、模板和参考文件。MCP Server 给 Agent 暴露工具、资源、提示等能力，远程服务器还涉及授权与网络连接。两者共同点是把外部内容和能力带进 Agent 的工作环境。一个看似无害的“总结会议记录”Skill 可能在脚本中读取整盘文件；一个“搜索公司文档”的 MCP Server 可能实际向外网发送请求。名称、描述和下载次数都不能证明运行时行为，签名也只能证明某个密钥签过某个版本，不能证明代码没有漏洞。

插件市场往往从便利性出发：搜索、安装、启用。然而企业上线要回答一组更具体的问题：发布者是否受信任？下载包与审核过的包是否一致？安装是否需要 shell、文件系统、网络、凭据和第三方账号？权限是否能在每个主机上落实？更新是否会改变工具说明、访问域名或运行命令？旧版本如何撤销？审计中能否把安装事件追溯到提交人、复核人和执行人？如果这些信息只藏在聊天记录里，目录再漂亮也难以治理。

本文采用“工件不可变、元数据可审查、安装须授权”的基本约束。每个包有 name、version、kind、publisher、sha256 和 capabilities。发布者对规范化的 manifest 签名，市场用管理员预先登记的公钥验证，再比对包哈希。审核员批准后，部署员才能将版本安装到独立目录；审核员与部署员不能用同一名字。这是示例中的岗位分离，不是真实身份认证，因为角色由命令行参数声明。生产版必须从 SSO/OIDC 身份令牌、组织成员关系和服务端策略得出角色，不能相信用户自报。

核心功能拆解：发现、验证、审批、安装与回滚

上图给出信任链。来源目录只回答“哪里有这个 Server/Skill”，发布包和签名回答“拿到的字节是否与受信任发布者的声明一致”，审查回答“在本组织中是否允许安装”，运行时策略回答“真正执行时能碰什么”。这些判断不能互相替代。尤其要避免把签名视为安全扫描结果：签名证书或公钥对应的身份若被盗，恶意版本也可能带有有效签名；审核还需要比较版本差异、依赖、域名、执行命令和数据流。

Skills 和 MCP 的打包边界

Skill 的 SKILL.md 可以包含普通文字，也可能引导 Agent 运行同目录脚本。教程项目校验 frontmatter 的基本字段、限制 ZIP 总大小与文件数，拒绝绝对路径、.. 路径、反斜杠和软链接；它并不完整解析官方 YAML 规范，也不分析脚本意图。MCP 示例只检查包根部的 server.json 名称和 JSON 格式，不把这个教学用 server.json 当成官方 Registry 的完整发布 schema。真实 MCP Registry 有自己的元数据规范、命名空间和发布流程；企业私有目录可参考其发现接口设计，却仍要独立实现权限和运行治理。

版本号在样例里采用严格的 major.minor.patch，例如 1.0.0。生产系统还要处理预发布、版本范围、依赖冲突、平台兼容性和可重现构建。一个插件在作者的 Linux 环境能安装，不代表在受限 Windows 主机里能运行。跨宿主“统一安装”通常需要适配器：把受审版本复制到宿主认可的位置，生成宿主特定配置，再做健康检查与撤回。我们的演示故意停在隔离目录，不以一个未经验证的写配置动作冒充多产品适配。

适合哪些人和场景

个人开发者需要一个小目录记录试用过的 Skills 与 MCP，防止几个月后不知道脚本来源。自动化团队可以用它建立发布者、版本和权限申报表，安排安全审查。企业平台团队需要把内部扩展与公开扩展放在同一治理视图，但分开信任根和部署环境：内部发布者可以走企业 CI 签名，外部包必须经过更严格的来源与行为审查。安全团队重点看依赖、网络目的地、目录权限、提示词注入与运行记录，而不是只看封面和评分。

一个真实的例子是“销售知识查询”插件。内容团队提供 Skill，指导 Agent 如何检索授权的销售文档；平台团队提供 MCP Server，用受限 API 查询 CRM。审批不能只写“允许访问 CRM”，还要明确只读端点、客户字段、数据保留、调用频率和工具输出的可信等级。若 Skill 更新后新增“自动导出客户名单”步骤，或 MCP Server 更新后新增写入工具，即使包来自同一发布者，也应该作为权限升级重新审批。演示中的 capabilities 只作为申报字段，不会自动强制网络或文件权限；这正是正式平台需要接入沙箱和策略引擎的原因。

安装与配置：把示例先跑在本机

1. 准备 Python 3.11+，在隔离虚拟环境安装 cryptography>=42,<51。从完整资料包的 08-src 目录执行 python -m pip install -r requirements.txt。不要把真实企业私钥或生产包放进演示目录。
2. 运行 python demo.py。脚本在临时目录生成演示密钥、两个虚构 Skill ZIP，依次信任发布者、签名、提交、审核、安装、回滚。临时密钥会随目录删除。它不会修改任何 Agent 主机，也不会联网。
3. 运行 python -m unittest discover -p 'test_*.py' -v。制作时 9 项测试通过，覆盖签名有效、manifest 被篡改、包字节改变、未知发布者、路径穿越、软链接、角色拒绝、字段验证及 MCP 元数据。测试不等于生产渗透测试。
4. 用 python marketplace.py --help 查看子命令。若要导入自己的包，先在可信流程里登记发布者公钥，再准备带 SHA-256 的 manifest，签名后 submit。未经签名、哈希不符或未审批版本不能 install。
5. 安装命令的 --target 只应指向专门的隔离存储。运行结束后检查 SQLite audit 表与目标目录；不要直接把该目录加入真实 Agent 的自动加载路径。上线前由平台适配器进行二次检查，绑定真实身份、沙箱权限和审批记录。
6. 对更新与回滚进行演练。样例保留前一个活跃版本指针，回滚只切换数据库记录且要求旧文件存在，不会清理新版本目录，也不会修改宿主的运行配置。正式环境需要原子发布、配置回滚、会话排空、健康探针和紧急停用。

免费包给出“上架前十五项核验表”和纯标准库的静态 ZIP 检查脚本。它能找出明显的路径穿越、软链接、文件数量或体积超限，以及 Skill/MCP 根文件缺失；它不能验证发布者签名，也不能判定包是否安全。付费包才有签名、目录、审批、安装和回滚的完整离线参考实现，附可编辑的风险登记、测试与安全验收表。先用免费脚本检查结构，再决定是否需要按完整项目建立受控的发布链。

实际工作流：一次插件从提交到撤回

假设团队想共享一个 citation-checker Skill。发布者先按 Agent Skills 规范写 SKILL.md，列明用途、触发方式和限制，测试脚本仅检查草稿引用是否有可打开的来源；发布工程把文件压成 ZIP，计算 SHA-256。manifest 声明 network=[]、filesystem=[]、process=false，再用发布者私钥对 manifest 的规范化 JSON 签名。签名文件与包分开存放，审核员不应从包里读取“我就是可信发布者”的自我声明，而应从企业预登记的发布者记录取得公钥。

提交时，市场用公钥验证签名、重算 ZIP 哈希、检查目录安全和根文件。通过后状态是 pending，不是立即可用。审核员检查内容、变更、许可证、脚本、依赖与权限；允许后转为 approved。部署员再次验证包未被替换，解压到 store/citation-checker-1.0.0，记录活跃版本和操作人。下一次发布 1.0.1 时重新签名、审核和安装。若质量问题暴露，回滚指针恢复到 1.0.0。这段本地闭环已经实际运行，但角色是命令行模拟，包只存于本机隔离目录，不能把输出当作生产环境的审计证明。

文件来源与工具权限应进入同一个发布决策。对于远程 MCP Server，不要只检查 server.json 指向的 URL：还要核对域名所有权、授权服务器、令牌受众与作用域、重定向地址、工具清单更新方式、网络出口和日志数据。官方 MCP Registry 是公共元数据目录，不能替企业审批私人网络中的服务。自建市场可以同步公开元数据，但在运行前仍需要组织自己的信任、授权和部署流程。2026-07-28 版 MCP 规范更新了授权与路由等机制，具体实现需按主机与 SDK 支持版本分别验证，不应把教程中的静态模板直接部署到任何生产 Agent。

对比与选型：从轻量清单到企业平台

如果只有一个人的几条只读 Skill，先做来源登记、版本锁定、手工检查和隔离测试，未必需要建设大型平台。如果一个团队每周分发几十个扩展、接入多个 Agent 客户端，目录、审批和审计会很快成为实际需求。再往上，跨部门权限、远程 MCP 凭据和自动更新要求把身份、策略、沙箱、签名、构建证明与运行监控纳入平台。建设顺序宜先定义权限申报和可复核证据，再设计一键安装的用户体验。

公共目录、包管理器和企业市场各有职责。MCP 官方 Registry 提供公开 Server 的发现和标准化元数据；npm、PyPI、容器仓库负责实际包托管；GitHub Artifact Attestations 与 Sigstore 可为工件来源和签名验证提供基础设施；企业市场则需要把这些证据与组织审批、环境策略、运行时监控连起来。是否采用现成产品，取决于私有包、主机适配、SSO、审计保留与离线部署要求。本文付费项目是参考实现，适合教学和方案验证；它不是一个已联通所有 Agent 客户端的商用市场。

风险、限制与生产落地清单

第一，签名私钥不能打包进插件或源码仓库。示例 keygen 用本地临时文件演示算法，生产应使用受管密钥服务或硬件安全模块，控制签名工作流、审批人和密钥轮换。还要验证 CI 构建身份与来源证明，避免“有签名但来源错误”。即使验证成功，也不能跳过代码审查和沙箱试运行。

第二，审核员和部署员不能靠命令参数自称。示例用 --role reviewer 和 --role deployer 教学展示流程分工，攻击者若能直接运行 CLI，就能假冒角色。生产系统需由服务端验证 SSO/OIDC 身份、组织角色和批准范围，签发短期授权，记录不可随意改写的审计日志。SQLite 文件可以被本机管理员改动，不适合当不可抵赖的审计库。需要保留审批原因、安装目标、工件摘要和撤回通知，并对敏感日志做权限和保留策略。

第三，ZIP 检查不是恶意软件检测。项目拒绝路径穿越、软链接、过大包和缺失根文件，但不执行静态依赖分析、病毒扫描、行为分析或容器隔离。Skill 文本本身也可能含有诱导 Agent 泄露数据的指令；MCP 工具描述和返回值是低信任内容。真实主机需要把数据来源与系统指令分开，对高风险工具调用设置批准，并在文件、网络、进程和凭据层强制最小权限。不要把一个“忽略所有限制”的提示词当作授权策略。

第四，更新会带来供应链漂移。旧版本获批不代表新版本自动获批；包名相同也可能换了发布者。建议固定发布者身份、版本和摘要，把新增域名、文件路径、进程能力、工具清单、依赖和许可证变化列为高风险差异。紧急撤回时要停止新安装、通知运行主机、撤销令牌并调查已执行的动作，而不只是把市场页面隐藏。示例 rollback 只切换隔离存储指针，正式平台还需要主机配置同步与运行中任务处置。

第五，公开目录的内容可变。MCP Registry 当前预览状态，元数据与 API 可能调整；不要把其搜索结果当作稳定的安全评级。对第三方包要核对官方作者渠道、包托管地址、许可证和签名身份。签名验证时要绑定预期的发布者身份，不能只看“签名有效”。Cosign 的 keyless 工作流还要求核对证书身份与 OIDC 颁发者；GitHub 构建证明也应核对仓库和工作流身份。离线验签需要提前取得并保护可信根材料。

事实依据与来源

官方已确认：Agent Skills 的目录与 frontmatter 格式；MCP 官方 Registry 的公开元数据定位和 preview 状态；MCP 2026-07-28 规范；Sigstore 的文件签名与验签机制；GitHub 的 Artifact Attestations。本站实际运行：本地 Ed25519 示例签名、两版本提交审批安装与回滚，9 项单元测试通过。尚未验证：真实企业 SSO、KMS/HSM、Cosign/GitHub Attestation 在本项目中的集成、远程 MCP Server 运行、不同 Agent 主机的配置适配、容器生产部署。企业平台建设路径属于编辑判断。

参考官方来源（内容核验日期：2026-10-08，美国太平洋时间）：

• Agent Skills Specification
• MCP Registry 官方说明
• MCP 2026-07-28 介绍
• Sigstore 文件签名
• Sigstore 验证文件签名
• GitHub Artifact Attestations

相关阅读：站内搜索 MCP；站内搜索 Agent 安全。

常见问题

下载一个 Skill 就能一键安装到所有 Agent 吗？

不能。Skill 的目录格式可移植，但不同主机发现目录、启用、工具授权与执行环境不完全相同。需要逐个适配并核对官方文档。本项目只把受审版本安装到隔离目录。

MCP Registry 的“官方”标签等于安全背书吗？

不是。官方 Registry 是公开服务器元数据和发现服务，目前预览。企业仍需检查发布者身份、包来源、服务器域名、授权范围和运行行为。

签名通过能否免除人工审核？

不能。签名证实的是特定密钥对特定 manifest 的签署，配合哈希能识别包字节改变。恶意代码、被盗密钥和过度权限仍需审查与运行时控制。

免费包与完整项目分别包含什么？

免费包包含 15 项上架检查表和不依赖第三方库的 ZIP 静态检查脚本，只能做基础结构核验。完整项目包含签名、审批、隔离安装、回滚的离线源码、9 项测试、16 组资料和可编辑表格；售价 ¥69，详见本站商品页。两者都不提供真实企业账号或云服务。

企业是否可以把这个代码直接接入 SSO 后上线？

不能直接上线。示例使用命令行自报角色、SQLite 审计和本地文件，尚无真实认证、策略强制、沙箱、密钥管理、并发事务保护、依赖扫描或高可用。应先做威胁建模和独立安全评估。

如何处理插件权限升级或紧急撤回？

把新增网络域名、进程执行、文件目录、工具列表和数据字段视为重新审核条件。紧急撤回需要阻止新安装、通知运行主机、暂停或隔离现有实例、撤销凭据并保留审计证据；只改目录状态不足以处理已安装版本。

领取配套资料

下载免费包：上架检查表＋ZIP 静态体检脚本。查看完整项目包（¥69）。