Codex 任务执行模型：从代码生成到可审查的软件工程 Agent

️Fairy️

272人浏览 · 2026-08-20 14:44:10

️Fairy️ · 2026-08-20 14:44:10 发布

2025 年 5 月，OpenAI 首次以研究预览形式发布云端 Codex。当时它已经能够在独立云环境中读取代码仓库、编写功能、修复 Bug、回答代码库问题并生成可供审查的 Pull Request。2025 年 10 月，Codex 进入正式可用阶段，同时加入 SDK、Slack 集成和企业管理能力。2026 年 2 月，Codex App 发布，把多个 Agent、并行任务、Worktree 和长期任务放进桌面工作环境；3 月扩展到 Windows。2026 年 7 月，Codex App 进一步并入新的 ChatGPT 桌面应用，Codex 继续作为其中的软件工程 Agent，并获得多仓库项目、Diff 内编辑和 Pull Request 审查等能力。OpenAI 在 2026 年 5 月披露，Codex 的每周使用人数已经超过 400 万。

这段发展过程很适合用来理解 AI Coding 产品近两年的核心变化。最早的代码助手主要围绕“生成一段代码”工作，输入通常是当前文件和光标附近的上下文，输出是一段补全结果。Codex 当前处理的基本单位已经扩展到“工程任务”。开发者可以提交“修复这个并发 Bug”“重构认证模块”“分析整个仓库的请求链路”“补齐测试并检查回归”等任务。Codex 随后读取项目上下文，在受控执行环境中调用文件、Shell 和其他工具，修改代码，运行验证，再把 Diff、总结或 Pull Request 交给开发者审查。官方当前将 Codex 覆盖到 ChatGPT、IDE、CLI 和云端环境，并提供 Worktree、Skills、MCP、自动任务和代码审查等扩展能力。

理解 Codex 的关键因此落在一个问题上：一个模型怎样从“生成文本”进入“执行软件工程任务”。 这篇文章围绕这一任务执行模型展开。

1. Local、Worktree 与 Cloud

五、并行任务

1. Worktree 隔离

六、权限模型

1. Sandbox 与 Approval

一、产品定义

1. 软件工程 Agent

Codex 可以理解为一个面向软件工程环境的 Agent。大语言模型仍然负责理解自然语言、代码语义和当前任务，并决定下一步需要获取什么信息或执行什么操作；Codex 同时为模型提供代码仓库、文件系统、Shell、Git、网络、MCP 等工程工具，并负责管理这些工具的执行环境、权限和结果展示。模型由此获得了持续行动能力。

例如开发者输入：

修复订单创建接口在重复请求下生成两条订单的问题，并补充回归测试。

普通聊天模型可以分析代码片段并给出修改建议。Codex 可以继续读取订单 Controller、Service、Repository 和数据库定义，搜索已有测试，修改相关文件，执行测试命令，根据测试结果继续调整代码，最终把实际代码变化作为 Diff 提交给开发者检查。这里包含多次模型推理和多次工具调用，因此一个任务通常会经历多个执行步骤。

“Agent”在这里表达的是一种运行方式。模型可以依据当前状态选择下一步动作，工具执行结果再次进入上下文，模型继续判断下一步，直到任务达到完成条件。软件工程环境让这个循环具有真实副作用：文件可能发生变化，测试可能真正运行，Git 工作区可能产生新的 Diff。因此产品还需要同步解决执行隔离、权限、验证和人工审查问题。

2. Codex 的组成

从 OpenAI 已公开的产品和文档可以把 Codex 的工作结构概括为五部分：模型、上下文、工具、执行环境和人工控制。这个划分用于帮助理解公开机制，并不表示 OpenAI 内部存在五个同名服务。

模型负责理解任务和代码，并持续决定后续操作。上下文来自用户指令、代码仓库、当前会话、AGENTS.md、Skills 以及被允许访问的其他信息。工具负责真正执行文件读取、编辑、Shell 命令和外部工具调用。执行环境决定代码和命令运行在哪里，可以是本地项目、Git Worktree 或云端容器。人工控制负责权限审批、Diff 检查、代码审查和最终接管。

这五部分组合之后，一个自然语言请求才能变成一个能够落地的软件工程任务。

二、任务模型

1. 从 Prompt 到工程任务

Codex 收到用户请求后，需要先建立足够的任务上下文。代码开发中的上下文远远超过用户输入的一句话。例如修改一个 Spring Boot 接口，实际实现可能分散在 Controller、Service、Repository、DTO、配置文件和测试代码中。Agent需要通过代码搜索和文件读取逐步补齐这些信息。

Codex 还提供 AGENTS.md。官方将其描述为面向 Agent 的项目指导文件，Codex 在开始工作前会读取它。团队可以在其中保存构建命令、测试方式、代码规范、目录约定和 Review 要求。它解决的是另一类上下文问题：很多工程规则长期存在，却不会自然出现在某一次用户 Prompt 中。

例如仓库中可以规定：

# 项目级规则：告诉 Codex 当前仓库采用 Maven。
Build: ./mvnw clean package

