这是我的第 189 篇原创文章

作者｜柏导 

OpenAI 在 2026 年 2 月 2 日正式介绍并上线的 Codex macOS 桌面应用文档与产品页面，它的定位是一个用来管理与编排多个编码代理（agents）的“指挥台”。同一天，OpenAI 在公开博文与媒体沟通中把核心问题定义成：模型能力已经能做更长、更复杂的端到端任务，新的瓶颈变成了人如何在跨项目、跨线程、跨天的尺度上指挥、监督、复盘并复用这些代理的工作，而现有 IDE 或纯终端交互并不天然适配这种“多代理并行+长时协作”的工作方式。

从功能形态看，Codex app 的基本组织单元是 thread（线程/会话）与 project（项目），你可以同时让多个线程运行、暂停、继续，把不同任务分发给不同代理，并在一个统一界面里切换上下文。官方描述里强调“多个 agents 在独立 threads 里按 project 组织”，以及你可以在每个 thread 内审阅改动、在 diff 上评论、必要时把改动打开到你的编辑器里手工调整，这些都指向一个明确的设计取舍：围绕“并行监督”“长期追踪”“跨项目分派”来设计 UI。

要理解 Codex app 的差异点，必须先把它与“传统 IDE 插件”区分开来：thread 的运行不等于只生成一段代码回复，而是一个循环过程，模型会在过程中触发文件读取、文件编辑、工具调用、命令执行等动作，直到任务完成或你终止。Codex 文档把这种过程明确称为 agent loop，并强调 thread 可以包含多轮 prompt（比如先实现功能，再补测试，再跑验证），你也可以在未来某个时间点恢复同一 thread 继续推进。

在执行环境上，Codex 把 thread 切分成 local 与 cloud 两类，这直接影响它能否“像 cowork 一样替你在后台干活”。文档对这两类的描述也非常清晰：local thread 在你的机器上运行，可以直接读写你本地的项目文件、运行你已有的命令与工具链；cloud thread 则运行在隔离的云端环境里，Codex 会克隆你的仓库并检出它正在工作的分支，适合你想并行跑多个任务、或者从别的设备委派任务时使用。文档也给出一个现实约束：要在 cloud thread 里对你的 repo 工作，通常需要先把代码推到 GitHub；同时它也提到可以从本机“delegate”包含当前工作状态的任务到云端。

Codex app 的“多代理并行”之所以可用，很大一部分靠的是对 Git 工作流的深度绑定。OpenAI 在产品博文里把 worktrees 作为关键能力单独强调：多个代理可以在同一个 repo 上各自工作而不冲突，每个代理在隔离的副本上探索不同路径，你可以把某个代理的改动检出到本地，也可以让它继续推进而不触碰你的本地 git state。这种设计本质上是在把“并行试错”的成本从人脑的上下文切换转移到版本控制与文件系统隔离上，降低了你同时管理多个实验分支的摩擦。

围绕“监督与复盘”，Codex app 还把 review 体验做成产品主路径，而不是事后补丁。官方强调你可以在 thread 内直接 review agent 的改动、在 diff 上评论并继续迭代，这与传统“生成 patch→自己开 IDE 看 diff→再回到聊天让它改”的割裂流程不同。它的隐含战略意图是把代理从“建议者”推向“可被 code review 管理的执行者”，把代理产出的变更纳入团队已熟悉的审查范式。

Codex app 的安全模型值得单独展开，因为这决定了它能否扩展到类似 Cowork 的“知识工作执行”。Codex 文档把安全控制拆成两层：sandbox mode 决定代理在技术上能触达什么（能写哪些路径、能否访问网络等），approval policy 决定代理在什么时候必须停下来征求你的同意（比如离开沙箱、访问网络、执行不在可信集合里的命令等）。默认情况下，代理的网络访问是关闭的；本地运行时采用 OS 级别强制的沙箱来限制它通常只能触达当前 workspace，同时再叠加 approval policy 来管理“何时必须问你”。

