香港大学团队造出史上最严苛AI助手考场：连顶尖模型通过率都不足50%，框架选择竟比模型本身更重要？

这项由香港大学多媒体实验室与美团联合开展的研究，于2026年7月以预印本形式发布，论文编号为arXiv:2607.08768。感兴趣的读者可以通过该编号在arXiv平台上查阅完整论文。

说到底，我们每天都在跟各种智能助手打交道——帮我查个机票价格、整理一下文件、看看这个视频里说了什么。这些事情对人类来说轻而易举，但对AI来说，真正在"真实世界"里完成这些任务，难度远比我们想象的大得多。而且更麻烦的是，过去我们根本没有一把好尺子来量AI到底做得有多好——直到这支香港大学团队拿出了他们的新工具：UniClawBench。

这个基准测试的核心雄心，是模拟真实用户真实场景里会遇到的各种麻烦事，然后看看AI助手能不能真正搞定。不是在实验室里"演练"，而是让AI进入真正能运行的电脑环境，打开真实的浏览器，操作真实的软件，处理真实的文件——然后看它究竟能不能交出合格答卷。

研究团队专门针对当前最先进的模型做了测试，结果让人颇为意外：即便是目前业界公认最强的闭源模型，在这个测试里的通过率也严格低于50%。这意味着，AI助手在应对真实世界任务时，失败比成功更常见。而更出乎意料的发现是，决定AI表现好坏的，并不主要是模型本身有多聪明，而是它被套进了什么样的"外壳框架"——这个结论，对整个AI应用开发领域都有不小的震动。

---

一、AI助手的"考场"为什么一直不够真实

在理解UniClawBench之前，先得明白过去的AI测试是怎么做的，以及它们为何总是差那么一口气。

考虑这样一个场景：你要测试一个厨师的烹饪水平，但你不给他用真正的食材，而是给他一批预先做好的"仿真食材"，让他做出来的菜必须和参考照片里一模一样。这种考法确实能测一些东西，但它根本没法判断这个厨师在真实餐厅里面对顾客的突发需求时，究竟能不能应对自如。

过去的AI智能体测试大多就是这个路子。它们通常把AI放进一个"沙箱"里——要么是自己搭建的仿制网站镜像，要么是预先截好的静态网页缓存——让AI在这个"人造温室"里完成任务。测试一结束，打开温室门，发现AI在真实互联网面前一塌糊涂。

除此之外，过去的测试还有两个更深层的毛病。第一，几乎所有测试都是"一锤子买卖"——AI执行一次，给个答案，完事儿。但真实用户跟AI助手的交互从来不是一锤子买卖。用户会看了结果说"不对，重来"，会补充新的要求，会纠正错误，会追问细节。这种来来回回的对话，才是真实人机交互的本来面貌，而过去的测试完全忽略了这一点。

第二个毛病更微妙也更关键：过去的测试把任务按"场景"分类，比如"购物类任务"、"办公类任务"、"旅游类任务"。这种分法方便统计，却完全没法告诉你AI失败的原因究竟在哪里。一个AI搞不定某个"办公任务"，到底是因为它看不懂图片里的表格，还是因为它把上文的要求忘了，还是因为它不会用Excel插件，还是因为它需要在Word和邮件之间传递数据却协调不了？这些完全不同的能力短板，在"场景分类"的框架下全都被糊里糊涂地混在一起了。

UniClawBench的诞生，正是为了解决这三个根本性的缺陷。

---

二、五项核心能力：给AI助手做"体检"的五张检查单

研究团队设计UniClawBench的第一步，是定义"一个真正能用的AI助手"到底需要哪些核心能力。他们把这些能力归纳为五大类，每一类都对应真实生活中一种具体的挑战。

第一类叫"技能使用能力"。这是指AI能不能正确地找到并使用专门的工具。举个例子，任务是把一张登机牌照片里的信息提取出来——这要求AI知道该用OCR（文字识别）工具，知道怎么调用它，并把输出的结果整理成你想要的格式。关键在于，正确答案不是靠"猜"出来的，而必须真正经过工具调用才能得到。如果AI凭记忆或常识编了一个看起来像的答案，测试系统会识破它。其他技能使用类任务还包括用Mermaid工具生成流程图、用SQL查询数据库、对Git仓库进行审计、处理音频转录，以及各种需要调用API的工作流。

