当 AI Agent 开始“团队作战”,Skill 也需要一个共享仓库:Nacos Skill Registry 入门(以及平替方案介绍)

当 AI Agent 开始“团队作战”,Skill 也需要一个共享仓库:Nacos Skill Registry 入门(以及平替方案介绍)

最近很多团队或者个人都在使用 AI Agent。

有的用 Claude Code,有的用 Codex,有的用 hermes,有的还会自己封装一套内部 Agent CLI。

刚开始用的时候,大家关注的问题通常是:

“它会不会写代码?”

“它能不能帮我改 Bug?”

“它能不能看懂我们项目?”

“它能不能按我们的规范来?”

“它能不能理解我们的需求?”

但用着用着,你会发现真正麻烦的不是“AI 会不会干活”,而是:

好用的那套提示词和工作流,怎么在团队里共享?

比如你写了一个很好用的代码审查 Skill,里面有团队的前端规范、接口规范、异常处理规范、日志规范。结果另一个同事也想用,你怎么办?

最常见的答案是:

“我发你一份,你复制到本地。”

听起来没毛病,但复制几次之后问题就来了:

谁手上的是最新版?

谁改过?

改坏了怎么办?

新人入职怎么拿到这些 Skill?

安全团队审核过的版本,怎么保证大家都用的是同一个?

这时候就需要一个统一的 Skill 仓库。

接下来我就给大家介绍一个新的工具:Nacos Skill Registry。

官方的说法是:Skill 管理,也就是 Skill Registry,是 Nacos 提供的私有 Skill 仓库能力,用来集中管理 Skill 的存储、版本、安全审核和分发。

换成大白话:

以前 Skill 散落在每个人电脑里。

现在可以统一放到 Nacos 里管理。

当然了,标题中也说到了,除了Nacos管理以外,我在文章的末尾也会介绍一下平替方案,主要是个人在本地做的集中Skills管理,团队并不适用,如果你的技术能力目前还是入门阶段,或者本职业是产品、运营或者其他非技术岗位,可以参考文章最后的方案,对于技术能力要求并不高,小白也可以上手。

一、先说说 Nacos 是什么

如果你不是开发同学,可能听过 Nacos,但不一定知道它到底是干嘛的。

Nacos 是阿里巴巴于 2018 年开源的服务发现与配置管理平台(Dynamic Naming and Configuration Service),源自阿里内部多年微服务治理实践。它主要用于服务注册发现、动态配置管理和服务健康检查,帮助分布式系统更稳定地运行。随着云原生和 AI 应用发展,Nacos 也逐步扩展到 MCP、Agent、Skill 等 AI 资源管理场景。

所以,基于概念我们可以先把 Nacos 理解成一个“登记中心”。

在微服务系统里,一个应用通常不会孤零零地运行。

它会调用很多别的服务,也会依赖很多配置。

比如一个电商系统里,有订单服务、库存服务、支付服务、用户服务。

订单服务要调用库存服务时,它总得知道库存服务在哪里吧?

但问题是,服务的地址不是固定的。

今天库存服务可能跑在这台机器上,明天可能扩容到另外几台机器上,后天又可能迁移了。

如果把地址写死在代码里,那系统一变动就麻烦了。

所以更好的方式是:

服务启动后,先到 Nacos 报个到:

“我叫库存服务,我现在在这里。”

其他服务要找它的时候,就去 Nacos 问:

“库存服务现在在哪?”

这就是服务注册与发现。

除了服务地址,Nacos 还经常用来管理配置。

比如某个功能开关、限流规则、灰度比例、数据库参数。

这些东西如果每次修改都要重新发版,会非常麻烦。

放到 Nacos 里之后,就可以统一管理、动态调整。

所以在很多开发者眼里,Nacos 过去主要是做两件事:

一个是服务发现。

一个是配置管理。

但到了 AI Agent 时代,事情变了。

Nacos 3.x 开始把能力扩展到了 AI 管理中心。

它不只管理服务和配置,也开始管理 Skill、Agent、MCP Server、Prompt、AgentSpec 这些 AI 资源。

而今天我们主要介绍一下Nacos Skill的能力,以后有机会再介绍一下Multi-agent能力,这个更加有意思。

二、为什么团队或者个人需要集中管理 Skills?

当一个人使用 Agent 时,Skill 可以放在本地。

比如你自己写了一个 code-review Skill,告诉 Agent 怎么审查代码。只要它对你有用,放在本机目录里就可以。

