第十八章 多 Agent 协作工作流

18.1 一个 Agent 不够

到这一章为止，我们一直在谈"一个 Codex 帮你做事"。

但 2026 年最前沿的玩法是：多个 Agent 同时为你工作，彼此分工、互相 review、并行加速。

想象这样的场景：

• Agent 1：架构师 —— 设计方案、分解任务
• Agent 2：开发者 —— 按方案实现具体代码
• Agent 3：测试员 —— 跑测试、找 bug
• Agent 4：审计员 —— 安全和性能审查
• Agent 5：文档员 —— 同步更新 README 和 API 文档

5 个 Agent 同时工作，每个负责自己擅长的部分，总耗时 = 单个 Agent 的 1/3 - 1/5。

这不是科幻，是 2026 年 Codex 桌面版（基于 Computer Use 的多代理隔离）和 Claude Code 等工具已经在做的事。

18.2 多 Agent 协作的三种基本架构

架构 1：流水线（Pipeline）

Agent A ──→ Agent B ──→ Agent C ──→ Agent D
设计       实现       测试       部署

每个 Agent 串行接力，前一个的输出是后一个的输入。

适合： 步骤明确、依赖性强的任务（比如完整 feature 开发）

架构 2：分工并行（Parallel）

            ┌─→ Agent A（前端）
任务分解 ──┤
            ├─→ Agent B（后端）
            └─→ Agent C（文档）
                        ↓
                    汇总交付

任务被拆成可并行的部分，多个 Agent 同时做，最后汇总。

适合： 子任务之间没有强依赖（比如同时改前端和后端）

架构 3：辩论 / 评审（Critique）

Agent A（提议） ──→ Agent B（批评） ──→ Agent A（修订） ──→ Agent B（再批评）
                                                                ↓
                                                            达成共识

一个 Agent 提议，另一个 Agent 故意挑刺，反复迭代。

适合： 需要"自检"的高风险任务（重要决策、安全审查）

18.3 实战：流水线模式

任务：给现有项目加一个完整的"用户认证"功能

涉及：数据表、API、前端、文档、测试。

角色分配

Agent A: 架构师（用 Claude Code 跑）
  - 设计 schema
  - 设计 API 接口
  - 写 PLAN.md

Agent B: 后端开发（用 Codex CLI 跑）
  - 按 PLAN.md 实现 API
  - 写数据库迁移
  - 写 API 测试

Agent C: 前端开发（用 Codex 桌面版跑）
  - 实现登录 / 注册 UI
  - 接 API
  - 跑 e2e 测试

Agent D: 文档员（用 Codex Web 跑）
  - 更新 README
  - 写 API 文档
  - 写用户手册

流程

Step 1: 你 → Agent A
"加一个用户认证功能（邮箱密码 + 第三方登录），写 PLAN.md"

Step 2: Agent A 输出 PLAN.md
你审 → 调整 → 确认

Step 3: PLAN.md → Agent B
Agent B 实现后端，输出 PR-backend

Step 4: PLAN.md + PR-backend 摘要 → Agent C
Agent C 实现前端，输出 PR-frontend

Step 5: PLAN.md + PR-backend + PR-frontend → Agent D
Agent D 写文档，输出 PR-docs

Step 6: 你 review 三个 PR，merge

关键技巧

技巧 1：用文件做 Agent 之间的"接口"

不要让 Agent 之间直接对话（容易跑偏）。用文件——PLAN.md、API.md、CHANGES.md——作为交接物。每个 Agent 只读自己需要的文件，输出指定文件。

技巧 2：每个 Agent 用独立的 AGENTS.md

project/
├── AGENTS.md                       # 通用规则
├── backend/AGENTS.md               # 后端 Agent 看这个
├── frontend/AGENTS.md              # 前端 Agent 看这个
└── docs/AGENTS.md                  # 文档 Agent 看这个

每个 AGENTS.md 强调"你的范围只在 X 目录，不要碰别的"。

技巧 3：你是总指挥

不要让 Agent 自动从一个 step 跳到下一个。每个 step 之间你审一下。否则一个错误会传染整个流水线。

18.4 实战：分工并行模式

任务：给项目做"国际化"（i18n）

涉及：

• 提取所有硬编码字符串到 i18n 文件
• 翻译成 5 种语言
• 改造组件支持 i18n 切换
• 更新文档

并行方案

你 → 任务分解：
  - 任务 A: 扫描代码，提取硬编码字符串到 strings.json
  - 任务 B: 翻译 strings.json 到 zh-CN, en-US, ja-JP, ko-KR, fr-FR
  - 任务 C: 改造 React 组件支持 useTranslation
  - 任务 D: 更新文档，加"国际化使用指南"

