CLASHarness：多智能体桌面冲突评测，样本批量造、判分不靠人

CLASHarness 让「多个 AI 智能体共用同一块电脑桌面时会不会互相干扰」变成一件可以批量制造、自动判分来测的事。它造出 600 个可执行的冲突轮次，让 15 个前沿模型各跑一遍，得到的最强结论不是模型看不见冲突，而是看见了也收不了尾，最需要主动改变系统状态的那类收尾动作，失败率落在 58% 到 72% 之间，连最强的 GPT-6 Astra 和 Claude Opus 5 也失败超过一半 CLASHarness。

CUA 评测一直默认只有一个智能体在干活

Computer Use Agent（CUA）是一类让模型像人一样看屏幕、点鼠标、敲键盘，去完成跨软件操作任务的智能体。围绕这类智能体的评测过去两年已经做得很工程化，但它从头到尾只回答一个问题：一个智能体能不能独自把活干完。真实部署正在往另一个方向走。当多个智能体共用同一块桌面，谁的指令算数、哪个数字才是真的、谁负责把手里的共享锁交出去，这些才是真正会让任务崩掉的地方。CLASHarness 补的就是这一块。

这个缺口不是猜出来的，它画在现有评测的架构图里。OSWorld 是目前 computer use 评测的事实标准，它把评测环境从网页沙盒拉回整台真实电脑，虚拟机里跑 Ubuntu、Windows、macOS，智能体用原始鼠标键盘指令操作，判定交给 134 个执行式检查函数直接读系统状态，不靠模型自己声称做完 OSWorld。但它的环境架构图上只有一个 Coordinator，没有多智能体协调模块。

图注：OSWorld 的环境基础设施。宿主机上运行 Coordinator 与 Task Manager，对接虚拟机暴露的状态、截图与可访问性树；配置文件用四种颜色标注初始化、后处理、检索与执行式评估。图中没有多智能体协调模块，只承担单智能体、真实 OS、执行式评估这一坐标。OSWorld

规模上，OSWorld 初版在 Ubuntu 上有 369 个任务，2024 年的基线里人类操作者能完成 72.36%，最佳模型只有 12.24%，跨应用工作流更低到 6.57%。这套数字定义了什么叫评测成熟，也说明它的边界被守得很清楚，只是边界之外还站着一群智能体。

前沿模型自己的表现也在提示这个方向。OSWorld 2.0 把任务拉长到真正的工作流，108 个任务的人类完成中位数是 1.6 小时，而最好配置也只做到 20.6% 的完整通过率。它列的十个挑战现象里有一个直接叫 Conflict Disambiguation，指的是跨源、过期、相互矛盾的更新，出现在 108 个任务中的 36.1%，属于模型最弱的一组 OSWorld 2.0。

要补上这块空白，还绕不开两个现实约束。手工写样本没法扩展，真实操作系统里的冲突场景太多太杂；放开让大模型自由生成又会漂移，叙事会跑偏，答案会泄漏，生成出来的评分标准经常根本没法满足，任务还没测就已经无解。CLASHarness 的两条设计承诺，可控和可验证，就是冲着这两个约束去的。

要造出可控的冲突样本，得把生成拆成三层八步

「可控」在这篇论文里有具体含义：冲突的类型和难度是参数，不是靠作者一个个手写出来的。做到这一点的手法是不让模型一口气把整个场景写完，而是把生成拆成三层、八步，每一步都能单独审计。这是全篇的核心机制。

第一层负责搭出一个共享的多智能体世界，用大约 8 次 LLM 调用定下全局大纲、子智能体与交互规则、背景工作区。第二层逐轮生成，每个场景包跑 10 轮，每 3 到 4 轮刷新一次里程碑，每一轮严格走八个显式子步。第三层负责审计与渲染，做一致性检查、多模态精修，最后渲染并核验。八个子步从写任务指令、生成同伴智能体消息、更新文件，一路做到注入视觉资产、提交关键事实、规划执行步骤、在真实沙盒里跑一遍参考轨迹，最后编译判定谓词。

图注：CLASHarness 的三层生成流水线。第一层由种子与插件初始化共享的多智能体世界；第二层每 3 到 4 轮刷新里程碑，每轮经八个显式子步生成，真值 v★ 在渲染前提交；第三层做一致性审计、视觉精修与渲染核验。绿色标签代表确定性处理，红色标签代表有界重试。CLASHarness

论文给出的规模是 20 个场景种子乘 3 个变体，共 60 个场景包，每个 10 轮，合计 600 个可执行冲突轮次，覆盖 3,284 条必需评分检查、7,970 个渲染出的多模态资产和 23 个插件。整套 600 轮的基准大约对应每个 10 轮场景包 95 次 API 调用。

