如何在 Agent.Space 使用 Codex：Workspace 实操指南

在 Agent.Space 使用 Codex，指的是让 Codex 这个 Agent harness 在持久化云端 Workspace 中运行。Codex 仍然负责组织编程工作循环，包括检查文件、修改内容、运行开发工具和验证结果；Workspace 则把项目文件、Session、受支持的 Preview 与明确留下的交接材料放在一起。

实际开始时只需一条短路径：创建或打开 Workspace，只加入任务需要的文件，选择 Codex 和兼容模型，定义一个结果可观察的任务，再根据保存下来的证据完成审查。Codex Agent 页面是了解当前产品可用性与相关文章的 Hub。

这条路径不会替代 OpenAI 原生 Codex 的每一种入口。它适合需要长期保存项目状态和进行交接的工作。如果你还在判断自己需要的是普通 ChatGPT 对话，还是由 Codex 执行的编程任务，请先看 Codex 与 ChatGPT 工作方式对比。

产品事实核验于 2026-09-02。 Agent、模型、功能与套餐可用性都可能变化。请把 Agent.Space 线上选择器和 OpenAI 当前官方文档作为最终依据。

在 Agent.Space 使用 Codex 意味着什么

下面四层会一起工作，但彼此不能互换：

层级	在这套工作流中的职责
模型	提供底层推理与生成能力。
Codex harness	组织上下文、工具、权限、文件修改、命令与验证。
Session	承载一个持续进行的 Codex 任务和可见对话。
Workspace	集中保存成员、Session、项目文件、Preview 与明确的交接状态。

OpenAI 把 Codex CLI 定义为可以在终端中检查和修改代码、运行命令并自动化工作的工具。Agent.Space 则把这种执行方式放进自己的 Workspace 合同中。Workspace 不会因此变成模型，模型也不会接管文件系统和协作层的职责。

某一层变化时，这个区分尤其重要。你可以更换兼容模型，但不能想当然地认为 harness 工作方式也会变化；也可以在项目文件保持不变的情况下，为另一个受支持 Agent 新建 Session。完整的 Agent.Space 架构说明解释了为什么项目才是工作流中稳定的中心。

什么时候适合选择这条 Codex 路径

当下面任一需求推动工作时，值得评估 Agent.Space：

项目需要在多次工作之间持续保留；
多个人需要检查同一份当前文件和受支持的 Preview；
另一位团队成员或 Agent 可能继续审查或推进结果；
你希望把 Codex harness 与兼容模型分开选择；
任务更适合托管云端 Runtime，而不是只配置在一台开发者电脑上。

如果你需要的功能只存在于当前 Codex App、CLI、IDE Extension 或 Codex Cloud，OpenAI 原生入口可能更简单。OpenAI 会分别记录这些入口，因为它们的执行位置、认证与界面并不相同。如果组织必须完全掌控 Runtime 和网络边界，自行管理的本地或云端方案也可能更合适。

如果你正在评估 OpenAI 原生的本地运行方式，Codex workspace-write Sandbox 指南说明了它的文件系统、网络和批准边界。

真正有用的问题不是“哪个产品的功能清单最长”，而是“项目状态应该放在哪里、谁需要继续工作，以及具体需要哪项原生功能”。

五步启动 Codex Session

1. 为项目创建 Workspace

用预期结果而不是 Agent 名称来给 Workspace 命名。结账错误调查 即使后来加入 Claude Code 或 OpenCode 仍然清楚；Codex 测试 则没有说明团队要完成什么。

2. 加入最少但足够的上下文

提供相关仓库文件、Brief、错误输出、设计参考或验收标准，并说明哪个来源最权威。不要因为某些材料存在就全部上传，也不要把 Secret 写进 Prompt 或普通项目文件。

3. 选择 Codex

新建 Session，并把 Codex 选为 Agent harness。应检查线上产品，而不是依赖旧截图或文章里的某个版本号。

4. 单独选择兼容模型

从产品当前为 Codex 显示的模型中选择。一个模型出现在 Provider 的目录里，不代表每个 Codex 集成都支持它。线上可选组合才是实际依据。

5. 发送一个边界清楚的 Turn

