AI赛跑中的"路痴"困局：明尼苏达大学研究揭示AI智能体的致命短板

这项由明尼苏达大学双城分校、延世大学和Grammarly联合开展的研究，以预印本形式发布于2026年4月（arXiv编号：2604.10261），目前正在学术审议中。研究构建了一个名为"THE AMAZING AGENT RACE（AAR，神奇智能体竞赛）"的测试框架，用于系统评估AI智能体（即能自主使用工具完成任务的AI程序）在复杂任务中的真实能力。

你是否曾经把一件复杂的事情交给AI助手去完成，比如"帮我查一下苹果公司几位创始人出生地之间的海拔差是多少"？表面上看，这只是一个简单的问题，但实际上要回答它，AI需要先找到苹果公司的维基百科页面，从中提取创始人姓名，然后跳转到每位创始人的个人页面，找出他们的出生城市，再调用地图API获取坐标，接着查询每个城市的海拔数据，最后做一次减法。任何一个环节出了差错，最终答案就会完全错误。

研究团队发现，现有的AI测评体系几乎都在测试"简单直线任务"，就像让运动员在笔直的跑道上冲刺，却从不测试他们在复杂路线图中的导航能力。研究团队分析了ToolBench、ToolHop、GAIA等六个主流测试基准，发现其中55%到100%的题目都是简单的"A导致B，B导致C"这样的直线型任务，平均步骤只有2到5步。这就像把驾照考试简化成只在空旷停车场里停车，却从不考复杂路况中的判断。

于是，研究团队设计了一个全新的测试场景——借鉴美国著名电视节目《了不起的赛跑》的形式，让AI智能体在信息迷宫中进行一场真正意义上的竞速赛。这套测试共包含1400道题目，每一道题都是一个错综复杂的任务网络，而不是简单的单向链条。

**一、普通测试与真实挑战之间的鸿沟**

以往给AI出的题目，大多像是一张从A到B的单行路：先做这个，再做那个，最后得出答案。研究团队将这种结构称为"线性链"。比如"查询某公司成立年份，然后计算数字根"，这两步之间只有一条路，走通就行。

然而现实世界中的任务往往不是这样的。更接近真实情况的是一种叫做"有向无环图"的结构——这个名字听起来很复杂，但本质上只是说：任务可以"分叉再合并"。举个具体例子：假设你要同时查询法兰克福的海拔高度和周边大学数量，然后把这两个数字做差。这时任务从"查法兰克福位置"这一步分叉成两条并行的支线——一条去查海拔，一条去查大学——最后两条支线再汇聚到"做差"这一步。这种"一分为二、二合为一"的结构，研究团队称之为"钻石模式"。

测试发现，现有六个主流基准测试中，钻石模式这类非线性结构的占比极低，甚至有三个基准（ToolBench、ToolHop和GAIA）是100%纯线性的。TaskBench虽然理论上有一些分支结构，但实际上94%的题目仍然是直线，平均只有1.7个步骤。相比之下，这套新测试框架中每一道题都是真正的分支网络，平均包含22个节点，最多含有5个钻石分叉，而且整体线性比例为0%。

这就像是对比两种驾驶考试：一种只让你在直道上开100米，另一种则要求你在立交桥、环形路口、单行道和限速区组成的城市路网中完整行驶一圈。两者测试的根本不是同一种能力。

**二、这场"竞赛"究竟是怎么设计的**

每道题目被称为一条"赛程"（leg），由四部分组成：一个维基百科起点页面、一份包含K个线索的"线索信封"、一套19种工具的使用说明，以及一个步骤预算。AI要完成这条赛程，最终输出一个0到9之间的单个数字作为答案，就像赛跑中的终点密码。

线索信封是整个设计中最精妙的部分。它用迂回晦涩的文字描述每一步的目标，绝不直接说出维基百科页面的标题，也不告诉AI要用哪个工具。比如它不会说"请访问纽约证券交易所的维基百科页面"，而是会写"寻找那个位于大苹果心脏、主宰金融命脉的繁忙枢纽……"。这样设计的目的是防止AI直接从记忆中调取答案，强迫它真正去"导航"和"推理"。

