Skills Registry 公测开启：为企业打造私有的 Skill 管理中心

AI Agent 进了企业，Skill 就不再是程序员桌上的玩具，而是团队每天都要用的生产力工具。但现实很骨感——大多数企业的 Skill 管理，还停留在“谁写的谁管、用的时候再找”的状态。

我们跟不少团队聊过，大家的困扰出奇地一致，归结起来主要是这四个。

困扰一：自研的 Skill 散落在各处，团队复用全靠“要”

A 同事写了一个客服问答 Skill，功能很不错。B 同事听说了也想用，只能私聊 A 要代码包。A 发了个 ZIP，B 下载解压、改配置、调环境，折腾半天才跑起来。

过了一个月，A 优化了一版，加了新功能。B 完全不知道，还在用旧版。C 同事又来找 A 要，A 再发一遍——团队里到底有几个人在用这个 Skill、用的是哪个版本，A 自己也说不清楚。

更麻烦的是，A 离职了。这个 Skill 的代码在他电脑里，没有人清楚完整内容，团队突然少了一个核心能力。

困扰二：多人共用一套 Skill，谁都能改、改完就生效

有些团队稍微成熟一点，会把 Skill 放到共享盘或者 Git 仓库里。Git 确实有版本追溯能力，但问题是权限太粗了——谁都可以直接提交修改。

核心业务用的 Skill，被新来的实习生顺手改了一个参数，合并进了主分支，直接上了线。等客服系统开始乱回答，大家排查了半天才发现是这个改动惹的祸。虽然能通过提交记录追责，但事故已经发生了，用户已经受到影响。Git 能帮你事后找人，却拦不住事前的误操作。

不同项目组共用一套 Skill 库更头疼。A 组改了自己的 Skill，不小心影响了 B 组的业务，因为底层依赖搞混了。两边撕了半天，最后发现是命名冲突。

困扰三：公开市场的 Skill，企业不敢直接用

公开市场里的 Skill 很丰富，下载就能用，看起来很美好。但企业真敢直接往生产环境里塞吗？

一个团队告诉我，他们从社区下载了一个“数据分析”Skill，刚准备上线就被安全团队监控到异常流量——原来这个 Skill 在试运行阶段就开始偷偷把请求数据发到外部服务器。幸好及时发现并阻断，没有造成实质损失。但这件事之后，团队立了一条规矩：所有外部 Skill 必须经过安全审核才能上线。

可问题是，审核怎么做？靠人工一行行看代码？一个 Skill 动辄几千行，还得看它的依赖链，根本审不过来。没有工具支撑，这条规矩就是一张废纸。

困扰四：迭代了新版本，不知道怎么验证、怎么回滚

Skill 和业务代码一样需要持续优化。你改了一版内部的数据处理 Skill，觉得逻辑更完善了，直接替换上线。结果用户反馈说输出格式反而乱了——原来新版本在某些边界 case 上处理得不对。

你想回滚到上一版，结果发现根本没保留。只能凭记忆一点点改回去，花了大半天才恢复。下一次再迭代的时候，你心里直打鼓：这次会不会又出幺蛾子？没有验证机制、没有回滚能力，每次更新都像在赌博。

这四个困扰，说到底是一个问题：企业缺少一个私有的、可控的、安全的 Skill 管理中心。

Skills Registry 就是来解决这些问题的。

Skills Registry 是面向企业的私有 Skill 仓库。它和公开市场（Skills Hub）的关系很简单：公开市场负责“提供”，Registry 负责“把关”。企业从公开市场找到需要的 Skill，导入到 Registry 中，经过安全审核和权限配置后，再分发给团队内的 Agent 使用。

下面四个能力，分别对应上面的四个困扰。

自己搭一套 Skill 管理体系，成本不低。要配服务器、搭存储、调网络，出了问题还得自己排查。很多团队想管，但光是“把环境跑起来”这一步就劝退了。

Skills Registry 的做法是：底座已经帮你搭好了，你只需“拎包入住”。

创建命名空间就能用，不需要自己维护实例

平台基于 Nacos 构建，底层能力已经就绪。你在控制台创建一个命名空间，就能立刻开始管理 Skill。不需要配置服务器、存储和网络，也不需要维护 Registry 实例的健康状态。对于没有专职运维团队的企业来说，管理 Skill 的门槛从“几周”降到了“几分钟”。

兼容标准协议，公开市场 Skill 直接导入

Registry 遵循开源 Skill 协议，与公开市场无缝对接。你可以直接浏览公开市场里的 Skill，看中哪个就导入到企业内部。公开市场上的 Skill 发了新版本，Registry 也能自动感知，你可以选择要不要跟进升级。公开市场的丰富生态和企业内部的严格管控，你都能享受到。

支持上传企业自研 Skill，不依赖外部提供商

