← 返回 PaperDaily 大模型与智能体

少花10倍算力！ASIL让开源小模型操作软件涨14个点

当Claude Code、Codex在代码世界里大杀四方时，GUI软件依然是智能体的"最后屏障"。上海交大与BIGAI提出ASIL，用结构化JSON观测+语义化代码动作替代截图点击，让GPT-5.4在380个任务上拿下81.6%的成功率，而同样的任务截图控制只有6.6%。一句话操作就能完成截图控制15次点击都完不成的活，这可能是智能体交互的一次范式革命。

龙哥读论文发布于 2026-09-02 00:20:00 阅读 4 查看原文

#Agent #大语言模型 #强化学习 #AI应用

paperdaily_reaction_gif

原论文信息如下：

论文标题:
ASIL: Replacing Screenshot-and-Click with Structured State and Semantic Actions

发表日期:
2026年08月

发表单位:
上海交通大学 X-LANCE实验室，北京通用人工智能研究院（BIGAI）

原文链接:
https://arxiv.org/pdf/2608.26991v1.pdf

项目链接:
https://sharryxr.github.io/ASIL/

一、智能体操作软件的新范式：从像素点击到语义操作

大家有没有想过一个问题：为什么AI写代码已经这么强了，但让它操作个办公软件、画个图、剪个视频还是那么费劲？

Claude Code、Codex这些代码智能体可以读代码库、跑命令、改文件、跑测试，在软件工程领域已经能独当一面。但一旦面对的是GIMP、Blender、LibreOffice这类图形界面软件，智能体就秒变"小学生"——它们需要模仿人类，先截图看看屏幕上有什么，然后决定往哪儿点、点几下。

上海交通大学X-LANCE实验室和北京通用人工智能研究院（BIGAI）的Rui Xie和Lu Chen，最近放了个大招：提出了ASIL（Agent-Software Interaction Layer），直接把"截图-点击"这套人类交互逻辑扔进了垃圾桶。

ASIL的核心思想其实特别朴素：既然软件底层本来就有结构化数据和可执行的逻辑，为什么还要让AI费劲去看屏幕上的像素？直接给AI一份结构化的JSON状态，让它用语义化的代码动作去操作软件不就行了？

图1：ASIL概览。传统GUI智能体被绑定在人类的截图-点击交互循环上，需要在不完整的像素表面做视觉定位，还要处理脆弱的马达动作序列。ASIL用软件状态的结构化观测和可执行的语义化代码动作替代了这一交互方式，通过文件、脚本和服务级别的访问路径，覆盖15个软件环境和380个基准任务。

ASIL概览。传统GUI智能体被绑定在人类的截图-点击交互循环上，需要在不完整的像素表面做视觉定位，还要处理脆弱的马达动作序列。ASIL用软件状态的结构化观测和可执行的语义化代码动作替代了这一交互方式，通过文件、脚本和服务级别的访问路径，覆盖15个软件环境和380个基准任务。

实验数据让人咋舌：在380个任务上，GPT-5.4用ASIL拿到了81.6%的成功率，而用传统的截图控制只有6.6%。双子星的sonnet4.6在ASIL下是81.2%，截图控制最好也就26.6%。这差距已经不是"优化"能弥补的了，完全是交互范式之间的鸿沟。

更恐怖的是，ASIL平均每个任务只需要执行不到5个动作，而GUI控制往往需要几十步甚至上百步。一句话的语义操作，顶得上人类操作员十五次小心翼翼的点击。

二、ASIL核心设计：结构化观测与语义动作的协议定义

为什么截图-点击对智能体来说这么低效？论文里给了两个层面剖析。观测层面：截图不是软件状态，只是可见像素的投影。隐藏的面板、后台进程、文档结构、内部元数据，这些任务决定性的信息，截图里根本没有。动作层面：GUI事件是坐标敏感的"马达级动作"，一个"给图层重命名"这种语义意图，展开之后是一长串依赖视觉定位的点击序列，换个主题皮肤可能就全崩了。

所以问题根本不是"让模型更会看屏幕"，而是软件操作智能体到底应该原生使用什么样的观测和动作接口。

ASIL的答案是：观测用结构化的JSON表示软件状态，动作用可执行的语义化代码操作。整套协议围绕四个设计原则展开：完整性（能看见可见表面之外的软件状态）、语义性（动作对应用户的软件操作意图而非GUI机制）、稳定性（标识符不随界面呈现变化而失效）、可组合性（复杂任务通过少量高层动作表达）。