让「冲突类型」真正变成参数的是分类体系。论文把冲突分成六个类别，但正文没有逐一列出六个名称，只给出各类别的种子数分布 9/6/6/6/4/1，以及一批可复现的样本，比如报销冲突和分布式锁争用。任务难度则用参考轨迹长度参数化，轨迹在 7 到 18 步之间，平均 10.28 步，对应一个 20 步的动作预算，9 步以内算简单，12 步以上算困难。同一个场景包内部，只有 1.6% 的语义判分标准会重复出现。

多智能体冲突具体长什么样，可以先用几种组织拓扑建立直觉。三个用户共享同一份资源时，可以由一个协调者智能体服务所有人，也可以每人一个智能体但彼此不通话，还可以让每人一个智能体并开一条互通渠道。同样的任务在这几种拓扑下的表现差别很大，协调者的效果在个人助理场景里常常接近点对点团队的两倍 Worse Together。CLASHarness 要造的，正是后一种拓扑下那些会互相打架的时刻。

同一时期还有一条同源但重心不同的路线，把 verifier 当成独立的软件制品，从执行反馈里持续自我修，而不是像 CLASHarness 这样在渲染前就把关键事实钉死 OpenComputer。两种设计都在回答同一个问题，怎么让生成的样本自带可信的判分，只是选择的重心不同。

判分不靠人：验证器在生成时就编译成代码

CLASHarness 判分不靠人的关键，是把评分标准在生成阶段就编译进流水线，并且把决定成败的那个事实在渲染之前就钉死。这和事后找模型打分是两回事。

可以把它想成两种出考卷的方式。多数基准是先把题出完，再找人阅卷，甚至找模型阅卷。CLASHarness 则是出题的同一只手同时写好标准答案和判分脚本。落到流水线里，就是第二个子步那一环：在资产被渲染成图片之前，先把决定成败的真值提交进去，并做一遍泄漏扫描，确认这个数不会提前出现在文本里。600 轮里有 346 轮把这个真值标成必需。

一个可复现的样本能看清这套设计在防什么。在报销冲突这个场景里，旧的缓存显示一个过期总额 850.00 EUR，这个数字在工作区文本里出现了 14 次，而真正正确的金额 725.46 EUR，等于 678.00 乘 1.07，在 25,526 个字符的文本里出现 0 次，只出现在那张逐项收据的图片里。想答对，就必须真的去看图。

到最后一步，判定谓词由纯代码编译出来，这一子步是 0 次 LLM 调用。也正因为判分标准是从执行过的参考轨迹编译而来，它是一段软件，不是一段随模型漂移的文本。

判分仍然留了一部分给模型。3,284 条检查里，34.9% 共 1,147 条是确定性的代码检查，65.1% 共 2,137 条由 LLM 做语义判分。答案不是全用代码，因为像界面语义这类判据很难全部编译成程序。也不该全用模型，因为那样就回到了没法审计、会随 prompt 漂移的老问题。为压住模型判分的不确定性，论文用多个样本做自洽检验，在 19,419 次调用上有 97.5% 的判决一致，换一个裁判模型重判，相关系数仍在 0.98 以上。视觉接地、证据锚定、收尾动作、时间窗口这几项承重结论，用的都是纯代码检查。

同期把 verifier 当软件制品的做法还有一个具体形态：每个应用配一组扩展接口，用结构化 JSON 输出断言与正反例。这跟 CLASHarness 的混合评分器是同一种思路的两个落地版本 OpenComputer。

图注：OpenComputer 中一个应用 endpoint 的接口规范示例。verifier 以可调用的接口形式暴露检查能力，输出结构化 JSON，包含断言、测试夹具与正反例。这是同期把 verifier 当成软件制品思路的一个具体形态，只展示接口样式，不是整体架构。OpenComputer

600 轮跑完，模型不是看不见冲突，而是收不了尾

把流水线跑起来之后，暴露出来的瓶颈集中在收尾与协调协议上，不在感知上。而且在这个场景里，想得越多反而越差。

15 个前沿模型各跑 600 轮，表现最好的 GPT-6 Astra 完整通过率 28.7%，平均检查得分 66.8%；最差的 Gemini 3.5 Flash 只有 3.0% 和 25.9%。这一组数字本身不算意外，真正的反差在于模型能通过 55% 到 67% 的单项检查，却只能解出 18.6% 到 28.7% 的完整任务。它们看得见问题，却收不了尾。

第一个瓶颈是视觉证据到底有多承重。把图片输入拿掉，换成纯文本，模型的表现塌到只剩原来的 11.1% 到 13.1%，这是在资产门控不显式的 254 轮上测到的相对保留率。也就是说，那批决定成败的事实真的藏在图里，不看图基本做不对。

图注：CLASHarness 的参数消融三联图。(a) 动作步数预算从 20 扩到 40 时通过率的变化；(b) 有视觉与盲测两组在全量、资产门控、非门控任务上的对比，盲测组只保留有视觉组 11.1% 到 13.1% 的通过率；(c) 换不同生成模型后模型相对排名保持一致。CLASHarness

