一、GUI Context 之后，Agent 还缺什么

我为App Agent设计了两种交互模式，GUI 模式和Chat 模式。

• GUI 模式：Agent 在真实页面中完成任务，复用现有交互流程和业务资产；
• Chat 模式：Agent 直接调用 MCP/Tool，通过对话交互以更加 AI Native 的方式完成任务。

存量业务中的流程，很多设计的是跟页面强相关的。上一篇的GUI Context 解决的是页面理解问题。它帮助 Agent 理解当前页面状态：我在哪、看到了什么。

但在 App Agent 的实践中，我很快发现，仅有 GUI Context 仍然不够。

因为 GUI Context 描述的是页面状态（State），而不是业务知识（Knowledge）。

以下单场景为例。 GUI Context 可以告诉 Agent：

screen_type: detailprimary_action:  label: 加入购物车

但它并不知道：

• 这个页面为什么存在；
• 用户通常会在这里完成什么任务；
• 哪些能力是核心路径；
• 后续可能进入哪些页面。

这些信息并不属于页面状态，而属于业务知识。

因此我把一部分业务知识放在了page metadata中，跳转到相应的页面后装载，帮助agent理解业务。

二、Page Metadata 描述什么

成本考虑，App Agent所选的模型性能一般，那更需要精细的控制上下文，在业务流程中把agent最需要的业务知识送给它。

GUI Context 可以帮助 Agent 观察页面，但产品规则不应该依赖 Agent 从页面中猜出来。

另外一个角度，我把流程类业务知识放在skills中，按需加载。那么page metadata中，应该放些什么呢。

2.1 页面职责和能力

Agent 需要知道这个页面为什么存在。 性能强大的模型，可以通过GUI Context推断出页面是干什么的，下一步该怎么做。没有强力模型不要紧，在降本增效背景下，花小钱把事办了，还能体现我Harness Engineering水平，这才是挑战。

所以page metadata会明示这页面干什么的。

例如不同业务流程中，很有很多详情页。

商品详情页的核心目标是完成商品选择； 订单详情页的核心目标是查看订单状态； 积分详情页的核心目标是了解积分和权益。

purpose:  用户选择商品并发起购买

准确的位置给与准确的明示，页面职责决定了 Agent 对当前页面的整体理解。

GUI Context是瞬时的页面状态，页面所承载的业务流程和知识，却不是靠瞬时状态能表达出来的。 比如：

• 在寸土寸金的App版面里面，很多有Tab页签，藏那么深OCR一眼看不出来。
• 有些刷新、分享功能藏在菜单中，这让agent扫页面怎么也看不出来。
• 有一些页面，有多步的小操作，如先看广告再领券。
• 动态触发的页面内容。

显式的页面职责和能力，就可以不让agent依赖推断，准确掌握UX层的业务认知。

2.2 业务约束

实际App中，一堆狗皮膏药的交叉营销广告，就让Agent瞬间迷失了自我。

这给我干哪去了？

Agent中嵌推荐和广告，那是另外一个话题，这里我们专注于完成任务。

这里的业务约束并不是控件状态，也不是运行时校验规则，而是页面设计时预设的决策边界。

例如订单确认页的核心目标是完成订单确认，而不是继续浏览商品；商品详情页的核心目标是完成商品选择，而不是无限扩散到评价、推荐或活动页面。

这些约束往往不会直接体现在 GUI Context 中，但会持续影响 Agent 的决策方向。是产品设计者希望用户遵循的业务路径。

对于能力较弱的模型而言，这类信息能够有效减少无意义探索，使 Agent 更稳定地沿着业务主链路推进任务。

三、Page Metadata 应该什么时候加载

最初的实践中，我将页面相关业务知识直接写进业务 Skill。 例如：

购买商品Skill├── 门店页知识├── 商品列表页知识├── 商品详情页知识├── 购物车页知识├── 订单确认页知识└── 支付页知识

当 Agent 识别到时购买意图后，动态加载skill，但Skill 涉及多个页面，用户仅仅是到了门店页的时候，context就携带着购物车页、订单确认页甚至支付页的知识。

这些知识当前并不会被使用，却会随着 Agent Loop 一轮轮重复进入上下文，浪费token，干扰LLM注意力。

一个现存的App，有上千个页面，这些页面能否非常精准的载入Agent呢，后台想到做成知识库，通过检索按需加载。但实践下来无论是RAG还是LLM wiki，都不太理想。首先多一次检索让App Agent变慢了，另一个就是检索会出现知识缺失、召回不完整、命中错误页面等问题。

最终我们把注入时机和页面跳转结合起来，非常自然的，App Agent会观察页面是否跳转，进入到一个新页面就需要这个页面的业务知识，依靠页面路由和别名可以准确加载。

这就是页面元数据的由来，整个过程不依赖 Agent 推理，不依赖检索，它完全由运行时页面驱动。

从结果看，这其实是一种比 Skill 更细粒度的渐进式披露。

Skill 解决的是：

当前任务需要什么流程知识

Page Metadata 解决的是：

当前页面需要什么页面知识

前者由业务驱动，后者由页面驱动。两者结合后，Agent 上下文中出现的知识才真正做到与当前任务、当前页面同时相关。

对于存量 App 场景，这种加载方式比 Skill、更比 RAG 更稳定，也更符合页面驱动的运行模式。

小结

我把与页面相关的业务知识，从业务skill中剥离到页面元数据Page Metadata，更精准的将页面职责、业务语义、能力边界以及产品设计者预期的用户路径等信息告诉Agent。既提高了业务操作准确性又节省了token。

实践中也是对渐进式披露，再往前走一步。

Page Appeared↓获取页面路由/别名↓加载对应 Page Metadata↓注入当前 Agent Context