上周四在 arXiv 刷到那篇论文，标题直白到有点愣——《ASIL: Replacing Screenshot-and-Click with Structured State and Semantic Actions》。看到前三个词我第一反应是：又来了。这圈子每三个月准冒一篇"我们用 xx 替代截图点击"的稿子，大多数走到扒一遍 accessibility tree 就收工，拿十来个任务自嗨一把。但这回我把实验和训练部分从头翻完，之前那点轻蔑没收回来，反倒结结实实打了自己一个嘴巴。
ASIL 做的事一句话能说完：不让 agent 猜按钮在哪，把应用状态以 JSON 暴露给它，把能做的操作暴露成一个个语义动作。模型不用瞪着一张 1980x1080 的截图琢磨"打印"按钮是不是右下角第三个——它只需要查状态，当前开了哪几个 sheet、哪个在活动，然后调 setActiveSheet(2)。
听着普通到不值一提。可这恰恰是我们在 IDE 里白用了好几年、一出 IDE 就弄丢的东西。
在编辑器里让 AI 定位"第 42 行那个报错"，它是怎么知道第 42 行在哪儿的？靠的是 language server 给的结构化位置，不是拿像素点数的。终端里让 agent 自己去看 git 状态、再跟上一句 diff，这也顺畅——文本流这东西天生就是结构化的。回头看所有"AI 写代码真顺手"的瞬间，几乎全发生在工具自身给 agent 留了个干净接口的语境里；反过来，凡是得靠"看"的界面，它立刻退回成刚入职的实习生——不是能力问题，是你在拿一种它根本不适配的语言跟它交流。对着截图干活，它就迷；干错了，你还解释不清它错在哪儿。
截图不是给 agent 的语言。
论文里那组对比数字，我看完愣了一阵。修复过运行环境、给够了 50 步截图预算，截图-点击基线在任务集上的严格成功率只有 6.6% 和 26.6%——严格成功率，就是 UI 状态和期望状态逐字段比对、多一个少一个都算错的那种。往里挑那批难度能对齐到 OSWorld 的子任务，也就 15.0% 和 53.3%。反观 ASIL，闭源模型一路过了 80%，平均每个任务的动作数压到 5 以下。
不过公道话还是得说：这组对比本身给截图点击上了枷锁。50 步听着不少，但长程任务里点错一步往往得赔进去 3 到 5 步收拾烂摊子，预算基本有一半供在错误修复上；而且截图基线还是"环境修复过"的——真实世界的 agent 连这待遇都未必有。所以 6.6% 这个数的绝对值千万别当真，把它读成"像素世界在被额外关照的时候仍然打不过结构世界"就够了。真实环境的差距，只会拉得比这更大。
真正让我在桌子前停住的是下一段：他们拿 MCP 做了个对照，结果不是作者们期待的压倒性胜利，是打平。没赢，也没输。
对这个"打平"我想了很久。一种解释是：MCP 本身没错，它缺的不是协议也不是格式。它的问题在默认——MCP 默认资源是否暴露成 JSON 由每个 server 自己定，它没强求你产出结构化状态，于是大家就顺着懒下去，能塞 Markdown 就塞 Markdown，模型拿到手再去自己解析文本语义。说到底，这跟截图点击犯的是同一种病，只不过把"从像素里识图"换成了"从半结构化文本里猜语义"。ASIL 的贡献不是立了个新协议，是把"结构化状态 + 语义动作"这条早就写在大家心里的原则从落灰的角落捞了出来：不管外面套的什么协议，背后那个接口得能吐出真状态，才有得救。跟 MCP 打平也恰恰印证了这点——左右结果的是你决定信息结构的方式，走廊上那个信使叫什么名字，其实没那么重要。
至于拿 LibreOffice UNO 当原生 API 对照组这件事——我笑了一声。不是嘲笑，是惊。做 UNO 扩展的人听到这组对比大概率血压先上来：UNO 是出了名的"有接口，但不是给人类使的"——对象模型繁琐、类型嵌套得像迷宫、函数调函数，写过两年都还得随时翻文档。从它手底下赢出 28 到 38 个百分点，诚然，这个对照组本身选了颗软柿子捏。
整篇翻完训练实验，我反而觉得，比 80% 成功率更硬的东西在后半篇躺着。
Qwen3.5-2B，一个参数小到有点不像话的模型，做了规模很轻量的监督微调，成功率从 58.0 升到 72.1；9B 那个从 66.6 升到 80.4。之后补了一程预算不太富余的在线策略强化，两个模型又各自摸到了 74.4 和 82.2。
2B 参数打到七成以上，这份能力从哪来的？绝不是模型藏了什么跨时代智慧，是界面自己把复杂度咽下去了。把结构化到三百个字段的状态喂给 2B 模型，它只需要学会"在这段 JSON 里找出我要的那个字段"，然后机械地执行调用。换成截图，它得先从像素堆里识别出对应的 UI 元素，再估算元素和鼠标光标的距离——这一步连 70B 模型都做得战战兢兢，2B 基本可以宣告不可能。同行里喜欢争论"小模型到底有没有推理能力"，我的看法是，这恰恰演示了：接口够好的时候，推理量可以被压到极低，剩下的那点逻辑拿什么规模的模型跑都跑得动。很多所谓推理问题，根子其实是感知问题。感知被结构化消解掉之后，对模型能力的需求直接断崖式下跌。
代价当然有，而且不小。最致命的是接入门槛：一个应用想接这套层，必须先做一次系统性的接口暴露工程。画一张 JSON schema 只是开了个头——哪些状态值得暴露、哪些动作适合切成原子操作、每个动作成功后的状态更新会不会引入一致性问题，桩桩件件得有人拍板。整套干下来，工程量快赶上给软件认真写一遍官方 API。当年 Windows 软件大面没铺 accessibility tree 的时候，屏幕阅读器产品活得举步维艰，根子不在技术，在这类适配根本排不进普通开发者的优先级表。ASIL 撞的是同一堵墙。
但方向我认为没错。开头那个困惑——为什么 agent 出了 IDE 就集体变智障——答案在这儿被重新端了出来：是接口，不是像素。论文的功劳把这个答案从代码编辑器一路搬进通用软件的地界，还给了可复现的实验框架。这套东西将来会不会成活，谁也不知道，正经 paper 终局困在评审人记忆里的不在少数。但十五个应用、三百八十个任务，这份基准确确实实给所有声称"AI 能操作你的桌面软件"的团队立了把尺子。你完全可以不认同 ASIL 的每一个设计决策，却可以拿这把尺子先量量自家 agent 是真会操作，还是仅仅截屏截得漂亮。
画外音：以后谁再演示"AI 自动整理文件"，我就把这个链接甩过去，问一句：你打算让 agent 是怎么知道今天的下载目录里多了哪三个文件——靠猜么？
扯远了，拉回来。
要说我在这篇里最想抄进笔记的是哪一条，不是 80% 成功率，不是 2B 模型逆袭，是它定义动作的那一路线：把动作定义成"语义上完整的一次操作"，而不是"完成操作的其中一小步"。它平均每任务动作数压到五个以内，秘密全在这。对照一下截图-点击流那种"移动鼠标、点击、等待、再查找"的碎步走法，语义动作里的每一步都像一句人话。这反手照见的是我们天天在给 Claude Code 写工具函数的那些事：凡是需要 agent 靠思考加细碎计划自己拼接步骤的，都脆；凡是能封装成一句"抽掉这一页"的，就别让它自己右键去找"删除幻灯片"在第几个菜单。
给自己留一条执行规则：给 agent 设计接口，顺序永远是状态、动作、协议。先想它要看到哪些状态，再想它可以发出哪些动作，最后才去想外面这层壳用协议怎么包。顺序一旦倒过来——尤其是从协议该长什么样起步——那我几乎可以提前为那次返工默哀。
ASIL 就把自己放这样一个位置上：它点了一个我们早该认真看一眼的题。