Vibhor Kumar：当AI采取行动时，什么能证明实际发生了什么？
内容提要
AI代理执行退款时，工具调用成功不等于业务交易成功。文章强调需区分执行记录与业务状态，建议用PostgreSQL事务绑定证据，确保AI意图与业务结果可追溯，并指出这是AI可靠性与未来按结果付费的关键。
延伸解读
执行记录与业务状态的区别
文章强调，AI代理调用工具成功并不等于业务交易成功。执行记录（如工具调用日志）只能证明AI尝试了某个操作，而业务状态（如退款是否实际提交）需要由权威业务系统确认。这种区分对于避免误判AI的可靠性至关重要，尤其是在涉及资金或关键业务操作时。
证据层：连接AI意图与业务结果
文章提出“证据层”概念，即通过持久化、关联的信息将AI决策与业务结果连接起来。这并非简单的日志存储，而是需要确保能够回答诸如“AI试图完成什么”“哪个业务实体受影响”“交易是否提交”等问题。实现方式包括在事务中绑定执行ID和业务状态变更，确保证据与业务结果一致。
事务边界与跨系统一致性
文章指出，真实工作流往往跨越多个系统，单一数据库事务无法保证跨系统原子性。为此，建议采用事务性发件箱模式，在本地事务中原子地提交业务状态和事件，再通过可靠的消息传递将事件发布到下游。这样，即使跨系统，也能通过相同的执行ID和实体标识保持证据链的完整性。
对AI商业模式的潜在影响
文章预测，AI成本计算可能从按token或任务转向按成功业务结果付费。届时，供应商和客户需要就“成功结果”的定义和证据达成一致。执行记录只能证明AI尝试了什么，而业务系统才能证明实际结果。因此，建立可审计的证据链将成为AI商业合同的关键部分。
Q&A
AI代理执行退款时，工具调用成功是否意味着业务交易成功？
不一定。工具调用成功只说明AI执行了动作，但业务交易可能失败或回滚。例如，AI调用退款服务后，支付操作可能失败，导致退款未实际完成。因此，需要区分执行记录和业务状态。
什么是证据层？它在AI架构中起什么作用？
证据层是连接AI决策/动作与权威业务状态的持久化关联信息。它回答诸如AI试图完成什么、哪个执行产生了动作、影响了哪个业务实体、应用了哪个策略、事务是否提交、最终状态如何等问题。它帮助企业在事后重建AI意图与业务后果之间的关系。
如何用PostgreSQL事务绑定AI动作的证据？请举例说明。
可以在同一个数据库事务中更新业务状态并插入证据记录。例如，在退款审批流程中，先更新退款状态为'approved'，然后插入一条包含execution_id的证据记录。如果状态更新成功，证据记录也会插入；如果事务回滚，两者都不会持久化。这样确保证据与业务状态变更一致。
AI执行记录和事务性证据有什么区别？为什么需要区分？
执行记录记录AI尝试了什么（如调用了哪个工具），事务性证据记录业务实际接受了什么（如退款是否真正提交）。两者回答不同问题，需要区分并关联。例如，事务回滚时，执行记录仍应保留AI的尝试，但不应有证据声称业务变更已提交。
当AI动作涉及外部系统（如支付提供商）时，PostgreSQL如何保证证据的完整性？
PostgreSQL无法跨系统保证原子性，但可以使用事务性发件箱模式：在本地事务中原子地提交业务状态和描述下一步事件的消息，然后由另一个进程可靠地发布该事件到下游，并携带相同的execution_id和实体标识。这样，PostgreSQL成为证据链中一个权威的关联环节。
为什么说AI可观测性不足以证明业务结果？
可观测性（如日志、追踪）主要用于理解系统行为，但业务证据需要更长的保留时间、与权威业务标识关联、更强的完整性保证，并可能满足监管要求。例如，日志可以显示AI调用了approve_claim()，但只有权威系统能证明索赔状态是否真的改变。因此，需要事务性证据来建立业务后果。
在按结果付费的AI商业模式中，事务性证据扮演什么角色？
当企业按成功业务结果向AI供应商付费时，双方需要就什么算作结果、如何归属以及什么证据证明其发生达成一致。执行轨迹显示AI尝试了什么，事务系统显示业务最终接受了什么，两者结合才能确定实际成功的结果，从而决定发票金额。
技术领导者现在可以如何测试其架构是否具备证据能力？
可以问三个问题：能否将AI动作与它引起的业务事务关联？能否区分AI尝试了什么与实际提交了什么？六个月后能否无需跨团队协调就能重建证据？如果答案是否定的，说明组织只有可观测性数据，但可能还没有证据架构。
