论文笔记：ACID-Compliant Agent Systems — 给 Agent 执行加上事务语义

当数据库领域的经典理论遇上 LLM Agent 执行的不确定性，会碰撞出什么？

背景：Agent 执行中途失败，谁来收拾残局？

数据库领域在 1980 年代就解决了这个问题——ACID 事务保证了一组操作要么全成功、要么全回滚，不会出现「钱扣了但货没发」这种中间状态。

但 Agent 执行和数据库事务有一个根本区别：数据库事务的操作结果是确定的，你可以精确地 commit 或 rollback；而 Agent 的每一步执行都有模型不确定性——同样一个「转账」操作，在不同状态下可能产生不同的副作用。

清华数据库组的这篇论文，核心贡献是把 ACID 语义重新诠释进了 Agent 执行的语义里。

数据库 ACID	Agent 语义重新诠释
原子性（Atomicity）	语义原子性（Semantic Atomicity）：一组操作要么全成功，要么状态完全回滚，不留副作用
一致性（Consistency）	语义一致性（Semantic Consistency）：最终状态满足预定义的不变量（invariants），而非只是「测试通过」
隔离性（Isolation）	语义隔离（Semantic Isolation）：并发执行的多个 Agent 操作互不干扰，特别是对共享状态的修改
持久性（Durability）	语义持久性（Semantic Durability）：操作结果可验证、可审计，不会因系统重启而丢失

事务性探索-执行-验证循环：每个操作先探索（plan），再执行，再验证状态一致性，任何一步失败都触发回滚。

置信度分歧验证（Confidence Divergence-based Validation）：用模型对当前状态的置信度和实际执行结果的对比来触发异常检测——当 Agent 自己对执行结果都没把握时，强制进入验证流程。

语义依赖感知的隔离：不同 Agent 的并发操作如果涉及语义相关的状态，强制序列化，而非只是锁机制。

关键数字：在广泛使用的基准上，比包括 Claude Code 在内的最先进 Agent 提升了 10.6%。

不是「让 Agent 有事务」，而是示范了如何把数据库领域的经典理论映射到新的执行场景。ACID 事务不是发明出来的，是移植过来的——这种跨领域的理论迁移，往往比纯经验性的工程优化更有生命力。

对于正在搭建 Agent 基础设施的团队，这篇论文提供了一个检查清单：你现在的 Agent 执行，有没有考虑语义原子性？状态验证依赖什么？不一致状态如何检测和回滚？

结论：把传统软件的事务理论「翻译」进 Agent 语义，是未来 Agent 基础设施的重要方向。模型能力会收敛，但事务保障方面的架构差距会成为新的护城河。