AI 资源生命周期

Nacos 从 3.2 开始支持 AI 资源生命周期管理，3.3 已统一覆盖 Agent、MCP Server、Prompt、Skill 和 AgentSpec。平台人员可以用相同的流程管理资源变更，避免未发布的内容影响线上应用。

本文介绍 3.3 的标准生命周期流程。已有 A2A、MCP 注册接口保留兼容行为，接入时请同时参考 Agent 管理和 MCP 管理。

资源和版本

一个 AI 资源由命名空间、资源类型和资源名标识。同一资源可以有多个版本，例如 Prompt order-summary 的 1.0.0 和 1.1.0。

资源级操作管理启用状态、可见范围和业务标签；版本级操作管理具体内容的编辑、审核、发布和上下线。禁用整个资源与下线某个版本是两个不同的操作。

发布成功后，版本即进入 online，不需要再执行一次上线操作。运行时能否读取或发现资源，还取决于资源是否启用、调用者权限以及对应资源的查询规则。

有适用的 Pipeline 时，日常变更按以下流程进行：

创建草稿 -> 编辑 -> 提交 -> reviewing -> reviewed
                                           |
                              审核通过后发布 -> online

创建并编辑草稿：修改内容并填写提交说明。已经发布的版本不能直接覆盖，应创建新版本的草稿。
提交：有已启用且支持该资源类型的 Pipeline 节点时，进入审核；没有适用节点时，提交会直接发布为 online。
检查审核结果：APPROVED 和 REJECTED 都会进入 reviewed。默认情况下，审核通过后仍需执行发布。
处理拒绝：需要修改内容时，先执行“重新编辑”（redraft），回到 draft 后修改并提交。只需重新执行检查时，可直接重新提交 reviewed 版本。
发布并验证：确认版本已上线，并从实际使用该资源的应用验证查询、下载或发现结果。

Pipeline 默认关闭。仅开启总开关也不代表所有资源都会被审核，还需要启用支持对应资源类型的检查节点。配置和扩展方式见 AI 发布 Pipeline 插件。

管理员可在应急场景使用强制发布，跳过 Pipeline 校验，将 draft、reviewing 或 reviewed 版本发布上线。强制发布不能代替下线版本的“重新上线”操作，应记录使用原因并确认风险。

版本标签将易读名称映射到版本，例如 stable -> 1.0.0。应用可以固定版本，也可以按资源支持的标签查询方式选择版本。

latest 是服务端维护的保留标签，标准生命周期操作遵循以下规则：

因此，latest 不一定始终指向版本号最大的版本：重新上线旧版本也会使它成为 latest。已有 A2A、MCP 直接注册接口的默认版本选择兼容规则见各自资源文档。

需要控制灰度或生产切换时，使用显式版本或 stable、canary 等自定义标签，并确认目标版本已上线。不要把未发布版本作为运行时使用的目标。修改标签只改变版本选择，不会修改版本内容或将版本自动上线。

需求	操作	使用前需要确认
暂停某个版本	将该版本下线	使用显式版本或自定义标签的应用可能无法继续读取；检查 latest 的自动切换结果
恢复已下线版本	将该版本重新上线	内容保持不变，latest 会切换到该版本
暂停整个资源	禁用资源	所有版本的运行时可用性都会受到影响
恢复资源	启用资源	不会把草稿或已下线版本自动发布上线
清理不再使用的内容	删除版本或资源	确认应用不再依赖它，删除不能代替可恢复的下线操作

MCP Server 和 Agent 的定义版本与运行实例、端点分开管理。版本上线不代表应用进程已经启动，也不保证端点健康；发布后还需要验证实际调用。

一个版本即使已经上线，调用者也可能因资源被禁用、可见范围限制或权限不足而无法使用。管理人员应依次检查资源启用状态、版本状态、客户端身份及权限。

可见性决定资源对哪些用户可见，鉴权决定当前身份能执行哪些操作。配置说明见可见性插件和鉴权。