服务账号与计费组

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

接下来去哪