飞猪 GUI Agent 的技术探索与工程实践 | 新程序员

Ne0inhk

26 Feb 2026 — 12 min read

作者 | 飞猪技术任圣志责编 | 唐小引

出品 | ZEEKLOG（ID：ZEEKLOGnews）

在移动互联网时代，用户与软件应用的交互高度依赖图形用户界面（GUI）。无论是搜索、购票、值机、退改签，还是查询订单等，这些操作本质上都是“看图点击输入等操作”的过程。

为了代替人操作软件，产生了模拟人操作软件应用的自动化技术（RPA）。然而，传统的自动化技术（如 Appium、Selenium、Airtest 等）严重依赖 GUI 控件（如 ID 或 XPath），一旦软件 GUI 发生变动，自动化脚本即失效，维护成本极高，开发效率极低。

为解决这一痛点，我们启动了 GUI Agent 项目——一个融合多模态大模型与设备控制能力的智能体系统。它能“看懂”界面、“理解”用户意图，并自主规划操作路径并执行操作，真正实现低维护、高泛化、可解释的智能自动化。

本文将分享我们在 GUI Agent 上的技术探索与工程实践，涵盖架构设计、关键技术突破、落地案例与未来展望。

为什么我们需要 GUI Agent

传统自动化技术的困境

我们曾广泛使用 Appium 和 Airtest 及购买厂商等 RPA 工具进行自动化流程执行，但在实际落地中面临三大难题：

📌 示例：一个简单的“航班值机”流程，在遇到按钮重命名（如“立即值机” → “在线办理”）、页面重构或加载延迟时，传统脚本极易失败，平均修复耗时超过 2 小时。

新思路：借力 AI，让 AI 像人类一样操作 GUI

人类如何完成 GUI 操作？观察发现，其行为路径是典型的“感知-决策-执行”闭环：

1. 看（Perceive）：识别界面上的文字、按钮、输入框；

2. 想（Reason）：结合任务目标判断当前状态及下一步动作；

3. 做（Act）：通过点击、输入、滑动完成操作。

如果我们能让 AI 模拟这个过程，就能构建一个真正“智能”的自动化系统。

于是，我们提出了 GUI Agent 的概念：

一个能“看得懂界面、想得清逻辑、做得对操作”的智能体。

该智能体不依赖于底层控件树，而是通过视觉 + 语义双重理解来驱动交互，具备强鲁棒性和跨平台适应能力。

GUI Agent 是什么

GUI Agent 是一个融合了多模态大模型、OCR、决策规划与设备控制的端到端智能系统，其核心能力如下表所示：

区别于传统自动化工具，GUI Agent 的最大优势在于：

✅ 无需控件 ID：完全基于视觉定位
✅ 支持跨平台：移动 App / 移动 H5 / PC 浏览器 / PC App 均可运行
✅ 具备容错与自愈能力：可处理异常弹窗、加载失败等动态情况
✅ 开发极简：只需提供自然语言描述即可运行任务

整体架构设计

GUI Agent 架构基于 ReAct（Reasoning + Acting）框架构建，形成“思考—行动—观察—迭代”的闭环流程。

架构层级图

流程图

模块交互图

核心工作流

[用户输入]     ↓Planner (LLM) 分析当前截图 + 历史记忆 → 生成 Action List    ↓Executor 执行动作（click/input/swipe）    ↓Capture Screenshot & OCR → 获取新状态    ↓Feedback Loop: 将结果送回 Planner 继续推理    ↓直到任务完成或判定不可行

该流程实现了类人的“试错式”交互策略，显著提升了复杂流程的成功率。

系统模块详解

（1）Planning Engine：任务规划大脑

输入：用户自然语言指令 + 当前界面截图 + 历史动作记录
输出：结构化 Action 列表（如 click("立即值机")）
核心技术：

使用 Qwen2.5-VL-72B 多模态大模型

结合定制 Prompt 模板实现任务分解与动作生成

支持多轮对话与上下文延续

🔍 注：Prompt 中明确限定输出格式与动作空间，确保可控性。

（2）UI-Tars 模型：视觉定位专家

功能：接收“元素描述” + 截图 → 输出精确点击坐标
模型基础：基于 Qwen-VL 微调的专用 UI Grounding 模型
准确率：>99%，尤其擅长按钮、输入框等高频组件

💡 创新点：引入“功能+外观”双维度描述（如“蓝色背景的确认按钮”），提升泛化能力。