更关键的是 Codex 对“提示注入（prompt injection）”的工程化应对。Codex 安全文档明确提到它默认使用 cached web search：返回的是 OpenAI 维护的预索引结果，而不是直接抓取实时网页，从而降低把任意不可信页面内容直接引入上下文的概率；同时它也提醒即便是缓存结果也应视为不可信内容。只有在你打开更高权限（例如 full access / yolo 等）或显式允许 live 搜索时，才会更接近“实时抓取”。这是一种非常清晰的安全折中：牺牲一部分即时性，换取对内容投毒与注入攻击面的压缩。

从 OS 层隔离细节看，Codex 在不同平台采用不同机制：文档写到 macOS 使用 Seatbelt 策略并通过 sandbox-exec 运行命令；Linux 结合 Landlock 与 seccomp；Windows 则在 WSL 下复用 Linux 沙箱语义，同时原生 Windows 沙箱仍处于实验状态且有明显限制。它意味着 OpenAI 这套栈的隔离并不依赖完整虚拟机，也能做到相当强的约束，但跨平台一致性与强度会因 OS 能力而不同。

Codex 的默认推荐策略也体现了“把安全当成产品体验”的思路：它会检测文件夹是否处于版本控制之下，并据此建议更合适的默认权限组合；在非版本控制目录下倾向于让你从 read-only 开始，避免在“不可回滚”的环境里直接放开自动写入与执行。它还强调你可以用 /permissions 切换到 read-only，仅做聊天与规划；你也可以显式设置不同 sandbox 与 approval policy 的组合，甚至把 approval prompts 关闭，但文档明确把全开放模式标注为危险并不推荐。

Codex app 在“工程化可治理”方面还有一个企业导向的点：它支持通过 OpenTelemetry 进行可选的监控与审计，默认关闭，需要显式启用；启用后会产生结构化事件，涵盖对话、API 请求、流式响应、用户 prompt（默认可做脱敏）、工具审批决策、工具结果等。这个能力的存在，说明 Codex app 并不是只面向个人开发者的玩具，而是在为团队引入“代理执行”这种新型生产力时预留了治理与合规的接口。

再往上看扩展能力，Codex app 的核心卖点之一是 skills。OpenAI 在产品博文里把它描述为 Codex 从“写代码的 agent”走向“用代码在你电脑上把事做完的 agent”的关键机制，并明确说 skills 可以把 instructions、resources、scripts 打包起来，让 Codex 更稳定地连接工具、执行工作流、遵循团队偏好。技能可以在 app 里创建和管理，你可以显式要求 Codex 调用某个技能，也可以让它根据任务自动选择。更重要的是，技能不是只在 app 内生效：OpenAI 写到当你在 app 里创建新技能后，Codex 能在 app、CLI、IDE extension 等多处复用，并且你可以把技能“check in”到仓库里，让整个团队共享。这些设计点几乎就是在为“企业版 Cowork：把组织工作流打包成可复用的代理能力”铺路。

OpenAI 还在同一篇博文里给了技能库的方向性样例：从把 Figma 设计稿转成 UI 代码、在 Linear 里做项目管理，到部署到 Cloudflare/Netlify/Render/Vercel，再到生成与编辑图片、引用最新 OpenAI API 文档、以及创建/编辑 PDF、表格、docx 等“非代码”文件。这一点与 Cowork 的定位发生了直接交集：OpenAI 显然不想把 Codex 锁死在代码层面，而是希望借助技能把“知识工作交付物”也纳入代理可执行的范畴。

在自动化层面，Codex app 提供 Automations。OpenAI 的描述是：Automations 把指令与可选技能组合起来，按你定义的时间表在后台运行；完成后结果进入 review queue，方便你再接管继续迭代。OpenAI 还披露他们内部已用 Automations 处理诸如每日 issue triage、汇总 CI 失败、生成每日 release brief、检查 bug 等“重复但重要”的工程运营任务，并且在路线图里明确提到未来会引入云端触发器，让 Codex 能持续在后台运行，而不是依赖你的电脑开着。这些都是把代理从“交互式助手”推向“持续运维的数字同事”的关键步骤。

除了 skills 与 automations，Codex app 还通过账户与配置的跨端一致性来降低迁移成本。OpenAI 明确写到 app 会继承你在 Codex CLI 与 IDE extension 里的 session history 与配置，让你可以把它当成一个新的交互入口，而不是重新开始的一套系统。对企业来说，这意味着更容易做统一的安全与行为约束；对个人来说，这意味着“同一个 agent 在不同表面上连续工作”的体验更接近真实同事，而不是一次性对话。

