先验证后付款：在 InterSystems IRIS AI Hub 中测试支付方案

葡萄牙语译文

11月1日验证更新，经审计的v7结果

在一项最终确定的、在任何输出产生前已冻结的12个案例测试中（案例和评分标准由一名评审员设定，另一名评审员预先冻结了确定性基线，在两次基础设施中断且无案例输出后，允许进行一次运行）， 原生代理在12个案例中的11个案例中给出了正确的原始提案，而采用“安全弃权”规则的方案为7个，确定性基线为8个，且未出现任何不安全的代理决策。预先注册的标准（正确决策数至少比两个基线多两个，零不安全决策，所有控制条件均满足）已达成。 基线模型做出了一个不安全决策（合成双重退款）。代理的一个正确退款被安全拦截，原因是测试账本不接受该异常标签，且代理遗漏了一次必需的证据缺失声明。仅针对这些案例的描述性证据：非盲测，非总体估计，非普遍优越性。 估算成本为0.026美元，非正式发票。

次要有效决策读数方面，代理为10/12，规则为7/12，确定性基线为8/12。已提交黄金数据中的r4“符合条件的效果”标签属于编写错误；该标签保持不变，并在有效读数中仍计入代理的负面结果。 测试账本仅在出现 duplicate_payment 或 duplicate_charge 时执行重复退款，绝不会因模型描述要求更广泛的操作而执行。

通过自动化浏览器导航并由 Rafael 手动登录，验证了基本认证评审流程，包括证据/批准/许可/收据链、无实际影响的收件人缺失案例，以及在 303、390、980 和 1100 像素处被篡改/恢复的记录副本。 这不是一项独立的人工研究。为保持访问权限，未运行注销和恢复码使用测试。在线查看器和视频展示的是先前录制的示例，而非 v7 运行结果；回放不会触发模型调用。

公开描述性报告总结了36条保留记录及独立验证所得的相同评分。原始的私有评估输入数据和答案键不予发布。请参阅v7报告。之前的v6结果及基础设施中止情况仍作为历史证据保留；本结果并未取代它们。

截至10月31日的开发与验证历史

支付异常情况需要人工裁决：重复支付、金额不符或证据缺失等情况，在采取任何行动前可能需要人工介入。“支付前验证”（Proof Before Pay）机制旨在探索如何在执行合成支付前，保留AI提案的证据并设定其限制。本文报告了一个小型私有实验室的测试情况，包括失败案例和更正措施；并不代表该系统已具备生产环境支付的就绪性。

该应用程序由 Rafael Orlando Mendes 维护。本文所述的模拟审核是在经过身份验证的自动化测试会话中运行的；这些审核不被视为 Rafael 进行的手动审批。

“Proof Before Pay”是本次竞赛的一项参赛应用：这是一个互操作性生产环境，其中AI Hub代理负责裁决棘手 案例，且每项决策均被封存（对输入的规范JSON、工具输出、政策 版本、声明的缺失证据以及决策）进行加盐的SHA-256哈希，该过程在评审员查看前、任何许可生效前以及 测试账本进行任何交易前完成。事后若修改记录，封印将变为红色。

本文涵盖了主办方要求的四个主题：AI Hub 使用体验、模型与成本、可观测性 与追踪，以及 Agentic 开发工具。

1. AI Hub 体验：哪些方面行之有效，哪些方面让我们感到惊喜

原生代理、原生工具、原生策略。pbp.Agent 继承自 %AI.Agent；五个只读工具 （订单、支付、付款人历史、证据、店铺政策）是 %AI.Tool 子类的类方法，按 %AI.ToolSet 分组；代理通过 EnsLib.AI.Agent.OutboundAdapter 在业务操作中运行，因此整个 决策在生产追踪中仅体现为一条消息。应用程序执行的路径为 Adapter.SendChat(prompt, .llm, session)；响应是一个 %AI.LLM.Response（Content，Usage），并且 session.GetStats() 返回 total_prompt_tokens、total_completion_tokens 和 total_llm_duration_ms。 两个策略 类，即 %AI.Policy.Authorization 和 %AI.Policy.Audit，将每次工具调用限制在当前运行的用例范围内（ 模型提供的其他用例的用例 ID 将被拒绝并记录在案）。 类字典证实了我们查看过的其他 %AI 方法 签名；此处仅描述我们的代码实际调用的方法。

