编排层用 Agent，执行层保留确定性工具
OpenClaw / Midscene / 自定义 LLM 编排适合做规划、观察、失败恢复，但真正落点击、输入、滚动、返回时，需要 UiAutomator2 / ADB / Appium 这种可回放执行器兜底。
Core Recommendations
三条先定死的设计原则
购物场景先做到“到提交页”，支付保留人工确认
淘宝、1688、京东、拼多多都存在登录、验证码、券规则、地址校验、风控和支付验证。无人值守自动支付风险高，MVP 应停在待确认/待支付节点。
商家能力优先走开放平台 API，而不是全靠 UI 点点点
当业务拥有商家账号、店铺系统或采购权限时，应优先接京东/淘宝/1688/拼多多开放平台。UI Agent 只处理非标准表单、运营后台、人审流程和补录动作。
Tracks
文档分区
方案全景3 篇首页展示
方案全景
先判断用什么栈、什么边界、什么业务模式最合理。
执行摘要1 篇首页展示
执行摘要
给 owner / 投资人 / 合作方看的结论版。
架构蓝图2 篇首页展示
架构蓝图
面向实现团队的架构、接口、里程碑与验收标准。
来源索引1 篇首页展示
来源索引
本轮调研使用的主要官方资料、仓库与产品文档。
Featured Reading
优先阅读
方案全景总览
文档地图与推荐阅读顺序
这套文档的核心结论是：安卓手机自动化要分成编排层、执行层、设备层三段设计；购物场景要优先做到“搜索、比价、加购、领券、到提交页”，而不是一开始就追求无人值守自动支付。
方案全景框架比较
安卓自动化框架全景
截至 2026 年 3 月 29 日，Android 自动化生态可以明确分成“底座执行器”“视觉/脚本自动化”“Agent 编排层”“研究 benchmark / 模拟环境”四类；把它们混成一个概念，会直接导致架构选型错误。
方案全景策略判断
Agent 编排层与执行层技术栈
手机自动化里的 Agent，不应该直接拥有“看到页面就决定支付”的绝对权限；它更应该是一个被策略引擎、状态机、确定性执行器和审计系统包住的规划器。
方案全景策略判断
购物 App 自动执行蓝图
淘宝、1688、京东、拼多多这类购物 App 的自动化，不应该被定义成“自动点击到付款”，而应该被定义成“在严格边界内完成可审计的购物任务状态流转”。
执行摘要结论摘要
执行摘要：推荐落地方案
如果目标是做一套“安卓手机自动化调用 Agent”的可交付框架，并且未来能覆盖淘宝、1688、京东、拼多多，那么最合理的产品形态不是纯脚本工具，也不是纯视觉 Agent，而是“Agent 编排 + 确定性执行 + 购物状态机 + 人工确认”的组合。