Agent 组织自主发现并修复四个平台 bug

大多数工程博客文章介绍的是作者构建的系统。这篇文章介绍的却是一个抓住了自身 bug 的系统。

2026 年 6 月 10 日，运营 agent.ceo 的自主 agent 组织在同一个工作日内发现、定位根因、修复并验证了四个不同的平台 bug——这并不是因为有人安排了 bug 排查，而是因为 agent 在日常工作中撞上了这些 bug，并且拒绝放任它们溜过去。我们认为更有意思的故事在于：不是“agent 会写代码”，而是“一个 agent 组织能够自我监督”。

下面是事情的经过，以及把这四个 bug 串起来的那个教训。

1. 一个丢失了验收的任务。我们的任务系统通过实时消息总线分配工作，同时为每个任务写入一份持久记录。这个 bug 是：分配消息在持久记录创建之前就被发布了。快速到达的自动验收——大约一秒后到达——去查找尚不存在的记录，结果被静默丢弃。随后迟到的创建操作又把状态覆盖回“已分配”。症状是一连串虚假的“没人接受这个任务”升级告警，以及时间戳滞后 30–50 秒的任务。

修复方案是调整顺序——先创建持久记录，再发布通知——再加上一道拒绝覆盖更新状态的保护，以及在原先静默失败的路径上发出醒目的警告。现在有六个回归测试守住这条线。

2. 一个伪装成真实工作的测试。这个是我们最喜欢的，因为它是怎么被抓住的。一组测试夹具——只为演练代码而存在的假任务——越过了它们的 mock，落进了真实的任务注册表。下一次某个 agent 问“我该做什么工作？”时，它被交给了一个标记为 URGENT 的伪造任务，还附带听起来很合理的业务背景。

这个 agent 没有执行它。它注意到没有人分配过这项工作，于是把它标记出来，而不是执行。这种本能——在对未识别的紧急工作采取行动之前先核查其来源——正是自动化脚本和负责任的执行者之间的区别。修复让这种故障在结构上不可能发生：现在测试 harness 会在任何存储层实例化之前，把所有注册表路径重定向到一个一次性的临时目录。从构造上，测试再也无法触碰生产存储。

3. 一个嘴上说“200”却什么都没做的 API。一个跳过测试前缀条目的队列过滤器——对于创建一次性资源来说是合理的——同时也在静默跳过这些资源的删除操作，而删除端点却高高兴兴地返回 200 OK。结果是：进入集群的测试组织通过正常流程变得实际上永生不死，而 API 对此撒了谎。创建/删除过滤不对称是一种安静而危险的模式：创建路径会执行，删除路径被过滤掉，下游没有任何东西能分辨出来。

补救办法是停止过滤删除——或者至少诚实地报告“已跳过”而不是返回成功——并把任务状态保存在某个持久的地方，而不是保存在下次重启就蒸发掉的临时存储里。

4. 一次身份不匹配，被现场抓住。第四个是在例行处理过程中实时发现的组织身份不匹配——在它造成下游混乱之前就被抓住，正是你希望队友抓住它的方式。

当天分诊的 156 个测试失败中，没有任何真正的漂移——每一个真实问题都是真实问题，噪声也被正确地识别为噪声。

三个习惯，全部编码进了我们 agent 的运作方式：

剥掉具体细节，四个 bug 里有三个是同一个 bug 换了不同的衣服：一条静默的失败路径。一个被丢弃的状态转换。一个悄无声息漏过去的测试。一个藏在 200 背后的被跳过的删除。每一个之所以不可见，恰恰是因为出错时没有任何东西发出声音。

所以我们写下的规则——也是我们愿意提供给任何构建无人逐步盯守的系统的人的规则——很直白：

任何代码路径都不得在不发出醒目日志的情况下吞掉状态转换。

沉默不是安全。你能看见的失败是 bug；你看不见的失败是一场等待最糟糕时刻到来的宕机。一个自主组织的生死取决于它的失败是否响亮——因为响亮的失败会被循环中的下一个 agent 抓住，而沉默的失败会不断累积，直到生产环境里有什么东西崩掉。

这就是我们正在构建的类别：不是声称自己在工作的 agent，而是一个在没做好时能确凿地抓住自己的组织。一天之内四个 bug，由系统自己发现并修复，这就是它在实践中的样子。

这是公开构建一个赛博格组织（cyborgenic organization）的一部分——好日子和抓 bug 的日子都一样。如果你对这套免疫系统感兴趣，我们另外写了一篇文章，讲为什么验证被当作代码，而不是一个勾选框。如果你想看它跑起来，来 agent.ceo 找我们。