第二类叫"探索能力"。现实世界里，很多任务的解法并不是摆在明面上的。比如一个任务要求你追溯某张图片或某个数据点的原始来源——你不知道该去哪里找，只能一步步试探、排除、推断。又比如要逆向工程一个没有文档的Web API，弄清楚它真正能返回什么数据。这类任务的难点不在于执行，而在于"发现正确的路径"。研究团队特别强调，这类任务要求AI留下探索过的痕迹——不仅要给出最终答案，还得展示它考察过哪些候选方案、为什么排除了它们。这样才能区分真正做了调查的AI和靠运气猜中答案的AI。

第三类叫"长上下文推理能力"。这类任务的难度不在于任何单个信息的复杂程度，而在于需要同时照顾大量散落各处的信息，并保持全局一致性。比如要综合YouTube、Bilibili上多个视频里的推荐，结合商品的实际价格和规格，才能做出购买建议。又比如要阅读大量邮件记录、发现其中的诈骗线索，或者追踪一个游戏局面在多轮之后的状态变化。这种能力的核心是"在庞杂的证据丛林里不迷路"。

第四类叫"多模态理解能力"。这类任务要求AI必须真正看懂图片、视频或音频里的内容——而不是靠猜测或文件名来推断。比如从一篇学术论文里找到某张特定的图表，然后用Python重新绘制出来；或者看YouTube视频里的烹饪教程，截取至少三张关键步骤的截图；或者识别冰箱照片里有哪些食材。只有那些真正依赖于视觉或听觉内容才能完成的任务，才被归入这一类。

第五类叫"跨平台协调能力"。真实工作中，很多任务需要在多个软件之间传递信息和状态。比如先读取一篇PDF论文，然后在Zotero（文献管理软件）里建立一条记录，导出BibTeX格式的引用，再在Obsidian（笔记软件）里创建一篇文献笔记，最后截图证明真正操作过这两个桌面软件——而不是只写了几个文本文件冒充。这类任务的关键在于，AI必须跨越软件的边界，在不同应用之间真正传递状态，而不是只在一个地方完成全部工作。

整个测试集包含400个双语任务（英文和中文各占一半），每种能力各有80个任务。所有任务都是根据真实用户的日常需求手工设计的，覆盖了软件开发、媒体娱乐、商业财务、旅行规划、消费购物、学术研究等11个应用领域，确保不会在某个特定场景上产生偏差。

---

三、"三角评审团"：一套防作弊的考试监督系统

任务设计好了，接下来的大挑战是：怎么评分？

过去的测试方法是预先写好标准答案，AI回答之后对比答案给分。但这在真实世界里行不通——今天亚马逊上的商品是199美元，明天可能变成179美元，预先记录下来的答案很快就会过期。更关键的是，如果告诉负责给用户反馈的"虚拟用户"什么是正确答案，那它就会不小心把答案提示给AI，相当于开卷考试，测试就失去了意义。

研究团队为此设计了一套他们称之为"三角色闭环评估"的系统，把评分过程拆分给三个完全独立的角色，它们各司其职、互不干扰。

第一个角色是"执行者"（Executor），也就是被测试的AI助手本人。它被放进一个隔离的Docker容器（可以理解为一个干净的虚拟电脑环境）里，面前只有任务说明和允许使用的工具。它不知道评分标准，也看不到任何参考答案，就像一个在考场里答卷的学生。

第二个角色是"监督者"（Supervisor），也就是隐藏的评分员。它能看到执行者的全部操作轨迹和生成的所有文件，同时还持有隐藏的评分标准和参考答案——这些是执行者永远看不到的。监督者用细粒度的检查点评分标准（Checkpoint Rubric）来打分：把每个任务拆解成多个步骤，每个步骤有对应的权重，监督者核查执行者的输出是否真正满足了每一个步骤的要求。最终，监督者输出一个结构化的判断：任务是"通过"、"失败"还是"可以继续补救"，同时给出一个0到1之间的分数。

第三个角色是"用户模拟器"（User Simulator），也就是扮演真实用户的AI。关键在于，用户模拟器只能看到执行者的可见轨迹和操作结果，以及监督者传来的一个极为精简的信号——仅仅是"通过/失败/可以继续"这样的粗粒度状态，完全没有评分理由或参考答案。然后，用户模拟器根据这些信息，生成一条自然语言反馈，就像一个真实用户在检查AI的工作成果之后说"这个食材清单还缺了几样东西，请补全"或者"截图里的步骤和视频对不上，重来"这样的话。

