企业官网建设流程全解析

Nacos AI Registry 规范解析：面向 AI 云原生应用的资源注册、治理与分发域

【免费下载链接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.项目地址: https://gitcode.com/GitHub_Trending/na/nacos

AI Registry 是 Nacos 3.x 中与 Config、Naming 并列的一等公民能力域，专门用于对 AI 资源（MCP Server、Agent、Prompt、Skill、AgentSpec）进行注册、治理、发现与分发。本文以 AI Registry Spec 为骨架，结合仓库中的源码与关联规范（AI Resource Model Spec、AI Resource Lifecycle Spec）展开讲解。读完本文，你将掌握 AI Registry 的领域边界、标准资源模型、资源类型清单、接口面划分、生命周期治理规则以及插件化横切机制的完整设计。

1. AI Registry 是什么：领域定位与边界

AI Registry 是 Nacos 中用于注册、治理、发现和分发 AI 资源的领域能力，与 Config（配置）和 Naming（服务发现）并列，是 Nacos 3.x 的一等公民能力。它复用了共享的资源身份namespaceId -> resourceType -> resourceName，该身份模型定义于 Resource Model Spec。

1.1 AI Registry 拥有什么

从规范第 1 节可以看到，AI Registry 拥有以下内容：

• AI 资源元数据与版本：包括版本、标签（labels）、状态、可见范围（scope）、属主（owner）和业务标签（biz tags）；
• 资源类型契约：为 MCP Server、Agent、Prompt、Skill、AgentSpec 五类资源定义类型契约；
• 运行时查询与订阅行为：面向受支持的 AI 资源的运行时查询和订阅能力；
• 管理工作流：草稿创建（draft）、评审（review）、发布（publish）、强制发布（force publish）、上下线（online/offline）、删除（delete）、上传（upload）、导入（import）和下载（download）；
• 领域级插件使用：对发布流水线（publish pipeline）、存储插件（storage plugins）、可见性（visibility）、鉴权（auth）和追踪（trace）钩子的领域级使用。

1.2 AI Registry 不拥有什么

同样重要的是理解领域边界，AI Registry不拥有以下内容：

• Config 资源语义：即使默认 AI 存储实现通过 Config 存储资源内容，Config 的资源语义也不属于 AI Registry；
• Naming 服务语义：即使 MCP 或 Agent 端点通过 Naming 服务和实例来表示，Naming 的语义也不属于 AI Registry；
• 社区注册表协议定义：由 AI Registry Adaptor Spec 定义的外部社区注册表协议不在本域范围内；
• 插件扩展契约：流水线、存储、资源导入、可见性和追踪的扩展规则由各自的插件规范定义。

从源码角度，该边界在模块划分上体现得非常清晰：AI Registry 的业务实现集中在ai/src/main/java/com/alibaba/nacos/ai/，其中model/目录存放AiResource与AiResourceVersion实体，storage/目录存放基于 Config 的默认存储实现，service/目录按mcp/、agent/、skills/、agentspec/等类型拆分为独立的操作服务。

2. 设计原则：版本优先、运行时与管理分离

AI Registry 遵循五项核心设计原则：

1. 版本优先（Version first）：标准模型基于AiResource元数据和AiResourceVersion不可变或受治理的版本。新增资源类型应先适配该模型，而不是引入自定义存储形态。
2. 运行时与管理分离（Runtime and management separation）：Client API 和 SDK 暴露运行时查询、端点注册和订阅；Admin、Console 和 Maintainer SDK 承担广泛列表、上传、发布治理和删除。
3. 资源身份稳定（Resource identity stability）：resourceType是第二层身份。除非存在兼容性路径要求，AI 资源不应引入 Config 风格的groupName身份。
4. 插件组合（Plugin composition）：可见性、存储、追踪和发布流水线行为通过插件组合，并从本领域规范链接到对应插件规范。外部资源导入应复用同一插件模型，将导入产物路由回资源操作器（resource operators），而不是重新定义一个隐藏的 AI 专属扩展机制。
5. 快速演进容忍（Fast evolution tolerance）：AI 协议和资源格式变化很快，当 MCP、A2A、Agent 打包或模型-工具生态发生变化时，规范可能需要不兼容或主版本修订。此类修订必须按照 Compatibility And Deprecation Spec 说明迁移、兼容和废弃行为。

3. 标准 AI 资源模型：元数据行 + 版本行

