多AI Agent时代，Skill分散管理令人头疼？Nacos Skill Sync终结手动复制，通过中心仓库统一管控与自动分发，显著提升效率与版本管理能力。
核心内容：
1. 多Agent环境下Skill分散、手动复制导致版本混乱的常见痛点
2. 现有管理方案（如Git submodule等）的局限性（部分解决问题但未形成闭环）
3. Nacos Skill Sync解决方案：中心仓库统一管理+自动分发（软链接/复制模式）
你的Skill散落在多少个地方？
当前AI Coding领域正呈现百花齐放的态势，没有永恒的王者。模型能力持续增强，Cursor、Claude Code、Codex等工具轮番成为阶段性首选；再加上额度限制、响应延迟等现实挑战，开发者早已习惯“不把所有鸡蛋放在一个篮子里”的策略。
除了编程工具，各类通用Agent也不断涌现，每有新工具问世，总有人第一时间尝试体验。
如今，同时使用多个AI Agent开展工作，一边试用新涌现的工具，一边防范正在使用的工具突然失效，已成为这个时代开发者的新常态。
然而，工具可以无缝切换，Skill却无法自动跟随迁移。在Codex中更新过的Skill，Claude Code里仍是旧版本，Cursor目录下还可能并存一份同名但内容迥异的副本。起初手动复制尚可忍受，时间一长便会陷入混乱：哪份才是最新版本？该用哪个覆盖哪个？接入新工具时是否还要重复搬运？
这种碎片化的版本管理不仅降低工作效率，更在反复确认中不断消耗人的精力。
一份Skill，一个中心仓库
其实社区早已意识到这个问题，并涌现出多种解决方案。有人使用Git submodule或Monorepo进行统一管理，但修改Prompt仍需走commit/push/pull流程，对日常Coding来说过于繁琐；有人尝试Syncthing这类通用文件同步工具，但它只识别文件而不理解Skill语义，双向修改时极易引发覆盖灾难；还有人转向LangSmith等Prompt管理平台，却发现它们专为LLM应用开发设计，并不管理本地Agent配置文件的同步。
开源社区也出现了一些专门针对Agent Skill管理的尝试，有的提供了基础分类检索与统一索引功能，让散落的Prompt有了归处；有的则聚焦跨项目共享，尝试解决同一个Skill在多个工程中重复维护的问题。
这些探索都精准切中了痛点的某个侧面，但实际试用下来，这些方案要么解决了“存储”问题，却未解决“自动分发”；要么解决了“共享”问题，却未解决“多Agent目录的实时同步与冲突感知”。当你的Cursor、Claude Code、Codex同时运行时，需要的是修改一处便全部生效、且随时能知晓哪份是最新版本——这个“最后一公里”的闭环，至今仍缺少现成的轮子能完整补上。
既然现有方案都在“部分解决”，那就自己打造一个能彻底闭环的方案。
这就是Nacos Skill Sync的诞生背景。它所做的事情可以用一句话概括：将Skill收敛至一个中心仓库，再按需分发给各个Agent。
具体来说：
- 只维护一份中心仓库，统一存放Skill内容与同步状态；
- 默认使用软链接让各Agent目录指向中心仓库——修改一处，全部生效。若环境不支持软链接，也可切换至复制模式，由CLI负责将内容同步过去；
- 同步状态随时可查：远端是否有更新、本地是否有改动、是否存在冲突，一眼就能明确下一步该做什么。
它提供两种模式，可按需选择：
模式 |
一句话概括 |
适合场景 |
Registry mode |
Nacos AI Registry + 可视化管理 + 跨设备共享 |
希望系统管理个人Skill库，或需要团队共建Skill的场景 |
Local mode |
本地中心仓库 + 软链接/复制同步 + 零服务依赖 |
只想先将本机多个Agent的Skill统一管理，不愿折腾部署 |
两种模式共用一套操作习惯，Local mode适合先在本机收拢Skill；Registry mode则会在对应profile下维护独立的Skill repo与同步状态。这样不同profile的Skill不会相互覆盖；真正切换同步来源时，CLI会先将旧profile的软链接安全回退至各Agent的本地副本。
先从Local mode入手完全可行，后续需要跨设备共享、团队协作或版本治理时，再切换至Registry mode。
▍Registry mode：远端Registry统一管理
如果你拥有十几个持续迭代的Skill，或者团队中多人使用同一套Skill，将其散落在各自的本地目录里，迟早会引发问题——版本不一致、修改后无人同步、新成员不知从何查找。
Registry mode所做的，是将Skill纳入Nacos AI Registry这个统一入口：
- 可视化：在控制台内浏览、搜索、查看Skill，无需再翻找目录；
- 版本治理：草稿、审核、发布、回滚、label——个人可追踪每个Skill的状态，团队能将高频使用的Skill沉淀为稳定版本；
- 跨设备同步：家庭电脑与办公电脑从同一个Registry拉取Skill，新设备接入时无需手动整理；
- 双向流通：远端的Skill可同步至本地，本地沉淀的Skill也能推送上去，不会仅停留在某一个人的电脑上。
一句话：Skill从“本地配置文件”转变为可追溯、可共享、可管理的Registry资产。
▍Local mode：将本机Skill收拢为一份
Local mode更为轻量——无需接入Nacos AI Registry，仅在本地构建中心仓库，并默认以软链接方式关联各Agent的Skill目录。
其核心目标是消除多Agent环境下的Skill冗余与版本不一致问题。当同一份Skill在Codex、Claude、Qoder、Cursor、Kiro、Lingma等工具中存在多个副本时，Local mode将其收敛为单一信源，确保修改一处即可全局生效。
目前会自动发现Codex、Claude、Qoder、QoderWork、Cursor、Kiro、Lingma、CoPaw、OpenClaw，以及通用的~/.agents/skills和~/.skills；其他目录也可通过skill-sync agent add手动添加。
已散落在各Agent目录中的Skill也可逐步纳入中心仓库。处理单个Skill时，执行skill-sync add
反之，如果某个Skill不再需要由Skill Sync管理，执行skill-sync remove
Local mode也可自然升级至Registry mode。将来若想升级至跨设备或团队协作，无需重新整理，绑定一个profile即可接入远端。
快速上手
▍方式一：Agent自驱动（推荐）
我们提供了一份标准的SKILL.md，其中完整描述了nacos-skill-sync的使用规范与交互流程。只需将下方指令发送给Agent，它便会自动读取该Skill、检查本地环境并执行同步；遇到模式选择或内容冲突等需人工决策的节点时，会主动暂停并向你确认。
阅读下面的 Skill，使用它来同步我本地的 Skill：
https://nacos.io/skill-sync/SKILL.md▍方式二：CLI手动操作
若希望自行控制同步流程，可通过CLI完成。
Registry mode（跨设备 / 团队协作）
# 1. 准备 CLI（二选一）
curl -fsSL https://nacos.io/nacos-installer.sh | bash -s -- --cli
# 或者直接使用 npx
npx @nacos-group/cli@latest skill-sync --help
# 2. 配置 CLI profile
npx @nacos-group/cli@latest profile edit test
# 3. 添加 Skill，启动同步，查看状态
npx @nacos-group/cli@latest --profile test skill-sync add pdf
npx @nacos-group/cli@latest --profile test skill-sync start
npx @nacos-group/cli@latest --profile test skill-sync statusLocal mode（单机轻量同步，无需 profile）
npx @nacos-group/cli skill-sync add pdf
npx @nacos-group/cli skill-sync start
npx @nacos-group/cli skill-sync status使用案例
下面两个例子分别对应Local mode和Registry mode：一个从个人本机开始，将高频工作流先收拢起来；另一个面向跨设备和团队协作，将共同规范纳入Registry。
▍案例一：记录工作内容&生成周报 Skill
很多人每天都会在多个Agent中处理不同任务：用Codex修改代码，用Claude Code查询日志，用Cursor补充测试。任务完成后，工作记录也随之散落在不同对话中。到周五再回头整理，常常需要翻查聊天记录、补充背景信息、合并重复事项，最终写出的周报还容易变成流水账。
这个问题可以先从本机解决：将每天如何记录、周报如何合并等习惯沉淀为一个biweekly-work-report Skill，放在Local mode中供本机Agent共用。任务结束时记录结果与影响，遇到同主题工作时合并更新，生成周报时保留进展、风险与下周计划。
使用Skill Sync将某个Agent创建的biweekly-work-report同步至所有Agent：
后续所有Agent均可使用这个Skill：
Codex：
Claude Code：
这样做无需预先准备服务端，也不必将私人工作记录同步出去。更关键的是，这并非将Skill复制一次就结束：后续在Codex中调整了周报字段，Claude Code和Cursor看到的也将是更新后的work-report。
▍案例二：文档统一格式 Skill
团队文档的问题更为典型。接口文档、技术方案、故障复盘可能由不同人、不同设备、不同Agent生成，标题层级、参数表字段、风险说明和评审清单很容易各写各的。依靠口头提醒不够稳定，复制模板又经常复制到旧版本。
这类格式规范更适合放入Registry mode。团队可将技术方案结构、API参数表字段顺序、术语写法、截图说明和评审检查项整理为一个doc-format Skill。
使用Skill Sync将AI Registry中的doc-format同步至所有多个设备的Agent：
后续不同设备的Agent均可使用这个Skill：
设备A Codex：
设备B Qoder：
规范更新后，只需维护Registry中的这一份。公司电脑、家庭电脑、新设备，以及团队成员的Agent同步后都会继续使用同一套格式。
日常维护：看status就够了
投入使用后，日常只需关注一个命令的输出：
Mode: nacos
Profile: team
Sync daemon: running (pid: 12345)
SKILL STATUS AGENTS NEXT
pdf Synced codex,claude,qoder -
review Local changes codex,claude,qoder auto-upload pending
draft Uploaded codex,claude,qoder waiting publish
block Upload blocked codex,claude,qoder Nacos draft exists; review/clear it, auto-upload will retry
triage Conflict codex,claude,qoder skill-sync resolve triage每个Skill处于什么状态、覆盖了哪些Agent、下一步该做什么——都一目了然。
状态 |
含义说明 |
|
一切正常，无需操作 |
|
Local mode下已链接到本地中心仓库 |
|
本地存在改动；开启auto-upload时daemon会自动上传，关闭时会保留在本地 |
|
已上传为草稿，等待审核或发布 |
|
本地与远端均有改动，需要你选择一个版本 |
|
远端已有草稿或审核中版本，需先在Nacos中处理；处理后将自动重试 |
遇到冲突也不必慌张，resolve命令可以选择以远端Registry、中心仓库或某个Agent的版本为准。策略默认保守——不会擅自替你做出选择，只有你明确指定了来源后才会执行。
让Skill拥有一份可信来源
多Agent并行将越来越普遍，真正需要管理的，不只是使用哪个Agent，而是这些Agent共同依赖的Skill。
更理想的方式，是将Skill纳入Registry：拥有统一入口，具备版本记录，也能在多台设备和团队成员之间共享。Local mode则提供了一个更轻量的入口，无需预先准备服务端，也能先将本机散落的Skill收拢起来。
无论从哪种方式开始，目标都是一致的：让Skill拥有一份可信来源。Agent可以更换，但Skill不应随之散落。
欢迎大家使用Nacos Skill Sync。如果在使用过程中发现任何问题，或有更好的改进建议，也欢迎随时向我们反馈。
相关链接：
- Nacos 开源地址：github.com/alibaba/nacos
- Nacos CLI：https://github.com/nacos-group/nacos-cli
- Nacos Skill Sync：https://nacos.io/skill-sync/SKILL.md