01 · 單一 gateway
所有呼叫，統一經一道閘。
所有模型流量 — 無論是 OpenAI、Anthropic，還是運行於您自家硬件上的 open-weights 模型 — 都經由單一 gateway 處理，每個應用程式配一條 virtual key。更換供應商只需修改 config，可為每個團隊設定開支上限，撤銷單一 key 亦毋須重新部署任何東西。一旦有兩個服務直接呼叫兩套 SDK，您便失去了監察、預算控制與切換的能力。
AI 整合指南
順暢整合 AI。
我們整合 OpenAI、Anthropic 與內部模型的方式，能有效避免從原型到上線之間的落差。
大多數 AI 功能都夭折於示範與部署之間。模型從來不是難點 — 真正困難的是圍繞模型的基建配套。以下是我們每個項目必跑的檢查清單，並按實際執行次序排列。
02 · grounding
讓答案建基於您自己的事實。
缺乏事實根據的 chatbot，會先擅自編造您的定價，事後才道歉。Retrieval 先行：您的手冊、文件與政策 — 經過分塊、嵌入，並在每個答案中附上引用出處。Guardrails 把守在前，確保對話不離題、不越界。若 context 未有涵蓋，正確的答案是「我不確定」，而不是即興發揮。
03 · 沉悶的部分
為 retry、timeout 與 rate limit 預留工夫。
原型只在 happy path 上運作正常；生產環境考驗的卻是其餘所有路徑。帶 backoff 與 jitter 的 retry、硬性 timeout、按用戶計的 rate limit，以及在串流中斷時能優雅回退的 streaming 機制。這些都不適合拿來做示範，卻全都承重 — 它們正是「一宗事故」與「一次無人察覺的重試」之間的分別。
04 · 審計與 rollback
像管理程式碼一樣為 prompt 做版本控制。
Prompt 存放於 git，而非儀表板上的文字框。每個 completion 都連同產生它的模型、prompt 版本與 context 一併記錄。當供應商更新模型、行為隨之改變 — 這是必然會發生的事 — 您可以在幾分鐘內 diff 出改動並 rollback，還附有一條合規團隊真正讀得懂的審計紀錄。
05 · evals
先講 eval，後談感覺。
一套由真實問題與預期行為組成的 golden set，在每次 prompt 或模型變更時自動運行。不是學術 benchmark — 而是您的問題、您的 edge case、您的語氣。「感覺上變好了」不算迴歸測試；一個能攔下部署的失敗 eval 才算。
06 · 退場機制
掌握自己的退場之路。
如果託管 API 起步最快，就從它開始 — 但要保持接縫乾淨，讓日後遷移至自家硬件上的 open-weights 模型時，只是改一次 config，而非重寫。我們自己正以同一套 gateway 模式，在自託管模型上運行生產工作負載；我們構建的一切都不會綁定任何供應商。一如我們交付的其他成果：它完全屬於您。