3 篇博文 含有标签「chaos-engineering」

打开你的智能体（agent）韧性测试套件，看看它实际上在测试什么。你会发现超时。你会发现连接中断、500 错误、频率限制响应、格式错误的 JSON，也许还有一个在失败前卡死三十秒的工具。所有这些都是经典模式下的故障注入：工具坏了，问题在于你的智能体是否能优雅地降级。

现在找找看那个工具完全没坏的测试。那个工具在 80 毫秒内响应，返回了完全符合 schema 的有效 JSON，但里面的值纯粹是错的。一个过期了三天的余额。一个交换了两个字段的客户记录。一个两位数移位的订单数量。一个本应返回四十行却返回空的查询结果列表。

你找不到它。几乎没有人注入过这种故障。而这正是你的智能体最无法抵御的故障，因为所有其他故障都会自我宣告，而这种故障不会。

你在九个月前编写的回退路径（fallback path）——那个用于捕获模型超时、切换到更便宜的供应商、并在两者都宕机时返回模板化消息的路径——实际上在过去的十二周里从未在生产环境中运行过。它仅在最初发布时被执行过一次，集成测试仍然能通过，操作指南（runbook）也仍在使用它。但这并不意味着它还能工作。第六周的一次重构改变了上游上下文对象的形状。第九周的一次依赖库升级悄悄移动了一个配置键。代码仍然可以编译。测试仍然能通过，因为它们是针对与代码相同的陈旧 Fixture 编写的。下次当你的主路径出现 504 错误时，你的“优雅降级”将会把一个 NullPointerException 甩在用户脸上，而复盘报告将会指出——这已经是今年第三次了——在上游契约变更后，回退路径从未被重新测试过。

这是 AI 系统韧性工程中一种隐性的失败模式。回退路径是你应用程序中专门为了被忽视而存在的部分。在一百天里，有九十九天生产流量都会绕过它。CI 从不执行它，因为没有任何测试与之关联。负责它的团队在两次事故之间会忘记它的存在。然后在第一百天，当主模型供应商出现区域性故障，你终于需要它时，这段代码却在付费客户面前发生了代码腐烂（bit-rots）。

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。