第 18 章 · 多 Agent 工厂与规模化

本篇目标：把 1 个 Agent 的 Harness 扩成 10+ 并发、成本可控、无人值守的产线。 社区 一个 Agent 的 Harness 是配置，十个 Agent 的 Harness 是编排平台。

18.1 从 1 到 10，多了哪些东西

社区 单 Agent 与多 Agent Harness 的对照（amux 等编排平台的共同骨架）：

判据 22：并发的头号失败模式永远是共享可变状态，不是模型能力。先解决 worktree 隔离与任务原子认领，再谈更聪明的编排。

18.2 确定性节点与智能体节点分离

社区 Stripe「Minions」每周交付约 1300 个 AI 生成 PR，其关键设计是把流水线拆成两类节点：

这条分离是规模化最重要的一条架构原则：能让脚本做的事，绝不让模型做。它同时降低 token 成本、延迟与不确定性，也让故障定位简单一个数量级。

一手案例：OpenAI 的 agent-first 实验

官方 Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, 2026-02-11：

四条对本系列直接构成印证的经验：

1. 早期慢不是模型不行，是环境欠规格：原文 "the environment was underspecified"，缺的是工具、抽象与内部结构。这正是第 03 章 information parity 与第 06 章定责二分法的规模化版本。
2. 给地图，不给百科全书："give Codex a map, not a 1,000-page instruction manual"——短 AGENTS.md 当目录，设计文档、规格、执行计划、技术债记录放进结构化 docs/。与第 07、10 章的指针化原则一致。
3. 约束不变量，不微观管理实现："By enforcing invariants, not micromanaging implementations"——固定分层、边界处解析数据形状、结构化日志、文件大小限制，靠 CI 与自定义 linter 强制。第 08 章的 hook / coverage test 就是这条的单 Agent 版。
4. 熵需要垃圾回收：Codex 会复制仓库里已有的坏模式，团队一度每周花 20% 时间清 "AI slop"；后来把 golden principles 编码进仓库，让后台任务定期扫描偏差、更新质量评分、开定向重构 PR。这是第 07 章「月度复审删除规则」的自动化形态。

还有一个与本系列的直连点：原文把「让 Codex 自审 → 请求更多 agent review → 响应反馈 → 循环直到所有 reviewer 满意」明确称为 Ralph Wiggum Loop——与第 14 章 DSH 的 ralph 工具（每轮换全新子 Agent 推进同一目标）是同一思想的不同实现。

⚠️ 原文自己给出的边界必须一并引用："This behavior depends heavily on the specific structure and tooling of this repository and should not be assumed to generalize without similar investment." 这些数字是单个团队在强 Harness 投入下的结果，不是行业基准，也不是你可预期的产出。

社区 amux 指南还提到 Stripe「Minions」每周约 1300 个 AI 生成 PR，以及「确定性节点 vs 智能体节点」的分离；本教程未定位到 Stripe 一手公告，仅作为架构线索。

18.3 成本与容量模型

生产 Harness 必须把成本当成一等约束，而不是月底看账单。

一个可落地的最小预算表：

单任务预算 = 常驻开销 × 轮次 + 工具结果 token + 输出 token + judge 开销
日预算     = 单任务预算 × 并发数 × 日均任务数
硬约束     = 日预算上限 + 单任务 max_turns + 每 session token 记账 + 超限熔断

官方 自动化鉴权的一条实操提醒：headless 自动化的受支持路径是 ANTHROPIC_API_KEY 或长生命周期 OAuth token，订阅登录不是受支持的无人值守路径；夜间任务要按计量 API key + 月度花费上限来预算，别假设订阅覆盖。DSH 侧同理：Harness 免费，模型调用按量计费 原文。

18.4 可观测性：从「看终端」到「看窗口」

社区 一句运维判据值得记住：「一次失败是噪音，十分钟十二次是事故。」 单事件阈值会误报也会漏报，生产告警必须落在时间窗上，并在上线前用最近 24 小时数据 backtest。

官方 DSH 侧对应 subsystems/session-telemetry、token-meter、append-only 事件日志与 Trajectory；但告警系统需要自建（第 16 章已标注为 推断）。

18.5 规模化的六个反模式

18.6 本章产出与验收

核心产出：一张 10 并发产线架构图（任务板 / worktree / 恢复 / 监控 / 记账 / 审计），加一份日预算模型与一次超限熔断演练记录。

验收点：

• 能解释确定性节点与智能体节点为何必须分离
• 能画出 worktree 隔离与合并队列的关系
• 能给出自己场景的单任务预算公式与三个硬约束
• 能说明为什么告警必须按时间窗而非单事件
• 能指出 18.5 里自己架构已经踩了哪几条

延伸阅读