AI智能体用软件为何卡壳：QGIS新旧版本实测33回合对11回合

2026年某天，一个AI智能体接到一项任务：打开QGIS这款地理信息系统软件，给世界各国GDP画一张分级地图。

它卡住了。当时用的是QGIS 3.10版本，要完成这个任务，得先读取177个国家的GDP数值，自行算出最大值最小值，再手动划出11个数据区间，还要挨个调用底层接口把渲染效果拼出来。33个回合过去，消耗了66万多个输入token，它依旧没做成，报错信息显示它传错了一个参数类型。

换成QGIS 3.44版本，同一个智能体只花了11个回合、3.6万token就完成了。原因在于新版本里有一个叫QgsClassificationFixedInterval的现成功能，一句调用就能把整个分级方案生成出来。

同一个任务，同一个AI，33回合对11回合。这不是AI变聪明了，而是软件本身在十几年的版本迭代里，已经悄悄把这件事变简单了。

这篇论文讲的就是这件事：软件进化原本是为了方便人类用户，结果顺带也让AI智能体更好用了。研究者们想问的是，软件要怎么长，AI才会用得顺手？

**

这事到底难在哪

**

如今的AI智能体正在成为一类新的软件使用者。它们不是人，却要像人一样打开Word写文档，打开Blender建3D模型，打开QGIS做地图分析。

问题是，这些软件的界面从来不是为AI设计的。

图形用户界面*：也就是我们平时点来点去的鼠标键盘界面，它假设用户能看懂屏幕上的按钮图标，能用眼睛判断操作效果。

软件开发包*：程序员用来调用软件底层功能的代码接口，它假设使用者能读文档、理解对象结构、会写代码调试。

命令行接口*：靠敲文字命令来操控软件的路子，形式上确实简单，可绝大多数桌面软件压根没提供通用命令行，即便有，覆盖的功能也相当有限，往往只能导入导出文件。

AI智能体正好卡在这三者之间，哪一套都不是为它设计的。走图形界面，它得一遍遍“看图识字”，猜按钮是干什么的；走开发包，它又得像程序员那样摸清对象模型，自己把底层调用链拼起来。界面于是成了AI干活的堵点，AI本事再大，界面不配合，任务照样完不成。

这就引出了研究者真正想弄清楚的问题：到底什么样的界面，才算是对AI智能体友好的界面？

**

把软件版本史当成一场天然实验

**

这个问题不好研究。如果研究者自己手工设计几种界面变体去对比，那本质上只是在验证自己脑子里的假设，并不客观。

研究者想到了一个巧妙的办法：软件的版本更新史，本身就是一场天然的、持续了十几年的“界面实验”。

同一款软件，核心功能这些年几乎没动过，QGIS依旧是画地图的，Blender依旧是做3D建模的。变的是界面层，也就是软件交给用户的操作方式，开发者一直在打磨它，原因很简单：人类用户总在抱怨“这个功能太难找了”“这步操作太麻烦了”。

研究者的做法是：任务定死、AI模型定死、判对错的裁判标准也定死，唯独换软件版本，这样一来，性能上出现的任何变化都能算到界面变化头上。

好比让同一个人去考不同年份的驾照考试，考题和考官标准都不变，只是车越来越新。通过率要是明显上去了，那多半是车更好开了，而不是人忽然开了窍。反过来，不控制变量，直接拿新手司机和老司机比，你分不清到底是车好还是人强。

基于这个思路，研究者搭建了一个叫DeskIF-Bench的评测基准*：是Desktop Interface Benchmark的缩写，意思是“桌面软件界面评测基准”，专门用来测试不同软件版本下AI完成任务的表现差异。

这个基准覆盖六款软件：办公软件Writer和Impress、矢量图形软件Inkscape、3D建模软件Blender、地理信息系统QGIS，以及CAD设计软件FreeCAD，横跨五个应用领域，办公、2D图形、3D内容、地理空间分析和计算机辅助设计。总共255个任务，每个应用至少30个任务。

每个任务都搭了一个自动判分脚本，专门核对AI最终产出的文件合不合要求。它不听AI自己说“我做完了”，而是走确定性的程序化检查，比如查文件里的具体数值对不对，或者在允许误差范围内比对图像像素。

