国内团队如何落地 Codex：网络、数据与研发流程指南

团队落地 Codex 不是给每台电脑装一个客户端就结束了。国内研发环境通常同时存在公司网络出口、私有代码、客户数据、软件供应链和审批制度。真正需要设计的是一条可审计的工作路径：什么代码可以发送、通过什么出口发送、Codex 可以执行什么、结果由谁验证。

本文适合研发负责人、平台工程师和安全负责人共同评估。它不是法律意见，也不替代 OpenAI 当前服务条款、组织合同和所在地法规。

IMPORTANT

本文于 2026 年 7 月 27 日校对。命令与配置示例已用当前本机 CLI 帮助核对；套餐能力、数据政策和可用地区应在采购或上线时重新查阅官方资料与合同。

一、先定义试点，而不是先全员安装

一个可控的首轮试点可以这样限定：

项目	建议起点
人员	3 至 8 名熟悉 Git、测试和代码审查的开发者
仓库	内部工具、示例项目或低敏业务模块
任务	单元测试、文档、静态分析修复、小范围重构
时间	2 至 4 周
权限	工作区写入、按需审批、默认禁止生产访问
成功指标	交付周期、一次通过率、回退次数、人工审查耗时、安全事件

首轮不要选择生产数据库迁移、认证核心、支付、密钥管理或含有大量客户数据的仓库。试点目标是验证流程和边界，不是证明工具可以替代完整研发团队。

二、把四个决策拆开

1. 产品与账号

确认团队账号、所在地区、采购方式和所需功能符合 OpenAI 当前可用范围。ChatGPT 套餐、API 平台和组织工作区是不同的权限与计费边界，不要只凭个人账号的使用经验推断企业能力。

2. 网络路径

明确客户端会访问哪些官方域名，是否经过公司代理、TLS 检查、域名 allowlist 或隔离开发环境。网络团队应记录允许范围和负责人，而不是给开发机开放不受限制的出口。

3. 数据路径

列出可能进入模型上下文的数据：提示词、源代码、终端输出、测试数据、截图、日志、MCP 或连接器返回内容。数据评估不能只看“是否上传整个仓库”，因为一段堆栈或配置文件也可能包含密钥和个人信息。

4. 执行权限

Codex 不只生成文本，还可能修改文件、运行测试、安装依赖或调用外部工具。沙箱限制“技术上能触碰什么”，审批策略决定“何时必须停下来确认”，两者都需要团队基线。

三、官方直连、组织网关和第三方中转怎么选

路径	优点	主要风险	适用前提
官方服务	产品兼容性与责任边界最清楚	需要满足官方可用地区、账号和网络条件	组织已完成采购与合规确认
组织自管网关	可做出口控制、审计、限流和密钥托管	需要持续维护协议兼容性，网关日志本身也含敏感数据	有平台与安全团队负责运营
第三方中转	接入看似简单	数据去向、模型真实性、密钥托管、稳定性和合同责任不透明	经过正式供应商、安全、法务和采购评估

不要因为某个 Base URL “能返回结果”就视为兼容。Codex 工作流可能依赖流式响应、工具调用、特定错误语义和模型能力；普通聊天接口可用，不代表完整的编码代理流程可用。

若组织评估第三方服务，至少要求：

• 明确运营主体、数据处理地点、分包商与退出机制；
• 说明提示词、代码、响应和访问日志的保留期限；
• 支持租户隔离、权限控制、密钥轮换、用量限制和审计导出；
• 书面确认不会将客户数据用于未授权训练或其他用途；
• 提供可验证的模型与接口兼容说明；
• 约定安全事件通知、数据删除和服务终止后的迁移方案。

四、建立代码与数据分级

可以先用四级模型建立清晰的默认规则：

等级	示例	Codex 使用建议
L0 公开	开源仓库、公开文档、公开测试数据	可按正常研发流程使用
L1 内部	一般内部工具、无客户数据的业务代码	仅限批准的组织账号和网络路径
L2 机密	未发布产品、核心算法、商业合同、内部漏洞	默认禁止，例外需数据所有者与安全审批
L3 严格受限	密钥、生产凭据、个人敏感信息、受监管数据	不得进入提示词、日志、截图或工具上下文

分级要落实到仓库、目录和数据源，而不是只写在制度文档里。例如测试夹具必须脱敏，生产日志不得直接粘贴，.env、证书、密钥目录和导出的客户数据应通过权限与扫描工具共同保护。

五、统一凭据和本机配置

凭据原则

• 每位用户或自动化任务使用可追踪的独立身份；
• 禁止共享个人 API Key 和把 Key 写入仓库；
• 使用组织批准的密钥管理系统注入短期或可轮换凭据；
• 设置预算、速率限制、异常用量告警和离职回收流程；
• 公开 Issue、CI 日志和诊断包发布前自动或人工脱敏。

推荐的 CLI 安全起点

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

对应的临时启动命令是：

codex --sandbox workspace-write --ask-for-approval on-request

陌生仓库和只读审查使用：

codex --sandbox read-only --ask-for-approval on-request

