如何用 OpenRouter 集中管理 AI API Key 與花費治理

一句話結論：AI 的 API Key 擴散方式和影子 IT 一模一樣——一個團隊一個團隊地來，每一次都有正當理由。結果是好幾把仍然有效的憑證、好幾張帳單，以及對兩者都沒有集中視圖。OpenRouter 把它們收斂到一把 Key 之下，帶上按 Key 的額度上限與用量可見性。這是「用一把結實的鎖換掉六把鬆的」，而不是「不上鎖」。

八個月前，行銷部的某個人把一把 OpenAI 的 Key 接進了內容腳本。支援團隊的工單摘要用的是一個外包顧問設定的 Anthropic Key。Vercel 的環境變數裡躺著一把 Google 的 Key，加它的人早就離職了，從那之後沒人碰過。研發有兩把，其中一把肯定躺在某個 git 歷史裡。

這些在當時都不是錯誤。每一把 Key 都是「最快把東西跑起來」的那條路，而每一個跑起來的東西，如今都在每天被用。

問題在於它們加起來是什麼。問一個簡單的問題——上個月 AI 花了多少錢，如果今晚把所有 Key 全輪替掉，哪些系統會掛——沒人答得上來。這才是真正的治理缺口，而它為什麼比以前更要緊，值得說清楚。

一家公司是怎麼走到「六把 Key、一把都沒有負責人」的

一把外洩的 AI 廠商 Key，和一個外洩的 SaaS 密碼不是同一類事故，差別在於計費。

多數憑證外洩暴露的是資料。而一把 AI 廠商 Key 暴露的是資料加上一條按量計費、沒有封頂的花錢通道。在公開儲存庫裡撿到你 Key 的人，可以一直用你的帳號跑推論，直到你發現為止——而通常會提醒你的那個機制，也就是異常帳單，是一個落後好幾週的指標。

在幾乎每一家已經用了一年 AI 的中小企業裡，都會出現三個具體缺口：

• 沒有清冊。沒有人手上有一份「哪些 Key 存在、在哪些系統裡、誰建的」的清單。最該擔心的恰恰是那些不在任何清單上的 Key，而建它們的人可能已經離職了。
• 沒有花費上限。廠商帳號上通常只有一個付款方式，頂多加一個軟性限額。一個跑飛的迴圈或者一把被盜的 Key，不會停在你選定的那個數字上。
• 看不出是誰在用。廠商主控台顯示的是這個帳號的總用量。它很少會告訴你：其中 80% 來自某個團隊的批次作業，而那個作業本來每週跑一次就夠了，現在每小時跑一次。

這個形狀，正是無程式碼自動化平台上會出現的影子 IT 問題——有人在角落裡搭了個有用的東西，然後它悄悄變成了正式系統。AI Key 版本更尖銳，因為暴露的不只是資訊，還有錢。

OpenRouter 實際收斂了什麼

OpenRouter 是一個閘道，坐在你的應用和大量模型廠商之間。你呼叫 OpenRouter，它代你去呼叫 OpenAI、Anthropic、Google、Meta 的託管模型以及其他家。它的 API 與 OpenAI 相容，這正是「遷移在實務上可行」的原因——多數用戶端函式庫只需要換掉 base URL 和 Key，而不是重寫程式碼。

真正在做治理這件事的是兩項能力。方案層級和限額的具體機制會變；在圍繞任何一個具體數字做設計之前，先看現行文件。

一把 Key、多個模型，以及廠商層級的備援路由

你的應用只持有一把憑證，而不是每家廠商一把。僅這一個變化，就讓後面所有事情變得可處理：輪替變成一次操作，清冊變成一份你真的產得出來的清單，而接入一個新模型不再意味著多一個帳號、多一張帳單、多一個會被弄丟的金鑰。

路由是另一半。因為閘道能觸達多家廠商，當主選廠商報錯或過載時，請求可以回落到備選——這很有用，但也值得實話實說：一次把你的提示詞悄悄發給了另一家廠商的備援，是一次資料治理事件，而不只是一個可用性特性。請明確設定允許哪些廠商，而不是接受預設集合。

按團隊的花費上限與用量可見性

第二項能力是：你可以在一個帳號下簽發多把 Key，每一把帶自己的額度上限，並且按 Key 看用量拆分。給行銷部的內容腳本一把自己的 Key、自己的天花板，給支援團隊的摘要器另一把。

這才是改變行為的那部分。廠商主控台告訴你這個帳號花了多少。按 Key 的拆分告訴你是哪個系統花的，而這是唯一一個別人能拿去做事的版本。而一個按 Key 的硬性上限，會把一個跑飛的腳本從「帳單驚喜」變成「一次失敗的 API 呼叫」——一個立刻自己報出來、報在正確的地方、報給闖禍那個團隊的事件。

