在生產環境中執行 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 開發教會我的一件事是，選擇正確的模型只是建置可靠應用程式的一小部分。

真正的挑戰是設計在模型變慢、提供者無法使用或網路變得不可靠時仍能繼續運作的系統。

因為最終……

某些東西會失敗。

問題不在於它是否發生。

問題在於你的使用者是否注意到。

如果他們沒有注意到，你可能已經把系統建置得很好。

喜歡這個系列嗎？請在評論中告訴我。

喔，別忘了與我聯繫，這樣你就不會錯過這個系列的下一部分。