你的 Skill 散落在几个地方？
Cloud Native
当前 AI Coding 的发展正处在百花齐放的时代，没有永远的王者。模型越来越强，Cursor、Claude Code、Codex 轮番成为阶段性首选；再加上额度限制、响应延迟等现实问题，开发者早就习惯了“鸡蛋不放在一个篮子里”。
除了编程工具，各种通用 Agent 也在不断涌现，每出一个新的，总有人第一时间去尝鲜。
如今，同时使用多个 AI Agent 干活，一边试用刚冒出来的新工具，一边防着正在用的突然掉链子，已经成为这个时代的开发新常态。
然而，工具可以无缝切换，Skill 却无法自动跟随。在 Codex 中更新过的 Skill，Claude Code 里仍是旧版，Cursor 目录下还可能并存一份同名但内容迥异的副本。起初手动复制尚可忍受，时间一长便陷入混乱：哪份才是最新？该用谁覆盖谁？接入新工具时是否还要重复搬运？
这种碎片化的版本管理不仅降低工作效率，更在反复确认中不断消耗人的心力。
一份 Skill，一个中心仓库
Cloud Native
其实社区早就意识到了这个问题，也涌现了不少解法。有人用 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 从“本地配置文件”变成了可追溯、可共享、可管理的 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，CLI 会检查各 Agent 目录里的同名内容，并在有差异时让你选择来源；如果想批量扫描已有目录，确认范围后再执行 skill-sync add --all。内容一致的会直接统一，不一致的会停下来让你选择以哪一份为准。
反过来，如果某个 Skill 不想再由 Skill Sync 管理，执行 skill-sync remove；想一次性取消全部同步，可以用 skill-sync remove --all。这个操作不会删除 Agent 里的 Skill，而是先把中心仓库内容复制回各 Agent，再移除同步状态。
Local mode 也可以自然升级到 Registry mode。将来想升级到跨设备或团队协作，不用重新整理，绑定一个 profile 就能接入远端。
快速上手
Cloud Native
▍方式一：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# 或者直接使用 npxnpx @nacos-group/cli@latest skill-sync --help# 2. 配置 CLI profilenpx @nacos-group/cli@latest profile edit test# 3. 添加 Skill，启动同步，查看状态npx @nacos-group/cli@latest --profile test skill-sync add pdfnpx @nacos-group/cli@latest --profile test skill-sync startnpx @nacos-group/cli@latest --profile test skill-sync status
Local mode（单机轻量同步，无需 profile）
npx @nacos-group/cli skill-sync add pdfnpx @nacos-group/cli skill-sync startnpx @nacos-group/cli skill-sync status
使用案例
Cloud Native
下面两个例子分别对应 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 就够了
Cloud Native
用起来之后，日常只看一个命令的输出：
Mode: nacosProfile: teamSync daemon: running (pid: 12345)SKILL STATUS AGENTS NEXTpdf Synced codex,claude,qoder -review Local changes codex,claude,qoder auto-upload pendingdraft Uploaded codex,claude,qoder waiting publishblock Upload blocked codex,claude,qoder Nacos draft exists; review/clear it, auto-upload will retrytriage Conflict codex,claude,qoder skill-sync resolve triage
每个 Skill 什么状态、覆盖了哪些 Agent、下一步该干什么——都在这了。
状态 | 意味着什么 |
| 一切正常，不用管 |
| Local mode 下已经链接到本地中心仓库 |
| 本地有改动；开启 auto-upload 时 daemon 会自动上传，关闭时会保留在本地 |
| 已上传为草稿，等待审核或发布 |
| 本地和远端都改了，需要你选一个版本 |
| 远端已有草稿或审核中版本，需要先在 Nacos 里处理；处理后会自动重试 |
遇到冲突也不用慌，resolve 命令可以选以远端 Registry、中心仓库还是某个 Agent 的版本为准。策略默认保守——不会擅自替你做选择，你明确指定了来源才会执行。
让 Skill 有一份可信来源
Cloud Native
多 Agent 并行会越来越常见，真正需要管理的，不只是用哪个 Agent，而是这些 Agent 共同依赖的 Skill。
更理想的方式，是把 Skill 放进 Registry：有统一入口，有版本记录，也能在多台设备和团队成员之间共享。Local mode 则提供了一个更轻的入口，不需要先准备服务端，也能先把本机散落的 Skill 收拢起来。
无论从哪种方式开始，目标都是一样的：让 Skill 有一份可信来源。Agent 可以换，Skill 不应该跟着散。
