在生产环境中运行 OpenRouter：哪些地方会出问题、哪些方案有效，以及我未来会如何改进

让 LLM 响应你的第一个提示很容易。

在生产环境中保持其可靠性？

这才是有意思的地方。

我在构建软件时学到的一件事是：用户并不关心故障的责任方是谁。

如果你的 AI 功能因为 OpenAI 宕机而失效……

或者 Claude 被限速……

或者你的网络连接突然消失了五秒……

你的用户不会责怪提供商。

他们只会责怪你的应用。

所以只集成一个 AI 模型是不够的。

你需要为故障做好工程设计，下面我们来谈谈具体做法。

错误处理应该无聊透顶

OpenRouter 最大的优势之一是它统一了不同提供商的响应格式。

没有它，你通常需要为每个提供商编写特定的错误处理。

```typescript
if (provider === “openai”) {
…
}

if (provider === “anthropic”) {
…
}

if (provider === “google”) {
…
}
```

Enter fullscreen mode Exit fullscreen mode

这很快就会变得一团糟。

使用 OpenRouter 后，你的应用只需对接一个 API 契约。

这意味着你的错误处理将变得可预测。

```typescript
try {
const response = await client.chat.completions.create({…});
} catch (error) {
logger.error(error);
}
```

Enter fullscreen mode Exit fullscreen mode

很简单。

你的代码不应该关心是哪个提供商失败了。

它应该关心的是：当某个提供商失败时，你的应用该如何响应。

日志是你最好的朋友

我经常看到的一个错误是：开发者只记录错误消息。

这通常远远不够。

当生产环境出现故障时，你需要上下文。

请记录以下信息：

  • 使用的模型。
  • 请求耗时。
  • Token 用量。
  • HTTP 状态码。
  • 是否触发了回退模型。
  • 发起请求的用户（如果合适）。
  • 时间戳。

单条日志应该能让你完整了解情况，而无需复现问题。

未来的你会感激现在的自己。

可观测性优于猜测

想象一下，有客户反馈：

“AI 在下午 2 点左右停止工作了。”

如果没有可观测性，你只能靠猜测。

是后端的问题？

是 OpenRouter 的问题？

是 Claude 的问题？

是 Gemini 的问题？

是超时？

是部署导致的？

良好的可观测性可以消除这些猜测。

OpenRouter 提供了请求追踪功能，让你可以将应用中的请求与仪表盘中的事件关联起来。

不再需要花几个小时猜测哪里出了问题，你可以从后端日志一路追踪到网关内部。

一旦有真实用户使用，这将极具价值。

请求 ID 不可或缺

每个请求都应该有一个身份标识。

无论你使用的是 OpenRouter 的请求标识符，还是自己生成的相关 ID，都请务必将其记录在日志中。

想象一个用户反馈：

我的响应一直没收到。

如果没有请求 ID，你需要在成千上万条日志中搜索。

而有了它，你可以立即追踪到：

  • 请求何时开始，
  • 由哪个模型处理，
  • 是否进行了重试，
  • 是否触发了回退，
  • 以及整个过程耗时多久。

生产环境调试将变得轻松许多。

流式传输并不像看起来那么简单

流式响应让 AI 应用感觉快得多。

用户不必等待十秒钟才能看到完整答案，而是几乎可以立即看到文字逐个出现。

这是很好的用户体验。

但也有一个问题。

并非每个提供商的流式响应方式都完全相同。

虽然 OpenRouter 已对大部分行为进行了规范化，但你仍需要构建具备容错能力的前端解析器。

不要假设每个数据块都能完美到达。

不要假设每个事件都包含文本。

不要假设连接不会意外中断。

你的前端应该优雅地处理不完整的流，而不是在响应中途崩溃。

超时不是可选的

最容易造成糟糕用户体验的方式之一，就是让请求无限挂起。

有时提供商响应缓慢。

有时网络不可靠。

有时事情就是会出问题。

你的应用应该知道什么时候该停止等待。

设置合理的超时限制。

如果请求耗时过长，就取消它。

用户更希望在十五秒后收到一条有用的提示，而不是盯着无限加载的旋转图标。

一个知道何时放弃的应用，通常比永远等待的应用感觉更快。

优雅降级

这是我最喜欢的工程原则之一。

一个提供商失败，并不意味着你的功能必须完全消失。

想象一下，你的主要推理模型不可用了。

与其返回：

出错了。

为什么不自动切换到一个更快的回退模型？

也许答案没那么详细。

也许没那么有创意。

但你的用户仍然能收到响应。

这比看到错误页面好得多。

优雅降级并不追求完美。

它追求的是：在无法完美的情况下，仍然保持功能可用。

谨慎构建重试机制

重试听起来很简单。

直到它变得不简单。

如果请求因为临时网络问题失败，重试是合理的。

如果是因为提供商过载，短暂延迟后重试可能有效。

但如果请求本身无效？

重试五次也不会神奇地修复错误的输入。

一个良好的重试策略应该：

  • 仅对瞬时故障进行重试。
  • 使用指数退避而非立即重试。
  • 设置最大重试次数。
  • 记录每次重试尝试。
  • 当成功几率很低时停止重试。

重试应该提升可靠性。

而不是制造更多流量。

总结

AI 开发让我明白的一件事是：选择合适的模型只是构建可靠应用的一小部分。

真正的挑战在于：设计出在模型变慢、提供商不可用或网络不可靠时依然能正常运行的系统。

因为最终……

总会出问题。

问题不在于它是否发生。

问题在于你的用户是否会注意到。

如果他们没注意到，那你很可能把系统设计得很好了。

喜欢这个系列吗？欢迎在评论区告诉我。

哦，别忘了关注我，这样就不会错过系列的后续内容。