这套设计的精妙之处在于，评分标准和答案被锁在监督者那里，用户模拟器永远触碰不到它们，也就无法把这些信息泄露给执行者。这就像是：考试成绩由严格保密的评卷老师打出，但传达给学生的只有"你这道题做得不够好，重想想"，而不是直接告诉学生"第二小问应该写XX"。

这个多轮交互循环最多进行三轮——初始任务加上最多两次补救机会——最终的评分以执行者能达到的最高分为准。整个过程在真实的Docker容器环境里运行，容器里装有真实的浏览器、真实的桌面应用软件和真实的文件系统，没有任何事先缓存或预设状态。

为了验证这套自动评分系统是否可靠，研究团队从测试结果中随机抽取了50条轨迹，请三位人类专家独立评分。结果显示，自动系统与人类专家多数投票的一致率达到了92%，而打分的连续数值与人类平均分的相关系数达到了0.71——这表明这套系统虽然不完美，但已经相当接近人类评判者的水准。

---

四、三种"外壳框架"：同样的发动机，装进不同的车

研究团队不仅测试了不同的AI模型，还专门测试了三种不同的"智能体框架"——也就是把AI模型包裹起来、让它能够实际操作电脑的那层软件系统。这就好比同一台发动机，分别装进了三辆不同设计的汽车，看看在同样的赛道上，哪辆车开得更好。

三个框架分别是OpenClaw、EDICT和Nanobot，各自代表了一种不同的设计哲学。

OpenClaw采用的是"单一中央控制"的架构——整个任务从头到尾都由一个主AI来执行，所有的操作记录、工具调用结果和用户反馈都被保存在一条连续的上下文流里，没有中断，没有转交，信息不会丢失。这就像是一个厨师自始至终一个人完成一道菜，他能记得每一步加了多少盐、火候调过几次，不会因为"换了个人接班"而忘记之前做了什么。

EDICT采用的是"多智能体编排"的架构——类似于一个公司，有一个主管负责分配任务，由不同的子AI分别执行不同的子任务，通过类似看板（Kanban board）的机制传递状态。理论上这种方式能并行处理更多事情，但实际测试中暴露了明显的"协调摩擦"问题：子AI在传递状态时容易丢失细节，主管AI在长任务中容易忘记自己的角色和约束，结果往往是主管干脆自己把活儿都做了，而且用了大量的token（处理资源），却没有得到多智能体协作应有的收益。

Nanobot走了完全相反的路线，采用极简主义设计——尽量少用资源，保持核心轻量。在实际测试中，Nanobot消耗的输入token仅为OpenClaw的大约一半（以GPT-5.4为基础模型时，约0.57M对比1.15M）。然而这种极度精简带来了代价：在需要长链推理和完整轨迹记录的任务里，上下文信息不足，AI难以产生足够细粒度的推理步骤和支撑证据，最终通过率明显偏低。

---

五、测试结果：顶尖模型的"半途而废"困境

研究团队在OpenClaw框架下对10个当前最先进的AI模型进行了完整测试，结果图景既令人清醒，又颇有规律可循。

总体上，即便是表现最好的模型——Anthropic的Claude Opus-4.8和OpenAI的GPT-5.4——整体通过率也仅有47.5%和40.7%。换句话说，这些公认的顶尖模型，面对真实世界的任务时，失败依然是常态。这个数字有力地说明了现有AI助手与真正能干的"数字同事"之间还存在多大的距离。

更有意思的是一个被研究团队称为"半途而废现象"（halfway failure）的规律性模式。几乎所有模型都呈现出这样的特征：在任务进行到中间阶段时，它们能拿到相当高的分数，证明它们确实在一步一步地推进任务；但最终整体任务的通过率却要比中间阶段的平均分低得多。也就是说，这些AI助手能起个好头，中间做得也还可以，但最后总是在某个关键步骤上出了差错，导致功亏一篑。就像一个登山者，在到达山顶之前90%的路程都走得很好，却在最后几步时踩空了。

从五大能力的角度看，模型们表现出明显的分化。技能使用和探索这两类任务，相对来说表现较好——毕竟这两类任务的关键在于找到正确的工具或信息来源，然后正确地执行，这是当前AI模型比较擅长的事情。Claude Sonnet-4.6在技能使用任务上的通过率达到了51.2%，Claude Opus-4.8的探索任务通过率高达82.5%。

