刘芷宁最近社区里关于 GUI-Agent 的讨论一下子就多起来了，阶跃星辰把 GUI-MCP 这个方向摆到台面上之后，HITL（Human In The Loop）又被反复拎出来讲。我花了两周时间把整套链路拆了一遍，顺手在桌面环境里跑了一个带人工确认闸门的最小原型，今天把这阵子的观察、踩坑和理解一次性说清楚。
先说结论：GUI-MCP 的本质不是让模型“看懂屏幕”，而是把“看屏幕、想动作、动手做”这三件事结构化地拆给不同模块，再用一套标准协议串起来。而 HITL 也绝不只是“在关键步骤弹个确认框”，它是在承认模型还很稚嫩的前提下，让 GUI-Agent 能安全地走出实验室、进到真实场景的唯一务实路径。
1. GUI-Agent 突然变热，但绝大多数实现还处在“稚”期
1.1 一个真实的翻车现场，比任何趋势报告都说明问题
我在测试一个基于多模态模型的 GUI 自动化流程时，让它去桌面端飞书里找一个同事的会话，然后回复一句“方案晚点发你”。指令很清晰，模型也真的驱动鼠标移动到了左侧会话列表，甚至还点开了一个头像。但问题出在它点开的不是同事 A，而是置顶群聊里昵称和同事 A 高度相似的一个人。这一步错了之后，后续动作全部错位：它把文字发进了完全不相干的群，还顺手关掉了窗口。
这个翻车现场很典型，它暴露的其实不是“模型傻”，而是整个 GUI-Agent 链路里最容易被忽略的问题：单步准确率再高，长链路执行起来也是指数级放大的风险。假设每一步视觉定位准确率是 95%，一个包含 10 步的操作任务，全部走对的概率只有 95% 的 10 次方，约 59.9%。如果任务有 20 步，就只剩 35.8%。而真实办公场景里的 GUI 操作，30 步以上非常常见。
这就是为什么我特别反对看 Demo 视频就下结论，一个精心挑选的演示任务说明不了任何问题。GUI-Agent 真正难的地方，不是“能不能学会”，而是“能不能在没人盯着的时候持续不犯错”。在这一点上，当前几乎所有方案都还相当稚嫩。
1.2 为什么 2024 年下半年开始，大家都在做同一件事
GUI-Agent 并不是新概念，PyAutoGUI、RPA、UI Automator 这些工具都存在很多年了。但过去用规则脚本做 GUI 自动化，每个应用都要单独写一套选择器，页面改版脚本就废，维护成本极高。大模型出现后，大家看到了用自然语言替代脚本语言的希望，这个方向在 2023 年就有不少工作，但当时普遍遇到一个尴尬：模型能描述“我想做什么”，但接不上“我该怎么调系统能力”。
这时候 MCP（Model Context Protocol）出来了。它解决的是一个很朴素的痛点：如果每个 Agent 都要自己定义一套工具调用协议，那生态会被打散；如果每家都接 MCP，模型就能用一套方式去调用文件、数据库、浏览器、设计软件等外部能力。
阶跃星辰把 MCP 往 GUI 方向延展，做 GUI-MCP，本质上是把“图形界面操作能力”也变成一种标准化的 MCP 工具服务。这样上层 Agent 不需要关心目标应用是用 Electron 写的还是原生 Win32 写的，只需要通过 MCP 接口去拿屏幕结构、做定位、发动作。这件事的巧妙之处在于，它没有试图让模型变得更聪明，而是先把接口拉齐了。
1.3 “稚”字的三层含义，我越拆越认同
标题里那个“稚”字，我一开始以为只是笔误，后来反复琢磨，觉得它比“之”更贴切。当前 GUI-Agent 的状态，完全当得起一个“稚”字。
第一层稚，在模型。多模态大模型对 GUI 的理解类似一个刚入职的实习生：看得懂界面大概长什么样，但对业务上下文、页面层级、交互隐喻的把握非常浅。它能识别出“这是一个按钮”，但很难判断“这个按钮点了会不可逆”。
第二层稚，在数据和评测。GUI-Agent 还缺少像 NLP 领域 GLUE、SuperGLUE 那样公认的评测体系。今天各家 Demo 都是自己出题自己考，很难横向评估一个 Agent 的真实水平，这也给实际选型带来了极大的不确定。
第三层稚，在工程。屏幕坐标漂移、应用内元素识别不稳定、长任务上下文爆炸、操作回滚缺失，这一大堆工程问题都还没有形成行业共识级的成熟方案。这个阶段去谈“全自动”，多少有点勉强，厂商们心里其实也清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。