TL;DR

Addy Osmani 提出了"编排税"（Orchestration Tax）的概念：启动更多 Agent 很容易，但你的认知带宽不会并行——每增加一个 Agent，你的判断、审查、纠错成本也在增加。本文拆解编排税的四种来源，给出降低编排税的三种实战模式，并附一套可运行的多 Agent 编排配置模板。

1. 多 Agent 看起来很美好，但有一个隐藏成本

2026 年 5 月 24 日，Addy Osmani 在《The Orchestration Tax》中写了一个很扎心的场景：

你让 Agent A 写后端 API，Agent B 写前端页面，Agent C 写单元测试，Agent D 审代码。它们并行了 10 分钟，产出了 800 行代码。然后你花了 45 分钟——理解每个 Agent 做了什么、检查它们之间的接口是否对齐、发现 Agent A 和 Agent B 对"用户 ID 字段名"的理解不一致导致前后端对接不上、手动修复这些问题。

Osmani 把这叫做编排税：你的认知带宽是固定的，每多一个并行 Agent，你的 review 负担不是线性增长，而是乘法增长——你要理解的不只是每个 Agent 的输出，还有它们之间的交叉影响。

这不是说不要用多 Agent。而是说，如果你不设计编排策略，编排税会吃掉所有效率红利。本文拆解编排税的来源，然后给出三种降低编排税的实战模式。

2. 编排税的四种来源

理解问题才能解决问题。编排税来自四个维度：

来源一：接口不对齐（最频繁）
两个 Agent 各自独立工作，对同一个数据结构的理解不同。Agent A 觉得 user_id 是 string，Agent B 觉得是 number。等你发现时，两边已经各写了 200 行代码。

来源二：上下文孤岛
Agent A 在修一个 bug 时引入了一个新的调用模式，Agent B 不知道这个变化，继续按旧模式写。两个 Agent 各自正确，合在一起就炸。

来源三：审查积压
三个 Agent 同时产出，你一个人 review。每份代码都要理解背景、验证逻辑、检查边界。大脑在三个上下文之间切来切去，效率极低。

来源四：错误级联
Agent A 的输出是 Agent B 的输入。如果 Agent A 有一个隐蔽的逻辑错误，Agent B 会基于错误的前提继续工作，错误被放大而不是被纠正。

3. 模式一：合同先行（Contract-First）

适用场景：多个 Agent 分别开发不同模块，模块间有明确接口。

核心思想：在 Agent 开始写代码之前，先让一个 Agent 产出接口契约（API spec、数据模型、类型定义），所有 Agent 共享这份契约作为"宪法"。

实战配置：

#!/bin/bash
# 合同先行模式：先定义接口，再并行开发
# 用法: bash contract-first.sh "用户管理系统" "包含注册、登录、个人信息修改"

FEATURE="$1"

echo "=== 阶段 1：定义接口契约 ==="
claude --print "
为以下功能设计完整的接口契约，输出到 contract.md：
功能：$FEATURE

契约必须包含：
1. API 端点列表（method、path、request body、response body）
2. 共享数据类型定义（TypeScript interface 格式）
3. 错误码约定
4. 数据库 schema 变更（如有）

格式：Markdown，精确到字段级别。
"

echo "=== 阶段 2：审查契约 ==="
echo "请人工审查 contract.md，确认无误后按回车继续..."
read -r

