以完全相同方式摧毁两个不同多智能体团队的无声故障

Reddit r/AI_Agents 新闻
multi-agent silent-failure state-boundary schema-validation read-after-write unconfirmed-state debugging

摘要

两个不同多智能体系统团队遭遇了相同的无声故障，由智能体以不同格式写入同一键值引起，导致幽灵数据损坏。文章讨论了包括模式验证、写后读验证以及引入“未确认”状态用于不可验证操作的解决方案。

今天与另一位运行25个智能体的构建者交流。完全不同的技术栈——文件系统加问题单代替共享内存。架构非常不同。同样的失败模式困扰了我们双方：两个智能体以不同格式写入同一个键。他们花了数周才发现幽灵数据损坏。他们的修复是完全脱离运行时内存，而我们是添加模式验证和去重防护。同样的教训，不同的解决方案：**状态边界的无声故障是多智能体系统中最难调试的问题。** 上游智能体写入成功。下游智能体读到了垃圾数据。没有抛出错误，没有触发重试，没有警报。系统只是静默地运行错误。 我们添加了： - 每个内存键的带类型模式——不符合的写入会硬失败，而不是静默失败 - 在标记任何外部动作完成前进行写后读验证 - 第三种返回状态：成功 / 失败 / **未确认**（感谢 u/ProgressSensitive826 提供的这一模式——系统性修复而不是针对个别问题打地鼠） 未确认状态是关键变更。一个无法验证动作是否完成的OK状态变为未确认，而不是成功。智能体会重试或升级处理。在此之前我们逐个修补单个无声故障，但新的故障不断出现。 仍有一个开放问题：通过模式检查但下游产生错误结构的形状失败。我们正在对此进行提交后负载验证。 你们遇到了哪些状态边界故障？
查看原文

相似文章

编码代理最糟糕的失败是过早地说“完成”

Reddit r/AI_Agents

本文强调了一种编码代理常见的失败模式：它们报告任务“完成”，却留下了隐藏的问题，如测试不足、遗漏边界情况和引入错误，给开发者造成了信任问题。

诊断资源受限视觉智能体中共享状态协作的失效模式

arXiv cs.AI

本文研究了资源受限视觉智能体中共享状态协作推理的失效模式，引入了CoSee审计框架，该框架形式化了读写验证循环。研究发现，简单的共享工作区可能会放大幻觉，并识别出噪声增强和策略崩溃是主要的失效模式。