以前我们讲的是 Agent 怎么规划、怎么调工具、怎么防错。

这一章往外走一步：Agent 如何和真实界面交互。

它不只读 API。它开始看屏幕、识别按钮、填写表单、观察反馈。

这就是 GUI Agent，也叫 Computer Use Agent。

它让 AI 从“会说”，继续变成“会操作”。

1. 为什么需要 GUI Agent

理想情况是：每个系统都有 API。

现实情况是：很多企业系统没有 API，或者 API 不完整。

老后台、ERP、CRM、报销系统、运营平台，往往只有页面。

人能点，程序不好接。

这时，GUI Agent 就有价值。

它把屏幕当成环境。

把按钮、输入框、弹窗、表格当成可理解对象。

再通过鼠标、键盘、浏览器控制器完成操作。

一句话：以前 Agent 调接口，现在 Agent 可以操作界面。

2. API、GUI、现实环境，别混在一起

三者不是替代关系，而是层层升级。

能用 API，就不要强行用 GUI。

API 稳定、快、便宜、好监控。

GUI 适合没有 API、流程分散、页面复杂的场景。

现实环境更复杂，比如摄像头、语音、机器人。它不只是点按钮，还要理解现场。

所以顺序很重要：

• 第一优先级：API 或 MCP 工具。

• 第二优先级：浏览器自动化或 GUI 操作。

• 第三优先级：摄像头、语音、机器人等现实环境交互。

3. GUI Agent 是怎么运行的

GUI Agent 的运行逻辑很像人操作电脑。

看一眼屏幕。

判断下一步。

点击、输入、滚动。

再看结果。

直到任务完成。

注意，这里最关键的不是“点”。

而是“每一步都观察反馈”。

页面加载慢怎么办？

弹窗挡住了怎么办？

按钮文案变了怎么办？

验证码出现了怎么办？

这些都不能靠一次性脚本解决。

GUI Agent 必须具备循环能力：观察、决策、行动、再观察。

4. 工程上要拆成 6 层

真正可上线的 GUI Agent，不能把所有事情都交给模型。

模型负责判断。

控制器负责执行。

策略层负责安全。

日志系统负责追踪。

这套架构里，最容易被忽略的是安全层。

很多人做 Demo，只关心能不能点。

但上线时真正的问题是：它能不能乱点？

比如自动提交审批、自动删除数据、自动转账、自动外发邮件。

这些动作必须被拦住。

5. 案例：报销系统自动填单

假设公司有一个老报销系统。

没有完整 API。

员工每次都要打开网页，选择费用类型，填写金额，上传发票。

这个流程重复、固定、耗时间。

适合用 GUI Agent 做辅助。

这里有一个重要边界：

Agent 可以自动填写草稿。

Agent 不应该自动提交审批。

因为提交之后会进入财务流程，属于高风险动作。

更稳妥的设计是：

• 读取票据，提取金额、日期、商户。

• 打开报销系统，自动填写表单。

• 上传附件，生成预览。

• 自动校验字段一致性。

• 最后停在确认页，让用户点击提交。

这就是“自动化”和“失控自动化”的区别。

6. GUI Agent 和传统 RPA 有什么区别

很多人会问：这不就是 RPA 吗？

不是。

RPA 更像固定脚本。

GUI Agent 更像会观察的操作员。

• RPA 依赖固定路径：第几个按钮、第几个输入框。

• GUI Agent 依赖理解能力：这个按钮是不是“保存”，这个弹窗是不是错误提示。

• RPA 适合稳定页面。

• GUI Agent 适合页面经常变化、需要判断的流程。

• RPA 更便宜、更可控。

• GUI Agent 更灵活，但更需要安全治理。

所以不要把 GUI Agent 当作 RPA 的完全替代品。

它更适合作为 RPA 的补充。

7. 进入现实世界：从屏幕到摄像头

更进一步，智能体不只看电脑屏幕。

它还能看摄像头、听语音、理解现场。

例如，用户把手机摄像头对准设备故障灯，Agent 可以判断可能原因，并指导下一步操作。

这种交互方式的关键，不是“回答更长”，而是“上下文更真实”。

屏幕、声音、图像、位置、设备状态，都会变成 Agent 的输入。

但风险也更高。

因为现实世界不能随便试错。

软件点错按钮可以回滚。

机器人碰错物体可能造成损失。

所以越靠近现实世界，越需要人工确认和安全边界。

8. 风险闸门：能操作，就必须能管住

GUI Agent 最大的价值，是能操作。

最大的问题，也是能操作。

因此必须在关键节点设置闸门。

低风险动作可以自动执行。

比如搜索、打开页面、复制信息、填写草稿。

中风险动作需要策略校验。

比如修改配置、上传文件、发送内部通知。

高风险动作必须人工确认。

比如付款、删除、提交审批、外发邮件、生产变更。

9. 上线前看这张清单

做 Demo 时你可以让 Agent 自由探索。

上线时不能。

上线系统要有边界、权限、审计、回滚、限流和评估。

尤其是 GUI Agent。

因为它面对的是变化的页面。

页面变化、按钮消失、弹窗出现、登录过期，都可能让它走偏。

工程上必须限制最大步骤数、最大重试次数、最大执行时长。

跑不通，就停。

不确定，就问人。

10. 总结

智能体交互，是 Agent 落地的下一层能力。

工具调用让 Agent 能访问系统。

MCP 让工具连接更标准。

GUI Agent 让 Agent 能操作没有 API 的界面。

多模态交互让 Agent 能理解真实环境。

结论：

• 能用 API，优先用 API。

• 必须操作页面，再用 GUI Agent。

• 涉及真实环境，必须加安全边界。

• 涉及高风险动作，必须让人确认。

• 所有动作都要有日志，所有失败都要能退出。

真正可上线的交互型 Agent，不是“会点按钮”的模型。

而是一套受控、可观测、可恢复的自动化系统。