图2：ASIL协议与运行时循环。ASIL将软件暴露为结构化观测和可执行的语义动作，然后通过规划、验证、记忆、重试和可检查的状态更新在同一JSON契约下闭环。

具体来说，智能体拿到的是一个包含六类信息的观测对象：任务元数据、应用状态、可交互元素、环境上下文、导航结构、以及一份精简的文本摘要。这些信息恰好是截图智能体最难恢复的：当前激活的是哪个文档、哪些实体可编辑、有什么后台条件影响正确性。

动作这一侧，ASIL定义了类型、目标和参数三元组，具体动作可以是修改结构化文件、执行原生脚本、调用服务端点、在内部拓扑中导航、或者触发批量操作。动作空间从"点这里"变成"把值设为多少"或者"调用这个函数"。一个语义动作可以封装一长串GUI序列，动作完成后的状态直接从下一个结构化观测中校验。

论文还给出了一个形式化定义：ASIL用观测函数Φ和动作空间A，替换掉原来的截图观测Pix和k步GUI动作序列。最关键的性质是，观测函数Φ在任务相关的子空间上近乎单射，而一个语义动作a等价于k步（k远大于1）的GUI马达动作序列。一步顶十步，效率和稳定性自然就上来了。

三、ASILization：如何把真实软件"接入"智能体

理念很好，但怎么落地？论文提出了一个半自动的"ASIL化"流水线。对每个应用，先找到最深的可行访问路径——最能稳定暴露软件状态和语义操作、同时实际可运行可评估的接口。最终的应用适配器实现一个统一的"观测-执行-验证"契约，让异构软件暴露同样的ASIL接口。

目前系统实现了三种反复出现的落地模式：文件级执行（解析SVG、ODF、notebook等结构化文件）、原生脚本执行（比如Blender的Python脚本接口）、服务/API执行（REST、WebSocket等）。15个应用中，6个走文件级，4个走原生脚本，5个走服务/API。

值得强调的是，JSON只是智能体面前统一的表示形式，并不要求软件原生存JSON。经过审核的文件解析器、脚本命令和API，都会把状态映射进同一个schema。这等于给不同的软件都接上了一个"翻译官"，让智能体用一套语言指挥所有软件。

一个应用要接入ASIL，需要至少暴露一条开放的读取路径加一条语义动作路径。对于大多数常见功能，总能找到至少一个符合条件的应用。但如果某个封闭软件的文件格式难以解包、又缺乏脚本和服务接口，那就只能留在ASIL的覆盖范围之外了。

论文里还展示了一个很有意思的数字：让GPT-5.4自动把一个97行的Gitea API文档编译成接口配置，只花了24.8秒，生成了一个观测视图和两个语义动作，零审计错误，3/3宿主机和3/3 Docker探针全部通过。这说明接入过程本身就在被AI自动化，以后给新软件"接ASIL"的成本会越来越低。

图7：实现路径。ASIL为每个软件环境选择最深的可行访问路径，同时保持统一的观测-动作协议；文件产物、原生函数和服务API都序列化为相同的可复用轨迹产物。

四、15个软件380个任务的系统化验证

为了验证ASIL不是只在一两个软件上有效，论文搭建了一个规模不小的基准测试：300个单应用任务加80个跨应用任务。单应用部分覆盖15个软件领域，每个20个任务，包括创意工具（Audacity、Blender、GIMP、Inkscape、Kdenlive、OBS）、办公套件（Draw.io、LibreOffice Calc/Impress/Writer）、开发环境（code-server、Gitea、JupyterLab）、文件与通讯（Nautilus、Thunderbird）。跨应用任务要求信息或产物跨越应用边界流动。

图3：基准覆盖与接口效应。基准覆盖15个单应用环境和80个跨应用工作流。主面板展示了来自GPT-5.4和Qwen3.6-plus基准结果目录中的代表性真实GUI截图；紧凑摘要展示了380任务联合评估中同任务ASIL与GUI的接口差距。

这里有个很细心的设计：基准实现为共享的评估系统，而不是分开的ASIL任务套件和GUI任务套件。相同的任务定义、初始产物、状态验证器和结果目录，在两种接口模式下共用。ASIL模式收结构化观测发JSON语义动作，GUI模式收截图发GUI事件动作。ASIL运行还会从软件状态渲染每步GUI快照，方便和截图驱动的GUI智能体运行做视觉对比。

评估器检查的是最终软件状态，而不是表面的动作历史。这个评估器在确定性执行、ASIL智能体运行、GUI运行、SFT数据筛选、RL奖励计算中被一致使用，保证了任务成功标准在软件层面可感知、可复现。

