2 篇博文 含有标签「fault-injection」

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

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

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

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

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