并行启动：
  - Codex Window 1: 跑任务 A（前置任务，必须先完成）
  - Codex Window 2/3/4: 等任务 A 完成后，分别跑 B/C/D

实操

打开 Codex 桌面版，菜单 → File → New Window，开 4 个独立窗口。每个窗口对应一个 Agent。

Window 1（任务 A）：

扫描整个 src/ 目录，提取所有硬编码的中文 / 英文字符串到 src/i18n/strings.json。
按页面 / 组件分组。完成后告诉我有多少条。

5 分钟后任务 A 完成。

Window 2/3/4 同时启动：

Window 2：

读 src/i18n/strings.json，翻译成 zh-CN, en-US, ja-JP, ko-KR, fr-FR 5 个版本，
分别保存到 src/i18n/{lang}.json。注意保持 key 一致，只翻译 value。

Window 3：

按 src/i18n/strings.json 的 key 列表，改造 src/ 下所有组件，
把硬编码字符串替换为 t('key.path') 调用。
不要改其他逻辑。

Window 4：

扫描项目，写一份 docs/i18n-guide.md，
包含：i18n 工作原理、新增语言怎么加、新增字符串怎么加、组件中怎么用。

3 个并行任务大约 20-30 分钟全部完成。

如果是串行做，要 1 个多小时。并行省了 60% 时间。

注意

• 三个 Window 共享你的 ChatGPT Plus 配额，会更快烧完
• 并行任务之间不能有依赖（任务 A 的 strings.json 是 B/C 的输入，所以 A 必须先完成）
• 可能出现"3 个 Agent 都改 README"这种冲突，需要事先明确"谁负责哪个文件"

18.5 实战：辩论 / 评审模式

任务：评估一个重要的架构决策

"我们要不要把数据库从 PostgreSQL 迁到 MongoDB？"

这种重大决策，让 AI 帮你"辩论"出最优解。

双 Agent 辩论

Agent A（赞成方）：

你的角色：数据库迁移的赞成方。

任务：
1. 分析当前项目（在 ~/projects/my-app/）
2. 列出 5 个支持迁移到 MongoDB 的理由
3. 估算迁移成本和收益
4. 输出 pro-migration.md

Agent B（反对方）：

你的角色：数据库迁移的反对方。

任务：
1. 分析当前项目（在 ~/projects/my-app/）
2. 列出 5 个反对迁移的理由
3. 列出迁移的隐藏成本和风险
4. 输出 con-migration.md

让两个 Agent 同时分析。然后你启动第三个 Agent：

Agent C（裁判）：

你的角色：客观裁判。

任务：
1. 读 pro-migration.md 和 con-migration.md
2. 对每个论点评估真实度（基于项目实际情况）
3. 给出综合建议：迁移 / 不迁移 / 部分迁移
4. 列出做出最终决定还需要的关键信息
5. 输出decision-recommendation.md

你看到三份文档：赞成、反对、综合判断。比一个 Agent 直接给"建议"靠谱得多。

适用场景

• 重大架构决策
• 投资 / 商业判断
• 复杂方案选型
• 高风险变更

18.6 让 Codex"操作"其他应用

2026 年 Codex 桌面版的 Computer Use 让一个 Agent 能"操作"另一个应用。

场景：自动化测试一个 web app

帮我测试 https://my-app.com 的注册流程：

1. 打开网页
2. 点"注册"按钮
3. 填表（用一个测试邮箱 + 强密码）
4. 提交
5. 检查是否跳转到欢迎页
6. 如果跳转，截图保存为 success.png
7. 如果失败，截图保存为 fail.png 并告诉我哪一步失败

测试完成后给我报告。

Codex 会用 In-App Browser 真的"打开浏览器、点按钮、填表"。这是真正的"端到端测试"。

场景：批量操作 GUI 应用

打开 macOS 的"图像捕捉"工具，
对 ~/Pictures/raw/ 里的所有 .heic 文件，
转换成 .jpg，保存到 ~/Pictures/converted/。
完成后报告转换数量。

Codex 通过 Computer Use 真的去点 GUI。这种"自动化 GUI"过去需要 AppleScript 或 Automator，现在自然语言就行。

18.7 多 Agent 的"治理"

Agent 多了会乱。需要一些治理：

治理 1：身份隔离

每个 Agent 用独立的 Codex 窗口（或独立 CLI 进程）。它们看不到对方的会话历史，避免互相污染。

治理 2：权限分级

架构师 Agent → Read-only 权限（只看不动手）
执行 Agent → Auto-approve safe（可以改文件）
部署 Agent → 严格 Ask First（动到生产前必须问）

治理 3：日志统一

