不改一行代码，存量接口秒变MCP服务——Nacos在AI时代的架构巨变

你的订单查询接口写了3年了，一行代码没动过。突然有一天，AI Agent直接调用它查到了用户的快递状态。你看了眼日志，发现请求来源不是浏览器，不是App——是一个大模型。你的接口，被Nacos偷偷"转正"成MCP服务了。

如果你是Java/Spring Cloud生态的开发者，Nacos对你来说应该跟空气一样熟悉——服务注册、配置管理、健康检查，天天用，天天见。

但你可能没注意到，Nacos在过去一年里发生了一次定位级别的巨变：

官方定义从"更易于构建云原生应用的动态服务发现、配置管理和服务管理平台"变成了"一个易于构建AI Agent应用的动态服务发现、配置管理和AI智能体管理平台"。

注意看，关键词从"云原生应用"变成了"AI Agent应用"，从"服务管理"变成了"AI智能体管理"。

这不是改了两个字的营销话术。这背后是Nacos 3.0→3.1→3.2三个版本、横跨一年的系统性架构重构。

今天这篇文章，讲清楚Nacos在AI时代到底做了什么、为什么这么做、以及对你有什么影响。

一、为什么服务注册中心需要"进化"？

1.1 微服务时代的Nacos

在微服务时代，Nacos干的事情很纯粹：

服务A启动 → 注册到Nacos → 服务B从Nacos查到A的地址 → 调用A

核心能力：服务注册、服务发现、配置管理。 干了快10年，非常成熟。

1.2 AI Agent时代的新需求

但到了AI Agent时代，问题变了。一个AI Agent要完成任务，需要调用各种"工具"——查天气、查订单、发邮件、操作数据库。

问题来了：Agent怎么知道有哪些工具可以用？怎么知道每个工具的调用方式？怎么动态发现新上线的工具？

如果你熟悉微服务架构，你会发现——这不就是"服务发现"的翻版吗？

微服务时代：服务A要调用服务B → 去注册中心查

AI Agent时代：Agent要调用MCP工具 → 去……也应该有个注册中心查

用人话说：微服务时代，Nacos是人与服务之间的"电话簿"。AI Agent时代，Nacos要变成Agent与工具之间的"电话簿"。

逻辑完全一样，只是使用者从"微服务"变成了"AI Agent"。

二、AI Registry：三层架构设计

Nacos 3.0引入了全新的AI Registry模块，和传统的服务注册、配置管理并列，成为Nacos的三大核心能力之一。

AI Registry的架构分为三层：

2.1 模型层（Model Layer）

管理AI模型的动态参数——Prompt模板、学习率、连接配置等。

这一层复用了Nacos配置管理的分发能力。 用人话说：你用Nacos管微服务的配置（数据库连接串、开关配置），现在也能用同样的方式管AI模型的配置（Prompt模板、模型参数）。

典型场景：

• 线上Prompt模板热更新，不用重启应用
• 多模型切换（比如从GPT-4o切到Claude Fable 5），改个配置就行
• A/B测试不同Prompt版本

2.2 工具层（Tool Layer）

这是AI Registry最核心的一层——MCP Registry。

它解决的问题是：让LLM模型和MCP工具之间实现自动发现、自动注册、智能检索。

关键能力：通过智能过滤，减少传递给大模型的工具描述数量，从而降低Token消耗。

为什么这很重要？ 想象一下：如果你有200个MCP工具，每次调用都把200个工具的描述全部塞给大模型，Token费用会爆炸。MCP Registry可以根据当前任务语义，只推荐最相关的3-5个工具，其余的不传。

2.3 应用层（Application Layer）

管理Agent本身——Agent的注册、发现、协作。

从Nacos 3.1开始，支持A2A（Agent-to-Agent）协议。Agent注册到Nacos后，其他Agent可以通过名字、描述、能力标签来发现和调用它。