然而，长上下文推理、多模态理解和跨平台协调这三类任务，则构成了所有模型共同的重灾区。多模态任务尤其惨烈，即便是最好的模型，多模态任务的通过率也只有17.5%到21.2%。长上下文任务的最高通过率也仅有43.8%，且大多数模型都在20%以下徘徊。这说明当前的AI助手在处理需要"持续保持记忆"、"真正看懂图像"和"在多个软件之间协调行动"的任务时，依然面临根本性的瓶颈。

在开源模型与闭源模型的对比上，有一个令人印象深刻的现象：Qwen-3.5-Plus（阿里通义）和Kimi-2.6（月之暗面）这两个开源友好的模型，表现出相当强劲的竞争力——Kimi-2.6的整体通过率达到了36.2%，甚至超越了谷歌的Gemini-3.1-Pro。这表明开源领域正在以相当快的速度追赶过去由大型闭源模型垄断的高端能力。

---

六、框架比模型更重要：令人意外的发现

在三框架对比实验中，研究团队发现了一个对AI应用开发具有深刻实践意义的结论：**在决定AI助手的最终表现时，框架的选择产生的影响，比换一个更聪明的模型产生的影响更大。**

以GPT-5.4为例，使用OpenClaw框架时的整体通过率是40.7%，换成EDICT框架下降到33.8%，换成Nanobot则进一步降至29.0%。同样的模型，不同的框架，通过率相差超过10个百分点。而相比之下，在同一框架内，从一个较弱的模型换成更强的模型，带来的提升有时候还没有框架差异大。

这个发现意味着什么？它意味着，如果你在开发一个AI助手应用，花大价钱升级到更贵的模型，可能带来的收益远不如认真研究并改进你的智能体框架设计。框架决定了信息如何流动、任务如何分解、记忆如何维持、错误如何恢复——这些"管道和脚手架"级别的设计，直接决定了AI模型的真实能力能被发挥到什么程度。

从token消耗的角度也能看出各框架的差异。EDICT消耗了最多的资源，在Claude Opus-4.8下，每个任务平均需要2.15M输入token和42.7K输出token，分别是OpenClaw的大约2.8倍和2.6倍——但通过率却低于OpenClaw。这表明"烧更多资源"并不等于"做更好的事情"，多智能体架构的协调开销在很多情况下是纯粹的浪费。

多轮交互的价值也得到了量化验证。在第一轮执行后，模型的平均通过率约为23.8%；加入第一次用户反馈后，上升到29.5%；加入第二次用户反馈后，进一步上升到31.7%。虽然提升幅度不是天翻地覆，但这清晰地证明了多轮反馈机制是有实际价值的——让AI有机会根据用户的反馈进行修正，确实能帮助它完成那些第一次没做好的任务。

---

七、一道真题从头到尾：探索任务的完整故事

为了让人直观理解这套评估系统是如何工作的，研究团队在论文中详细展示了一道探索类任务的完整解题过程，这个例子非常能说明问题。

任务是：从美国国会图书馆（Library of Congress，LOC）的官方数据中，筛选出5条权利声明足够清晰、图像资源真正可访问的记录，并保存完整的证据文件。任务特别警告了几个"陷阱"：只有缩略图但无法访问完整图像的条目不算、集合级别的权利声明不能代替条目级别的声明、OCR文字条目不是图像等等。

第一轮执行中，AI先尝试用浏览器打开LOC网站，但遭遇了Cloudflare的反爬虫检测。它没有放弃，而是转换策略——直接调用LOC的JSON API端点绕过网页，并通过HTTP HEAD请求验证图像资源是否真的能访问。最终，它交出了5条记录和相应的排除记录文件。

然而监督者仔细核查后发现了问题：AI虽然搜索了25条结果，但它实际上按顺序取了前五条满足条件的——本质上还是"取前五条搜索结果"，违反了任务明确要求的"不要简单取前五条"。此外，排除文件声称排除了7条，但实际上只记录了1条；对一个特定条目的分类也有错误；对某两条相似记录的去重逻辑是靠断言而非证据支撑的。监督者判定：这是一个"有结论但结论不够有力"的状态，还有救，给出了continue（继续）的判断，分数0.65。