但当团队开始一起使用 Agent,问题就复杂了。

  1. Skill 会变成团队知识资产

一个成熟的 Skill,往往不是一次写好的。

它可能经历了很多次迭代:

第一次只是告诉 Agent “帮我检查代码”。

后来加上了团队的目录结构。

再后来加上了接口规范、异常处理规范、日志规范。

再后来加上了“遇到数据库迁移必须检查回滚脚本”。

最后,它变成了一个非常贴合团队研发习惯的专业 Agent 工作流。

这类 Skill 其实就是团队知识资产。

它沉淀的不是某个人的 Prompt 小技巧,而是团队对某类工作的标准做法。

如果这些 Skill 只存在于某个人电脑上,那么它就很难复用、很难治理,也很容易丢失。

  1. 共用 Skills 可以降低团队协作成本

集中管理 Skills 的核心价值,不是“把文件放到服务器上”这么简单,而是让团队形成共用能力。

比如一个团队可以维护这些共用 Skills:

frontend-review:前端代码审查规范

backend-api-design:后端接口设计规范

incident-diagnosis:线上故障排查流程

release-checklist:发版前检查清单

domain-modeling:领域建模方法

wms-requirement-analysis:特定业务系统的需求分析流程

团队成员不需要各自维护一份。

新人也不需要问:“你那个好用的 Skill 发我一下。”

只要从统一仓库发现、安装、更新即可。

这和代码依赖管理很像。

没有 Maven、npm、PyPI 之前,大家也可以复制 jar 包、复制源码、复制脚本。

但一旦团队协作规模变大,依赖就必须有仓库、有版本、有权限、有发布流程。

Skill 也一样。

当 Skill 从个人 Prompt 变成团队基础设施,它就需要 Registry。

同样,如果你改

  1. 集中管理带来版本、权限和安全

Nacos Skill Registry 的价值可以概括成几件事:

团队共享:一次创建,团队共用

版本管控:支持草稿、审核、发布、上下线

安全保障:可接入发布 Pipeline,做安全扫描

灵活分发:通过 CLI、API、SDK 发现和安装

可见性控制:支持 PUBLIC / PRIVATE 范围控制

这些能力在个人使用时可能不明显,但在企业或团队场景里非常重要。

举个例子:

如果一个 Skill 里包含“如何访问内部系统”“如何处理客户数据”“如何生成 SQL 变更”的操作指令,它就不能随意传播,也不能绕过审核。

如果某个 Skill 被发现存在 Prompt 注入风险、数据泄露风险、恶意代码模式,团队也需要有机制把它下线、修复、重新发布。

Nacos 文档中提到,Skill 的发布 Pipeline 可以在发布前进行自动化检查,内置 skill-scanner 插件可用于检测 Prompt 注入、数据泄露风险和恶意代码模式。

这意味着,Skill 不只是“好不好用”的问题,也开始进入“能不能安全使用”的治理阶段。

  1. 个人也值得用 Nacos 管 Skills

很多人会觉得,Skill Registry 是团队才需要的东西。

其实个人重度使用 Agent,也很容易遇到类似问题。

比如你同时使用 Claude Code、Codex、Cursor,甚至还有本地自建 Agent。

每个工具都有自己的 Skill 或规则目录。刚开始你可以手动复制,但时间一长,就会发现:

哪个工具里的 Skill 是最新版?

我在公司电脑改过的 Skill,家里电脑怎么同步?

这个项目用的代码审查 Skill,能不能复用到另一个项目?

我之前写过的排障 Skill,放哪儿了?

对个人来说,Nacos 就像一个自己的私有 Skill 仓库。

你可以把常用 Skill 统一放进去,比如写作、代码审查、Bug 排查、需求拆解、SQL 检查、学习笔记整理等。不同电脑、不同 Agent、不同项目,都从同一个地方下载和同步。

这样最大的好处是:

你的 AI 使用经验不会散落在各个工具和目录里,而是变成一套可以持续积累、随时迁移、统一更新的个人能力库。

换句话说,团队用 Nacos 是为了共享和治理。

个人用 Nacos,则是为了沉淀、复用和迁移。

三、Nacos 和 Skills 的安装配置步骤

下面用一个偏实操的流程,介绍如何把 Nacos Skill Registry 跑起来。

第一步:准备 Nacos Server

