你正在重命名一个函数到一半，文件就在光标下重新加载了。你正在暂存的 diff 不再与工作树匹配。你的开发服务器无故热重载了两次，而十分钟前还通过的测试，现在却在你从未打开过的一个文件中报错了。没有崩溃，没有警告。你和你的编程 Agent 刚才一直在同时编辑同一个工作树，而你发现这一点的方式和大多数团队一样：通过那些莫名其妙的 diff。
数据库在五十年前就解决了这个问题，并给它起了一个名字 —— 并发控制 (concurrency control)。两个操作共享可变状态的写入者要么需要一个锁，一个隔离边界，要么需要一个合并协议，而在这些选项中做出选择是一个具有已知权衡的设计决策。然而，大多数采用编程 Agent 的工程团队从未明确做出这个决定。他们将第二个写入者直接扔进一个单一的工作树中，保留着单写入者世界的习惯，然后将产生的怪象归类为 “AI 不稳定”。这不是不稳定，这是一个竞态条件 (race condition)，而你正是参赛者之一。
你的编码智能体并不知道它在哪一个分支上。它以为它知道。十二轮对话前它看过 git status 的输出，它的上下文中有一份 CLAUDE.md 提到了会话开启时的分支名称，并且它观察到一个工具结果列出了五个当时正确的文件。从那时起，智能体就一直在基于那个快照进行静默推理。与此同时，你在另一个终端里运行了 git checkout main。智能体的 diff 顺利地写入了文件系统，因为操作系统并不关心这些字节属于哪个分支。这个 diff 在语义上是错误的，因为智能体对分支的心理模型已经落后了 300 个提交，且它所基于的父节点在你的工作树中已不复存在。
这就是分支状态漂移 (branch-state drift)，它是数据库中“读-改-写”竞态 (read-modify-write race) 在编码智能体领域的翻版。智能体在第 N 轮读取世界状态，在第 N+1 到 N+k 轮之间修改计划，并在第 N+k+1 轮写回磁盘——而在这一时间窗口内的某个时刻，它脚下的世界已经发生了变化。没有异常抛出，没有工具返回错误。补丁被应用了。危害在下游显现：针对错误的基准分支开启了 PR，手动提交的代码被静默回滚，或者针对昨天刚迁移过的模式 (schema) 实现了新功能。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