**

版本越新，AI表现越好，但好在哪里

**

研究者用两个AI模型，DeepSeek V4 Flash和Claude Haiku 4.5，分别在每款软件的四个历史版本上跑了全部任务。

12组“模型+软件”的搭配里，最新版本的成功率无一例外都高过最旧版本，结果相当齐整。

进步最突出的是地理信息软件QGIS：DeepSeek从41%升到69%，Haiku从33%升到65%，两个模型都涨了近30个百分点。演示软件Impress同样提升19个百分点，由33%到52%。

研究者并未停在“版本越新越好用”这一步，而是翻进AI执行任务的完整记录，追问是哪些具体的界面改动带来了这些提升。

三个反复出现的属性由此浮出水面。

其一是可发现性*：软件界面能否让AI在运行过程中找到自己需要的功能，并把该功能怎么用、参数是什么意思讲清楚。

可发现性差的时候，AI只能到处翻文档，或者靠反复试错去猜某个功能该怎么调用。FreeCAD这款CAD软件的旧版本里，可复用的模型参数被藏在一个叫“别名电子表格单元格”的间接结构里；新版本1.0直接引入了名为App::VarSet的专门对象，参数变成一眼可见的属性。QGIS从3.10到3.44，平均每个函数的运行时描述文字量多了20%，参数含义、行为说明、使用示例都更齐全。

其二是颗粒度*：软件提供的操作功能与用户真正想做的事贴合得有多紧。颗粒度太粗，AI就得把一个简单目标拆成一长串底层调用，每多一步调用就多一次出错的机会。

QGIS处理工具箱里的操作数量从272个涨到440个，新增的不少是贴近真实需求的高阶操作。比如一个几何检查功能，过去要手动遍历每个要素的每个顶点逐一检查，新版本里一句调用就能完成。靠这类改进，Haiku在QGIS上的平均调用链长度从30.4步降到21.2步。

其三是可观测性*：AI改动软件里的某个状态之后，能不能用同样便捷的方式把状态读回来确认，也就是“写得进去也要能读得出来”。

三个属性里，只有它没有随版本更新而改善。研究者审查了581条AI自称“任务已完成”、实际验证却失败的执行记录，QGIS里有个很典型的例子：QgsFillSymbol.setAngle可以直接设置符号角度，却找不到对应的“读取角度”功能，想确认改没改成功，得深入到符号图层内部去扒。更极端的是QgsFeatureRenderer.setVertexMarkerAppearance这个设置功能，在四个评测版本里压根没有对应的读取功能。

好比一台洗衣机，你能设定水温，却没有仪表盘告诉你水到底烧到多少度，只能靠猜，或者伸手去试。这个问题不解决，AI执行完一个动作后根本不知道它产生了什么效果，只能假设“命令没报错就是成功了”。可命令本身执行成功，和最终达成用户想要的效果，完全是两件事。

**

ANIS：给软件现场“长出”一套AI专用界面

**

软件自然进化十年，才勉强改善两个属性，还有一个属性十年原地不动。研究者的下一个念头很直接：能不能不等软件进化，直接人工合成一套专门给AI用的界面？

这就是论文的核心方案ANIS，全称Agent-Native Interface Synthesizer*，直译是“智能体原生界面合成器”。说白了，它是一个框架，能自动给任何已安装的桌面软件“重新搭建”一套AI友好的界面。

ANIS分两个阶段干活。

第一阶段叫原子命令合成，在软件装好之后一次性完成。它从运行中的软件里挖掘能力线索：软件自带的注册操作列表（比如QGIS的处理算法、Blender的操作符）、通过代码反射探查出的对象方法和可写属性、以及软件菜单里暴露的用户操作。这三类来源各自都不完整，但凡能发现的都先收起来，宁可多收不要漏掉。

挖出来的功能并非个个都留。ANIS会实际在软件里把候选操作执行一遍，只保留能持久修改文件内容、或者能把文件状态读出来的功能，纯粹的运行时内部机制或临时状态会被过滤掉。

