ENZOMEGA.
Clipping 微信公众号

Nacos 3.x AI 注册中心设计解密：让 4 套协议在同一张表里和平共处

by Fox爱分享 原文 ↗
Created: 2026-07-04
#公众号文章

公众号名称：Fox爱分享

作者名称：Fox爱分享

发布时间：2026-07-04 07:00

上篇我们聊了 Distro 协议的数据同步细节，有读者问：“Nacos 3.x 加了 AI 功能，Prompt、MCP Server、A2A Agent、Skill、AgentSpecs 这些东西，到底是怎么管起来的？“官方文档写得很清楚，但源码背后的设计意图藏在更深处。这篇文章，我们把 AI 注册中心翻个底朝天。

开篇：三个悖论

悖论一：越不同，越要统一。

Prompt 是纯文本，MCP Server 是 JSON 配置包，A2A Agent 是 AgentCard，Skill 是 ZIP 二进制包，AgentSpecs 是 manifest 规范包——5 种完全不同的东西，存储格式、调用方式、版本模型各不相同。正常思路应该是”各建各的表，各管各的”。但 Nacos 偏要把它们塞进同一套元数据框架。凭什么？

悖论二：内容、地址、版本，是三种数据。

一份 Prompt 的正文是一回事，MCP Server 的可调用端点是另一回事，版本历史又是一回事——这三种数据天然不该放同一张表。但 Nacos 用两张表全接住了。怎么绕过去的？

悖论三：复用 = 偷懒？

Nacos 没有给 AI 资源发明新存储引擎。Config 模块复用，Naming 模块复用，SPI 扩展机制复用——“能复用的全复用”，是偷懒还是克制？

把这三个悖论答清楚，Nacos AI 注册中心你就吃透了。

一、统一数据模型：两张表兜住 5 套协议

Nacos AI 注册中心的核心数据结构只有两张表。

ai_resource：元数据主表，存不变的——资源类型、名称、命名空间、可见范围、业务标签。

ai_resource_version：版本明细表，每发一个新版本生成一条记录，存 JSON 格式的内容快照、发布状态、操作人。

┌──────────────────────────┐     ┌───────────────────────────────┐
│       ai_resource        │     │     ai_resource_version       │
├──────────────────────────┤     ├───────────────────────────────┤
│ id (PK)                  │───< │ resource_id (FK)              │
│ type                     │     │ version                       │
│   prompt                 │     │ content (JSON)                │
│   mcp_server             │     │ status                        │
│   a2a_agent              │     │   draft → reviewing →        │
│   skill                  │     │   reviewed → published →     │
│   agentspec              │     │   online → offline             │
│ namespace_id             │     │ gmt_create / gmt_modified      │
│ group_name               │     │ created_by                    │
│ resource_name            │     │ labels (KV)                   │
│ visibility               │     │                               │
│   private / shared /     │     │                               │
│   public                 │     │                               │
│ labels (KV)              │     │                               │
└──────────────────────────┘     └───────────────────────────────┘

type 字段是整个系统的分岔路口。

type = prompt，content 里是纯文本。type = mcp_server，content 里是 MCP JSON Schema。type = skill，content 里存 ZIP 包引用。type = agentspec，content 里是 manifest + 资源文件。

元数据操作——列表、查询、删除、权限控制——全部走通用 SQL，和 type 无关。内容解析按 type 分流，各走各的解析器。

这就是第一层抽象：统一元数据视图，分离内容存储逻辑。

二、5 类资源对比：它们到底有什么不同？

很多人分不清”MCP 管理”和”Agent 管理”的边界，也分不清”Agent”和”AgentSpecs”为什么是两件不同的事。官方文档给了全景图：

维度PromptMCP ServerA2A AgentSkillAgentSpecs
核心内容提示词文本JSON 配置包AgentCard JSONZIP 二进制包manifest + 资源文件
版本粒度每版本独立 Prompt工具/资源/端点各有版本每版本独立 AgentCard每版本独立 ZIP每版本独立 ZIP
可调用端点无HTTP/SSE/STDIOHTTP 端点无无
生命周期draft→reviewing→published→online→offlineregister→online→offlineregister→online→offlinedraft→reviewing→published→online→offlinedraft→reviewing→published→online→offline
内容存储NacosConfig (text)NacosConfig (JSON)NacosNaming (元数据)NacosConfig (binary)NacosConfig (ZIP)
Pipeline 审查✅ PublishPipelineExecutor❌❌✅ PublishPipelineExecutor❌
协议定位AI 指令模板AI 工具注册标准Agent 间通信协议AI 能力分发单元Agent 规范包

两个关键区分：

Agent ≠ AgentSpecs。 官方文档说得很清楚——Agent 管理关注的是”可调用的 Agent 入口”，告诉你怎么找到并调用一个 Agent；AgentSpecs 管理关注的是”Agent 规范包”，告诉你这个 Agent 是什么、依赖什么、怎么构建它。两者可以配合使用，但不是同一种资源。

Pipeline 只覆盖 Prompt 和 Skill。 这不是设计疏忽——Prompt 涉及内容创作，Skill 涉及代码执行，风险更高，需要审查门。Agent 和 MCP Server 更多是注册元数据，治理风险相对可控。

上图是官方文档给出的 Nacos AI 注册中心全景。 这张图的核心信息是：Nacos 不只是把 AI 资源存起来，而是在管理端提供了完整的能力治理体系。 安全审核对应 Pipeline 审查门，权限分配对应 visibility 和 namespace 隔离，版本管理对应 ai_resource_version 表，效果验证则是运行时通过 Naming 动态注入端点后的调用结果反馈。