Nacos Skill 管理能力从 Nacos 3.2.0 开始提供。

所以如果你要体验 Skill Registry,建议使用 Nacos 3.2.x 或之后版本。

如果只是本地体验,可以使用单机模式。

Nacos 官方文档中提到,单机模式适合本地开发、功能验证和测试环境,可以使用内置 Derby 数据库;生产环境则建议使用集群模式和外部数据库。

常见部署方式有三种:

第一种,发行版部署。

下载 Nacos Server,配置后启动。

第二种,Docker 部署。

适合本地快速体验。Nacos 单机部署文档中也提供了 Docker 方式,并支持通过环境变量开启鉴权、挂载配置文件等。

第三种,Kubernetes / 集群部署。

适合企业生产环境。

如果你只是想先体验 Skill Registry,建议先用单机模式跑通流程;等团队确认要正式使用,再考虑数据库、鉴权、监控、备份和集群高可用。

第二步:进入控制台,找到 Skill 管理

Nacos 控制台提供了 Skill 管理界面,位置在:

AI 注册中心 > Skill 管理

在这个页面里,可以看到 Skill 列表。

列表页通常会展示 Skill 名称、描述、业务标签、在线版本数、草稿状态、下载量、更新时间等信息。

你可以通过三种方式创建 Skill:

手动创建:填写 Skill 名称、描述和 SKILL.md

AI 生成:提供背景描述,由 Copilot 生成 Skill 内容

上传 ZIP:上传包含 SKILL.md 和资源文件的 Skill 包

一个典型 Skill 目录大概长这样:

my-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/

其中 SKILL.md 是核心文件,包含 Skill 的元数据和具体指令。

scripts、references、assets 等目录可以放脚本、参考资料、模板等资源。

第三步:配置发布流程和安全审核

在团队环境里,不建议所有 Skill 都直接发布上线。

更推荐的流程是:

draft -> reviewing -> online -> offline

也就是:

先创建草稿。

再提交审核。

审核通过后发布上线。

不再使用时下线。

Nacos 文档中提到,同一个 Skill 同时只能有一个 draft 或 reviewing 状态的版本;版本一旦发布为 online

后内容不可修改,如果要变更,需要基于该版本新建草稿,再重新提交审核和发布。

如果团队重视安全,可以开启 Pipeline。

示例配置如下:

nacos.plugin.ai-pipeline.enabled=true nacos.plugin.ai-pipeline.type=skill-scanner nacos.plugin.ai-pipeline.skill-scanner.enabled=true nacos.plugin.ai-pipeline.skill-scanner.command=/path/to/skill-scanner

开启后,Skill 发布前可以经过自动化检查。

如果检查通过,再进入后续发布流程。

如果检查拒绝,则回退到草稿状态,修改后重新提交。

第四步:安装 Nacos CLI

除了控制台,Nacos 也提供 CLI 用于 Skill 管理。

官方文档中说明,Nacos CLI 支持配置管理、AI 技能 Skill 和 AgentSpec 的生命周期管理,包括 upload、review、release,以及交互式终端模式。

Linux / macOS 推荐使用官方安装脚本:

curl -fsSL https://nacos.io/nacos-installer.sh | bash -s -- --cli

如果你已有 Node.js 环境,也可以通过 npm 安装:

npm install -g @nacos-group/cli nacos-cli --help

或者使用 npx:

npx @nacos-group/cli --help

安装完成后,验证一下:

nacos-cli --help

第五步:配置 Nacos CLI 连接信息

Nacos CLI 推荐使用 profile 管理不同环境连接信息。

执行:

nacos-cli profile edit

它会引导你填写:

Nacos host,Nacos port,认证方式,用户名,密码,namespace

配置文件默认保存在:

~/.nacos-cli/default.conf

也可以为不同环境创建不同 profile:

nacos-cli profile edit dev nacos-cli profile edit prod

查看配置:

nacos-cli profile show

使用指定环境:

nacos-cli --profile dev skill-list

Nacos CLI 也支持命令行参数、环境变量和显式指定配置文件。

官方文档中给出的优先级是:命令行参数最高,其次是 --config,再是profile,然后是环境变量,最后是默认值。

第六步:上传、审核、发布 Skill

假设你本地有一个 Skill:

/path/to/my-skill/ ├── SKILL.md └── references/

上传 Skill:

nacos-cli skill-upload /path/to/my-skill

查看 Skill 列表:

nacos-cli skill-list

