333 个智能体构建，Claude Code 收尾

《用智能体重建 williamliu.ai》6 篇系列的第 3 篇。请从总览开始阅读。

要点

🏗️ Codex 目标模式（goal mode）把 1 条指令变成 333 个智能体和 43 次提交，历时 5 天。
🔍 规则是：每项变更都冻结为精确 diff，并通过发现者（Finder）、质疑者（Adversary）和裁决者（Referee）审查；所有例外都必须记录。
🧱 它卡在代码之外：无法运行的沙箱，以及连续 6 次失败的部署。
🔁 随后 Claude Code 担任编排者：修复交给新的 Codex 运行，自己做一些小修正，之后审查、截图并运行完整测试关卡。
⚖️ Codex 更擅长持续并行构建；Claude Code 更擅长引导、查看实际结果和处理运维。
🪞 两者各自发现了对方的错误，也都会犯自己的错误。

同一次改版由两套很不一样的智能体配置完成；在这个项目里，它们的失效方式不同，恰好让彼此成为对方的检查机制。 第一套是单个 Codex 目标：我给出 1 条指令，由 1 个根智能体带领数百个子智能体。第二套是在我的终端里运行 Claude Code，由它决定下一步修什么，再把工作交给新的 Codex 运行。本文用同一个代码库、同一周和日志里的数字来比较两者。

fig 01 两套配置并排对比。Codex 目标模式，9 月 2 日至 8 日：含根智能体在内共 333 个智能体，43 次提交，33 亿 Codex token，按 API 价格折算为 $1,671。Claude Code 指挥 Codex，9 月 10 日至 12 日：1 个 Claude Code 会话，89 个 Codex 智能体，16 次提交，6.6 亿 Codex token 加 3.6 亿 Claude token，按 API 价格折算为 $632。

到 9 月 16 日生产上线时，宽口径台账中的 Codex 运行从 514 次增至 630 次，Claude 运行从 36 次增至 53 次。本文对 333 次运行构建阶段和 89 次运行对齐阶段的比较没有变化：这些严格口径阶段此前已经结束。后续工作只是为同一套分工提供了更多证据。

🏗️ 目标模式：1 条指令，333 个智能体

我的一段指令变成了一次为期 5 天、大部分时间自行推进的构建，其间 5 次停下来等我批准：研究、规格文档（spec）、里程碑计划和 43 次提交。 我要求 Codex 对比设计与当前网站，把工作拆成可并行执行的小任务，避开数据层，保护生产环境，使用子智能体，并审查每项变更，"until no critical bugs."（直到没有严重 bug。）Codex 把它作为目标运行：一个长期存在的目标，会跨越多个轮次持续执行，直到完成或受阻。

根智能体完成研究、撰写规格文档和计划，并在每个关卡等待我批准。它停下来等我 5 次，总计将近 6 小时。等待最久的一次约 3 小时，是等我批准修订后的规格文档。随后它展开并行工作。字体、博客页面、播客页和浏览器测试工具分别成为一条工作线，各自使用自己的智能体和 git 工作树（worktree）。同一时间只有 1 个智能体拥有共享文件，根智能体每次集成一项已完成工作并提交。

我很早就让它按任务难度选择模型。它确实这样做了：整个过程中用了 7 个模型，简单任务交给小模型，最强模型担任最终裁决者。

🔍 按规则，每项变更由 3 名审查者把关

规则是：发现者、质疑者和裁决者检查过完全相同的冻结 diff 之前，任何内容都不能提交。 每项候选变更都按明确的允许路径列表暂存，并用 diff 的 SHA-256 哈希留下指纹。发现者寻找 bug、安全问题和遗漏的测试。质疑者挑战每项发现，并继续寻找发现者漏掉的问题。通常由最强模型担任裁决者，判定严重级别。只要有一项阻断问题成立，就必须修复或明确作出决定，然后生成新哈希，再开始一轮完整审查。构建后期，无法使用独立审查者时，根智能体自行审查了部分变更，并把这种情况标为后备审查，没有冒充独立审查。