作者团队也坦诚地指出一个公平性问题：ASIL提示词里带有从评估器得到的文本成功提示，而GUI提示词只有任务说明。所以他们不建议把原始主表格的比较解读为纯粹的接口变量隔离。后文所有补充实验都是双方关掉提示再跑的。

这个基准搭建得相当扎实。300个单应用任务加上80个跨应用任务，覆盖了创意工具（Audacity、Blender、GIMP、Inkscape、Kdenlive、OBS）、办公套件（Draw.io、LibreOffice Calc/Impress/Writer）、开发环境（code-server、Gitea、JupyterLab）以及文件与通讯工具（Nautilus、Thunderbird）。每个单应用环境20个任务，跨应用任务则要求信息或产物在不同软件之间流动，考验的是智能体在真实工作流里的穿梭能力。
最有心的是评估器的设计。它不是看智能体做了多少步、有没有走到某个坐标，而是直接检查软件最终状态对不对。同一个评估器贯穿了确定性执行、ASIL智能体运行、GUI运行、SFT数据筛选和RL奖励计算，保证任务成功标准在软件层面可感知、可复现。ASIL运行还会从底层软件状态渲染出每步GUI快照，让两种接口模式在同一任务、同一验证器下做苹果对苹果的比较。

看表1就知道差距有多扎心。GPT-5.4在15步预算内用ASIL拿到81.6%的严格成功率，平均每个任务执行的语义动作不到5个。同样的任务，给GUI模式放宽到50步预算，GPT-5.4只拿到6.6%。sonnet4.6算争气的，修复后的原生电脑使用水平在50步下能到26.6%，可一旦预算缩回ASIL同款的15步，立刻掉到17.9%。

表1：主380任务基准结果。列头展示任务数量；完整区域成员见附录A。†GUI / 50max行为本轮修复后的原生电脑使用重测；GUI / 15max将相同的轨迹截断至15步。括号内为相对于对应ASIL基础模型的点变化；加粗和下划线分别标记每列最佳和第二佳分数。

细心的人可能会问：GUI模型是不是没调好？作者这轮确实下了功夫修复运行时、加长预算，还专门做了一个和OSWorld难度对齐的easy60子带。从表2能看到，即使在这个更友好的子带上，GPT-5.4的GUI成绩也只从6.6涨到15.0，sonnet4.6从26.6涨到53.3。跟ASIL的80+相比，依然是断崖式差距。

表2：Camera-ready校准结果（%）。上半部分：按任务带划分的修复后GUI / 50max结果。下半部分：匹配的原生接口基线，在相同任务、相同评估器、相同模型、15步预算且无成功提示的条件下运行。

更硬核的对比来自软件自带的自动化接口。论文把60个LibreOffice任务分别用ASIL和原生UNO API跑了一遍。UNO API是LibreOffice官方自动化接口，理论上暴露了完整的功能面，可结果让人意外：GPT-5.4用ASIL拿了95.0%严格成功率，用UNO只有66.7%；sonnet4.6更夸张，ASIL 98.3%对UNO 60.0%。ASIL比原生API高出28到38个点。这说明一个标准化、带约束的观测-动作契约，有时候比一个功能完整但低层次的原生API对智能体更友好。当然，也有打平甚至略输的场景——20个draw.io任务里，GPT-5.4的ASIL和MCP接口都是55.0%，sonnet4.6用ASIL只有25.0%、用MCP能到55.0%。作者没有嘴硬，明确说ASIL的定位是组合式贡献：一个统一跨应用的契约，而不是在每个特定应用上都要碾压原生接口。

图5：同一任务在GUI控制和ASIL控制下的对比。GPT-5.4在两种模式下运行libreoffice_19工资表任务；思考和动作从官方GUI与ASIL评估运行中逐字摘录。GUI运行识别出字面量制表符粘贴问题，但无法逃出低层级输入循环，在15个事件后失败；ASIL用一个modify_file动作直接写入电子表格状态并通过。

公平性方面论文也给了交代。GIMP上做了一个44任务的视觉补充消融：关掉成功提示、给ASIL每步额外喂截图，结果ASIL-only是44.1，加截图反而略降到43.7。这说明ASIL目前的瓶颈主要在感知动作词汇，而不是缺少截图信息。提示词本身的影响也量化了：balanced-30上，GPT-5.4带评估器提示是29/30，去掉提示是26/30，有3个点的水分。

