让 Agent 在 API 故障时安全切换服务

AI Agent 调用的 API 挂了，继续重试未必有用，临时换一家也未必安全。原文给出的办法是：先发现候选接口，再检查兼容性，最后依据明确规则决定是否切换，并用真实调用结果验证兜底是否成功。

它的价值在于把「找得到替代服务」和「可以放心使用」分开了。对于接入邮件、支付等外部能力的程序员，这套流程值得参考；但原文提供的是方案和假设场景，没有给出生产故障实测或成功率对照。

重试解决不了所有故障，替换也不能只看功能

API 失败可能有不同原因：服务暂时不可用、触发限流、返回格式异常，或者供应商已经修改接口，不再支持所需操作。

短暂故障适合按策略重试；接口能力已经消失，重复相同请求通常解决不了问题。因此，作者提出让 Agent 在原服务持续不适用时，搜索能完成同一任务的替代接口。

难点在后半程。

两家服务都声称支持事务邮件，不代表请求可以直接搬过去。认证方式、请求结构、价格、速率限制、数据处理规则和具体行为都可能不同。「能发邮件」只是能力描述，距离完成一次符合业务要求的发送还有不少条件。

替代 API 必须同时通过可用性和兼容性检查。

原文用一个假设场景说明边界：常用邮件供应商不可用时，要求 Agent 搜索其他事务邮件 API，排除故障供应商，检查相关候选的认证、文档和可靠性证据，但未经批准不能发送邮件或切换服务。

这条任务指令包含三层约束：搜索目标必须明确，推荐之前必须检查，发现候选不能直接触发外部操作。对 Agent 来说，查目录和发送邮件应当是两个独立步骤，权限也应分别控制。

Agent Nexus 提供候选，但不负责证明可以直接接入

作者选择 Agent Nexus 作为发现层。它的注册表收录 APIs、MCP servers 和命令行工具，可以返回候选接口及其端点、认证要求、使用信息和已有可靠性信号。

原文给出的远程 MCP 端点是 https://agentnexus.app/api/public/mcp。兼容的客户端可以配置可选的 Agent Nexus API key，受支持的集成共享每日配额，但原文没有给出具体额度。

这里有一个容易混淆的凭证边界：Agent Nexus API key 用于访问发现服务，不能替代外部供应商自己的凭证。即使查到了邮件 API，仍然需要对应服务的账号和密钥。

连接后，可以先确认客户端是否暴露发现工具和条目查询工具。不过，工具列表加载成功只证明连接可用。Agent 还得实际调用 discover_capabilities，才能证明它执行了搜索。

不使用 MCP 客户端时，也可以通过 HTTP 独立调试发现过程：

curl -sS --get \
  'https://agentnexus.app/api/public/discover' \
  -H "x-api-key: $AGENTNEXUS_API_KEY" \
  --data-urlencode \
    'need=Find an alternative API for transactional email' \
  --data-urlencode 'category=api' \
  --data-urlencode 'limit=3'

这里要看 need、category=api 和 limit=3：它们分别表达任务、限定接口类别、限制返回数量。运行前需要设置 AGENTNEXUS_API_KEY；匿名发现则移除认证头。原文没有说明匿名访问与认证访问的完整能力差异。

拿到候选后，还要查询具体条目。原文使用 mailjet-api 这个 slug 演示：

curl -sS \
  'https://agentnexus.app/api/public/registry/mailjet-api'

需要留意 URL 最后的 mailjet-api，它定位一个注册表条目。这条命令用于读取候选信息，不能证明该服务已经成功发送邮件，也不构成对它的推荐。

注册表结果还会随收录内容和可靠性数据变化。生产系统应当把返回值当作候选清单，后续继续核验接口契约，也就是调用双方必须遵守的输入、输出、认证和行为约定。

真正的兜底，要管住决策和执行结果

作者建议把切换过程写成明确策略：先识别并分类故障，只有错误类型和重试规则允许时才重试；原供应商持续不适用，再发现候选、检查契约、排除不符合条件的服务。

到这里还不能直接执行。

系统还需确认候选支持目标操作、凭证已经具备，并评估配置修改、费用、数据保护要求和行为差异。随后请求批准，或执行事先明确授权的切换策略，再安全测试新集成，最后记录真实调用结果。

邮件和支付最能说明其中的业务差异。

邮件服务可能要求验证发件域名，还要防止重试造成重复发送。支付则需要检查幂等性、交易状态、对账方式和供应商特有语义。所谓幂等性，就是重复请求不会造成重复扣款等额外结果。原请求返回超时，并不能直接证明交易没有发生，贸然换一家重做可能扩大问题。

如果没有候选满足要求，Agent 应停止并解释限制，不能因为某个服务排名第一就强行采用。

可靠性信号也需要分层理解。注册表可能提供评分、最近探测时间及结果、样本信息和 Agent 调用报告，但健康检查成功不保证当前业务操作成功；缺少调用报告也不等于服务不可靠，可能只是尚未有人上报。

发现成功、检查完成、业务执行成功，是三件不同的事。

原文提到 Agent Nexus 支持上报成功、失败及延迟等调用结果，但没有给出报告接口的具体端点、请求结构或示例。能够确认的原则是：只有目标操作确实完成，才能报告成功；实际调用失败，也必须保留失败事实。

因此，一次完整测试不能止于 MCP 连接成功。它至少要覆盖识别故障、实际搜索、检查候选、解释剩余风险、遵守授权边界，以及执行后记录真实结果。

我的判断

我赞同这套流程对权限和证据的区分。Agent 有能力发现新工具，不代表它已经具备切换供应商所需的业务判断和授权。将搜索、评估、批准、执行拆开，能让问题出在哪一步更容易追查。

但原文对效果的论证有限。事务邮件是一个假设案例，文章没有展示完整发现响应、实际切换代码、故障恢复耗时，也没有与固定备用供应商方案比较。它是一套有参考价值的设计建议，不能据此认定动态发现一定提高可用性。

另外，动态发现的收益取决于接入准备程度。搜索到了新服务，团队仍可能缺少账号、凭证、域名验证或适配代码。对于要求快速恢复的核心链路，我更倾向于提前接好并验证备用服务；动态发现可用于寻找后续候选、辅助排障，或处理允许人工介入的任务。

原文也没有说明注册表评分如何计算、探测覆盖哪些操作、数据多久更新。这些信息缺失时，评分只能辅助筛选，不能直接充当自动切换的依据。

还有一个工程上的缺口：这些规则如何强制执行。文章给出了自然语言约束，却没有展示应用如何限制 Agent 的实际权限。我的取舍是让凭证、工具权限和执行入口落实关键限制，提示词负责表达任务意图，两者共同约束行为。

能拿来做什么

• 在 Node 服务或 Agent 工作流中，把故障分类放到重试之前，明确哪些错误值得重试，哪些情况需要进入候选评估，避免所有异常都走同一条恢复路径。
• 将「搜索替代 API」做成独立的只读步骤，要求输出认证要求、接口差异和待确认事项。排障阶段先形成可审阅的候选说明，再进入发送邮件等执行步骤。
• 为现有邮件集成整理切换检查项，至少确认供应商凭证、发件域名验证和防重复发送机制。允许自动切换的条件应提前写进策略。
• 验收 AI 编程产出的兜底流程时，分别检查发现记录、评估结论和实际调用结果。不要仅凭工具列表加载成功，或注册表返回了候选，就认定整条流程已经跑通。