用人话说：微服务有服务发现，现在Agent也有Agent发现了。 你的"订单查询Agent"注册到Nacos，别人的"客服总管Agent"就能自动找到它、调用它。

三、MCP Registry：零代码让存量接口变MCP服务

这是Nacos在AI时代最实用的杀手级功能。

3.1 问题背景

大部分企业有海量的存量HTTP/RPC接口——查订单、查库存、查物流……这些接口已经跑了多年，稳得一批。

现在AI Agent需要调用这些能力。按传统方式，你需要：

1. 为每个接口写一个MCP Server适配层
2. 实现MCP协议的JSON-RPC格式
3. 部署、测试、维护

如果你有200个接口，这个工作量足够让你开始怀疑人生。

3.2 Nacos的解法：声明式零代码转换

Nacos MCP Registry支持三种注册方式：

第一种方式是真正的杀手锏。 你只需要在Nacos控制台（或通过JSON声明文件）描述一下你的HTTP接口——URL是什么、参数有哪些、返回什么格式——Nacos就会自动把它"包装"成一个标准的MCP服务。

不改一行业务代码。不部署额外服务。不需要MCP SDK。

3.3 实际效果

以"查询订单状态"接口为例：

改造前：

HTTP GET /api/orders/{orderId}/status
→ 只有前端和其他微服务能调用

在Nacos声明后：

MCP Tool: query_order_status
→ 任何AI Agent都能通过MCP协议调用
→ 大模型自动理解这个工具的用途和参数

从"只有程序员能调用"变成了"AI Agent也能调用"——且你的接口代码完全没变。

Nacos官方说这个过程可以把集成周期从数周缩短到数小时。对于有大量存量接口的企业来说，这个效率提升是数量级的。

四、MCP Router：Agent的"智能导航"

MCP Registry解决的是"工具怎么注册"的问题。MCP Router解决的是"Agent怎么找到并使用工具"的问题。

4.1 两种工作模式

4.2 Router模式的工作流程

Agent发起任务："帮我查一下用户的订单状态"
    ↓
MCP Router收到请求
    ↓
从Nacos MCP Registry获取所有已注册的MCP Server列表
    ↓
根据任务语义，智能匹配最相关的MCP Server
    ↓
返回推荐的工具列表给Agent
    ↓
Agent选择并调用具体工具

核心价值：Agent只需要对接一个MCP Server（Router本身），就能访问所有已注册的MCP工具。

这个设计思路和微服务里的API Gateway异曲同工——服务调用方不需要知道每个服务的具体地址，只需要知道网关地址就行。

4.3 Router提供的核心工具

MCP Router本身作为一个MCP Server，向Agent暴露三个工具：

用人话说：MCP Router就是Agent的"应用商店"——搜索、安装、使用，一站式搞定。

4.4 Proxy模式的价值

很多早期的MCP Server用的是stdio协议（标准输入输出），这在生产环境中有安全隐患——进程直接暴露在宿主机上。

MCP Router的Proxy模式可以：

1. 把stdio/SSE协议的MCP Server转换为Streamable HTTP协议
2. 通过Docker容器隔离运行
3. 无需修改原有MCP Server代码

安全性和可管理性一步到位。

五、A2A注册中心：Agent之间也能"互相发现"

Nacos 3.1.0引入了A2A（Agent-to-Agent）协议支持，这是继MCP之后的另一个重要能力。

5.1 MCP vs A2A

用人话说：MCP是"我需要一把锤子"，A2A是"我需要一个木匠"。 一个找工具，一个找人（Agent）。

5.2 实际场景

假设你有这些Agent：

• 订单Agent：查订单、改地址、申请退款
• 物流Agent：查物流、预估到达时间
• 客服Agent：总调度，理解用户意图后分发给对应Agent

以前，客服Agent需要硬编码知道订单Agent和物流Agent的地址。新增一个Agent？改代码、重新部署。

有了Nacos A2A注册中心：

