当AI系统学会对自己的写入装聋作哑

一个招聘系统在候选人文件任何变更后等待五分钟，然后重写顶部的摘要。招聘人员添加笔记、简历进来、通话记录添加——五分钟后再更新摘要。听起来合理，但这里藏着陷阱：摘要本身就在文件里，重写摘要又改变了文件，于是五分钟后又重写一次，永远循环。作者通过这个“愚蠢的问题”揭示了所有读写同一存储的系统都会遇到的自我触发循环，并分享了三种“听不见的写入”策略。

循环的形状：读、写、再读

任何既读取存储又向同一存储写入的系统，都会陷入这个循环。招聘系统读取候选人文件并写入摘要；发布工作日志的流水线读取提交记录并写入日志条目，而日志条目本身又是一次提交；计费操作中的拒付代理读取索赔并写回备注。三个不同业务，形状一模一样。机器读取一个东西，对它说些什么，然后把说的内容放回它读取的地方。

浪费的令牌是显眼的成本，更隐蔽的代价是：所有基于“是否变化”的信号都会失效。候选人文件中的哈希本应回答一个问题：这个人的证据自上次处理后是否移动过？如果摘要被包含在哈希中，答案永远是“是”。哈希不再意味着候选人变了，而是意味着机器做了点什么——而机器总是在做点什么。

哈希（Hash）作为变更信号：文中提到的“哈希”通常指对候选人文件内容计算出的固定长度指纹（如 SHA-256）。系统保存上次处理后的哈希，下次只需重新计算并与旧值比对：若一致，说明内容未变，可跳过昂贵处理；若不同，则视为“证据移动”，需要重新分析。这依赖一个隐含前提——哈希只覆盖“业务证据”字段（简历、笔记、通话记录），不覆盖系统自己生成的派生内容（如摘要）。一旦摘要被纳入哈希输入，机器的每次回写都会改变哈希值，使“是否变化”的判断从“候选人是否变化”退化为“机器是否运行过”，变更信号彻底失效。因此，哈希边界的划定与写入可见性策略必须协同设计。

修复写入，而非触发器

我的第一反应是让触发器更聪明：根据变更者过滤、检查时间戳、比较新旧摘要并跳过匹配项。但这些方案在下一个写入路径出现时就会失效，而写入路径总是会出现。真正的修复在写入发生的地方：当系统写入时，它当场决定这次写入是否允许系统以后听到。

在招聘系统中，现在有三种静默写入。档案回写不产生审计事件——招聘人员的编辑和入站简历会进入触发流，但机器自己的更新不会。AI摘要笔记被排除在证据和哈希之外——笔记仍然存在，可以打开阅读，但它不是证据，不计入我们对这个人的了解，也不参与哈希，不影响这个人是否改变。批量创建条目不发事件——提取过程将简历拆成数十个条目，如果每个条目都触发创建事件，提取就会唤醒提取，所以批量路径故意静默。

关键洞见：读取和写入同一存储的系统，除非逐次写入地决定它对自身的哪些变化失聪，否则它将在自己的输出上循环。

触发器（Trigger）与事件驱动架构的局限：触发器是数据库或流水线中“当某条件满足时自动执行动作”的机制，常见于变更数据捕获（CDC）与事件驱动系统。它天然对“存储中发生的一切写入”作出反应，却无法区分写入来源与语义。文中第一反应“让触发器更聪明”属于在消费端做过滤，但每新增一条写入路径（新代理、新批量任务、新回写逻辑）都可能绕过过滤规则，导致循环复活。真正的修复点前移到生产端：写入方在落盘时即声明“本次写入是否应被后续监听者感知”，从而把可见性决策与业务语义绑定，而非依赖中心化的启发式规则。

到处都是一样的形状

站点流水线是最清晰的案例。它读取我交付的内容，写入工作日志条目，刷新操作图，并添加到目前已有159条目的洞察日志中。每一个输出都是一次提交。如果流水线把自己的提交当作工作，它会发布一条关于发布条目的条目。所以它自己的提交就是它听不见的写入。

计费侧形状相同但风险更高。语音代理致电付款人并将结果写在索赔上，拒付代理监视索赔。如果通话备注被视为索赔变更，拒付代理会重新评估索赔并写入自己的备注，语音代理的调度器会看到变更的索赔并再次致电付款人。没有人故意设计这个循环，它只是两个合理代理共享一张表的结果。所以无论什么上线前都要问同样的问题：这些写入中，另一个代理能听到哪些？

多代理共享存储的级联触发：计费案例中，语音代理与拒付代理共享同一张索赔表，各自读取并写回备注。若双方都把对方写入视为“索赔变更”，就会形成 A 写→B 读→B 写→A 读的级联循环，且每轮都可能触发真实副作用（如重复致电付款人）。这类问题在多代理系统里尤为隐蔽，因为每个代理单独看都合理，循环是交互涌现的结果。设计时需要为每对“生产者—消费者”明确可见性矩阵：哪些写入对哪些代理可见、哪些应静默。该矩阵应作为代理上线前的必检项，而非事后调试的补丁。

沉默不留痕迹

不产生事件的写入是审计日志不会显示的写入。我是故意这么选的，而且还会再选一次。但这意味着沉默是我必须另存的事实，因为它不会自己留下痕迹。日志显示发生了什么，却从不显示什么被故意没听到。所以失聪写入列表就写在触发器旁边，当摘要做出意外举动时，这是我首先读的东西。

结果：摘要现在在真实变更后五分钟内重写，并在自己写入后保持安静。审计流显示招聘人员编辑和录入事件，而不是机器自言自语。

五条原则

1. 在连接触发器之前，写下系统做的每一次写入。触发器只花一个下午，列表才是设计。
2. 默认让你的输出静默。如果是机器写的，机器就不该听到，除非你能说出为什么它应该。
3. 让你的输出远离哈希。包含摘要的哈希每次机器运行都会说“变了”。
4. 批量写入不发事件。如果一个步骤创建一百个条目，它绝不能唤醒创建条目的步骤。
5. 把失聪列表放在人会读到的地方。沉默在日志中不留痕迹，所以它需要在别处留下点什么。

触发器花了一个下午，但真正的一周是坐下来列出机器的每一次写入，并逐一问：机器是否应该被允许听到？一个倾听一切的系统最终主要听到的是自己。