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/nacosAI 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 RegistryNaming 服务语义即使 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 遵循五项核心设计原则版本优先Version first标准模型基于AiResource元数据和AiResourceVersion不可变或受治理的版本。新增资源类型应先适配该模型而不是引入自定义存储形态。运行时与管理分离Runtime and management separationClient API 和 SDK 暴露运行时查询、端点注册和订阅Admin、Console 和 Maintainer SDK 承担广泛列表、上传、发布治理和删除。资源身份稳定Resource identity stabilityresourceType是第二层身份。除非存在兼容性路径要求AI 资源不应引入 Config 风格的groupName身份。插件组合Plugin composition可见性、存储、追踪和发布流水线行为通过插件组合并从本领域规范链接到对应插件规范。外部资源导入应复用同一插件模型将导入产物路由回资源操作器resource operators而不是重新定义一个隐藏的 AI 专属扩展机制。快速演进容忍Fast evolution toleranceAI 协议和资源格式变化很快当 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.javanamespaceId命名空间隔离边界namespaceIdtype资源类型mcp、agent、prompt、skill、agentspectypename稳定的资源名称namedesc资源描述descstatus元数据状态enable或disablestatusowner创建者或属主身份继承自VisibilityResourcescope可见范围PUBLIC或PRIVATE继承自VisibilityResourcebizTags用于过滤或 UI 分组的业务标签bizTagsext资源类型拥有的扩展 JSONextfrom引导bootstrap、导入import或同步sync的来源标记fromversionInfoJSON 治理摘要见下文versionInfometaVersion元数据 CAS 更新使用的乐观锁版本metaVersiondownloadCount聚合下载或使用计数如支持downloadCount值得注意的是AiResource继承了com.alibaba.nacos.plugin.visibility.model.VisibilityResource并实现了getResourceName()与getResourceType()这说明可见性控制直接内嵌在元数据实体中与 Visibility Plugin Spec 的插件模型衔接。name、type、namespaceId是身份字段不能作为普通元数据被修改。3.2 AiResourceVersion版本行AiResourceVersion是版本行包含作者、版本、版本状态、描述、存储 JSON、发布流水线信息和下载计数字段规范含义源码字段AiResourceVersion.javanamespaceId,type,name父级元数据身份对应三个字段version父资源下唯一的版本字符串versionauthor创建或导入该版本的操作者authordesc版本描述或提交信息descstatus版本生命周期状态statusstorage通过 AI 存储插件管理的存储内容 JSON 指针storagepublishPipelineInfo关联流水线执行的发布评审状态 JSONpublishPipelineInfodownloadCount每版本下载或使用计数如支持downloadCount规范要求已发布内容默认按不可变处理如果某类型必须允许内容变更其类型规范必须定义精确的安全规则。3.3 versionInfo JSON资源级版本摘要AiResource.versionInfo保存资源级的版本治理摘要包含四个关键字段字段含义editingVersion当前草稿版本如有reviewingVersion当前评审中版本如有onlineCnt在线版本数量labels标签到版本的映射包含latest关键约束一个资源最多同时存在一个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 的资源类型清单类型标准身份当前或已批准的持久化形态规范mcpnamespaceId - mcp - mcpName已批准目标ai_resource与ai_resource_version承载管理生命周期描述符指向未变更的 Config 内容。历史 Manifest 及现有 Direct、Service Ref、frontend/backend 与 Runtime Naming 布局仍作为服务平面serving plane。MCP Server SpecagentnamespaceId - agent - agentName已批准目标ai_resource、ai_resource_version、AI 存储和基于 Naming 的运行时端点发布。历史 A2A 存储在迁移完成前保持为兼容性来源。Agent Management SpecpromptnamespaceId - prompt - promptKey使用ai_resource、ai_resource_version和 AI 存储遗留 Prompt 数据可以迁移。Prompt SpecskillnamespaceId - skill - name使用ai_resource、ai_resource_version、AI 存储和一个用于发现的轻量级 Manifest。Skill SpecagentspecnamespaceId - agentspec - name使用ai_resource、ai_resource_version和 AI 存储。AgentSpec Spec此外A2A AgentCard 是agent版本内部的协议绑定。历史a2a资源身份和 API 是由 A2A Agent Spec 描述的兼容性门面facade不得创建第二个规范的 Agent 身份。源码中的类型常量与路由定义可在ai/src/main/java/com/alibaba/nacos/ai/constant/AiResourceConstants.javaRESOURCE_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 节Agenttypeagent时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 / SDKAI Registry 通过多个接口面暴露能力。规范第 5 节的接口面划分如下接口面受众规则/v3/client/ai/...运行时客户端与 Agent 框架查询已知资源、下载运行时产物、订阅、注册客户端拥有的端点/v3/admin/ai/...管理工具与 Maintainer SDK创建、更新、列表、发布、删除、上传、导入和版本操作/v3/console/ai/...Nacos 控制台 UI基于同一领域语义的 UI 编排gRPC AI 请求Java Client SDK 运行时流量查询 AI 资源、执行 RAD 发现与订阅、发布客户端拥有的端点如支持Java SDK运行时应用集成见 Java SDK Implementation SpecJava Maintainer SDK类型化管理集成应与 Admin API 语义和资源类型规范对齐AI Registry adaptor外部社区注册表客户端独立端口的可选兼容端点见 AI Registry Adaptor Spec这些路由在源码中有精确对应。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/mcpAI_RESOURCE_SEARCH_CLIENT_PATH /v3/client/ai/resources/searchAI_RESOURCE_IMPORT_ADMIN_PATH /v3/admin/ai/importAgent.ADMIN_PATH /v3/admin/ai/agents、Agent.CLIENT_PATH /v3/client/ai/agentsSkill.ADMIN_PATH /v3/admin/ai/skills、Skill.CLIENT_PATH /v3/client/ai/skillsAgentSpecs.ADMIN_PATH /v3/admin/ai/agentspecs、AgentSpecs.CLIENT_PATH /v3/client/ai/agentspecsPrompt.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 状态模型元数据状态状态含义enable资源可见且至少存在一个可查询版本时可被使用disable元数据级禁用类型规范定义查询行为版本状态状态含义draft构建中的可编辑版本reviewing已提交等待发布流水线评审reviewed流水线评审完成等待显式发布、强制发布、重新草稿化或重新提交online已发布且可查询offline已从常规运行时路由中移除的既有版本这些状态常量在源码中有完整定义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标记为historicaltrue的结果属于上一评审周期不得完成当前评审对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 直接上线门面做特化setAsLatestfalse可能保留当前有效指针标准 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 的迁移与演进事项MCP 迁移遵循 MCP Server Spec 中的异步单向管理过渡SYNCING - LIFECYCLE_MANAGED创建 Resource/Version 指针而不改变 Config 字节或 Naming等待零差异调和和每个成员的治理能力切换后继续维护历史 Manifest 和当前端点服务布局。生产行为在该契约实现并验证前保持待定pending。历史 A2A AgentCard 和 Naming 端点数据必须通过滚动升级计划迁移到 Agent 模型遗留 API 保持为投影projections不是独立的资源存储。Prompt有从遗留 Config 形态 Prompt 数据迁移到标准 AI 资源模型的路径遗留映射必须保持为兼容性存储而不是正式的 Config 资源语义。RAD 返回确定性的端点集合。健康过滤、优先级/权重选择和负载均衡是客户端侧策略不改变 Registry 快照。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 Spec11. 总结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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考