赛程中的每个节点都有明确类型。"路线信息点"要求AI导航到正确的维基百科页面并提取特定信息，比如某机构的创立年份或某城市的人口数量。"路障"则要求AI执行多步工具调用，例如先用地理编码工具获取某城市的坐标，再用坐标查询海拔数据。"绕行"是对已获取数值进行数学变换，比如求数字根或找下一个质数。"终点线"则是把前面所有节点收集到的数值汇总计算，通过取模运算得出那个最终的单个数字答案。

工具箱中包含19种工具，分成抓取与搜索、谷歌地图系列、天气查询、Python代码执行、国家统计数据、股票数据和加密货币数据等八大类。其中地图类工具最多，包括地理编码、反向地理编码、附近地点搜索、地点评分、距离矩阵、海拔查询和路线规划七种。股票和加密货币工具会返回实时数据，确保AI不可能靠背诵答案过关，因为数据会随时间变化。

难度分为四个等级。简单级别的赛程在钻石增强之前包含3到6个节点，只有1个钻石分叉，信息提取仅需查看维基百科的信息框；中等级别扩展到7到12个节点，1到2个钻石；困难级别包含13到16个节点，需要跨越多个章节提取信息；极端级别则高达17到21个预增强节点，3到5个钻石，加上最深3跳的维基百科爬取深度。由于每个钻石分叉会增加3个额外节点（两条支线加一个汇合点），极端难度赛程实际平均达到33个节点。

**三、测试题目是如何自动生成的**

为了生成1400道高质量题目，研究团队搭建了一条八步自动化流水线，就像一家精密的工厂生产线。

流水线从"爬取"开始：系统从英语维基百科浏览量前十万的页面中随机选取一个作为种子，抓取该页面及其通过链接可到达的1到3跳范围内的页面，缓存所有信息框字段和正文内容。接着是"规划"步骤，用AI大模型根据难度参数规划一条有主题的路线，为每个节点生成提取提示。然后"构建"步骤将规划转化为具体的节点实例：路线信息点指定要从哪个页面提取哪个字段，路障节点从17个预设模板中选择并实例化，绕行节点指定具体的数学变换。

"预验证"步骤会在真实API上试运行所有工具调用链，剔除失败的链，并重新编排节点顺序。"链接"步骤通过链接跟踪或搜索查询将相邻节点连接起来。"增强"步骤插入钻石分叉模式，将线性链转化为有向无环图。"执行"步骤按照依赖顺序运行所有工具调用链，计算出每个节点的真实值和最终答案密码。最后"语言化"步骤将所有节点描述转化为迂回的线索文本，用婉转说法替代直接的维基百科标题，确保没有任何线索直接暴露页面名称。

只有当线索的"往返对齐分数"达到0.7以上，且线索隐含的答案与执行器计算出的答案一致，这道题才会被接受；否则直接丢弃重新生成。研究团队还通过四重机制确保题目不会被AI"背答案"蒙混过关：线索描述用婉转说法替代原始标题；路障答案依赖实时API数据；绕行变换产生的数值在维基百科中根本不存在；最终密码通过对程序化生成实例进行取模运算得出。

**四、谁来参加这场竞赛，成绩如何**

研究团队让三种AI智能体框架分别参赛，每种框架代表一种不同的"选手类型"。

Codex CLI是OpenAI开发的编程助手智能体，擅长自主规划和执行Shell命令，可以调用工具、写代码，并在出错后自行修正。Claude Code是Anthropic开发的类似工具，同样能自主规划、执行命令，并进行迭代式错误修复。Mini-swe-agent是一个轻量级版本的软件工程智能体，通过一种叫做"ReAct循环"的机制在bash终端中逐步执行工具调用。

在模型选择上，Codex CLI和Mini-swe-agent使用了OpenAI的GPT-5.4（旗舰级）和GPT-5.4-mini（经济型）两个版本；Claude Code使用了Anthropic的Claude Sonnet 4；研究团队还额外测试了一个120亿参数的开源推理模型GPT-OSS-120B，通过OpenRouter接入，专门测试"深度推理型"模型是否能在这种任务上表现出色。

