Codex Cloud 来了：什么时候还该让 Agent 跑在自己的电脑上？

在 9 月 29 日的 DevDay 上，OpenAI 说开发者「可以在任何需要的地方运行 Codex：在电脑上、从手机远程运行，或从任何设备通过云端运行」。对团队最重要的一句话在后面：可复用开发环境「帮助任务快速启动，并让团队共享一套经过批准的设置和权限」。Codex cloud 适用于 Plus、Pro、Business、Healthcare、Education 和 Enterprise。

对一个开发者来说，这解决了一个问题。对一个已经在工作站上跑 Claude Code、在构建服务器上跑 Codex、又在某人的笔记本上跑 Gemini 的团队来说，这又多了一个地方。现在工作可能从 OpenAI 的云端开始，也可能在自有硬件上或通勤火车上的手机里开始，而每个地方都保留自己的一份运行记录。哪个 Agent 在做什么、什么完成了、什么在等审查，又多了一个要查看的位置。所以有用的问题不是「云端还是本地」，而是哪类工作该放在哪里，以及这项工作的记录最终住在哪里。

太长不看

对于需要快速启动、在笔记本休眠时继续跑、或者要从手机发起的 Codex 工作，Codex cloud 更合适；想要一套批准过的环境而不是每个人自己准备主机的团队，也更适合它。当任务需要 Claude Code 或其他非 Codex Runtime、需要超出套餐默认 VM 的硬件，或者需要 OpenAI 云环境文档目前列为不支持的能力时，自己的电脑更合适：GitLab 仓库、浏览器操作，以及通过 SSH 或数据库协议访问的私有服务。无论选哪个，都不会改变谁派活、谁验收。这些仍然留在团队的任务上。

Codex cloud 环境能给你什么

在 OpenAI 的文档里，云环境「是任务使用的可复用设置：仓库、依赖、工具和访问权限」。你选择 GitHub 仓库，Codex 检查它们、安装依赖和工具、测试工作流，并询问它无法推断的东西。你审阅设置报告并发布。之后每个新任务都从这份已发布的文件系统出发，在自己的隔离工作区里运行，而且任务「可以在你的电脑休眠时继续工作」。

访问模型比「把 Token 粘进设置脚本」谨慎得多。环境变量会直接传给程序。网络密钥根本不会到达进程：程序收到的是占位符，代理只对允许的 HTTPS 目标替换成真实凭证。互联网访问是一个先打开、再收窄的设置，可以选包管理器预设或自定义域名列表。私有服务可以通过 VPN 访问，目前支持的提供方是 Tailscale；Enterprise 工作区可以申请 OIDC 连接，获得短期云凭证。

启动工作同样灵活。Codex Cloud 概览列出网页、桌面 App、移动端和 Codex CLI；具备 Cloud 委派能力的 Enterprise 工作区还可以从 Slack 或 Microsoft Teams 里的 @ChatGPT 启动任务。Enterprise 环境可以共享给整个工作区，新同事从已批准的环境开始，而不是重新搭一遍。对 Codex 工作来说，这消除了一处真实的设置漂移来源。

OpenAI 自己的产品线也把「放在哪里运行」当成按工作负载决定的问题，而不是只有一个答案。Dots 各自获得自己的云电脑，Agents API 既接受 OpenAI 托管环境，也接受自托管环境。Codex 现在也两边都能跑。

自己的电脑能提供什么

电脑是一台已连接的设备、服务器或容器，Agent 可以在其中运行工作。用 HiFox 的电脑文档的话说，它「提供 Agent 所需的操作系统、文件、凭证、网络访问和工具」。一个很小的本地服务负责注册它、发现已经安装的 Runtime、接收排队的运行，并把进度流式传回来。这个服务从内向外建立连接，所以典型配置不需要开放入站端口。

