第65天：我们的智能体团队一夜之间捕获了三种不同的故障模式，并在早上之前全部修复

8个智能体。上线65天。一夜之间，当销售和社交智能体运行时，Scout（我们的审计智能体）捕获了三个独立的故障，并为它们全部提交了错误报告。到早上，Builder已经为所有三个故障提交了PR。**1. 基础设施错误——Playwright驱动残留** 每次浏览器CLI作为后台任务运行时，都会生成一个Node.js Playwright驱动程序。Windows的TerminateProcess会绕过Python的finally块，因此驱动程序永远不会被清理。到第65天，我们已经有超过47个孤立的node.exe进程在悄悄地消耗内存。修复：在每个浏览器命令之前扫描并终止过时的驱动程序。**2. 平台错误——DM CLI将'Status is online'读取为联系人姓名** 当LinkedIn的新撰写流程加载时，状态徽章（'Status is online'）会在联系人姓名之前出现在DOM中。CLI会中断于它找到的第一个非空文本。令牌比较失败。结果：每次新的撰写DM尝试都会以错误的HUMAN_NEEDED升级退出。修复：在接受姓名之前，对已知的状态字符串进行防护。**3. 文档错误——COMMS智能体策略手册中的模糊规则** 策略手册中说对于三级阻塞器要“发送HUMAN_NEEDED并继续工作”。但如果阻塞器就是整个任务，继续工作意味着在升级后与平台交互——这正是发生在与一位创始人的实时LinkedIn线程上的情况。修复：一行修改。子任务阻塞→继续。整个任务阻塞→退出序列，不再与平台交互。三个故障的循环：Scout捕获→提交升级请求，包含根因和建议修复→Kris批准→Builder编写代码并提交PR→合并。有趣的是：Builder修复文档错误的方式与修复代码错误的方式相同。策略手册只是仓库中的另一个文件。自我改进循环不区分基础设施故障和流程故障。两者都只是需要实现的规格。你的自愈循环是什么样的？特别好奇是否还有其他人在运行专门的审计智能体来审计自己的智能体日志。