我用 Supervisor 把多 agent 编排失败率从 40% 砍到 8%
怪招本 v3 改版时，让一个 reviewer agent 检查 25 篇文章骨架的一致性。第一版失败率 40%，调了 3 处 review 标准后砍到 8%。Supervisor 模式的核心不是 prompt，是 review 标准的颗粒度。
一句话总结：Supervisor 模式不是”让一个 agent 检查另一个 agent”，是”review 标准要可量化、可分层、可追溯”。第一版我用「写得不够好」做标准，失败率 40%；改用「frontmatter 字段完整性 / H2 数量 / token 表存在」3 项硬指标后，失败率 8%。
任务源头
怪招本 v3 改版时，我让 Commander agent 一次产出 25 篇文章骨架（5 个 type × 5 栏目）。Commander 跑得很快——4 小时，25 篇粗稿全出。
但粗稿质量参差不齐：
- 3 篇缺 frontmatter 的
tags字段 - 2 篇 H2 数量少于 5 个（结构单薄）
- 4 篇没有 token 账单表（不符合怪招本规范）
- 1 篇甚至 frontmatter 的
no字段写错（C7 写成了 C6）
失败率 40%（10/25 不达标）。如果直接发布，站点的风格一致性就崩了。
按以前的做法，我会自己逐篇 review——25 篇每篇 5 分钟，至少 2 小时。
这次用 Mavis（Supervisor 模式）——一个 reviewer agent 自动检查所有 25 篇。
下面是 review 标准从模糊到精确的 3 次迭代。
时间线：3 轮 review 迭代，约 90 分钟
| 轮次 | review 标准 | 失败率 | 失败原因 |
|---|---|---|---|
| v1 | 「写得不够好」 | 40% | 标准模糊，agent 自由发挥 |
| v2 | 5 项硬指标 | 12% | 标准太严，把好稿子也毙了 |
| v3 | 5 项硬指标 + 分层 | 8% | 区分 critical / minor 错误 |
决策点 1：Supervisor 的 review 标准要可量化
v1 我用的 prompt 是：
# 你的角色
Supervisor。检查下面 25 篇稿件的质量，给出修改意见。
# 任务
逐篇 review，列出问题。
结果 reviewer agent 给出了 10 个「写得不够好」「结构松散」「结尾仓促」这种主观判断——我对照原文一看，4 篇根本没问题，是 reviewer 跑偏了。
手动决定：改成硬指标。
v2 的 prompt：
# 你的角色
Supervisor。检查下面 25 篇稿件。
# 5 项硬指标（每项 1 分）
1. frontmatter 有 title / lede / date / no / section / type / readTime / tags
2. H2 数量 ≥ 5
3. 包含至少 1 个表格
4. 包含 token 账单表（按 Sonnet 3.5 估算）
5. 末尾有"附：工具调用链"段落
# 输出格式
每篇给出分数 + 缺失项列表。
v2 跑下来，3 篇 4 分（缺 1 项），1 篇 3 分（缺 2 项）。失败率从 40% 砍到 16%。
决策点 2：怎么处理 Supervisor 自己的错误
v2 还有个问题：reviewer 把好稿子也毙了。
具体一篇：某篇「现场」段落只有 2 行文字（没有截图），reviewer 给了 4 分因为「缺截图不算缺结构」。但我作为人类判断——没截图的案例段落质量就是降一档。
手动决定：把硬指标从”全过即合格”改成”分层判定”。
v3 的分层：
# 判定等级
- critical（必须修）：缺 frontmatter 字段 / H2 少于 5 / 无 token 表 / 无工具链附录
- major（建议修）：缺表格 / 缺决策点段落
- minor（可选修）：缺截图 / 措辞可优化
v3 跑下来，25 篇里：
- 2 篇 critical（缺 token 表）→ 必须修
- 1 篇 major（缺表格）→ 建议修
- 2 篇 minor（缺截图）→ 可选
失败率 8%（2/25 critical 失败）。
决策点 3：Supervisor 和被监督者的 token 分配
这次任务的总 token 账单：
| 角色 | 输入 token | 输出 token | 费用 | 单价 |
|---|---|---|---|---|
| Commander（产 25 篇） | 65k | 28k | $1.18 | 一次性 |
| Supervisor v1（模糊标准） | 12k | 5k | $0.22 | 浪费 |
| Supervisor v2（5 项硬指标） | 18k | 8k | $0.34 | |
| Supervisor v3（分层判定） | 22k | 9k | $0.40 | |
| 合计 | 117k | 50k | $2.14 |
关键洞察：Supervisor v1 的 $0.22 是纯浪费——标准太模糊，跑了跟没跑一样。
Supervisor 模式的成本结构：reviewer 的成本是作者的 30-50%。如果 v1 这种失败率高的 reviewer，成本不是问题（才 $0.22），但时间浪费是问题——我自己看完 10 篇「写得不够好」的反馈要 30 分钟。
最优策略：第 1 轮 review 就用硬指标，不要试「写得不够好」这种模糊 prompt。
token 账单（v3 最终跑）
| 阶段 | 输入 token | 输出 token | 费用 |
|---|---|---|---|
| Commander 产 25 篇粗稿 | 65k | 28k | $1.18 |
| Supervisor v3 review 25 篇 | 22k | 9k | $0.40 |
| 我手动修 2 篇 critical | 6k | 4k | $0.13 |
| 我手动优化 3 篇 major/minor | 8k | 5k | $0.17 |
| 合计 | 101k | 46k | $1.88 |
对比没 Supervisor 的版本：我自己逐篇 review 25 篇 = 2 小时（时薪按 $30 = $60）。Supervisor 帮我省了 58 美元 + 2 小时，前提是 v3 的硬指标 + 分层判定。
给也想用 Supervisor 的朋友的 3 条建议
1. review 标准必须是硬指标，不要用「写得不够好」。Supervisor 的核心不是「让一个 agent 检查另一个」，是「review 标准要可量化」。5 项硬指标（frontmatter / H2 / 表格 / token 表 / 工具链）覆盖 80% 的质量问题。
2. 分层判定：critical / major / minor。v2 的「全过即合格」会把好稿子也毙了——比如缺截图不算结构问题，是 minor。但缺 token 表是 critical。分层后我自己只需要修 2 篇 critical，剩下的都是可选优化。
3. 第 1 轮 review 就用硬指标，不要试「写得不够好」这种 prompt。v1 的 $0.22 看起来便宜，但失败率 40% 意味着我自己要花 30 分钟看反馈——Supervisor 模式的真正成本不是 token，是「你自己消化反馈的时间」。
现场
对比 v1 → v3 的 review 报告：
| 维度 | v1 模糊标准 | v3 分层硬指标 |
|---|---|---|
| review prompt 长度 | 50 字 | 280 字 |
| 25 篇 review 时间 | 8 分钟 | 12 分钟 |
| 失败率 | 40% | 8% |
| 误判率（好稿被毙） | 16% | 0% |
| 我自己消化反馈的时间 | 30 分钟 | 5 分钟 |
关键洞察：v3 的 review 时间比 v1 长 4 分钟（8 → 12），但我消化反馈的时间从 30 分钟砍到 5 分钟。Supervisor 模式优化的是你，不是 agent。
附：v3 的 Supervisor prompt 模板
# 你的角色
Supervisor。检查下面 {N} 篇稿件。
# {N} 项硬指标（每项 1 分）
1. frontmatter 完整：title / lede / date / no / section / type / readTime / tags
2. H2 数量 ≥ {MIN_H2}
3. 包含至少 {MIN_TABLES} 个表格
4. 包含 token 账单表（按 Sonnet 3.5 估算）
5. 末尾有"附：工具调用链"段落
# 判定等级
- critical（必须修）：指标 1-4 任一缺失
- major（建议修）：指标 5 缺失
- minor（可选修）：截图缺失 / 措辞可优化
# 输出格式（每篇）
{
"no": "C7",
"score": 5,
"level": "pass",
"issues": []
}
关键设计：
- 硬指标用
{}占位符（不要硬编码 5/5/1）——不同栏目最低标准不同 - level 三档而不是「pass/fail」——major 和 minor 不阻塞发布
- 输出 JSON 不输出散文——我后续用脚本批量统计失败率
下一篇写 Co-thinker——它跟 Supervisor 的差别不是 review，是反问的视角。Supervisor 反问稿件，Co-thinker 反问你。
— 怪招本 #008 · 2026-06-28