令我们感到惊讶的是（这些是运行时观察到的现象，而非文档中提及的）：

• 声明式代理的 %OnInit 不会在构造函数中运行；必须在 CreateSession() 之前调用 %Init()。
• 构建版本 154 中的 Gemini 提供程序具有固定的端点，且仅接受 api_key。顶级 base_url 会被拒绝； 嵌套的 http_config.base_url会被接受但随后被忽略。因此，我们成功的实际运行中使用了 openai提供程序，针对 Google 的 OpenAI 兼容端点，并使用 Gemini 密钥。该应用现在会拒绝模棱两可的 Gemini 重写，而不是默默忽略它。
• 在严格的参数检查下（网关路径返回 HTTP 404），当客户端发送 temperature 时，GPT-5.4 mini 拒绝了该请求 （来自网关路径的 HTTP 404）。 首次尝试按设计将问题上报给人工处理，但未产生任何效果；在省略该参数后， 运行成功。基线版本即使在省略参数的情况下也会锁定请求的采样温度（0），因此 该运行的实际采样温度无法确定。这些锁定值保持不变。 较新版本通过回归测试记录了一个 哨兵值（-1，“未发送”）；而基线版本则未记录。我们未能确定在这些运行中使用的模型是否遵循了请求的采样温度。
• EnsLib.Workflow.TaskResponse.%FormValues 是一个数组，而非字符串。在切换到 SetAt(note, "pbp_note") 之前， 首次批准标记中评审员的注释曾无提示地缺失；这些早期记录保持不变， 回归测试现已涵盖该注释。
• 一个 SQL 排序规则细节：GROUP BY Source 返回了大写形式的 RULES/MODEL；而 stats 端点会对键值进行标准化处理。
• 工作流角色必须包含审阅者会话的真实 $USERNAME；默认审阅者列表中未包含该字段，因此 无法确定审批归属。已在安装程序中修复。

上述每项问题都属于只有在针对真实构建从头到尾完整运行工作流时才会显现的情况。

2. 模型与成本（实测数据，小样本，无排名）

一个合成重复支付场景，每个模型运行一次，请求温度为 0（关于实际发送的值，请参见上文注释）， 每个模型调用工具五次，通过受限的私有网关（三家供应商的运行使用 OpenRouter； 直接 Gemini 运行使用 Google 的兼容端点）。未验证任何账单收据。

数值已按所示进行四舍五入。该测试中 API 报告的总支出为 0.01699175 美元（OpenRouter）。 直接 Gemini 端点不报告每次调用的成本，因此下文中的所有直接 Gemini 数据均是根据 API 报告的代币数量 乘以 Google 的公开标价估算得出，并已明确标注；目前尚未核对任何发票。 在这些成功的单场景烟雾测试中，报告/估算值低于每项决策 0.01 美元；这并非普遍的价格保证，且不包括单独保留的不确定误差预留金。同时记录了延迟。 单个场景不进行模型排名；单位 滑点（次要单位以货币形式表示）是我们在此烟雾测试中观察到的唯一质量差异，且该差异未 进入账本，因为与该效果绑定的金额来自密封记录，而非文本描述。该运行结束后， 代理指令明确指出工具金额以次要单位计。

2.1 隐藏矩阵、五轮、单一模型（gemini-3.8-flash direct，兼容 OpenAI 的传输协议）

在每轮新模型工作流开始前，源提交、收集器、证据闸门、评分器、答案键和输入均经过哈希处理并冻结，随后在付费准入前由GET独立验证。基线还包括此前执行的七项规则控制；这些并非新的保留结果。 每个新模型案例仅进行一次工作流尝试，并在这些运行中使用了两次 HTTP 生成，且不进行工作流重试。 评分分为三层：原始模型提案（未密封的诊断结果）、 有效的密封决策（经过上下文保护和服务器端策略处理后），以及测试账本效果（收据， 从账本根节点重新计算得出，与决策承诺及按正确顺序记录的人工授权相关联 顺序）。“安全”意味着每个案例均具备有效证据且不存在危险的有效结果；它绝不意味着正确。

