正文
Codex 已经不只是一个聊天式代码助手。OpenAI 的 Codex app 文档把它描述成可以并行处理 Codex threads 的桌面工作台，并且带有 worktree、Git diff、自动化和线程级终端。2026-06-25 发布的 arXiv 研究也提到，Codex 使用正在从单次问答转向更长期、更复杂的 agentic workflow，其中一部分用户已经在每周管理三个或更多并发 Codex agent。
这件事对开发者的影响很实际：多开几个 Agent 很容易，但让它们不互相覆盖、不吃掉无关上下文、不把权限放大、不留下无法验收的 diff，才是真正的门槛。
如果你准备让 Codex 同时处理多个任务，先把流程拆成四件事：
| 先做什么 | 目的 |
|---|---|
| 任务拆分 | 让每个 Agent 只改一块明确边界 |
| 上下文限制 | 让 Agent 只读必要文件和规则 |
| 权限限制 | 让命令、网络、凭据和 Git 写操作可控 |
| 验收记录 | 让合并前能复查 diff、命令、失败和风险 |
什么时候适合多 Agent 并行
多 Agent 并行适合“互相独立、验收标准清楚、文件边界能切开”的任务。
| 适合并行 | 不适合并行 |
|---|---|
| 一个 Agent 改前端页面，另一个补文档 | 多个 Agent 同时改同一个核心状态管理 |
| 一个 Agent 写测试，另一个修类型错误 | 需求还没定就让多个 Agent 各自猜方案 |
| 一个 Agent 查兼容性，另一个做小范围迁移 | 数据库 schema、鉴权、支付链路同时被多处改 |
| 一个 Agent 只做 review，另一个只做实现 | 没有验收命令、没有 diff 边界的探索任务 |
判断标准很简单：如果两个任务的文件集合、依赖路径和验收命令能写清楚，就可以考虑并行。如果任务之间互相等待、互相改同一批文件，先不要并行。
并行不是为了让 Agent 更忙，而是为了减少人类等待时间。你要把自己放在调度和验收位置，而不是让多个 Agent 自己决定项目方向。
先把任务拆成不会抢文件的小块
多 Agent 最常见的问题不是“写不出来”，而是三个 Agent 同时改同一个文件。最后每个 diff 看起来都合理，合起来就变成冲突、重复逻辑和行为漂移。
拆任务时先写清楚四个边界：
| 边界 | 写法 |
|---|---|
| 文件边界 | 允许改哪些目录和文件，哪些文件只读 |
| 行为边界 | 要改变什么，不改变什么旧行为 |
| 命令边界 | 可以运行哪些验证命令，哪些命令需要确认 |
| 输出边界 | 最后必须交回哪些记录 |
可以按这种方式切：
Agent A：只处理 src/pages/articles 里的列表展示问题。
Agent B：只处理 content/zh/articles 的 Markdown 结构检查。
Agent C：只读 diff 和测试结果，做 review，不改文件。不要这样切：
Agent A：优化文章页。
Agent B：提升 SEO。
Agent C：修一下样式。后一种写法会让三个 Agent 都有理由改页面、meta、样式和数据结构。任务听起来更“高级”，实际更容易互相覆盖。
每个 Agent 只拿必要上下文
给 Agent 全仓库上下文很方便，但并行时会放大误伤。一个 Agent 不需要知道所有业务规则，也不需要读所有历史讨论。它需要的是当前任务相关文件、局部规则、验收标准和禁止事项。
给上下文时可以分三层：
| 层级 | 给什么 |
|---|---|
| 项目规则 | AGENTS.md、包管理器、构建命令、代码风格、禁止事项 |
| 任务上下文 | 需求、目标文件、相关组件、已知错误、期望输出 |
| 验收上下文 | 要跑的命令、要检查的页面、不能回归的行为 |
OpenAI 的 AGENTS.md 文档说明，Codex 会在开始工作前读取项目指令文件，并按全局、项目、子目录的顺序合并规则。多 Agent 并行时，这个机制很有用，但不要把规则文件写成巨大的产品说明书。规则越长，Agent 越容易抓错重点。
更稳的做法是：全局规则管通用习惯，项目根目录规则管仓库约束，子目录规则管局部禁区。每个并行任务再用 prompt 补充这次任务的文件边界和验收标准。
用 worktree 隔离并行改动
同一个工作目录里开多个 Agent，最容易出现两个问题：
- 一个 Agent 还没完成，另一个 Agent 已经基于中间状态继续改。
- 你很难判断某个文件到底是谁改的、为什么改的。
Codex app 的 worktree 模式就是为这种场景准备的。官方文档说明，Worktree 会创建新的 Git worktree，让改动和当前项目保持隔离，也适合在同一个项目里并排跑独立任务。
建议按任务创建独立分支或 worktree：
codex/task-article-list
codex/task-content-audit
codex/task-review-only每个 Agent 的任务卡里写清楚：
工作模式：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 打开网络，一个 Agent 读日志；单看每一步都不夸张，合起来可能已经越过了团队原本能接受的边界。
OpenAI 的 Codex 安全文档说明，Codex 默认关闭网络访问，本地会用沙箱限制可触达范围，并通过 approval policy 决定哪些动作需要暂停确认。这个默认值很重要，不要因为“多个 Agent 要快一点”就一次性打开全部权限。
可以按任务给权限：
| 任务类型 | 建议权限 |
|---|---|
| 只读分析 | 读文件、看 diff，不写文件，不联网 |
| 小范围实现 | 只写指定目录，验证命令白名单 |
| 依赖升级 | 允许包管理器命令，但需要人工确认 |
| 外部 API 调试 | 只放行必要域名，不给生产凭据 |
| 安全 review | 只读 diff、日志和配置，不执行修复命令 |
网络权限尤其要收窄。Codex 文档里提到，启用网络后可以用 network proxy 和域名策略约束出站目标。实际使用时，给 Agent 一个明确 allowlist，比“你需要什么就自己联网查”更可靠。
每个 Agent 必须交回验收记录
多 Agent 并行后，最大的管理成本是验收。你不能只看“完成了”三个字，也不能只看最终代码能不能跑。每个 Agent 都要交回可以复查的记录。
验收记录至少包含：
| 记录 | 说明 |
|---|---|
| 目标 | 它被要求解决什么问题 |
| 修改范围 | 改了哪些文件，是否越界 |
| 关键 diff | 哪些行为发生变化 |
| 验证命令 | 运行了什么命令，结果是什么 |
| 失败日志 | 哪些命令失败，失败原因是什么 |
| 未验证项 | 哪些东西没跑、没确认、需要人类判断 |
| 后续风险 | 合并前还要看什么 |
可以把完成回执固定成这种格式：
完成回执
1. 任务目标：
2. 修改文件：
3. 关键行为变化：
4. 已运行验证：
5. 失败或跳过的验证：
6. 未确认风险：
7. 建议合并顺序：如果 Agent 没有写“失败或跳过的验证”，默认视为不完整。真实开发里，没跑的验证往往比跑过的验证更重要。
合并前先做冲突检查
多个 Agent 交回 diff 后，不要按完成时间直接合并。先做一次合并前检查。
建议顺序：
- 先看每个 Agent 是否越过文件边界。
- 再看多个 diff 是否改了同一批文件。
- 然后看验收命令是否覆盖了真实入口。
- 最后按依赖顺序合并，而不是按提交时间合并。
可以把 diff 分成三类：
| diff 类型 | 处理方式 |
|---|---|
| 独立 diff | 可以先合并，但仍要跑对应验证 |
| 相邻 diff | 需要手动看接口、类型、样式和文案是否一致 |
| 冲突 diff | 暂停合并，让一个 Agent 或人类重新整理方案 |
不要让第二个 Agent 在第一个 Agent 的未验收 diff 上继续改，除非你明确告诉它这是新的基线。否则它可能把前一个 Agent 的错误当成项目事实。
哪些任务不要并行
不是所有任务都适合拆给多个 Agent。
这些任务先单线程：
- 核心架构改造。
- 鉴权、支付、权限、审计日志。
- 数据库 schema 和迁移脚本。
- 跨端共享类型和协议。
- 还没确定产品行为的需求。
- 需要大量人工判断的 UI 重设计。
- 没有回滚方案的批量重命名。
这些任务可以用多 Agent，但角色要分开：
| 场景 | 分工 |
|---|---|
| 大功能实现 | 一个 Agent 实现，一个 Agent 写测试，一个 Agent review diff |
| 旧代码迁移 | 一个 Agent 改代码，一个 Agent 查旧入口，一个 Agent 做兼容性清单 |
| 内容站维护 | 一个 Agent 写正文，一个 Agent 查 frontmatter，一个 Agent 只做断链检查 |
| 安全修复 | 一个 Agent 最小修补，一个 Agent 只读验证，一个 Agent 写复盘记录 |
并行不等于大家都写代码。很多时候，最有价值的第二个 Agent 是只读 reviewer。
可以直接复制的任务卡
给 Codex 多 Agent 并行时，可以从这张任务卡开始。
目标：
在不影响其它模块的前提下，完成 [具体任务]。
工作模式：
使用独立 worktree / 独立分支。
允许读取：
- [相关目录或文件]
- AGENTS.md
- 现有测试或文档
允许修改：
- [明确文件或目录]
禁止修改：
- package.json
- lockfile
- 数据库迁移
- 生产配置
- 与任务无关的 UI 和文案
命令权限：
- 可以运行：[命令列表]
- 需要确认：[安装依赖、联网、删除、Git 写操作、部署]
验收标准：
- [页面或功能行为]
- [测试或构建命令]
- [不能回归的旧行为]
完成时必须输出：
1. 修改文件列表
2. 关键 diff 说明
3. 已运行命令和结果
4. 失败或跳过的验证
5. 未确认风险
6. 建议合并顺序如果任务卡写不出来，说明这个任务还不适合并行。先让一个 Agent 做只读梳理，输出拆分方案，再决定开几个执行线程。
多 Agent 工作流的最低标准
把 Codex 从聊天用法推进到多 Agent 工作流，不是多开几个窗口就结束了。最低标准是：
- 每个 Agent 有独立目标。
- 每个 Agent 有明确文件边界。
- 每个 Agent 有最小上下文。
- 每个 Agent 有受控权限。
- 每个 Agent 有验收记录。
- 合并前有人看 diff、失败日志和未验证项。
做到这些，多 Agent 才是在帮你缩短等待时间。做不到这些，多 Agent 只是把一次大的不确定性拆成几次更难追踪的小不确定性。
更稳的心智模型是：Codex Agent 是并行开发线程，不是自动合并机器。你可以让它们同时推进，但合并权、权限边界和最终验收必须留在人类或团队流程手里。