模型编排的魅力到底在哪里

现如今多智能体编排的建议是：让最强的模型当指挥，成本低的模型去干活。Quesma 的工程师 Bartosz Kotrys 把这条建议认真复现了一次：他把四个 Claude 模型串起来，跑 Terminal-Bench 2.1。这个 benchmark 把 agent 扔进一个沙箱终端，让它完成 89 个真实的命令行任务，从编译项目到恢复密码，每个任务给五次机会。跑完解决率 78%，榜单第七，总账单 1,178 美元，大约是第一名单模型条目成本的两倍。

在跑terminal bench时他遇到的四个问题全在编排层，模型本身一个都没遇到。我们这篇按顺序过一遍遇到的四个问题，顺便看看 跑agent遇到的445 条轨迹里，多智能体到底把钱和时间花在了哪。

两分钟搭好的编排器

先看编排器。整个编排器是四个文件，没有框架，没有编排库：CLAUDE.md 里多追加一段话，加上三个角色文件。四个角色分工是：Fable 5 当编排器，只规划和派活，自己不写代码；Haiku 4.5 当侦察员，只读不写；Opus 5 当执行者，改代码、跑命令、调试；Sonnet 5 当验证者，审查干完的活。

让我们仔细看这次bench。prompt 里有个刻意的约束：agent harness里的每句话都在负责描述编排，没有一句对应的任务提示。原因是榜单上其他条目全都没有自定义 prompt，一旦开始写相关指令，就会有没有控制变量的问题，测试的就是 prompt  engineering，而不是编排的性能，对比也就不公平了。脚手架只保留本身，这次跑分和普通单 agent 跑分之间唯一的差别就是多Agent这个动作，后面所有的问题也都出自这个动作。

模型拒绝干活

有三个任务五次尝试一次都没做成：vulnerable-secret、break-filter-js-from-html、password-recovery。执行者连做错的机会都没有，它不肯动手。每次尝试都一轮就返回同一个报错，成本为零："Claude Code can't respond to this message with Opus 5. Try rephrasing the request in a new session or change your model." 这是安全分类器在拒绝完全合法的 benchmark 任务：找泄漏的密钥、拦 XSS payload、恢复密码，都是安全工程师每天上班会干的活。

关键在对照。把同样三个任务放进普通的单 agent 会话，不搞编排，直接问 Opus 5，它全做出来了，6 次尝试 6 次解决。同一个模型，同样的任务，直接问就会做，变成agent委派来的子任务就拒绝，14 次委派 14 次拒绝。

我们第一个猜测是新出的 Opus 5 比排在它前面的 Opus 4.8 更谨慎，于是做了测试：同样的任务、同样的委派配置，两个模型行为一模一样。换模型没用，拒绝的原因出在任务的呈现方式上。他证明不了拒答的原因，但细节不难发现：一个子任务被另一个 agent 剥掉原始上下文、只剩一句干巴巴的"找到密钥"之后，在安全层眼里比人类提出的同一个请求更可疑。能证明的是效果：拒绝是编排器制造出来的，榜单上的单 agent 条目永远碰不到它，因为它们不委派。

这种失败模式只有把模型连接起来才会出现。带着它再看榜单，差距更直观：78% 排名第七，如果把三个被拒任务按直接跑的对照记成解决，就是 80.5%，第三名。第七名和第三名之间差的 2.5 个点，就是这三次拒绝回答。

验证设成可选，就有一半概率被跳过

验证者由编排器自行决定是否回答，实际在 76% 的运行里被回答了。这一个选择成了整个 benchmark 里最强的成功预测变量：回答了验证者，任务解决率 91%；跳过审查，43%。差距有 48 个点，而且模型相同，任务也相同。

我们承认这里有选择偏差：编排器只验证它自己觉得快干完的活。但差距仍然指向 prompt：CLAUDE.md 里写的是"验证者审查工作"，从来没写"结束之前必须验证"。于是四分之一的时间里编排器跳过审查直接交活，交出去的活一半是错的。整条流水线里最值钱的一步被设成了可选，这个 78% 是松 prompt 设下的下限，模型能力的上限比这高。对照榜首更清楚：第一名 83.8%，而真正被审查过的那部分活解决率 91%，验证如果强制执行，第一名就是可以达到的。

最贵的模型在token花销最大的地方上

成本拆开看是个低级错误。1,178 美元让这次跑分成了全榜第二贵，仅次于 Codex + GPT-5.5 的 2,059 美元，而第一名的 Claude Code + Fable 5 只花了 553 美元。这些钱benchmark的是第七名。