AI Registry 的目标标准模型是一个两行模型：

AiResource(namespaceId, type, name) -> AiResourceVersion(namespaceId, type, name, version)

在源码中，这两个实体分别对应ai/src/main/java/com/alibaba/nacos/ai/model/AiResource.java和ai/src/main/java/com/alibaba/nacos/ai/model/AiResourceVersion.java。

3.1 AiResource：元数据行

AiResource是元数据行，包含资源名称、类型、描述、启用状态、命名空间、属主、可见范围、业务标签、来源、乐观锁metaVersion、下载计数和versionInfoJSON。对应源码字段如下（均为@since 3.2.0）：

值得注意的是，AiResource继承了com.alibaba.nacos.plugin.visibility.model.VisibilityResource，并实现了getResourceName()与getResourceType()，这说明可见性控制直接内嵌在元数据实体中，与 Visibility Plugin Spec 的插件模型衔接。

name、type、namespaceId是身份字段，不能作为普通元数据被修改。

3.2 AiResourceVersion：版本行

AiResourceVersion是版本行，包含作者、版本、版本状态、描述、存储 JSON、发布流水线信息和下载计数：

规范要求：已发布内容默认按不可变处理；如果某类型必须允许内容变更，其类型规范必须定义精确的安全规则。

3.3 versionInfo JSON：资源级版本摘要

AiResource.versionInfo保存资源级的版本治理摘要，包含四个关键字段：

关键约束：

• 一个资源最多同时存在一个editingVersion和一个reviewingVersion；当存在其他工作版本时，新建草稿必须失败，除非类型规范显式定义了覆盖行为；
• 标签不得指向草稿或评审中版本；
• 运行时客户端可以通过显式版本、标签或类型特定的latest默认值查询。

在源码中，工作版本（working version）约束有明确的并发控制：ai/src/main/java/com/alibaba/nacos/ai/constant/AiResourceConstants.java定义了MAX_WORKING_VERSION_RETRY = 3，用于 CAS 元数据更新操作的重试上限，防止多操作者并发创建草稿。

4. 资源类型清单：五大类型与兼容性布局

规范第 4 节给出了 AI Registry 的资源类型清单：

此外，A2A AgentCard 是agent版本内部的协议绑定。历史a2a资源身份和 API 是由 A2A Agent Spec 描述的兼容性门面（facade），不得创建第二个规范的 Agent 身份。

源码中的类型常量与路由定义可在ai/src/main/java/com/alibaba/nacos/ai/constant/AiResourceConstants.java（RESOURCE_TYPE_SKILL、RESOURCE_TYPE_PROMPT、RESOURCE_TYPE_MCP）以及ai/src/main/java/com/alibaba/nacos/ai/constant/Constants.java（各类型的ADMIN_PATH/CLIENT_PATH）中确认。

4.1 类型特化的存储与端点规则

不同类型在存储细节上有明确的特化规则（见 AI Resource Model Spec 第 5 节）：

• Agent：type=agent时，ext包含目录扩展和派生的在线版本目录，版本storage指向一个完整的 Agent 版本内容对象。Agent 运行时端点不存储在AiResourceVersion.storage，因为它们遵循客户端拥有的 Naming 生命周期。
• MCP：规范名称是mcpName。资源ext只存储 schema 版本和已废弃的 UUID 形态mcpId物理存储及遗留 API 别名。版本storage描述符通过白名单mcp-config-v1键格式指向现有 MCP Server 及可选的 Tools/Resources Config 对象，不复制、不改写、不扩展这些负载，也不把它们变成用户拥有的 Config 资源。精确字段定义见 MCP Server Spec 及 mcp-resource-ext schema 和 mcp-version-storage schema。
• MCP 运行时端点同样不存储在版本storage中，而是使用客户端拥有的 Naming 运行时状态。MCP 普通 Service Ref 仍归其 Naming 用户所有；MCP Direct 持久化 Naming Service 仍是当前端点事实和兼容性服务契约，生命周期托管期间不会用 Version Config 快照替代它。

5. 接口面：Client / Admin / Console / gRPC / SDK

AI Registry 通过多个接口面暴露能力。规范第 5 节的接口面划分如下：

这些路由在源码中有精确对应。ai/src/main/java/com/alibaba/nacos/ai/constant/Constants.java定义了核心路径常量，例如：

