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

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