上周刷 GitHub 的时候，看到 Nacos 发布了 3.2.0-BETA 版本。

我下意识地以为又是一个常规迭代——修了几个 Bug，优化了点性能，跟我们普通开发者关系不大。

结果点进去一看，我愣住了。

Nacos 居然变成了一个 AI 资源治理平台？

从 1.x 的服务注册发现，到 2.x 的配置灰度管理，再到 3.x 的 MCP Registry、Agent Registry、Prompt Registry、Skill Registry……

这哪是版本升级，这是换了个赛道啊。

作为一个用了三年 Nacos 的老用户，我花了一下午时间把 3.x 的更新文档翻了个遍，总结出了 5 个最重要的变化。

不管你是准备升级，还是纯好奇，这篇文章都值得看完。

---

02 变化一：AI Registry —— 四合一的资源治理

Nacos 3.x 最大的变化，就是在原有的「服务注册」和「配置管理」之外，新增了一套完整的 AI Registry。

什么是 AI Registry？

简单来说，就是把企业里所有跟 AI 相关的资源，统一纳管到 Nacos 里。包括四类：

资源类型	作用	类比理解
MCP	模型上下文协议，标准化工具接入	API 网关
Agent	AI 智能体，承载任务与工作流	微服务实例
Prompt	驱动 Agent 的指令模板	配置文件
Skill	可复用的能力包，封装具体动作	公共组件

重点说说 Skill Registry。

Skill 本质上是 Agent 可调用的能力包——检索文档、调用 API、执行脚本等等。以前这些 Skill 散落在各个团队的 Git 仓库里，没有统一的管理入口。

Nacos 3.2 的 Skill Registry 解决了这个问题：

• 支持 Skill 的注册、更新、版本管理
• 支持 ZIP 包上传下载，批量导入导出
• 支持命名空间隔离，多团队互不干扰
• 和配置、服务一样，具备完整的生命周期管理

对我们普通开发者的意义：

如果你的团队正在做 AI 相关的项目，Nacos 3.x 可以成为统一的 AI 资产管理平台，不用再自己造轮子了。

---

03 变化二：MCP Registry —— 存量 API "0改动"接入 AI

这是我觉得最实用的功能。

背景：

MCP（Model Context Protocol）最近火得不行。Cursor、Windsurf、OpenAI 都在支持，国内百度地图、高德地图也发布了 MCP Server。

但问题也来了——企业里已有的 HTTP API，怎么改造成 MCP Server？

每个接口重写一遍？成本太高了。

Nacos 的解法：

通过 MCP Registry + Higress AI 网关，实现存量 API "0代码改动"升级到 MCP 协议。

原理很简单：

1. Nacos 里已经有服务的注册信息和地址
2. 只需要补充接口的描述信息（接口名、参数、作用）
3. Higress 网关自动把 HTTP 请求转换成 MCP 协议的 JSON RPC
4. 对外暴露标准的 MCP Server 接口

[Agent/大模型] --MCP协议--> [Higress网关] --HTTP--> [你的存量服务]
                              ↑
                        [Nacos 管理 Tool 元信息]

举个例子：

你们有一个查询订单状态的接口 /api/order/status，以前是给前端调用的。现在通过 Nacos MCP Registry，不用改一行代码，大模型就能直接调用这个接口来查询订单状态。

这意味着什么？

存量业务系统接入 AI 的成本，从「 weeks 」降到了「 hours 」。

---

04 变化三：Nacos Copilot —— 控制台里塞了个大模型

Nacos 3.2 直接在控制台里集成了 AI 能力，叫 Nacos Copilot。

基于 agentscope-java 框架接入大模型，可以在控制台内完成：

• Prompt 优化：对 Prompt 模板进行结构化优化，提升清晰度和可执行性
• Skill 优化：对 Skill 的描述、指令给出改进建议
• 全流程闭环：编辑 → 优化 → 发布，不用切出控制台

我的看法：

