# 39 · 企业管理与治理：一个人玩和一家公司用，是两件事

> 📚 **系列导航**：上一篇〔[38 术语表（小白友好）](38-glossary.md) 〕把整个 Codex 篇出现过的黑话攒成了一份随查随翻的词典——那是给你「读懂别人」用的。这一篇是 **Codex 篇的最后一篇，也是一篇选读**：面向**团队管理员 / 技术负责人**，讲一家公司怎么把 Codex 安全、可控、可审计地铺给一整支团队。**如果你是个人用户，这篇可以直接跳过**，前面 38 篇你已经够用了；但如果你哪天要负责给团队开通，再回来看这篇也不迟。这是终点，文末我给整个 Codex 篇做个收尾。

说句可能得罪人的话：**一个人玩 Codex 和一家公司用 Codex，根本是两件事。**

你自己用，关心的是「这模型聪不聪明、跑得快不快、好不好用」。可一旦你是那个要拍板「全公司 200 个工程师都用它」的人，你脑子里第一个蹦出来的问题往往不是「好不好用」，而是——**「我们的代码会不会被拿去训练？谁动了什么我能不能查到？哪天有人手贱让它 `rm -rf` 了生产配置，我拦得住吗？」**

我自己就踩过这个认知差。今年四月帮一个朋友的小团队评估要不要上 Codex，我兴冲冲给他演示了一通多强多快，他听完只问了我一句：「**那我们客户的代码，OpenAI 会不会拿去训模型？**」我当场卡壳——我压根没研究过这块，只能灰头土脸回去翻官方文档。那次之后我才明白：**对管理员来说，「治理」不是锦上添花，是能不能用的前提。**

这一篇就把这个前提讲清楚。

**看完这一篇，你会拿到：**

- 个人版和团队 / 企业版到底差在哪——**有些治理能力，不是配置开关，是套餐门槛**
- 统一开通与账号管理：SSO、SCIM、RBAC 这三个缩写，对管理员到底意味着什么
- 最关心的数据问题：**代码会不会被拿去训练、数据存在哪、留多久**，官方怎么说
- 怎么用一份「集中下发的策略文件」给全团队拧死安全底线，不用挨个电脑配
- 审计与合规：谁干了什么、用了哪个模型、token 谁建的，怎么导出来对账
- 成本与额度怎么看、怎么管，别月底被账单吓一跳
- 一份给管理员的「上线前自检清单」，照着走一遍再铺开