所有 Agent 的执行日志都写到同一个 ~/codex-logs/ 目录，文件名带时间戳和 Agent 标识。出问题可以全局追溯。

治理 4：人为最终裁决

任何 Agent 之间冲突 / 互推责任的情况，人工介入。不要让 AI 自己"商量解决"——它们会陷入循环。

18.8 多 Agent 的失败模式

失败 1：循环互推

Agent A："这个我做不了，让 Agent B 做" Agent B："这个我也做不了，让 Agent A 做" （无限循环）

预防：明确每个 Agent 的边界，重叠的工作只能有一个 owner。

失败 2：理解漂移

Agent A 设计了方案，Agent B 实现时偏离了方案，Agent C 测试时按 B 的实现来，结果跟 A 的方案完全不同。

预防：每个 Agent 的输出都加"checklist"，下一个 Agent 必须先勾选 checklist 才开工。

失败 3：互相破坏

并行时，Agent 1 和 Agent 2 同时改一个文件。

预防：事先明确文件归属。或者用 git branch 隔离。

失败 4：成本飙升

5 个 Agent 同时跑，token 消耗可能是单 Agent 的 10 倍。

预防：算账。多 Agent 适合"高价值任务"，不要用来跑日常小任务。

失败 5：调试困难

某个 step 出问题了，不知道是哪个 Agent 的锅。

预防：详尽的日志 + 中间产出全部留存（不要 Agent 之间直接传递，都通过文件）。

18.9 一个完整的多 Agent Demo：自动化博客发布

我用一个真实场景把多 Agent 协作串起来。

任务

每周自动发布一篇技术博客。流程：

1. 选题
2. 起草
3. 修改润色
4. 配图
5. 发布

5 个 Agent 协作

Agent 1：选题（content-radar Skill）

每周一早上 8:00 自动触发：

• 扫描 30 个信息源
• 选 3 个候选选题
• 输出 candidates.md

人工选定一个。

Agent 2：起草（draft-writer Skill）

输入：选定的话题 工作：

• 查 5-10 篇相关资料
• 起草一篇 1500 字博客
• 输出 draft-v1.md

Agent 3：编辑（editor Skill）

输入：draft-v1.md 工作：

• 检查事实
• 检查文笔
• 检查结构
• 输出 review.md（修改建议）

人工拍板：接受哪些修改。

Agent 4：配图（illustrator Skill）

输入：终稿 工作：

• 用 gpt-image-1.5 生成 2-3 张配图
• 加 alt 描述
• 输出 final.md

Agent 5：发布（publisher Skill）

输入：final.md + 配图 工作：

• 转 HTML
• 上传到博客后台（用 Computer Use 操作浏览器）
• 设定发布时间
• 推送到社交媒体

整个流程 5 个 Agent 接力，人工干预只在"选题确认"和"接受编辑建议"两个点。从想法到发布的总耗时 < 1 小时（其中人工 10 分钟）。

18.10 普通人需要多 Agent 吗

诚实的回答：大多数普通人不需要。

单 Codex + 几个 Skills 已经能解决 90% 的问题。

什么时候你才"需要"多 Agent：

• 你已经把单 Agent 用得很熟，遇到了"复杂任务总要拆几次会话"的瓶颈
• 你的任务有明显的"并行加速"潜力（比如同时改前后端）
• 你处理的是高风险任务，需要"互审"机制
• 你有团队，想做"AI 流水线"

如果以上没有，先把单 Agent 用透。多 Agent 是高级玩法，但不是必经之路。

18.11 未来：Agent 编排框架

现在的多 Agent 还是"手工搭"——你开几个窗口、定义几个角色。

未来 1-2 年会出现"Agent 编排框架"：

• 你画一个流程图
• 框架自动调度多个 Agent
• 自动管理依赖、并行、错误恢复
• 类似 Airflow + Kubernetes 之于"任务调度"

OpenAI、Anthropic、各种创业公司都在做。值得关注。

18.12 本章小结

• 一个 Agent 处理 90%，多 Agent 解决剩下的"硬任务"
• 三种基本架构：流水线 / 并行 / 辩论
• 核心技巧：用文件做 Agent 接口、独立 AGENTS.md、人是总指挥
• Computer Use 让 Agent 能操作其他 GUI 应用
• 治理：身份隔离 + 权限分级 + 统一日志 + 人工裁决
• 5 种失败模式：循环、漂移、破坏、成本、调试
• 普通人先用透单 Agent，多 Agent 是进阶玩法
• 未来 1-2 年会有 Agent 编排框架

下一章看 Codex 在 GitHub 和 CI/CD 中的应用：第十九章 · GitHub 集成与 CI/CD。