# 测试规则：修改业务代码后至少运行相关测试。
Test: ./mvnw test

# 工程约束：Controller 只处理请求转换，
# 具体业务逻辑继续放在 Service 层。
Architecture: Keep business logic out of controllers.

# 审查要求：最终交付前检查异常路径和空值处理。
Review: Check exception paths and null handling before handoff.

这些内容会成为任务上下文的一部分。开发者无需在每一个 Prompt 中反复说明同样的项目规范。

Skills 又进一步处理“可复用工作方法”。官方定义的 Skill 可以封装指令、资源和脚本，用于重复执行一类任务。例如团队可以封装“发布前检查”“数据库迁移检查”或者“前端 Playwright 验证”等工作方式。AGENTS.md 更接近仓库长期规则，Skill 更接近一个可以重复调用的任务能力。

三、执行循环

1. 模型与工具的往复执行

Codex 最值得理解的部分是 Agent Loop。OpenAI 在 Codex GA 公告中明确提到，Codex SDK 延续了 Codex CLI 所使用的 Agent 实现，其中包含 Prompt、Tool Definitions 和 Agent Loop。

可以用下面的抽象伪代码理解它。该代码用于解释公开工作机制，不代表 Codex 内部源码：

# 读取用户提交的软件工程任务。
task = receive_user_task()

# 加载仓库规则、会话信息以及当前代码环境，
# 构造模型第一次决策所需的上下文。
context = load_project_context(task)

# 任务尚未满足完成条件时持续运行。
while not task_finished(context):

    # 模型根据当前任务和已有信息决定下一步动作。
    # 动作可能是继续读取文件、搜索代码、修改文件、
    # 执行测试，也可能直接生成最终说明。
    action = model_decide_next_action(context)

    # 如果下一步需要真正操作外部环境，
    # 先进入权限和沙箱检查。
    if action.requires_tool:

        # 检查该 Tool 是否允许访问对应文件、网络
        # 或其他外部资源。
        check_permission(action)

        # 在当前 Local、Worktree 或 Cloud Environment
        # 中真正执行 Tool。
        result = execute_tool(action)

        # 将执行结果加入上下文。
        # 下一轮模型能够看到测试日志、文件内容
        # 或命令返回值并继续判断。
        context.append(result)

    else:

        # 当模型已经能够结束任务时，
        # 生成最终说明以及需要开发者审查的结果。
        finish_task(action)

这一循环解释了很多 Coding Agent 表面上看起来很“聪明”的行为。Agent 修改代码以后可以主动运行测试，因为测试命令本身就是可调用工具。测试失败以后它能够继续修改，因为失败日志重新进入了下一轮上下文。一个任务可以持续较长时间，因为模型和工具之间可以进行多轮交互。

这里也能看出 Coding Agent 和一次 LLM API 调用之间的工程差异。LLM 负责一次决策，Agent Runtime负责把多次决策和真实工具执行组织成持续任务。

四、执行环境

1. Local、Worktree 与 Cloud

模型拥有工具以后，代码究竟在哪里修改成为一个核心产品问题。Codex 当前提供本地环境、Worktree 和云端环境等不同执行位置。

Local 表示 Agent直接进入开发者当前的工作目录。这种方式适合开发者持续参与的任务，例如分析 Bug、修改几个文件并立即本地验证。Agent 的操作与开发者正在使用的代码环境高度接近，因此反馈速度快。

Worktree 基于 Git 原生 Worktree 机制创建仓库的第二个 Checkout。不同 Agent 可以获得各自独立的文件副本，同时共享同一个 Git 仓库历史。Codex 官方将其用于同一项目中的并行聊天和后台任务。Agent A 可以修复支付模块，Agent B 同时补充测试，两者的文件修改不会直接覆盖开发者当前工作目录。【Agent协同开发】

Cloud Environment 则把任务放进云端容器。官方流程包括创建容器、Checkout 指定分支或 Commit、执行 Setup Script，然后按照配置决定 Agent 的网络访问范围。它更适合需要较长执行时间或不希望占用当前本地开发环境的任务。

这三种环境体现了 Codex 很重要的产品设计：任务执行位置可以独立于聊天界面存在。用户面对的是同一个 Agent，会话背后的代码操作可以发生在本地、独立 Worktree 或云端环境中。

五、并行任务

1. Worktree 隔离

多个 Agent 同时修改一个 Git 仓库时，很容易出现文件覆盖和分支状态冲突。Codex App 从发布时就把 Worktree 作为多 Agent 并行的重要基础。每个 Agent 在独立 Checkout 中修改自己的文件，开发者当前本地工作区可以继续保持原有状态。

这里包含一个具有普遍意义的 Agent 工程原则：并行执行需要资源隔离。

如果两个 Agent 共享同一个可写文件系统，即使模型本身都做出了正确决策，也可能因为执行环境相互覆盖而产生错误。Worktree把“Agent 的逻辑并发”转化为“文件系统层面的隔离并发”。这一思想同样适用于数据分析 Agent、自动测试 Agent 和文档生成 Agent：当多个自治任务可能修改同一资源时，应先划分独立工作空间【Checkout】，再考虑并行调度。

