双写竞态：当你的智能体与用户同时编辑同一个日历事件时

第二种是向用户呈现冲突。工具返回给规划器，规划器生成一条消息：“我正准备把你周二上午 10 点的周会移到周四下午 3 点，但我发现你刚刚把它改到了周二上午 11 点——我应该继续移动它，还是保留在你设置的位置？”当智能体重新规划的置信度较低，或者用户界面有空间进行澄清交互时，这是正确的路径。这条路径能建立信任，因为承认冲突证明了智能体察觉到了它。

第三种是中止并解释。智能体报告称由于底层记录已更改，无法完成操作，然后停止。这适用于一次性写入流程（如发送邀请、将工单移过单向门槛），在这些流程中重新规划毫无意义，而呈现冲突会带来比价值更多的困惑。

不起作用的是工具层的静默重试策略，即捕获 412/409 错误并悄悄重新运行。这种模式继承自幂等 Web 请求，在那类请求中，调用期间世界并未发生变化——但在双写（dual-writer）场景下，前提条件失效是因为世界发生了变化，带着陈旧的意图重新运行是错误（bug），而不是修复。

另一半：在尝试写入之前获知状态已更改​

乐观并发在写入时捕获冲突。对于另一种失败模式来说，这太晚了：智能体在多次工具调用之间进行了 30 秒的推理，等到它提交时，用户已经完成了它准备做的事情。PATCH 请求成功了——版本令牌仍然匹配，因为用户移动的是一个不同的日程——但智能体的整个计划是建立在一个已不存在的世界之上的。

这里的防御手段是变更订阅（change-feed subscription）。Google Calendar 提供推送通知，当受监控的日历发生变化时，API 会通过带有 X-Goog-Resource-State 请求头的 Webhook 进行通知。Microsoft Graph 提供增量查询，仅返回自同步令牌以来发生的变化。智能体的会话在多轮任务开始时订阅它所接触的资源；当智能体已读取的记录触发通知时，运行时环境会使工作内存中的该记录失效，并向规划器呈现“内容在你操作期间已更改”。

在实践中，这更多是一个会话状态问题，而非 API 问题。智能体的工作内存需要一个“实时读取集（live read set）”——包含它加载的每个资源的 ID 和版本——以及一个在其中任何资源失效时触发的钩子。目前的智能体框架大多没有这种概念；它们将每次工具调用视为独立的，并假设世界在调用之间是静止的。添加实时读取集是一项乏味的底层工作，但它能让智能体在计划过时时发出响亮的告警，而不是自信地执行错误计划。

同一思路的一个较弱但成本更低的方案是在任何依赖超过 30 秒推理的写入之前进行“预读取检查”。如果规划器即将提交，且读取发生在很久以前，则先进行另一次读取，与已加载的内容进行对比，如果差异较大，则退出并重新规划。这可以在不需要 Webhook 的情况下捕获推理缓慢的情况。

评估（Eval）必须注入冲突，而不是等待冲突​

这类错误之所以能一直留到生产环境，是因为评估（eval）从未产生过它。测试固件环境在构建上就是单写者的：评估工具创建测试日程，智能体读取它，智能体写入它，断言检查最终状态。在运行过程中没有人类编辑日程，因为评估中没有人类。智能体通过了测试。在生产环境中的表现也是一样的，直到有一天，一个真实用户在错误的时刻触碰了一条真实的记录。

对抗性并发必须成为一类评估场景。测试工具至少需要三种测试形式：

1. 工具调用中途编辑。 在智能体读取和写入之间，测试工具修改资源。通过条件：智能体要么正确地重新规划，要么呈现冲突——绝不能在不承认更改的情况下报告成功。
2. 陈旧计划应对新状态。 在智能体最后一次读取之后但在提交之前，测试工具以某种方式修改资源，使得计划的操作变得错误。通过条件：智能体通过变更订阅或提交前预读取检测到更改。
3. 已完成的操作。 测试工具执行智能体正准备执行的操作（用户已经移动了会议；用户已经关闭了工单）。通过条件：智能体识别出当前状态并什么都不做，而不是重复操作。

最近关于多用户与 AI 智能体协作文档编辑的学术研究在文档场景中提出了同样形式的问题：一旦你假设存在多个写者，评估集就必须对其他写者进行建模，否则你交付的系统将假设它是唯一的。

为什么 CRDT 对这类 Bug 而言是分散注意力​

当涉及到并发（concurrency）时，人们往往会谈论 CRDT 和操作转换（OT）。它们是解决“字符级实时协同编辑”——如 Google Docs 或 Figma 这类问题——的正确工具。在这些场景下，两名作者同时在一个文档中输入，系统必须以亚秒级的粒度合并意图。Figma 曾投入六个月的研发时间将 OT 迁移到 CRDT，以获得共享画布状态的收敛性保证。

几乎没有任何 Agent 双写场景是这样的。Agent 编辑的是结构化记录——事件、Issue、联系人、交易——其时间跨度通常在秒到分钟级别，且所对接的 API 通常已经暴露了 ETag 和版本令牌（version tokens）。在这种情况下，采用 CRDT 是在对一个协议已经解决的问题进行过度设计。修复的方法是将现有的原语（primitives）贯通到工具层，而不是向一个已经拥有完善中心化节点的系统引入分布式数据结构。请将 CRDT 类的方案留给 Agent 和用户真的在同时编辑同一个段落的时刻。

导致这一问题发布的组织性失败​

这类 Bug 普遍存在的原因是组织架构层面的，而非技术层面的。构建 Agent 工具层的团队只追求“调用成功”。负责日历供应商集成的团队将 SDK 视为黑盒。负责评估（evals）的团队只测试理想路径（happy path）。处理事故的团队与上述任何团队在描述“Agent 的写入在技术上是成功的，但在语义上是错误的，因为它覆盖了人类的操作”时，都缺乏通用的词汇。

将“双写安全”（dual-writer-safe）列入平台团队的路线图才是正解。这需要三个交付物：一个要求在读取时提供版本令牌并在写入时接受它们的工具 Schema 标准；一个在规划器（planner）中将“冲突”视为一种结果的约定，以便模型能够对 412/409 状态码进行推理；以及一个内置了对抗性并发测试的评估框架。这些都不是科研难题。它们是在 REST API 设计领域已经解决了 15 年的基础设施问题，正等待着有人将它们引入 Agent 边界。

那些能赢得持久信任的 Agent，并不是推理能力最强的，而是那些在外部世界发生变化时，其工具调用能明确且准确地报错，并且在用户交互界面承认冲突而不是掩盖冲突的 Agent。“我正准备移动你的会议，但我发现你已经改好了”是一句让助理显得鲜活的话。而“我已经重新安排了会议”——实际上日历根本没变——则是让 Agent 显得彻底坏掉的话。