关于可用性与商业化，OpenAI 写到 Codex app 当天起在 macOS 上可用，并把 Codex 纳入 ChatGPT Plus/Pro/Business/Enterprise/Edu 订阅中，使用可包含在订阅额度内且可按需购买额外 credits；同时在有限时间内把 Codex 开放给 ChatGPT Free 与 Go，并对现有 Codex 用户在各付费档位“翻倍 rate limits”。从“产品战略”角度，这相当于一次典型的扩张动作：用更低门槛扩大安装基数，让多代理工作流尽快沉淀成习惯与组织流程，从而提高粘性与付费转换。

相较于Claude Code ，其官方定位是“住在终端里的 agentic coding tool”，核心叙事是“不是另一个聊天窗口，也不是另一个 IDE，而是到你已在工作的地方去”。它强调可以从自然语言描述直接构建功能、定位并修复 bug、理解任意代码库，并且能通过 MCP 连接外部数据源（例如 Google Drive、Figma、Slack），甚至把组织内工具链接入，让代理能读设计文档、更新 Jira、调用自研工具。它还特别强调“Unix philosophy”的可组合性，例如把日志流 pipe 给 Claude，让它在发现异常时通知某个渠道，或在 CI 里自动生成翻译并发起 PR。

从“代理循环”的工程实现角度，Claude Code 的文档把 tool 使用分成文件操作、搜索、执行、Web 搜索、代码智能等类别，并强调还有用于生成 subagents、向用户提问、编排流程的工具。它也强调可扩展层包括 skills、MCP、hooks、subagents 等，形成覆盖“端上执行—外部系统连接—自动触发”的完整栈。与此同时，Anthropic 还把 Claude Code 的能力以库的形式下放到 Claude Agent SDK，宣称 SDK 提供与 Claude Code 同源的工具、agent loop 与上下文管理，并允许在 Python/TypeScript 中编程化配置允许的工具集合。换言之，Claude Code 并不只是在卖一个 CLI，而是在卖一套可嵌入任意产品形态的 agent runtime。

安全机制上，Claude Code 与 Codex 的思路高度同构但实现细节有差异。Claude Code 文档把 sandboxing 的价值定义为“用预先定义边界替代每条 bash 命令都弹窗审批”，以解决 approval fatigue、提高 автономность；它描述沙箱通过 OS 级原语实现文件系统与网络隔离，文件系统默认可读写当前工作目录及子目录、对其他路径的修改需要显式许可，网络则通过沙箱外代理实现域名限制与新增域名请求时的提示；在 OS 层实现上，它写到 macOS 用 Seatbelt，Linux/WSL2 用 bubblewrap。Claude Code 还提供 auto-allow 与 regular permissions 两种模式，区别在于沙箱内的安全命令是否自动放行。

Codex 的安全文档同样把控制拆成“能做什么”（sandbox）与“何时问你”（approval policy），并且默认关闭网络。不同点在于 Codex 把 web search 与“命令的网络访问”区分得更细：即便不允许 spawned commands 访问网络，仍可通过 web search 工具在 cached 模式下获取预索引结果，从而让“查资料”与“联网执行脚本/拉依赖”分离授权。这种分离对于减少 prompt injection 的爆炸半径尤其重要：很多攻击并不需要你运行有害命令，只要把有害指令塞进上下文诱导 agent 自己去做“看似合理但越权”的动作即可。Codex 通过把 live 内容引入与实际网络执行拆开授权，理论上能让你更细粒度地控制风险。

在“减少审批弹窗”这件事上，两边也都在用工程手段对抗人类的注意力衰减。Anthropic 的工程文章宣称他们的 sandboxing 在内部使用中把权限提示减少了 84%，并把文件系统隔离与网络隔离视为对抗 prompt injection 的关键组合。Codex 的路线同样是“默认限制+可配置扩展”，并在产品博文里写到默认只允许在工作文件夹/分支内编辑、默认用 cached web search，然后对需要更高权限的动作（例如网络访问）再征求许可。两者从价值观到实现路径都很接近：真正决定差异的往往不是“有没有沙箱”，而是默认策略的保守程度、跨平台实现一致性、以及企业可治理接口是否完善。

