一、存量 App 为什么需要 GUI Agent

讨论 GUI Agent 之前，一个经常被忽略的问题是：

为什么不直接做 Chat风格的Agent？

从 AI Native 的角度看，Chat + Tool 确实是更理想的形态。用户表达意图，Agent 调用结构化能力完成任务，中间不再依赖复杂的页面交互。

但对于已经发展十多年的移动互联网来说，现实远没有这么简单。 用户熟悉的页面结构、精心设计的交互流程、营销活动链路、异常处理逻辑，以及各种业务状态机，共同构成了产品的重要资产。

以点外卖场景为例，一个看似简单的“帮我点一份麦当劳套餐”，背后可能涉及门店选择、商品规格、优惠券计算、配送方式确认、活动推荐、订单确认等多个环节。这些能力往往已经深度嵌入页面流程，而不是以独立 Tool 的形式存在。

理论上，企业可以将这些能力重新抽象成 API，包装成再构建一套全新的 Agent 体系。但对于大多数存量业务而言，这意味着巨大的改造成本，以及漫长的建设周期。

因此，在存量 App 场景下，GUI Agent 成为一条现实可行的路径。

它不要求业务立即完成 AI Native 改造，而是允许 Agent 像用户一样操作真实页面，在现有交互体系中完成任务。页面、流程、状态机和业务规则得以继续复用，用户也能够通过熟悉的界面获得过程可见性和最终确认权。

从这个角度看，GUI Agent 的核心价值并不是“模拟点击”，而是帮助 Agent 复用过去十多年积累下来的交互资产。

二、页面采集只是手段，页面理解才是关键

GUI Agent 的第一步通常是获取当前页面信息。最直接的就是截图扔给图像大模型，但是图像大模型一方面微调困难，运行慢还贵。除了图片，还有多种方式获取页面数据：

• App内直接采集控件树View Tree；
• Accessibility 获取可访问性节点；
• ADB 或 uiautomator 导出页面结构；
• OCR 提取页面文本；
• Web 场景直接获取 DOM 结构。

这些方案各有优劣，但本质上都在回答同一个问题：

当前屏幕上有哪些信息。

例如：

OCR 可以识别页面上的文字；View Tree 可以获取控件层级和坐标；Accessibility 可以提供更丰富的语义描述；视觉模型能够直接理解页面截图。

从页面采集角度看，它们已经能够覆盖绝大多数场景。但GUI Agent 面临的核心挑战并不是“如何获取页面”。 真正的问题在于：

获取到的页面数据，是否能够直接成为 Agent 的上下文。

对于 Agent 来说，页面理解的目标不是复原屏幕内容，而是决定下一步行动。

例如：

本期应还3000元 立即还款

对于用户而言，这是一个账单页面。

但对于 OCR 来说，这只是几个文本块。对于 View Tree 来说，这只是若干节点。对于视觉模型来说，这只是页面中的几个视觉区域。

这些信息能够描述页面内容，却无法直接表达页面语义。

同样的问题也存在于交互状态上。Gui Agent实际上了生产环境，页面出现 Loading、弹窗、Toast、键盘遮挡、选中状态变化等各种场景，原始页面数据虽然发生了变化，但这些变化对于 Agent 的意义并不相同。

Agent 真正关心的是：

• 当前处于什么页面；
• 页面是否可操作；
• 是否存在阻塞交互的弹窗；
• 当前任务对应的入口在哪里；
• 哪些动作是有效候选动作。

这些信息并不存在于任何单一采集源中。

因此，无论是 OCR、View Tree、Accessibility 还是视觉模型，它们本质上都只是页面观测结果（Observation），而不是 Agent 可以直接消费的运行时上下文（Context）。

从这个角度看，GUI Agent 的核心问题并不是页面采集，而是如何将异构的页面观测结果转换为稳定、统一、面向任务的页面语义。

三、GUI Context：Agent 的统一页面描述

页面采集解决的是数据来源问题，GUI Context 解决的是数据表达问题。我在采集层与 Agent 之间定义了一套统一的页面描述规范——GUI Context。GUI Context 不关心页面如何实现，而关注页面当前的业务语义和可操作性。

其具体形态是一份 Page Description：单屏的结构化语义描述，由采集层产出，由 Agent / Skill 直接消费。

LLM Agent  │ consumesGUI Context (Page Description)    │ produced byCollection Adapter  │ readsSDK Tree / Accessibility / OCR / ADB / Web DOM / ...

3.1 Page Description 的字段

一份 Page Description 是结构化对象，按职责切成若干字段。每段回答一个具体问题，可缺省但不重叠：

identity / layout / state

身份决定 agent 策略。screen_type 取自统一分类（见 §2），不是 Activity 类名：

identity:screen_id:"com.zs.inappgui.ShopDetailActivity"screen_name:"ShopDetail"screen_type:detaillayout:orientation:portraitwidth_px:1080height_px:2400density:2.75state:loading:falsekeyboard_visible:false

layout 的像素值用于坐标回填到点击命令；state 的 loading / keyboard_visible / refreshing 用来阻止 agent 在错误时机操作。

structure / navigation

structure 给出可被确定计算的量级，让 agent 不需要在 LLM 里数节点：

structure:item_count:12scrollable_regions:1input_fields:0image_count:5content_type:list# list | feed | grid | form | single

navigation 描述跨页通道：