danger-full-access 和绕过审批的选项不应成为团队默认。确需使用时，应放在有额外隔离、无生产凭据、可销毁且有审计的环境中。

六、用 AGENTS.md 固化仓库规则

全局安全策略应由组织配置和管理制度执行；仓库自己的构建、测试与修改边界适合写入 AGENTS.md：

# Repository guidance

## Data boundary
- Do not read or modify `.env`, certificate, or production export files.
- Use only fixtures under `tests/fixtures/sanitized/`.
- Do not paste source code or logs into external websites.

## Commands
- Install: `pnpm install --frozen-lockfile`
- Lint: `pnpm lint`
- Test: `pnpm test`
- Build: `pnpm build`

## Change rules
- Keep public API and database schema backward compatible.
- Do not add dependencies or change CI without approval.
- Never run deployment, migration, or production commands.

## Verification
- Run targeted tests after each behavior change.
- Before handoff, run lint, test, and build.
- Report failures, skipped checks, and unverified behavior.

AGENTS.md 不是密钥存储，也不能替代系统级访问控制。高风险命令应通过 CI 权限、云平台 IAM、数据库账号和人工审批真正限制，而不是只依赖提示词中的“请不要”。

七、设计一条可审查的研发流程

推荐把任务分成六个检查点：

选题与数据分级 -> 只读调查 -> 人工确认范围 -> 小步实现
-> 自动验证 -> 人工审查与合并

1. 只读调查

先不要修改文件。阅读相关入口、测试和 AGENTS.md，说明当前行为、最小修改范围、风险和验证命令。不要读取 .env、生产日志或客户数据。

2. 人工确认计划

开发者核对文件范围、公开接口、依赖和数据边界。涉及新外部服务、数据库结构、权限或生产环境时，任务必须停下来走现有审批流程。

3. 小步实现

每次只改变一个可观察行为，并运行最相关的测试。不要把依赖升级、全仓格式化和业务功能混在同一个 diff 中。

4. 自动验证

至少运行仓库约定的 lint、类型检查、测试和构建。安全扫描、许可证检查、密钥扫描和制品签名继续由现有 CI 执行，不能因为代码由 Codex 生成而跳过。

5. 独立人工审查

代码所有者仍需理解最终 diff。高风险模块可以增加独立审查上下文，但 Codex 自审不能代替责任人批准。

八、MCP、浏览器和外部工具要单独审批

接入 MCP、浏览器、工单系统或云平台后，Codex 的数据与执行边界会扩大。每个工具都应建立清单：

• 所有者、版本和软件来源；
• 可读取的数据范围；
• 可执行的写操作和破坏性操作；
• 认证方式、凭据存储和轮换周期；
• 网络目标和日志保留；
• 最小权限、审批点和紧急停用方法。

只读工具也可能泄露敏感数据；能创建 Issue、发送消息、改云资源或操作数据库的工具更需要细粒度权限和明确的人类确认。

九、自动化与 CI 从只读开始

codex exec 适合生成变更摘要、分析失败测试或执行结构化只读检查：

codex exec --sandbox read-only "审查当前 diff，优先报告正确性、安全和兼容性问题"

正式接入 CI 前确认：

• 身份和 Key 仅对当前任务可用，日志不会输出凭据；
• 运行器没有生产环境访问权；
• 输出不会被未经检查地自动合并或部署；
• 失败、超时和额度耗尽时安全停止；
• 模型、客户端和提示词版本可追踪；
• 成本与调用次数有上限和告警。

先运行一段时间的只读建议模式，再考虑自动提交代码；不要把“能自动修改”直接等同于“可以无人值守合并”。

十、试点复盘看什么

仅统计生成代码行数会鼓励错误行为。更有意义的指标包括：

• 从任务开始到通过审查的周期变化；
• 首次提交通过测试和代码审查的比例；
• 每个任务的人工纠偏次数和回退次数；
• 新增缺陷、遗漏测试和安全告警数量；
• API 或套餐成本，以及异常用量；
• 哪类任务收益明显，哪类任务风险过高；
• 开发者是否能解释并维护最终代码。

试点结束后形成允许任务、禁止任务、推荐提示模板和故障升级路径，再决定是否扩大范围。

十一、上线前检查清单

• [ ] 账号、采购、地区与合同边界已确认；
• [ ] 官方或供应商的数据处理条款已完成评估；
• [ ] 网络域名、代理、日志和责任人有记录；
• [ ] 仓库与数据已经分级，L2/L3 默认受限；
• [ ] 身份独立、凭据可轮换、预算和异常告警已启用；
• [ ] 默认沙箱、审批和网络策略已经验证；
• [ ] AGENTS.md 与真实构建、测试命令一致；
• [ ] MCP 和外部工具逐个完成最小权限评估；
• [ ] CI 保留测试、安全、许可证和人工审查门禁；
• [ ] 有停用账号、撤销密钥、删除数据和处理安全事件的流程。

官方资料

• Codex 产品文档
• Agent approvals & security
• Configuration Reference
• AGENTS.md 自定义指令中文译文
• Codex 命令、配置与安全参考
• OpenAI Codex 官方仓库

最后校对：2026 年 7 月 27 日