正文

Codex 已经不只是一个聊天式代码助手。OpenAI 的 Codex app 文档把它描述成可以并行处理 Codex threads 的桌面工作台，并且带有 worktree、Git diff、自动化和线程级终端。2026-06-25 发布的 arXiv 研究也提到，Codex 使用正在从单次问答转向更长期、更复杂的 agentic workflow，其中一部分用户已经在每周管理三个或更多并发 Codex agent。

这件事对开发者的影响很实际：多开几个 Agent 很容易，但让它们不互相覆盖、不吃掉无关上下文、不把权限放大、不留下无法验收的 diff，才是真正的门槛。

如果你准备让 Codex 同时处理多个任务，先把流程拆成四件事：

什么时候适合多 Agent 并行

多 Agent 并行适合“互相独立、验收标准清楚、文件边界能切开”的任务。

判断标准很简单：如果两个任务的文件集合、依赖路径和验收命令能写清楚，就可以考虑并行。如果任务之间互相等待、互相改同一批文件，先不要并行。

并行不是为了让 Agent 更忙，而是为了减少人类等待时间。你要把自己放在调度和验收位置，而不是让多个 Agent 自己决定项目方向。

先把任务拆成不会抢文件的小块

多 Agent 最常见的问题不是“写不出来”，而是三个 Agent 同时改同一个文件。最后每个 diff 看起来都合理，合起来就变成冲突、重复逻辑和行为漂移。

拆任务时先写清楚四个边界：

可以按这种方式切：

不要这样切：

后一种写法会让三个 Agent 都有理由改页面、meta、样式和数据结构。任务听起来更“高级”，实际更容易互相覆盖。

Agent A：只处理 src/pages/articles 里的列表展示问题。
Agent B：只处理 content/zh/articles 的 Markdown 结构检查。
Agent C：只读 diff 和测试结果，做 review，不改文件。

Agent A：优化文章页。
Agent B：提升 SEO。
Agent C：修一下样式。

每个 Agent 只拿必要上下文

给 Agent 全仓库上下文很方便，但并行时会放大误伤。一个 Agent 不需要知道所有业务规则，也不需要读所有历史讨论。它需要的是当前任务相关文件、局部规则、验收标准和禁止事项。

给上下文时可以分三层：

OpenAI 的 AGENTS.md 文档说明，Codex 会在开始工作前读取项目指令文件，并按全局、项目、子目录的顺序合并规则。多 Agent 并行时，这个机制很有用，但不要把规则文件写成巨大的产品说明书。规则越长，Agent 越容易抓错重点。

更稳的做法是：全局规则管通用习惯，项目根目录规则管仓库约束，子目录规则管局部禁区。每个并行任务再用 prompt 补充这次任务的文件边界和验收标准。

用 worktree 隔离并行改动

同一个工作目录里开多个 Agent，最容易出现两个问题：

Codex app 的 worktree 模式就是为这种场景准备的。官方文档说明，Worktree 会创建新的 Git worktree，让改动和当前项目保持隔离，也适合在同一个项目里并排跑独立任务。

建议按任务创建独立分支或 worktree：

每个 Agent 的任务卡里写清楚：

如果一个任务必须在主工作目录处理，先停掉其它会写文件的 Agent。并行可以加速，混在同一个目录里写文件通常只会增加合并成本。

• 一个 Agent 还没完成，另一个 Agent 已经基于中间状态继续改。
• 你很难判断某个文件到底是谁改的、为什么改的。

codex/task-article-list
codex/task-content-audit
codex/task-review-only

工作模式：Worktree
分支名：codex/task-content-audit
允许修改：content/zh/articles/**/*.md
禁止修改：data/article-index.ts、package.json、nuxt.config.ts
验收命令：node scripts/generate-article-index.mjs 后检查 git diff
完成输出：变更摘要、修改文件、生成索引结果、未验证项

权限和网络不要随着并行一起放大

多 Agent 并行会让权限风险叠加。一个 Agent 装依赖，一个 Agent 跑脚本，一个 Agent 打开网络，一个 Agent 读日志；单看每一步都不夸张，合起来可能已经越过了团队原本能接受的边界。