fig 02 构建阶段按角色划分的 Codex 运行与 token：202 次审查者运行（75 次发现者、62 次质疑者、65 次裁决者）使用 5.61 亿 token；130 次实现、修复和研究运行使用 13.4 亿；1 个根智能体使用 13.9 亿。

也就是说，构建阶段有 202 次审查者运行，对应 130 次构建、修复和研究运行。按 token 计算，情况正好相反：审查者使用 5.61 亿，占构建阶段 33 亿 token 的 17%；构建者使用 13.4 亿，负责协调所有人的根智能体使用 13.9 亿。审查者读取一份冻结 diff；构建者读取自己要修改的代码；根智能体每执行一步，都要重读自己不断增长的整段对话。冻结哈希的重要性超出我的预期。审查者不能批准仍在变化的改动，修复也不能悄悄扩大范围。

这套冻结 diff 的循环，把《动态工作流是首个像流程工具的 AI 编码功能》（Dynamic Workflows Are the First AI Coding Feature That Looks Like a Process Tool）的观点落到了实处：流程本身可检查、可重复，不依附于某一个智能体的答案。

它们找到了真实问题。一个浏览器测试辅助工具会在有人打开调试日志时打印真实访问凭据；共用的 cookie jar 也可能在两个测试服务器之间携带预览访问 token。两项问题都用假 secret 复现，并在提交前修复。

这份初稿完成后，内联视频功能在 Claude Code 编排下再次检验了同一思路。Codex 负责实现，随后又由 Codex 进行了 15 轮审查。前 11 轮看起来都已通过后，仓库自身的完整关卡——而不是另一名审查者——发现了 INV-7：发布侧代码不得导入内容类型模块。修复后进行了第 12 和 13 轮审查，随后完整关卡发现第二条不变量：拿到快照的构建不得重新打开输入。第 14 和 15 轮审查关闭了这个问题，第 15 轮给出 READY TO COMMIT。这并不代表审查没有用，而是说明了它的边界：冻结 diff 审查可以对改动施压检验，仓库自身的不变量仍是另一套事实依据。

🧱 目标模式卡在哪里

构建于 9 月 7 日完成；目标模式停止推进，发生在把它放到预发布 URL 这一步。 代码之外的 2 件事拖慢了进度。

我的机器上无法使用沙箱。 Codex 的沙箱无法创建所需的网络命名空间，甚至无法通过补丁工具读取现有文件。它改为写出完整替换文件，先用 git apply --check 验证再应用；遇到 2 个损坏的补丁时，它选择拒绝，而没有强行应用。
部署失败 6 次。 其中 3 次在 Python 内部崩溃，1 次在嵌套构建中失败，1 次败在一项测试，另 1 次是构建环境无法启动某个工具。第 5 篇会详细说明。

审查循环也没有刹车。自定义音频播放器一直审到第 14 轮，看起来仍然不像设计。9 月 7 日快结束时，我问网站为何还没有继续推进，以及过去 24 小时究竟完成了什么。随后不久，我让 Codex 把部署问题连同全部发现移交给 Claude Code。

🔁 Claude Code 担任编排者

第二阶段，Claude Code 选择每项修复、写出精确任务说明、让 Codex 实现，然后亲自检查结果；更快的小修正则由它直接完成。 12 轮修复都采用同一个循环：

Claude Code 写任务说明：设计参考、确切问题、范围内文件，以及需要运行的测试。
一次新的 Codex 运行负责实现并运行针对性测试。审查发现新问题时，由后续 Codex 运行修复，或由 Claude Code 直接做小修正。
Claude Code 审查 diff，在桌面和手机宽度下截图，与设计对比，并自行运行完整测试关卡。
每轮 1 次提交，合适时再执行预发布部署。

fig 03 一轮修复：Claude Code 编写任务说明，一次新的 Codex 运行负责实现和测试（审查发现新问题时，由后续运行或直接的小修正处理）；随后 Claude Code 审查 diff、截图对比设计，并在提交前运行完整测试关卡。

整个阶段中，Claude Code 共启动 30 次 Codex 运行，其中 18 次实现、12 次审查和审计；这些运行又生成 59 个智能体，其中 46 个是审查者。从把改版放上预发布环境（staging），到最后一轮修复，整个对齐阶段使用 6.6 亿 Codex token 和 3.6 亿 Claude token，按 API 价格折算为 $632；Codex 构建阶段则为 $1,671。部署路径修复后，每次预发布部署约需 1.5 分钟。

