一个超时不能回答两个问题：AI写入确认为何需要双窗口

当AI请求写入数据，人工需要点击确认——这个场景里藏着两个完全不同的"过期"问题：对话还要不要继续等？ 以及 这条待办记录还能不能被操作？ 用同一个超时值回答两件事，代价是列表上显示"等待你确认"，点击却必然失败。开源运行时 KeelBase 的作者拆解了这套双窗口 + 单点仲裁的设计，并给出了四个可以自查的问题。

为什么两个问题看起来像一个

两个问题都像是"确认能活多久"，所以直觉上就是"一个数字、一列字段"。但它们的消费者完全不同：第一个问题的答案被正在等待的那条对话流消费，答错的代价是体验——多等一会儿，或者提前放行；第二个问题的答案被数据层和每一个决策入口消费，答错的代价是一致性——用户点了一个必然失败的按钮，或者一条已经死掉的记录仍然显示可操作。

原文用一张表把这种不对称摆得很清楚：前者错在毫秒之间，后者错在"系统自己制造了失败"。当两者共享一个值时，第二个问题的答案就会被第一个问题的需求拖着走。

现场还原：两处计算，靠一句注释维系

KeelBase 作者遇到的真实问题是：离线窗口的边界被计算了两次——读路径在内存里比较时间戳，维护扫描在 SQL 里比较时间戳。让两者保持一致的，是代码里的一句注释，大意是"这里的谓词和那边的一致"。

注释不是谓词。

一旦两边漂移，就会出现这样的记录：列表显示"等待你确认"，扫描任务却已经把它判为过期。点击失败不是偶发，而是列表在批量制造——它把一条死记录当成待办任务呈现给用户。这类 bug 难查的地方在于，表象是"点击偶尔失败"，根因是两处代码对同一个时刻持有不同定义。

修复一：两个窗口，每个边界只由一个函数计算

修复分两半。第一半是承认这是两个窗口：

• 对话内等待默认 60 秒，过期只结束这次等待，让对话继续，不碰数据；
• 离线窗口默认 24 小时，记录在这段时间内保持可决策，只有它过期才把记录翻转为超时。

第二半是让每个边界只由一个函数计算。读路径和维护扫描都调用它，拿到同一个时刻。这样"显示为可操作"和"已经过期"在结构上就不可能同时为真。原文强调的重点不是算术正确，而是"只有一个地方在做这件事"——两处实现，剩下的就只有一句承诺它们一致的注释。

修复二：所有决策争抢同一个仲裁点

有了两个窗口，就有了两个决策入口：对话里的按钮，以及之后出现的待办列表。它们可能竞争。

解决办法是让它们争抢同一个东西：一次数据库条件更新，条件里包含"当前状态仍然是 pending"。更新命中一行，这次决策成立并执行；命中零行，说明已经有人决策过，这次不执行。

原文明确反对"先读再决定"：读和写之间有间隙，两个决策都可能读到"仍是 pending"。条件更新是原子的——谁先改到这一行，谁拥有这次决策。两个入口，一个仲裁点，这一节的全部内容就是这些。

条件更新与 compare-and-swap（CAS）

条件更新是数据库层面的一种原子操作：UPDATE ... WHERE id = ? AND status = 'pending'。它的关键在于“判断”和“写入”发生在同一个原子操作内，不存在先读后写的时间窗口。数据库引擎在执行时会锁定目标行（或使用乐观锁版本号），确保只有一个事务能命中 status = 'pending' 这个条件。CAS 是更一般化的概念，指“仅当当前值等于预期值时才写入新值”，条件更新是其关系型数据库中的实现形态。与之相对的是“先 SELECT 再 UPDATE”的两步模式：两步之间其他事务可能已经修改了该行，导致两个决策都以为自己是第一个。在分布式系统中，CAS 的等价物还包括 Redis 的 SET NX、etcd 的 compare-and-swap 事务等。理解这一点就能明白原文为何强调“内存检查不是仲裁”——内存中的布尔标志没有原子性保证，多个并发路径可以同时读到“未决策”并通过检查。

第二个现场：一次"不知道"被读成了"是"

