EXECUTIVE READOUT · 2026-08-23
一句话结论：Codex 不是“会写代码的聊天框”，而是一套以任务为中心的工程执行平台
核心结构：统一任务入口连接项目上下文，任务被放入 Local、Worktree 或 Cloud 隔离环境，由编码智能体循环执行“理解—调用工具—修改—验证”，最后以摘要、日志、Diff、Pull Request 等可审查产物交还用户；Skill、沙箱、审批与网络策略横向约束整条链路。
官网将 Codex 定位为 ChatGPT 中的编程智能体，并明确强调端到端工程任务、并行工作流、工作树、云端环境、Skill、后台任务与代码审查。官方文档进一步确认桌面端、CLI、IDE 与云端是同一产品体系的不同入口。
从产品行为看，Codex 的竞争力不只来自编码模型，而来自“上下文装配 + 受控执行环境 + 工具循环 + 版本控制交付 + 人在回路治理”的组合。具体内部调度服务、模型路由、数据表与消息基础设施未公开，报告只描述功能等价能力。
一个容易误拆的点：官网所说“多智能体工作流”能够确认的是多个任务/聊天可并行运行；这不等于每个任务内部一定由多个 Agent 自动分工。后者在本次证据范围内仍是未知。
取证范围与分析边界
本报告围绕“用户如何把工程目标交给 Codex，并获得可审查代码结果”建立架构。证据来自用户指定官网的真实页面、官网可见产品演示，以及 2026-08-23 抓取的官方 OpenAI 文档。未登录 Codex 云端工作台，也未创建真实任务、连接仓库或触发任何写操作。
| 证据 | 来源 | 可见事实 | 支撑结论 |
|---|---|---|---|
| E-001 | Codex 中文官网 首屏与产品能力区 | Codex 已进入 ChatGPT；端到端任务、并行工作流、工作树、云环境、Skill、后台工作、代码审查。 | 产品定位与能力边界。 |
| E-002 | 官网首屏，ego-browser 只读截图 | 桌面工作台演示包含 Project、Codex、任务列表、项目选择、权限与模型控件。 | 任务入口和控制面是产品的一等能力。 |
| E-003 | ChatGPT desktop app | 项目并行、长时工作、文件产物、浏览器/桌面工具、定时任务集中在一个桌面工作区。 | 桌面端是跨项目控制中心。 |
| E-004 | Codex environments | 新建 Codex chat 时可选择 Local、Worktree、Cloud；前两者运行在用户电脑。 | 环境选择是任务执行前的关键路由。 |
| E-005 | Git worktrees | 多个独立 chat 可在同一项目并行，不互相干扰；支持 Local 与 Worktree 之间 Handoff。 | 本地并行与改动隔离依赖 Git worktree 语义。 |
| E-006 | Codex cloud、Cloud environments | 创建容器、检出仓库、运行 setup、应用网络策略、智能体循环执行命令、输出回答与 Diff。 | 云端 Run 的公开生命周期。 |
| E-007 | Build skills | Skill 打包说明、资源和可选脚本；选用后再完整加载 SKILL.md；可通过插件分发。 | 复用工作流与团队规范的扩展机制。 |
| E-008 | Sandbox、Approvals & security | 沙箱定义技术边界，审批策略决定何时停下来询问；本地默认限制写入范围和网络，云端为隔离容器。 | 治理层不是附属功能，而是执行前提。 |
| E-009 | Codex cloud | 任务可从 Web、GitHub、GitLab、Linear、Slack 发起；结果可查看摘要与 Diff、继续追问或开 PR。 | 入口与交付面向完整工程协作链。 |
| E-010 | 证据缺口 | 未公开任务队列、内部状态服务、模型路由算法、长期记忆实现、数据库/对象存储/日志平台选型。 | 报告中的对应层只能是能力推断或建议设计。 |
六个核心功能域：从“说一句”到“交一份可审查改动”
1. 任务与项目
对象：Project、Chat、Task。
价值：把目标、文件、仓库和历史组织在同一上下文里。
关键状态：新建、运行中、等待、可审查、归档。
2. 执行环境
对象：Local、Worktree、Cloud environment。
价值：在速度、隔离、并行与后台运行之间做选择。
关键状态：未准备、准备中、就绪、失效。
3. 智能体执行
对象：Run、Command、Check、Result。
价值：将自然语言目标转成连续的代码理解、编辑、测试和纠偏动作。
关键状态：规划、执行、验证、失败、完成。
4. 扩展与规范
对象：AGENTS.md、Skill、Plugin、MCP/Connector、脚本。
价值：让执行单元理解团队工作方式，并接入外部能力。
关键状态：发现、加载、授权、调用、失败。
5. 验证与交付
对象：Summary、Log、Diff、Pull Request、Review。
价值：把“模型说完成”变成“人能检查、继续修改或合并”的工程结果。
6. 安全与治理
对象：Sandbox、Approval、Network policy、Secret、权限。
价值：让智能体尽可能自主，同时把越界动作交还给人判断。
域之间的真正耦合点不是 Prompt，而是状态。环境是否就绪、权限是否通过、工具是否成功、检查是否通过、Diff 是否可审查，这些状态决定下一步能不能继续。
端到端五条流：一个“修复并提交”任务如何穿过系统
下面把同一任务拆成五条并行流。它回答的不是“模型说了什么”，而是谁触发、谁处理、读什么、写什么、失败时回到哪里。
用户交互流
选择项目 / 仓库
E-002
E-002
描述目标并附上下文
选择 Local / Worktree / Cloud
E-004
E-004
查看进度与审批
审查摘要、Diff、PR
控制流
创建 Chat / Run
装配项目上下文
环境与权限门
智能体循环执行
验证通过？
工具调用流
读文件 / 搜索代码
执行命令 / 编辑文件
调用 Skill / Plugin / MCP
运行测试 / Lint / Build
Git Diff / PR
数据状态流
项目与用户约束
会话上下文与指令
Run 状态 / 日志 / 审批
检查结果 / 错误
摘要与可追溯记录
代码资产流
基线仓库 / 分支
隔离 Checkout
Working Tree 改动
已验证 Diff
PR / Handoff / 合并
关键判断门
| 判断门 | 通过条件 | 失败/中断路径 | 证据等级 |
|---|---|---|---|
| 环境门 | 仓库、依赖、工具、环境变量已准备 | 回到环境配置或 setup 日志 | 已确认 E-006 |
| 权限门 | 文件范围、命令与网络在沙箱内，或用户批准越界动作 | 等待审批、降低权限或终止 | 已确认 E-008 |
| 执行门 | 工具动作返回可解释结果 | 重试、换方法、请求补充；具体策略未知 | 合理推断 |
| 完成门 | 任务目标满足，关键检查通过，Diff 与摘要可审查 | 继续修改、标记失败或取消 | 合理推断 E-006 |
| 交付门 | 用户接受结果并 Handoff、开 PR 或合并 | 追问、要求修改、归档 | 已确认 E-005 / E-009 |
产品分层架构：九层里，真正决定体验的是中间四层
| 层 | 主要组件 | 输入 / 输出 | 证据判断 |
|---|---|---|---|
| 1. 用户与渠道 | ChatGPT 桌面端、Web、CLI、IDE、Remote；GitHub/GitLab/Linear/Slack | 目标、通知、审查与继续操作 | 已确认 E-003 / E-009 |
| 2. 交互与工作台 | Project、Chat、任务列表、Composer、环境/权限/模型选择、日志与 Diff | 任务定义 ↔ 进度与结果 | 已确认 E-002 / E-006 |
| 3. 应用业务域 | 项目组织、任务管理、代码审查、定时/后台工作、通知 | 用户目标 → 可管理任务 | 已确认 E-001 / E-003 |
| 4. 编排与状态 | 环境路由、Run 生命周期、审批等待、重试、取消、跟进、Handoff | 任务状态与下一步决策 | 部分确认 E-004 / E-005 / E-008 |
| 5. 动作与工具 | 文件读写、Shell、Git、测试/构建、浏览器/桌面工具、插件、MCP | 工具参数 → 结果 / 错误 / 产物 | 已确认 E-003 / E-006 / E-007 |
| 6. AI 能力 | 编码模型、推理策略、上下文装配、工具选择 | 目标与观察 → 下一动作 | 合理推断；具体路由未知 |
| 7. 上下文与数据 | User / Project / Chat / Run / Approval / Tool result / Diff / Review | 跨步骤读写与追溯 | 合理推断 |
| 8. 知识与规范 | AGENTS.md、Skill、Plugin、团队规则、项目文档 | 可复用工作法 → 本次执行约束 | 已确认 E-007 |
| 9. 基础设施与治理 | 本地 OS 沙箱、云容器、网络代理、审批、密钥隔离、日志 | 策略 → 允许 / 拒绝 / 审批 | 已确认 E-006 / E-008 |
中间四层：应用业务域、编排状态、工具动作、上下文数据。模型升级可以让单步更聪明，但没有这四层，长任务仍会变成“说得很好，改到哪儿了不知道”。
上下文与核心实体：Codex 如何保持“我在改哪个项目、做到哪一步”
以下是功能等价语义模型，不是 OpenAI 数据库表。它把短期会话、工程环境、执行事件与最终代码资产分开，便于理解跨端同步和可追溯性。
| 语义实体 | 关键内容 | 生命周期 | 关系 | 等级 |
|---|---|---|---|---|
| User / Workspace | 身份、套餐、团队、权限、策略 | 长期 | 拥有 Project，约束 Run | 合理推断 |
| Project | 文件夹/仓库、项目说明、历史 chats | 长期 | 聚合 Chat 与环境 | 已确认 E-002 / E-003 |
| Chat / Task | 目标、用户输入、附件、跟进 | 中期 | 发起一个或多个 Run | 已确认 |
| Environment | Local / Worktree / Cloud、依赖、变量、网络策略 | 任务或可复用 | 承载 Run | 已确认 E-004 / E-006 |
| Run | 当前状态、执行步骤、日志、错误、耗时 | 单次执行 | 产生 ToolAction 与 Result | 合理推断 |
| Approval | 动作、原因、范围、决定、操作者 | 事件记录 | 控制 Run 是否继续 | 能力确认 E-008 |
| ToolAction | 命令/工具、输入、结果、错误 | 事件记录 | 修改 Working Tree 或上下文 | 合理推断 |
| ChangeSet | 文件变更、Diff、检查结果、提交/PR | 版本化 | 由 Run 产生，供 Review | 已确认 E-006 / E-009 |
| Skill / Rule | 说明、资源、脚本、触发条件 | 可复用 | 装配进任务上下文 | 已确认 E-007 |
Codex 全景架构主图
主图以公开能力为骨架：实线框与实线箭头为已确认产品能力，虚线为功能等价推断，紫色点线为建议设计。它不声称还原 OpenAI 私有后端。
已确认：页面或官方文档直接支持合理推断：实现未知但产品需要建议设计：若建设同类平台应补强
主图读法：用户从任一入口创建任务；工作台组织上下文和控制选项；编排层选择执行环境并维护状态；编码智能体在受控环境内循环调用工具；所有动作结果形成可追溯事件和代码变更；沙箱、审批、网络与密钥策略横向裁决每一次越界行为。
As-Is：当前可确认的产品架构
统一入口，多执行面
ChatGPT 桌面端、Web、CLI、IDE 与 Remote 共享 Codex 产品能力；任务还可从代码托管和协作工具进入。E-003E-009
环境是一级选择
Local 贴近现有工作区，Worktree 解决并行冲突，Cloud 解决隔离与后台长任务。E-004E-005E-006
交付以版本控制资产为中心
云任务完成后展示回答与 Diff；用户可继续追问或打开 PR。Codex 的“完成”最终需要落在代码变化和检查结果上。E-006
能力扩展与治理并列
Skill / Plugin / MCP 扩大能力边界，Sandbox / Approval / Network policy 同时收紧行为边界。扩展和约束是一对系统能力。E-007E-008
核心任务的公开状态骨架
Draft → Environment Preparing → Running ↔ Waiting for Approval
├─ tool/check failed → recover / retry / ask user / fail
├─ user interrupts → cancelled / archived
└─ validation passes → Reviewable → follow-up / handoff / pull request合理推断 状态名称是功能等价表达。官方材料确认了环境准备、运行、审批、日志、Diff、跟进、PR、取消/归档等用户可见行为，但未公开完整状态枚举。
To-Be：如果要建设同类产品，建议把“可验证完成”做成架构主线
以下不是对 Codex 现状的断言，而是基于公开产品结构给同类 AI 编程平台的建议设计。
1. 单一任务事实源
用事件账本统一 UI 进度、智能体日志、工具结果、代码 Diff 与 PR 状态，避免“聊天说完成，仓库没有结果”。
2. 显式完成契约
任务创建时记录验收条件；完成门同时检查目标、变更范围、测试与用户约束，而不是把智能体停止生成当作完成。
3. 工具动作幂等化
为网络调用、PR 创建、部署和外部写操作建立 request id、重放保护与补偿机制，重试不重复产生副作用。
4. Context Pack 可观测
展示本次 Run 读取了哪些规则、Skills、文件和历史，让用户知道“它为什么这么做”，也方便发现上下文污染。
5. 分级审批策略
审批不只按“是否越界”，还应结合资源类型、命令风险、数据敏感度、外部副作用和历史信任动态分级。
6. 结果可移植
确保 Run、Diff、测试证据与决策记录可在 Desktop、CLI、IDE、Cloud 和 Remote 之间连续接力，而不是只同步对话文本。
高价值风险：不是“AI 会不会写错”，而是错误能否被发现、限制与恢复
| 优先级 | 风险机制 | 影响 | 证据强度 | 可检测信号 | 控制点 |
|---|---|---|---|---|---|
| P0 | 外部内容中的 Prompt Injection 影响工具动作 | 泄密、恶意依赖或未授权外部写入 | 已确认风险 E-008 | 异常域名、命令拼接、数据外传 | 默认断网、域名/方法白名单、审批、敏感数据隔离 |
| P0 | “生成完成”与“工程验收完成”混淆 | 错误代码、漏测、不可合并 Diff | 合理推断 | 测试未跑、验收条件未满足、Diff 超范围 | 完成契约、强制检查、人工 Review |
| P1 | 并行 Worktree / Cloud 任务基线漂移 | 冲突、重复修改、合并返工 | 合理推断 E-005 / E-006 | 基线 SHA 变化、重叠文件、合并冲突 | 基线锁定、依赖图、变更提醒、可控 rebase |
| P1 | 上下文来源不透明或陈旧 | 执行遵循错误规则，重复犯错 | 合理推断 E-007 | Skill 版本不一致、规则冲突、引用过期 | Context manifest、版本号、来源优先级、冲突提示 |
| P1 | 审批疲劳 | 用户机械放行高风险动作，或频繁中断长任务 | 合理推断 E-008 | 同类审批高频、用户秒点允许 | 可解释风险、批量规则、最小权限、可信前缀 |
| P2 | 云环境缓存与依赖状态漂移 | 复现失败、环境只在某次任务可用 | 已确认机制 E-006 | setup/maintenance 差异、缓存命中后失败 | 锁版本、缓存失效策略、环境指纹 |
架构组件—证据追溯
| 组件 | 为什么进入主图 | 证据 | 等级 | 置信度 | 缺口 |
|---|---|---|---|---|---|
| 多端入口 | 官网与文档明确列出 Desktop / Web / CLI / IDE / Remote | E-001 / E-003 | 已确认 | 高 | 跨端同步协议未知 |
| Project / Chat / Task 工作台 | 官网演示与桌面文档直接显示 | E-002 / E-003 | 已确认 | 高 | 对象精确定义与权限模型未知 |
| 环境路由 | Local / Worktree / Cloud 是新任务选择 | E-004 | 已确认 | 高 | 自动推荐逻辑未知 |
| 任务编排与状态机 | 长任务、审批等待、重试、取消、跟进需要持久状态 | E-003 / E-006 / E-008 | 合理推断 | 中高 | 内部状态服务与事件协议未知 |
| 编码智能体循环 | 官方云生命周期明确“命令循环、编辑、检查、验证” | E-006 | 已确认行为 | 高 | 模型路由和规划算法未知 |
| Skill / Plugin / MCP | 官方文档确认可复用工作流与外部能力 | E-007 | 已确认 | 高 | 运行时发现、冲突与权限细节未完全覆盖 |
| 代码资产与 Review | 结果以 Diff、检查、PR、Handoff 交付 | E-005 / E-006 / E-009 | 已确认 | 高 | 服务端持久化与版本保留策略未知 |
| 沙箱与审批 | 官方明确为两层协同控制 | E-008 | 已确认 | 高 | 不同套餐和组织策略差异未分析 |
| 事件账本 | 用于统一任务、工具、错误与交付状态 | E-010 | 建议设计 | 中 | OpenAI 是否采用同类实现未知 |
未知与下一步验证
本报告可以确认产品结构，不能反推出私有技术栈。以下问题若没有后台、网络请求、官方白皮书或真实任务记录，不应被写成“Codex 内部就是这样”。
模型与路由
不同任务如何选择模型、推理档位、压缩策略与上下文预算；是否存在多模型回退。
内部多 Agent
单个 Run 是否自动拆给多个专业 Agent，以及它们如何分工、共享状态和合并结果。
数据与事件基础设施
任务状态、日志、Diff、审批与跨端同步使用什么数据库、队列或事件协议。
质量评测
平台如何衡量任务成功、回归风险、代码质量与用户接受率，哪些检查是系统强制。
资源计量
不同任务、模型、云容器、工具调用和后台时长如何计费与限额。
企业治理细节
组织级策略如何覆盖个人设置，审计日志、保留期、租户隔离和数据驻留的完整实现。
最小验证清单
- 登录后只读观察一个现有 Project：确认任务对象、环境选择、运行状态、审批与 Diff 的真实字段。
- 用无副作用的小仓库分别跑 Local、Worktree、Cloud，同一任务比较状态、日志、文件落点与恢复方式。
- 对一次失败测试、一次需要审批的命令、一次用户中断建立完整时序，核对本报告的状态骨架。
- 检查任务完成后，Chat 摘要、Working Tree、Diff、PR 与历史列表是否一致；不把“Agent 说完成”当作唯一证据。
用户补充位：如果你有 Codex 登录后页面、实际任务日志或团队使用流程，可以在下一轮加入为 E-011 之后的新证据，并重算“编排状态”和“完成门”两部分。