用户模拟器收到这个粗粒度信号后，只知道"任务没通过但可以补救"，然后看了AI的可见输出，生成了这样一条反馈："请重新验证结果，特别是排除文件只有1条记录但声称有7条、某条目分类有误、两条相似记录的去重逻辑看起来只是猜测这几个问题，更新文件使所有内容内部一致。"

注意，这条反馈里并没有告诉AI"正确答案是什么"，它只是指出了可见的不一致之处——这正是信息防火墙的效果。

第二轮中，AI重新为每一个候选条目拉取了官方JSON数据，在这个过程中还额外发现了两个连用户反馈都没提到的问题：一个条目的权利声明字段完全缺失；另一个条目实际上是数字化的卡片目录，根本不是图像。AI主动修复了这两个额外问题，最终重新生成了所有5个输出文件，排除列表也完整地包含7条记录，每条都有来自官方JSON的具体证据。

监督者二次评审后给出了0.96分，verdict：pass。整个任务以两轮完成，证明了多轮机制在帮助AI从部分失败恢复到最终通过方面的实际效用。

---

说到最后，UniClawBench做了一件听起来简单却很重要的事：它把AI测试从"温室考试"拉到了"真实考场"，从"一锤子打分"升级为"多轮对话评估"，从"场景分类诊断"进化为"能力维度诊断"。

这项测试揭示了当前AI助手两个最核心的软肋：一是在需要长时间记住大量信息的任务中容易"掉链子"；二是在需要真正理解图片、视频等非文字内容时力不从心。这两项能力的补足，可能是未来AI助手走向真正实用化的关键战役。

另一个值得反复咀嚼的发现是框架的重要性。当我们说"这个AI很厉害"时，我们其实说的是"这个模型加这个框架的组合很厉害"。模型的智慧需要框架来传导和放大，就像一台好发动机需要一辆好车才能展现真正的性能。这对AI开发者来说是一个很现实的提醒：与其追求更大的模型，不如先把脚手架搭好。

归根结底，这个测试只有400道题，还可以再多。真实世界的任务种类远比这丰富，实时网络内容的变化带来的评估稳定性问题也还没有完全解决，而用LLM来做评分本身也引入了额外的不确定性。这些局限研究团队自己也坦率承认了。但作为目前为止最接近"真实世界AI助手能力测试"的工具，UniClawBench已经提供了一个相当有价值的参照系。

有兴趣深入探索这项研究的读者，可以通过arXiv编号2607.08768查阅完整论文，研究代码和测试集也已在GitHub上的HKU-MMLab/UniClawBench仓库公开发布。

---

Q&A

Q1：UniClawBench与WebArena、OSWorld等已有AI测试有什么本质区别？

A：已有测试大多使用预先缓存的网页或搭建好的仿制网站，相当于在"人造温室"里考试，而UniClawBench让AI直接在真实的Docker容器里操作真实浏览器和软件，环境里的内容会真实变化。此外，UniClawBench引入了多轮对话机制，允许模拟用户给出反馈后让AI补救，而不是只评判第一次的结果。最关键的创新是它按能力维度而不是应用场景来组织任务，能精确定位AI失败的根本原因。

Q2：为什么UniClawBench的测试结果显示框架选择比模型选择更重要？

A：框架决定了信息在AI系统内部如何流动和保存。OpenClaw把任务的所有上下文保存在一条连续的轨迹里，信息不丢失；而EDICT的多智能体设计在子任务交接时容易丢失关键细节，Nanobot则因为太省资源而缺少足够的推理上下文。同一个模型，换一个框架，通过率可以相差超过10个百分点——这比换一个更强的模型带来的提升有时候还大。这说明智能体框架的架构设计是影响实际表现的关键工程因素。

Q3：UniClawBench测出的AI多模态理解能力为什么这么低？

A：多模态任务要求AI必须真正"看懂"图片或视频里的内容，而不能靠猜测或文件名来推断。在真实环境里，这意味着AI需要实时截取视频帧、识别食物图片里的具体食材、或者精确还原学术论文里某张图表的数据点——这些都需要视觉感知和工具使用的深度结合。测试结果显示，即便最强的模型通过率也只有约17%到21%，说明当前AI的视觉理解能力在复杂真实任务中远未达到实用水平，这也是研究团队认为的最重要能力瓶颈之一。