五、训练效率的突破：小规模数据带来双位数提升

ASIL最被低估的价值，其实是训练侧。截图点击的RL回滚，每一步都要付视觉编码、多模态推理、GUI执行、状态等待、验证的全套费用；一个几十步的轨迹跑下来，成本高得让人肉疼。而ASIL的轨迹结构化和可验证，天然就是为训练准备的。

图4：ASIL轨迹作为可复用的学习产物。经过验证的ASIL观测、动作、产物和评估器结果可跨监督微调和评估器驱动的回滚训练复用。同一个闭环驱动两个阶段：SFT从重放和引导轨迹更新策略，而在线策略RL从回滚中更新策略，其奖励来自同一个ASIL评估器。两个阶段都在Qwen3.5-2B和Qwen3.5-9B上带来最终的380任务增益，且9B家族的训练增量在第5.4节报告的精选80任务硬套件上进一步放大3–4个点。

论文做了一个完整的训练闭环：先用GPT-5.4跑出验证过的ASIL轨迹，筛选出SFT数据；然后在一个带评估器奖励的在线策略RL环境里继续训练小模型。训练预算小得惊人——最终的SFT阶段只用了几千条step级别的ASIL样本，RL阶段用320个训练任务加80个验证任务，2B模型用4张A800，9B模型用8张A800。

结果非常提气。Qwen3.5-2B从58.0起步，SFT后直接跳到72.1，加上RL再进一步到74.4；Qwen3.5-9B从66.6起步，SFT到了80.4，RL到82.2。双双实现双位数提升。这还不是刷榜刷出来的虚高——论文单独做了一个80任务的硬套件，专门挑长时序、多约束、交付级质量的工作流，比如真实照片编辑、跨应用工件传递、办公和图表交付物。在这个更难的数据集上，9B的SFT和RL增益从主基准的+13.8和+15.5进一步放大到+17.1和+19.8，Multi-App得分从33.9一路涨到73.9再到77.2。

表3：ASIL / 15max模式下的留出80任务硬套件结果。区域细分（24个GIMP、12个Draw.io+LibreOffice、8个code-server+Gitea+JupyterLab、6个Nautilus+Thunderbird、30个多应用）和完整设置见附录A；括号内为相对于对应ASIL基础模型的点变化。表4：实现模式消融。面板（a）按模式A文件支持、模式B原生脚本、模式C服务/API实现将单应用任务分组；GUI / 50max行从本轮修复后的重测中重新计算。面板（b）在相同的60个LibreOffice任务上比较文件支持和脚本分发访问路径。

长时序工作流正是语义动作最能发挥价值的地方——低层级GUI轨迹容易在几十步里积累误差，最后一步错步步错；而ASIL把操作抽象成“设置这个值”“调用这个函数”，天然抗误差累积。不过也要泼盆冷水：2B模型在硬套件上，RL反而不如SFT（+3.6对+6.0），说明小模型在难度尾部的迁移并不均匀。训练收益，不是每个尺寸每个数据分布都通用。

六、局限与展望：哪些场景仍需GUI交互

ASIL当然不是银弹。它有一个硬门槛：软件得至少暴露一条开放的读取路径和一条语义动作路径。文件格式封闭、没有可解析结构、又缺乏脚本或服务接口的软件，ASIL就只能干瞪眼。论文对此也很坦白——覆盖范围是针对软件功能的，不是每个封闭产品都能进得来。

图6：ASIL下的代表性失败模式。每个面板将真实的硬套件任务指令与典型的思考/动作概要以及七模型硬套件评估中观察到的总体通过次数配对。移除截图定位后仍存在残余错误：真实照片编辑暴露访问路径限制，电子表格任务暴露数据覆盖缺口，Thunderbird则显示监督训练回归（RL后来恢复）。思考/动作片段从典型任务动作规范中缩写；总体通过次数来自硬套件评估报告（第5.4节）。表5：与邻近的智能体原生或程序化软件接口的契约级比较。该表比较的是文档化的接口维度，而非任务性能；LibreOffice UNO和draw.io MCP的匹配任务结果见表2。

从图6的失败模式来看，创意软件里的真实照片编辑是最大的集体短板，这暴露的是访问路径和数据覆盖的瓶颈，不是接口本身的锅。Thunderbird上还出现了一个有意思的现象：SFT阶段模型反而退步了，要靠RL才能找补回来。训练数据的质量和覆盖，依然是决定上限的关键。

