构建 Multi-Agent 系统：我从 6 个月的生产故障中学到的经验

Source: Dev.to

静默失败问题

最糟糕的故障不是崩溃。崩溃很吵，你会注意到它们。最糟糕的故障是表面上看起来一切正常，却在细微之处出错。

我有一个代理本应更新数据库记录。它连续三天返回“成功”，直到我发现它每次都在更新错误的记录。问题出在一个看似正确的字符串模板上，索引出现了 off‑by‑one 错误。

三天的错误数据，因为我信任了“成功”信息。

实际会失败的地方

六个月后，总结出以下模式：

• 你没想到要测试的边缘情况。 用户输入中的 Unicode 字符、空字符串、部分解析成功的 malformed JSON。这些在单元测试中不会出现，因为你根本没想到要为它们写测试。
• 带有 CVE 的依赖。 我在常用的代理框架中发现了三个关键漏洞。不是冷门包，而是大家都在用的流行库，没人对它们进行审计。
• 协同失败。 当你拥有多个代理时，故障模式会成倍增加。竞争条件、消息顺序假设、状态不同步。某个代理变慢，整个系统会以单个代理测试时无法预测的方式退化。
• 静默的认证失败。 API 密钥过期，代理收到 401 错误，但代码把 “401 unauthorized” 当作 “空结果” 处理，继续在错误假设下运行。我见过代理在数小时内基于未被识别的认证失败做出决策。

测试缺口

大多数团队以错误的方式测试代理。他们只测试 LLM 是否产生合理输出，却不测试整个系统在以下情况下的行为是否正确：

• LLM 返回垃圾数据
• API 超时
• 数据库连接中断
• 另一个代理发送了 malformed 消息
• 内存耗尽

生产环境并不在乎你的 LLM 有多聪明，生产环境在乎的是你的系统能否应对现实。

我们现在的做法

我们加入了对抗性测试。向代理抛出奇怪的输入，观察会出现什么破坏。我们对每个依赖进行 CVE 扫描。我们在并发负载下对多代理协同进行压力测试。我们注入故障并观察恢复情况。

每一个在投产前发现 bug 的测试，都相当于十次事故。

我真正想问的问题

对于在生产环境运行代理的朋友们：哪种故障模式让你感到意外？不是你预料并计划好的那种，而是以你未曾预见的方式导致系统出问题的那种。

我正在收集这些案例。不是为了写文章，只是想知道我的失败是奇怪还是正常。