• MCP_ADMIN_PATH = "/v3/admin/ai/mcp"、MCP_CLIENT_PATH = "/v3/client/ai/mcp"、MCP_CONSOLE_PATH = "/v3/console/ai/mcp"；
• AI_RESOURCE_SEARCH_CLIENT_PATH = "/v3/client/ai/resources/search"；
• AI_RESOURCE_IMPORT_ADMIN_PATH = "/v3/admin/ai/import"；
• Agent.ADMIN_PATH = "/v3/admin/ai/agents"、Agent.CLIENT_PATH = "/v3/client/ai/agents"；
• Skill.ADMIN_PATH = "/v3/admin/ai/skills"、Skill.CLIENT_PATH = "/v3/client/ai/skills"；
• AgentSpecs.ADMIN_PATH = "/v3/admin/ai/agentspecs"、AgentSpecs.CLIENT_PATH = "/v3/client/ai/agentspecs"；
• Prompt.ADMIN_PATH = "/v3/admin/ai/prompt"、Prompt.CLIENT_PATH = "/v3/client/ai/prompt"。

对应的 Controller 全部位于ai/src/main/java/com/alibaba/nacos/ai/controller/，包括McpAdminController、McpClientController、AgentAdminController、AgentClientController、SkillAdminController、SkillClientController、PromptAdminController、PromptClientController、AgentSpecAdminController、AgentSpecClientController、A2aAdminController、PipelineAdminController、AiResourceImportAdminController和AiResourceSearchClientController。这些控制器都通过@NacosApi标注并统一使用 v3 的Result/Page响应模型。

以McpAdminController（映射Constants.MCP_ADMIN_PATH，即/v3/admin/ai/mcp）为例，其端点完整覆盖了生命周期管理面：

GET /versions 版本列表 GET /version 版本详情 POST /draft 创建草稿 PUT /draft 更新草稿 DELETE /draft 删除草稿 POST /submit 提交评审 POST /publish 发布 POST /force-publish 强制发布 POST /redraft 重新草稿化 POST /online 上线 POST /offline 下线 PUT /labels 更新标签

6. 横切规则：v3 协议、可见性与插件组合

规范第 6 节定义了 AI Registry 必须遵守的横切规则：

• AI Registry API 必须遵守 HTTP API Spec 中的 v3 响应、错误、鉴权和 API 类型规则；
• gRPC 负载必须遵循 gRPC API Spec；
• 运行时查询和订阅应优先使用版本或标签路由，而不是宽泛的资源列表；
• 可见性必须使用 Visibility Plugin Spec；
• 发布流水线扩展行为必须使用 AI Publish Pipeline Plugin Spec；
• 资源存储扩展行为必须使用 AI Storage Plugin Spec；
• 外部 AI 资源导入行为必须使用 AI Resource Import Plugin Spec。导入插件把操作者配置的外部来源转换为导入产物；资源操作器把产物应用到当前存储和生命周期模型；
• 追踪与审计事件应使用 Trace Plugin Spec 和共享的可观测性规则。

6.1 存储插件 SPI：以代码印证插件化存储

存储扩展的 SPI 定义在plugin/ai/src/main/java/com/alibaba/nacos/plugin/ai/storage/spi/AiResourceStorage.java。该接口注释明确指出其定位：类似 Nacos 的多数据源/多存储实现，每个存储提供方实现该接口，只关心如何按键读写，为通用 AI 资源（Skill、Prompt 等）设计。接口方法如下：