一套可落地的遷移：盤點、切流、撤銷

先盤點，並且預期這份清單是不全的。去每家廠商的帳號裡看已簽發的 Key，然後搜你自己的地盤：託管平台的環境變數、CI/CD 的 secrets、Serverless 設定、自動化平台，以及——很難看但必須查的——git 歷史。直接去問每個團隊他們在跑什麼；人會主動交代出掃描找不到的東西。最後得到一份「Key、系統、負責人、最後使用時間」的清單。

不要跳過「這個還在用嗎」這一欄。你查出來的東西裡，相當一部分正在支撐某個沒人記得的功能。這些 Key 是純風險、零收益，也是整個過程裡最容易拿下的分。

一次遷一個工作負載，從最不關鍵的開始。換 base URL 和 Key，把舊的廠商 Key 留著但不再使用；如果這個負載重要，就短期內兩條路並行跑一陣。請求換了路由之後，模型行為可能有細微差異，所以要在真實樣本上檢查輸出品質，而不是預設它就是個無痛替換。

按使用方簽發 Key，而不是按人。一個系統或一個團隊一把 Key，額度上限依據實際觀測到的用量加餘裕來定——不是拍腦袋定。這個上限是斷路器，不是預算。

撤銷舊 Key，並確認真的撤銷了。這一步最容易被延後然後忘掉，結果是你同時擁有了新閘道和舊的散亂。先撤銷，再確認沒有東西掛掉，再去廠商主控台確認這把 Key 真的沒了。

把帳號的負責人寫下來。一個沒有具名負責人的單點收斂，就是一個單點故障。一個人負責 OpenRouter 帳號，一個人是有紀錄的備援人，而且這兩件事記錄在一個不會隨他們離職而消失的地方。

OpenRouter vs 各團隊各拿各的 Key vs 自建內部閘道

• 用 OpenRouter 收斂。一把憑證、按 Key 的天花板、按使用方的用量可見性，以及不用每次新開帳號就能用上很多模型。代價是你多了一個相依：一個中間層現在處在每一個請求的路徑上，有它自己的可用性和它自己的條款。對多數中小企業這是筆划算的交易，因為另一個選項並不是「沒有中間層」——而是「六家廠商各有各的中間層」。
• 各團隊保留自己的廠商 Key。沒有遷移成本、沒有新供應商，而且和每家廠商都是直接關係——如果某個情境確實需要某家廠商的企業級資料條款，這一點是真的重要。代價就是你現在的處境：沒有清冊、沒有上限、沒有統一視圖，而且一次輪替意味著要同時協調所有團隊。
• 自建內部閘道。控制力最強。路由、日誌、去識別化、限額都你說了算，凡是你沒發出去的東西就不會離開你的基礎架構。但它同時也是一個你現在要養的服務：值班、升級、跟著廠商 API 變化改、以及建它要花的那幾個人月。在規模夠大或者資料處理要求夠嚴的情境下站得住腳，對一家 50 人的公司則很少站得住。

適合多數中小企業的模式是：一般負載走閘道，換取可見性和天花板；同時為那一個「資料處理需要特定合約」的情境，保留一條刻意為之的廠商直連關係。

收斂解決不了什麼

一把被攻破的閘道 Key，現在能碰到所有模型。這是誠實的取捨。你把六把鬆的鎖換成了一把結實的，那這把就最好真的結實：盡可能短生命週期、按使用方收窄、按週期輪替、絕不進儲存庫。集中化是真實存在的風險，而答案是——對這一把憑證的照顧，要超過那六把中任何一把曾經得到過的。

提示詞內容仍然離開了你的網路。閘道改變的是「你向誰付費、你輪替什麼」。它並不改變這個事實：你的提示詞——裡面可能有客戶資料、內部文件或原始碼——正在被發給一個第三方，再轉給一家模型廠商。去看閘道的現行資料處理條款和各廠商的政策，並對敏感負載限制允許的廠商範圍。

故障變成共享的。當所有負載都走同一條路，中間層出問題就是所有負載同時出問題。備援路由緩解的是模型廠商的故障，不是閘道本身的故障。請提前決定哪些負載可以直接失敗，哪些需要一條「打破玻璃」的廠商直連通道——Key 保持有效但平時不用。

這裡沒有任何東西在審查大家在建什麼。對花費和憑證的治理，不等於對使用情境的治理。一個按 Key 的限額，不會告訴你某個團隊正在把客戶合約餵給一個本來就不該看到它的模型。