这个功能现在还比较初级，主要是 Prompt 和 Skill 的优化。但方向很明确——Nacos 正在从「人工管理平台」进化成「AI 辅助管理平台」。

后续如果延伸到配置管理、服务治理场景，想象空间很大。

---

05 变化四 & 五：nacos-cli + nacos-setup —— 运维体验大升级

这两个工具解决的是同一个痛点：Nacos 的安装和运维太麻烦了。

nacos-setup：一键安装

以前部署 Nacos，要下载安装包、改配置、调端口、处理 Java 版本……新手能折腾一整天。

现在一条命令搞定：

# Linux / macOS
curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash
sudo nacos-setup -v 3.2.0-beta

# Windows
iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 | iex

支持单机模式和集群模式，还能模拟滚动升级：

# 启动3节点集群
nacos-setup -c prod -n 3 -v 3.2.0-beta

nacos-cli：命令行操作

以前改个配置、查个服务，必须登录控制台点鼠标。

现在可以用命令行：

# 查询配置
nacos-cli config get --dataId example.yaml --group DEFAULT_GROUP

# 发布 Skill
nacos-cli skill upload --file skill.zip --namespace dev

# 查询 Prompt
nacos-cli prompt get --key order-analysis

对 CI/CD 和自动化流水线非常友好。

---

06 升级前必看：这些坑别踩

坑一：Java 版本要求

版本	Java 要求
Nacos 2.x	Java 8+
Nacos 3.x	Java 17+

如果你的项目还在用 Java 8 或 11，升级 Nacos 3.x 之前，先把 JDK 版本搞定。

坑二：Server 和 Console 拆分部署

Nacos 3.0 开始，控制台（Console）和引擎（Server）支持拆分部署。

好处：

• 控制台可以独立升级，不影响核心服务
• 安全隔离更好

注意：

• 如果是从 2.x 升级，需要处理新旧命名空间的兼容问题
• 部署架构变了，运维脚本可能需要调整

坑三：3.2 还是 Beta

目前 3.2.0 是 BETA 版本，不建议直接上生产环境。

建议策略：

• 本地/测试环境先用起来，熟悉新特性
• 生产环境继续用 2.5.x（最新稳定版）
• 等 3.2 GA 后再考虑迁移

---

07 我的看法：Nacos 为什么要拥抱 AI？

可能有人会问：一个服务注册中心，好好做注册发现不行吗？搞什么 AI？

我理解的原因有两个：

第一，云原生基础设施已经卷到头了。

服务发现、配置管理、灰度发布……这些功能 Nacos 已经做得很成熟了。继续在这个赛道内卷，边际收益越来越低。

第二，AI 应用架构确实需要一个新的"注册中心"。

传统的微服务架构里，服务是固定的、有明确接口的。但 AI 架构里：

• Agent 是动态的、自治的
• MCP Server 是描述驱动的、不是代码驱动的
• Prompt 和 Skill 是需要版本管理和灰度发布的

这些 AI 资源的治理需求，和传统微服务不一样。

Nacos 选择在这个时候切入，是在抢占"AI 时代基础设施"的生态位。

---

08 总结：不同场景怎么选？

场景	推荐版本	理由
传统微服务，稳定优先	Nacos 2.5.x	稳定、成熟、Java 8 兼容
准备接入 AI，存量 API 改造	Nacos 3.0+	MCP Registry 是刚需
尝鲜新特性，本地开发	Nacos 3.2 BETA	AI Registry、Copilot 体验
生产环境升级	等 3.2 GA	Beta 版本不要上生产

---

09 写在最后

从 Nacos 的演进可以看出一个趋势：

基础设施软件正在全面拥抱 AI。

不只是 Nacos，Elasticsearch 推出了 AI 搜索、MongoDB 推出了 Vector Search、Redis 推出了 RedisVL……

作为后端开发者，我们需要关注的不只是 CRUD 和接口性能，还要理解 AI 时代的架构变化。

因为技术栈不会等你准备好了才变。