资产治理与仿真验证

一句话：资产治理回答“组织有哪些能力、这次任务实际用了什么”，把版本、摘要与依赖钉死；仿真验证回答“在上线之前，它的行为能不能被验证”，用可控环境换可验证行为。前者交付台账，后者交付证据，都不替人做判决。

对应原书：第 15 章《AI 资产的发现与管理》、第 16 章《Agent 行为生成与质量验证》。

为什么需要

团队规模一上来，最先失控的不是模型，而是“用了什么”：Prompt 改了七版，线上跑的是哪一版没人说得清；Skill 的 SKILL.md 没变，里面的脚本被替换了；同一个 MCP Server 扩了容，端点变了，调用方还在用旧地址；Agent 依赖了哪些 Prompt、Skill、MCP，变更后会影响谁，只能靠人问。

这三组混淆必须先在概念上拆开：模板 ≠ 最终输入，标签 ≠ 精确版本，发现 ≠ 授权 ≠ 健康。 四类问题随之而来——资源在哪、哪个版本能用、一次任务实际用了什么、变更会影响谁。验证侧的问题是另一个：真实环境里不敢让它失败。医疗系统靠执业资格卡入口、SOP 约束过程、复盘沉淀教训、模拟器训练罕见场景，共同点不是保证每个医生每次都正确，而是用一个可靠系统约束一个不可靠的内核。Agent 正好是那个不可靠内核：推理可能幻觉、工具可能调错、参数可能越界，Harness、工具协议与编排分工才是外部可靠结构。

一次退款任务里，人类客服有五样保障——培训与资质、SOP、同事复核、复盘、演练；换成 Agent，五样一起归零。补制度以年计，但“一个能安全失败的环境”可以立刻建：这就是仿真在当下唯一能做的事。

核心机制

一、五类资产：共用治理，不共用验证

Prompt、Skill、MCP Server、Agent、AgentSpec 共用名称、版本、生命周期、可见范围与发布记录，但验证方法与消费协议各不相同。把它们当成同一种“资源”管理，就会出现用 Prompt 的评测方式去验 Skill，或者用 Agent 的版本号去指代 AgentSpec。

二、Prompt 的工程化

结构化模板五部分组成：指令层（低优先级不能覆盖高优先级）、模板与变量（受控渲染，防变量破坏指令边界）、输入输出要求、运行依赖、验证材料。变更分三类：文字修订（预期不变，但仍要评测）、接口变化（变量、输出 Schema、工具依赖）、行为变化（规则、步骤、拒绝范围）——分类只帮助评审，不能代替评测。评测本身要绑三层：结构检查、任务评测、运行评测，记录关联 Prompt 版本、模型版本、推理参数、工具定义与评测集版本。发布可以用精确版本，也可以用 stable / canary 标签；历史版本永远不变，变的只是标签指向，回滚就是改标签，同时记录原因、执行人与影响范围。版本号只负责唯一标识，兼容性靠评测加人工判断。真正用于回放的是有效 Prompt 指纹：Prompt 版本 + 变量快照 + 模型与参数 + 工具定义版本 + 策略版本 + Context 来源，六项一起写进 Context Manifest。

三、Skill 是完整能力包

一个 Skill 至少包含 SKILL.md、manifest.yaml（标识、依赖、权限声明）、scripts、templates、references、tests、LICENSE。摘要必须覆盖完整包——只对 SKILL.md 算摘要，脚本被替换就发现不了。准入六阶段：来源核实 → 完整性校验（摘要 + 签名）→ 静态检查 → 隔离验证 → 人工评审 → 内部发布；签名只证明“来自谁、没被替换”，不证明“没有风险”。运行时权限不超过 Manifest 声明，按任务重新授权；默认禁外网、文件限制在任务目录、外部服务用短期最小凭据。上线后还要持续处置：定期重检把结论绑到摘要、依赖、工具与策略版本上；一旦发现风险，先停新安装，再通知使用方迁移到安全版本。

四、MCP：定义与端点分离

MCP Server 的资源信息分五组：基本信息、能力定义（Tools / Resources / Prompts，随版本发布）、运行信息（端点与健康，随部署变化）、治理信息、连接要求。扩缩容不产生新版本，Tool Schema 变化才产生新版本——把两者混在一个版本号里，每次扩容都要重新评审。进入方式有三种：框架/SDK 启动时自动注册、存量 HTTP/RPC 经 OpenAPI 转换、外部导入补内部治理。Router 只按任务缩小候选，不改变 MCP 语义；真正的调用仍由原生 MCP 完成。Agent 不应绕过 Registry 直连来源地址。

五、双 Registry 与 RAD

