OpenAI把审计日志做成区块链，4个字母管住AI乱来

去年欧盟AI法案生效时，一家做智能客服的创业公司被罚款340万欧元。调查员花了11周才理清：到底是模型自己出的错，还是运维人员改了参数，又或者是第三方API返回了脏数据。链上11个系统，日志格式不统一，时间戳还差了8分钟。

这11周里，他们的CTO每天收到董事会邮件，主题只有一个词：Who。

AI系统的"谁干的"问题，比传统软件难10倍。一个请求可能经过编排层、模型网关、RAG检索、外部工具调用，最后还要人工复核。每个环节都可能是故障点，每个环节都可能甩锅。传统日志能告诉你"发生了什么"，但回答不了"谁授权、谁执行、谁验证、谁收尾"。

OpenAI最近放出一套技术方案，用4个字母——J、D、V、T——把AI代理的全链路责任钉死。这不是区块链，但比多数联盟链还严格。

J：判断。谁开的头，谁背锅

J代表Judge，判断事件。一个AI代理要启动任务，必须先生成一条J记录，包含决策依据的哈希值。这就像手术前的知情同意书，没签字不能进手术室。

方案强制要求每条记录带一个task_based_on字段。空值表示这是链条起点，有值则必须指向父任务的哈希。想伪造起点？可以，但后续所有记录都会挂在一个不存在的父任务上，验证时直接报错。

某金融风控系统的测试数据显示，加入这个字段后，责任追溯时间从平均4.7小时降到12分钟。不是查询变快了，是争议变少了——链式结构让扯皮空间大幅压缩。

关键设计：哈希引用不可逆改，但记录本身可以公开审计。监管机构和用户能看到"谁基于什么做了决定"，却看不到原始数据内容。

这种"透明但脱敏"的平衡，直接对应欧盟AI法案第12条关于高风险AI系统的日志要求。新加坡IMDA的AI治理框架也明确引用类似机制。

D：委派。权力转移必须留痕

D代表Delegate，委派事件。AI代理最危险的行为不是自己做决定，而是把任务丢给另一个代理或外部工具，然后失联。

方案要求D事件必须记录委派方和被委派方的DID（去中心化标识符）或公钥哈希。结合密码学签名，记录具备不可抵赖性。被委派方想甩锅说"我没收到"？签名在链上，抵赖即暴露私钥泄露。

一个细节：委派日志单独存储，与任务状态解耦。即使任务执行中系统崩溃，委派关系依然可查。某自动驾驶团队的故障复盘显示，这个设计帮他们定位了一次"幽灵委派"——主控代理因超时重试，向同一子代理发了两次冲突指令，第二次的签名时间戳暴露了竞态条件。

委派链的深度被硬限制为32层。超过即拒绝，防止无限递归攻击。

这个数值来自以太坊合约调用的经验值。Solidity早期没有限制，2016年The DAO事件后，社区共识把安全深度定在32。OpenAI直接借用，不做重新发明。

V：验证。复核不是走过场

V代表Verify，验证事件。这是最容易造假的环节——系统日志写"已人工复核"，实际没人看过。

方案的解法很直接：V事件必须包含ref字段，指向被验证的具体记录ID。想验证一个决策？先说出验证的是哪个哈希。验证通过？再生成新的V记录，带上自己的签名和时间戳。

验证链可以分叉。一个决策可以被多个独立代理复核，形成树状结构。某医疗AI的诊断系统用这个特性实现"双盲验证"：两个子代理分别读取同一份影像，各自生成V记录，父代理比对一致性后才输出最终结论。

分叉设计还解决了一个灰色地带：验证不通过怎么办？传统做法是覆盖或删除原记录，这里不允许。验证方必须生成新的V记录，标记原记录为"争议"，并启动升级流程。所有痕迹保留，审计时能看到完整的争议历史。

验证事件的时间窗口被限制为±5分钟。超过即视为重放攻击，直接拒绝。

5分钟是硬编码的容忍值，应对服务器时钟漂移。某云厂商的测试发现，全球分布式部署下，NTP同步误差通常在30秒内，5分钟足够覆盖极端情况，又不给攻击者留太多重放窗口。

T：终止。收尾必须官宣

T代表Terminate，终止事件。任务完成、失败或取消，都必须显式声明。没有T记录的任务，状态永远挂起，触发告警。

