AI 工程小册

主题

第 15 章 AI 资产的发现与管理 · 面试能讲版 ​

核心观点 + 逻辑框架 + 资产治理与发现全景（治理篇第 3 章）

原书章节 ↗

▍速览 ​

一句话版（开场，约 20 秒）

Prompt、Skill、MCP Server、Agent、AgentSpec 五类能力资产，共用版本、生命周期、评审和权限，但不共用验证方法与消费协议。稳态 Agent 声明式解析出 Lock Manifest，动态 Agent 用 ARD 按意图发现、RAD 解析远程 Agent，Context Compiler 最终装配出可回放的 Context Manifest——从组织有哪些能力，到本次任务实际用了什么，形成连续关系。

一段话版（展开，约 90–120 秒）

Agent 的行为不只取决于模型，还取决于它能看到哪些指令、能用哪些工具、连哪些外部能力。当 Agent 多了，这些能力资产就从应用内配置变成公共资源，需要回答四个问题：资源在哪、哪个版本能用、一次任务实际用了什么、变更会影响谁。能力资产分五类管理。Prompt 做成结构化模板——指令层、变量 Schema、输出要求、运行依赖、验证材料；变更分文字修订、接口变化、行为变化三类，分类帮助评审但不能代替评测；发布用 stable/canary 标签灰度，回滚只动标签不动历史版本；一次调用实际生效的组合叫有效 Prompt（版本+变量快照+模型参数+工具定义+策略+Context 来源），记录成指纹进 Context Manifest。Skill 是完整能力包，摘要覆盖整个包；外部 Skill 要过可信准入六阶段——来源核实、完整性校验、静态检查、隔离验证、人工评审、内部发布；运行时权限不超过 Manifest 声明，按任务重新授权。MCP 管理的关键是能力定义与运行端点分开演进，三种进入方式（自动注册、OpenAPI 转换、外部导入），Router 只缩小候选、不改变 MCP 语义。Agent Registry 管现在有哪些 Agent 可发现可调用（AgentCard 版本化），AgentSpec Registry 管一个 Agent 应如何描述组装；RAD 用 Search/Discover/Watch/Register/Deregister 五操作做协议无关的远程发现，底层仍走 A2A。所有资产变更走同一条评审流水线：草稿、提交评审固定候选摘要、自动检查、人工确认、不可变发布、灰度、运行验证；检查不修改候选内容，运行反馈只生成新候选。承载这一切的是 Agentic Resource Registry（Nacos 参考实现）：权威 Registry 保存资源事实，内容存储、发布 Pipeline、发现索引、Policy Engine、Resolver 各司其职，检索索引是可重建派生数据。获取分两条路：稳态 Agent 声明引用、Resolver 解析、Lock Manifest（构建期/部署期/启动期三种绑定）；动态 Agent 把任务事实形成 Capability Requirement，ARD 跨类型发现、治理过滤，需要远程调用时按需 RAD。最后 Context Compiler 按指令层级、信任边界、Token 预算装配，外部内容默认是数据、不自动获得高优先级，输出 Context Manifest 支持回放与归因。分阶段演进 L0 分散维护到 L5 持续改进，判断标准是实际能力，而不是是否部署了某个产品。

  • 一个命题：能力资产有台账——五类资源共用治理、各保留消费协议
  • 五类资产：Prompt · Skill · MCP Server · Agent · AgentSpec
  • 评审纪律：固定候选摘要 · 检查不改内容 · 不可变发布 · 反馈生成新候选
  • 两种获取：稳态声明式 Lock Manifest / 动态 ARD+RAD 按任务发现
  • 闭环证据：Context Manifest 可回放 · 权威 Registry 与派生索引分离

一句话（收尾）

资产治理的核心不是把五类资源塞进一张表，而是把资源事实、发布治理、运行发现连成同一条链路——版本不可变、标签可移动、选择可解释、运行可回放。

▍逻辑框架（记忆卡片） ​

① 命题：能力资产需要台账与版本 ​

Agent 的行为取决于模型、所见指令、可用工具、可连外部能力与上下文。能力资产从应用内配置变为公共资源后，团队要回答：资源在哪、哪个版本可用、一次任务实际用了什么、变更影响谁。五类资产共用名称、版本、生命周期、可见范围与发布记录，但不共用验证方法与消费协议。承载基础设施＝Agentic Resource Registry（Nacos 参考实现，从 Config、Naming 向 AI Registry 演进，3.3 版本线基线）。