Agent Registry 管现在有哪些 Agent 可发现、可调用，含 AgentCard、版本、端点、可见范围，逻辑版本与运行端点分开表达；AgentSpec Registry 管一个 Agent 应如何描述、组装、分发，含 Manifest、Prompt/Skill/MCP 引用与运行配置。两者不共用版本号。RAD 五个操作：Search（轻量目录）→ Discover（解析快照：精确版本 + 协议描述 + 端点）→ Watch（完整替换快照）→ Register（发布端点批次）→ Deregister（撤销）。它协议无关，底层仍走 A2A；ARD 获取 Agent 也不以 RAD 为前提。

六、评审：固定候选摘要的闭环

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

七、资源中心：权威数据与派生索引分离

承载这一切的是六件东西：权威 Registry（逻辑资源、版本、状态、标签、权限、引用关系）、AI 内容存储（Prompt 正文、Skill 包）、发布 Pipeline、发现索引（文档/分块/向量）、Policy Engine（按身份、Namespace、风险等级判资格）、Resolver（把引用与标签解析成不可变版本加摘要）。版本、状态、权限、摘要以 Registry 为准，索引是可重建的派生数据：可以增量收敛、定期核对，旧索引命中时也要回 Registry 复核当前状态。管理链路处理创建、评审、扫描、索引生成，可以慢；运行链路只提供查询、解析、下载、端点发现与变更通知，要快，本地缓存必须绑定精确版本与摘要。

八、稳态与动态两条获取路径

这张图要表达的是同一条链路的两种入口：左边把“用哪个版本”在发布前就锁死，右边把“需要什么能力”留到任务运行时再解析，最后都在 Context Compiler 汇合，产出可回放的 Context Manifest。

稳态路径适合客服分类、合规审核这类固定流程：AgentSpec 声明引用，Resolver 按身份与环境解析，生成锁定精确版本与摘要的 Lock Manifest，再加载。绑定时机可以选构建期、部署期或启动期——越靠前越稳定，越靠后越灵活。动态路径适合开放任务：把任务事实整理成结构化的 Capability Requirement，跨类型发现、治理过滤后再按需解析，需要远程调用时走 RAD。混合模式最常见：核心 Prompt 与高频 Skill 固定版本，业务长尾按任务发现，高风险操作要求人工确认。

九、Context 的六级优先级

系统策略 > 任务 Prompt > 已批准 Skill > 能力说明 > Knowledge / RAG / Memory > 用户输入与调用结果。外部内容默认是数据，措辞再强也不能升级为系统指令。Token 预算渐进装配：核心策略完整保留，Skill 步骤先行，资料延迟到相关步骤，Tool Schema 按任务披露子集；裁剪必须可解释——保留、摘要还是省略，以及原因。获取失败时不要混合新旧版本：整体退回上一组已验证组合，或者停止。

十、仿真：用可控环境换可验证行为

仿真不依赖那三样制度前提，只需要一个能安全失败的环境。它用软件承载被测 Agent 所处的外部世界：用户模拟承载人（会记错金额的顾客、会撤回的审批人），环境模拟承载外部条件（工具与 API、数据与业务状态、文件、模型服务、外部事件、时间本身），这个世界可保存、可修改、可重放，且没有真实后果。边界是授权与后果，不是实现方式：不触达未授权的生产账户、数据与网络，不产生不可控的真实副作用。连隔离的真实后端仍然算仿真；全替身但把请求路由到生产账户，仍然是事故。

三种执行模式：全替身（回归、可复现性最高）、混合（端到端集成）、隔离真实依赖（服务栈验证、保真度最高）。结论不能跨模式混用。 被测系统（SUT）不能进仿真：推理、工具选择、参数构造、异常处理都属被测对象，替换任何一项就等于把它移出回路；判断口径是“考察的内容不能换，设定的条件必须换”。替身机制再按开放度选：脚本、录制回放、规则、状态机、模型生成或混合。

十一、两个模拟器与两张账

用户模拟器分三层：Persona 是角色底色（专业度、表达偏好、行为倾向）；认知状态记录“她知道什么”，允许与客观事实不同——真实状态与用户认知两份都要留；行为策略由反应规则、状态机与时钟驱动的耐心组成。工程主流是 Hybrid：意图选择交给状态机，自然语言表达交给模型，输出再经事实校验与披露规则校验。质量看五维——角色一致性、反应规则符合率、信息可见性、终止规则符合率、行为分布多样性，生成与评分要用不同模型。

环境模拟器守四条：事实一致，API 返回与数据库状态来自同一事实模型，create_refund 受理后 get_refund 必须查得到；超时按三个位置精雕，请求未发送测重试退避，已发送未提交测等待与查询确认，已提交但响应丢失测重复提交防护；Run 级隔离，独立工作区、账户数据与会话；故障注入四步留痕，计划、生效、命中、恢复各记一笔——“注入了”和“生效了”是两件事。两张账最容易被忽略：事件联动账记录同一事件在用户、Agent、环境三方的状态与时点，用来回答“撤回到底生效没有”；时间分离账区分业务日历时间、仿真逻辑时间、单调时钟与墙钟时间，四者混用会让超时与重试判断失真。

十二、对象链与证据分层