第一次先选择结果可观察、能够撤销的任务，例如诊断一个可复现错误、修改一个组件、审查一份 Patch，或者增加一项定义清楚的测试。完整迁移会把太多可能的失败原因混在一起，不适合作为首次运行。

给 Codex 一个可以验证的任务

好的请求会告诉 Codex 什么结果最重要，以及怎样证明结果正确，而不是规定每一个按键动作。

text

目标修改[具体行为或产物]，使它达到[可观察结果]。
上下文- 把[文件或 Brief]作为事实依据。- 修改前先检查[相关范围]。
允许范围- 可以修改[文件或行为]。
禁止范围- 不要修改[必须保持不变的区域]。- 未经批准，不要执行外部操作或破坏性操作。
验收检查- [测试、构建、Preview 状态或内容要求]- [第二项完成条件]
完成前列出修改过的文件、已运行和未运行的检查、假设，以及最小的下一步。

目标修改[具体行为或产物]，使它达到[可观察结果]。
上下文- 把[文件或 Brief]作为事实依据。- 修改前先检查[相关范围]。
允许范围- 可以修改[文件或行为]。
禁止范围- 不要修改[必须保持不变的区域]。- 未经批准，不要执行外部操作或破坏性操作。
验收检查- [测试、构建、Preview 状态或内容要求]- [第二项完成条件]
完成前列出修改过的文件、已运行和未运行的检查、假设，以及最小的下一步。

这份合同给 harness 留出了调查空间，也保留了真人决策边界。如果工作包含主观产品或架构选择，应先让 Codex 列出证据和选项，再停下来等待真人决定，而不是直接实现。

审查结果，再继续或交接

把 Agent 的回复当成工作报告，而不是正确性的证明。按下面顺序检查项目状态：

把结果与书面验收标准逐项对照。
检查实际保存的文件，确认没有无关修改。
如果结果涉及视觉行为，打开受支持的 Preview 或产物。
阅读相关测试、构建、Lint 或其他验证输出。
记录哪些命令没有运行、哪些假设仍未验证。
决定接受结果、请求一次边界清楚的修改，还是恢复原状态。

如果要由另一个 Agent 继续，应在同一 Workspace 中新建独立 Session，并留下明确交接：目标、改动文件、通过和失败的检查、待决定事项，以及一个下一步。新 Session 可以检查已保存文件和主动保留的交接材料，但不会悄悄获得 Codex 的隐藏推理。

如果有用的本地上下文已经存在 Codex 对话中，可以使用专门流程导入选定的 Codex 对话。导入对话和迁移项目文件仍然是两件不同的事。

哪些仍然由 OpenAI 决定

Agent.Space 独立于 OpenAI。它不是 OpenAI 订阅、API 余额、转售服务、共享账号，也不是绕过 OpenAI 账号、支付、地区或使用规则的方式。

以下事项仍由 OpenAI 决定：

Codex 的核心行为与原生产品入口；
模型能力和 OpenAI 专属功能资格；
官方认证、订阅、API 与使用规则；
只存在于 Codex App、CLI、IDE Extension 或 Cloud 的功能；
OpenAI 账号适用的条款与数据控制。

例如，OpenAI 当前认证文档会区分通过 ChatGPT 订阅访问和通过 API Key 按量访问，而 Codex Cloud 当前要求通过 ChatGPT 登录。同一个 harness 名称出现在两个产品里，并不会把这些路径自动转换成 Agent.Space 套餐。

如果你主要想决定访问和计费路径，而不是了解 Workspace 工作流，请阅读单独的 Codex 订阅、API 与托管 Workspace 对比。

一次安全的 Codex 首次运行

扩大项目之前，先确认一个完整循环能够成立：

选择： Codex 与需要的兼容模型都出现在当前线上产品中。
范围：第一个任务小而可逆。
权限：敏感、外部和破坏性操作仍需明确审查。
证据：已保存文件和相关检查能够支持完成结论。
连续性：另一 Session 或团队成员能从可检查材料理解当前状态。

第一次运行的完成标志，是 Workspace 中留下了可以验证的结果，以及另一个人也能照着执行的下一步。只有这条路径清楚后，再扩大仓库范围、任务时长、Session 数量或协作人数。