手机 Agent 自动化最容易出问题的，不是模型效果，而是权限、风控、支付和数据边界；如果这几条线不先写死，后面框架再强也会在上线前被卡死。
Google Play 与 Accessibility 的红线
Google Play 关于 AccessibilityService API 的政策 在 2026-03-29 仍然写得非常明确：
- 自动化用途可以使用 Accessibility API，但必须是 narrow and clearly understood purpose。
- 任何让应用“自主发起、规划、执行动作或决策”的用法都被严格禁止。
- 只有经过验证的 accessibility tools，且核心目的是帮助残障用户，才可在该范围内豁免。
这意味着：
如果你的方案要上 Google Play
- 不能把通用购物 Agent 做成“自主决策 + 自主执行”的 Accessibility 工具
- 只能做明确、静态、用户定义的规则式自动化
- 还需要披露和同意流程
如果你的方案是企业内部、侧载、真机池
Play 政策不等于全部法律边界，但它仍然提醒了一件事：
通用自主 Agent + Accessibility 权限，是高风险组合。
Android 官方底座的边界
Android 官方 UI Automator 文档 把它定位为自动化测试框架。这更适合：
- 内部测试
- 设备农场
- 自动化执行器
而不适合直接包装成“面向普通用户的自动购物 App”。
购物平台侧的风险点
即便不考虑 Play，淘宝、1688、京东、拼多多这类平台也普遍存在下面几类控制：
- 登录校验
- 图形验证码 / 滑块 / 行为验证
- 异常设备识别
- 短信 / 口令 / 二次确认
- 支付风控
- 地址、实名、采购权限校验
这些都不应该被绕过。
本方案明确不做的事
- 不尝试绕过验证码、滑块、OTP
- 不保存或推断用户密码
- 不在无审批的情况下执行真实支付
- 不隐藏真实执行动作
- 不静默抓取地址、银行卡、实名信息
- 不做账号批量刷单、抢购、黄牛型自动化
必须具备的合规设计
明示权限
如果你使用 Accessibility、屏幕录制、通知读取、无障碍或媒体投屏能力，必须在产品里显式说明：
- 为什么需要
- 会读到什么
- 用在什么场景
- 用户如何关闭
最小化数据
建议只保存下面这些与执行强相关的数据：
- 任务目标
- 当前页面状态
- 截图
- 执行动作日志
- 订单摘要
尽量不保存：
- 全量聊天记录
- 全量账号凭证
- 支付凭证
- 不必要的个人敏感信息
支付前双保险
支付前应至少具备两道限制：
- 状态机强制进入
approval_required - 用户显式确认后才能继续
账号隔离
建议按 账号 -> 设备 -> 任务 三层隔离：
- 一个设备尽量绑定固定账号
- 不同客户、不同店铺不要混设备
- 任务日志与账号身份分开保存
为什么推荐“到确认页停机”
因为对真实购物业务来说，价值最大的往往不是最后那一下支付，而是前面的重复劳动：
- 搜索与筛选
- SKU 对比
- 券规则判断
- 配送和店铺核验
- 加购与订单准备
把自动化做到确认页，人来决定最后一步，通常已经覆盖 80% 的劳动量，但合规风险会低很多。
什么时候应该改走 API
下面这些场景不应该继续深挖 UI-only：
- 你已经有商家后台权限
- 你需要处理大量订单
- 你需要库存、价格、订单号强结构化
- 你需要可审计的交易链路
这时应该优先看：
适合做的产品定义
合规友好的定义
“一个内部采购 / 运营助理，帮助用户在授权账号下完成商品搜索、筛选、加购和订单准备，并在关键节点请求人工确认。”
风险高的定义
“一个无人值守的购物机器人，自主决定、提交并支付订单。”
前者可控，后者几乎一定会撞到平台规则、支付风控和权限审查。
结论
手机 Agent 自动化能做，但必须把“自主规划”和“自主执行”拆开，把“任务完成率”让位给“边界清晰、可审计、可回退”。购物场景尤其如此。