相较于 Cowork ，其官方页面把它定义为“把 Claude Code 的执行能力带给所有人”，并明确它面向的是“knowledge work beyond coding”，入口在 Claude Desktop 的侧边栏，与 Chat 与 Code 并列；它举的例子是整理下载目录、把截图/票据变成电子表格、从散落笔记里生成报告与汇总文档、做市场分析并产出 PPT/Excel 等。它把关键承诺写成三段：你描述目标并授权访问；Claude 自己拆步骤并执行；在关键动作前让你审批并可随时重定向。

Cowork 的帮助中心把它称为 research preview，并强调由于“agentic nature + internet access”存在独特风险，建议避免给它接触含敏感信息的本地文件，限制浏览器与网络访问到可信域名，警惕 prompt injection，并只使用可信 MCP 扩展；同时它也披露自身的安全措施包括通过强化学习训练模型拒绝恶意指令、对进入上下文的不可信内容做分类扫描以识别潜在注入，但仍强调攻击概率非零且用户对代理代表自己执行的所有行为承担责任。

更能体现 Cowork 现阶段产品取舍的，是它对运行与合规的描述。Cowork 页面写到它在你的电脑上以隔离的虚拟机（VM）本地运行，你只能让它访问你明确授权的文件夹与连接器，并且通过 allowlist 控制网络访问；同时对于 Team 与 Enterprise 用户，它明确说对话历史存储在本地设备上而不是 Anthropic 服务器，企业的 audit logs、compliance API、data exports 目前不会捕获 Cowork 活动，管理员可以选择开关，并且它不适用于 HIPAA、FedRAMP 或金融服务等受监管工作负载。换言之，Cowork 当前更像一个“能力前置、合规后补”的研究预览：先把端侧可执行能力推给用户，再逐步补齐企业治理链路。

把 Codex app 与 Cowork 放在一起看，你会发现两者在“交付物谱系”上已经发生重叠但起点不同。Codex app 的起点仍然是 repo、分支、worktree、diff review 与工程自动化，它把版本控制当作可回滚、可审查、可协作的核心安全网；Cowork 的起点是文件夹、文档、表格、演示与浏览器操作，它把“工作文件夹授权 + 计划先行 + 关键动作审批”当作安全网。Codex 通过 skills 把 PDF/表格/docx 这类知识工作交付物纳入能力库，而 Cowork 则通过“执行 power behind Claude Code”把代码代理的工具链迁移到非代码任务，这意味着两条路线正在向同一件事收敛：用统一的 agent runtime 驱动跨软件的真实工作，而不只是生成文本建议。

Codex app 这类应用的宏观价值，远不止“更快写代码”。它代表一种新的软件交互范式：用户不再通过 GUI 的按钮与表单一步步操作，而是通过目标描述让 agent 规划并执行，再由人类做监督与最终验收。MCP 规范把这种范式抽象成“宿主应用—连接器—服务器”的可组合生态，允许不同领域的数据与工具以标准方式暴露给 agent；而 Codex app 与 Cowork 则是在不同人群中验证同一件事：当模型具备足够的推理与工具使用能力后，决定生产力上限的不是单次回答质量，而是“它能否在真实工具链里持续、可靠、可控地完成任务并产出可审阅的结果”。

这种应用一旦跑通，会在价值链上重塑多个环节。对个人来说，它把大量低价值但必须完成的“机械性数字劳动”外包给代理，例如资料整理、格式转换、批量更新、跨系统汇总、重复性工程运维；对团队来说，它把流程固化为可复用的技能/插件，使组织经验不再只存在于资深员工的脑中；对平台方来说，它把用户的“工作上下文”与“工具连接”沉淀在自家生态里，形成比模型本身更强的粘性，因为迁移成本不再只是换一个聊天窗口，而是要迁移一整套权限、连接器、技能库与自动化。

同时，这类应用也会把竞争焦点从“谁的模型更会写代码”推向“谁的 agent 栈更能落地”。OpenAI 自己则在博文里把挑战定义为“如何在规模上指挥与协作 agents”，并把 skills、automations、sandboxing、跨表面一致性作为答案的一部分。换句话说，模型能力的差距在缩小时，产品形态与工程系统（安全、连接、审计、可回滚、成本控制）会成为主要护城河。