第二个瓶颈是检测与解决之间的落差。在需要主动改变系统状态的冲突轮次，通过率从 28.1% 掉到 11.0%，对照组几乎没变，净差是 18.2 个百分点。这个数字的置信区间是 −29.1 到 −7.2，p 值 0.052，论文自己把它定性为倾向性证据，不是铁板钉钉。落差还有剂量效应，只做调查的通过率是 28.1%，推进协议掉到 12.3%，走完整个协议只剩 4.4%。

第三个瓶颈也是最硬的。收尾动作的失败率在 58% 到 72% 之间，时间窗口同步的失败率更高，落在 83% 到 97% 之间，而且这两组数字是跨被评估的 API 模型（十个 20 步模型）的分布。换句话说，需要释放共享锁、把任务交接给子智能体的那一刻，是当前前沿模型共同的塌陷点，而不是某几个弱模型的短板。

图注：跨失败模式的分组失败率，覆盖十个 20 步 API 模型与 3,284 条评分检查，按内容、视觉接地、结构协议三组能力桶组织。最右侧两条对应收尾动作与时间窗口同步，失败率带最宽。图上编码的是失败率而不是通过率，不能直接反推模型排名。CLASHarness

这个收尾瓶颈不是孤例。ROGUE 在受限资源访问的八个任务上发现，父智能体自己的违规率是 0，但交出去的指令没带上限制，子智能体的违规率却有 12% 到 50% ROGUE。Worse Together 在真实多人场景里也量到了类似形状，团队每次执行中出现越权改写的时间占比在 65% 到 77%，凭空编造信息占 53% 到 58%，论文同时声明这些只是高频现象，并没有证明它们是性能下滑的原因 Worse Together。

还有一处反常值得单拎出来：在这个任务里加大测试时算力是负收益。Gemini 3.5 Flash 把推理档位从低升到高，通过率从 13.5% 崩到 3.0%，因为推理 token 挤占了本来就不多的动作步数。在十个 20 步 API 模型里，升高推理档位只有 Gemini 3.5 Flash 被明确报告为显著变差（5 个提升、4 个持平、1 个下降），推理 token 占比与任务成功率的相关系数是 −0.70。跨六个冲突类别做统计，各模型也没有显著的领域偏好。

它把多智能体冲突变成可规模化评测的对象，但 20 个种子还撑不起分类级结论

这份基准确立了多智能体冲突可以被规模化、可验证地评测。但它首先给出的是一组方向性的瓶颈，还不是分类级别的定论。

把它放回领域图谱，能看出它站在哪。OS Agents 这份 ACL 2025 综述系统整理了操作系统智能体的平台、任务与评测维度，但它列出的开放挑战只有安全隐私和个性化自演化两项，没有多智能体冲突，而且覆盖截止在 2025 年初 OS Agents。这份清单的空白本身就是论点：CLASHarness 进入的是一个综述尚未看见的方向。

论文自陈的边界也需要认真对待。整份基准建立在 20 个种子乘 3 个变体上，每个单元格的样本量很小，覆盖最少的类别只有 20 个种子里的 1 个，所以六个类别之间的差异只能给出倾向，不足以支撑分类级结论。65.1% 的判分仍落在 LLM 语义判断上，即便有自洽与换裁判的重判兜底，整体通过率的上限仍受裁判噪声约束。15 个模型用的是论文内部代号，无法一一映射到公开版本。600 轮全部跑在 20 步的动作预算下，只有 GPT-6 Astra 用 40 步重跑过，所以顶级模型上检测与解决之间的落差，有一部分其实来自步数被耗尽。

用一句话收口：CLASHarness 的价值在于把「多个智能体抢同一块桌面」从工程吐槽变成了一个能批量生成、自动打分、可复现的实验对象，而它暴露出的收尾协议塌陷，目前看来是整个前沿梯队的共同问题，不是某一代模型的暂时缺陷。

想深入可以读原文：CLASHarness: Benchmarking Multi-Agent Conflict in Computer Use via a Controllable and Verifiable Generation Pipeline，arXiv:2610.19128

参考文献

• CLASHarness: Benchmarking Multi-Agent Conflict in Computer Use via a Controllable and Verifiable Generation Pipeline，arXiv:2610.19128
• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments，arXiv:2404.07972
• OpenComputer: Verifiable Software Worlds for Computer-Use Agents，arXiv:2605.19769
• ROGUE: Evaluating Corrigibility Failures in Frontier Computer-Use Agents，arXiv:2606.00341
• Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams，arXiv:2610.00583
• OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks，arXiv:2606.29537
• OS Agents: A Survey on MLLM-based Agents for Computer, Phone and Browser Use，ACL 2025