选择 Codex 的使用形态，重点不在于给功能排座次，而在于让工具匹配你的工作情境：任务出现时你人在哪里、代码在本地机器上还是已连接的仓库里，以及你习惯怎样审查改动。这四种形态——CLI、IDE 扩展、桌面应用和云端任务——背后是同一个 agent，但在运行环境、仓库访问和审查流程上各有差异。想先建立整体认识，Codex 概览是一张不错的地图，帮你确定默认的入手方式。
Codex CLI：终端优先的默认选择
CLI 是一个开源的编码 agent，直接在本地终端中、于你的仓库内运行。你描述一个任务，它会读取并编辑文件，在沙盒中执行 shell 命令，并按照你配置的模式请求批准。批准与沙盒行为因版本而异，请检查你当前的设置。
如果你本来就常驻终端，CLI 的优势最为明显：快速修复、调试中的重构、Git 相关的杂务，或通过 SSH 在远程机器上作业。审查就发生在终端里——随着操作发生，你逐个查看 diff，实时批准或拒绝。它还会读取项目级指令，因此能与你仓库的既有约定保持一致。
Codex IDE 扩展：在代码现场完成编辑与审查
IDE 扩展把 Codex 带入 VS Code 及兼容编辑器。你在侧边栏委派任务，看着建议的修改落入工作区，并逐个 diff 决定接受或拒绝——就在你自己正在编写的代码旁边。
这种形态适合 agent 出力与手动编码交替进行的功能开发——编辑器、调试器和插件都保持原样，只是把成块的实施工作外包出去。它的审查流程是最有说服力的理由：修改出现在你本来就会动手的位置，评估它们本就是你日常编辑循环的一部分。
Codex 应用：桌面端的大本营
Codex 应用是一个独立的桌面程序，给 agent 工作一个图形化的大本营。视版本和平台支持而定，它可以并排运行和监控多个本地 agent 会话，并在支持的情况下接入云端任务，让一个窗口同时容纳本地会话与委派出去的工作。
如果你经常同时推进多项任务，希望无需切换终端标签页就能看到它们的状态、diff 和动态，就选应用。平台与功能细节随版本而变，在把它设为主力形态之前，请先确认你的安装版本支持哪些能力。
Codex 云端：委派任务，回头验收
云端任务在为已连接仓库准备好的隔离环境中运行。你指派一个范围清晰的任务，agent 在托管环境中完成工作，改动随后回到你面前等待审查——通常以 diff 或 Pull Request 的形式呈现（取决于你的配置）。多个任务可以并行运行。
这是异步、自成一体工作的主场：依赖升级、补测试覆盖、代码迁移，或在你专注本地工作时并行推进的第二项任务。环境是托管的，你不需要预先配置开发机——但相应地也用不上本地工具链，所以结果同样需要认真验证，与对待任何一次贡献无异。
场景对照表：为任务匹配形态
| 场景 | 优先选择 | 为什么合适 |
|---|---|---|
| 在 shell 中调试时的快速修复或重构 | CLI | 直接在你的本地仓库和现有工具链内工作 |
| 与自己的编辑并行的多文件功能开发 | IDE 扩展 | diff 与审批就发生在代码所在之处 |
| 本机上多项任务同时运行 | 应用 | 一个窗口监控所有并行的本地会话 |
| 不想全程盯着的、范围明确的杂务 | 云端 | 在隔离环境中运行，返回可审查的 diff |
| 尚未配置开发环境的机器 | 云端 | 无需本地仓库或工具链 |
| 亲手审查一个进行中的分支 | CLI 或 IDE 扩展 | 你需要本地检出、测试和人工判断 |
三个决策标准贯穿每一行。第一，上下文在哪里——你的机器，还是已连接的仓库？第二，任务需要你的环境和实时判断，还是可以无人值守地运行？第三，你要的是顺序专注，还是并行吞吐？
一套可复用的切换流程
各形态是互补而非对手，任务可以在它们之间流转。参考这份清单：
- 把任务简报写成文字：目标、涉及的文件和完成标准——不依附于任何形态。
- 将仓库约定记录在 AGENTS.md 文件里，让每个形态收到相同的指令。
- 在专用分支上工作，启动 agent 前先 commit 或 stash，让产出的 diff 可以明确归因。
- 移动任务时复用写好的简报，而不是凭记忆改述。
- 所有改动经由同一条审查路径落地：阅读 diff、运行测试，然后合并或丢弃。
可复现的例子：修复一个不稳定的测试——先用 IDE 扩展在本地起草修复，推送分支，再把更大范围的清理工作交给云端，与此同时你继续审查第一处改动。两者最终都会以可审查改动的形式，汇入同一条分支历史。
边界、验证与恢复
以上描述的是各形态的设计意图；具体功能、设置和行为可能因产品、账户类型、管理员策略、模型、地区和最新文档而异。如果本文与你的实际体验有出入，请把它当作查阅官方来源的信号，而不是你工作流程出了问题。
云端任务以仓库的已连接状态为准，因此未推送的本地工作对它们不可见——先推送。本地形态则继承你机器的真实状况：缺失的依赖、版本漂移和权限上的小脾气，都会左右 agent 能做什么。任务的类型同样关键：探索性、交互式的工作适合本地形态，而耗时长、自成一体的杂务适合云端。
用同一套方法验证每一处改动：亲自阅读 diff、运行测试套件，让 CI 做最终裁决。agent 的自信不等于测试结果。恢复是 Git 的本职——分支、commit 和 revert 能把任何一次糟糕运行的损害圈定在有限范围内。任务一旦跑偏，就停下、重置分支，再用更明确的完成标准重新下达指令。丢弃一个云端 Pull Request 不需要付出任何代价。
安全与隐私边界
本地形态可以在其配置的范围内读取文件、执行命令；沙盒与审批设置控制着这个范围，名称和默认值因版本而异。云端任务在隔离环境中运行，但在向它委派涉及已连接仓库的工作之前，先想想仓库里有什么。
不要把密钥写进提示词、项目文件或 agent 指令；环境自带密钥管理的地方，优先用它。管理员与组织策略可能限制可用功能或数据处理方式，因此你在本地看到的，可能与同事看到的不同。拿不准的时候，以该形态的官方文档为准——不是记忆，也不是这篇文章。
常见问题
同一个仓库可以使用多个形态吗？
可以。本地形态共享你的本地克隆，云端则面向已连接的仓库工作。把共享约定写进 AGENTS.md 有助于各形态保持一致的表现，不过功能重叠程度因形态和版本而异。
应该从哪个形态入手？
匹配你的工作情境。终端优先的开发者试试 CLI，以编辑器为中心的开发者选 IDE 扩展，需要并行处理多项任务的人用应用，有异步、范围明确工作的人交给云端任务。
四种形态的行为完全一样吗？
不一样。它们在运行环境、仓库访问和审查流程上各有差异，部分功能还会因账户或策略而不同。但验证习惯——阅读 diff、运行测试——在任何地方都应该一致。
如何让 agent 的改动始终可恢复？
在分支上工作，审慎设置审批与沙盒选项，应用前审查每一处 diff，合并前运行测试。回退 commit 或关闭 Pull Request 永远是最后一道保险。