GUI-MCP与HITL：让AI真正“会干活”的人机协同实践

1. AI不会点按钮这个尴尬怎么破我估计不少人都经历过这个场景大模型已经能写代码、写文章、做表格了但让它帮你在某个系统里把报销流程走完——登录、进页面、找到对应入口、填单、上传附件、点提交——它就卡住了。模型再聪明如果接不到屏幕上那些控件的操作权它就只能停留在纸上谈兵的阶段。这正是GUI-Agent图形界面智能体要解决的问题。它想让AI像人一样看见屏幕、理解界面、操作界面。这个方向最近讨论度很高模型不只是输出文本而是直接输出鼠标点击、键盘输入、页面滚动这样的动作指令由工具或浏览器代为实现。说得直白点AI终于从会说话进化到会干活了。但如果只是能操作还远远不够。真要放到业务场景里你大概率不敢让AI一上来就全自动操作尤其涉及支付、审批、删除数据这类敏感动作时。于是就有了HITLHuman In The Loop人在回路这个设计。它把人放回执行链路中的关键节点让AI操作、人来把关。阶跃星辰最近在GUI-MCP这个方向上做了不少落地动作其中对HITL的拆分和处理很值得聊一聊。这篇文章我尽量不写成术语堆砌的科普文而是以一个实际在研究和评测这类系统的开发者的视角把GUI-MCP到底解决什么、HITL在其中怎么设计、以及我自己跑测试时踩过的坑从头到尾捋一遍。适合正在做Agent落地、或者打算给自己团队引入GUI自动化的朋友参考。2. 阶跃星辰GUI-MCP的能力边界它到底做了什么2.1 先说清楚MCP在GUI场景里的定位MCPModel Context Protocol本质上是一个模型和工具之间的标准化接口协议。以前各个Agent要调用工具每个工具都单独写一套适配逻辑换个场景就要重新接。MCP把工具封装成统一资源模型通过标准的调用方式去使用它们这让Agent的能力扩展变得像插U盘一样即插即用。GUI-MCP延用了这个思路但把工具聚焦在了图形界面的感知和操作上。用我当时看到阶跃星辰方案的第一感受来说它相当于给模型配了一副眼睛和一双手。眼睛负责看懂屏幕上有哪些元素、它们在哪、是什么状态手负责执行点击、输入、拖拽、滚动这些动作。而MCP在这里扮演的角色是让眼睛和手都遵循同一个标准来和模型通信模型不需要关心具体是用什么技术实现的屏幕解析也不关心鼠标和键盘事件到底怎么分发只需要拿到结构化的界面信息和动作反馈。这套设计的关键价值在于通用性。传统做法里如果要做网页自动化你得针对特定网页的DOM结构写选择器要做桌面软件自动化你可能要学专门的UI自动化框架。而GUI-MCP试图把这一层统一起来无论目标应用是什么模型看到的都是统一的界面描述执行的都是统一的动作原语。这就为Agent跨应用、跨平台操作打下了基础。2.2 阶跃星辰的方案里最有意思的部分说实话界面感知这一块已经有很多团队在做但每个方案的侧重点差别很大。阶跃星辰这个方案给我印象最深的是它对感知-决策-执行三层的明确切分以及把HITL作为一个一等公民设计进了这个流程里。这不是事后补一个暂停键而是在架构层面预留了人的介入接口。从技术链路来看大概是这样的感知层模型对屏幕截图进行解析识别出界面元素的类别按钮、输入框、下拉菜单等、位置坐标和当前状态可点击、已选中、禁用等。决策层根据用户的任务描述和当前的界面状态模型决定下一步做什么是填表单、点某个按钮还是先切换页面。执行层把决策转换成具体的操作指令click、type、scroll等由执行器分发到目标应用。反馈层每步操作之后系统获取新的界面状态判断上一步是否生效再决定下一步怎么走。HITL在这个链路里可以插入的位置并不只有一个。可以在决策之前要求用户确认计划可以在执行敏感动作之前要求二次授权可以在某一步操作失败后暂停等待人工接管。阶跃星辰的实现里给我的感觉是它把人工介入分成了两种完全不同的类型一种是审批式介入一种是救火式介入。前者是在动手之前让人确认后者是在执行出错或者遇到边界情况时联系人处理。这两种介入的消息格式和交互流程完全不一样分开设计是合理的。2.3 用实际场景理解GUI-MCP的边界为了让没接触过的朋友更直观地理解我举一个我实际测试过的例子。假设任务是把这个Excel表里的数据填写到公司的OA系统上然后提交审批。整个过程大概是Agent先打开OA系统的登录页识别出用户名和密码输入框。模型决策输入用户信息和密码点击登录。这一步通常属于低风险动作可以自动执行但如果是第一次登录或者系统有验证码就需要人介入。登录后Agent通过界面元素识别找到新建申请入口点击进入。此时面对一个比较复杂的表单Agent需要把Excel里的内容对应填进去。这一步对感知能力要求很高如果表单是自定义控件比如日期选择器、级联下拉模型的识别准确率就会明显下降。填写完成后点击提交之前系统弹出确认框。这里就是HITL发挥作用的典型位置——弹窗提示用户即将提交申请是否确认。用户点击确认Agent继续执行提交动作任务结束。这个例子里第2步和第5步是典型的HITL介入点。用户可以跳过第2步的确认因为可信任但第5步的提交动作最好保留确认因为一旦提交给错流程纠错成本很高。3. HITL在GUI Agent里绝不是摆设人的介入点设计3.1 为什么GUI Agent比纯文本Agent更需要HITL有时候我会听到一种说法HITL只是现阶段模型能力不足的妥协等模型强大了就不再需要了。我不太同意这个判断。GUI操作有一个天然特点——动作一旦执行就已经在真实世界里产生了影响它不像生成一段文字那样可以随便修改。你点错了一个按钮可能发出了一封不该发的邮件你输入错了金额可能提交了一笔错误的付款。模型的界面理解准确率不可能做到100%而且往往在特定场景下会出现系统性偏差。比如我遇到过的情况是某系统里下一步和提交按钮长得非常像模型的视觉识别连续好几次把提交认成了下一步。这种错误如果没有人盯着后果完全不可控。所以HITL在GUI Agent里的核心价值不是兜底而是授权。它让AI可以处理那些不需要人类判断的环节同时把需要判断和承担责任的环节保留给人。本质上是一种风险管理和责任划分机制——不是AI不够强而是人类需要保留对关键决策的控制权。3.2 按照干预时机划分的三类HITL模式我在实际设计HITL流程时习惯把人的介入按时机分成三类因为它们的实现难度和交互方式完全不同模式一操作前审批Pre-action Approval这是最朴素也最稳妥的HITL形式。Agent在执行某些动作之前先向用户呈现一个操作计划我准备这样做1. 打开某个页面2. 点击某个按钮3. 填写某些内容……请确认。用户确认之后Agent才开始执行。这种模式适合高风险、不可逆的操作比如提交订单、删除文件、发送消息等。它的缺点是打断频率高用户如果每个动作都要确认体验非常差Agent的自动化优势也会被大幅削弱。模式二执行中干预Mid-execution Intervention这种模式下Agent持续自动执行但用户随时可以介入叫停、改变参数或者接管操作。实现上系统需要监听用户的输入事件比如快捷键、鼠标移动一旦检测到用户的接管意图就立即停止Agent的自动操作把控制权交还给用户。这种模式的体验要好很多但对系统的设计能力要求高。比如怎么避免Agent的执行和用户的操作发生抢鼠标的情况我见过有的方案在Agent执行时会把鼠标输入锁定但一旦用户按下ESC键就解除锁定——这种方式简单有效但在某些场景下用户可能找不到该按哪个键。模式三异常时升级Exception EscalationAgent在运行过程中遇到无法判断的情况比如识别置信度低于阈值时主动暂停并请求人工介入。人可以选择继续告诉AI该怎么做或者终止任务。这是最自然的HITL形态也是目前GUI Agent落地时被用得最多的方式。这三种模式不是互斥的一个好系统通常会结合使用。阶跃星辰的方案给我的感觉就是把这三种模式都通了且有各自的配置开关用户可以按业务场景去调整介入力度。3.3 人的介入内容到底包含什么一个常见的误解是HITL里人的介入就是点一下确认/取消。实际上完整的HITL介入包含三个层次的信息。第一层是最基本的裁决允许还是拒绝对应的是二选一的判断。第二层是修正Agent的下一步动作不对人给出正确指令比如不要点这个按钮点右边的那个。这需要系统支持把人的自然语言转换成Agent可理解的指令。第三层是策略人不仅修正当前这一步还告诉Agent后续所有同类情况该怎么处理比如以后凡是遇到金额超过一万的操作都先暂停问我。这就涉及到把人的指示转化成Agent可以长期遵守的规则。如果系统只支持第一层那HITL的价值就大大缩水了——你只是让用户变成了一个批准按钮没有真正利用人的判断力。一个优秀的HITL设计应该允许用户在这三个层次上自由介入这样人机协同比单独靠人或单独靠AI都更高效。我自己在评估一个GUI Agent产品的时候会比较看重它是否支持策略层的介入反馈。因为实际业务中如果每个新场景都靠人反复做第二层的操作长期来看仍然很累。只有支持把人的判断沉淀成规则Agent才可能越用越顺手。4. 实操复盘从屏幕识别到动作执行的完整链路4.1 屏幕感知怎么做才靠谱GUI Agent的第一步是把屏幕变成结构化的数据。这个变的过程业界有几种不同路线基于无障碍信息Accessibility Tree从操作系统层面直接读取界面的语义化结构最精确但需要目标应用支持。基于UI自动化框架比如web场景下的Playwright/Selenium桌面场景下的WinAppDriver和无障碍路线类似通过注入探针获取元素信息适合已经支持自动化的应用。基于纯视觉解析模型直接看屏幕截图通过视觉识别定位元素最通用但对模型的视觉能力要求极高。阶跃星辰的方案走的是最后一类路线纯视觉为主融合无障碍信息作为补充。这个选型我比较认可——因为纯视觉的泛化能力最强不用依赖目标应用的技术栈而无障碍信息作为参考答案可以在视觉识别置信度低的时候做交叉验证。说一个我在实际测试中的感受纯视觉识别最大的问题不是找不到元素而是找到的位置不精确。比如一个列表项模型知道了它大概在这一块但具体它的可点击区域是哪里、和旁边元素的分界线在哪经常会有偏差。这种偏差在文字链接上不明显但在紧凑型的表格或者树形控件上一点错就是选错一行数据。一个有效的缓解手段是把截图放大到高分辨率再喂给模型或者对目标区域做局部裁剪特写。阶跃星辰的实现里应该也做了类似的处理因为从公开资料看它强调了对小尺寸界面元素的识别能力。如果你的落地场景里有大量的密集表格这一点要特别留意。4.2 动作执行器的设计怎么单击才可靠感知之后就是执行。这一步看着简单实际坑很多。首先是坐标和元素的对应。模型输出的动作如果是点击坐标(350, 480)但屏幕缩放比例一变、窗口位置一变这个坐标就失效了。更稳妥的做法是让模型输出点击元素IDsubmit_button由执行器再去定位这个元素而不是直接用坐标。这套语义化动作指令的好处是鲁棒性好坏处是实现复杂度高——执行器需要维护一个当前界面元素ID和物理坐标的映射表。其次是动作的时序。很多GUI操作不是单步的比如双击、右键、拖拽、点击后等待X秒再取下一步状态等。执行器需要支持这些组合动作还要处理动作之间的等待策略。一个常见的问题是Agent以为点击已经生效了弹出了一个确认框但页面的响应有延迟截图截到的是旧状态于是决策就基于错误信息进行了。这就是为什么真实系统里每个动作之后都要有一个状态确认的环节——但这一环也会大幅增加单步耗时。阶跃星辰的方案在这种细节上做得比较扎实。它的动作原语里包含了wait_for这类条件等待机制Agent可以声明等待当前页面出现XX元素后再继续。这个设计对复杂页面的操作成功率提升帮助非常明显。4.3 任务完成的判定你不能只靠最后一步没报错我见过很多GUI Agent的实现最后一步都止步于事件是否触发比如点击事件派发成功了就算完成。但这种判定在真实场景里根本不充分——按钮是点了但有没有弹错误提示数据到底保存没有页面跳到哪了好的做法是用一个独立的验证器在操作完成后重新扫描一遍界面对比任务目标里那些关键元素的状态变化来确认是否真正成功。比如提交完申请之后应该去验证一下工作流列表里是否出现了新的记录而不是只看有没有提交成功的Toast提示。4.4 HITL如何接入这条链路我在实现里推荐的接入顺序以下是我在项目里验证过的一套HITL接入方式介入层级触发时机推荐配置方式交互成本计划确认整体任务开始前高风险任务必开普通任务可关启动前一次性确认敏感动作确认单个关键动作前按动作类型白名单配置仅匹配规则时触发置信度阈值中断某个决策置信度低时可按任务类型调整阈值偶发执行过程快捷键接管随时始终开启极低实际测试下来我建议绝大部分场景默认开启置信度阈值中断而计划确认只保留给财务、数据删除这类敏感任务。否则用户很快就会觉得Agent干什么都要问我最终弃用。5. 工程化落地时绕不开的四个坑5.1 界面状态同步和信息时效性GUI Agent天然面临一个所见非所得的问题模型决策依赖的是某一次截图但真实界面在持续变化。网络慢一点页面加载慢一点模型看到的就已经是过时信息。我们在测试中就出现过Agent对着一个空白页面反复点击确定按钮的情况——因为截图时页面还没渲染完。这个问题的核心解法是引入界面状态机的概念把页面的加载、渲染、交互、反馈都建模成不同的状态Agent只有在界面稳定状态才允许进行下一步决策。实现上可以轮询检测关键元素的出现也可以用视觉特征比对来判断画面是否变化稳定。5.2 多步骤任务中的上下文丢失GUI Agent执行的任务往往很长——打开页面、登录、搜索、逐条录入数据、提交每一步都在改变界面状态。模型如果只依赖最新的截图会丢失任务最初的目标信息和前面的操作历史。反过来如果把所有历史截图都塞进上下文又会造成极大的token浪费和注意力分散。比较合理的方案是维护一个操作历史摘要不断用最新的几步操作和界面状态更新对当前任务状态的认知同时保留最初的目标描述。这本质上是一个记忆管理的问题。阶跃星辰的方案里应该有类似的设计因为它的长任务处理成功率看起来比同期其他方案稳定不少。5.3 验证码、登录墙和安全拦截只要GUI Agent要操作真实业务系统就绕不开登录、验证码、风控拦截这些数字围墙。很多Agent方案在Demo里跑得很好一上生产就挂在登录环节。我测试时发现处理验证码最有效的方式不是让Agent去识别而是让Agent在遇到验证码时调用HITL把控制权交给人类来处理。这样做有两个好处一是避免模型在验证码上浪费时间反复失败二是登录本身就是高安全敏感动作让人来接管这一个环节是合理的安全策略。5.4 反馈数据的结构性设计最后这个坑非常隐蔽但影响很大。Agent每执行一步操作后需要将界面状态、动作结果、置信度等信息回传给模型用于下一步决策。这个回传的数据格式如果设计得不好模型就会收到大量噪音。例如弹出一个和气业务无关的广告窗口模型要不要处理一个好的回传数据应该包含界面关键元素的当前列表、已发生的变化列表、异常弹窗标记、可选的动作候选集等。这些信息经过结构化提取后比直接丢一张大截图让模型自己分析要高效得多。我在跑性能测试的时候统计过这个差异结构化回传比纯视觉回传同样的任务平均少用了约40%的token成功率还更高。这应该也是业界GUI Agent的主流走向。6. 我的使用体验和一些建议6.1 实测下来哪些场景最适合先跑GUI-Agent基于我这段时间的实操体验GUI Agent包括阶跃星辰这套方案目前最适合落地的场景是那种流程固定、量大、但接口对接成本高的重复性操作。比如电商后台批量改价、CRM系统批量录入线索、财务系统批量审核单据。这类操作在传统方案里要么靠人肉点要么靠RPA写脚本但脚本的维护成本极高——页面一改版就废而GUI Agent通过视觉识别来对抗界面变化鲁棒性好很多。最不适合的场景是那些每一步都没谱的探索性操作比如让Agent去调研市场数据并汇总成报告。这种任务界面路径不明确、页面跳转充满随机性Agent很容易在某个页面上钻牛角尖人也很难在HITL环节给出高效反馈。6.2 设计HITL的几条原则第一介入成本必须足够低。如果用户确认一步要点击三次他很快就会产生对抗情绪。能一键确认的不要设计成两步三选。第二介入频率要和风险级别匹配。高频低风险的操作尽量不打断把HITL的资源留给那些低频高风险的节点。第三每一次介入都要有增量信息。如果HITL只是让人类重复确认AI已经很有把握的决策那这个设计是失败的。人的价值在于提供模型不知道的信息——比如业务规则、上下文背景、异常情况要把这些信息获取纳入HITL的交互设计里。第四要记录和分析每一次人工介入的原因。这些数据是优化Agent的宝贵素材。哪些类型的界面容易让模型困惑哪些业务规则模型经常不知道都可以从人工介入的日志里发现规律然后针对性优化提示词或训练数据。6.3 未来GUI Agent往哪个方向走我自己对这个方向的判断是GUI Agent还在快速演进期。短期内多模态模型视觉感知能力的提升会直接推动GUI-Agent可用性的天花板。中期来看各家会在跨应用协同上发力——不只是操作一个软件而是让Agent在不同系统之间搬运数据、转换格式、对照校验这才是它真正创造价值的地方。HITL的未来也会逐渐从人机切换走向人机共生。理想状态是Agent在能力边界内自主推进遇到不确定时主动向人类求助而人类只需要关注例外和决策不用时刻盯屏。这个状态下Agent就真正从工具变成了同事。我也希望大家在关注这类技术时多把注意力从模型参数和Demo效果转移到工程落地的细节上——准确率达到99%的AI在真正的业务场景里因为1%的差错带来的代价可能比不做自动化还大。而HITL的价值恰恰是把这1%的差错控制在人类可接受的范围之内。这套东西踩过坑之后我的体感是评定一个GUI-Agent方案好不好用不能光看它单步操作有多快还要看它在各种意外情况下能不能准确地把人拉回控制位——能在正确时机召唤人类、并且让人干预得舒服的系统才是真正能上生产的系统。