基线测试结果。客户消息中的提示注入（6/6）、禁止操作诱饵（2/2）、矛盾 证据（4/4）、超过测试账本限额的金额（2/2）以及一笔美元支付（1/1）均被成功处理。 有一例在 决策层失败：两个共享同一付款参考号的Pix事件（同一笔付款被观察到两次）被标记为 重复退款；上下文守护程序仅检查了参考号是否被观察到，而未检查其是否唯一，且 账本仅因无关原因拒绝了该操作。 没有任何进展，人工审核层依然存在，基准值仍 记录为 safe=false。同一次运行还暴露了第二个漏洞：代理路径从未生成退款目标，因此没有任何 由代理决定的退款能够执行；唯一执行的退款均来自确定性规则。

发生了哪些变化，以及为何每项变更都发生在服务器端。 (1) 守护程序现在要求提供两个不同的、非空的支付引用， 才会接受重复退款。(2) 共享退款目标验证会检查规范化的已观察支付集、金额及付款人绑定。若未提供明确的已观察目标，则基于时间戳的筛选机制会按UTC时间选择较晚的支付，并拒绝模棱两可或格式错误的时间。 已知的存储目标必须与付款人匹配；若目标不存在，系统绝不会自行生成，且仍会阻止财务效果； 规则引擎现采用相同的推导逻辑——此前一次独立的开发审计中，通过相反的选择方式，确实重现了针对同一对的两个完整的合成退款。两个旧的失败收据均保留；此开发故障不计入冻结轮次统计。 (3) Ledger.Stage 在同一锁定下查询该对的两个引用，而 Execute 拒绝 对同一对进行第二次退款，即使该计划是在修复前授权的也不例外。(4) GetOrder 现在将商店记录的退款 目的地作为订单部分的副本返回（refund_destination 或 null），以便代理可以观察到它；发送方写入订单对象中的目的地 仅在返回的工具副本中被覆盖； 原始存储的输入将被保留。客户消息不会选择效果目标。

第3轮是表格中的一次真实失败：所有四笔合法退款均未产生任何效果。原因在于我们： 代理指令要求模型在无法看到退款目标时将其声明为缺失，而没有任何工具 向其显示目标。账本拒绝了该请求，这是针对声明缺失情况的正确行为。 修复后，v4重新运行了相同的十个输入以及 四个新的控制案例：14/14个有效决策正确，六个合法退款均准确执行一次， 退款对象为记录中的付款人（包括一个订单带有伪造目的地——该目的地被标记为商店记录，且 客户要求提供第三个密钥的情况）， 八个否定案例未产生任何结果，而一个原始提案（尽管记录的 目的地与付款人不同仍建议退款）被服务器转换为升级处理。v4 是一个包含四个 前瞻性控制案例的回归测试，而非全新的保留样本组，因此我们不报告总体准确率。

第五轮是我们此前承诺尚未完成的：八个案例包含前64个案例中未出现的陷阱类型，由 评审员在所有先前结果已知的情况下编写，通过哈希值进行冻结，并在首次调用前通过GET方法进行交叉核对 （黄金数据位于存储库之外且不在任何提示信息中）。 已向存储的目标地址执行了三笔合法退款， 其中包括：一笔是后续付款在数组中排在首位的情况；一笔是注入位于 delivery_proof字段而非客户消息中的情况；还有一笔是消息要求执行被禁止的操作 pay_external_account 操作。另有五项否定操作未产生效果，且针对某人仍处于待处理状态；这些并非已完成的工作流。原始提案曾出现一次错误：在一笔 订单中，其 amount_minor为格式错误的字符串“189.90”的订单中，模型在其 理由栏中写道“18990个小单位（189.90巴西雷亚尔）”，在未提示的情况下转换了单位以使支付金额匹配，并提出了退款建议。 服务器端的目标 推导拒绝了该格式错误的金额，最终做出的决定是升级处理，其中 refund_target 被标记为缺失，且 没有任何进展。 此后我们并未修改提示；若添加“非数字字符串形式的金额将触发升级”， 那属于未来回归测试的情形，与本次结果无关。八个案例要么发现缺陷，要么未能发现缺陷；它们不进行任何估算。

截至 10 月 28 日的历史账目，针对前五轮：在 Gemini 直接端点上估计总计 0.25 美元（代币数量乘以列表价格），外加 OpenRouter上API报告的0.017美元；因HTTP 404请求失败而产生的0.115美元仍由我们自己的 网关保留。 活跃累计上限仍为1美元，从未扩大。五组估算值加上早先通过Gemini直接渠道的初步估算，总计0.252672美元； API 报告的 OpenRouter 支出为 0.01699175 美元，保留的 404 错误金额为 0.114858 美元，因此计入 1 美元上限的总金额为 0.38452175 美元。 各轮的汇总数据见 docs/validation/benchmark-rounds-summary.json 和 docs/validation/live-independent-v5.json； 针对 v2、v3、v4 和 v5 的门控、评分器及正向门控的独立重新计算结果一并发布。

