并发Agent系统的有状态治理
Stateful Governance for Concurrent Agentic Systems

论文的出发点是Agent正在从"给建议"转向"直接执行有真实副作用的操作"——退款、库存预订、云资源分配、资金转账。这类操作天然存在并发：多个Agent、多个用户请求可能同时争用同一份预算、同一批库存、同一个待审批流程。现有的安全护栏（无论是基于规则的策略引擎还是Cedar这类策略语言）几乎都只在请求到达的瞬间读取一次状态、做出allow/deny判断，然后就把这个判断当作永久有效的授权来执行。但真实系统里，从"判断"到"效果落地"之间存在时间窗口，窗口内状态可能已经被别的并发请求改变——预算被花光、库存被别人订走、审批被撤销。论文把这种"授权依据已经失效但系统仍然执行"的现象定义为stale authorization，并指出这不是某个具体bug，而是"请求时决策"这一范式本身的结构性缺陷：策略语言表达能力再强，只要执行机制不管状态在决策后如何演变，陈旧授权就必然发生。论文进一步提出了可形式化验证的正确性条件——policy-state serializability（PSS）：并发执行产生的历史必须存在一个等价的串行历史，使得每个终态决策都匹配它在串行顺序中所处位置之前的策略状态，被允许的操作才产生效果，被拒绝的操作不产生效果，且最终效果与状态一致。

论文没有让策略作者在每条规则里手写并发保护逻辑，而是划分了清晰的信任边界：Agent与Agent框架被视为不可信调用方，Provenact运行时与"策略状态供应商"（policy-state provider）被视为可信方。策略程序通过一份"认证的策略状态视图契约"（certified policy-state view contract）声明它需要读取哪些状态、这些状态提供什么一致性保证，以及效果提交时需要哪些状态足迹（footprint）解析器和可信执行器。运行时在编译期做依赖与作用域的静态验证（要求策略表达式类型良好且有界），在请求到达时把这些抽象依赖解析成具体的作用域集合。

真正解决陈旧授权的是"作用域执行"（scoped enforcement）机制，提供两种模式：事务模式（transaction mode）——把决策读取和效果提交包在同一个事务边界内，用作用域锁（scoped locking）处理重叠的逻辑作用域，配合幂等记录处理重试；预留模式（reservation mode）——先为将要消耗的资源打一个预留标记，决策通过后再把预留转为实际提交，允许其他不冲突的并发请求继续推进而不必等锁释放。

对于人工审批这类天然要跨越较长时间窗口的操作，论文把它处理成"分阶段治理操作"（split-phase governed operation）：审批发起时对相关状态打预留或后续重新验证的标记，审批通过后再决定是直接提交（若状态未变）还是要求重新验证（若状态已变）。这让"长时间挂起的审批"和"高并发的无关操作"可以共存，而不是简单地用一把大锁把整个系统串行化。

最关键的一组对比是RQ5：现有的两个Agent框架（AGT、Omnigent）各自的原生成本控制机制能保护自己的预算状态，但对外部团队预算、库存这类跨系统状态完全无感——Omnigent的批准保留率甚至低至1.6/20.8，说明并发审批场景下几乎所有审批都被悄悄作废却仍然执行了效果。Provenact不是靠更聪明的策略语言，而是靠把状态一致性检查下沉到运行时的效果提交路径上，用同样的0违规结果同时覆盖了事务模式和预留模式两种不同的并发处理哲学。

这篇论文瞄准的时间点很准：只要Agent还停留在"给建议、人做决定"的阶段，请求时鉴权够用；但一旦Agent开始直接触发退款、下单、转账这类不可逆副作用，"决策时状态"和"效果落地时状态"之间的时间差就会从理论风险变成生产事故来源，而且是那种极难在测试环境复现的并发时序bug——正如论文RQ1里刻意构造的"完全冲突场景"所展示的，问题只在高并发争抢下才会暴露，日常低并发测试很可能永远发现不了。

和我关注的duplex agent方向做个类比会更清楚问题的普遍性：duplex agent要解决的是"交互层的实时响应"与"思考层的深度推理"之间的时序错配——回复已经说出口，但支撑这个回复的推理状态可能已经过时；Provenact要解决的是"策略决策"与"效果提交"之间的时序错配——授权已经给出，但支撑这个授权的资源状态可能已经过时。两者本质上都是"承诺（commitment）发生的时刻"与"承诺所依赖的状态仍然有效的时刻"发生了分离，区别只在于一个是语义/推理层面的过时，一个是资源/权限层面的过时。这提示了一类更通用的系统设计原则：任何允许异步、并发、长时间挂起（审批、多轮推理）的Agent系统，都需要显式回答"我的某个既成事实，是否仍然可以被它发生前一刻的状态所解释"，而不能只在决策发起时检查一次就假装它永远成立。

实践角度看，Provenact的价值主张也很务实：它没有要求策略作者重新学一套并发编程范式，而是把序列化/预留/重新验证这些机制做成运行时基础设施，策略代码本身几乎不用感知并发（RQ4里策略演化只需改极少可信代码）。这种"正确性下沉到运行时、复杂度不上浮到策略作者"的分层思路，是任何要落地到真实生产环境的Agent治理框架都绕不开的工程约束——毕竟策略作者通常是业务方而非分布式系统专家。唯一的保留意见是：论文的评测场景（PostgreSQL原型、脚本化无LLM工作流）离真实LLM Agent的不确定性行为还有距离，Provenact能否在Agent自身决策也存在不确定性（比如同一意图触发不同数量的重试请求）的场景下继续保持PSS，是一个值得后续验证的问题。