echo "=== 阶段 3：并行开发 ==="
# Agent A: 后端
(claude --print "
根据 contract.md 中的 API 契约和数据库 schema，
实现后端代码（FastAPI）。
严格遵循契约中定义的每一个字段名和类型。
如果有契约未覆盖的细节，先记录到 contract-questions.md，不要擅自决定。
") &
PID_A=$!

# Agent B: 前端
(claude --print "
根据 contract.md 中的 API 契约和类型定义，
实现前端代码（React + TypeScript）。
使用契约中定义的类型，从 contract.md 复制 interface 定义到 shared-types.ts。
严格遵循契约中定义的每一个字段名和类型。
") &
PID_B=$!

# Agent C: 测试
(claude --print "
根据 contract.md 中的 API 契约，
生成集成测试代码。
覆盖所有端点的正常路径和契约中定义的错误码。
") &
PID_C=$!

wait $PID_A $PID_B $PID_C

echo "=== 阶段 4：一致性检查 ==="
claude --print "
检查以下三个 Agent 的输出是否都与 contract.md 一致：
1. 后端代码
2. 前端代码
3. 测试代码

列出所有不一致之处，分级：
- 阻断级：字段名或类型不匹配，运行时必出错
- 警告级：约定之外的设计选择不一致
"

为什么这能降低编排税：接口不对齐（来源一）和上下文孤岛（来源二）被合同直接解决。Agent 不需要知道对方在做什么，只要遵守同一份合同。

成本：多了一个"定义合同"的阶段。但对于模块间有明确边界的场景，这个成本远低于事后修复接口不一致的成本。

4. 模式二：接力赛（Relay）

适用场景：任务有明确的先后依赖，下游依赖上游的输出。

核心思想：不要并行，让 Agent 一个接一个地跑，每个 Agent 的产出经过人工 checkpoint 后才交给下一个。

实战配置：

#!/bin/bash
# 接力赛模式：串行执行，每步有人工检查点
# 用法: bash relay.sh

set -e

echo "=== 第 1 棒：需求拆解 ==="
claude --print "
将 docs/feature-spec.md 中的需求拆解为可执行的任务清单。
输出到 tasks-breakdown.md。
每个任务必须包含：输入、输出、验收标准。
"
echo "CHECKPOINT: 请审查 tasks-breakdown.md"
echo "确认无误后按回车..."
read -r

echo "=== 第 2 棒：数据模型设计 ==="
claude --print "
根据 tasks-breakdown.md 设计数据库 schema 和数据模型。
输出到 schema-design.md 和 src/models.py。
参考：上一步的 tasks-breakdown.md
"
echo "CHECKPOINT: 请审查数据模型"
read -r

echo "=== 第 3 棒：核心逻辑实现 ==="
claude --print "
根据 schema-design.md 和 tasks-breakdown.md，
实现核心业务逻辑。
参考：上一步的 schema-design.md 和 tasks-breakdown.md
"
echo "CHECKPOINT: 请审查核心逻辑"
read -r

echo "=== 第 4 棒：测试与边缘情况 ==="
claude --print "
为已实现的核心逻辑编写测试。
重点覆盖：上一步代码中的边界条件、tasks-breakdown.md 中定义的验收标准。
"
echo "流水线完成。"

为什么这能降低编排税：审查积压（来源三）和错误级联（来源四）被 checkpoint 机制解决。每个 Agent 只需要审查一份产出，而不是三份。而且错误在 checkpoint 被拦截，不会传递到下游。

成本：比并行慢，但总耗时（Agent 时间 + 你的 review 时间）通常更短——因为你的 review 效率大幅提升。

5. 模式三：双 Agent 制衡（Dual-Agent Checks）

适用场景：对质量要求高的核心模块，值得花双倍 API 成本。

核心思想：一个 Agent 写代码，另一个 Agent 审代码。两者并行工作，审查 Agent 在代码 Agent 每完成一个文件后立即审查。

实战配置：

创建 scripts/dual-agent.sh：

#!/bin/bash
# 双 Agent 制衡模式
# 一个写代码，一个审代码，实时纠偏
# 用法: bash scripts/dual-agent.sh "实现用户认证模块"

TASK="$1"
WORK_DIR=$(pwd)
REVIEW_DIR=$(mktemp -d)

# 清理函数
cleanup() {
    rm -rf "$REVIEW_DIR"
}
trap cleanup EXIT

echo "启动代码 Agent..."
# 代码 Agent 在项目目录中工作
claude --print --output-format text "$TASK

重要：每完成一个文件，就在文件末尾添加一行注释：
// @REVIEW_READY: <文件名>
然后暂停，等待审查反馈。
如果有审查意见，先修改再继续。" > "$WORK_DIR/code-agent-output.txt" 2>&1 &
CODE_PID=$!

echo "启动审查 Agent..."
# 审查 Agent 监控代码 Agent 的输出
(
    REVIEWED_FILES=""
    while kill -0 $CODE_PID 2>/dev/null; do
        sleep 5
        # 检查是否有新文件标记为待审查
        NEW_FILES=$(grep "@REVIEW_READY:" "$WORK_DIR/code-agent-output.txt" 2>/dev/null | tail -1)
        if [ -n "$NEW_FILES" ] && [ "$NEW_FILES" != "$REVIEWED_FILES" ]; then
            FILE_NAME=$(echo "$NEW_FILES" | sed 's/.*@REVIEW_READY: //')
            if [ -f "$WORK_DIR/$FILE_NAME" ]; then
                echo "审查 Agent: 正在审查 $FILE_NAME"
                REVIEW=$(claude --print --output-format text "
审查文件 $FILE_NAME，检查：
1. 安全漏洞（注入、越权、敏感信息泄露）
2. 逻辑错误（边界条件、空值处理、并发问题）
3. 与项目现有代码的一致性
4. 可读性和可维护性

如果发现问题，输出格式：
## 阻断问题
- [文件名:行号] 问题描述
## 建议改进
- [文件名:行号] 建议
## 审查通过
如果没有问题，输出 '审查通过：无问题'。
")
                echo "$REVIEW" >> "$WORK_DIR/review-feedback.md"
                REVIEWED_FILES="$NEW_FILES"
            fi
        fi
    done
    echo "审查 Agent: 代码 Agent 已完成，开始最终审查..."
) &
REVIEW_PID=$!

wait $CODE_PID
wait $REVIEW_PID

echo "=== 双 Agent 制衡完成 ==="
echo "代码输出: $WORK_DIR/code-agent-output.txt"
echo "审查反馈: $WORK_DIR/review-feedback.md"

为什么这能降低编排税：审查 Agent 在每个文件完成后立即审查，而不是等你最后一次性审查所有代码。错误在源头被拦截，不会级联。而且审查 Agent 的存在本身会约束代码 Agent 的行为——它知道有人盯着。

成本：双倍 API 调用量。但对于安全敏感或核心业务模块，这笔投资是值得的。

6. 模式选择指南

你的场景适合哪个模式？按这个决策树走：

任务之间有明确接口边界？
  ├── 是 → 合同先行模式
  └── 否 → 任务有先后依赖？
              ├── 是 → 接力赛模式
              └── 否 → 对质量要求极高？
                        ├── 是 → 双 Agent 制衡模式
                        └── 否 → 考虑：真的需要多 Agent 吗？
                                  也许一个 Agent 就够了。

最后一个分支是最重要的提醒：不是所有任务都需要多 Agent。Osmani 在《Your parallel Agent limit》中写道：大多数人能有效管理的并行 Agent 数量是 2-3 个，超过这个数，编排税超过效率收益。

7. 踩坑与最佳实践

坑 1：过早并行
很多人在任务定义还不清晰的时候就启动了多个 Agent。结果每个 Agent 都在"模糊地带"做了自己的假设，最后拼不起来。解决：在并行之前，确保任务边界已经足够清晰——最实用的标准是"你能用一句话说清楚每个 Agent 的输入和输出吗？"

坑 2：忽略了"胶水代码"
多个 Agent 产出的模块之间需要胶水代码来连接。如果你没有在计划中预留胶水代码的开发时间，最后就是你自己手动写这些胶水——而这恰恰是最容易出 bug 的部分。建议：在任务拆分时，把"集成层"作为一个独立任务分配给一个 Agent。

坑 3：Agent 之间的"礼貌性沉默"
当审查 Agent 检查代码 Agent 的产出时，代码 Agent 可能会生成看起来合理但实际有问题的代码，而审查 Agent 因为缺少足够的领域知识而放行。解决：在审查 skill 文件中包含项目的关键业务规则，确保审查 Agent 不只是做语法检查。

坑 4：没有成本追踪
多 Agent 编排的 API 调用量是指数级的。建议在每次编排任务开始时记录时间戳和预估 token 量，结束后对比实际消耗。一个月后你就能看出哪些类型的任务适合多 Agent，哪些不划算。

8. 总结

编排税不是反对多 Agent 的理由，而是提醒你：并行 Agent 的数量不是免费的。每增加一个 Agent，你就在增加接口对齐、上下文同步、审查、纠错的成本。

三种模式的核心思路其实是一致的：用结构化的流程降低认知负担。合同先行用接口定义减少对齐成本，接力赛用 checkpoint 减少审查积压，双 Agent 制衡用实时审查防止错误级联。

当你下一次想"再开一个 Agent 来加速"时，先问自己：这个 Agent 带来的产出增量，能覆盖我审查它、对齐它、纠错它的时间吗？如果能，开；如果不能，也许现在这个就够了。

参考资料

• Addy Osmani - The Orchestration Tax (2026-05-24)
• Addy Osmani - Your parallel Agent limit (2026-04-07)
• Addy Osmani - The Code Agent Orchestra (2026-03-26)
• Claude Code 官方文档