> ⚠️ 下文凡涉及具体页面、命令、配置项、默认行为，都以 Codex [企业文档](https://developers.openai.com/codex/enterprise/admin-setup) 为准；模型名、套餐、各项能力的可用范围会随版本和你的具体合同变动，**看到时一律以你自己工作区后台实际显示的为准**，本篇不写死。企业治理能力大多绑定 **ChatGPT Business / Enterprise** 套餐，你能不能看到某个开关，取决于你的套餐和角色。

---

## 01 先认清：个人版和企业版差的不是功能，是「管得住」

很多人以为企业版就是「个人版 + 更多额度」。不对。

**类比：自己家厨房和中央厨房。** 你在自己家做饭，刀放哪、火开多大、要不要洗手，全凭你自己；没人管，也不需要人管。可一家连锁餐厅的中央厨房，光「能做饭」远远不够——你得有**统一的操作规程**（谁都不能凭手感）、**门禁和工牌**（谁能进哪个区域）、**监控录像**（出事能倒查）、**进货台账**（成本对得上）。企业版 Codex 多出来的那一大块，全是这套「管得住」的能力，而不是「更能做饭」。

具体差在哪，一张表看明白：

| 维度 | 个人版（Plus / Pro 等） | 团队 / 企业版（Business / Enterprise） |
|---|---|---|
| **谁能用** | 你一个人，自己说了算 | 管理员在工作区后台统一开关，可按角色 / 分组授权 |
| **登录方式** | 自己的账号密码 | 可强制 **SSO**（单点登录）、**MFA**（多因素）、**SCIM** 自动同步账号 |
| **安全底线** | 自己在本机配 `sandbox`、审批 | 管理员**集中下发策略**，用户改不动（`requirements.toml`） |
| **数据训练** | 看你账户设置 | **企业数据不用于训练**，官方明确承诺 |
| **审计** | 基本没有 | 可导出活动日志、谁干了什么、合规对账 |
| **用量观测** | 自己界面看个大概 | Analytics 仪表盘 + API，按人 / 按产品面拆开看 |
| **谁来管** | 没有「管」这一说 | 专门的 Codex Admin 角色，管策略、环境、分析 |

看出来了吧——**右边这一整列，本质上都不是「功能」，是「控制权」**。个人用户压根用不上，但对管理员，这一列才是真正的核心。

还有个一开始容易绊倒人的点：**Codex 分「本地（local）」和「云端（cloud）」两套，开通是分开的。**

Codex local（本地）包括桌面 App、CLI、IDE 扩展，代理跑在开发者自己电脑的沙箱里。Codex cloud（云端）包括云端任务、Code Review、iOS 等，代理跑在托管的远程容器里，需要把代码库（目前要求 GitHub 云端仓库）接进去。

管理员可以只开本地、只开云端、或者两个都开。**这个选择直接决定了「代码在哪台机器上被处理」，是你做数据评估时第一个要拍板的事。** 我那次给朋友评估，就是先卡在这——他们代码在自建 GitLab 上，云端那套直接用不了，只能走本地 + SDK 自建，评估方向当场就变了。

> 💡 一句话总结：企业版多出来的不是「更能干」，是「管得住」——授权、策略、审计、成本，这四样才是管理员要的东西。

---

## 02 统一开通与账号管理：SSO、SCIM、RBAC 三件套

团队上工具，第一个头疼的从来不是「好不好用」，是「**怎么给一群人开通、又怎么在有人离职时干净地关掉**」。手动一个个加，加到第二十个你就崩溃了，更别说有人走了你忘了关。

这就是 SSO、SCIM、RBAC 这三件套要解决的。

**类比：公司的门禁工牌系统。** SSO 是「一张工牌刷所有门」（不用每个系统记一套密码）；SCIM 是「HR 系统里入职 / 离职，门禁自动开 / 关」（账号跟着人事走，不用 IT 手动操作）；RBAC 是「工牌上的权限等级——实习生只能进工区，财务才能进机房」（不同角色看到不同的开关）。

逐个说人话：

**SSO（Single Sign-On，单点登录）**——员工用公司统一的身份（比如 Okta、Azure AD）登录 Codex，不用单独注册。管理员还能强制要求 **MFA**（多因素认证），把弱密码这条路堵死。

**SCIM（账号自动同步）**——把 Codex 的用户分组接到你的身份提供商（IdP）。有人入职，IdP 里一加，他自动进对应的组、拿到对应权限；有人离职，IdP 里一删，访问自动收回。**关键价值是「可审计、集中管」**——成员变动有迹可循，不靠某个 IT 同事的记性。

**RBAC（Role-Based Access Control，基于角色的访问控制）**——这是管理员最该上心的一个。官方给了一套很值得照抄的分组模式：

- 建一个「Codex Users」组给所有该用 Codex 的人；
- 再单独建一个「Codex Admin」组，只放少数该管策略和设置的人；
- 把「允许管理 Codex」这个权限**只**给 Codex Admin 组。

为什么要这么分？因为 **Codex Admin 能动的东西很重**——能看全工作区的用量分析、能改下发给所有人的安全策略、能管云端环境。这种权限给宽了，等于把全公司的安全底线交给一堆人随便改。**官方的原则就一句：管理权限给最少的人。** 我自己的习惯是，这种「能改全员策略」的角色，宁可只给两三个人，也不图省事开给一整个 team。

动手层面，管理员开通的大致路径是这样（具体页面以你后台为准）：

```text
1. 进 ChatGPT 企业后台 → Workspace Settings → Settings and Permissions
2. 打开「Allow members to use Codex Local」→ 本地三件套（App/CLI/IDE）可用
3. 若要云端：打开「Allow members to use Codex cloud」+ 接好 GitHub 连接器
4. 进 Custom Roles，建 Codex Users / Codex Admin 两个组，按上面的模式分权
5. 用 SCIM 把这两个组接到你的 IdP，成员变动自动同步
```

新工作区**默认就开了 Codex local**；如果某个用户登录时撞到 `403 - Unauthorized. Contact your ChatGPT administrator for access.`，八成就是这个本地开关没打开，或者他不在被授权的组里。

> 💡 一句话总结：SSO 管「怎么进」、SCIM 管「人来人走自动同步」、RBAC 管「谁能看到哪个开关」——管理权限永远给最少的人。

---

## 03 数据治理：代码到底会不会被拿去训练

这是我那次评估卡壳的问题，也是几乎每个团队负责人问的第一个问题。直接给结论，全是官方白纸黑字写的：

> - 不用企业数据训练模型（No training on enterprise data）
> - 本地三件套（App、CLI、IDE）支持零数据留存（Zero Data Retention），代码留在开发者环境里
> - 数据驻留（residency）和留存策略，跟随你的 ChatGPT Enterprise 设置
> - 静态加密 AES-256、传输加密 TLS 1.2+
> - 可通过 Compliance API 做审计日志

把这几条翻译成管理员真正关心的三个问题：

**第一，会不会拿去训练？** 不会——企业数据不用于训练模型。这是企业版相对个人版一个实打实的承诺差异。

**第二，代码存在哪、留多久？** 本地三件套支持**零数据留存（ZDR）**——说白了，Codex 在你开发者的机器上干活，代码不往 OpenAI 那边长期留。云端那套因为要把仓库接进托管容器，涉及的数据驻留和留存，跟随你 Enterprise 合同里的设置走。**所以「本地 vs 云端」不只是性能选择，更是数据流向选择。**

**第三，驻留（residency）能不能锁区域？** 可以在下发的策略里用 `enforce_residency` 这类键约束（比如 `enforce_residency = "us"`），让数据处理留在指定区域。具体支持哪些区域、怎么生效，以你的合同和官方[企业配置文档](https://developers.openai.com/codex/enterprise/managed-configuration) 为准。

这里有个细节我得替你点破，不然容易误判：**审计日志和「代码留存」是两码事。** Codex 用 ChatGPT 身份登录跑的活，会产生一份审计记录（给合规用的，下一节细讲），**这份审计日志官方说保留最长 30 天**；而「不拿来训练、本地 ZDR」管的是「你的代码会不会被 OpenAI 留下来用」。一个是「为了让你能查」，一个是「为了不让别人用」，别混。

**类比：银行的「监控录像」和「不挪用你存款」。** 监控录像（审计日志）留一段时间是为了出事能倒查；「不挪用你的钱去放贷」（不训练、ZDR）是另一码事的承诺。两条你都需要，但别把一条当成另一条。

> 💡 一句话总结：企业数据不训练、本地三件套零留存、可锁数据驻留区域——但「审计日志保留 30 天」和「代码不被留存训练」是两套独立的承诺，分开理解。

---

## 04 集中下发策略：给全团队拧死安全底线，不用挨个配

第 15、16 篇里我们聊过本地的 `sandbox`、审批、`requirements.toml`——那是「**你自己**给**自己**的机器拧螺丝」。但你是管理员，总不能跑去 200 台电脑挨个配吧？

企业版的解法是：**把策略集中下发，用户本地改不动。**

**类比：连锁店总部下发的操作手册。** 单店店长能调的是「今天上不上新品」这种日常；但「食材保质期红线、收银对账流程」这种安全底线，是总部统一下发、各店必须执行、店长改不了的。Codex 的企业策略就是这本「总部手册」。

官方把可下发的东西分成两类，务必分清：

| 类型 | 是什么 | 用户能不能改 |
|---|---|---|
| **Requirements（强制要求）** | 管理员钉死的安全约束：允许哪些审批策略、哪些沙箱模式、能不能联网、能用哪些 MCP 服务器…… | **改不动**，冲突时 Codex 自动回退到合规值并提示用户 |
| **Managed defaults（托管默认值）** | Codex 启动时套用的起始值 | 会话里能临时改，但下次启动又被重置回托管默认 |

这两个的载体都是 TOML 文件，管理员主要打交道的是 `requirements.toml`（强制要求）和 `managed_config.toml`（托管默认）。**最省事的下发方式是「云端托管」**——在 [Codex 策略页](https://chatgpt.com/codex/settings/policies) 写好，绑定到某个用户组，用户用 ChatGPT 登录后，本地三件套自动拉取生效，**根本不用先往每台电脑塞文件**。

举个最常见的需求：**禁掉「全权限裸奔」、把审批和沙箱锁在安全档**。下发这么一段就行（这是官方给的示例，按你需要改）：

```toml
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
```

这两行的效果是：**封死 `--ask-for-approval never` 和 `--sandbox danger-full-access`（也就是 `--yolo`）**——不管哪个聪明的同事想偷懒裸奔，这道墙拦着他。

再比如，你想给全员**禁用某些实验性能力**（比如电脑操控），下发：

```toml
[features]
browser_use = false
in_app_browser = false
computer_use = false
```

或者你想**对某些高危命令强制弹审批**：

```toml
[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "推送 / 提交前必须人工确认" },
]
```

**注意：requirements 里的规则只能是 `"prompt"`（弹审批）或 `"forbidden"`（禁止），不能用 `"allow"` 给用户放权——这是设计上的，企业策略只用来「收紧」，不用来「放宽」。**

对管不了云端、要走设备管理的场景（比如纯本地、用 MDM 推配置的公司），官方也支持 macOS 的 MDM（Jamf Pro、Fleet、Kandji 这类）下发 base64 编码的 TOML，以及 `/etc/codex/requirements.toml`（Unix）/`%ProgramData%\OpenAI\Codex\requirements.toml`（Windows）这类系统级文件。**平台差异要留意**：路径在 Mac/Linux 和 Windows 上不一样，云端托管则跨平台统一，新团队优先走云端托管最省心。

> 💡 一句话总结：用 `requirements.toml` 集中下发安全底线，云端托管最省事，用户改不动——企业策略只负责「收紧」，不负责「放权」。

---

## 05 审计与合规：谁干了什么，导得出来

策略拧死了底线，但你还得能回答「**出事了，谁在什么时候、用哪个模型、干了什么**」。这就是审计。

官方给了三个层次的观测手段，按「从轻到重」记：

| 工具 | 干什么用 | 谁用 |
|---|---|---|
| **Analytics 仪表盘** | 后台点开就看：谁在用、用多少、Code Review 反馈如何 | 管理员日常自助看 |
| **Analytics API** | 把每日用量结构化拉进你的数仓 / BI | 接报表、做领导汇报 |
| **Compliance API** | 导出详细活动日志，接进 SIEM / eDiscovery / DLP | 安全、法务、合规调查 |

日常你打开 [Analytics 仪表盘](https://admin.openai.com/analytics/codex) 就够了——能按 CLI / IDE / 云端 / Code Review 等不同产品面拆开看活跃用户、用量、token 消耗，还能导出 CSV / JSON。**注意官方提示：用量数据可能有最长 12 小时的延迟**，别拿它当实时监控用。

真要做合规调查、追责，得动 **Compliance API**。它能导出的东西很细：

它能导出的字段包括：发给 Codex 的 prompt 原文、Codex 生成的回复、工作区 / 用户 / 时间戳 / 模型等标识、token 用量与请求元数据。也就是说，你能回答「谁跑了这个任务」「谁创建或吊销了某个 access token」「什么时候跑的」「用了哪个模型」。

管理员实际拉日志，大致长这样（具体 endpoint 和参数以官方为准）：

```bash
curl -L -H "Authorization: Bearer YOUR_COMPLIANCE_API_KEY" \
  "https://api.chatgpt.com/v1/compliance/workspaces/WORKSPACE_ID/logs?event_type=CODEX_LOG&after=2026-03-01T00:00:00Z"
```

**预期效果**：返回一批可下载的合规日志文件清单，你再按 `log_file_id` 逐个拉下来，接进自己的 SIEM 做监控和归档。

两个坑我替你标出来，别掉进去：

**第一，审计日志保留 30 天**——上一节说过，这是窗口期，**超过 30 天的记录别指望还能拉到**，要长期留存就得自己定期导出归档。

**第二，只有用 ChatGPT 身份登录跑的活才进合规导出**。官方原话：**用 API key 认证的 Codex 用量，走的是你 API 组织的设置，不在 Compliance API 导出范围内**。所以如果你的团队有自动化是用 Platform API key 跑的，这部分审计得去 API 组织那边另算，别在这儿干等。

还有个跟审计强相关的东西要管：**access token（访问令牌）**。它是给自动化（CI、定时任务、`codex exec` 脚本）用的「Codex 身份令牌」，跑出来的活会挂在创建它的那个工作区成员名下、进治理数据。管理员要把它当密钥管：

- 存进密钥管理器、别进日志、定期轮换、设有限期（7/30/60/90 天比「永不过期」强）、用完即吊销；
- 公开 CI、fork 的 PR、共享机器上别用——这些地方令牌容易泄露给工作区外的人。

我自己的经验是：**access token 千万别图省事设「永不过期」**。去年我有个个人脚本的令牌挂了大半年没动，后来排查时光是确认「这玩意儿现在还有没有效、是谁建的、还在哪用」就折腾了半小时。给团队管的时候，有限期 + 定期轮换是省心的唯一解。

> 💡 一句话总结：日常看 Analytics 仪表盘，合规追责用 Compliance API；记住两条红线——日志只留 30 天、只有 ChatGPT 登录的用量进合规导出。

---

## 06 成本与额度管控：别月底被账单吓一跳

最后聊钱。团队用 AI 工具，最怕的就是「**月底账单一来，没人知道这钱花哪了**」。

Codex 的成本观测，主要还是靠上一节那个 **Analytics 仪表盘 / API**——它能把 credit（额度）和 token 消耗按**产品面**（CLI / IDE / 云端 / Code Review）和**按人**拆开，谁是消耗大户一目了然。

**类比：家庭账本的分类记账。** 你想知道钱花哪了，光看「这月花了一万」没用，得拆成「房租、吃饭、打车」。Analytics 的「按产品面 / 按人」拆分，就是给你这本分类账——哪个 team 在云端跑得凶、谁天天把推理强度拉满，数据摆在那。

管理员能动的成本旋钮，大致三类：

**第一，从策略层面省**。前面下发 `requirements.toml` 时，顺手就能把「贵的用法」收一收——比如限制沙箱模式、禁掉某些重型实验功能，本身就是在控成本。

**第二，从模型 / 推理强度层面省**。第 30 篇讲过，**推理强度拉满最烧钱**。你可以在 `managed_config.toml` 里给全团队定个保守的默认值（比如 `model_reasoning_effort = "medium"`），让大家从合适档位起步，而不是人人开局 `xhigh`。轻量子任务用 `gpt-5.4-mini` 这类小模型，也能显著压成本。

**第三，从额度 / 服务层级层面管**。`service_tier` 这类配置（`fast` 速度提升 1.5x 但积分消耗更高；`flex` 为另一内置值，具体差异以你的合同和后台为准）也能在托管默认里统一定调，把「默认走省钱档」变成团队习惯。

这里给你一个我自己带团队总结的「成本对账节奏」，照做能少踩很多坑：

| ❌ 容易翻车的做法 | ✅ 更稳的做法 |
|---|---|
| 等月底账单来了才看 | 每周固定看一次 Analytics，盯异常增长 |
| 全员默认 `xhigh` 顶格推理 | 托管默认设 `medium`，真难的活再手动拉高 |
| 谁都能用最贵的旗舰 + 全功能 | 用策略给大多数人定保守档，放开给少数重度场景 |
| 没人对账，出问题甩锅 | 指定一个「用量负责人」，定期出报告 |

官方也建议得很实在：**给「采用情况报告」和「审计合规」各指派一个负责人，定一个复盘节奏，先想清楚「成功长什么样」再铺开。** 别上来就全员放开，等花超了再回头收——那时候习惯已经养坏了。

> 💡 一句话总结：成本靠 Analytics 按人 / 按面拆账，靠托管默认把推理强度和服务层级定在保守档，再指个人定期对账——别等月底账单教你做人。

---

## 07 小结

这一篇我们站在管理员的角度，把「一家公司怎么用好 Codex」的几块拼图凑齐了：

- **个人版和企业版，差的是「管得住」**——授权、策略、审计、成本，这四样才是核心，不是「更能干」。
- **账号管理三件套**：SSO 管登录、SCIM 管人来人走自动同步、RBAC 管谁能碰哪个开关；管理权限永远给最少的人。
- **数据治理**：企业数据不训练、本地三件套零留存、可锁驻留区域；但「审计日志留 30 天」和「代码不被训练留存」是两套独立承诺。
- **集中下发策略**：用 `requirements.toml` 给全员拧死安全底线，云端托管最省事，企业策略只收紧不放权。
- **审计合规**：日常看 Analytics 仪表盘，追责用 Compliance API；记牢「日志留 30 天、只有 ChatGPT 登录的用量进导出」两条红线。
- **成本管控**：按人 / 按产品面拆账，托管默认把推理强度和服务层级定在保守档，指个负责人定期对账。

**你现在应该能**：判断自家团队该开本地还是云端、回答老板「代码会不会被训练」、用一份策略文件给全员定好安全底线、知道出事了去哪导日志、以及怎么在月底账单炸锅前就把成本盯住。这些不是让你今天就全配完——而是当你哪天真要拍板上线，你心里有谱、有据、有清单。

最后给你一份**上线前自检清单**，铺开前照着过一遍：

- [ ] 确定了用本地 / 云端 / 还是两个都开（直接决定数据流向）
- [ ] 指定好三类负责人：工作区 owner、安全 owner、分析 owner
- [ ] 建好 Codex Users 与 Codex Admin 两个组，管理权限只给少数人
- [ ] SSO / MFA / SCIM 接好，成员变动可自动同步、可审计
- [ ] 下发了 `requirements.toml`，封死裸奔档、定好安全底线
- [ ] Analytics 与 Compliance API key 配好，知道日志去哪导、留多久
- [ ] access token 都设了有限期、有轮换计划
- [ ] 定好成本复盘节奏和「成功长什么样」

---

写到这儿，**整个 Codex 篇就到终点了。**

回头看这一路：咱们从第 01 篇「Codex 到底是个啥」起步，装好环境、跑通第一个任务；一路认识了 CLI、桌面 App、IDE、云端这几张面孔，搞懂了 `AGENTS.md`、`config.toml`、权限沙箱、MCP、子代理、Skill、Hook 这些零件；学会了怎么选模型、怎么提速、怎么把它接进 Git、Slack、CI；最后用术语表和这篇企业治理收了尾。**38 篇正文 + 1 篇选读，你已经从「听说过 Codex」走到了「能把它稳稳用进真实工作流」。**

先恭喜你读到这儿——**能把一整套工具教程啃完的人，本来就不多。**

但说句实话，**这些字看完，顶多算「知道」，离「会用」还差一步，那一步只能靠你自己跑。** 我的建议很简单：别再囤教程了。现在就打开终端，挑一个你手头真实的小活——修个 bug、写个脚本、重构一段烂代码——交给 Codex 跑一遍。会卡壳、会有不如意，但**你第一次亲手让它帮你解决一个真问题的那个瞬间，比读十篇教程都顶用**。

工具是死的，你拿它干成的事才是活的。去实战吧，兄弟。