public interface AiResourceStorage extends PluginConfigSpec { String type(); // 存储提供方类型，如 "nacos_config"、"oss" void save(StorageKey storageKey, byte[] content) throws NacosException; byte[] get(StorageKey storageKey) throws NacosException; void delete(StorageKey storageKey) throws NacosException; }

默认实现是ai/src/main/java/com/alibaba/nacos/ai/storage/NacosConfigAiResourceStorage.java，其type()返回nacos_config。save()方法把内容写入 Config：构造ConfigForm、通过configOperationService.publishConfig发布（遇到ConfigAlreadyExistsException时转为更新）、并调用SyncEffectService同步生效；get()通过ConfigQueryChainService查询链读取内容；delete()通过configOperationService.deleteConfig删除。它还在ConfigPersistContext.withSkipHistory()守卫下写入，跳过 Config 历史记录——这正是"AI 资源内容虽然存储在nacos_config中，但不得被视为用户拥有的 Config 资源"这一领域边界的实现证据。

AiResourceVersion.storage字段持久化每个版本选中的存储提供方。有效提供方配置只在写入新版本时生效；已有版本的读取、草稿替换和删除必须路由到其持久化的提供方。不带提供方的遗留存储描述符属于nacos_config。默认存储提供方通过配置键nacos.ai.storage.provider（定义于Constants.java的AI_STORAGE_PROVIDER_CONFIG_KEY）选择。

6.2 可见性规则

AI Resource Model Spec 第 6 节明确了可见性实现规则：

• 创建操作应通过配置的可见性服务解析默认范围；
• 读取操作在资源存在但调用者不可见时应返回 not found；
• 写操作在元数据、版本或范围变更前必须检查写可见性；
• 查询操作应尽可能使用可见性查询建议（visibility query advice），而不是对大规模结果集做后置过滤；
• 调用者提供的业务过滤条件（如 owner、scope）必须在计数和分页前与可见性查询建议求交集；类型实现不得在转换后覆盖可见性条件。

7. 生命周期：草稿 → 评审 → 发布 → 上下线

AI Resource Lifecycle Spec 定义了版本化 AI 资源的通用生命周期规则，类型规范可以细化这些规则。

7.1 状态模型

元数据状态：

版本状态：

这些状态常量在源码中有完整定义：ai/src/main/java/com/alibaba/nacos/ai/constant/AiResourceConstants.java包含META_STATUS_ENABLE、META_STATUS_DISABLE、VERSION_STATUS_ONLINE、VERSION_STATUS_DRAFT、VERSION_STATUS_REVIEWING、VERSION_STATUS_REVIEWED、VERSION_STATUS_OFFLINE。

7.2 标准流程

create/upload draft -> update draft -> submit -> reviewing -> reviewed -> publish -> online -> offline/online toggle or delete

• 如果未启用发布流水线，或没有流水线节点匹配该资源类型，submit可以根据类型实现直接发布；
• force-publish绕过流水线校验，必须保持为管理操作。它只接受draft、reviewing、reviewed版本；online和offline版本必须被拒绝。

7.3 草稿规则

• 一个资源应最多存在一个工作草稿，除非类型规范定义了覆盖或多草稿行为；
• 草稿创建可以新建元数据行，也可以从在线版本派生（fork）；
• 草稿更新只能修改当前草稿版本；
• 删除草稿会清除元数据editingVersion指针，并删除草稿版本行和存储内容；
• 上传操作可以类型特化，但除非是显式的 bootstrap/import 操作，否则仍应产出草稿版本。

7.4 评审与发布规则

提交（submit）的核心规则：

• submit 解析显式版本、当前editingVersion，或处于reviewing/reviewed状态的reviewingVersion；
• 没有草稿、评审中或已评审目标时，submit 必须失败；
• submit 接受draft、reviewing、reviewed状态的目标版本：draft和reviewed目标进入评审/直接发布流程（reviewed目标视为重新提交，不得绕过流水线进入发布流程）；reviewing目标是幂等 no-op，返回当前版本而不启动新的流水线；
• 留在reviewing版本上的当前终态流水线结果（APPROVED或REJECTED）被视为中断的完成转换，重新提交前归一化为reviewed；标记为historical=true的结果属于上一评审周期，不得完成当前评审；
• 对online或offline版本调用 submit 必须返回INVALID_PARAM，且不得变更版本状态或元数据指针；
• 评审中版本必须记录到元数据reviewingVersion；
• 流水线执行状态可以写入publishPipelineInfo和pipeline_execution；
• 审批通过和拒绝的流水线结果都会把版本移到reviewed；被拒绝后如需继续编辑，用户必须显式执行 redraft（重新草稿化）。

发布（publish）的核心规则：

• publish 把版本移到online、清除工作指针、必要时递增onlineCnt，服务端按资源类型规范管理latest标签；
• 当资源类型维护独立的兼容性服务投影时，生命周期行是持久化的期望状态，投影收敛跟随生命周期变更，操作只有在投影验证通过后才报告成功；收敛失败保留生命周期行，以便幂等重试或 reconciler 完成投影；
• publish 和 force-publish 请求可以保留历史updateLatestLabel参数用于兼容，该参数已废弃，新客户端不得发送；当它缺失或为true时，发布版本成为服务端管理的 latest 版本。标签更新 API 必须忽略客户端提供的latest标签键，并把当前服务端管理的latest值合并回有效标签映射；
• force publish 应用与 publish 相同的成功状态转换，但跳过流水线审批检查；
• 除非类型规范定义了确定性的细化规则，成功的 publish 或 online 操作使目标版本成为latest。当前 latest 版本被删除或下线时，默认替代是剩余在线版本中最大的版本；若无在线版本剩余，服务端移除latest。

latest 回退的确定性：规范针对不同资源类型给出了明确的回退策略。MCP 类型选择最大 SemVer，其次最大数字形态vN，再次最大大小写敏感的稳定字符串。Agent 类型仅对遗留 A2A 直接上线门面做特化（setAsLatest=false可能保留当前有效指针），标准 Agent publish/online 操作仍会移动latest。

7.5 从源码看标准生命周期实现

以 Skill 为例，ai/src/main/java/com/alibaba/nacos/ai/service/skills/SkillOperationServiceImpl.java完整实现了上述流程，其公开方法与方法名一一对应：

createDraft(namespaceId, name, basedOnVersion, ...) // 创建草稿（可基于版本 fork） updateDraft(namespaceId, skill, commitMsg) // 更新草稿 deleteDraft(namespaceId, name) // 删除草稿 submit(namespaceId, name, version) // 提交评审 publish(namespaceId, name, version, updateLatestLabel) forcePublish(namespaceId, name, version, ...) // 强制发布 redraft(namespaceId, name, version) // 重新草稿化 updateLabels(namespaceId, name, labels) // 更新标签 updateBizTags(namespaceId, name, bizTags) // 更新业务标签 changeOnlineStatus(namespaceId, name, scope, version, ...) // 上下线 updateScope(namespaceId, name, scope) // 更新可见范围 deleteSkill(namespaceId, skillName) // 删除资源

submit的注释与实现精确对应规范流程：解析目标版本 → 移动状态到reviewing→ 检查发布流水线是否可用，可用则异步运行，否则直接发布。实现中通过resourceManager.resolveSubmitTarget解析目标、isReviewingVersion判断幂等 no-op、moveToReviewing移动状态、publishPipelineExecutor.isPipelineAvailable判断流水线可用性，最后runPipelineExecution异步执行流水线，启动失败时回退直接发布。

Agent 侧的同类实现位于ai/src/main/java/com/alibaba/nacos/ai/service/agent/AgentOperationService.java，提供createDraft、submit、publish、forcePublish、redraft、updateLabels、deleteDraft、deleteAgent等操作。MCP 侧的生命周期实现位于ai/src/main/java/com/alibaba/nacos/ai/service/mcp/，其中McpLifecycleOperationService的online/offline操作通过requireVersionStatuses对版本状态做前置校验。

7.6 标签规则

• latest是保留的默认标签，指向最新已发布版本；
• latest由服务端管理。手动标签更新请求可以包含latest用于兼容，但服务端必须忽略客户端提供的latest值，并把当前服务端管理的latest值合并进有效标签；
• 标签映射到版本字符串，不得指向draft或reviewing版本；
• 更改标签本身不会变更版本内容或版本状态；
• 按标签的运行时查询必须在请求时解析标签。

7.7 删除规则

删除是 AI Registry 中安全性要求最高的一类操作：

• 删除版本应移除版本行和该版本类型拥有的存储；
• 删除资源应移除元数据、所有版本行和所有类型拥有的存储；
• 资源删除在变更元数据之前必须加载每个 Version 的 storage 描述符。存储清理必须路由到每个描述符中持久化的提供方，并尝试清理所有被引用的内容对象；
• 加载完所有描述符后，类型可以先把自己的 Resource 和 Versions 移到非服务状态，再收敛外部兼容性投影并开始物理清理。保留的行是清理完成前的持久化重试锚点；
• 元数据和版本行只有在所有引用的存储内容成功清理后才能删除。任一次清理失败，删除操作必须报告失败并保留用于重试的行和描述符；
• 删除操作只有在公开 API 契约规定"缺失资源视为成功"时才应幂等；
• 删除在线版本应在类型实现支持时更新onlineCnt或标签；
• MCP 拥有的 Direct Naming 清理和 MCP Version Config 清理使用同样的行保留规则：任一失败都报告删除未完成并保留 Resource/Version 行和描述符用于重试。普通被引用的 Services 和客户端拥有的 Runtime 状态不是类型拥有的清理目标。

8. 追踪与计数器

AI 资源操作应为以下事件发出追踪/审计事件：创建草稿、更新草稿、提交、评审通过/拒绝、发布、强制发布、上下线、删除、标签更新、描述更新、范围更新和下载。

关键实现约定：

• 追踪插件行为由 Trace Plugin Spec 定义；计数器是诊断用途，不得定义鉴权或生命周期状态；
• AI 资源追踪事件使用AiResourceTraceEvent；
• 默认 AI 资源追踪插件把 JSON 行审计日志写入ai-resource-trace.log，同时允许外部追踪订阅者消费相同事件。

9. 迁移与演进：从兼容到标准模型的路径

规范第 7 节明确了 AI Registry 的迁移与演进事项：

1. MCP 迁移遵循 MCP Server Spec 中的异步单向管理过渡SYNCING -> LIFECYCLE_MANAGED：创建 Resource/Version 指针而不改变 Config 字节或 Naming，等待零差异调和和每个成员的治理能力，切换后继续维护历史 Manifest 和当前端点服务布局。生产行为在该契约实现并验证前保持待定（pending）。
2. 历史 A2A AgentCard 和 Naming 端点数据必须通过滚动升级计划迁移到 Agent 模型；遗留 API 保持为投影（projections），不是独立的资源存储。
3. Prompt有从遗留 Config 形态 Prompt 数据迁移到标准 AI 资源模型的路径；遗留映射必须保持为兼容性存储，而不是正式的 Config 资源语义。
4. RAD 返回确定性的端点集合。健康过滤、优先级/权重选择和负载均衡是客户端侧策略，不改变 Registry 快照。
5. AI 资源 schema 和协议特定负载可能随着上游 MCP、A2A 和 Agent 打包生态的演进需要主版本修订。

从仓库现状看，迁移代码已有落地：ai/src/main/java/com/alibaba/nacos/ai/config/PromptDataMigrationTask.java实现了遗留 Prompt 数据向标准模型的迁移任务，其中定义了VERSION_STATUS_ONLINE = "online"等兼容常量。仓库还提供了AiResourceIndexBackfillTask、AiResourceIndexTaskConsumer等搜索索引回填组件，以及AiResourceSearchConfigurationValidator等配置校验器，支撑 AI 资源检索的索引化。

10. 相关规范地图与延伸阅读

AI Registry 不是孤立的领域，它与以下规范紧密关联，建议按需深入：

• 资源模型与生命周期：AI Resource Model Spec、AI Resource Lifecycle Spec、Resource Model Spec
• 类型规范：MCP Server Spec、Agent Management Spec、Agent Storage Spec、Prompt Spec、Skill Spec、AgentSpec Spec、A2A Agent Spec
• 接口与协议：HTTP API Spec、gRPC API Spec、Java SDK Implementation Spec、AI Registry Adaptor Spec
• 插件契约：AI Publish Pipeline Plugin Spec、AI Storage Plugin Spec、AI Resource Import Plugin Spec、Visibility Plugin Spec、Trace Plugin Spec
• 兼容与废弃：Compatibility And Deprecation Spec

11. 总结

AI Registry 是 Nacos 面向 AI 云原生应用的资源治理中枢，其核心设计可以概括为：

• 两行模型：AiResource（元数据行）+AiResourceVersion（版本行），以namespaceId -> resourceType -> resourceName为统一身份；
• 五类资源：MCP Server、Agent、Prompt、Skill、AgentSpec，各有明确的存储形态与兼容性布局；
• 接口面分离：/v3/client/ai、/v3/admin/ai、/v3/console/ai、gRPC 与双 SDK 各司其职；
• 受治理的生命周期：draft -> reviewing -> reviewed -> online/offline全流程，配合latest服务端标签管理与严格的删除安全规则；
• 插件化横切：存储、可见性、发布流水线、导入与追踪全部通过插件组合，领域规范只定义行为如何反应到生命周期。

从源码到规范的双重视角可以看到，AI Registry 的设计始终贯彻"版本优先"与"运行时/管理分离"原则，在快速演进的 AI 生态与稳定的基础设施能力之间建立了清晰的边界。对于需要把 MCP 服务、Agent、Prompt、Skill 等 AI 资产纳入统一注册、评审、发布与发现体系的应用，AI Registry 提供了完整且可扩展的治理范式。

【免费下载链接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.项目地址: https://gitcode.com/GitHub_Trending/na/nacos