多智能体编排器越改越差？我们给 40 次真实运行做了全量对照实验
一句话版本：把执行链路从「静态计划」改成「角色化自主协作」是智能体圈最热的方向，我们真做了——接进系统、跑 40 次真实任务、和现有链路同题配对，结果新架构输了：均值 0.3576 vs 基线 0.3990/0.4833。但 A/A 对照（同题同配置同刻并发四份，得分 0.28→1.00）暴露了比输赢更重要的东西：编排本身的不确定性，才是多智能体最大的坑。
为什么要做这次改造
buddyme 现有主链路是 `ModeRouter → ReWOO（Planner → Worker 滑动窗口 → 合成）`：一次规划、静态依赖、按数据流走步骤。它稳，但形态是「照图施工」——遇到「做什么本身就是判断」的开放任务，图不够用。
行业给的答案是 DROrchestrator（DeepResearch 编排器）这类角色化编排：总调度把目标拆成「角色 × 任务 × 依赖」的有向无环图，每个角色是一个自治子智能体，自己决定搜索什么、何时停止，通过共享账本交换中间产出，最后汇总成报告。
我们把它接进系统作为可选执行档（环境变量 `BENCH_AGENT_KIND=dr` 开启），生产主链路零改动。然后做的不是「跑通即发布」，而是老老实实跑基准。
改造怎么做的：三处改动，全部加开关
工程上的纪律比结论本身更值得抄：
第一处：入口分流。 在基准执行入口 `common.py` 加一个 `kind=dr` 分支——只构造 DROrchestrator 并把工作目录指过去，原有的 chat/loop/plan_exec/rewoo 四种执行档一个字不动。
第二处：工作区适配。 DR 默认建知识库式子文件夹结构，加 `BUDDYME_DR_FLAT_WS=1` 开关切到扁平工作区；不开就是原行为。
第三处：独立驱动脚本。 测试驱动和对比脚本全新建文件，不碰旧实验代码——保证基线数字可以原样复现。
三处改动对应一条铁律：试验性架构必须可一键关闭。40 次运行验证的不仅是新架构，还有「改了它不会伤到线上」这件事本身。
实验设计：40 次运行 × 双基线 × A/A 稳定性对照
从 9 个数据集抽 10 题（Evo-Bench 办公任务、AgentDojo 旅行/Slack、DeepSearchQA 深度检索、GTA 矩阵计算、PinchBench 会议分析、VitaBench 个性化推荐），跑 4 轮共 40 次真实 LLM 运行；同时与两条基线同题配对：
| 轮次 | n | 均分 |
|---|---|---|
| r1（顺序） | 10 | 0.4945 |
| r2（顺序） | 10 | 0.2000 |
| r3（并发） | 10 | 0.3444 |
| std10b（并发） | 10 | 0.3917 |
| 四轮合计 | 40 | 0.3576 |
配对结果：相对 A3 单臂基线 -0.0414（2 升 3 降 5 平），相对 default 臂 -0.1257（1 升 4 降 5 平）。
关键发现：A/A 对照撕开了真正的伤口
输给基线不丢人——丢人的是不知道为什么输。于是我们做了最贵也最值的一步：同一道题、同一配置、同一时刻，并发跑四份：
| 份 | 得分 | 耗时 |
|---|---|---|
| pp1 | 0.28 | 215s |
| pp2 | 0.39 | 404s |
| pp3 | 0.39 | 509s |
| pp4 | 1.00 | 638s |
同一份代码、同一个模型、同一个目标，得分从 0.28 到 1.00，耗时差 3 倍。这一刀排除了时间漂移和负载差异，把矛头指向编排本身的三个随机环节：拆解（LLM 自由生成任务与依赖）、子智能体行程（自由决定搜索与停止）、汇总（哪些结果进报告）。
对照另一道题更狠：四份全 0，且工作目录里根本没有任务要求的 orders.json——失败模式不是「做得不好」，是「交付物形态就错了」。
失败模式清单（照着排查你的多智能体系统）
1. 交付物错配：DR 只产 answer.md/txt，交付型任务要 orders.json/xlsx → 结构性 0 分
2. 拆解随机：无固定模板，同一题四轮拆出四种任务形态
3. 无并发上限：全角色同刻并发，排队把耗时拉到 3 倍
4. 无重派：子任务单次尝试失败即丢分，无回补
5. 角色固定：不按题型选人，交付型题仍派 deep_search 角色
而基线 ReWOO 赢的结构性原因也清晰了：静态计划恰好匹配「路径可预先确定」的交付型题目——变量替换是确定性的、路径短、没有自由发挥的环节，也就没有自由发挥的方差。
结论与决策选项
| 选项 | 前提 | 后续工作 |
|---|---|---|
| A 维持现状（DR 仅测试档） | 接受暂不接入 | 无 |
| B 门控接入（默认关） | 有报告类场景需求 | 交付物契约、拆解模板、收口校验 |
| C 按题型分流 | 先做题型分类器 | 分类器 + 60 题验证 |
| D 继续工程化 | 看好角色化路线 | 确定性拆解+交付契约+重试+并发上限 |
常见问题
多智能体不是比单智能体强吗？
答：分任务。开放型/报告型任务上角色协作有优势；交付型任务上静态计划碾压自主协作。我们的配对差是负的，但 A/A 方差（σ 均值 0.227）说明「强不强」之前先得「稳不稳」。
40 次运行能下结论吗？
答：不能下显著性结论——n=10 配对符号检验无统计效力，需要 ≥60 题池。这份报告的价值在方向与失败模式清单，不在终审判决。
改坏了怎么办？
答：这就是「全部加开关」的意义。`BENCH_AGENT_KIND` 不设，系统行为与改造前逐字节一致；三个开关全关，生产链路零风险。
落到实操：在 BuddyMe 上复现这套验证
这套「改造→A/A 对照→失败模式归因→决策选项」的方法论，在 BuddyMe 上可以整套跑：
- 验证即生产：接入新执行档用环境变量门控，跑基准用同一套入口——试验架构永远可一键退回
- 过程留痕：每次运行的拆解结果、子智能体行程、账本内容全量落盘，A/A 差异可以逐环节 diff 到根因
- 免费额度：每天 4500 万 Token，40 次真实运行的验证成本约等于零，让「上线前先跑数据」成为默认动作而非奢侈
智能体的架构升级不该靠信仰，该靠同题配对。跑不赢的架构先关掉，跑得稳的再谈接进来。
*数据来源：buddyme 内部基准 DROrchestrator 改造验证报告（2026-11-02，9 数据集 10 题 × 4 轮 × 双基线配对 + A/A 对照，模型 buddyme_glm_flash5.3 全程真实 LLM 运行）。*