模板≠最终输入 · 标签≠精确版本 · 发现≠授权≠健康

② Prompt 工程化：模板 · 版本 · 评测 · 回滚 ​

  • 结构化模板：指令层（低优先级不能覆盖高优先级）+ 模板与变量（受控渲染，防变量破坏指令边界）+ 输入输出要求 + 运行依赖 + 验证材料
  • 变更三类：文字修订（预期不变仍要评测）/ 接口变化（变量/输出 Schema/工具依赖）/ 行为变化（规则/步骤/拒绝范围）；版本号只承担唯一标识，兼容性靠评测+人工判断
  • 评测绑定：结构检查 + 任务评测 + 运行评测；记录必须关联 Prompt 版本、模型版本、推理参数、工具定义、评测集版本
  • 发布灰度回滚：精确版本或 stable/canary 标签；历史版本不变，变的是标签指向；回滚记录原因、执行人、影响范围
  • 有效 Prompt 指纹：Prompt 版本 + 变量快照 + 模型与参数 + 工具定义版本 + 策略版本 + Context 来源 → 指纹 → Context Manifest

③ Skill：能力包 · 可信准入 · 运行时限制 ​

  • 完整能力包：SKILL.md + manifest.yaml（标识/依赖/权限声明）+ scripts/templates/references/tests/LICENSE；摘要覆盖完整包，只对 SKILL.md 算摘要会漏掉脚本变化
  • 可信准入六阶段：来源核实 → 完整性校验（摘要+签名）→ 静态检查 → 隔离验证 → 人工评审 → 内部发布；签名证明来自谁、没被替换，不证明没风险
  • 运行时限制：权限不超过 Manifest 声明，按任务重新授权；默认禁外网、文件限任务目录、外部服务用短期最小凭据注入
  • 持续处置：定期重检（结论关联摘要+依赖+工具与策略版本）；发现风险→停新安装、通知使用方、迁移安全版本

④ MCP：定义与端点分离 · Router 不改语义 ​

  • 资源模型：基本信息 / 能力定义（Tools·Resources·Prompts，随版本发布）/ 运行信息（端点/健康，随部署变化）/ 治理信息 / 连接要求——扩缩容不产生新版本，Tool Schema 变化才形成新版本
  • 三种进入：框架/SDK 启动自动注册 · 存量 HTTP/RPC 经 OpenAPI 转换 · 外部导入补内部治理；Agent 不绕过 Registry 直连来源地址
  • Router 边界：router 模式提供 search_mcp_server/add_mcp_server/use_tool，按任务缩小候选；proxy 模式把 stdio/SSE 转为 Streamable HTTP；只缩小候选范围，不改变 MCP 语义，真正调用仍由原生 MCP 完成

⑤ Agent Registry 与 AgentSpec Registry ​

  • Agent Registry：管现在有哪些 Agent 可发现可调用——Agent 定义、协议原生描述（A2A AgentCard）、版本、运行端点、可见范围；逻辑版本与运行端点分开表达
  • AgentSpec Registry：管一个 Agent 应如何描述、组装、分发——Manifest、Prompt/Skill/MCP 引用、运行配置；构建/部署阶段解析为锁定清单；两者不共用版本号
  • RAD 五操作（协议无关，Nacos 3.3 初步完成）：Search 轻量目录 → Discover 解析快照（精确版本+协议描述+端点）→ Watch 完整替换快照 → Register 发布 Endpoint Batch → Deregister 撤销；ARD 获取 Agent 不以 RAD 为前提

⑥ 变更评审：固定候选摘要的闭环 ​

  • 草稿 → 提交评审固定候选内容与摘要 → 自动检查（格式/安全/依赖/评测）→ 人工确认 → 不可变发布 → 上线灰度 → 运行验证（指标/Trace）
  • 检查不修改候选内容：要改就回草稿形成新候选摘要；运行反馈只生成新候选，不直接改在线内容
  • 评审通过≠正式上线：评审=满足发布条件，发布=形成不可变版本，在线状态与标签=运行时可发现；紧急强制发布须记录原因、风险接受人、恢复目标
  • 评测记录绑定：资源类型+候选版本+内容摘要+评测集版本+模型/运行时版本+策略版本+工具版本+执行时间；摘要不一致即停止发布