OpenAI 的 Codex 安全文档说明，Codex 默认关闭网络访问，本地会用沙箱限制可触达范围，并通过 approval policy 决定哪些动作需要暂停确认。这个默认值很重要，不要因为“多个 Agent 要快一点”就一次性打开全部权限。

可以按任务给权限：

网络权限尤其要收窄。Codex 文档里提到，启用网络后可以用 network proxy 和域名策略约束出站目标。实际使用时，给 Agent 一个明确 allowlist，比“你需要什么就自己联网查”更可靠。

每个 Agent 必须交回验收记录

多 Agent 并行后，最大的管理成本是验收。你不能只看“完成了”三个字，也不能只看最终代码能不能跑。每个 Agent 都要交回可以复查的记录。

验收记录至少包含：

可以把完成回执固定成这种格式：

如果 Agent 没有写“失败或跳过的验证”，默认视为不完整。真实开发里，没跑的验证往往比跑过的验证更重要。

完成回执

1. 任务目标：
2. 修改文件：
3. 关键行为变化：
4. 已运行验证：
5. 失败或跳过的验证：
6. 未确认风险：
7. 建议合并顺序：

合并前先做冲突检查

多个 Agent 交回 diff 后，不要按完成时间直接合并。先做一次合并前检查。

建议顺序：

可以把 diff 分成三类：

不要让第二个 Agent 在第一个 Agent 的未验收 diff 上继续改，除非你明确告诉它这是新的基线。否则它可能把前一个 Agent 的错误当成项目事实。

• 先看每个 Agent 是否越过文件边界。
• 再看多个 diff 是否改了同一批文件。
• 然后看验收命令是否覆盖了真实入口。
• 最后按依赖顺序合并，而不是按提交时间合并。

哪些任务不要并行

不是所有任务都适合拆给多个 Agent。

这些任务先单线程：

这些任务可以用多 Agent，但角色要分开：

并行不等于大家都写代码。很多时候，最有价值的第二个 Agent 是只读 reviewer。

• 核心架构改造。
• 鉴权、支付、权限、审计日志。
• 数据库 schema 和迁移脚本。
• 跨端共享类型和协议。
• 还没确定产品行为的需求。
• 需要大量人工判断的 UI 重设计。
• 没有回滚方案的批量重命名。

可以直接复制的任务卡

给 Codex 多 Agent 并行时，可以从这张任务卡开始。

如果任务卡写不出来，说明这个任务还不适合并行。先让一个 Agent 做只读梳理，输出拆分方案，再决定开几个执行线程。

目标：
在不影响其它模块的前提下，完成 [具体任务]。

工作模式：
使用独立 worktree / 独立分支。

允许读取：
- [相关目录或文件]
- AGENTS.md
- 现有测试或文档

允许修改：
- [明确文件或目录]

禁止修改：
- package.json
- lockfile
- 数据库迁移
- 生产配置
- 与任务无关的 UI 和文案

命令权限：
- 可以运行：[命令列表]
- 需要确认：[安装依赖、联网、删除、Git 写操作、部署]

验收标准：
- [页面或功能行为]
- [测试或构建命令]
- [不能回归的旧行为]

完成时必须输出：
1. 修改文件列表
2. 关键 diff 说明
3. 已运行命令和结果
4. 失败或跳过的验证
5. 未确认风险
6. 建议合并顺序

多 Agent 工作流的最低标准

把 Codex 从聊天用法推进到多 Agent 工作流，不是多开几个窗口就结束了。最低标准是：

做到这些，多 Agent 才是在帮你缩短等待时间。做不到这些，多 Agent 只是把一次大的不确定性拆成几次更难追踪的小不确定性。

更稳的心智模型是：Codex Agent 是并行开发线程，不是自动合并机器。你可以让它们同时推进，但合并权、权限边界和最终验收必须留在人类或团队流程手里。

• 每个 Agent 有独立目标。
• 每个 Agent 有明确文件边界。
• 每个 Agent 有最小上下文。
• 每个 Agent 有受控权限。
• 每个 Agent 有验收记录。
• 合并前有人看 diff、失败日志和未验证项。

参考来源

相关文章