这条对象链的每一段只回答自己的问题：Scenario Spec 声明测什么，Manifest 在启动时锁定资产版本，Run 产生事实，Run Result 收拢材料；三道检查依次问材料在不在、条件成不成立、够不够支撑评价，都通过之后才轮到 Evaluation 给判定。证据不足时正确输出是“不可判定”，不是硬给一个分。证据要分三层：records 是原始记录，observations 是事实性观测，evidence 是可供引用的证据；criterion → evidence_refs → verdict 由 Evaluation Result 建立，不属于 Run Result——同一份 records 可以被重评分、合规检查、回归各自组织判断，不被上一轮结论污染。triggers 是计划，Event 是事实，两者不共享名字。

Run 的四个状态彼此独立：执行状态（完成/崩溃/取消）、仿真有效性（有效/被破坏/未检查）、证据完整性（完整/部分）、任务质量（由独立的评估给出）。一次完整有效的 Run 完全可能算出错误金额；压成一个“成功/失败”，会把“跑完了但环境失效”误判成通过。Harness 做五件事：解析场景、编排受控运行、管理替身与隔离、汇集记录引用、清理复位。不做五件事：任务生命周期、鉴权与权限决策、遥测采集、质量评分、发布决策。收进来一件，就从一个执行引擎膨胀成总控制器。它内部并行三条流：交互流（消息、工具请求、可见事件）、控制流（装载、初始化、故障、终止、清理）、证据流（Trace、状态、产物、控制记录）。

十三、统计边界与假设校准

n 次运行零违规，不代表违规率为零。单侧 95% 置信上界近似为 3/n：300 次零违规，上界约 1%。报告结论时必须带这个边界，否则“没出过事”会被读成“不会出事”。Testing Gate 汇总证据，但不是发布决定者，治理节点拿证据做决策，例外审批留痕。仿真假设也会过期：用户模型是假设，场景来自已知失败模式；仿真成功率上升，而生产上人工接管持续增加，就是假设失效的信号。校准应该由事件驱动（接口变更、故障复盘、用户结构变化），而不是按固定周期走形式。

最小上手

asset:
  identity: "namespace + type + name + version"
  skill_digest: whole_package
  mcp_version: definition_only
  prompt_fingerprint: [prompt_version, vars_snapshot, model_params, tool_versions, policy_version, context_sources]
simulation:
  manifest_locks: [user_policy, initial_data, tool_contract, simulator_config, eval_spec]
  run_result: [records, artifacts, observations, evidence, completeness]
  checks: [records_complete, run_valid, evidence_sufficient]

验收看三件事：任一运行都能给出 Lock Manifest 与 Context Manifest；改一个 Skill 脚本会改变摘要并触发重检；仿真报告能区分“任务失败”和“环境失效”。

生产动作

• 先做最小闭环，再扩资产类型。挑一条高频链路，从 Prompt 指纹和 Lock Manifest 做起，跑通“发布—回放—归因”，比一次性建五个 Registry 有效。
• 把索引当派生数据。发现索引可以重建、增量收敛、定期核对；旧索引命中时也要回 Registry 复核当前状态。
• 用摘要锚定，不用标签锚定。stable 只是指针，回放要靠精确版本加内容摘要。
• 先补最贵的验证。仿真环境里优先覆盖“失败后能不能恢复”“副作用有没有重复”，而不是只测成功路径。
• 例外要留痕。强制发布、跳过评审都要记录理由、责任人与恢复目标。

边界

• 签名不代表安全。它只证明来源与完整性。
• 发现不代表可用。健康、授权、版本状态都要单独判断。
• 仿真不能证明生产正确。它证明的是“在给定场景与条件下，行为符合预期”；场景覆盖不到的地方，结论不成立。
• 证据材料不是质量结论。运行完成、任务成功、允许发布是三个独立结论；退款申请数等于 1 是观测，处理得对不对是判断。
• 动态发现只适合长尾。核心链路仍应锁版本，否则每次运行都可能换一套依赖。

讲清楚

资产治理的核心是“把用的是什么钉死”：五类资产共用版本、生命周期与评审，但各有验证方法；Prompt 用指纹，Skill 用整包摘要，MCP 把定义与端点分开版本化；稳态路径锁 Lock Manifest，动态路径把任务事实变成能力需求再发现，最后都汇到 Context Compiler，产出可回放的 Context Manifest。

仿真验证的核心是“在能安全失败的环境里拿证据”：用户模拟承载人、环境模拟承载外部条件，边界看授权与后果，不看是不是真环境；Scenario Spec 声明场景，Manifest 锁定资产版本，Run 产生记录、制品、观察与证据，三道检查通过后才交给评估。运行完成、任务成功、允许发布是三件事；证据不足就输出不可判定。

最后记住统计边界：n 次零违规的上界大约是 3/n，不是零。仿真结论要带场景、模式与样本量，否则它只是“这次没出事”。

适用：AI 资产治理、发布评审与仿真验证体系设计 | 初稿 2026-10