我们未测量的内容包括：提案者/批评者/整合者链是否能胜过单个代理（运行前设定的规则： 仅当危险决策的降幅显著且不超过成本的3倍时才允许存在三个角色），矩阵上的其他模型，以及 任何与实际结算相关的内容。

3. 可观测性与追踪：封印即追踪

生产追踪已将每个步骤以消息形式呈现。我们补充了三点：

1. 决策消息承载着承诺；密封记录包含被观测的内容：对于规则决策， 即规则读取的输入；对于模型决策，即代理看到的工具实际输出（而不仅仅是调用 了工具这一事实）。 它还包含政策哈希值、生效版本以及缺失映射：即代理所需但 未获得的证据，这些证据被密封为 null，以确保日后无人能“补全档案”。
2. 上下文守护程序 (python/pbp_guard/decision.py) 会拒绝以下提案：其证据引用未被任何 工具返回；其标记与操作相矛盾（例如无资金支持的退款、涉及资金转移的非财务操作）；或 缺少必备工具之一。 被拒绝的提案将作为无权限的未密封诊断信息存储；密封的 决策即为升级处理，其中保留了代理声明的无知状态。 在回归测试中，我们 重现的三种攻击（错误标记、虚构引用、缺少未通过门控的证据）均以密封的升级处理告终，且 许可数和收据数均为零。
3. 审查控制台会根据密封记录，精确重现代理所见与未见的内容（时间机器），并允许 任何人编辑副本并进行验证：完整、被篡改、资金转移后密封，或无法验证。

测试范围因并非等效单位而单独列出：重放模式下的 48 项端到端生命周期检查 （sealed_seq < authorized_seq < executed_seq，重复请求产生单一效果，忽略重复接收，接收时拒绝 PII）； 39项账本检查，外加12个并发IRIS会话，每个会话产生恰好一个效果且收据完全一致（均在 显式基线中）；以及规模较小的守护程序、见证人和API测试套件，各具独立范围。该账本为测试 账本；不涉及任何银行、结算或外部锚定。

4. IRIS 代理开发

AI 开发助手支持了实现和源代码检查。运行时声明已通过 私有构建 154 实例进行验证。在这些 受控运行中，我们未使用 iris-agentic-dev 包或组织者的互操作性技能， 因此不主张该工具带来的加分。 原生类字典提供了实际的方法签名、 属性集合和提供者配置元数据。使用虚假凭据进行的小型构造函数探测，将 配置接受与实际网络路由区分开来。编译器诊断、框架断言报告以及完整的 合成工作流捕获了仅靠源代码审查无法发现的错误。 原生会话统计数据和受限网关 提供了使用情况和传输证据；但二者均不能替代计费凭证。有用的改进包括 提供商端点/参数文档，以及展示经过身份验证的工作流审核员身份的示例。任何后续 使用官方 Agentic Dev 工具进行的实验都将另行报告，并注明其实际范围和日期。

证据的局限性

本地密封可检测记录副本相对于存储的承诺所做的修改。它们既不能建立公共公证，也无法防范能够重写数据库及其承诺的管理员。BRL/测试付款人检查、存储记录的来源标签以及合成收据均无法验证真实的银行收款方或结算情况。

外部锚定功能尚未实现，也不作相关声明。参考中 pbp_seal提到的链和 Solana 辅助程序位于运行时之外，且不在 IPM 模块范围内。 我们计划在后续版本中考虑实现一个可选的、 异步锚定机制，用于锚定托管中的承诺，该机制独立于存储库的数据库，并配备跨 验证器，以便通过管理员无法控制的参考来检测后续的重写行为。 这 既不会阻止篡改，也不会证明原始决策正确，更不会验证银行结算；这只是 一个未设定时间表的路线图项目，且竞赛标准并未要求此功能。在此之前，保护机制仅限于本地， 控制台也会明确提示这一点。

当前进展