那GUI会彻底退出历史舞台吗？大概率不会。一个很实在的理由：ASIL的运行本身需要渲染GUI快照作为人工审阅入口，这说明GUI在“给人看的界面”这个角色上依然有价值。另一个理由是，有些软件天生没有可编程接口，比如某些闭源设计工具，文件格式解不开、没有脚本、没有服务端，这时候截图点击是唯一的人机通道。

真正的未来大概率是分层的：能钻到最深访问路径的场景用ASIL语义动作；必须看像素的视觉本质任务保留GUI；中间地带由统一的验证器接住，不管智能体走哪条路，最终对错都由软件状态来判断。论文里那个24.8秒把Gitea API文档变成可用接口配置的案例，已经预示了接入流程本身的自动化趋势。软件-智能体交互的接口，正在从“模拟人的操作”走向“直连软件的本体”。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？上海交大与BIGAI提出ASIL智能体软件交互层，用结构化JSON状态和语义化代码动作替代截图-点击操作范式，在380项任务中达到80%以上成功率，且平均仅需不到5个动作。

这篇工作最值得看的点是什么？ASIL在380任务基准上达到80%以上严格成功率（GPT-5.4: 81.6%，sonnet4.6: 81.2%），而修复后的GUI模式仅达6.6%和26.6%；ASIL超过LibreOffice UNO API 28-38个严格百分点，与draw.io MCP持平；小规模SFT和RL训练使Qwen3.5-2B从58.0提升至74.4，Qwen3.5-9B从66.6提升至82.2

这篇工作的边界或风险在哪里？优点：(1) 提出全新的智能体-软件交互范式，从根本上解决截图-点击的低效问题；(2) 系统化实现方法论，覆盖15个应用，具有良好泛化性；(3) 训练效率显著提升，小规模数据即可获得大幅增益；(4) 实验设计严谨，包含多种对比基线和有效性验证。缺点：(1) 对完全封闭的软件（无文件、脚本、API访问路径）无法适用；(2) 对需要像素级感知的任务（如真实照片编辑）仍有局限；(3) 主基准ASIL提示包含评估器提示，与GUI提示不对称；(4) 2B小模型在长时任务上RL稳定性不足

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★★

把GUI智能体的困境重新定义为接口问题，用结构化观测替代像素观测、语义动作替代GUI事件，干净利落的范式级贡献。

实验合理度：★★★★☆

380任务共享验证器、修复GUI基线、原生接口对比、提示消融，对比设计较扎实。主表存在提示词差异，但作者主动披露并做了大量校准实验兜底。

学术研究价值：★★★★★

把代码智能体的成功经验系统性迁移到GUI软件，并给出完整评测和训练方案，后续围绕“智能体该用什么接口”的研究都会被这篇工作锚定。

稳定性：★★★★☆

语义动作天然隔离布局和主题变化，稳定性远高于坐标点击；但依赖软件是否开放可编程接口，封闭场景无法保证。

适应性以及泛化能力：★★★★☆

15个应用三种实现模式加上跨应用任务，覆盖面可观；但真实照片编辑和封闭软件仍是盲区，泛化到任意软件还有距离。

硬件需求及成本：★★★★☆

推理侧每任务不到5个动作，成本远低于长轨迹GUI；训练侧SFT几千样本、RL 320任务加4/8张A800，对小团队也很友好。

复现难度：★★★★☆

项目页面已放出，15个应用的适配器配置、训练设置和评测流程都有文档；但部分适配器开发和任务设计仍有人工审核环节，完整复现需要一定工作量。

产品化成熟度：★★★★☆

在RPA、办公自动化、跨应用工作流等场景已经具备落地条件；但覆盖范围仍集中在开源或可脚本化软件，面向大众商业软件的广度和稳定性还需要工程打磨。

可能的问题：主表ASIL提示词含评估器成功提示而GUI侧没有，接口变量未完全隔离；后续校准虽然做了大量弥补，但公平性问题仍是评审焦点。2B模型在硬套件上RL不如SFT，训练收益的普适性需要更多验证。适配器开发和任务审核仍有人工环节，规模化接入的真实成本被低估。

主要参考文献

[1] Xie R., Chen L. ASIL: Replacing Screenshot-and-Click with Structured State and Semantic Actions. arXiv:2608.26991, 2026.

[2] ASIL Project Page. https://sharryxr.github.io/ASIL/

[3] Yang J. et al. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS 2024.

[4] Wang X. et al. CodeAct: Executable Code as a Unified Action Space for Language Agents. arXiv:2402.01030, 2024.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！