盲评 · 双向评审抵消位置偏置 · 多次取平均 · 持续更新
AO 多智能体质量评测：发现与结论（Phase 1）
用
eval/run-eval.ts（npm run eval）做的质量评测闭环结论存档。 目的：回答 ao 押注的核心假设是否成立——多角色 DAG 协作的产出，是否真比用户自己写一句 prompt 更好？
方法
- 对比：同一输入，跑 ao 多智能体工作流的最终产出 vs 一次性 prompt 基线（模拟用户不用 ao 的写法）。
- 盲评：judge 不知哪份来自 ao；对 (A=多智能体,B=基线) 和交换后的 (A=基线,B=多智能体) 各评一次取平均 → 抵消 LLM 评审最大的位置偏置。双向不一致 → 标"低可信"。
- 生成/评审分离：生成用待测模型，评审固定用强模型（Claude）给可信判别。
- 多次平均：每模板跑 N 次取平均，压住单次高方差。
结果
强模型生成（Claude 两侧），高可信子集
| 模板 | 多智能体 | 单次基线 | 结论 |
|---|---|---|---|
| story-creation | 9.0 | 8.0 | ✅ 多智能体 |
| tech-blog | 8.0 | 9.0 | ❌ 基线 |
| ai-opinion | 8.0 | 9.0 | ❌ 基线 |
| product-review | 7.5 | 8.5 | ❌ 基线 |
→ 多智能体 1 胜 3 负，≈ 打平偏负。且单次"高可信"仍跨次剧烈摆动（ai-opinion 四轮：5.5→9.0→9.0→8.0），证明 N=1 不够、需多次平均。
弱模型生成（ollama/llama3 两侧），3 次取平均
| 模板 | 多智能体 | 单次基线 | 胜者 | 稳定性(多胜/总) |
|---|---|---|---|---|
| story-creation | 5.0 | 6.3 | ❌ 基线 | 0/3 |
| tech-blog | 3.0 | 4.5 | ❌ 基线 | 0/3 |
| ai-opinion | 2.5 | 5.2 | ❌ 基线 | 0/3 |
| product-review | 4.7 | 4.2 | ✅ 多智能体 | 2/3 |
→ 多智能体 1 胜 3 负，且 3 个败局都是 0/3（三次跑里从没赢过）——稳定的规律，非噪音。
中档模型生成（DeepSeek，ao 的实际默认 provider），3 次取平均
| 模板 | 多智能体 | 单次基线 | 胜者 | 稳定性(多胜/总) |
|---|---|---|---|---|
| story-creation | 8.0 | 7.0 | ✅ 多智能体 | 2/3 |
| tech-blog | 8.2 | 5.7 | ✅ 多智能体 | 3/3（高可信） |
| ai-opinion | 8.7 | 8.2 | ✅ 多智能体 | 2/3 |
| product-review | 7.5 | 7.7 | ❌ 基线 | 1/3 |
→ 多智能体 3 胜 1 负——与强、弱两端完全相反。tech-blog 3/3 高可信决定性胜出（8.2 vs 5.7：DeepSeek 单次写的博客有 bug/截断，多智能体流水线产出完整可发布）。
2026-09-25 复测：强模型档 + 把验收写成数据（claude-code 两侧，story-creation，n=1）
| 模板 | 多智能体 | 单次基线 | 结论 |
|---|---|---|---|
| story-creation | 8.0 | 4.5 | ✅ 多智能体（双向一致，高可信） |
同一模板、同一档位（强模型），此前是 9.0 vs 8.0（险胜），这次是 8.0 vs 4.5（拉开）。差在哪，两位盲评员的 理由里写得很直白——都在数验收标准：
A 没有标题，开头直接写掀卷帘门的动作，结尾停在夜光表针的画面上；B 带了「# 快七分钟」这个标题、结尾直接点明主题， 违反了验收标准第 1、3、4 条。
中间发生的事：① 模板把 deliverables 与成稿步的 acceptance 写全了（「没有标题 / 字数 ±30% / 第一段就是具体画面 /
不点题」）；② 盲评的锚点修成取交付物那一步的 acceptance（此前取「最后一个完成的步骤」，末尾挂 review 步时会拿甲的
尺子量乙）。于是「把验收写成数据」这件事第一次在评分上直接体现出来。
但这条数据要连着它的偏置一起读：基线从没看过那份验收标准（它拿到的只有「任务目标 + 输入 + 请直接产出成品」）， 而多智能体那侧不仅看过、还被自动核验逼着满足。这正是产品的真实使用形态（你把验收写一次，流水线替你执行）， 但不是 prompt 对 prompt 的等价比较——真要做等价比较，基线 prompt 里也得带上同一份验收标准。
所以当场做了对照组：同一档位（claude-code 两侧）、同一天，换一个没有写 acceptance、也没声明 deliverables
的模板跑同样的对比：
| 模板 | 多智能体 | 单次基线 | 结论 |
|---|---|---|---|
| tech-blog（无 acceptance） | 8.5 | 8.5 | ➖ 打平（低可信：两向互相矛盾） |
两位盲评员这次谁也说服不了谁——一位说基线覆盖面全（profile / GIL / rayon / NumPy / CI 都写到了）， 另一位说多智能体那份「第一版更慢」的真实叙事更有说服力、数据更可复现。产出长度也相差一倍 （多智能体 5517 字 / 基线 11739 字）。
两条合起来读，结论比单看任何一条都干净：强模型档上，多智能体本身 ≈ 打平（与本文件早先的判断一致）； 把验收写成数据之后才拉开差距。 也就是说 8.0 vs 4.5 那条量的是「AO 这套用法值不值」， 不是「多智能体天生更强」——两个问题的答案不一样，别混着引用。
结论：关系是非单调的（Goldilocks）
把三档拼起来，规律很清楚——多智能体相对单次的增益，取决于生成模型的强弱，且不是越强越好或越弱越好：
| 生成模型档位 | 多智能体 vs 单次 | 为什么 |
|---|---|---|
| 极弱（llama3 8B） | ❌ 决定性更差（1胜3负，败局 0/3） | 每步质量太低，交接链放大漂移/错误，不纠错 |
| 中档（DeepSeek，默认） | ✅ 更好（3胜1负） | 模型够格执行每个专精步骤，但单次又没到顶 → 分工真能抬质量 |
| 强（Claude） | ≈ 打平偏负（1胜3负） | 单次已接近上限，编排开销不划算 |
修正此前判断：本文件早期写"核心假设被证伪"是错的——那是只看了两端（llama3 太弱、Claude 太强），都不是 ao 的真实档位。补上中档（DeepSeek）后，核心假设在 ao 的实际默认 provider 上是成立的：多智能体确实赢。
机制：弱模型在交接处累积漂移（中英混杂、跑题、虚构 API、漏草稿），交接链是误差放大器；中档模型每步都能胜任专精子任务，分工带来真实的"先研究再写、先评审再定稿"的质量增益；强模型单次已够好，多一道工序边际收益趋零。
最重要的现实含义：ao 默认就用 DeepSeek，而 DeepSeek 正落在"分工有用"的甜区。所以**"便宜但不弱的模型 + 多智能体 = 更好产出"这个卖点，数据支持**——前提是默认 provider 不能掉到 llama3 那种极弱档（那会主动变差）。
过程中发现并修复的真问题（评测闭环的副产品）
- 4 个模板引用已发布角色库不存在的角色（用户装完跑不通的 shipping bug）→ 依赖提到
^1.1.0。 - 收口步骤产物污染（漏进复盘/反问/
ao命令）→ 加反污染约束；ai-opinion 5.5→9.0 翻盘。 - 收口步骤产出过薄（只吐结论、丢上游内容）→ investment 改为整合完整报告。
- harness 截断偏置（喂 judge 前截到 3500 字，砍掉长产出结尾、系统性惩罚长产出）→ 提到 20000。
- judge JSON 解析失败整条丢失 → 重试一次。
战略含义
- "便宜但不弱的模型 + 多智能体 = 更好产出"这个卖点，数据支持——在默认的 DeepSeek 档位，多智能体 3 胜 1 负。可以放心讲"质量"，但要讲清楚是在这一档。
- 默认 provider 是生死线，且要卡在甜区：默认必须是 DeepSeek 这种"够格但没到顶"的档位。绝不能默认到 llama3 那种极弱档——那会让多智能体主动比单次更差，新用户第一次就被劝退。若用户自带强模型（Claude/GPT-4 级），诚实说法是"≈打平，价值在结构化复现而非质量提升"。
- 任务类型有差异：创作/观点/技术写作（story/ai-opinion/tech-blog）多智能体稳赢；偏"汇总评审"的 product-review 仍接近或略输——分工增益在"需要先研究/先评审再产出"的任务上最明显。
- 过程价值始终在：确定性 DAG、角色校验、可 resume 迭代、版本化可复现——这是质量增益之外的、不依赖模型档位的护城河。
边界与局限
- 三档各 4 个模板、3 次平均——有清晰信号但非穷举；judge 用 Claude（强但仍有少量位置偏置，低可信项已标注，多次平均已部分压噪）。
- 甜区的边界未精测：DeepSeek 赢、llama3 输，但中间还有大片模型（GPT-4o-mini、Qwen、更大的开源模型等）没测，"分工有用"的具体强弱区间仍是估计。
- 基线 prompt 由"工作流目标+输入"机械合成，不是精调的人类 prompt——真实强 prompt 可能让基线更强。
- 声明了
acceptance的模板，盲评会拿它当首要锚点，而基线从没看过这份标准（见 2026-09-25 那条）。 这对「AO 用起来是不是更省心」是有效的，对「多智能体本身是不是更强」是有偏的——读这类数字时要分清问的是哪一个。
复现
# 默认：ollama 生成 + claude-code 评审 + 1 次
npm run eval [workflows/x.yaml ...]
# 自定义
AO_GEN_PROVIDER=deepseek AO_GEN_MODEL=deepseek-chat \
AO_JUDGE_PROVIDER=claude-code \
AO_EVAL_RUNS=3 \
npm run eval workflows/story-creation.yaml ...
自己复现
git clone https://github.com/jnMetaCode/agency-orchestrator
npm install && npm run eval