现在讨论 Codex vs GitHub Copilot，比较的是 OpenAI 原生 Codex 产品体系与范围更广的 GitHub Copilot 平台，而不再只是“Agent 对比代码补全”。Codex 可能出现在三条不同路径中：直接使用 OpenAI 原生产品、在 GitHub Copilot 中选择第三方 Codex Coding Agent，或在 Agent.Space 中使用受支持的 Codex Harness。它们虽然共用 Codex 名称，但账号、Workspace、Policy 控制和账单并不相同。因此，选择应该从“谁负责 Repository 工作流与用量”开始，而不是先寻找一个笼统的性能冠军。
上次核验：2026 年 9 月 11 日。 GitHub 的第三方 Coding Agent 集成目前仍处于 Public Preview。套餐、Policy、支持的 Agent、模型、计费方式和产品入口都可能变化；购买或启用前应重新检查本文引用的官方来源。
先定义这场比较到底在比什么
OpenAI 把 Codex 描述为可以在 ChatGPT、IDE Extension 和终端中使用的 Coding Agent；其原生产品还包含 Cloud Environment 和 ChatGPT 中的多 Agent 工作方式。当前产品入口应以 OpenAI Codex 官方介绍为准。
GitHub Copilot 则是一个覆盖范围更大的 GitHub 产品平台。当前 GitHub Copilot 官方介绍不仅包含 IDE 内代码建议与 Chat，也包含命令行帮助、共享上下文、Pull Request 辅助，以及由 Agent 完成研究、规划、修改代码和创建 PR 的工作流；入口覆盖 IDE、Desktop、Mobile、CLI 和 GitHub Website。
这会产生三个不同的选择：
- 使用 OpenAI 原生 Codex。 Codex 权限、原生界面、套餐用量和可选的 API 计费由 OpenAI 管理。
- 在 GitHub Copilot 中使用 Codex。 GitHub 提供 Copilot 套餐、Repository 工作流、Policy 门槛、Agent Session 入口和集成路径的用量计量。
- 在 Agent.Space 中使用 Codex。 Agent.Space 围绕受支持的 Codex Harness 提供自己的账号、套餐与云端 Workspace；它独立于 OpenAI 和 GitHub。
直接答案是：如果你主要需要 OpenAI 原生 Codex 体验，应先评估 Codex；如果 GitHub 与 IDE 工作流、Repository Policy、Code Review 和多模型/多 Agent 平台才是决策中心，应先评估 Copilot。如果付费 Copilot 套餐已经显示 Codex 第三方 Agent，且 Policy 允许使用，Codex 也可以成为 Copilot 平台中的一个 Agent——所以两者并不总是二选一。
有一个区别能避免误导：出现在 Copilot 通用 model picker（模型选择器）里的模型，不会自动成为 GitHub 第三方 Codex Agent 可选的模型。Copilot 功能、所选模型与合作 Agent 工作流是三个不同层级。
三种 Codex 路径，对应三套商业归属
不要把这三条路径理解为共用一份订阅的三个启动器。
第一条是 OpenAI 直接提供的产品路径。当前 Codex 官方定价页把 Codex 列入多个 ChatGPT 套餐，并区分 API Key 路径。要完整了解这些计费方式，可以阅读现有的 OpenAI Codex 价格指南，不要假设每个任务都有统一价格。
第二条是 GitHub 集成路径。GitHub 的第三方 Coding Agent 官方文档把 OpenAI Codex 列为受支持 Agent；启用合作 Agent 时会安装 openai code agent GitHub App，其操作会出现在 GitHub Audit Log 中。这不会把 Copilot 订阅转换成 OpenAI 原生 Codex 订阅。
第三条是独立的托管 Workspace。Agent.Space 把 Agent Harness、所选模型、项目文件和 Workspace 上下文分成不同层；它不会继承 GitHub Copilot Policy，也不会把 Agent.Space 付款转换成 GitHub 或 OpenAI 余额。
为什么 GitHub 平台会改变选择
不能继续把 GitHub Copilot 简化成代码补全。Completion 仍然是产品的一部分，但这套产品也能覆盖“输入代码”前后、以 Repository 为中心的工作。
如果团队的运营循环从 Issue 开始，以经过 Review 的 Pull Request 结束，GitHub 平台本身就会影响选择。Copilot 可以参与 IDE 和命令行工作、组织上下文、生成 PR 描述、研究与规划改动、修改代码，并提交 Pull Request 等待审核。对于组织，Business 和 Enterprise 还会把套餐与 Policy 交给中心化管理。
第三方 Agent 进一步延伸了这条 Repository 工作流。GitHub 当前允许从这些位置发起 Coding Agent 任务：
- Agents Tab；
- 分配给 Agent 的 Issue；
- Pull Request 评论中的 Agent Mention；
- GitHub Mobile；
- Visual Studio Code 中的 Session。
如果 GitHub 已经是团队的协作边界，这种路径会比较自然。管理员可以决定是否开放合作 Agent，Repository 活动继续留在 GitHub 工作流中，Agent 产出的改动也会以 Pull Request 返回。
这并不能证明 Copilot 生成的代码优于原生 Codex。它说明 GitHub 负责了任务外围更多“操作系统”式能力：Repository 入口、Policy、PR 流程、Audit Evidence 和 GitHub 侧用量控制。这是平台差异，不是模型 Benchmark 结论。
近期模型与治理变化怎样影响选择
GPT-6 Astra 已在 GitHub Copilot 正式可用，覆盖 Pro+、Max、Business 与 Enterprise 客户。GitHub 通过 Copilot 通用 model picker，在受支持的 IDE、CLI、网页、Mobile、Copilot App 与 Copilot Coding Agent 入口提供它。但这不代表 Astra 是 GitHub 第三方 OpenAI Codex Agent 提供的模型；合作 Agent 有单独的模型清单。
OpenAI 的原生 ChatGPT Work 与 Codex 说明也记录了 Astra 使用路径。访问资格取决于适用的 OpenAI 套餐，文档要求 Codex CLI v0.153.0 及以上版本和最新版 Codex Desktop App。这条路径的账号与用量归 OpenAI 管理，不会使用 Copilot Allowance。
GitHub 面向 Copilot Agent 操作的 Enterprise managed permissions已经正式可用，覆盖 Copilot App、Copilot CLI 与 VS Code Agent Host Session。管理员可以集中设置 Shell 命令、文件读取与编辑、网络域名是 block、ask 还是 allow；用户、Workspace 与已保存的批准不能削弱 managed 限制。另一项 JetBrains Copilot managed sandbox仍处于 Public Preview，为该入口增加集中管理的文件系统、网络、Proxy、工具与 macOS Keychain 边界。团队要在真正部署的 Client 上核验控制，不能假设同一 Policy 在所有入口行为完全一致。
这些变化让模型可用性与治理能力更值得纳入购买判断，但仍不能证明 Copilot Agent 的输出一定优于原生 Codex，也不能说明 GitHub 控制项与 Agent.Space Workspace 完全相同。
GitHub 的 Codex 第三方 Agent Preview 需要什么
截至核验日，GitHub 表示第三方 Coding Agent 对付费 Copilot 套餐开放，并且仍处于 Public Preview。要在 GitHub 中分配 Codex 任务，还必须先在适用的个人、组织或 Enterprise Copilot Policy 中启用它。
GitHub 当前第三方 Agent 文档列出的 OpenAI Codex Agent 选项是：Auto、GPT-5.3-Codex、GPT-5.4 与 GPT-5.4 nano。这是合作 Codex 工作流的模型清单，不是 Astra 所在的 Copilot 通用 model picker。
这项 Preview 有四个实际影响：
- 可用性受 Policy 控制。 官方文档列出 Codex，不代表每个账号或 Repository 都已经启用。
- 入口会改变控制方式。 GitHub 的 Cloud Agent Policy 管理 GitHub 托管的分配流程；VS Code 中的 Local Agent 使用另一套设置。
- GitHub 侧存在两类用量。 GitHub 说明 Coding Agent 会根据模型和 Token 使用量消耗 AI Credits，同时消耗执行所需的 GitHub Actions Minutes。
- Preview 细节可能变化。 支持的 Agent、模型、入口、限制与控制都要在发布当天重新检查。
付费前先查看实时 Copilot 套餐对比。GitHub 当前的 Billing Model 为不同套餐提供 AI Credits 用量，超出后可能进入按量计费；GitHub 也明确表示，付费套餐中的 Code Completions 与 Next Edit Suggestions 不消耗 AI Credits。因此，仅知道“Copilot 每月多少钱”还不足以估算以 Agent 为主的工作流成本。
GitHub 的模型与定价说明解释了模型选择和处理的 Token 如何影响 AI Credits。有些功能还会出现第二个计量项：例如 Copilot Code Review 可能同时消耗模型交互所需的 AI Credits，以及收集项目上下文等 Agentic 能力所需的 GitHub Actions Minutes。拥有这些资源的个人、Repository、组织或 Enterprise，未必是直接使用 OpenAI 时的账单所有者。
比较价格前，先选择运行方式
最有用的比较应该先确定你的工作必须进入哪套系统。
当 Codex 本身就是你要购买的产品时，选择 OpenAI 原生 Codex
如果你需要 ChatGPT、Codex App、IDE 或 CLI 中的 OpenAI 直接体验，并且愿意管理对应的 OpenAI 账号和用量路径，可以先从这里开始。想把 Codex 与 GitHub Copilot 的更广泛功能拆开独立评估时，这也是更干净的比较基线。
付费前确认需要的原生入口、目标 ChatGPT 套餐或 API 路径是否覆盖它，以及哪个账号拥有用量。不能因为某个入口包含一份用量，就推断它自动支付所有其他入口。
当 GitHub 负责工作流时，选择 GitHub Copilot
如果 IDE 辅助、GitHub Issues、Pull Requests、Code Review、Repository Policy 和组织计费需要放在同一个 GitHub 管理系统里，那么 Copilot 在产品层面更契合——这不等于它是性能赢家。团队已经使用 Copilot Suggestions 和 Chat 时，还可以在同一治理边界下增加异步 Agent，减少产品之间的切换。
如果你想使用的 Agent 是 Codex，购买另一套产品前先确认 Third-party Preview 是否已经启用，然后测试 GitHub 集成是否包含团队真正需要的入口、模型、权限与任务流程。“Copilot 中可以用 Codex”并不能证明它与所有 OpenAI 原生 Codex 界面完全等价。
如果真正要比较的是 GitHub 中的 Claude 路径与 Anthropic 独立 harness，而不是 Codex，请改看 Claude Code vs GitHub Copilot。
当两套产品承担不同工作时，可以组合使用
个人可能用原生 Codex 处理本地终端或 App 任务，同时由团队使用 Copilot 管理 Repository Policy 和 PR Review。如果每一笔购买都拥有不同工作，这种组合就可能合理；如果两个套餐支付的是同一类任务，且没人能说清必须使用哪份账单或平台，就会形成重复支出。
分别为每条路径写下一个代表任务，记录它从哪里开始、由谁授权、文件在哪里运行、如何审核结果，以及哪一个 Usage Meter 发生变化。这比单纯比较功能数量更能支持购买判断。
当缺少的是共享 Workspace 时，再评估 Agent.Space
当你希望 Codex 与其他受支持 Agent Harness 围绕同一套持久项目文件和上下文，在一个云端 Workspace 中工作时，Agent.Space 才进入候选。它不是 GitHub Copilot 平台，也不会取代 GitHub 的 Repository Policy、Audit System、Copilot Code Review 或组织套餐。
Agent.Space 适合哪里，哪些能力仍由 GitHub 负责
Agent.Space Codex 页面描述了当前产品边界：Codex 保留自己的 Harness 工作方式，模型单独选择，项目文件与上下文则留在 Workspace 中，方便审核或交接。
因此，以下需求可以考虑 Agent.Space：
- 把项目工作保存在持久化云端 Workspace；
- 让受支持的 Codex Harness 与其他受支持 Agent 围绕同一个项目工作；
- 保留文件与明确任务上下文，让真人或另一个 Agent 继续；
- 采用独立于 GitHub Copilot Seat 的 Agent.Space 商业路径。
GitHub 专属能力仍由 GitHub 负责。如果验收条件明确要求 Copilot 组织 Policy、GitHub Audit Evidence、自动 Copilot Code Review、Issue Assignment Flow 或 GitHub Actions 计费控制，应向 GitHub 核验和购买这些能力；不应把 Agent.Space 写成它们的替代品。
Agent.Space 的 Pricing 也要单独判断。请根据所需 Workspace 与模型路径查看当前 Agent.Space 套餐，不要像三者共用同一份用量一样，用 Agent.Space 价格直接抵扣 Copilot 或 OpenAI 账单。
付费前核对 Policy、账单与工作流
个人购买或团队启用前，可以按下面的清单核对：
- 主要工作流： 工作从 ChatGPT/Codex、IDE、GitHub Issue/PR，还是 Agent.Space Workspace 开始？
- 商业归属： 这条路径由 OpenAI、GitHub 还是 Agent.Space 管理账号与用量余额？
- Repository 归属： 哪套系统负责 Repository 权限、Branch、PR 和 Review 要求？
- Policy 门槛： 是否需要个人、组织或 Enterprise Policy 启用 Codex 或其他 Agent？
- 计量方式： 任务消耗 OpenAI 套餐/API 项目、GitHub AI Credits 与 Actions Minutes，还是 Agent.Space 套餐/余额？
- 所需入口： 目标功能是否存在于你真正使用的 App、CLI、IDE、Browser、Mobile 或 Cloud 入口？
- Preview 风险： 必要工作流是否仍处于 Preview？它的可用范围发生变化时怎么办？
- 团队证据： 已验收 Diff、Test Output、Review Discussion 与任务归属会保留在哪里？
- 重复支出： 每个付费产品是否负责不同工作，还是两个订阅正在支付同一套流程？
最终结论
现在的 Codex vs GitHub Copilot 已不是“自主 Agent 对比代码补全”。OpenAI 原生 Codex 是直接的 Codex 产品路径；GitHub Copilot 是更广的 GitHub 与 IDE 平台，也能在 Copilot Policy 和 GitHub 用量体系下，把 Codex 作为第三方 Coding Agent 提供；Agent.Space 则是第三条独立路径，把受支持的 Codex Harness 放在自己的云端 Workspace 中。
先选择工作流的所有者：使用 OpenAI 原生 Codex 产品、使用 GitHub 管理以 Repository 为中心的 Copilot 流程，或使用 Agent.Space 的独立 Workspace 与套餐。然后再核验具体入口、Policy、Preview 状态和账单。以上事实都不能证明任何一方是通用的速度、质量、安全或成本赢家。
如果持久化 Workspace 和独立 Agent.Space 路径符合你要运行的任务，可以在 Agent.Space 开始使用 Codex。