返回 ResolveAI 项目总览 · 交互图：运行时 · 证据 · CHAIN
很多 Agent 演示把一次运行压缩成两步：用户输入一句话，模型返回一段看起来合理的回答。这个界面足以展示语言能力，却无法回答真正决定系统能否被审阅的问题：模型依据的是哪一版场景与配置？它提出了什么动作？谁判断这个动作被允许？Tool 是否真的执行？执行成功是否等于业务结果正确？失败输出和重试有没有被保留下来？
ResolveAI 把一次运行设计成一个结构化的 Run 证据对象，而不是一条聊天消息。它把 Provider 尝试、候选动作、授权判断、工作流状态、Tool 观察、业务结果和评测结论拆开保存，并允许运营人员在同一页面逐项查看。
这篇文章只回答一个问题：一次 Run 如何从固定输入走到模型外门禁、受控执行和证据固化，同时避免把“模型提议”“系统允许”“Tool 成功”和“业务成功”混成同一件事？
Run 不是回答，而是一次可重放的判断
运行开始前，页面会固定业务场景、工作流版本、配置修订、历史上下文 Run、客户输入和模型实验参数。服务端的 POST /api/runs 入口再次验证这些引用是否存在、历史 Run 是否属于同一场景，以及当前 AI 能力是否被场景配置准入；缺少条件时，请求在进入 Provider 前就失败。
真实产品截图：左侧固定场景、配置修订、Policy、Tool 合约与模型参数，中间保留输入和回答，右侧单独呈现结构化候选动作。内容为脱敏演示场景。
这一步的价值不是“多显示几个 ID”。它建立了归因前提：之后看到的 Proposal、Guard 结果和 Tool 轨迹都必须指向同一个运行身份。如果上下文、配置或模型参数可以在执行后被静默替换，任何评测分数和故障分析都失去参照。
当前 Runtime 有两类受控 Proposal 来源
ResolveAI 并没有把所有场景都强行塞进同一种 Provider 合同。当前代码存在两条路径，它们共享门禁和证据骨架，但模型职责不同。
第一条是 Fact Contract。Provider 只提取客户目标、约束、候选实体和时间事实，Prompt 明确禁止它选择动作、Tool、Policy 结果或 Workflow 转移。Runtime 校验结构后，用确定性逻辑把 Facts 与场景的受保护动作编译成候选 Decision。适合资格、时效、边界判断等需要先稳定业务事实的场景。
第二条是 Agent Decision Contract。Provider 可以从当前场景允许的集合中提出候选动作和参数，但 Prompt 同样明确：它无权决定权限、Policy 结果、Workflow 转移、发布状态、配置修改，也无权宣布业务副作用已经获得授权。响应进入 Runtime 后还要经过规范化和契约校验。
两条路径的共同点不是“模型只抽取事实”，而是：模型输出都只是受控 Proposal 来源，不是最终执行授权。
Archify 技术解释图：Facts 经 Runtime 编译或候选动作经规范化后，都必须经过模型外 Policy、Guard 与 Workflow；阻断路径跳过 Tool，允许路径才产生执行观察，随后一起进入追加式 RunStore。图解释当前代码关系，不代表生产部署拓扑。
交互版时序图还可以切换明暗主题并查看节点与连线：/demos/resolve-ai/runtime-evidence-chain/。
无效 Provider 输出为什么也要成为证据
Provider 返回格式错误、字段越界或不符合合同，并不意味着系统应该伪造一个“看起来能继续”的成功 Decision。
在 Fact Contract 路径中，Provider 原始响应先被解析成 Facts；解析失败时，结果保持为空并记录降级原因，Runtime 可以转向受约束的确定性事实解析器，再由同一个编译函数生成候选动作。Provider 尝试和后备来源都进入证据，后续可以区分“模型成功抽取”和“系统使用确定性后备”。
在 Agent Decision 路径中，Runtime 会规范化 Provider 响应、检查候选动作合同，并对特定错误执行有上限的重试。只有明确的澄清场景存在受限的确定性 clarification fallback；它不是给任意坏输出补一个成功动作。普通文本响应与 schema 无效也不会被混为同一种失败。
因此一次 Run 不只保存最终答案，还保存 ProviderAttempt：请求快照、响应、耗时、Token 使用、错误分类、重试序号和降级状态。敏感字段在进入存储前会被清理，过长输出也会受到上限约束。
这个设计牺牲了一点“结果对象的简洁”，换来故障可定位性。没有 Attempt，就无法判断问题发生在 Provider、规范化、模型外门禁、Tool，还是最终业务评测。
Policy、Guard 和 Workflow 为什么必须在模型外
候选 Proposal 进入 Runtime 后，至少经过三类确定性判断。
Policy 读取固定业务状态和结构化候选动作，计算规则是否满足，并生成规则命中证据。它不依赖模型在自然语言里自述“我符合政策”。
Guard 检查候选动作是否与场景受保护动作一致、Tool 参数是否绑定到已确认实体、Policy 是否允许，以及当前动作是否应由人工持有。任何一个边界不满足，都返回明确的 failureType 和 evidence。
Workflow 只有在 Decision 存在且 Guard 放行时才提交状态转移；被阻断的动作不会通过另一个状态更新入口悄悄改变业务状态。
真实产品截图：Guard 的 allowed、failureType 和证据单独展示。截图中的放行只证明该次候选动作通过当前本地合同，不等于生产审批或业务结果已经正确。
这三层之所以不能合并成一个“安全分数”，是因为它们回答不同问题：
- Proposal：模型建议做什么？
- Policy：业务规则是否允许？
- Guard：动作、实体、权限和人工边界是否匹配？
- Workflow：在当前状态下是否可以提交转移？
当系统把这些对象分开，日常审阅或事故复盘时就能指出最早分歧层，而不是把所有失败都归因给 Prompt。
固定上下文让归因成立
运行页面的上下文页签不只回放聊天记录。它还显示 Provider、业务状态快照、问题结构分析等必要组件，并标明哪些组件已装配、哪些由当前 Runtime 主动排除。
真实产品截图：客户对话、Provider、业务状态和问题结构被分别标记。它证明页面具备上下文审阅入口，但不是一次当前生产调用的现场记录。
这样做是为了避免一种常见误判：同一句输入在两次运行中得到不同结果，人们立即归因于模型波动；实际上变化可能来自配置修订、业务状态、候选实体或 Tool 合约。固定上下文让这些变量能够被检查。
当前实现使用本地追加式 JSONL 保存运行记录，适合实践项目中的可重放和审计，但不具备生产数据库的事务、并发、备份和保留策略证明。文章中的“不可变”指单次 Run 证据快照不被原地改写，不是对存储基础设施作生产 SLA 承诺。
Tool 成功不等于业务成功
Guard 放行后，Runtime 才会调用 Tool 或检索 Knowledge。Tool 轨迹记录调用类型、参数、执行状态和 Observation；如果 Guard 阻断，则跳过 Tool，并把阻断作为失败 Run 保存。
真实产品截图：知识检索的查询、执行状态和命中文档可回看。当前部分 Tool 与 Knowledge 行为来自本地 Harness，不代表已经接入生产系统。
即使 Tool 返回 success，也只说明调用合同层完成。业务结果仍需要单独判断，例如回答是否真正解决客户问题、是否引用正确政策版本、是否出现禁止行为，以及最终状态是否符合 Expected Outcome。
因此评测器把结果拆成几个维度：Decision 是否正确、Tool 行为是否正确、业务 Outcome 是否达标、是否出现 forbidden behavior，并记录 first divergence。RunStore 在写入前完成清理和评测；需要调查的结果可以打开 Investigation 入口，但调查、回归集和发布治理属于后续生命周期，不在本文展开。
一次 Run 最终留下什么
把整条链路压缩成可审阅对象，一次 Run 至少留下五组相互关联但语义不同的证据：
- Attempt：Provider 请求、响应、耗时、使用量、错误和重试；
- Proposal / Decision：Facts 的确定性编译结果或模型候选动作；
- Gate Trace：Policy、Guard 与 Workflow 的允许、阻断和转移依据；
- Observation / Outcome：Tool 或 Knowledge 返回，以及最终业务状态；
- Evaluation：Decision、Tool、Outcome 和禁止行为的分层判断。
这套结构解决的不是“如何让模型更聪明”，而是“如何让一次运行值得被相信、被质疑、被重放”。它让团队能够明确说出：模型提出了什么，系统为什么允许或拒绝，副作用有没有发生，结果为什么通过或失败。
验证结果与边界
本文对应的聚焦验证覆盖 9 个测试文件、75 项测试，包括事实合同、两类 Runtime 校准、Provider 规范化、Policy、Guard、Workflow、Evaluation 和 RunStore 持久化；均在 2026-09-01 的当前工作树通过。新时序图通过 Archify showcase 9/9 结构检查，并在 1440×900、1600×1000、1920×1080、2048×1320 的明亮主题，以及最小和最大尺寸的深色主题中完成实际截图审阅，无横向或纵向溢出。
当前截图来自本地演示验收，部分 Tool、Knowledge 和外部行为由 Harness 提供。企业身份、正式审批和生产 Connector 尚未接入；生产容量、故障演练、客户采用与业务效果仍待验证。
排查一次 Run 时，可以沿 Attempt、Decision、Policy、Guard、Tool 和 Outcome 找到最早偏离的位置。本地 Guard 决定当前动作是否可执行，组织中的最终审批仍需要外部身份和授权流程。