除了从公开市场导入，Registry 也支持直接上传企业自研的 Skill。本地开发完成后，打包成 ZIP 通过页面上传，或者通过 OSS 通道批量导入，即可进入 Registry 的统一管理流程。企业的核心能力完全自主可控，不需要绑定任何外部提供商。

nacos-cli 一键上传和安装，团队分发零门槛

Skill 进入 Registry 后，团队成员可以通过 nacos-cli 命令行工具一键安装到自己的 Agent 中。不再需要手动下载、解压、配置，一条命令就能完成分发。反过来，本地开发好的 Skill 也可以通过 nacos-cli 一键上传到 Registry，无需打开网页操作。对于需要给多台服务器批量更新 Skill 的场景，这能省掉大量重复劳动。

以前 A 同事写了个好 Skill，要到处发 ZIP。现在上传到 Registry 设置为公开，全团队直接在库里搜得到、装得上。A 更新了版本，所有人都能收到，不会再有人用旧版。

Skill 不再散落各处，而是统一汇聚到企业的私有仓库。创建命名空间就能用，公开市场 Skill 直接导入，团队分发一条命令搞定。

团队大了，Skill 就成了共享资源。没有边界和权限，协作必然乱套。

Skills Registry 从三个层面来解决。

命名空间级别数据隔离，各团队互不干扰

你可以按项目、按团队、按业务线划分不同的命名空间，每个空间里的 Skill 完全独立。A 项目组在自己的空间里折腾，B 项目组完全不受影响。不同业务线的数据天然隔离，从源头上杜绝了“互相串台”。

Skill 可见性自由设置，公开共享但防篡改

每个 Skill 可以设置为公开或私有：

• 公开 Skill：命名空间内有权限的用户都能查看和使用，但不能修改。你写了一个好 Skill，设为公开的那一刻，同事直接就能用，不需要你逐个授权；同时 Skill 的内容受保护，不会被误改。
• 私有 Skill：只有你自己或被你授权的人才能看到和修改，适合核心业务或敏感场景。

大部分 Skill 都是“公开给大家用、但只允许我改”——既实现了共享，又守住了编辑权。

权限落到单个 Skill，owner 自主管控

Registry 的权限控制精细到了单个 Skill 的级别。你是 Skill 的 owner，可以修改、可以删除、可以发起审核。如果你授权了同事协助迭代，对方也能修改，但改完后必须经过安全扫描和审核流程，最终能不能发布，还是你说了算。

这样既实现了团队协作，又避免了“人人可改、改完就生效”的失控局面。

各团队数据隔离互不干扰，公开 Skill 全团队可用但防篡改，权限落到单个 Skill，owner 自主管控。

外部 Skill 有安全风险，这是事实。但“有风险”不等于“不能用”，关键是要有机制把风险拦住。

Skills Registry 的做法是：所有 Skill 进门前先过安检，owner 做最终把关。

接入阿里云 AI 安全护栏，扫描维度可自定义

平台接入了阿里云安全护栏技术，这是阿里云安全工程师针对 AI 场景专门打造的防护体系。扫描引擎覆盖以下检测维度：

• 提示词攻击：检测 Skill 中是否藏有 Prompt Injection、越狱攻击等风险，防止系统指令被篡改。
• 敏感数据泄露：识别 Skill 中是否硬编码了密钥、Token、数据库连接串等敏感信息。
• 数据外发行为：检测 Skill 运行时是否会将数据发送到外部服务器。
• 恶意代码：识别后门、危险系统调用、恶意文件等风险。
• 恶意 URL：检测 Skill 中是否引用了恶意或不可信的链接。
• 依赖漏洞：检测 Skill 依赖的外部包是否存在已知安全漏洞。
• 模型幻觉：评估 Skill 是否可能引发模型输出不可靠内容。

更关键的是，企业可以自定义扫描策略——调整检测项的严格程度、设置风险阈值、添加自定义过滤词、配置专属的安全规则。不同行业、不同规模的企业，对安全的要求千差万别，Registry 允许你按自己的标准来。

扫描未通过时，owner 有权根据实际情况决定是否继续发布

扫描完成后，系统会生成清晰的风险报告。对于未通过扫描的 Skill，普通用户无法继续发布。但 Skill 的 owner 作为最了解这个 Skill 的人，可以根据实际情况做判断：如果扫描报出的风险属于误报或可接受范围，owner 可以选择继续发布；如果确实有问题，就打回修改。

这个机制设计得很务实。机器扫描负责“提醒风险”，owner 负责“结合业务做判断”。既保证了安全底线，又不会因为机器误报卡住业务进度。

此外，从上传到发布的每一个环节都有记录。出了问题能追溯到具体的人、具体的版本、具体的操作。