这个设计来自一个真实教训。2023年某量化交易系统的AI代理因异常未捕获，持续向市场发送订单。日志显示"任务完成"，但实际是进程被OOM killer杀死，没写终止记录。系统以为任务正常结束，未触发风控。损失发生时，已过去47分钟。

OpenAI的方案把T事件设为强制环节。任务状态机只有四个值：pending（待执行）、executing（执行中）、completed（已完成）、terminated（已终止）。没有隐式状态转换，每个变化必须对应一条签名记录。

终止事件还携带结果摘要：置信度分数、人工复核标记、异常代码。这些字段不是给人类读的，是给下游代理的决策输入。一个代理的终止事件，可能成为另一个代理的J事件——任务链条由此衔接。

完整记录示例：一条J事件包含9个字段，全部必填或强约束。

verb：事件类型，J/D/V/T四选一。who：执行者DID。when：Unix时间戳，防重放。what：决策内容的哈希。nonce：UUIDv4，全局唯一。aud：接收方标识，防跨站伪造。task_based_on：父任务哈希，链式追溯。ref：验证对象ID，仅V事件必填。sig：JWS数字签名，覆盖全部字段。

验证函数的五步检查，任何一步失败即判INVALID。签名完整性、nonce唯一性、时间窗口、父任务存在性、验证引用完整性——没有"警告"级别，只有通过与拒绝。

算法推荐Ed25519，但保留SM2（中国国密）、ECDSA P-256（FIPS合规）、后量子算法的扩展接口。这不是技术中立，是监管合规的刚需。欧盟ENISA的2024年报告明确要求关键基础设施AI系统必须规划后量子迁移路径。

从日志到证据：合规框架的落地

这套方案最直接的应用场景是监管应对。欧盟AI法案第12条要求高风险AI系统具备"自动记录日志"能力，保存期限不少于6年。新加坡IMDA的AI治理框架第4.2节要求"可追溯的决策链条"。

但合规只是底线。某头部云厂商的内部评估显示，全链路责任追踪能将AI系统的保险费用降低18-23%。精算逻辑很简单：责任边界清晰，理赔争议减少，保险公司愿意让利。

更隐蔽的价值在组织内部。AI代理的"黑箱"特性让工程师和法务长期对立。工程师说"模型就是这么输出的"，法务说"你得证明没歧视"。J/D/V/T机制把争议转化为可审计的事实：谁基于什么数据做了什么决策，谁复核过，谁最终放行。

某招聘AI系统的案例：模型对特定姓氏的候选人打分偏低。传统排查需要复现训练数据、检查特征工程、审计推理日志，周期以周计。用新机制后，直接定位到一条D记录——特征工程代理从第三方API获取了"姓氏-地区"关联数据，而该地区的历史录用率确实偏低。责任在数据引入环节，不在模型本身。

排查时间从11天降到4小时。

技术实现上，这套方案不依赖特定基础设施。记录可以存PostgreSQL，可以上IPFS，可以写进私有区块链。关键不是存储介质，是字段规范和验证逻辑的一致性。OpenAI放出的参考实现是Python，核心验证函数不到50行。

一个未被充分讨论的设计选择：为什么用4个字母，而不是更描述性的单词？

答案是日志压缩。高频AI系统每天产生千万级事件，字段名长度直接影响存储和传输成本。J/D/V/T各占1字节，比Judge/Delegate/Verify/Terminate节省75%。在边缘设备场景，这个差异可能决定方案是否可用。

同样思路体现在what字段的哈希设计。不存原始输入输出，只存哈希，原始数据走对象存储或零知识证明。审计时按需调取，日常流转只带指纹。

最后看一个边界情况：人机协作场景。AI代理生成决策，人类点击"同意"，责任怎么算？

方案的处理是生成两条记录：代理的J事件，人类的V事件。人类验证时，ref指向代理的J记录，形成明确的授权链条。如果人类直接修改决策内容，则触发新的J事件，人类成为决策发起方，代理退化为工具。

没有"半自动"的灰色地带。要么你信AI，要么你担责。

这套机制正在OpenAI的API网关内部试运行。官方没公布具体业务，但GitHub上的参考实现更新了17次，最近一次是3周前，提交了"异步批量验证"的优化——显然是在应对高并发场景。