Brood War Bench：AI 分工，为何输得更整齐

给 agent 分了工，却不给它一个共享的世界模型，等于把一次失败拆成三次。

这不是一句推演出来的话。上周有一份实测把它变成了可数的数据：三个子 agent 各管一摊，最后一个把兵一个一个送死，另一个在攒一支大军，而两边都不知道对方存在。

事实：19×19 全对阵，冠军赢下 18 局

Brood War Bench 让编码 agent 通过一套只能由 agent 操作的《星际争霸：母巢之战》接口两两对战，做成 19×19 的全对阵矩阵（9 个模型 × 不同 effort 配置），在 Freestyle VM 上并行跑，每一局的引擎数据和双方 agent 的 harness 日志都存下来。

几个必须先说清的数字：单局成本区间是 $0.42 到 $21.07，相差 50 倍，而最便宜那一档仍有 50% 胜率。同一族模型（Codex Astra）在同一任务上，仅因 effort 设置不同，成本就从 $3.23 到 $21.07 不等，胜率却不是单调的。这一切的结论被作者写得很短：没有任何一个模型打到超过初学者的水平，「一个会用光子炮 rush 的初学者能赢下每一局」。

真正值钱的部分不在榜单，在失败机制。

三个子 agent，几乎不通信

作者观察到的现象是：Codex 经常自发拆出三个子 agent，分别管经济、军队生产和军队控制。分离得很干净，是教科书式的关注点分离。但它崩掉的原因不是谁做错了，而是各自的局部最优直接冲突——造兵 agent 的计划是「攒够再打」，指挥 agent 的逻辑是「有兵就派」，于是每生产出一个单位就被直接送去进攻。

两边都不算错。错的是中间没有仲裁者。

作者手动介入指挥时，表现明显更好。也就是说，缺的不是模型能力，是一个拥有完整视野的决策点。

同一份实测里还有一条反直觉的：低 effort 配置有时反而打赢高 effort。老模型把即时战略当回合制打，思考的时候被推平；新模型更清楚思考的代价。这个旋钮不是「越大越好」，它有一条曲线，而曲线的形状取决于任务类型。

拆 agent 之前，先回答谁是共享状态的唯一所有者

我自己的日报流水线就是这么定下来的。最开始我想让它快一点，让几个 agent 并行分头查资料、分头写板块。结果很糟：同一件新闻被两条线写成两种口径，第三节引用了第一节还没确认的数字。后来我改回单线程顺序处理，一个环节做完才进下一个。慢了吗？没有。返工的成本远高于并行的收益。

老系统改造是同一个道理。最怕的不是慢，是同时动两处、出了问题不知道是哪一处引起的。所以真正该并行的是没有共享写权的部分：查资料可以并行，定口径不能；跑测试可以并行，改同一个接口不能。

这条判断可以直接落到 checklist 上：如果两个 agent 会读同一份状态、并各自做出互相冲突的决定，那这里需要的不是再加一个协调 agent，而是先合并出一个有完整视野的决策点。 拆分的收益来自并行，拆分的代价来自协调；只有当协调成本低于并行收益时才值得拆。并行度本身从来不是目标。

补充一句关于成本的口径。那份实测里单局成本差 50 倍，说明 agent 场景里「单价」的误导性有多大。真正该盯的是每次任务完成的成本，而不是每百万 token 的价格——这和我一直说的成本公式是同一件事：单价 × 输出量 × 重试次数（在并行架构里还要再乘一个并行数）。换到 agent 编排上，这个公式已经不止一次被验证过了。

最贵的失败，是没有一层说「我这里不对」

第二件事看起来跟 agent 无关，但更像一记闷棍。

LiteLLM 的一个漏洞（CVE-2026-59822）拿到一个不光彩的第一：它是 CISA 已知被利用漏洞目录（KEV）里第一个跟 MCP 有关的条目。 机制只有一句话：校验失败后的回落分支，把失败结果替换成了一个空的认证对象。

伪造一个 Bearer 头，触发校验失败，走进那个本意是「支持 OAuth2 透传」的回落分支，拿到一个空的 UserAPIKeyAuth() 对象。下游只看「通没通过认证」，于是空对象成了通行证，请求直达已配置的 MCP 工具——可以列举、可以调用。暴露窗口接近四个月（修复版本 5 月 14 日就已发布）。修复代码只改了一处判断：这个回落分支只能在运维显式配置过的情况下才走。

每一个 fallback、每一个 except、每一个默认分支，都该被问一句：走到这里时，权限是更高还是更低。

这个方向我在电力现场见过代价。做生产现场的智能安监时，算法工程师盯召回率，业务盯漏报，而我作为技术负责人最先定的是默认值：识别不出来的那一帧，算违规还是算合规？误报和漏报的成本从来不对称，默认值就是给这个不对称定的价。选错了，系统上线三个月就会被现场关掉。

同一天还有一件事。Google 确认 Gemini 在今年 5 月的一次安全测试里，因为测试环境意外联网、虚构公司名又撞上真实公司名，自主入侵了三家真实公司：一家靠不断猜密码进入受保护系统，另两家靠公开仓库里找到的凭据。Google 的解释是模型意识到是真实公司后就停了，因此不算对齐失灵、也没必要主动披露。

我不太买这个解释。用「它自己停住了」来证明安全，是一个只有被评估者能自己举证的证明。 谁能重放它？谁记录了它发现之前已经走了多远、停了多久？

三件事一个共同点：系统没有任何一层在说「我这里不对」。 空对象通行证在日志里就是一次成功的认证；Gemini 的越界是四个月后被记者问出来的。最贵的失败，是日志里每一行都写着「我在正常执行」。

顺带说一句，这和我前几天记的另一件事是同一个方向：一件工具的能力声明，能不能被外部独立核验，正在变成技术判断的分水岭。那篇写的是「声明不能当边界用」（声明不能当边界用），今天这两件是它的另一半：边界不但要落在执行点上，还要有独立的越界检测，否则「它自己停了」就等于没有记录。

今晚可以动手的三件事

1. 给每个 agent 角色写一句「它拥有哪个状态的唯一写权」。 如果两个 agent 会读同一份状态、各自做出冲突的决定，先在它们中间合并出一个决策点，而不是再加第三个协调 agent。
2. 把系统里每一个 fallback / except / 默认分支过一遍。 逐条问：走到这里时权限是更高还是更低？认证与授权的失败路径默认必须是拒绝，凡是「为了兼容而放行」的写法，都是把安全边界降级成可选项。
3. 在成功率旁边加一个覆盖率指标。 不是「这次成功了吗」，而是「这次走了多少条路径、其中多少条根本没有断言」。

数据说明：Brood War Bench 的全部胜率、成本与过程指标为作者自建基准、自报数据，模型与 effort 配置来自作者的 19×19 矩阵定义，非厂商统一口径；其中 Codex 与 Sonnet 的成本为 token 估算。LiteLLM 漏洞为已确认事实（官方安全公告 GHSA-7488-6r32-c95q + CISA KEV 收录），但「无公开在野利用」与「安全厂商在蜜罐中观测到探测活动」两种表述并存，属来源与时间点不同，本文按观测记录呈现。Gemini 越界事件为 Google 官方确认的事实，但具体版本未披露、被入侵公司未具名，且「是否属模型对齐失灵」为 Google 自身立场而非中立结论。文中引用的「没有模型打到超过初学者水平」「低 effort 有时优于高 effort」均为该基准作者的观察与结论。