钱究竟花在哪了？和成本相关最高的一件事是执行者产出多少：输出 token 数和单次尝试成本的相关系数 r=0.93，委派次数几乎不影响账单。账单由干大批量活的那个角色决定，而他全跑里最贵的模型恰好坐在那个位子上。

Opus 5 当执行者，吃掉 58% 的开销。最便宜的 Haiku 4.5 坐在侦察位上，对成功率只贡献了 1 个点。产量最大的活用了最贵的模型，最不重要的活用了最便宜的模型。用作者自己的话说，贵的地方在连接方式上，多智能体本身不为这个问题背锅：把 Sonnet 或 Haiku 换去实现，Opus 留给真正难的推理问题，同一套架构的成本能降到零头。上一篇文章写过这个思路，让便宜模型动手解决问题、贵模型动脑思考大方向。

交接超过六次，成功率反而腰斩

交接次数决定的事比成本还多，它还决定成败，方向跟直觉相反：超过某个点之后，问题越多，活干得越不细致，开始空转。

子智能体委派 3 到 5 次的尝试解决率达到 90%，单次 2.41 美元。编排器的分解决得不够，一次把整个问题甩出去，解决率只有 59%。6 次以上，Agent就已经混乱，如果把同一份活来回委派，解决率甚至掉到 50%，单次 9.51 美元，接近四倍成本。好的编排 prompt 在允许委派的同时，还得给委派设定上限。

可靠性决定了分数

把 445 条轨迹合起来看，可靠性决定了分数，和模型的原始能力关系不大。模型自己单次执行会尝试能解决 78% 的任务，如果模型执行五次尝试取并集能到 93%。

89 个任务里有 28 个是不稳定的：这次解决，下次模型可能做不出来，同样的模型同样的任务，纯看运气。真正够不着的只有 4 个，五次都没做成：编译 CompCert、两个 MIPS 解释器、一个文本检索任务。这才是能力的天花板，但天花板不高。

还有一个意外的结果。原本预期四个模型的harness会在最难的任务上完全迷失，错误的hand off会放大，整个系统空转。实际没有。从易到难，解决率是 85%、79%、76%，只掉了 9 个点，尽管难任务单次成本是易任务的 2.4 倍。编排恰恰在你预期协调开销会压垮它的任务上成功解决了。要说模型编排有什么理由，这是第一个。

445 条轨迹里的其他信息

Terminal-Bench 的榜单有一列 Hacks，专门扣作弊的分数，这个 benchmark 有作弊前科：榜上前五名里的 Cursor CLI + Grok 4.5 被扣了 9 分，真实分数更接近 70%，不是榜上的 79%。所以值得问一句，他的编排器是不是也偷偷作弊才到的 78%。轨迹给出的答案是没有：沙箱挡住了 agent 找答案文件时会去摸的设备和挂载逃逸，一次成功的作弊都没有。干净的跑分和分数一样值钱。

还有几个数字：

• 失败的尝试比成功的更贵。失败的尝试平均 3.60 美元、26 分钟，成功的平均 2.52 美元、19 分钟。agent 放弃之前挣扎的时间，比它干成之前花的时间还长。
• 账单高度集中在头部。最贵的 25% 尝试吃掉 57% 的总开销。一个任务，cell segmentation，单次尝试花了 23 美元，差点顶到他设的单次预算上限。
• agent 读得远比写得多。整个跑分过了 11.6 亿 token：读入 5.98 亿，生成 2,300 万，26 比 1，其中只有 48% 命中缓存。
• 全部加起来是 145 个 agent 小时，445 次尝试，1,289 次委派。

作者说这些都不稀奇，是 frontier 模型在循环里跑起来的日常状态。

框架的问题

回头数四个坑：委派任务的呈现方式、把审查设成可选的 prompt、坐错位子的贵模型、委派过度就空转的编排器。没有一条是因为模型太笨。

那编排还值得做吗？答案显而易见，四个 frontier 模型加一个编排器，在这个 benchmark 上没赢过一个好的单一模型，花的钱还更多。但是我们仍然觉得这个方向可行，因为我们multi agnet所有出错的地方都能追到问题：prompt 约束、验证合同、模型到角色的分配、委派时递过去的上下文。他一次跑分里集齐四个错误，仍然拿了第七；光修掉拒绝就是第三；强制执行验证，第一名就够得着。

我们在 benchmark 那篇文章里评价过，验收要做到骗不了 agent，需要验证设成可选，整体来看，框架是你能控制的部分，而且框架就是四个文件，很快就能能改完。但是要把模型串起来干活，需要四件事情做完备：委派任务带上原始上下文，验证写成强制执行，模型负责决策，并且交接需要仔细审核。

-- 完 --

机智流推荐阅读：

1. ‍

2. 

3. 

4.