當「一個帳號」已經不夠用
不少開發團隊都在升級自己的 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，那他會分別看到各自的內容。
- Org admin 的權限 ── 組織管理員是跨 Workspace 的超級使用者：他們可以查看、編輯每一個 Workspace 裡的所有東西（含金鑰、guardrails、routing、presets 等）。只有 org admin 能建立或刪除 Workspace，以及控制誰能進哪個 Workspace。
- 移除成員的步驟 ── 把人從 Workspace 踢掉之前，必須先刪除他在該 Workspace 內建立的 API keys。他的其他 Workspace 權限不受影響。特別注意：只要這個人還在組織裡，他就「永遠」擁有 Default workspace 的存取權。
最後這一點很微妙。Default workspace 對所有組織成員預設開放，你不能把某人鎖在 Default workspace 外面卻同時留他在組織裡。如果你需要完全隔離某個成員，要嘛把他降級到只留在他需要的那個 Workspace（但還是看得到 Default），要嘛直接從組織移除。
Management API 的實戰意義
OpenRouter 同時開放了 Management API，讓你可以透過程式建立與管理 Workspace。這對需要大量部署的場景很重要。Management keys 本身運作在帳號層級，所以一把 key 就能管理所有 Workspace 的設定，不需要為每個環境生出不同的管理金鑰。
換句話說，你可以把 Workspace 當成一種「基礎設施即程式碼」的單位，透過 API 在 CI/CD 流程裡自動建立新的 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 當成產品基礎設施的人來說，來得正是時候。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。