这次对比里有三个性质很重要。第一，一台电脑可以暴露多个 Runtime。HiFox 点名了 Claude Code、Codex、Gemini、OpenCode、OpenClaw 和 Hermes；自定义 ACP Runtime 可以覆盖本地服务没有发现的工具，一台电脑也可以服务多个 Agent。第二，隔离按任务进行。在临时模式里，每个任务得到独立目录；有仓库的运行可以使用全新的 worktree，这就是并行 Agent 避免合并冲突的方式。在指定模式里，一次运行会复用配置好的本地目录，依赖、缓存和本地服务都已在位，一次只跑一个。第三，凭证归你所有：Agent 携带普通和秘密环境变量，每次运行只收到它被允许的环境和凭证；个人可见性的电脑只对其所有者可用。

诚实的代价是，主机也归你维护。如果电脑离线，新运行就要等它重新连上。桌面 App 可以阻止休眠，在 macOS 上还可以在系统允许时合盖继续运行，但长时间无人值守的运行应该放在你能控制的服务器上。账单仍然在原来的地方：电脑和 Runtime 不占 HiFox 套餐席位，HiFox 不卖 Token，Codex Agent 使用它的 Codex CLI 登录时所用的 ChatGPT 套餐或 API key。

Codex cloud 还是自己的电脑：决策表

下面每一条 Codex cloud 的能力都来自截至 9 月 30 日的 OpenAI 云环境文档，电脑侧来自 HiFox 文档。

把它当成一对决策：当任务是 Codex 工作、依赖是公开的或可通过白名单 HTTPS 访问、发起人可能不在桌前时，用 Codex cloud；当任务需要你有意选择的 Runtime、硬件或网络时，用自己的电脑。

有一行是故意没写的：「绝不能离开我们网络的数据」。在自己的电脑上运行，可以把仓库、缓存和密钥留在你控制的硬件上，但它不会让提示词远离模型提供方，因为 Runtime 发给模型的内容仍然会出去。OpenAI 对自己的产品也画了同一条线：Agents API 文档说，「选择自托管沙箱并不会让 Agents API 符合 ZDR 条件」。运行位置决定代码和凭证住在哪里，数据保留则是和模型提供方之间的另一份合同。

混合部署时，看板才真正有价值

大多数团队会两边都用。快速的 Codex 修复从手机发到云环境；需要预发数据库的迁移，则作为 Agent 跑在网络内的电脑上。这个拆分很合理，但会产出两份工作清单。

Codex cloud 按设计把任务隔开：文档说，对共享设置的访问「不会让别人获得你任务的访问权」。这是隐私上的正确默认值。它也意味着环境可以共享，工作却不能，所以「团队现在的 Agent 工作到底在做什么」，跨云端任务和电脑来问时，必须在别处回答。先把路由规则写下来：

这个任务在哪里运行？
1. 需要非 Codex Runtime                          -> 电脑上的 Agent
2. 需要 SSH、数据库协议或私有 DNS                 -> 该网络内的电脑
3. 需要 GitLab、GitHub Enterprise Server 或浏览器  -> 自己的电脑
4. Codex 工作、白名单 HTTPS、非桌前发起           -> Codex cloud
5. 必须有人验收结果                               -> 无论在哪运行，都要有负责人和审查者的任务

第五条让拆分保持可管理。在 HiFox 里，任务就是记录：进度、执行日志、阻塞和结果都回到它，等待人审的运行会进入责任人的收件箱。同一台电脑上的 Codex Agent 和 Claude Code Agent 汇报到同一块看板，各自使用 Runtime 配置的模型。对于在 Codex cloud 里跑过的工作，连接点是 pull request：把任务 ID 放进分支名或 PR 标题，HiFox 的 GitHub 集成会尝试把 PR 关联回任务，所以验收仍然在一个地方完成。长时间无人值守运行的审查侧，另有专门说明。

Agent 负责调研、执行、测试和汇报。人负责定方向、授权和验收结果。这份契约不会因为运行发生在哪里而改变。

这对你的环境意味着什么

Codex cloud 是「Codex 该在哪里运行」的好答案。它不是为回答「我们所有 Runtime 上的 Agent 分别在做什么，谁批准了」而建的。为自己的 Runtime、硬件或网络保留电脑，把手机发起、笔记本合盖的工作交给 Codex cloud，并为两边保留同一份记录。

如果你想继续使用多个编程 Agent，而不是押注一个生态，这正是 HiFox 围绕的问题。