别再手动复制 Skill 了：多 Agent 时代的 Skill 管理方案

多AI Agent时代，Skill分散混乱？Nacos Skill Sync终结手动复制，用中心仓库统一管理+自动分发，效率和版本管理双双升级。

核心内容：
1. 多Agent使用下Skill分散、手动复制致版本混乱的痛点
2. 现有管理方案（Git submodule等）的不足（部分解决未闭环）
3. Nacos Skill Sync方案：中心仓库统一管理+自动分发（软链接/复制模式）

当前AI Coding的发展正处在百花齐放的时代，没有永远的王者。模型越来越强，Cursor、Claude Code、Codex轮番成为阶段性首选；再加上额度限制、响应延迟等现实问题，开发者早就习惯了“鸡蛋不放在一个篮子里”。

除了编程工具，各种通用Agent也在不断涌现，每出一个新的，总有人第一时间去尝鲜。

如今，同时使用多个AI Agent干活，一边试用刚冒出来的新工具，一边防着正在用的突然掉链子，已经成为这个时代的开发新常态。

然而，工具可以无缝切换，Skill却无法自动跟随。在Codex中更新过的Skill，Claude Code里仍是旧版，Cursor目录下还可能并存一份同名但内容迥异的副本。起初手动复制尚可忍受，时间一长便陷入混乱：哪份才是最新？该用谁覆盖谁？接入新工具时是否还要重复搬运？

其实社区早就意识到了这个问题，也涌现了不少解法。有人用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目录指向中心仓库——改一处，全部生效。环境不支持软链接的话，也可以切换到复制模式，由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的本地副本。

，后续需要跨设备共享、团队协作或版本治理时，再切到Registry mode。

▍

Registry mode：远端 Registry 统一管理

如果你手上有十几个Skill在持续迭代，或者团队里几个人都在用同一套Skill，把它们散放在各自的本地目录里，迟早会出问题——版本不一致、改了没人同步、新成员不知道去哪找。

Registry mode做的，是把Skill放进Nacos AI Registry这个统一入口：

• 可视化：控制台里浏览、搜索、查看Skill，不用再翻目录；

• 版本治理：草稿、审核、发布、回滚、label——个人能追踪每个Skill的状态，团队能把高频Skill沉淀成稳定版本；

• 跨设备同步：家里电脑和公司电脑从同一个Registry拉Skill，新设备接入不用再手动整理；

• 双向流通：远端的可以同步到本地，本地沉淀的也能推上去，不会只留在某一个人的电脑上。

一句话：

▍

Local mode：把本机 Skill 收拢成一份

Local mode更轻量——无需接入Nacos AI Registry，仅在本地构建中心仓库，并默认以软链接方式关联各Agent的Skill目录。

其核心目标是消除多Agent环境下的Skill冗余与版本不一致问题。当

。

目前会自动发现Codex、Claude、Qoder、QoderWork、Cursor、Kiro、Lingma、CoPaw、OpenClaw，以及通用的~/.agents/skills和~/.skills；其他目录也可以通过skill-sync agent add手动加入。

已经散落在各Agent目录里的Skill也可以逐步纳入中心仓库。处理单个Skill时，执行skill-sync add ，CLI会检查各Agent目录里的同名内容，并在有差异时让你选择来源；如果想批量扫描已有目录，确认范围后再执行skill-sync add --all。内容一致的会直接统一，不一致的会停下来让你选择以哪一份为准。

反过来，如果某个Skill不想再由Skill Sync管理，执行skill-sync remove ；想一次性取消全部同步，可以用skill-sync remove --all。这个操作不会删除Agent里的Skill，而是先把中心仓库内容复制回各Agent，再移除同步状态。

Local mode也可以自然升级到Registry mode。将来想升级到跨设备或团队协作，不用重新整理，绑定一个profile就能接入远端。

▍

方式一：Agent 自驱动（推荐）

我们提供了一份标准的SKILL.md，其中完整描述了nacos-skill-sync的使用规范与交互流程。只需将下方指令发送给Agent，它便会自动读取该Skill、检查本地环境并执行同步；遇到模式选择或内容冲突等需人工决策的节点时，会主动暂停并向你确认。

阅读下面的 Skill，使用它来同步我本地的 Skill：
https://nacos.io/skill-sync/SKILL.md

▍

方式二：CLI 手动操作

若希望自行控制同步流程，可通过CLI完成。

# 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 status

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复制一次就结束：后面在Codex里调整了周报字段，Claude Code和Cursor看到的也会是更新后的work-report。

▍

案例二：文档统一格式 Skill

团队文档的问题更典型。接口文档、技术方案、故障复盘可能由不同人、不同设备、不同Agent生成，标题层级、参数表字段、风险说明和评审清单很容易各写各的。靠口头提醒不稳定，复制模板又经常复制到旧版本。

这类格式规范更适合放进Registry mode。团队可以把技术方案结构、API参数表字段顺序、术语写法、截图说明和评审检查项整理成一个doc-format Skill。

规范更新后，只维护Registry里的这一份。公司电脑、家里电脑、新设备，以及团队成员的Agent同步后都会继续使用同一套格式。

用起来之后，日常只看一个命令的输出：

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、下一步该干什么——都在这了。

状态	意味着什么
Synced	一切正常，不用管
Linked	Local mode下已经链接到本地中心仓库
Local changes	本地有改动；开启auto-upload时daemon会自动上传，关闭时会保留在本地
Uploaded	已上传为草稿，等待审核或发布
Conflict	本地和远端都改了，需要你选一个版本
Upload blocked	远端已有草稿或审核中版本，需要先在Nacos里处理；处理后会自动重试

遇到冲突也不用慌，resolve命令可以选以远端Registry、中心仓库还是某个Agent的版本为准。

多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