Codex 的 Handoff 进一步允许聊天在 Local 和 Worktree 之间移动。开发者可以先让 Agent 在后台 Worktree 中执行，完成主要修改以后再把聊天和代码移动到 Local 环境，继续运行本地服务、人工修改或完成最终验证。Codex负责处理相关 Git 操作。

六、权限模型

1. Sandbox 与 Approval

Coding Agent 可以执行 Shell、修改代码和访问网络，因此“Agent 能做什么”需要由运行时明确控制。Codex 当前把 Sandbox 和 Approval 分成两个概念。Sandbox定义命令实际能够访问哪些文件和网络资源；Approval定义遇到某些操作时是否暂停并要求人工确认。

默认的 workspace-write 模式允许 Codex读取和修改当前工作区，并运行常规本地命令。访问工作区之外的文件或网络时，系统可以根据配置要求人工批准。MCP 或应用工具如果明确标记为具有破坏性副作用，也会进入审批机制。

这说明“人工控制”并不需要发生在 Agent 的每一步。运行时可以提前划定自动执行范围，让低风险动作持续运行，把高风险动作提升到人工审批。这种设计很适合迁移到企业 Agent：读取知识库可以自动进行，发送邮件、删除数据、付款或修改生产配置则进入明确的权限边界。

七、验证机制

1. 从代码生成到证据生成

Coding Agent完成文件修改以后仍然需要回答一个问题：结果是否真的正确。

Codex 可以执行测试、构建、Lint 或其他项目命令，并在结果出现错误时继续迭代。官方的前端开发案例还会通过 Playwright 打开实际页面，比较实现结果并继续调整。CLI 同样提供独立的 /review 能力，可以针对当前修改、Commit 或基准分支执行代码审查。

因此一个更完整的软件工程 Agent 任务可以表示为：

任务输入
→ 获取仓库上下文
→ 修改代码
→ 执行构建或测试
→ 读取验证结果
→ 修正实现
→ 重新验证
→ 输出 Diff 与任务总结
→ 人工审查

真正具有工程价值的地方集中在后半段。生成代码只是产生候选结果，测试日志、构建结果、页面行为和 Diff 才构成开发者能够检查的证据。

八、任务可审查性

1. 可审查的自动化

Codex 最值得迁移到其他 Agent 产品的一项设计思想可以概括为“可审查的自动化”。

Agent 可以获得较强的自主执行能力，但执行范围受到 Sandbox 和权限限制；后台任务可以在 Worktree 或云端环境中持续运行，同时避免直接污染开发者当前工作区；任务结束后，开发者看到的是具体的代码 Diff、测试结果、总结或 Pull Request，并可以继续评论、修改和接管。

这一设计形成了一个清晰的控制结构：自动化发生在限定空间内，结果通过可检查对象返回给人。开发者无需实时监督 Agent 每一次文件读取和普通命令，同时仍然保留对高风险行为和最终代码的控制权。

这个思路可以直接迁移到大量非 Coding Agent。数据库 Agent 可以在只读副本中先生成查询结果，再让人工批准写操作；科研 Agent 可以在独立工作区完成数据处理，再提供可复查的数据、代码和日志；办公 Agent 可以先生成邮件或合同草稿，再由人工确认发送。Agent 自动化程度越高，结果可审查性和执行边界越需要成为产品本身的一部分。

九、产品边界

Codex 的任务质量仍然依赖任务描述、仓库结构、测试覆盖率和可访问的工程上下文。AGENTS.md、Skills 和明确的测试命令能够增加稳定上下文，但无法自动弥补缺失的业务规则。Sandbox 能限制可访问资源，也无法判断一个业务操作在组织层面是否合理。测试可以验证已有断言，测试覆盖范围之外的业务行为仍然需要人工评估。

多 Agent 并行同样存在合并问题。Worktree解决不同 Agent 同时修改文件时的工作区隔离，最终代码仍需通过 Git 合并、测试和 Review 进入主分支。执行隔离提高了并行任务的安全性，软件工程中的最终一致性依旧依赖现有版本控制和审查机制。【以人为本】

因此，Codex 的产品结构可以归纳为一个较完整的软件工程 Agent 模型：模型负责决策，工具负责行动，上下文负责提供项目知识，执行环境负责隔离副作用，验证机制负责产生结果证据，人工审查负责最终控制。 这几个部分共同决定了 Coding Agent 能否从代码生成工具进入真实研发环境。

十、来源

Codex 产品与发展历程：

https://openai.com/index/introducing-codex/
https://openai.com/index/codex-now-generally-available/
https://openai.com/index/introducing-the-codex-app/
https://openai.com/codex/

Codex 官方开发文档：

https://developers.openai.com/codex/overview/
https://developers.openai.com/codex/agent-configuration/agents-md
https://developers.openai.com/codex/build-skills
https://developers.openai.com/codex/environments/git-worktrees
https://developers.openai.com/codex/environments/cloud-environment
https://developers.openai.com/codex/concepts/sandboxing
https://developers.openai.com/codex/agent-approvals-security
https://developers.openai.com/codex/cli