把它做對：輪替、最小權限，與什麼時候該讓 IT 介入

按週期輪替，也在人員離職時輪替。收斂讓輪替變得便宜，這就抽掉了過去「所以我們從來不輪替」的那個藉口。訂一個週期，寫進有負責人的行事曆，並且在任何有權限的人離開時立刻輪替。

每把 Key 只對應一個使用方。永遠不要簽發一把多個系統共用的通用 Key。當你需要緊急撤銷時，你希望只弄壞一樣東西，而且你希望在動手之前就知道是哪一樣。

用實測用量來定上限。先跑幾週，看每把 Key 的真實數字，再帶餘裕設限。憑空拍出來的天花板要麼沒用，要麼會在凌晨兩點為一個行為完全正常的負載把人叫醒。

在閘道側記錄日誌，並把日誌放在廠商刪不掉的地方。按 Key 的用量時間序列就是你的早期預警：一次無法解釋的階躍，要麼是 bug，要麼是被攻破，兩種都得當天看。

把這個帳號當正式基礎架構對待。帳號開多因素驗證、限制管理員存取、對限額變更告警、有書面負責人。持有「通往所有模型的那一把 Key」的帳號不是一次註冊，它是一套紀錄系統。

把盤點做誠實、決定什麼走閘道而什麼保留廠商直連合約、寫出一套忙起來也還會被遵守的 Key 處理規則，是 AI+ 支援的工作。底下的憑證衛生——金鑰儲存、輪替、多因素、離職回收，以及在散亂重新累積起來之前就抓住它——屬於代管 IT 資安服務。日常把它跑起來則是一般的代管 IT 支援。關於無程式碼自動化裡非常相近的影子 IT 模式，可以看我們關於用 Power Automate 做 AI 工作流自動化的文章；想在做任何決定之前先把盤點跑一遍，也可以直接聯絡我們。

常見問題

OpenRouter 會看到每一條提示詞的內容嗎？

請求要經過閘道，所以請把內容視為對它可見，並據此治理。具體記錄什麼、留多久、按什麼條款，由現行文件和你的帳號設定（包括各廠商的資料政策）決定——請直接去讀那些，而不是依賴任何摘要，包括這一篇。對真正敏感的負載，更穩妥的設計是與一家你確實審過其企業條款的廠商建立刻意為之的直連關係。

如果 OpenRouter 自己掛了怎麼辦？

所有走它的東西會同時受影響。備援路由幫的是模型廠商掛掉的情況，不是閘道掛掉的情況。請提前決定哪些負載可以直接失敗，哪些需要一條「打破玻璃」的通道：一把保持有效、也在輪替的廠商直連 Key，加上一份告訴別人怎麼切過去的操作手冊。沒演練過的應急通道，在事故中第一次演練時是不會成功的。

某個敏感情境還能直連廠商嗎？

可以，而且對很多公司來說這才是正確架構：一般負載走閘道，那個需要特定合約的情境保留一條直連。關鍵在於這個例外是刻意的、有紀錄的，而不是遷移之前遺留下來的。一個沒有紀錄的例外，和散亂是分不出來的。

怎麼給每個團隊設硬性花費上限？

按團隊或系統分別簽發 Key，並給每一把掛上額度上限；具體機制看現行文件。數字要基於幾週的實測用量加餘裕，而不是猜。另外還要決定：一把 Key 撞到天花板時應該發生什麼——呼叫失敗正是目的，但得有人被通知到，而且這個告警應該發給擁有這個負載的團隊，而不是只發給帳號擁有者。

這比直連各家廠商更便宜嗎？

成本不是主要論點，也不要預設它會下降。閘道可能在底層廠商定價之上加一層。收斂可靠買到的是可見性、天花板，以及一次操作就能完成的輪替。實務中真正出現的節省，往往來自「看清了每個使用方的用量」，然後發現某個每小時跑一次的負載其實並不需要那麼跑。

需要改我們的應用程式碼嗎？

通常改得很少。它的 API 與 OpenAI 相容，多數用戶端換個 base URL 和 Key 就行。時間要預留給驗證而不是重寫：在真實樣本上確認輸出仍然是你期望的，因為路由可能把你的請求送到了和以前不同的模型或廠商面前。

有團隊不肯遷怎麼辦？

把它當治理問題，不是技術問題。由一個有權限的人立下規則：新的 AI 負載一律走閘道，既有的在某個明確的日期前遷完。沒有這條，你會同時擁有一個閘道和繼續擴散的散亂，那比兩者中任何一個單獨存在都更糟——你多了一樣要管的東西，卻沒拿到你當初要的那份可見性。