每个留下的功能，ANIS都会配一份统一规格的说明文档：参数是什么、合法取值范围、一个使用示例，再绑定一份已在软件里验证跑得通的具体实现。尤其要说的是，对每一个“写”类型的功能，ANIS都会去找有没有对应的“读”功能，有就一并暴露出来，从源头上补齐可观测性这块短板。

整个过程会生成成千上万条命令，直接堆成清单显然又会制造新的“查找困难”。所以ANIS按命令操作的对象分组：QGIS里所有关于“图层”的命令归一类，所有关于“布局”的归另一类。AI要用时先浏览分类摘要，再看某条命令的详细说明，不必把所有命令都塞进自己的记忆。

这套思路放到生活里也好懂。想象你刚搬进新房子，房东把说明书全扔给你，可说明书是按建筑施工顺序写的，水电气暖混在一起。想关掉卧室空调，得先翻遍整本。ANIS做的事，相当于有人帮你把说明书重新整理了一遍：按房间分类，卧室这页只讲卧室的开关怎么用，而且每个开关旁边都配了指示灯，告诉你现在是开是关。没有这层整理，AI每次操作前都要在一堆杂乱接口里“大海捞针”。论文里提到，AI会把24%到36%的输入token花在“找功能”上，原因就在这里。

**

第二阶段：让界面自己长出“高阶功能”

**

原子命令解决的是可发现性和可观测性。颗粒度这个属性有点特殊：软件该提供哪些“大招”级别的高阶操作，只有在真实使用中才看得出来，提前猜是猜不出来的。

于是ANIS设计了第二阶段，叫目标级命令。思路是：在原子命令被实际使用的过程中持续记录AI调用命令的序列，一旦发现某个子序列在不同任务请求里反复出现超过三次，就检查这些请求背后是不是共享同一个底层目标。确认是，就把这个子序列打包成一个全新的、有名字的高阶命令。

这里有一处很克制的设计。反复出现并不等于就是用户目标，也可能只是恰好用了同一套实现套路，背后的请求目的其实毫不相干。因此ANIS不会见到重复就打包，它要先确认这些序列确实指向同一个产出结果。

打包完成后还有最后一道关：在一份全新的文件副本上把这个新命令重跑一遍，看最终保存下来的状态对不对。只有通过这项复现检验，命令才会正式发布。

拿QGIS来说，做一张完整的打印版图原本要五步：建布局、加地图、加图例、加比例尺、加标题。ANIS发现这串操作反复出现，就把它收成一条命令，调一次就能走完五步。

好比厨房里常做的一道番茄炒蛋。起初每回都得切番茄、打蛋、热油、下蛋、下番茄、调味，六个步骤分开来。哪天你发现流程每次一个样，就把它写成菜谱贴在墙上，下回照着走一遍即可，不用再琢磨盐放多少。不这么做的话，每做一次同一道菜都得重新组织六个步骤，既慢，又容易漏掉一味调料。

**

实际效果如何

**

研究者在扩充后的368个任务上做了对比，测试集覆盖八款应用，三种界面方案同场竞技：软件原生开发包、已有的CLI-Anything方案，以及ANIS。

模型用的是DeepSeek V4 Flash。原生开发包整体成功率68.5%，每个任务平均烧掉8.44万token。CLI-Anything只有17.4%。研究者进一步拆解发现，它失败的任务里98.7%是因为根本没提供完成任务所需的命令，AI自己用错命令的只占1.3%。短板在覆盖面太窄，命令行这种形式本身没问题。

ANIS仅凭原子命令就把成功率提到72.3%，每个任务只花2.26万token，token开销省下73%。再加上目标级命令，成功率升到74.5%，token消耗2.12万，省了近75%。

换成Claude Haiku 4.5，趋势一模一样：原生开发包61.4%，ANIS原子命令64.9%，叠加目标级命令后67.4%。

有两款软件例外，FreeCAD和Blender上ANIS的成功率反而略低于原生开发包。研究者的解释是，这两款软件的操作之间存在大量隐性依赖，比如FreeCAD里的操作依赖关联的草图和建模特征，Blender的操作依赖场景中物体的选中状态和编辑模式。这类隐性前提不像QGIS那样参数一目了然，自动验证更难，所以原生开发包里有一小部分能力，ANIS没能合成出来。