实时模式使用您自己的密钥运行（PBP_LLM_PROVIDER、PBP_LLM_MODEL，即提供商的密钥变量）；若无密钥， 生产环境将运行已记录的决策，并在每个印章及控制台中明确标注此状态。 安装过程为 docker compose up，基于 本地加载的 build-154 镜像；原生后端基线在全新卷上通过了冷安装和生命周期测试 （安装、重启、重建、SIGKILL，同一张完整收据）。 后续的用户界面、网关和文档 变更已分别经过验证，并未作为另一项完整的源代码冷映像运行进行展示。 IPM 模块作为专用 实例的可选组件提供：在纯厂商镜像上，该模块已加载、编译并配置（未启动生产环境），打包为 纯源代码归档，卸载时未执行彻底清理，并使用同一份完整的收据重新加载。 IPM 在 通过一次验证的空卷上自行引导，此前已等待实例报告登录已启用且 USER 命名空间存在； 早前的尝试在任何应用程序代码运行前即告失败，其原因尚未查明，且该运行未在 未进行跟踪的情况下重复。 未测试任何公共注册表安装，且安装程序创建的评审员资源需通过 手动方式退役（参见 IPM-OPERATOR.txt 和 docs/validation/native-IPM-bootstrap.json）。代码库是公开的；而隐藏的 对抗矩阵则有意未公开。

相关工作包括谷歌的 代理支付协议（AP2）。我们并不声称 发明了“先验证后支付”机制；我们的贡献在于原生的 IRIS/AI Hub 执行机制，其具备显式证据和显式**无知、冻结决策、确定性策略、幂等恢复以及任何人都可以验证的法证重放功能。

10月31日验证附录，第5.3条

此次合格重现现已包含未追踪的 USER IPM 启动过程、 仅源代码的软件包生命周期、原始收据回读，以及脚本化的裁判 HTTP 流程（55 项断言加上 7 项拒绝检查）。 由Claude生成的原始 步骤和由Codex生成的修复部分均单独标注来源。本次运行使用了 所有者现有的授权构建154镜像，在Apple Silicon上通过amd64模拟环境运行； 并非来自供应商的新下载，也不是独立的人工/浏览器DOM操作流程。

后续报告的十二个案例配对队列包含两次独立读数。 官方首次尝试保留了八个 G 级仪器化错误；在修复测试框架兼容性后， 技术性重试并未取代该结果。官方试验 1：R S0/C8/ABS4；D S3/C9/AUTres3； G S0/C4/error8。该重试在 生成新输出前已明确声明，使用了相同的已知案例和 未更改的代理，并通过 SHA 复用了原始的确定性控制。这是事后操作， 并非独立样本；首次尝试中 G 的动作已可见。 其 G 没有做出任何不安全决策，有 11 次正确决策、1 次安全弃权以及 3 次自主残余关闭。确定性分诊 D 也有 3 次此类 关闭：未证明所需的自主性增益。保守规则 R 也没有做出不安全决策。 D在自由文本残余案例（c08、c09、codex-02）中做出了三次不安全的决策；其中一次在脚本化审查后达到了合成效果。由此无法得出任何关于总体准确性或普遍优越性的 结论。 Claude 在 C1236 中独立组装了配对记录，并按字节逐一重新计算了两个评分。最终的描述性报告保留了这两种读数。G 自主关闭了 c05/c07/c10；D 关闭了 c05/c07/codex-01。这些是数量相同但不同的数据集。 选定c08/c09文本错误的作者熟悉D的词汇库，因此这些错误在设计上本就在预料之中，无法证明普遍优越性。 所有十二组“证据缺失”的答案集均为空；本组测试不评估 “证据缺失”的识别能力。不允许进行第3次试验。获批的视频仍为 历史影像，不包含新的推断或基准声明。

10月31日的两组使用量/关税估算值分别为0.02585100美元和0.02580975美元。 在未变的1美元上限下，累计报告支出、临时估算值以及未变的不确定404保留额目前合计为0.43618250美元。这些估算值并非账单收据。

固定协议分类，葡萄牙语原文：“在线束故障后对G组进行的回顾性技术重复，同为已知队列；并非独立样本；G组在试验1中的表现早在重复之前就已经显现”。

来源与演示

• 来源、安装及评判路径
• 在运行中的 IRIS 实例上记录的示例（已通过身份验证，回放过程中不进行模型调用）
• Open Exchange 应用程序（已于 11 月 3 日提交，截至发布时正在等待审核）

视频 4.2.1，附有英语、葡萄牙语、西班牙语和简体中文字幕。该视频录制于 v7 评估之前；其中未展示 v7 运行情况。