一天跑完十年软件更新，AI智能体用上了专门为自己设计的界面

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作为AI模型测试，原生开发包的整体成功率是68.5%，每个任务平均消耗8.44万token。CLI-Anything的成功率只有17.4%,研究者进一步分析发现，CLI-Anything失败的任务里98.7%是因为它压根没提供完成任务所需的命令，只有1.3%是AI自己用错了命令,说明它的短板在于覆盖面太窄，不是命令行这种形式本身不行。

ANIS光靠原子命令就把成功率拉到了72.3%，每个任务只消耗2.26万token，相当于省了73%的token开销。再叠加目标级命令之后，成功率进一步涨到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评测基准是什么？

A：DeskIF-Bench是一个包含255个任务的桌面软件界面评测基准，覆盖六款应用五个领域，通过固定任务和AI模型、只改变软件版本的方式，来研究界面变化对AI完成任务效果的影响，后扩展至368个任务覆盖八款应用。

Q2：ANIS框架具体做了什么？

A：ANIS是一个能自动给已安装软件生成AI专用界面的框架，分两阶段工作：先从运行中的软件挖掘并验证可用功能，打包成标准化的原子命令；再根据实际使用中反复出现的操作序列，合成更高阶的目标级命令，整体可将AI任务成功率提升到74.5%，同时token消耗降低约75%。

Q3：为什么AI用桌面软件原本的界面会表现不好？

A：因为图形界面假设用户能看懂按钮，开发包假设用户懂代码和文档，命令行工具功能覆盖太窄，这三类界面都不是为AI设计的，导致AI要么反复试错识别界面，要么要自己拼接底层调用链，容易出错且消耗大量token。