三、共享基础设施：Config + Naming + SPI

三层共享基础设施，让 AI 注册中心不需要任何新存储引擎。

第一层：内容存储——Config 模块

不管 Prompt 文本、MCP JSON、Skill ZIP，内容全部走 Nacos Config 模块存储。

ai_resource_version.content → Config (dataId + group + namespace)

MCP Server 的内容尤其典型——它把 version info、server spec、tools spec、resource spec 分别存成 4 个独立的 Config dataId：

// McpServerOperationService.java 第 742-746 行
ConfigQueryChainRequest request = new ConfigQueryChainRequest();
request.setDataId(
    McpConfigUtils.formatServerSpecInfoDataId(mcpServerId, version)
);
request.setGroup(Constants.MCP_SERVER_GROUP);   // Group = 协议类型标识
request.setTenant(namespaceId);                  // tenant = 命名空间隔离
return request;

Group 是协议类型标识，tenant 是命名空间隔离，dataId 是具体资源 ID——这是 Config 模块在 AI 场景下的原生复用，不是打补丁。

第二层：端点注册——Naming 模块

MCP Server 和 A2A Agent 的可调用端点，不在 Config 里，而是注册进 Nacos Naming：

MCP endpoint → NacosNaming Instance (serviceName = "mcpName::version")
A2A endpoint → NacosNaming Instance (serviceName = "agentName")

MCP endpoint 的动态注入是整个设计里最精妙的地方——URL 不在注册时写死，而在查询时从 Naming 实时拉取：

// McpServerOperationService.java 第 254-269 行
private void injectBackendEndpointRef(McpServerDetailInfo detailInfo) throws NacosException {
    // 从 Naming 实时拉取 MCP Server 的实例列表
    // serviceRef 存的是 Naming serviceName，不是写死的 URL
    List instances = endpointOperationService.getMcpServerEndpointInstances(
        detailInfo.getRemoteServerConfig().getServiceRef()
    );

    // 根据传输协议（HTTP/SSE/STDIO）填充 endpoint 列表
    String protocol = detailInfo.getRemoteServerConfig()
                                 .getServiceRef().getTransportProtocol();
    List backendEndpoints = transferToMcpEndpointInfo(
        instances,
        detailInfo.getRemoteServerConfig().getExportPath(),
        protocol
    );
    detailInfo.setBackendEndpoints(backendEndpoints);
}

当 MCP Server 漂移了——IP 变了、容器重启了——Naming 自动处理健康检查和负载均衡，客户端每次查询拿到的永远是最新可用的端点列表。这是注册中心的看家本领在 AI 场景的降维落地。

第三层：审查门——Pipeline + SPI

Prompt 和 Skill 发布时需要审查，但审查标准随业务变化，不能写死。Nacos 用 PublishPipelineExecutor + SPI 实现可插拔审查链：

发布请求 → PublishPipelineExecutor → SPI 插件链（异步串行）
    ↓
任一插件 reject → 立即短路返回
通过全部插件 → 发布成功，事件异步回调通知

第四层：导入扩展——Importer SPI

Prompt 和 Skill 支持从外部导入——Git 仓库、HuggingFace、MCP 官方 Registry。导入逻辑全部走 Importer SPI，默认实现从 Nacos 内部导入，可替换为任意外部数据源。

四、完整生命周期：状态机里藏着治理哲学

官方文档给出了 AI 资源的完整状态流转：

创建草稿(draft) → 修改草稿 → 提交审核(submit)
    ↓
审核中(reviewing) → 审核通过(reviewed)
    ↓
发布(published) → 上线(online) → 下线(offline)
                                     ↓
                              重新上线(re-online)

一个重要警告： 管理员在紧急场景下可以强制发布（force publish），但这会跳过 Pipeline 校验。官方文档明确说”应当谨慎使用”——跳过审查门的内容，可能是 prompt injection，可能是恶意 Skill 包，可能是带漏洞的 MCP 工具。

强制发布不是设计漏洞，是治理弹性。但弹性越大，责任越重。

总结：AI 注册中心的 5 个核心设计

设计点方案效果
统一元数据双表模型（ai_resource + ai_resource_version）5 套协议共用一套 SQL，type 分流内容解析
内容存储Config 模块复用不引入新存储引擎，各协议独立演化
端点注册Naming 模块动态注入URL 查询时实时拉取，漂移自愈
审查门Pipeline + SPI 可插拔链审查标准随业务变化，不写死
治理弹性强制发布逃生舱紧急场景可用，但跳过校验应谨慎

最后说一句

很多人觉得 AI 注册中心”就是加了几张表”，其实里面的设计克制得非常精妙。

Nacos 3.x AI 注册中心最厉害的地方在哪？就在于它没有发明任何新东西——用 Config 存内容，用 Naming 做端点，用 SPI 做扩展，用 Pipeline 做审查门。5 套协议在元数据层看起来是同一种东西，在内容存储层各自独立演化，在端点注册层复用 Nacos 自有的 Naming，在治理扩展层靠 SPI 应对未来变化。

这种”用约束换统一”的设计思想，跟注册中心的”连接即状态”是同一个脉络——不发明新轮子，但让已有轮子跑出新赛道。

如果你觉得这篇文章有收获，欢迎转发给更多做 AI 工程的朋友。接下来三篇，我们逐个拆解 AI 注册中心的三个核心模块——Prompt 生命周期、MCP Server 端点注入、Skill 能力分发，篇篇有干货。

关注「Fox爱分享」，持续输出分布式/云原生/AI 工程硬核内容。

内容效果不满意？点此反馈

输入关键词开始搜索