返回 ResolveAI 项目总览 · 交互图：CONFIGURATION · ASSET · 治理
很多 Agent 项目在演示时只有一个“保存配置”按钮：改完 Prompt、Tool 描述或业务规则，下一次运行就自动使用新内容。这个路径很短，却把几个不同问题混在了一起：我改的是哪一类资产？改动基于哪个版本？谁看过差异？当前场景到底绑定哪个版本？一个页面停留太久后提交，会不会覆盖别人刚保存的修订？单项资产完整，是否意味着整个场景已经可以运行？
ResolveAI 的配置治理从六类配置资产开始：每次修改形成独立候选版本，审核事件绑定基线和内容哈希；发布后的资产需显式写入场景新修订，场景最后再经过整体就绪判断。当前流程运行于本地，企业审批和生产发布系统尚未接入。
这篇文章只回答一个问题：为什么“配置已经保存”只能证明输入被记录，不能证明它已经安全地成为一次 Agent 运行的明确上下文？
为什么不把所有内容都放进一份场景 JSON
一个客服 Agent 场景同时包含业务决策、对话编排、外部系统合同、知识范围、人工接管边界和评测真值。它们虽然会在同一次 Run 中协作，却有不同的负责人、风险和验证方法。
真实产品截图：场景实施向导把业务定义拆成六类配置资产，并要求先选择生成草稿、复用版本或暂不纳入。此时得到的是实施计划，还不是运行许可。
ResolveAI 当前把它们分为六类：
- Policy：适用范围、优先级、生效时间、例外和可执行决策规则；
- Workflow：编排模式、服务旅程、开场上下文和状态转换；
- Tool：接口输入合同、成功/失败回执与语义边界；
- Knowledge：允许检索的文档及明确版本，不在这里复制知识正文；
- Human：人工责任、接管条件和写操作确认要求；
- Evaluation：业务成功真值、禁止行为、检查项和客户回复模板。
这个拆分的价值不是“类型更多”，而是让每类资产拥有自己的最小正确性合同。例如 Workflow 不允许两个完全相同条件指向不确定转换；Tool 行为必须引用已声明的 Tool 合同，并同时具备成功与失败样例；Knowledge 文档 ID 必须唯一；Human 中的人工写操作必须要求人工确认；Evaluation 不能让同一个动作同时出现在必要动作和禁止动作里。
如果这些内容只是一份自由 JSON，系统最多知道“语法能解析”。拆成资产以后，才有可能回答“这次到底改变了哪一层业务合同”。
资产版本不是覆盖式表单
配置资产记录 assetId、类型、版本、Owner、生命周期、基线版本、Payload、内容哈希、来源、更新时间、操作者和审核事件。生命周期只有四种：draft、in_review、released、archived。
真实产品截图：配置资产目录把已发布版本和开放候选分开统计，并展示资产类型、生命周期、引用场景与可进入的治理入口。
从一个已发布版本开始修改时，Store 会创建新版本，而不是原地覆盖。候选记录 basedOnVersion，Payload 会被重新校验并计算规范化 SHA-256 contentHash。同一资产一次只允许存在一个 draft 或 in_review 候选；已进入审核的内容也不能继续编辑，必须先退回草稿。
这个设计保护了两个对象。
第一个是正在被场景引用的已发布版本。它在新候选出现后仍保持不变，历史 Run 不会因为今天改了配置而失去当时的运行解释。
第二个是审核对象本身。如果审核期间还允许修改 Payload，那么“批准候选 v2”可能批准的是一个已经变化的对象。当前实现把可编辑状态和审核状态分开，降低了这种偷换对象的风险。
当前 Store 仍是单进程 Map 加可选 JSONL 追加持久化，不具备数据库事务、跨进程唯一约束或多实例锁。因此它证明了版本合同和状态迁移可以运行，不证明已经解决企业级并发。
审核不是给一个模糊的“配置”打勾
候选提交前，系统会把它与 basedOnVersion 指向的基线做结构化差异分析。不同字段被映射为不同风险：Policy 的作用域、例外和决策规则是高风险；生效时间是中风险；Workflow 的编排责任和流程分支是高风险；Tool 接口合同、Human 接管边界、Evaluation 业务真值与禁止行为同样属于高风险变化。
差异报告保存候选哈希、基线哈希、变化列表、总体风险、阻断原因，以及一个 requiresProductionApproval 风险信号。这里必须严谨区分：这个布尔值不是生产审批器，也不代表企业批准已经完成。 它只告诉后续流程“该候选触及了业务边界，不能把资产 Registry 的发布动作当成最终上线”。
提交、退回和批准事件会记录：
- 事件类型；
- 操作者标签与说明；
- 基线版本和基线内容哈希；
- 候选内容哈希；
- 由这些字段生成的证据哈希；
- 事件时间。
如果候选与基线完全相同、找不到基线、或类型专属校验仍有阻断项，提交审核会返回 configuration_asset_review_blocked。退回修改不会删除之前的提交事件；再次提交和批准会继续追加事件，因此能够看到一次候选经历了怎样的审核循环。
项目里有没有一个“最终审批人”
没有预设某个特别的人。
当前页面在提交审核时使用 workspace-reviewer 作为逻辑操作者标签，在场景绑定时使用 workspace-operator。这两个值帮助本地实践记录“哪个角色动作发生了”，但它们不是登录身份、电子签名、组织角色或 RBAC 证明。
页面上的“确认审核并发布”真正做的是：对当前候选重新检查 blockers，追加带说明和哈希的 approved 事件，把候选生命周期改成 released，并把此前的 released 版本标为 archived。它表达的是本地配置资产 Registry 中的版本审核与发布。
它不代表：
- 某个专职员工已经获得或行使最终审批权；
- 四眼原则、审批委派和越权控制已经实现；
- 企业发布单已经通过；
- 生产流量已经切换；
- 场景已经自动使用这个版本。
资产审核事件和发布生命周期已持久化；真实审批人身份、RBAC 与生产批准仍未接入。 因此，读取审核事件可以还原资产流转，但实际生产批准还需要组织身份与授权系统。
发布资产之后，当前场景仍然不变
只有类型匹配且 lifecycle 为 released 的资产，才能应用到场景。绑定时，系统不会修改资产本身，而是克隆当前场景定义，替换对应层的内容，并写入一条明确引用：assetId + revision + status: ready + source: registry。
Archify 生命周期图：候选草稿、审核门禁、资产发布、场景修订和整体就绪是连续但不等价的状态；审核阻断与绑定拒绝有明确失败出口。图描述当前本地合同，不代表企业生产审批已经接入。
交互版可以切换明暗主题、聚焦资产版本、审核证据和场景绑定：/demos/resolve-ai/configuration-asset-governance/。
场景绑定请求还必须提交 expectedRevision。服务端先读取当前场景修订；如果页面携带的修订号已经过期，返回 409 revision_conflict，不会继续写入，也不会在 UI 中声称“绑定成功”。成功绑定则保存一个新的场景配置修订。
这是一条重要的不变量：发布新资产不会静默改变旧场景；只有一次显式且基于最新修订的绑定，才会产生新的场景输入。
不同资产在绑定时还保留类型边界。Tool 绑定只替换接口与回执，不扩大动作权限；Knowledge 绑定会重新检查允许列表中的每个文档版本仍然存在且为 ready；Human 绑定保留既有自动化权限，只替换人工责任边界；Evaluation 绑定不会批量改写历史 Case 的输入与期望快照，并明确要求用新契约执行回归。
为什么已经配置 Policy，场景仍可能 No-Go
场景 readiness 判断的对象不是某一张表单，而是完整运行合同。即使 Policy 已经保存并显示版本、作用域、生效时间和例外，如果 Workflow、Tool、Knowledge、Human 或 Evaluation 仍是草稿，场景仍然不能被视为完整。
真实产品截图：Policy 字段已经配置，右侧仍显示暂缓上线，并指出实施资产尚未就绪。单项完成不等于整体可运行。
当前 readiness 会检查业务目标、负责人、证据来源、请求边界、动作权限、评测 Owner、期望业务结果、响应模板和资产绑定状态。只要存在非 ready 实施资产，就给出 Implementation asset is not ready；如果复用资产无法证明来源场景和配置版本，则给出 Reused asset provenance is missing。
这里的关键不是错误文案，而是状态所有权：资产 Registry 决定某个资产版本是否已经发布；场景修订决定当前场景引用哪个资产版本；readiness 决定所有输入组合后是否满足运行前置条件。三个判断不能互相代替。
配置资产 release 不是 production release
一个资产版本进入 released，只意味着它具备被场景引用的资格。场景绑定完成后，仍需要影响分析、关联 Evaluation Case、离线 Run、门禁结论和可回滚证据。
真实产品截图：发布中心把业务输入、配置输入、质量输入和证据输出放在一条资料流中。配置只是发布资料的一部分。
当前 Release Evidence 还会明确列出“审核人身份与 RBAC”和“生产流量”状态。它们没有因为本地测试通过就被伪装成已完成能力。也就是说，ResolveAI 当前能够演示配置变更如何进入可回归、可解释的发布准备流程，但不能据此声称真实企业审批、部署系统和生产切流已经接通。
这个边界也解释了为什么 UI 文案会反复强调“资产发布仍不会自动修改任何场景或生产流量”。如果把本地 Registry 的 released 直接翻译成“已上线”，就会在对外说明中把一个可验证的实践实现夸大成不存在的生产事实。
最小反例：保存成功为什么仍然不够
可以用四个反例检查这套设计是否真的有意义。
第一，候选与基线完全相同。保存可以成功，但提交审核应被阻断，因为没有可审核的有效变更。
第二，Tool 候选新增了合同却没有失败回执样例。JSON 结构可以成立，但资产语义不完整，仍不能进入审核。
第三，一个操作者在旧页面上绑定已发布 Policy，期间场景已被别人更新。资产本身合法，但 expectedRevision 过期，绑定必须返回 409，而不是覆盖最新场景。
第四，Policy 已发布并绑定，但其他实施资产仍为 draft。场景修订存在，单项资产也正确，整体 readiness 仍应是 No-Go。
这四个反例分别证明：持久化成功、结构合法、资产发布和场景修订，都不是“可运行”的同义词。
当前验证与边界
本轮聚焦验证执行了 5 个测试文件、132 项测试，覆盖资产草稿与不可变发布版本、审核阻断、退回/重提/批准证据链、类型专属校验、资产工作区、详情页绑定冲突、场景修订、readiness 和完整 API 合同；全部在当前工作树通过。
新生命周期图通过 Archify showcase 9/9 检查，完成 1440×900、1600×1000、1920×1080、2048×1320 明亮主题，以及 1440×900、2048×1320 深色主题的首屏 containment 和实际截图审阅。最终没有横向或纵向溢出、线穿节点、关系交叉和标签遮挡；经过 1 轮聚焦视觉修正。
仍需保留五条边界：当前 Store 是本地单进程实现；API 中的 tenant 字段不等于企业级租户隔离；操作者标签不是认证身份；风险标记不执行企业审批；资产发布与场景绑定都没有连接生产部署和流量系统。本文依赖未提交工作树，参考提交不能独立复现全部机制。
配置从保存到运行，需要经过候选版本、差异审核、资产发布、场景修订和整体就绪检查。排查“配置已发布但运行未变化”时，应先检查场景是否绑定了对应修订。本地资产的 released 状态表示资产发布，生产上线仍需外部审批与发布系统。