摘要： OpenRouter 在 2026 年 4 月 22 日推出 Workspaces，讓同一帳號下的專案、團隊與環境分開管理，各自設定 API keys、guardrails、routing、presets、plugins、observability、BYOK 與成員。帳號層級的額度帳單、組織管理、management keys 與資料政策仍共用，workspace 只能把繼承政策收得更嚴，不能放寬。只要成員留在組織內就仍能進 Default workspace，Chatroom 與 Fusion 也還未提供完整環境隔離。
一個帳號，終於能長出多個工作環境
愈來愈多團隊開始認真對待自己的 LLM 路由層。OpenRouter 在 4 月 22 日上架了名為 Workspaces 的新功能，說白了，就是讓你在同一個帳號之內，把不同專案、團隊與環境各自劃開來管。這篇不打算寫成新聞稿，我想站在產品設計的角度，老實盤點這項功能究竟處理了什麼問題、目前又留下哪些缺口。
若你至今仍守著 OpenRouter 的「Default workspace」單兵作戰，這次更新對你而言近乎無感：既有的 API keys、金鑰與各項設定原樣不動，照舊使用即可。真正被這波改變觸及的，是那些帳號裡已經塞了三四個專案、或者陸續有協作者加入的人。
一個 Workspace 就是一座自給自足的小島
依照 OpenRouter 於 2026 年 4 月 22 日發出的公告，Workspace 的核心設計是「環境隔離」，下列項目都可以在每個 Workspace 裡分開設定：
- API keys ── 金鑰封在單一 Workspace 內，不會流出到其他專案。
- Guardrails ── 針對該 Workspace 的所有金鑰與成員套上治理規則。
- Routing 偏好 ── 各個 Workspace 能分別定義路由邏輯（成本、延遲、吞吐量等）。
- Presets ── 常用的系統提示與模型參數可存成捷徑。
- Plugins ── 各 Workspace 的 API 請求能套用不同的預設外掛行為。
- Observability 整合 ── 各 Workspace 可分頭接上不同的監控工具，也能全部匯進同一處。
- BYOK（自帶金鑰） ── provider 金鑰可選擇綁在特定 Workspace，或開放跨 Workspace 共用。
- Members ── 誰能檢視、操作哪個 Workspace，可以逐一指定。
對同時維運「staging」與「production」兩套環境的團隊來說，這套設計格外對味：切換環境不必再手動調 routing，也不怕 staging 的測試流量誤觸 production 的 observability 整合。
真正畫下上限的，是帳號層級的設定
多環境架構最頭痛的戲碼，莫過於「我在 A 處的設定被 B 處蓋掉」。OpenRouter 的應對是把設定拆成兩層：
Account level（帳號層級，全域共用） 以下項目整個帳號只有一份，所有 Workspace 共用：
- 活動記錄與日誌（可依 Workspace 篩選）
- 額度與帳單
- 組織成員管理與角色指派
- Management keys（用來跨 Workspace 執行管理的 API 金鑰）
- 隱私與資料政策（零記錄、資料保留等）
Workspace level（工作區層級，彼此獨立） 在帳號層級畫出的「天花板」底下，各 Workspace 只能把 guardrails 往嚴格方向加，不能反向放寬。打個比方：帳號層級若是封禁了某個 model，任何 Workspace 都別想暗中把它重新打開。這種「繼承式」的權限設計實務上一聽就懂，也把權限蔓延的路堵死了。
動手之前，先把成員權限的邊界讀清楚
打算將 Workspaces 用於團隊協作的話，底下幾條邊界條件值得先背起來。OpenRouter 的 FAQ 講明這些都是刻意為之的設計：
- Workspace 成員看得到什麼 ── 同一個 Workspace 裡的成員能建立並管理自己的 API keys，也能查看該 Workspace 的成員名單與角色。若一個人隸屬多個 Workspace，各個 Workspace 的內容會分開呈現給他。
- Org admin 的權力範圍 ── 組織管理員等於橫跨所有 Workspace 的超級使用者：每一個 Workspace 裡的全部內容（金鑰、guardrails、routing、presets 等）他們都能檢視與編輯。建立或刪除 Workspace、決定誰能進哪個 Workspace，同樣是 org admin 的專屬權限。
- 移除成員的前置作業 ── 要把某人從 Workspace 踢除，得先刪掉他在該 Workspace 內建立的 API keys；他在其他 Workspace 的權限不受波及。另一個關鍵細節：只要此人還留在組織裡，他對 Default workspace 的存取權就「永遠」成立。
這最後一條相當耐人尋味。Default workspace 對組織全員預設敞開，你無法一邊把人留在組織內、一邊把他擋在 Default workspace 之外。真需要徹底隔離某位成員，只有兩條路：把他縮限到僅剩必要的那個 Workspace（Default 依舊看得到），或者直接請他離開組織。
Management API 能在實戰裡做什麼
伴隨功能上線，OpenRouter 也開放了 Management API，讓 Workspace 能以程式建立與管理。對需要大批部署的場景，這點分量十足。Management keys 的效力範圍是帳號層級，因此單憑一把 key 就能調度所有 Workspace 的設定，犯不著替每個環境另外發行管理金鑰。
換句話說，你可以把 Workspace 視為「基礎設施即程式碼」的操作單位：在 CI/CD 流程裡用 API 自動開出新的 staging Workspace、灌入對應的 routing presets，測試收尾後再一口氣刪除。
第一版還補不齊的缺口
任何新功能的第一版都有極限。OpenRouter 在公告與 FAQ 裡便親自點出一項：Chatroom 和 Fusion 目前只能綁在 Default workspace，還無法搬進其他 Workspace 運作。假如你的團隊主要透過這兩個介面協作，短期內仍得回到 Default workspace 操作。
此外，帳號層級的資料政策是不折不扣的硬上限，Workspace 層級只准「更嚴」、不准「更寬」。這對合規是利多，但若你原本盤算讓各個 Workspace 擁有完全獨立的 privacy 設定（例如生產環境開零記錄、實驗環境保留日誌），這個願望現階段還無法實現。
下一步怎麼走比較務實
如果你是一個人開發，Default workspace 用得順手，那就維持現狀，不必折騰。
反過來說，下列痛點只要中了任何一項，Workspaces 就值得你花一個下午把它設好：
- 好幾個專案共用同一把 API key，深怕金鑰一旦外洩，波及範圍太廣。
- staging 與 production 的 routing 邏輯不一致，每回部署都得手動改設定。
- 團隊成員各管各的，你希望 A 只能碰專案 X、B 只能碰專案 Y。
這項功能才剛上線，OpenRouter 團隊正在蒐集回饋。實際用過之後，若你覺得某些邊界條件欠合理，不妨直接透過他們的 Discord 或 X（原 Twitter）反映，這類產品的迭代步調一般都不慢。
整體來看，Workspaces 算不上什麼耀眼的 AI 功能，倒是一次腳踏實地的基礎架構升級。它推著 OpenRouter 從「單人用的 API 路由工具」走向「團隊可治理的 LLM 閘道」——對真正把 LLM 當產品基礎設施在經營的人而言，這一步來得剛剛好。