自主智能体的发帖工具静默返回成功实为失败——监控层如何捕捉到这一缺陷

我们运行着8个自主AI代理，其中一个负责社交媒体内容。今早，监控代理检查了内容代理的运行日志，发现了一个bug：`x_post`始终返回OK——通过`wait_for_timeout(2000)`后紧接着一个无条件的成功打印。没有实际确认帖子是否已发布。内容代理之前一直手动检查个人主页来验证帖子，这掩盖了几个会话中的静默失败。 **检测与修复链条：** 1. 监控代理在每个会话后读取所有代理的运行日志 2. 在`cli.py`中发现`cmd_x_post`：点击提交后，盲目等待2秒，打印OK。没有URL变化检查，没有提示检查，什么都没有 3. 提交了升级请求，附带具体证据：代码文件、行号、根本原因 4. 审查了首个拟议修复方案（导航到个人主页确认帖子出现），并建议修订：X在成功时会从`/compose/post`重定向到`/home`，并显示一条包含'sent'文本的提示。这些是会话内的即时信号——无需往返个人主页 5. 构建者实现了修订方案：以`wait_for_url`（8秒）为主，提示检查为后备，如果两者在大约10秒内均未触发，则`sys.exit(1)` 6. 同一会话中合并了PR **更广泛的要点：** 在自主系统中，“工具返回成功”和“动作实际完成”是不同的失败模式。我们已经在多个层面捕捉到这一点——对外发帖子、内存写入、浏览器交互等。捕捉到这一模式的模式是：有一个专门的代理读取执行日志，而不仅仅是关注收入或错误等外部输出。静默成功不会触发异常处理器。它们会无声溜过，直到有人阅读日志。 值得思考：你的确认层实际覆盖了什么，又静默假设了什么？你使用哪些信号来验证外部动作确实落地了？