navigation:back_available:truetabs:-{label:"首页",selected:true}-{label:"资讯",selected:false}-{label:"推荐",selected:false}-{label:"我的",selected:false}

key_elements

按语义角色而非控件类名标注关键元素，跨平台共用：

key_elements:search:-label:"搜索商家或商品"cart:-label:"购物车"back:-label:"返回"primary_action:-label:"去结算"

content / actions

content 是去重后的可见对象列表，每条携带 label / role / bounds / traits / clickable；actions 是从 content 衍生出来的可执行候选，已带坐标和 spatial hint。两者分开，是为了把“屏幕上有什么”和“现在能做什么”解耦。

content:-label:"星巴克"role:buttonbounds:[24,148,196,220]traits:[button]clickable:true-label:"¥29.0"role:pricebounds:[24,556,100,580]clickable:false-label:"搜索商家或商品"role:inputbounds:[16,60,374,116]traits:[search,adjustable]clickable:trueactions:-{label:"星巴克",action:click,target:[110,184]}-{label:"搜索商家或商品",action:input,target:[195,88],input_hint:"搜索"}-{label:"商品列表",action:scroll,direction:down}

overlays

遮挡是 GUI Agent 出错的高发区，必须独立成段而不是混进 content：

overlays:-type:dialog# dialog | popup | bottom_sheet | toast | permission_requesttitle:"确认删除"message:"确定要从购物车中删除该商品吗？"dismiss_action:"确定"

Universal Traits

类名不进描述，所有元素的语义靠一份共用 trait 表表达，可叠加：

例：列表里一个可点击价格标签，traits = [button, price, list-item]。

3.2 Screen Type Taxonomy

screen_type 是 agent 策略分支的第一层路标。规范给出闭集分类：

分类由适配器按结构特征确定性给出，命中顺序大致是：阻塞遮挡 > loading > error > 多输入 + 提交（form） > 结算关键词 + 底部价格（checkout） > 购物车结构 > 搜索 + 结果（search） > 重复列表 patten（list） > 单详情（detail） > 入口网格（home） > 登录字段（login）。无匹配则 unknown，agent 仍可工作，只是不享受类型先验。

3.3 Page Delta：增量更新

每次 action 后整页重传成本高、噪声大。Delta 描述自上一份 Page Description 之后的局部变化：

base_hash:"a1b2c3d4"screen_changed:falsechanges:-{type:badge_changed,target:"购物车",old_value:0,new_value:1}-{type:overlay_appeared,target:"已加入购物车",overlay_type:toast}-{type:text_changed,target:"购物车按钮",new_text:"购物车(1)"}

变化类型是闭集：element_appeared / element_disappeared / text_changed / state_changed / overlay_appeared / overlay_dismissed / badge_changed / scroll_position / keyboard_changed。

何时用全量、何时用增量有明确规则：

强制重同步避免 Delta 链路漂移；agent 端只需消费两种消息，不需要自己做状态合并。

3.4 Collection Adapter

适配器是 spec 之外的实现层，但规范给出统一管线：

Raw Data → Normalize → Classify → Extract → Build

• Normalize：原始树 / OCR 块 / 节点统一成「带 bounds / text / clickable / traits 的扁平候选元素」；
• Classify：按结构特征确定 screen_type；
• Extract：识别 key_elements / content / navigation / overlays，去重；
• Build：组装出符合规范的 Page Description。

四种典型来源各自的取舍：

不论来自哪一种，输出都必须落到同一份 Page Description；这是「采集多样、语义稳定」这条边界能成立的工程前提。

四、GUI Context 之外：一些实践后的思考

GUI Context 的设计初衷只是解决页面理解问题。但随着App Agent系统逐渐复杂，我发现背后其实指向了一些更普遍的 Agent 工程规律。整个项目做下来积累很多宝贵经验，以后可专门再单独讨论。

Agent 不应该直接消费页面，而应该消费页面模型

无论是 View Tree、Accessibility、OCR，还是未来的视觉模型，它们本质上都只是页面观测结果（Observation）。Agent 真正需要的不是观测本身，而是能够支持决策的环境模型（Model）。

Observation  ↓  Page Model  ↓  Reasoning

GUI Context 的价值并不在于定义了一种新的数据格式，而是在页面观测与 Agent 推理之间建立了一层稳定的页面模型。

模型最重要的能力是推理，而不是解析

页面分类、元素筛选、弹窗识别、状态判断，这些本质上都是确定性问题。能够通过规则、算法或运行时确定的信息，不应该反复消耗 LLM 的推理预算。

成熟的 Agent 系统应该尽量遵循同一个原则：

能确定计算的，就不要让模型猜。

App侧的SDK目前有大量的计算、转换、diff，这些让模型专注于规划、决策和异常处理，而不是充当页面解析器。

事实与解释应该分离

很多 Agent Prompt 天然会混入大量解释性描述：

你可能位于商品详情页建议点击购买按钮

但这些判断本身已经包含了推理。

GUI Context 的设计更倾向于只提供事实，

至于下一步是否应该点击，则由 Agent 根据任务目标自行决策。

事实层越稳定，上层 Skill、Workflow 和 Planner 的可维护性就越高。

GUI Context告诉Agent我看见了什么，但是没有回答“这个页面为什么存在，以及它能够帮助用户完成什么呢”，下一个问题自然变成了，如何让 Agent 理解页面背后的业务语义。

emm，且听下回分解。