（3）OCR 辅助判断

引擎选型：Paddle OCR + 再训练+ 阿里云本地部署（用于航司域文字增强）
用途：

页面状态识别（如“值机完成”）

错误检测（如“网络异常，请重试”）

匹配预设 stopTexts 实现流程终止

⚠️ 补充点：在部分航司上会有特殊字体字符识别错误。

（4）Agent Memory：长期记忆系统

作用：

存储历史动作、思考过程、中间状态

支持错误回溯、审计追踪、多轮协作

数据库设计：

CREATE TABLE agent_session (    session_id VARCHAR(64) PRIMARY KEY,    user_id VARCHAR(32),    start_time DATETIME,    status ENUM('running', 'completed', 'failed')); CREATE TABLE agent_memory (    id BIGINT AUTO_INCREMENT PRIMARY KEY,    session_id VARCHAR(64),    step INT,    thought TEXT,    action JSON,    screenshot_url TEXT,    timestamp DATETIME);

查询支持：按 session 查询全过程日志，便于调试与合规审查

（5）Client SDK：客户端集成层

职责：

移动端/PC 端采集截图与用户输入

接收服务端下发的动作指令并执行

支持多种接入方式：

Android：ADB + airtest
PC：WebDriver/WindowsDriver

通信协议：gRPC over TLS，保障安全性与实时性

🔐 安全提示：所有敏感操作（如退票、付款）需二次确认，防止误触发。

关键技术实践

如何让大模型“真正看懂”界面？

直接将截图传给 LLM 效果不佳。我们通过以下方法显著提升理解准确性：

（1）精细化 Prompt 设计

明确角色定义、平台类型、可用动作集
提供示例 Few-shot 示例引导输出格式
强调“基于当前截图决策”，避免预测未来状态

（2）上下文增强策略

注入历史动作与反馈结果
添加设备元信息（platform: mobile）

（3）结构化动作空间定义

{  "actions": [    {      "name": "click",      "description": "点击屏幕上某个元素",      "parameters": {        "element_desc": "必须详细描述目标元素的功能与视觉特征"      }    },    {      "name": "input_text",      "description": "向指定输入框填入文本",      "parameters": {        "text": "待输入内容",        "element_desc": "目标输入框描述",        "override": "是否清空原内容"      }    }  ]}

✅ 最佳实践：要求 element_desc 包含“功能 + 文案 + 位置”三要素，例如：“位于页面底部的绿色按钮，文案为‘立即提交’”。

动态坐标预测的成功率优化

UI-Tars 在部分文字+输入框场景无法正确识别控件坐标，影响点击成功率。我们采取以下措施提升稳定性：

错误处理与自愈机制

构建三层容错体系，提升任务鲁棒性：

此外，引入“动作震荡检测”：若连续动作后但界面未变或变化巨大（可能跳转了页面），则重新调用 planning 服务。

性能优化：速度与精度的平衡

为降低端到端延迟，我们在多个环节进行优化：

📈 当前 P95 端到端延迟：2.8 秒/步，满足多数非实时场景需求。

落地案例：机票值机流程自动化

业务背景

值机是飞猪出行场景中的高频操作，具有以下特点：

规则明确：步骤固定，输入参数清晰
重复性强：相同的操作流程
成功率敏感：失败直接影响用户体验

传统方式需用户手动完成以下步骤：

1. 打开手机浏览器

2. 输入航司值机 URL

3. 填写票信息和乘机人姓名

4. 点击“值机”

5. 同意相关协议

6. 选择座位

7. 确认值机

GUI Agent 实现流程示例

用户仅需发送一条自然语言指令：

“我的姓是张，名是三，票号是 FL123456，帮我完成值机。”

Agent 自动执行如下动作序列：

Thought: 当前页面为首页，需进入订单页查找航班Actions: [click("我的"), click("我的订单")] Thought: 输入票号开始搜索Actions: [input_text("FL1234", "请输入票号", true)] Thought: 找到航班后点击值机Actions: [click("去值机")] Thought: 填写乘机人信息Actions: [input_text("张", "姓"), input_text("三", "名")] Thought: 同意协议并选座Actions: [click("我已阅读并同意"), click("确认"), click("靠窗座位")] Thought: 提交值机请求Actions: [click("提交值机")] Thought: OCR 检测到“值机成功”，任务完成Actions: [status("complete")]

最终通过 OCR 验证“值机成功”字样，返回结构化结果给用户。