AO 多智能体质量评测：发现与结论（Phase 1）
June 5, 2026 · View on GitHub
用
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/截断，多智能体流水线产出完整可发布）。
结论：关系是非单调的（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 可能让基线更强。
复现
# 默认：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 ...