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

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

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

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

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

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

看完这一篇，你会拿到：

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

⚠️ 下文凡涉及具体页面、命令、配置项、默认行为，都以 Codex 企业文档 为准；模型名、套餐、各项能力的可用范围会随版本和你的具体合同变动，看到时一律以你自己工作区后台实际显示的为准，本篇不写死。企业治理能力大多绑定 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。

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

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"），让数据处理留在指定区域。具体支持哪些区域、怎么生效，以你的合同和官方企业配置文档 为准。

这里有个细节我得替你点破，不然容易误判：审计日志和「代码留存」是两码事。 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 策略页 写好，绑定到某个用户组，用户用 ChatGPT 登录后，本地三件套自动拉取生效，根本不用先往每台电脑塞文件。

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

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

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

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

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

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

[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 仪表盘 就够了——能按 CLI / IDE / 云端 / Code Review 等不同产品面拆开看活跃用户、用量、token 消耗，还能导出 CSV / JSON。注意官方提示：用量数据可能有最长 12 小时的延迟，别拿它当实时监控用。

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

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

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

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 跑一遍。会卡壳、会有不如意，但你第一次亲手让它帮你解决一个真问题的那个瞬间，比读十篇教程都顶用。

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