AI decision models
一层尚未被审计的新中间件
一种模式正在成型：AI 代理在执行任务途中，需要确认交易对手是否被制裁、某供应商的 SOC 2 声明是否仍在有效期、或某个钱包是否被标记。它不再等人工去查，而是按次购买一份带签名的证明——通过 x402（基于 HTTP 402 的微支付流程，在 Base 上结算）用稳定币付款——然后继续执行。
这确实是有用的基础设施。但目前它大体上仍是一套未经审计的基础设施。链只提供结算与来源追溯，不提供事实真相、法律效力，也不提供审计师会认可的内部控制。这些必须由你在自己这一侧工程化地构建出来。
本清单面向需要为上述工程签字放行的人。每一项只有通过或不通过，没有部分得分，也不看感觉。
预言机是什么，不是什么
合规预言机返回的是关于某个主体的机器可读声明：判定结果、schema 版本、签发方、时间戳、有效期。做得好的会附带签名，让你可以离线验证；做得差的只是一个挂着漂亮 logo 的 JSON 接口。
它不是什么：它不是法律意见，不能替代你自己的尽职调查，也不能单独作为提交给监管机构的抗辩材料。「链上验证」是一句架构描述，不是合规论证。
图示：来源页预览图（仅作编辑上下文；版权归属原发布方） · 来源引用：github.com
12 项检查清单
1. 证明来源
通过： 每个响应都携带签发方标识（DID 或地址）、schema 版本、签发时间、有效期，以及一个由你自己的服务用固定密钥离线验签的签名——而不是用同一个提供声明的接口取回来的密钥。
不通过： 你信任 TLS 连接，并把这叫作验证。
2. 声明的语义
通过： schema 已公开，判定值是枚举的，并且存在一个明确的「未知／数据不足」状态，在结构上与「拒绝」区分开。否则代理一定会把两者混为一谈。
不通过： 自由文本判定、未文档化的枚举，或一个布尔值。
3. 时效与吊销
通过： 最大陈旧度在合约中写明，存在吊销或 epoch 机制，且客户端在代理看到证明之前就拒收过期证明。
不通过： 证明没有有效期，或者有效期从来没人校验。
4. 支付完整性
通过： 可以按次、按会话设置价格上限；支付路径具备防重放；每笔支付映射到一个幂等键，使得重试的工具调用不会被重复计费；支付凭据能与响应 ID 在你的账本中对账。
不通过： 代理内部存在超时后再次付款的重试循环。
5. 结算与私钥风险
通过： 你对 Base 的最终性假设有书面记录，监控超过阈值的重组，付款私钥存放在 KMS 或 HSM 中并设有硬性支出上限与无限额度授权。
不通过： 代理的运行环境里放着一个有余额的热钱包和一笔宽松授权。
6. 失败即拒绝的默认值
通过： 预言机不可用、超时、签名不匹配、预算耗尽，全部收敛为「阻断」或「升级给人工」，绝不收敛为「放行」。这个默认值在策略层写一次，而不是写在提示词里。
不通过： 验证失败后由代理自行决定怎么办。
7. 工具调用加固
通过： 验证步骤在你的服务中执行，位于模型上下文之外。模型只拿到一个布尔值加一条带签名的证据引用，不能读一段 JSON 然后推理出「看起来没问题」。工具参数在发起付费调用之前先做 schema 校验。
不通过： 把证明贴进提示词，让模型自己打分。
图示：HEXOPS 原创配图（受选题启发，非复制原文图片） · 来源引用：github.com
8. 数据最小化
通过： 在签发方 schema 允许的范围内，发送哈希化或令牌化的主体标识。任何可识别个人身份的信息都不写入 calldata，日志中对主体做脱敏。
不通过： 姓名、出生日期或证件号码出现在一笔永久且公开的交易负载中。
9. 可审计性
通过： 每条决策记录保存请求哈希、响应哈希、签发方、验证器版本、支付交易引用与判定结果，保留期限符合你所处监管体系的要求，并且无需供应商配合即可导出。
不通过： 证据只存在于保留 14 天的应用日志里。
10. 签发方与辖区适配
通过： 你知道签发方作为法律实体是谁、其声明对应哪些制裁名单或框架、这些名单多久刷新一次，且你方合规职能已对该映射签字确认。
不通过： 团队里没人能说出签发方的监管机构或数据来源。
11. 成本与延迟预算
通过： 已在接近真实并发下测得 p95 延迟与单次调用成本，在预算上限处设置熔断，并对「单次决策成本」的漂移设置告警。
不通过： 支出无上限，只有在代理对着不稳定接口死循环时才被发现。
12. 退出方案
通过： 可以接入第二家签发方，响应格式可移植（或可轻松映射），合同允许迁移并导出数据。
不通过： 单一预言机、专有 schema、无法导出。
如何给结果打分
诚实地数通过项，写在纸面上，并记录每一项由谁核验。
- 12/12 —— 可以放行到受监管的决策路径。
- 9–11 —— 仅以咨询模式或人工在环模式上线，每个缺口都需记录为补偿性控制并指定负责人。
- 8 项及以下 —— 不要让这套东西接触受监管的工作流，只用于内部初筛，并置于硬性阻断之后。
出现这些信号就该放弃
- 签发方无法或不愿说明签名如何离线验证。
- 定价不透明或没有上限。
- 官方文档里唯一的集成方式是「把 API key 放进代理环境变量」。
- 没有吊销机制——上个季度为真的状态仍被当作当前状态返回。
- 营销话术围绕「链」展开，而不是围绕数据源展开。
关键要点
- Base 上的 x402 解决的是机器对机器合规查询的支付问题，不解决保证问题。
- 杠杆最高的单项控制是失败即拒绝：无法验证的证明必须阻断，而不是放行。
- 验证应属于你自己的服务层，绝不放进模型上下文——否则一次提示词注入就能和它辩论。
- 真正的交付物是可审计性。如果离开供应商就无法导出证据，那这项控制并不属于你。
- 把签发方当作交易对手而非权威：明确它是谁、把它的声明映射到你的义务，并保留第二来源。
下一步
- 为十二项各指定一名负责人和证据交付截止日。
- 搭一个桩预言机，分别返回被篡改、已过期和未知的判定，确认你的代理在这三种情况下都会阻断。
- 在第一次生产调用之前写好支出上限与幂等策略，而不是之后。
- 本迭代就把决策记录 schema 加进数据模型；事后补审计轨迹的代价高得多。
- 每当签发方、schema 版本或结算链发生变化，重跑这份清单。
来源
- Algernon — 基于 x402、运行在 Base 上、面向 AI 代理的 B2B 合规与安全预言机：https://github.com/tobiaslofton/algernon-x402-oracle
