服務賬號與計費組

Service Accounts 解決“自動化不能綁在個人賬號上”的問題，Billing Groups 解決“AI 程式設計成本要歸到團隊或專案”的問題。兩者放在一起，才是企業規模化使用 Cursor 的管理底座。

1. 一句話判斷

真人賬號用於開發者互動，Service Accounts 用於 CI、API、CLI、Cloud Agents 自動化；真人成本和自動化成本都要進入 Billing Groups 和 Analytics。

不要用離職員工、平臺 owner 或共享郵箱的賬號跑自動化。那會製造許可權、審計、金鑰輪換和成本歸因問題。

2. Service Accounts 適合做什麼

官方定義 Service Accounts 為 Enterprise 裡的 non-human accounts，可用於：

• consume APIs。
• authenticate CLI。
• invoke Cloud Agents。
• 把自動化從個人賬號中解耦。

典型場景：

• Linear issue 建立後自動觸發 Cloud Agent 實現功能。
• Sentry 錯誤觸發 Cloud Agent 排查和修復。
• 內部工程平臺觸發遷移、重構、依賴升級。
• CI/CD 或 cron job 執行 Cursor CLI。

3. Service Accounts 的關鍵邊界

官方文件給了幾個關鍵點：

• Service Accounts 不消耗 seat license。
• 它們的 usage 消耗團隊 usage pool。
• 使用情況會進入團隊 analytics 和 billing。
• Service Accounts 發起的 Cloud Agent runs 對所有 team admins 可見。
• Cloud Agent repository access 依賴 team-level Cursor GitHub app 授權。

這裡最容易踩坑的是 GitHub 授權。個人 GitHub integration 不夠，Service Accounts 要訪問儲存庫，必須有 team-level GitHub integration。

4. 建立和輪換

建立路徑：

1. 進入 Cursor Dashboard。
2. 開啟 Settings。
3. 進入 Service Accounts。
4. 建立新的 Service Account。
5. 複製 API key，並立刻儲存到企業金鑰系統。

API key 只顯示一次，丟失後只能 rotate。

管理要求：

• 每個自動化工作流一個獨立 Service Account。
• 名稱要描述用途，例如 linear-agent-runner、sentry-autofix。
• key 有輪換週期和 owner。
• 廢棄自動化要 archive account，撤銷所有 API keys。
• 不把 Service Account key 寫進儲存庫、日誌、CI 輸出或教程截圖。

5. CLI 與 API 用法邊界

Service Accounts 可透過 API key 調 Cloud Agents API，也可透過 CURSOR_API_KEY 認證 Cursor CLI。

CI 中只應透過 secret store 注入環境變數：

export CURSOR_API_KEY="$CURSOR_SERVICE_ACCOUNT_KEY"
agent -p --force "Run the approved maintenance task"

不要把 API key 寫進指令碼、Docker image、README 或 issue。所有自動化都要產出 PR、日誌或可審計工件。

6. Billing Groups 解決什麼

Billing Groups 讓 Enterprise admins 按使用者組理解和管理 spend，適合 reporting、internal chargebacks、budgeting。

官方規則：

• 每個成員一次只能屬於一個 billing group。
• 未分配成員進入保留的 Unassigned group。
• usage 按發生時的使用者所在 group 歸屬。
• 使用者後來移動 group，不會改變歷史歸屬。
• 刪除 group 是破壞性操作，歷史 usage 會回到 Unassigned。

7. 分配 Billing Groups 的四種方式

官方支援四種方式：

• SCIM：同步現有 IdP group。
• API：透過 Admin API 建立 group 並新增成員。
• CSV：上傳 group name 和 member email。
• Manual：手動選擇 Unassigned 成員加入 group。

如果 group 由 SCIM 同步，成員分配必須在 IdP 管理，不能透過 CSV、API 或 UI 修改。

建議優先順序：

1. 組織穩定、IdP 組清晰：用 SCIM。
2. 平臺工程自動化強：用 Admin API。
3. 一次性遷移：用 CSV。
4. 小團隊或臨時試點：手動。

8. 成本治理閉環

Billing Groups 不只是財務報表。它應該接到這些流程：

• 每月看 group spend、成員數、自動化 usage。
• 高成本 group 拆分模型使用、Cloud Agents、CLI、Service Accounts。
• 預算異常時先看 team settings、spend limits、service account activity。
• 新團隊上線前先建 group，再發賬號和自動化許可權。
• 刪除 group 前確認歷史 usage 是否能接受回到 Unassigned。

9. 商業級驗收

• 自動化全部改用 Service Accounts，不繫結個人賬號。
• 每個 Service Account 有 owner、用途、key rotation、許可權範圍。
• Service Account usage 能在 analytics 和 billing 中看到。
• Team-level GitHub integration 已連線，只授權必要儲存庫。
• CI/CD、cron、內部平臺透過 secret store 注入 CURSOR_API_KEY。
• Billing Groups 覆蓋團隊、部門或專案成本中心。
• Unassigned group 每月清理，不能長期堆積真實使用者。
• SCIM-synced group 的成員變更只在 IdP 中執行。
• 刪除 billing group 前完成歷史 usage 歸屬確認。

10. 常見失敗點

• 用個人賬號跑自動化，員工離職後任務失效。
• 一個 Service Account 承載所有自動化，審計和輪換不可控。
• Service Account key 打進 CI 日誌或儲存庫。
• 只有個人 GitHub integration，Service Account 無法訪問儲存庫。
• Billing Groups 建了但沒人維護 Unassigned。
• 刪除 billing group 後才發現歷史成本無法恢復。

官方來源

• https://cursor.com/docs/enterprise.md
• https://cursor.com/docs/account/enterprise/service-accounts.md
• https://cursor.com/docs/account/enterprise/billing-groups.md
• https://cursor.com/docs/cloud-agent/api/endpoints.md
• https://cursor.com/docs/cli/reference/authentication.md
• https://cursor.com/docs/account/teams/admin-api.md

接下來去哪