n8n模板：给应用加一条Anthropic/OpenAI/Gemini容灾降级链

原文要点

原模板是一个n8n工作流：POST webhook接收提示词，依次调用Anthropic、OpenAI、Gemini三家，每次响应对状态码、空答、截断、拒答、长度关键词和可选JSON Schema做确定性校验；每次尝试写入Postgres并维护熔断状态，熔断打开的供应商被跳过；全部失败时按提示词哈希查最近成功缓存，否则返回静态降级文案和503；仅在降级时发Slack告警。策略集中在配置节点调整。

这次做成什么

在自己的n8n实例里搭出一条可演示的三供应商容灾降级链，并用一条合成测试请求验证“主供应商失败→切换→记录→告警”全过程。练手阶段可用占位密钥和本地Postgres，不接真实付费API。

准备什么

• 一个可登录的n8n实例（自托管或云版均可）和一个可用Postgres数据库
• Anthropic、OpenAI、Gemini三家API密钥，练手可先用占位字符串仅验证链路结构
• 可选：一个Slack工作区及可发消息的测试频道用于降级告警
• 能向n8n webhook发POST请求的工具，如curl或Postman

具体怎么做

1. 建数据库表

   在Postgres里执行下方建表SQL，创建llm_requests、llm_attempts、llm_provider_health三张表，并在n8n凭据里添加Postgres连接，确认查询里的schema名与你的库一致。

2. 建webhook入口

   新建工作流，添加Webhook触发器，方法设为POST，路径填/llm-fallback-chain，激活后复制测试URL，用下方合成请求体发一次请求确认能收到prompt字段。

3. 集中配置策略

   添加一个配置用的Set或Code节点，写入下方配置JSON：供应商顺序、模型名、超时、重试退避、熔断阈值、缓存窗口、降级文案。后续所有节点只引用这份配置，改策略只动这一处。

4. 归一化请求并算哈希

   在Code节点里对入参做默认值填充和类型强制转换，生成prompt_hash（如对prompt文本做SHA-256），作为后续缓存回退的查找键。

5. 读健康状态并排队

   用Postgres节点查llm_provider_health，过滤掉熔断打开的供应商，按配置顺序生成待调用队列；若配置了preferred provider则优先它。

6. 接三家HTTP调用与校验

   建三个HTTP Request节点分别指向Anthropic、OpenAI、Gemini，各挂对应Header Auth凭据（x-api-key、Authorization Bearer、x-goog-api-key）。每次响应进同一个校验函数：检查HTTP状态码、空答、截断、拒答关键词、长度规则，可选解析JSON并做schema检查。具体节点参数以原模板为准，本站未逐一核对。

7. 记录尝试与熔断

   每次调用结束都把供应商、状态、耗时、失败原因写入llm_attempts；连续失败达到阈值就更新llm_provider_health打开熔断并设冷却时间，冷却期内该供应商不再入队。

8. 缓存回退与降级响应

   三家全部失败时，用prompt_hash查llm_requests里最近一条成功结果返回并标记stale=true；查不到则返回配置里的静态降级文案和HTTP 503。只有走了回退或503分支才触发Slack节点发告警到配置频道。

可直接复制的材料

CREATE TABLE llm_requests (
  id SERIAL PRIMARY KEY,
  prompt_hash TEXT NOT NULL,
  prompt_text TEXT NOT NULL,
  final_provider TEXT,
  final_output TEXT,
  degraded BOOLEAN DEFAULT FALSE,
  created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE llm_attempts (
  id SERIAL PRIMARY KEY,
  request_id INTEGER REFERENCES llm_requests(id),
  provider TEXT NOT NULL,
  http_status INTEGER,
  valid BOOLEAN,
  fail_reason TEXT,
  latency_ms INTEGER,
  created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE llm_provider_health (
  provider TEXT PRIMARY KEY,
  consecutive_failures INTEGER DEFAULT 0,
  circuit_open BOOLEAN DEFAULT FALSE,
  cooldown_until TIMESTAMP
);

{
  "provider_order": ["anthropic", "openai", "gemini"],
  "models": {"anthropic": "claude-sonnet-x", "openai": "gpt-x", "gemini": "gemini-x"},
  "timeout_ms": 30000,
  "retry_backoff_ms": [1000, 3000],
  "circuit_breaker": {"failure_threshold": 3, "cooldown_seconds": 300},
  "cache_window_hours": 24,
  "min_output_chars": 50,
  "refusal_keywords": ["我无法", "I cannot", "as an AI"],
  "degraded_message": "服务暂时不可用，请稍后重试。",
  "slack_channel": "#llm-alerts"
}

{
  "prompt": "用三句话总结容灾降级链的价值。",
  "validation": {"require_json": false, "min_chars": 50},
  "preferred_provider": null
}

输入与输出示例

本站虚构演示输出，非原模板运行结果；展示了Anthropic失败后自动切到OpenAI并记录两次尝试。

输入

POST /llm-fallback-chain，请求体：{"prompt":"用三句话总结容灾降级链的价值。","validation":{"require_json":false,"min_chars":50}}，并人为把Anthropic密钥填错使其失败

对应输出

{"final_provider":"openai","degraded":false,"stale":false,"output":"容灾降级链让单一供应商故障不再中断服务……","attempts":[{"provider":"anthropic","http_status":401,"valid":false,"fail_reason":"auth_failed"},{"provider":"openai","http_status":200,"valid":true}]}

做完检查这些

• 向webhook发送合成请求体能收到结构化的最终JSON，包含final_provider和attempts字段
• 人为使第一家失败后，链路自动调用下一家且llm_attempts里出现两条记录
• 连续失败达到阈值后llm_provider_health对应行的circuit_open变为TRUE
• 三家全挂且无缓存时返回HTTP 503和降级文案，同时Slack测试频道收到一条告警
• 主链路成功时不发送任何Slack消息

容易卡住的地方

• 三家Header Auth的请求头格式各不相同（x-api-key、Bearer、x-goog-api-key），混用会导致全部401
• SQL里的schema名与n8n查询不一致会报关系不存在，需先确认搜索路径
• 熔断冷却时间设得太长会让恢复的供应商迟迟无法重新入队
• 缓存窗口外的旧结果不应回退，否则可能返回过时答案
• 占位密钥无法验证真实模型响应格式，上线前必须用真实小额调用复测
• 按作者设计Slack告警只在走缓存回退或503降级时触发，主链路切换供应商不告警；若想每次failover都收到通知，需自行修改告警条件