⑦ 资源中心：六组件与两条链路 ​

  • 权威 Registry（逻辑资源/版本/状态/标签/权限/引用关系）· AI 内容存储（Prompt 正文/Skill 包等大体量内容）· 发布 Pipeline · 发现索引（Document/Chunk/向量）· Policy Engine（身份/Namespace/风险等级判资格）· Resolver（引用/标签→不可变版本+摘要）
  • 权威数据与派生索引分离：版本/状态/权限/摘要以 Registry 为准；索引可重建、增量收敛、定期核对，旧索引命中也要回 Registry 复核当前状态
  • 管理链路与运行链路分开：管理处理创建/评审/扫描/索引生成（可慢）；运行链路只向合格 Agent 提供查询/解析/下载/端点发现/变更通知（要快），本地缓存与精确版本摘要绑定
  • Nacos 标识：namespaceId + resourceType + resourceName + version；状态 draft/reviewing/reviewed/online/offline；双向引用关系：Agent 依赖了什么 + 资源变更影响谁

⑧ 稳态 vs 动态：声明式解析与按任务发现 ​

  • 稳态 Agent（客服分类/合规审核/固定流程）：AgentSpec 声明引用 → Resolver 按身份+环境解析 → 精确版本+摘要 Lock Manifest → 加载/连接，任务边界内版本稳定；三种绑定：构建期（镜像内固定）/ 部署期（CI/CD 解析生成锁定清单）/ 启动期（拉取 stable 标签，更新快）
  • 动态 Agent（开放任务）：任务事实 → 结构化 Capability Requirement → ARD 跨类型发现 → 治理过滤与版本解析 → 远程 Agent 场景按需 RAD → Context Compiler 装配
  • 混合模式：核心 Prompt + 高频稳定 Skill 固定版本；业务长尾能力按任务发现；高风险操作可要求人工确认或只返回能力说明

⑨ 从发现到 Context：装配纪律与回放 ​

  • 发现摘要与执行内容分离：候选比较只用轻量元数据；选定后 Resolver 解析精确版本，Context Compiler 按资源类型取执行所需内容
  • 优先级与信任边界：系统策略 > 任务 Prompt > 已批准 Skill > 能力说明 > Knowledge/RAG/Memory > 用户输入与调用结果——外部内容默认是数据，措辞再强也不能升级为系统指令；能力说明与实际授权一致
  • Token 预算渐进式装配：核心策略完整保留，Skill 步骤先行、资料延迟到相关步骤，Tool Schema 按任务披露子集；裁剪策略可解释（保留/摘要/省略+原因）
  • 一致性与回放：获取失败不混合新旧版本（整体退回上组已验证组合或停止）；端点故障不改历史版本；Context Manifest 记录 agent_release/model/资源版本/策略版本/发现请求/端点/指纹

⑩ 运营指标与分阶段演进 ​

  • 指标五方面：资源治理（无负责人数量/版本漂移率/回滚时间）· 变更评审（自动检查通过率/评测退化率/回退率）· 发现质量（Top-K 命中/候选采用/误匹配/可解释率）· 运行效率（解析延迟/加载时间/缓存命中/Token 消耗）· 安全治理（未检查外部 Skill/风险版本/撤回后新加载次数）——指标要结合业务结果解释
  • L0 分散维护 → L1 版本留存 → L2 统一 Registry → L3 统一评估与可信供应链 → L4 受控动态发现 → L5 持续改进；判断标准是实际能力（只建列表但允许覆盖历史≠L2；有语义检索但无权限过滤≠L4）

▍逻辑全景图（AI 资产：从五类资源到两种获取路径） ​

示意 · 按第 15 章正文重构，并入原书图 15-5 的稳态/动态双路径要素

统一治理五类能力资产；稳态声明式解析、动态 ARD/RAD 按任务发现，最终进入可回放的 Context Manifest

  • 五类资产/权威 Registry
  • 稳态声明式路径
  • 动态发现路径
  • 发布评审

示意 · 按第 15 章正文重构（原书另有图 15-1 MCP Registry/Router 关系、15-2 Agent Registry/RAD 职责边界、15-3 发布评审闭环、15-4 Nacos 全景、15-5 稳态动态路径、15-6 Context 装配流程）

▍书中关键图（SVG 重绘版 · 示意） ​

图 15-3 发布、评审与迭代闭环：一次评审绑定同一候选内容与摘要，运行反馈只生成新候选版本

示意 · 依原书图 15-3 发布评审闭环重构（虚线退回回路、底部记录条为原图结构）；图 15-5 的稳态/动态双路径已并入上方『逻辑全景图』

把 AI 工程讲到既懂也会用

AI 工程小册 · 持续更新