所有参赛者都在同样的条件下竞争：在Docker容器中运行，每道题有600秒的时间限制，可以访问所有19种工具，工具输出超过8000字符会被截断。评判系统记录每个参赛者写入答案文件的数字，同时通过比对工具调用日志与标准执行轨迹来计算部分信用指标。

总成绩出来后，没有一个参赛者超过37.2%的正确率。做个对比参照：随机猜测一个0到9的数字，正确率应该是10%。最好的成绩也只比随机猜测高出约27个百分点，这个数字在1400道题的测试中听起来相当令人沮丧。

**五、三把尺子分别量什么**

研究团队使用了三个相互补充的评估指标，就像医生同时检查体温、血压和心率，而不是只用一个综合健康分数来判断病情。

"终点线准确率"（FA）是最直接的指标：AI写出来的数字是否等于标准答案？这是主要胜负判定标准。"补给站访问率"（PVR）则专门衡量导航能力：对于需要导航到的维基百科页面，AI实际访问了多大比例的正确页面？这个指标揭示的是AI是否走对了路，而不仅仅是最终是否到达终点。"路障完成率"（RCR）衡量工具使用能力：对于需要调用工具的节点，AI是否调用了所有应该调用的工具？这反映的是AI是否掌握了正确的技能，即便它可能在错误的地点使用了这些技能。

这三把尺子的组合让研究团队能够做出精准的"失败归因"。一个AI可能同时表现出高RCR和低PVR，意味着它非常擅长使用工具，但导航到了错误的页面，在错误的数据上做了正确的计算——这就像一个厨艺精湛的厨师，却把猪肉错认成了牛肉，做出来的菜在技术上完美，但食材就不对。

**六、数字背后的惊人发现**

研究的核心发现可以用一句话概括：AI智能体是出色的工具使用者，却是糟糕的导航员。

从错误分布来看，导航错误占据了所有失败案例的主导地位。在线性赛程测试中，随着难度从简单升至极端，导航错误率从5%急剧攀升至52%，而工具使用错误始终维持在3.5%到15%的低位。换句话说，到了最难的题目，超过一半的失败都是因为AI找错了页面，而不是因为它不会用工具。

在非线性（钻石型）赛程中，这个差距更加明显：导航错误率整体达到47.3%，比线性赛程高出16个百分点；而工具使用错误率反而降到了3.8%，比线性赛程还低5个百分点。这个现象出乎意料：更复杂的分支结构并没有让工具使用变得更难，反而因为钻石谜题提供了更明确的工具调用线索，工具使用反而更容易了。真正被钻石结构难倒的，是导航能力——面对更长的路线和更复杂的网络，AI越来越容易迷路。

智能体框架的选择比模型大小更重要，这是另一个出人意料的发现。Codex CLI加上旗舰模型GPT-5.4的组合得分37.1%，而换成轻量级Mini-swe-agent加GPT-5.4-mini组合只有26.1%，差距高达11个百分点。但Codex CLI加GPT-5.4和Claude Code加Sonnet 4的成绩几乎完全相同（37.1%对37.2%），尽管来自完全不同的公司和模型系列。框架之间的差距，比模型大小之间的差距更大。

工具使用能力上的差异部分解释了这个现象：Codex CLI的路障完成率达到65.8%，而Mini-swe-agent只有34.4%。Mini-swe-agent平均只走8到9步就提交答案，而Codex CLI平均走34到48步——Mini-swe-agent在没有充分验证的情况下就匆忙作答，就像一个学生做完前两道题就觉得整张卷子都做完了。

令人眼前一亮的是Claude Code的效率表现：它使用的Token数量（即处理文字的计算量）比Codex CLI少6倍（每道题约11.4万到22.5万Token对比140万到180万Token），却取得了相同的准确率。这说明在当前的AI智能体架构中，花钱越多未必表现越好——资源消耗和任务表现在很大程度上是解耦的。

