换个宇宙1. 先说清楚：GUI-MCP 和普通 MCP 到底差在哪
1.1 MCP 最初解决的，是“给模型发工具”的问题
MCP（Model Context Protocol）这名字听起来很学术，拆开看就是给大模型统一发“工具清单”的接口规范。以前要让外部工具跑一遍，你需要针对每个平台写一套私有 function calling 格式。MCP 出现之后，工具变成了统一的 JSON-RPC 服务，模型拿到服务端暴露的资源列表和工具列表，按 schema 调参、执行、拿回结果，形成闭环。
这个环节里，工具粒度通常是一个可编程函数：查天气、查订单、算运费、生成图表。模型只需要知道“我要调哪个函数，传什么参数”，剩下的由服务端执行。对模型来说，真实世界的界面是透明的——只要函数封装好，模型不必理解前端按钮长什么样。
1.2 GUI-MCP 把工具粒度从“函数”变成了“界面操作”
GUI Agent 的思路完全不同，它不依赖对方系统是否开放 API，也不依赖函数是否精心封装，而是直接面对用户的图形界面。模型看到的是屏幕截图、可访问性树（Accessibility Tree）、窗口句柄这一层原始信息，输出的动作是“点击这个按钮”“把文本框内容清空再输入”“滚动到列表底部”。
如果说 MCP 是给模型配了一套“遥控器”，GUI-MCP 就是让模型真正上手去“握鼠标”。两者的差异不仅是操作精度问题，更是抽象层级的问题：MCP 让模型调用抽象功能，GUI-MCP 让模型在像素级/控件级信息上重建任务语义。这也是为什么它比普通 MCP 更容易让使用者感到“智能”——它不是在调接口，它是在模仿你操作电脑。
1.3 阶跃星辰在这个链条里的位置
阶跃星辰做 GUI-MCP 的产品思路，从公开信息看，是把多模态大模型的视觉理解、GUI 操作规划、以及 MCP 工具调用能力组合成一套面向终端的 Agent 方案。标题里括号中断的位置，很可能是某个具体模块或场景的占位——桌面端自动化、浏览器操作、手机端智能助理都有可能。
它跟普通 GUI Agent 的区别在于：通过 MCP 标准把界面操作能力开放成服务，给外部 Agent 调用。别人不需要重新训练一个模型，只要通过 MCP 客户端接进来，就能复用它的 GUI 理解能力。这是标准先行的生态化打法，也是最近各家 Agent 产品都往 MCP 上靠的原因。
这里先说一个判断：GUI-MCP 的难度不在“让模型会点击”，而在“让模型知道该在什么时候点击、什么时候不点”。后一半问题，刚好引出 HITL（Human In The Loop）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 拆开看 GUI-Agent 的三大构成模块
2.1 界面感知层：从截图到结构化 UI 树
第一层是感知。模型必须知道自己面对的是怎样一个界面状态。目前主流方案有三种：像素级截图、OCR 文本、以及可访问性树。
- 像素级截图：最接近“人眼看屏幕”，信息最全，但噪声也最大。模型要自己判断哪些区域是弹窗、哪些是背景、哪些按钮是禁用态。
- OCR 文本：只提取可见文字，减少视觉歧义，但丢失了控件的位置关系和层级。
- 可访问性树：效率最高，能直接拿到按钮的语义、坐标、状态，但依赖系统或浏览器暴露的信息。某些自绘控件（比如 Canvas 渲染的表格、桌面端自绘皮肤按钮）会退化成一整块图，语义信息全丢。
一个可用的 GUI-MCP 服务端，通常不会只用其中一种，而是把三类信息融合成统一的状态描述。举个例子：可访问性树给了元素层级和 button 的 role，像素截图负责补全视觉上下文（比如知道这个 button 是一个红色的危险操作按钮），OCR 负责兜底，处理那些没有暴露到 a11y 树里的文字内容。融合之后按层级传给模型，模型推理时既能看到“屏幕上有什么”，又能知道“哪些区域可以交互、交互后果大概是什么”。
2.2 任务分解层：把目标变成操作序列
拿到界面状态之后，模型需要把用户的长目标拆成短动作。这一步本质上是多步规划问题，也是当前 GUI Agent 准确率最不稳定的一环。用户说“帮我完成这个报销单”，系统需要决定：先打开哪个页面、第一步点哪个菜单、是否要填写金额、填完要不要点提交。
这里有个很容易被忽略的问题：操作序列不是固定长度。有时一步就能搞定，有时中间因为弹窗、加载延迟、登录失效，需要在原计划上插入额外步骤。比如“打开知识库”这个任务本身很简单，但如果界面上突然冒出一个强制更新弹窗，Agent 就必须先处理弹窗，回到正常流程后再继续。所以成熟方案不会用一次性 planning 就结束，而是做成“观察→规划→动作→再观察”的循环，每一步都重新评估当前页面状态。
任务分解层还有个关键参数：单步规划的最大动作数。我见过不少 Agent 卡在某个页面来回重试，就是因为模型不断产生“点击同一个按钮”的循环动作。好的做法是给规划器一个内置的重复检测器：如果最近 N 步动作几乎是同一个 action 且页面状态没有实质变化，就停止循环，主动请求人工介入而不是硬试下去。
2.3 动作执行层：点击、输入、滚动如何落到真机
动作执行相对机械，但隐蔽坑最多。元素定位策略通常按优先顺序：a11y 树的 resource-id → 控件文本 → OCR 坐标 → 像素坐标。顺序靠前者更稳定，靠后者兼容性更好但风险更高。
特别是坐标类点击，一旦屏幕分辨率变化、窗口位置移动、或者浏览器缩放比例改变，原本正确的坐标就可能点偏。这时候 Agent 不会告诉你“我点歪了”，它只会以为点击没生效，然后重新规划出一个更离谱的操作。所以执行层一定要有校验机制：点击之后，重新采样页面状态，对比点击前后的差异。如果点击前后页面完全没变，要么是点到了无效区域，要么是按钮本身有防重复逻辑，这时候应该把“执行异常”作为一个重要信号返回给规划层，而不是假装无事发生。
另一个隐蔽问题是元素遮挡判断。模型根据 a11y 树选中的按钮坐标是对的，但执行时按钮被一个半透明的 Loadding 遮罩挡住，点击事件穿不过去。坐标系校验只能保证“位置对”，无法保证“可点击”。这个问题需要在执行层用 hit-test 或者前端遮挡检测来解决，否则再准确的规划都会在执行环节翻车。
3. HITL：人类参与的层级比“审核”深得多
3.1 纠正一个动作，还是纠正一版流程？
HITL 的第一个关键设计是：人在哪个层级介入。目前常见的有四种：
- 预执行审批：Agent 给出下一步计划，人确认后才执行，适合高成本操作。
- 动作级介入：执行过程中发现错了，人可以暂停、修改、回退到某一步。
- 结果级反馈：Agent 完成整件事之后，人给整体结果打分或写文字评价。
- 策略级反馈：人不针对单次任务，而是告诉 Agent“以后这种场景默认不要用弹窗方式”。
不同层级的 HITL，收集到的信息价值完全不同。动作级介入信息最实时，但打断成本高；结果级反馈成本低，但只能事后纠偏；策略级反馈最抽象，但对模型长期行为影响最大。只做“审核”是最低级的用法，因为审核只给了二值结果——同意或拒绝，完全没有解释为什么。而 HITL 的高级用法，是让反馈数据直接参与调整模型的后续决策。举个例子，用户拒绝了一个动作，如果能顺带记录他随后手动执行了什么操作，这个“替代动作”就是一条极端有价值的正样本：它表示模型原本的意图方向不对，但用户最终的目标是什么。
3.2 显式反馈和隐式反馈，一个都不能少
反馈的采集形式也分层。显式反馈指的是对话框里的“满意/不满意”“正确/错误”“输入一段文字纠偏”；隐式反馈则是从用户行为里反推的。比如用户点了“撤销”，说明刚才动作不对；用户快速修改了某个字段再继续，说明 Agent 生成的初值方向值得学习；用户把窗口拖到一边，可能意味着 Agent 弹出的提示遮挡了他正在看的内容。
HITL 的完整链路应该是“显式反馈做兜底、隐式反馈做密度”。显式反馈质量高但稀疏，用户不可能每次都耐心打分；隐式反馈频率高、批量大，但要小心误判。用户撤销也不一定代表 Agent 错了，也可能是他自己改主意了；用户长时间不操作可能是在发呆，也可能是在犹豫要不要执行 Agent 建议的操作。所以隐式反馈的特征工程很重要，不能只看单点行为，要结合页面状态、任务上下文、操作时序一起判断。
3.3 HITL 让 GUI-Agent 越用越准的机制
为什么加入 HITL 之后，Agent 会“越用越准”？机制有三条。
第一，GUI 任务里最难的是“意图歧义”：同一个界面状态可能对应多种合理操作。例如邮件列表里出现了三个未读邮件，模型不知道用户想先处理哪封。人给出一次纠正后，即使不做模型更新，只是把它存成一次会话级的偏好，当前会话里的后续动作都会更准确。这解决的是短期适应问题。
第二，反馈数据可以做成偏好对，直接用于微调或 RLHF 阶段的奖励模型。用户拒绝动作 A 然后手动执行了动作 B，这就是一个天然的(A < B)偏好样本。长期积累下来，可以针对不同业务场景训练专门的奖励模型，让基座模型在多步 GUI 操作上的排序能力更强。这个是长期迭代问题。
第三，HITL 能沉淀成显式的长期规则文件。比如“涉及金额超过 X 元的操作必须二次确认”“发送邮件之前必须检查收件人列表”“遇到系统更新弹窗一律点稍后”。这种规则用一次反馈就能固化成系统策略，不需要等样本积累，也不依赖统计显著性。这是短期规则、中期个性化、长期模型训练三层同时生效的机制。说“越用越准”不算夸张。
4. 把 GUI-MCP + HITL 方案落地的操作路径
4.1 硬件、模型和工具链选型
要在本地环境把一整套方案跑起来，我以基于 MCP 的典型架构为例，按最小可运行版本准备：一个多模态大模型 API 用于视觉理解和动作规划、一个 GUI-MCP 服务端用于提供界面状态解析和动作执行能力、一个 MCP 客户端负责协议层连接与工具调用、一个 HITL 中间件负责拦截动作并决定是否必须人工审批，再加上一个目标测试程序做实操验证。
模型选型上，7B-14B 量级的本地模型已经能完成简单的按钮定位和单步点击，但涉及多步依赖的复杂任务（比如跨页面填写表单），推荐使用 70B 量级或云端 API，否则规划推理的稳定性会让你想摔键盘。视觉编码分辨率也很关键，部分微调小模型在低分辨率下漏看弹窗，但在高分辨率下推理速度又会明显变慢，需要根据实际任务做取舍。
4.2 配置 HITL 的三种触发策略
HITL 开关最好做成规则驱动，不要让人每步都审批。我的建议是只对三类操作强制人工介入：
- 高成本动作：删除数据、提交订单、发送消息、付款。
- 不可逆操作：覆盖已有文件、批量修改。
- 模型置信度低的步骤：当模型对某一步动作的概率低于阈值时，主动把控制权交给人。
置信度阈值需要根据任务调。任务简单时可以放到 0.6，复杂任务最好提高到 0.85，否则会频繁打断用户。可以在中间件里维护一个危险动作清单，调度前先过滤一遍，匹配上的直接进入等待人工审批状态，其余动作走自动执行。
4.3 一个最小回环的伪代码逻辑
用伪代码描述一个最小回环的运行节奏，比文字清楚：
code复制loop:
obs = sample_screenshot()
ui_tree = gui_mcp_get_state(obs)
actions, confidence = agent.plan(ui_tree, task)
for each action:
if is_high_risk(action) or confidence < threshold:
pass_to_human(action, ui_tree)
if human.reject(action):
learn_negative(action, reason)
continue
result = gui_mcp_execute(action)
save_event(ui_tree, action, result)
if result.error:
request_human_intervention("检测到异常状态")
注意 learn_negative(action, reason) 这里：不只记一条“这个动作被拒了”，还要把人拒绝之后自己手动执行的替代动作一起记下来。否则你只拥有负样本，却没有正样本，模型学不到“应该换成什么”。这也是很多人搭了 HITL 数据链路但模型效果迟迟不提升的原因——负向数据有了，但没有对齐目标。
4.4 数据模型的落地设计
数据库表至少要有三张：事件记录表、人工反馈表、审批日志表。
事件记录表存每次动作的页面状态、模型输出、执行结果。页面状态字段建议存结构化的 UI 树 JSON 而不是只存截图路径，否则离线分析时还得重新截图对齐，非常痛苦。人工反馈表存用户对单次动作的评价和纠错文本，这个表是后续训练集的主要来源。审批日志表存审批结果、审批人 ID、审批耗时，做团队级 HITL 时可以用来分析不同审批人之间的尺度一致性。
另外提醒一句：事件记录表的 UI 树字段可能会非常大，如果每步操作都全量存储，数据库增长会很快。建议对 UI 树做 diff 存储——如果当前页面状态和上一步没有本质变化，只存差异部分；有变化才全量存储。
5. 实测中遇到的几个坑和完整排查链路
5.1 弹窗把界面状态全部打乱
第一个必踩的坑就是弹窗干扰。真实环境里，一个定时弹窗可能在任何时刻覆盖当前焦点。Agent 在上一步规划时界面状态还是完好的，等它执行第一步点击，实际点击坐标已经落在弹窗区域上。表现就是：点了没反应，或者误触了弹窗上的按钮，导致页面状态进一步不可预知。
排查时看事件记录表，如果发现“规划时的 UI 树”和“执行时的 UI 树”不是同一版本，说明状态已经过期。正确做法是给每个动作执行前加一个版本校验：执行前重新拉取 UI 树，如果页面关键区域的哈希和规划时不一致，立即中止动作，重新采样、重新规划，而不是硬执行。版本号可以直接用 UI 树的哈希值，不用额外设计业务字段。
5.2 人工反馈噪声大：三个人三种意见
我实际测过让三个人对同一批 Agent 动作打标签，一致性不到七成。有人说弹窗应该直接关，有人说应该等一下看内容；有人对“自动填写金额”很满意，有人强烈反对让 Agent 碰任何金额字段。这就是反馈数据的 label noise。如果不处理，直接拿去微调，模型会学会一种“打太极”式的行为：碰到类似场景，给出的操作犹豫不决，因为它学到的是人类用户之间的分歧。
处理思路有两个。一是反馈表单尽量结构化，不要只留一个文本框。把“取消/重试/修改建议/这是一个长期规则”设计成四个按钮，能显著提高样本有效性。自由文本作为补充字段而不是主字段。二是多用户投票：同样的动作至少让 2-3 人评，出现分歧时视为低置信度样本，不进训练集，而是送去人工仲裁。仲裁成本高，但只占全部样本的一小部分，总体可控。
5.3 UI 结构一变，Agent 当场失灵
网页改版对 GUI-Agent 是致命的。上周还能定位到的按钮，这周 DOM 结构变了，resource-id 不存在，OCR 又读到一堆营销文案干扰信息。Agent 不是变笨了，而是它依赖的感知基准确实被销毁了。模型参数没变，prompt 也没变，但输入给它看的界面已经不是我训练时的那个界面了。
我的经验是：定期做回归测试集。挑 20 个高频任务，每周自动跑一遍，记录成功率曲线。一旦成功率明显下降，优先检查 UI 变更日志而不是模型参数。部署架构上一定要把“界面状态抽取”和“任务规划”解耦：前者更新频繁，后者稳定复用，不要耦合在同一个 prompt 或同一个服务里。状态抽取层可以做成独立微服务，UI 一旦变更只改抽取逻辑，任务规划器完全无感。
5.4 人类审批的超时与并发
HITL 中间件如果不处理并发，很快会出大问题。当多个任务同时请求人工审批时，如果没有超时预算，一个长时间不点“审批”的用户会把整个任务队列卡死。我见过一个团队因为审批超时设置成“无限等待”，结果一个无人值守的批量任务把生产队列堵了一整晚。
解决方式：给每一级人工介入设置明确的超时时间——普通操作 30 秒，高风险操作 120 秒。超时后按预案处理：可以自动取消该动作并记录，也可以降级为“等待更长时间”并释放任务线程。另外，审批队列要有优先级：付款、删除类最高，其他常规操作排后，避免高优任务被人海淹没。队列积压超过警戒线时，应该暂停自动任务的派发而不是继续堆积。
5.5 反馈数据过拟合到特定用户
最后一个坑在后期出现：HITL 数据直接灌进 RAG 或微调流程后，模型会对某个用户的偏好过拟合。某个用户特别谨慎，拒绝所有自动操作，于是模型在这个用户身上越来越保守；换一个激进用户，又越来越莽撞。同一个 Agent 部署给多个用户使用时，这个现象尤其明显。
应对办法是给反馈数据加“用户画像权重”而不是一视同仁地采样。历史行为上更谨慎的用户，他们的拒绝样本权重可以降低，避免模型学到用特定用户的性格覆盖全局策略。更稳妥的做法是反馈数据先只做离线分析，跑完效果评估再决定是否进入微调集，定期滚动更新，而不是实时灌入——尤其不要在推理链路上直接拼接用户级别的偏好文本，那会让模型的决策逻辑变得完全不可解释。
6. 对阶跃星辰这条路线的个人判断
拆完结构，我也说说实际感受。
GUI-MCP 最大的进步，是把 Agent 从“只能调用 API 的对话助手”往前推了一大步。它开始承担操作资格，去碰用户真实的软件界面。这带来的直接好处是任务的完成感强了——用户看到的不再是一段总结文本，而是一个被实际完成的操作过程。这也是为什么 GUI-Agent 这个方向会让很多人兴奋：它是把大模型从“建议者”变成“执行者”的临门一脚。
但操作资格扩大，也意味着错误成本扩大。API 调用错了可以重试，界面操作错了可能产生脏数据，再严重点就是误删文件或误发邮件。这种场景下，HITL 不只是界面上的一个开关，它其实是产品责任边界的一部分。哪个动作能自动、哪个动作必须由人确认，不应该是一个拍脑袋策略，而应该是一个可配置、可审计、可动态调整的体系。这是我从实际部署里体会最深的一点——先设计好“人什么时候介入、介入后反馈怎么回流”，再谈模型能力提升。
另一个让我印象深刻的点是数据飞轮。过去做一个 GUI Agent，最大的瓶颈是缺真实的操作轨迹数据。HITL 机制天然地把每一次使用、每一次纠正、每一次拒绝都变成数据资产。那些说“Agent 越用越懂你”的产品，本质上是把 HITL 数据喂回了模型，而不是靠模型自己在推理时突然变聪明。
如果让我给后来者一个建议：先把 HITL 想清楚，再调模型。模型能力再强也会有错，真正决定用户体验的，是错误发生之后有没有一条顺畅的、有信息量的挽回路径。把反馈表单做得足够好，把超时策略定得足够清楚，把数据链路埋得足够完整，比多刷一个点的模型准确率重要得多。
最后提醒一句：跑 GUI 自动化的时候，务必确保操作对象是你自己拥有使用权限的系统，或者已获得明确授权的测试环境。技术本身是工具，边界清楚了，才能持续做下去。