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

1. AI不会点按钮，这个尴尬怎么破

我估计不少人都经历过这个场景：大模型已经能写代码、写文章、做表格了，但让它帮你在某个系统里把报销流程走完——登录、进页面、找到对应入口、填单、上传附件、点提交——它就卡住了。模型再聪明，如果接不到屏幕上那些控件的"操作权"，它就只能停留在"纸上谈兵"的阶段。

这正是GUI-Agent（图形界面智能体）要解决的问题。它想让AI像人一样"看见"屏幕、"理解"界面、"操作"界面。这个方向最近讨论度很高，模型不只是输出文本，而是直接输出鼠标点击、键盘输入、页面滚动这样的动作指令，由工具或浏览器代为实现。说得直白点，AI终于从"会说话"进化到"会干活"了。

但如果只是"能操作"还远远不够。真要放到业务场景里，你大概率不敢让AI一上来就全自动操作，尤其涉及支付、审批、删除数据这类敏感动作时。于是就有了HITL（Human In The Loop，人在回路）这个设计。它把人放回执行链路中的关键节点，让AI操作、人来把关。阶跃星辰最近在GUI-MCP这个方向上做了不少落地动作，其中对HITL的拆分和处理很值得聊一聊。

这篇文章我尽量不写成术语堆砌的科普文，而是以一个实际在研究和评测这类系统的开发者的视角，把GUI-MCP到底解决什么、HITL在其中怎么设计、以及我自己跑测试时踩过的坑，从头到尾捋一遍。适合正在做Agent落地、或者打算给自己团队引入GUI自动化的朋友参考。

2. 阶跃星辰GUI-MCP的能力边界：它到底做了什么

2.1 先说清楚MCP在GUI场景里的定位

MCP（Model 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系统上，然后提交审批。"

整个过程大概是：

1. Agent先打开OA系统的登录页，识别出用户名和密码输入框。
2. 模型决策：输入用户信息和密码，点击登录。这一步通常属于"低风险动作"，可以自动执行，但如果是第一次登录或者系统有验证码，就需要人介入。
3. 登录后，Agent通过界面元素识别找到"新建申请"入口，点击进入。
4. 此时面对一个比较复杂的表单，Agent需要把Excel里的内容对应填进去。这一步对感知能力要求很高，如果表单是自定义控件（比如日期选择器、级联下拉），模型的识别准确率就会明显下降。
5. 填写完成后，点击"提交"之前，系统弹出确认框。这里就是HITL发挥作用的典型位置——弹窗提示用户"即将提交申请，是否确认？"。
6. 用户点击确认，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 Escalation）

Agent在运行过程中遇到无法判断的情况（比如识别置信度低于阈值）时，主动暂停并请求人工介入。人可以选择继续（告诉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)"，但屏幕缩放比例一变、窗口位置一变，这个坐标就失效了。更稳妥的做法是让模型输出"点击元素ID=submit_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方案好不好用，不能光看它单步操作有多快，还要看它在各种意外情况下能不能准确地把人拉回控制位——能在正确时机召唤人类、并且让人干预得舒服的系统，才是真正能上生产的系统。