初稿之后也继续沿用了这套模式。真实的 7 篇文章暴露出小型测试样稿掩盖的博客布局问题，我要求并行启动 Codex 修复智能体。3 个智能体分别在独立工作树中修复索引页、首字下沉，以及文章元数据和图注标签，之后又做了 1 轮窄屏修复。Claude Code 用本地截图工具渲染真实的 7 篇文章，逐个验证各工作树，再合并修复。有效的分工不只是并行：Codex 负责边界清晰的改动，编排者保留视觉判断和集成工作。

🪞 它们各自发现了对方的错误

在这个项目里，真正有用的特性是两套智能体栈会以不同方式失败。 日志里有几个例子：

Codex 的针对性测试漏掉了完整关卡发现的问题。 一项修复重命名了函数参数，但 3 个旧测试仍使用旧名称。Codex 自己的运行只检查了靠近改动的测试。Claude Code 的完整关卡失败，修复随后保留了旧测试原本表达的含义。
测试通过的布局 bug，被 Claude Code 审查发现。 展开的单集说明被渲染进只有 72 像素宽的封面栏。将 <details> 元素设为 display: contents 时，浏览器不会把它的子元素当作网格项。Claude Code 从截图发现了问题；几何测试现在会固定这个行为。
未经批准的文案混了进来，审查把它挡住了。 Codex 添加了 4 条无人批准的中文字符串，Claude Code 在审查中将其删除。项目页上一行未经批准的介绍也在第 1 轮修复中被删除。
Codex 发现 Claude Code 的计划错误。 审查 Claude Code 的部署计划时，Codex 发现一条 npm 命令漏了 --，这会让部署依赖的一个 flag 被静默丢弃。
我可以改变由谁审查什么。 一次只读 Codex 审计为 AEO/SEO 计划提供输入，但我要求由 Claude 而不是 Codex 审查这个计划。Claude 找到 3 个必须修复的问题：显示“Updated”日期会违反协议；标签聚合页的路由衔接说明不足；尾斜杠改动的范围太大。
Claude Code 也会误诊。 它起初把一批被终止的审查任务判断为工具框架的误报。系统日志显示，其中至少 1 次是真正的内核内存不足终止；它随后在日志中纠正了判断。

⚖️ 两种模式各自适合什么

规格明确、可以放手运行的构建适合目标模式；需要对照图片判断结果时，适合交给交互式编排者。

fig 04 两套配置在这个项目中的强项：目标模式适合长期并行构建、严格审查冻结 diff，以及只需我偶尔介入便连续工作数天；交互式编排者适合视觉验证、运维和部署，并能在几分钟内改变方向。

目标模式在规格明确的部分表现最好。它只需我偶尔介入，就能连续工作数天，同时维持审查标准。弱点是可见性、刹车和协调成本：我问了 20 次进度，在我设定规则前，中等问题不断重新触发审查；仅根智能体就用掉 13.9 亿 token，反复读取一段从未停止增长的对话。

编排者擅长需要观察和判断的任务：拿截图对设计、阅读部署日志、决定下一项修复。它把我的 4 个视觉问题分别在约 90 分钟内变成一次提交。弱点是每项修复的成本。每项修复都从一次新的 Codex 运行开始，需要从零熟悉仓库；这些运行平均使用 2,170 万 token，约为目标模式构建者平均 1,030 万的 2 倍。按 API 价格折算，Claude Code 自己的会话在部署路径上的成本也高于改版本身。第 6 篇列出了明细。

如果重来一次，我会先让编排者打通可用的部署路径，再让带有审查停止规则的目标模式完成构建，最后让编排者回来对照设计审计。

你的智能体工作流中，哪一部分需要人盯着，哪一部分可以独自运行 5 天？

本文写作方式：由 Claude Code 根据我本人的会话日志起草，另一个 Codex 智能体对照同一批日志核对事实，最后由我修改定稿。封面插图由 AI 生成；图表依据文中数字绘制。