第二条，截图看界面，但在送给 LLM 之前先做一层处理，把界面元素的位置用边界框圈出来并标上编号，让 LLM 操作时说「点击 12 号区域」，后端再解析那个框的中心坐标执行实际点击。这个方法有个正式名字，叫 Set-of-Mark Prompting（SoM），是微软 2023 年发的论文。核心思路是用数字标记把视觉定位问题转化成符号引用问题，绕开模型直接预测像素坐标的不确定性。它相当于在截图流派里内嵌了一层 MCP 风格的收束，把「点哪里」这个开放问题压缩成了「选哪个编号」。
第三条，原生多模态，模型直接看截图，自己输出要点击的坐标，一步到位。这条路理论上最简洁，省掉了中间层，但对模型能力的要求很高。就实际观察来看，只有 100B 以上参数量的原生多模态模型做这件事才比较靠谱，Claude Sonnet 和 Qwen 的 35B 版本连按钮位置都经常找不准，原因不难理解，精确的空间定位本来就不是语言模型最擅长的事，参数量不够的时候，坐标预测的准确性会掉得很厉害。而且如果你界面里的控件很小的话，超大尺寸模型也容易点不中那个小 checkbox。
DOM 路线有一个显而易见的上限：它能告诉你界面上有什么元素，但没办法告诉你这些元素在空间上是怎么排列的。类 Excel 的复杂界面是个典型的例子，几十列、几百行的数据表格，哪一格是脏数据，单靠 DOM 节点的语义信息根本看不出来，必须结合位置关系才能判断。更麻烦的问题是，DOM 路线要求程序主动去做事件转发和接口适配，现在这个领域没有统一标准，也不是每一个开发者都有意愿欢迎 LLM 来操作自己的产品。强行适配一套不情愿的界面，开发成本很高，效果也未必好。
读图路线从原理上绕开了这些问题，它不需要对方配合，只要能截图就能操作，和人眼看屏幕没有本质区别。现在卡着这条路线的瓶颈主要是模型的空间理解能力，100B 以下的模型在坐标预测上不够准，但这个限制会随着模型迭代持续松动，不太像是一个结构性的死角。
读视频更进一步，时序信息可以让模型理解「做了什么之后发生了什么」，对需要观察界面动态反馈的操作场景理论上更合适。限制是成本，视频流意味着每秒若干帧全部进上下文，Token 消耗和 GPU 开销都是截图方案的几十倍，现在几乎没有人做得起，主流实现继续停在看图调工具的水平，视频方向还处于仅限媒体老师狂欢的范围。
但从趋势上看，随着推理成本持续下降、多模态模型的空间理解能力持续提升，读图和读视频路线比 DOM 路线有更宽的天花板。DOM 永远需要对方的配合，而屏幕永远在那里。
第三条，原生多模态，模型直接看截图，自己输出要点击的坐标，一步到位。这条路理论上最简洁，省掉了中间层，但对模型能力的要求很高。就实际观察来看，只有 100B 以上参数量的原生多模态模型做这件事才比较靠谱，Claude Sonnet 和 Qwen 的 35B 版本连按钮位置都经常找不准，原因不难理解，精确的空间定位本来就不是语言模型最擅长的事，参数量不够的时候，坐标预测的准确性会掉得很厉害。而且如果你界面里的控件很小的话，超大尺寸模型也容易点不中那个小 checkbox。
DOM 路线有一个显而易见的上限：它能告诉你界面上有什么元素，但没办法告诉你这些元素在空间上是怎么排列的。类 Excel 的复杂界面是个典型的例子，几十列、几百行的数据表格，哪一格是脏数据，单靠 DOM 节点的语义信息根本看不出来，必须结合位置关系才能判断。更麻烦的问题是，DOM 路线要求程序主动去做事件转发和接口适配，现在这个领域没有统一标准，也不是每一个开发者都有意愿欢迎 LLM 来操作自己的产品。强行适配一套不情愿的界面，开发成本很高，效果也未必好。
读图路线从原理上绕开了这些问题，它不需要对方配合，只要能截图就能操作，和人眼看屏幕没有本质区别。现在卡着这条路线的瓶颈主要是模型的空间理解能力，100B 以下的模型在坐标预测上不够准，但这个限制会随着模型迭代持续松动，不太像是一个结构性的死角。
读视频更进一步，时序信息可以让模型理解「做了什么之后发生了什么」，对需要观察界面动态反馈的操作场景理论上更合适。限制是成本，视频流意味着每秒若干帧全部进上下文，Token 消耗和 GPU 开销都是截图方案的几十倍，现在几乎没有人做得起，主流实现继续停在看图调工具的水平，视频方向还处于仅限媒体老师狂欢的范围。
但从趋势上看，随着推理成本持续下降、多模态模型的空间理解能力持续提升，读图和读视频路线比 DOM 路线有更宽的天花板。DOM 永远需要对方的配合，而屏幕永远在那里。