查看 Skill 详情:

nacos-cli skill-describe my-skill

提交审核:

nacos-cli skill-review my-skill

审核通过后发布:

nacos-cli skill-release my-skill --version 0.0.2

如果要发布但不更新 latest 标签,可以使用:

nacos-cli skill-release my-skill --version 0.0.2 --update-latest=false

Nacos CLI 文档中也提醒,如果 skill-review 后马上执行 skill-release 出现参数校验错误,通常是异步评审管线还没把版本标记为 reviewed,可以等待几秒后用skill-describe 查看状态,再重试。

第七步:下载和同步 Skill

团队成员要使用 Skill,可以从 Nacos 下载:

nacos-cli skill-get my-skill

默认会下载到:

~/.skills/my-skill/

也可以指定目录:

nacos-cli skill-get my-skill -o /custom/path

如果希望本地 Skill 跟随 Nacos 中的版本变化自动同步,可以使用:

nacos-cli skill-sync my-skill nacos-cli skill-sync skill-a skill-b

同步全部:

nacos-cli skill-sync --all

这样,团队就可以把 Nacos 作为统一来源,把 Skill 分发到不同 Agent CLI 可以读取的位置。

四、平替方案,个人多Agent共用Skills

方案一:在主 Agent CLI 里做映射

很多人会以 Claude Code、Codex 或其他主 Agent CLI 作为入口。

比如你在claude code中已经有一套 Skills,某个主 Agent 能识别这些 Skills。为了让另一个 Agent,比如codex 也能使用,就在本地做一层映射:

把 Claude 的 Skill 映射到 Codex 可识别的位置,可以用脚本同步不同 Agent 的 Skill 目录,然后在项目初始化脚本里自动创建软链接。

这种方式的优点是快。

对于个人来说,能用就行。

做法也很简单,直接在你主Agent的对话中,让他帮你同步就行,提示词很简单,举个例子:

帮我把/root/.claude/skills/中的grill-me技能**映射**到/root/codex/skills中。

没有服务端,没有仓库,没有权限系统,也不用引入额外基础设施。

但问题也很明显:

第一,它依赖本地环境。

深度AI使用者可能不止一台电脑,然后电脑路径不同,Agent CLI 版本不同,目录结构不同,脚本很容易失效。

第二,它缺少版本治理。

你不知道你什么时候的一个触发动作,就让Skill变了,然后你其他的Agent也按照错误的流程走下去了。

第三,挺消耗token的

Agent每次执行这个任务的时候,他会思考这个SKILLS干什么的,我应该怎么映射,映射过去是否需要修改什么配置。然后你就看到你的token刷刷的变成了2.0K,3.0K……

方案二:用 Git 仓库管理

还有一些人或者小团队会把 Skills 放进 Git 仓库。

这比纯复制或者映射要好一些。

Git 可以管理历史,可以做 Review,可以按分支协作,也可以通过脚本安装到本地。

但 Git 仓库仍然不是专门为 Skill 分发设计的,他只是一个源码仓库,尤其关于Skill变更审核,安全性方面和映射的做法差不多,只不过他有个好处就是可以记录变更历史,但是麻烦点在于你每个Agent还得去复制,不方便。

结语:Skill 会成为团队 AI 工程化的基础单元

AI Agent 刚进入团队时,大家关注的是模型能力。

但真正进入日常生产之后,决定效果的往往不是模型本身,而是团队有没有把经验沉淀成可复用、可维护、可治理的能力包。

Skill 就是这样的能力包。

它把团队的规范、流程、模板、上下文、工具使用方式封装起来,让 Agent 不再只是一个“会聊天的模型”,而是更像一个懂团队工作方式的助手。

而 Nacos Skill Registry 的意义,是让这些 Skill 不再散落在个人电脑里,不再靠复制和脚本同步,而是进入统一仓库、版本管理、安全审核和标准分发。

如果说过去的 Nacos 管的是微服务时代的“服务”和“配置”,那么在 AI Agent 时代,Nacos 正在把 Skill、Agent、MCP、Prompt 这些 AI 资源也纳入统一治理。

对于已经开始规模化使用 Claude、Codex 或其他 Agent CLI 的团队来说,Nacos Skill Registry 值得重点关注。

因为当每个人都在写 Prompt 时,团队真正需要的不是更多 Prompt,而是一套能被共用、被迭代、被审核、被分发的 Skills 体系。

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费