接入阿里云 AI 安全护栏，扫描维度可自定义；未通过扫描时 owner 有权根据实际情况决定是否继续发布，其他用户无法推进。

Skill 要持续优化，但优化不能靠“赌”。Registry 给了团队一套完整的版本治理工具，让每次迭代都有迹可循、每次发布都有退路。

语义化版本 + 版本锁定，生产环境不受意外影响

每个 Skill 遵循语义化版本号，版本间可以对比差异。更重要的是，Agent 绑定 Skill 时会锁定具体版本。同事发布了新版本，你的生产环境不会自动跟着变——你完全掌控什么时候升级、升级到哪个版本。已发布的版本内容不可修改，你看到的是什么，用的就是什么，不会有“今天和昨天不一样”的意外。

灰度发布逐步放量，有问题自动回滚

Registry 支持灰度发布。新版本可以先让一小部分 Agent 试用，观察核心指标（成功率、响应延迟）是否正常，再逐步扩大范围。如果灰度过程中指标劣化，系统自动回滚到上一个稳定版本。这种“小步快跑、随时止损”的方式，让团队敢于尝试优化，又不用担心搞崩生产环境。

Skill 和版本独立上下线，管控更精细

Registry 把“Skill 是否启用”和“某个版本是否在线”拆成了两个独立的控制维度。你可以把整个 Skill 全局禁用，也可以单独下线某个有问题的版本，让 Agent 自动回退到上一个在线版本。面对问题时可以“精准打击”，而不是“一刀切”。

版本变更后，Agent 能在秒级感知并加载新版本，整个过程无需重启。

结合 AgentLoop，Skill 迭代从“赌”变成“有据可依”

Skill 优化最大的难题是：改了之后到底好不好？以前只能靠主观感受判断。Skills Registry 已经在规划与 AgentLoop 的深度集成——AgentLoop 是阿里云推出的 AI Agent 效果优化平台，提供全链路可观测性和基于 LLM-as-Judge 的评估体系。

未来，你可以通过 AgentLoop 对 Skill 进行量化评估：工具选择是否正确、参数填写是否准确、Agent 轨迹是否合理。Bad Case 会自动沉淀为数据集，形成“发现问题 → 优化 Skill → 验证效果”的数据飞轮。Skill 的迭代不再是“我觉得好了就发”，而是有数据支撑、有评估依据的科学过程。

版本锁定保证生产稳定，灰度发布逐步验证、指标劣化自动回滚，Skill 和版本独立上下线；结合 AgentLoop，Skill 迭代将有数据支撑。

公开市场和 Skills Registry 不是谁替代谁，而是各司其职。两者的核心差异可以概括为：

打个比方：公开市场像是超市，商品丰富，你可以随便挑。Registry 像是家里的厨房，从超市买回来的菜要清洗、处理、按家人的口味调配，才能上桌。两者缺一不可。

企业可以从公开市场发现和浏览 Skill，但导入到 Registry 后，必须经过企业内部的安全审核和权限配置，才能被团队使用。当公开市场上的 Skill 发布了新版本，Registry 会自动感知，企业可以选择是否同步升级。

关键原则是：外部 Skill 进入企业后，必须通过内部安全审核才能使用。这不是不信任公开市场，而是在通用审核之上，再叠加一层企业自定义的安全策略。

Skills Registry 现已开启公测，参与方式很简单：

第一步：开通体验

只需要一个阿里云账号，开通 MSE 产品即可参与。

第二步：创建并上传你的第一个 Skill

进入 MSE 产品页面，找到 AI Registry 入口，创建一个工作空间，上传你的第一个 Skill。可以设置为公开给团队使用，也可以设为私有。跑一遍完整的注册流程，感受一下平台的能力。

第三步：邀请同事一起用

把 Skill 公开后，邀请团队其他同事来使用。他们可以通过 nacos-cli 一键安装你的 Skill 到自己的 Agent 中，不需要手动下载配置。

公测期间遇到的问题和建议，欢迎反馈。你的真实使用体验，会直接影响后续功能的迭代方向。

说实话，Skill 管理这件事，很多企业已经意识到它的重要性。现在大家的关注点除了在“怎么让 Agent 更聪明”，还会进一步的去想：当团队里有几十个、上百个 Skill 的时候，怎么保证它们安全、可控、可追溯？

Skills Registry 的出发点很简单：企业在用 AI 能力的时候，不能只关注“用得上”，还得关注“管得住”。外部 Skill 要能放心用，内部 Skill 要能高效复用，迭代更新要敢做也能回。

如果你和团队也正在经历这些困扰——Skill 散落各处找不到、外部 Skill 不敢用、多人协作怕误改、版本更新没底气——不妨在公测期间体验一下 Skills Registry。看看它能不能帮你把 AI 能力真正管起来。