1. 每个Agent启动时自动注册AgentCard（名称、能力描述、版本）
2. 客服Agent通过Nacos动态发现所有可用Agent
3. 支持名称搜索和模糊匹配

新Agent上线即可被发现，下线自动摘除。和微服务的服务注册发现一模一样——只是主角从"服务"变成了"Agent"。

六、Nacos 3.2：Skill管理 + Copilot

Nacos 3.2进一步扩展了AI资产管理的边界，新增了两个重要能力。

6.1 Skill管理

Skill本质上是Agent可调用的能力包——比微服务粒度更细，比单个API接口粒度更粗。

Nacos 3.2支持：

• Skill的版本管理和ZIP上传
• 命名空间隔离（多团队独立管理）
• HMAC签名防篡改——Skill发布时Nacos对内容签名，Agent运行时验证签名
• 沙箱运行——Skill在独立Docker容器中执行，只能访问授权资源

安全设计的思路很清晰：Skill是可执行的代码包，不能"裸奔"——必须签名验证+沙箱隔离。

6.2 Nacos Copilot

Nacos控制台集成了AI助手，可以在控制台内直接：

• 优化Prompt模板
• 调试和完善Skill描述
• 自然语言查询配置和服务状态

从"人管AI资产"到"AI辅助管AI资产"——套娃了属于是。

6.3 版本演进总览

一个清晰的演进路线：先让工具能被发现（MCP），再让Agent能被发现（A2A），最后让所有AI资产都能被管理（Skill/Prompt/Agent全家桶）。

七、安全架构：从"默认信任"到"零信任"

值得单独说的是Nacos 3.0在安全方面的变化，因为Nacos 2.x在安全上被诟病已久。

7.1 Nacos 2.x的安全问题

Nacos 2.x有一个著名的设计缺陷：控制台和Server共用一个端口，认证逻辑混在一起。这导致了多次安全漏洞——攻击者可以绕过控制台认证直接操作Server API。

用人话说：大门和后门用同一把锁，结果后门的锁被撬了，大门也跟着遭殃。

7.2 Nacos 3.0的安全重构

核心思路：把控制面和数据面彻底拆开，各自独立认证，互不影响。

对于AI场景来说，这个安全重构尤其重要——因为MCP Registry里存的是工具描述和API密钥，A2A Registry里存的是Agent的能力和地址。这些都是高价值目标，安全性怎么强调都不过分。

八、升级注意事项

如果你打算从Nacos 2.x升级到3.x，有几个关键点必须知道：

写在最后

Nacos从微服务注册中心到AI智能体管理平台的转变，其实揭示了一个更深层的趋势：AI Agent时代的基础设施，不是从零开始造的——而是从云原生基础设施"长"出来的。

服务注册→MCP Registry，服务发现→MCP Router，服务间调用→A2A协议——每一个AI时代的新能力，都能在微服务时代找到对应物。

这不是巧合。本质上，AI Agent面临的分布式系统问题——发现、路由、负载均衡、健康检查、安全认证——和微服务面临的问题一模一样。区别只在于：以前的使用者是程序员写的代码，现在的使用者是大模型驱动的Agent。

所以Nacos的转型逻辑非常清晰：不是"推倒重来做AI"，而是"把微服务时代积累的能力，用AI时代的协议重新封装一遍"。 零代码转MCP服务就是最好的证明——底层还是你那个HTTP接口，只是外面多了一层MCP协议的壳。

如果你是Spring Cloud生态的用户，这对你来说是个好消息——你不需要换技术栈，Nacos会帮你把存量资产接入AI时代。 你需要做的，只是升级Nacos版本，然后在控制台点几下。

一句话总结：Nacos的野心不小——它想做AI Agent时代的"基础设施层"，就像它在微服务时代做到的那样。从目前3.0到3.2的演进节奏来看，它正在一步一步兑现这个目标。

我是RiemannChow，一个在架构领域摸爬滚打多年的技术人。如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。关注「老周聊架构」，每周深度解读AI和架构的最新趋势。

— 完 —