研究者还做了一项消融实验，专门看可观测性有多要紧：让AI照旧用全套编辑命令，但不许调用任何读取状态的观测命令。整体成功率从72.3%掉到60.3%，少了12个百分点。

跌得最狠的是Calc电子表格软件，掉了30.3个百分点。研究者举了Blender的一个例子：任务要求把椅子转向面对桌子。能读状态的AI先读出椅子当前朝向，算出该转多少度，设置完再读一遍确认朝向正确，顺利过关。被禁掉读取的AI直接套用“旋转180度”这个常见操作，命令执行成功、没有报错，可椅子最终朝向垂直于桌子，验证失败。

这个结果挺扎心。AI光“能操作”远远不够，命令执行没报错，不代表任务真的完成了。就像闭着眼睛拧水龙头，龙头确实转了，水温调到多少度你压根不知道，直到伸手去试才晓得烫不烫。可观测性省掉的不是操作本身的工作量，而是那种“盲人摸象式操作”带来的巨大风险。

**

表格里的数字说明了什么

**

| 界面方案 | 整体成功率 | 每任务token消耗 |

|---|---|---|

| 原生SDK | 68.5% | 8.44万 |

| CLI-Anything | 17.4% | 6.70万(降21%) |

| ANIS原子命令 | 72.3% | 2.26万(降73%) |

| **ANIS原子+目标级命令** | **74.5%** | **2.12万(降75%)** |

这张表格背后藏着一个容易忽略的信号：成功率提升和token消耗下降是同时发生的。不是拿更多算力换更高准确率，而是用更

**

写在后面

**

读完这篇论文，让我最意外的不是ANIS这套合成方案本身，而是研究者拿软件版本史来做实验的思路。

我们平时把软件更新日志当成产品经理的碎碎念，这个版本修了什么bug、加了什么小功能，看过就忘。这篇论文却把十几年的版本更新史变成了一份档案，记录人类是怎么一点点把复杂软件变简单的。QGIS的处理工具箱从272个操作涨到440个，背后是无数真实用户在论坛上抱怨“这个功能太难用了”，然后被开发者听到、改进、沉淀下来。AI智能体现在能直接受益于这份人类几十年攒下的“易用性遗产”，这件事本身挺有意思。

还有一点我总在琢磨：可观测性。三个属性当中，它是十几年来唯一没能靠软件自身演进顺手解决掉的那个。这大概能说明，人早就习惯了盯着屏幕上的即时反馈来判断操作有没有生效，开发者自然也就没什么动力再单独做一套“用文字读出来”的接口。直到 AI 这种只认文本、压根没有视觉反馈的新用户冒出来，这个缺口才真成了非补不可的事。反过来讲，AI 一出现，就在逼着软件界面朝一个人类从来没真正需要过的方向走。

论文同样没回避遗留的难题：像FreeCAD、Blender这种靠隐性对象关系运转的软件，ANIS仍会丢失部分能力。原因在于，这些操作的前提条件埋在场景状态里，光凭参数描述没法自动摸清。下一步要追问的或许正是这一点：当一项操作"该不该做"取决于一堆看不见的隐性状态，自动化系统怎样才能像人那样"读懂上下文"？

Q&A

Q1：DeskIF-Bench评测基准是什么？它涵盖255个任务，覆盖六款应用、五个领域，做法是锁定任务和AI模型、只切换软件版本，以此观察界面变动对AI完成任务效果的影响；后来任务数扩到368个，应用增至八款。

Q2：ANIS框架具体做了什么？它负责为已安装软件自动生成AI专用界面，分两步推进：先是从运行中的软件里挖掘并验证可用功能，打成标准化的原子命令；再依据实际使用中反复出现的操作序列，合成层级更高的目标级命令。整体上，AI任务成功率被拉到74.5%，token消耗则减少约75%。

Q3：为什么AI用桌面软件原本的界面会表现不好？图形界面默认用户看得懂按钮，开发包默认用户熟悉代码和文档，命令行工具的功能覆盖又太窄，三类界面都不是给AI准备的。结果AI要么一遍遍试错去辨认界面，要么得自己拼出底层调用链，既容易出错，也吃掉大量token。