如果目标是做一套“安卓手机自动化调用 Agent”的可交付框架，并且未来能覆盖淘宝、1688、京东、拼多多，那么最合理的产品形态不是纯脚本工具，也不是纯视觉 Agent，而是“Agent 编排 + 确定性执行 + 购物状态机 + 人工确认”的组合。
推荐结论
推荐架构
- 上层：
OpenClaw/Midscene/ 自定义 LLM planner - 中层：
Policy Engine + Shopping State Machine - 下层：
UiAutomator2 + ADB - 兜底：OCR / 截图 / 图像匹配
- 设备：真机池或云机池
- 业务出口：有 API 能力的平台优先走官方开放平台
推荐 MVP 范围
- 多平台搜索与筛选
- 商品详情解析
- SKU 选择
- 加购或进入结算页
- 券信息识别
- 到确认订单页后暂停，等待人工确认
不建议作为 MVP 的能力
- 自动支付
- 批量刷号
- 绕过验证码
- 全视觉无状态机的闭环购买
为什么这个方案最现实
纯脚本路线的问题
Auto.js / Maestro / 固定脚本很快能做出 demo，但在真实购物 App 里会遇到：
- 页面改版
- 弹窗噪音
- 优惠券规则变化
- 风控验证
维护成本会持续上升。
纯 Agent 路线的问题
只靠视觉 Agent 去理解购物流程，在真实生产里太脆。
- 成功率波动大
- 失败不可解释
- 风险动作边界不清
混合路线的优势
Agent 负责“理解与规划”，执行器负责“稳定完成动作”，状态机负责“把风险挡住”。这是最适合长期演化的组合。
购物场景的业务判断
对消费者端
最实用的价值不是“替你付钱”，而是：
- 替你筛商品
- 替你看券
- 替你加购
- 替你准备订单
对商家 / 采购端
如果拥有开放平台权限，就应优先做：
- 商品、订单、库存走 API
- 手机 Agent 补齐后台运营、人审和非标准页面
这条路的商业价值更高，也更稳。
投入顺序
P0：控制层与日志
- 先把
ADB + UiAutomator2 + 截图 + 日志 + 录屏做稳 - 验证能否稳定搜索、进详情、加购
P1：Agent 编排
- 接入
Midscene或自定义 planner - 让模型具备页面理解和失败恢复能力
P2：购物状态机
- 明确
search_results -> product_detail -> sku_selection -> checkout_review -> approval_required - 把敏感动作全部锁在审批节点后
P3：平台化
- 设备池
- 任务队列
- 审计后台
- 多账号隔离
风险摘要
| 风险 | 结论 |
|---|---|
| Play Accessibility 政策 | 通用自主购物 Agent 不适合走 Play 分发 |
| 平台风控 | 必须假设验证码、登录失效、支付阻断随时出现 |
| 页面改版 | 必须有 selector、视觉和状态机三层兜底 |
| 支付链路 | 必须保留人工确认或转 API |
| 隐私数据 | 地址、实名、支付信息必须最小化处理 |
最终建议
把这个项目定义成：
“一套面向 Android 真机/云机的 Agent 自动化框架，用于购物 App 的搜索、筛选、加购、订单准备和受控结算流程；默认停在确认页，支付必须人工确认或通过官方开放平台完成。”
这个定义最容易做出能上线、能审计、能扩展的产品。