至于那个120亿参数的开源推理模型GPT-OSS-120B，结果令人唏嘘：在线性赛程中只有3.1%的准确率，仅略高于随机猜测，比GPT-5.4低了足足12倍。原因并不是模型太小，而是它的"思考方式"不合适。这类推理模型会花大量时间在内部进行深度思考，结果在600秒的时间限制内平均只调用了2.2次工具（相比之下GPT-5.4调用了27次），几乎只完成了1轮有效的动作就超时了。在AAR的非线性赛程测试中，研究团队在测试了68道题后因为0%的准确率而提前终止了测试。深度推理对于需要大量浅层工具调用的导航任务来说，反而成了一种负担——就像用一台精密的天文望远镜来找丢在客厅的钥匙，工具本身没有问题，但场景根本不匹配。

**七、"捷径"现象与测试的真实边界**

研究团队还发现了一个颇为微妙的现象：在非线性赛程中，有14%到21%的正确答案是通过"走捷径"得到的——AI在只访问了不到30%的规定维基百科页面的情况下，依然给出了正确答案。在线性赛程中，这个比例是6%到11%。到了极端难度的非线性赛程，正确答案中有高达88%都是通过捷径达成的。

这些捷径并不是碰运气猜中的。走捷径的AI平均路障完成率达到43.8%，中间值准确率达到60.9%，比随机猜测高出3.5倍，说明它们确实在进行真实的工具链推理。它们的策略是：通过线索描述中隐含的地理或数值信息，直接推断出API调用所需的参数，绕过维基百科的导航步骤，直接完成工具调用。

这揭示了测试设计的一个结构性特点：在非线性赛程中，62%的标准中间值属于工具调用或计算节点，这些节点不需要访问任何维基百科页面就可以完成；只有38%的中间值真正需要从维基百科页面中提取信息。如果把走捷径的成功案例剔除，非线性赛程的实际准确率会从31%骤降到14%到17%，几乎回到随机猜测的水平。研究团队认为，在未来版本中应该设计更隐晦的线索表达方式，减少工具参数在文字中的泄漏，但这需要在"够难"和"仍然可解"之间找到平衡。

**八、失败是如何发生的——五种典型的"迷路"方式**

通过人工检查50个失败案例，研究团队归纳出五种典型失败模式。

第一种是"幻觉式规划"：AI写出了一堆看似合理的步骤和观察，但实际上根本没有真正执行任何工具调用，所有"数据"都是它自己编造的。第二种是"参数传递错误"：工具调用本身是对的，但上一步的输出没有正确地作为下一步的输入，导致整个工具链在传递数据时出了岔子。第三种是"终点线算术错误"：前面所有节点都做对了，但在最后的汇总计算中出现了失误，通过钻石汇合点聚合多个数值的过程尤其容易出错。第四种是"长途漂移"：在节点数量多的赛程中，AI逐渐偏离了正确路线，越走越远，最终完全迷失在错误的维基百科页面群中。第五种是"预算耗尽"：AI还没做完就用完了步骤配额，不得不提前放弃。不过这种情况相对少见，所有配置下步骤预算耗尽率均低于1.5%。

有一个具体案例很能说明问题：在一道极端难度赛程（36个节点）中，使用Codex CLI加GPT-5.4-mini的AI只访问了14个必要页面中的1个（补给站访问率仅为0.07），但却调用了所有应该调用的工具类型（路障完成率达到1.0）——它把正确的工具用在了错误的页面上。这个AI甚至在不同的错误候选页面之间反复自我纠正，但因为初始导航就偏了，越纠正越偏。如果只看最终的准确率数字，你会以为它一无是处；但分拆指标后才发现，它的工具使用能力其实是完美的，只有导航能力彻底失效了。这正是三指标分析框架的价值所在。

还有一个反向的有趣案例：一道35节点的极端难度赛程，AI只访问了11个必要页面中的大约1个（补给站访问率0.09），但最终正确给出了答案。它的策略是从起点页面出发，然后通过地图地理编码、海拔查询、周边地点搜索和Python代码执行等工具，在不访问维基百科的情况下正确计算出了80%的中间值，最终得出正确的终点密码。这个"工具捷径"案例展示了AI的一种创造性解题思路，但也暴露了测试设计中线索泄漏的问题。

**九、各工具模板的表现差异**