另一个真实事故：决策必须先写入才算数，如果写入抛异常呢？旧行为吞掉了错误，照样释放内存中的等待，于是链条变成：数据库抖动、写入失败 → 内存等待被释放、工具执行 → 记录仍是 pending → 下一个决策（对话里或列表里）看到"仍是 pending"，再执行一次。

"我们不知道决策是否落地"被读成了"是"。 修复很直白：没有证据表明决策到达数据库，就不释放；让这一次失败、让人重试，而不是把不确定性翻译成执行。原文还特别指出：对于没有幂等键的外部工具，第二次运行就是真实重放，目标系统确实会收到两次——这条路径上，失败关闭不是谨慎，是必须。

幂等键与失败关闭（fail-closed）

幂等键是调用方为每次操作生成的一个唯一标识（如 UUID），随请求一起发送给目标系统。目标系统记录已处理的幂等键，重复请求到达时直接返回首次结果而不重复执行。没有幂等键时，重试或重放对目标系统而言就是一次全新的调用——转账会转两次，发邮件会发两封。这正是原文说“第二次运行就是真实重放”的含义。失败关闭（fail-closed）则是一种默认策略：当系统无法确认操作是否成功时，选择拒绝继续而非默认成功。与之相对的 fail-open 会在不确定时放行，换取可用性但牺牲一致性。确认机制的本质是“未经确认不许运行”，因此持久化失败时 fail-closed 不是过度谨慎，而是该语义的直接推论。代价是数据库不可用时确认功能整体停摆，原文明确承认并接受了这一取舍。

这个设计不跨越的边界

作者主动划清了一条线：仲裁点保证至多一次决策，不保证至多一次执行。 如果同一个请求被模型重试或服务重启后重发，那是另一个问题，要在另一层解决。"同一个决策不能被做两次"和"同一个调用不能被发两次"必须分开说，把它们揉进一句"我们保证只执行一次"就是过度承诺。这一点被写进了结果消息和文档里，而不是留给用户去发现。

至多一次决策 vs 至多一次执行

这是分布式系统中两个不同层次的一致性保证。“至多一次决策”（at-most-once decision）由仲裁点保证：同一笔待确认记录不会被两个入口同时批准或拒绝，条件更新命中零行即表示决策已被他人完成。“至多一次执行”（at-most-once execution）则要求工具调用本身不被重复触发，这需要端到端的去重机制——幂等键、调用日志、目标系统的幂等支持——跨越了决策层之外的重试、重启、网络分区等场景。混淆两者会导致过度承诺：仲裁点只能管住“谁有权做这个决定”，管不住“决定做出后请求被重发了几次”。工程上必须把这两句话分开写进文档和接口契约，否则使用者会误以为系统提供了它并未提供的保证。

四个可以自查的问题

1. 你的超时回答几个问题？ 如果一个值同时决定"UI 要不要继续等"和"这条记录还能不能用"，那就是共享值。
2. 边界有几处实现？ 两处实现，离漂移只差一句注释。
3. 竞争决策由什么仲裁？ 内存检查不是仲裁，条件更新或任何原子 compare-and-swap 才是。
4. 决策持久化失败时的默认行为是什么？ 如果写入失败后的下一步是"照样执行"，默认就是放行。

写在最后

回到开头：一个超时不能回答两个问题。KeelBase 的做法是拆成两个窗口——60 秒的对话内等待和 24 小时的可决策待办；每个边界只由一个函数计算；所有决策争抢一次条件更新；没有落地证据就不释放任何东西。

这套机制来自 KeelBase，一个位于 AI agent 和业务系统之间的开源运行时，在工具真正执行前重新校验身份、授权、范围、风险与确认状态。仓库地址：GitHub（github.com/rain6fish/KeelBase）与 Gitee 镜像（gitee.com/rain6fish/KeelBase），国内访问 Gitee 更快。

作者还坦白了一个前提：整套设计假设决策可以被持久化。如果数据库不可用，系统选择拒绝而非放行——对某些系统来说，这意味着确认功能会整体停摆。这是刻意的：如果确认的含义是"未经确认的东西不许运行"，那么当什么都无法确认时，就什么都不该运行。