研究团队还分析了不同工具类型对最终准确率的影响差异。纯计算类模板表现最好，比如日期计算（平均准确率40.2%）和数学转换（33.4%），因为一旦AI拿到了输入数值，Python代码执行几乎不会出错。地理API类模板居中，比如地理编码+海拔查询（27.0%）和附近地点计数（28.1%），这类工具要求正确的地理定位，导航错误会直接导致工具调用在错误位置进行。最难的是需要精确参数格式的专业API，比如股票价格查询（18.5%）、天气查询（22.2%）和地点评分查询（22.5%），因为AI经常在股票代码格式、日期格式或地点名称精确度上出错。这个规律在所有四种智能体配置中保持一致。

说到底，这项研究做了一件很重要的事：它把"AI助手到底哪里不行"这个问题讲清楚了。以前我们只知道AI做不对某些复杂任务，但不知道是哪个环节出了问题。是不会用工具？是算数不好？还是别的什么？现在我们有了明确的答案：不是工具使用能力不行，而是导航能力太差。AI智能体在拿到正确数据后通常能做出正确的分析，但要让它自己去找到正确的数据源，在浩如烟海的网页中准确定位到目标页面，这件事对它来说远比我们以为的要难得多。

随着难度增加，导航错误率从5%飙升到52%，而工具错误率始终维持在个位数。更长的路线、更多的分叉，让AI越来越容易迷路。不正确的AI往往会越做越乱——它们平均比正确完成任务的AI多发出56%的搜索请求，多抓取18%的网页，但效果反而更差。问题不在于它们搜索得不够多，而在于它们搜索的方向一开始就错了，越努力越南辕北辙。

这对未来的AI开发者意味着：与其让AI搜索更多内容，不如提高它的精准定位能力；与其增加推理深度，不如在关键节点加入"我是不是走对路了"的自检机制；与其堆砌参数规模，不如优化智能体框架对导航任务的处理方式——毕竟Claude Code用六分之一的计算资源就做到了和Codex CLI相同的成绩。

这些发现对于任何正在使用或开发AI助手的人都有实际意义。下次你发现AI给出了一个看似工整但明显不对劲的答案时，不妨想想：它很可能不是"不会做"，而是"找错地方了"。对于这篇感兴趣的读者，可以通过arXiv编号2604.10261查阅完整论文，以及访问该项目在GitHub上的公开代码库，里面包含了所有1400道题目、标准执行轨迹和完整的评估代码。

Q&A

Q1：THE AMAZING AGENT RACE测试和以往AI工具使用测试有什么本质区别？

A：THE AMAZING AGENT RACE的核心区别在于引入了分支合并的网络结构，而不是传统测试中的简单直线链条。以往测试55%到100%是纯线性的，平均只有2到5个步骤，AI只需按顺序执行操作即可。而AAR的每道题都是真正的有向无环图结构，平均有22个节点，包含多个"一分为二再合二为一"的钻石分叉点，同时要求AI先自主导航维基百科找到必要信息，再调用外部API工具完成计算。

Q2：终点线准确率、补给站访问率和路障完成率三个指标各自测什么？

A：终点线准确率（FA）是最终的对错判定：AI写出的单个数字是否等于标准答案。补给站访问率（PVR）专门衡量导航能力：AI实际访问了多大比例的正确维基百科页面，反映它是否走对了路。路障完成率（RCR）衡量工具使用能力：对于需要调用外部工具的节点，AI是否调用了所有应该调用的工具，反映它是否掌握了正确的操作技能。三个指标合用才能精确判断失败发生在导航、工具使用还是最终计算哪个环节。

Q3：为什么深度推理模型GPT-OSS-120B在AAR测试中表现这么差？

A：GPT-OSS-120B的问题不在于模型能力本身，而在于它的"工作方式"和任务要求不匹配。这类推理模型会花大量时间在内部进行深度思考和规划，结果在每道题600秒的时间限制内，平均只完成了约2.2次工具调用，还不等它真正开始行动就超时了。相比之下，GPT-5.4在同样时间内平均完成27次工具调用。AAR这类任务需要的是快速执行大量浅层工具调用，而不是少量深度思考，深度推理模式在这里完全是一种反效果。