这套项目不适合一次性做成“大而全自动购物平台”；正确的节奏是先把设备控制、日志、状态机、审批链路做稳，再逐步把 Agent 的权限放大。
Phase 0：控制层打底
目标：不用 Agent，也能稳定把手机控制起来。
交付物
- 设备注册与健康检查
- 截图、录屏、前后台切换
tap / input / back / scroll / dump_ui- 单任务日志与工件归档
验收
- 能稳定启动指定 App
- 能稳定完成搜索框输入
- 能稳定进入详情页并返回
- 所有步骤都有截图和日志
Phase 1：规则式购物流程
目标：先不用大模型，先跑通确定性购物流程。
覆盖范围
- 淘宝 / 1688 / 京东 / 拼多多 四选一先做
- 搜索
- 筛选
- 详情页提取
- SKU 选择
- 加购
验收
- 在 20 个预设任务里，到达加购或确认页成功率 >= 80%
- 所有失败都能归因为页面未加载、弹窗、登录失效、规则不匹配之一
Phase 2：接入 Agent Planner
目标：让系统能处理更复杂、更开放的表达。
交付物
- LLM planner
- 结构化 action schema
- 失败恢复策略
- 屏幕描述与状态联合判定
验收
- 自然语言任务可被解析成结构化目标
- Planner 不得直接越过 policy engine 执行动作
- 关键步骤失败后支持至少一次恢复
Phase 3：购物状态机与审批流
目标：让系统从“能跑”变成“可控”。
交付物
- 统一状态机
approval_required节点- 账号/设备绑定
- 风控拦截器
验收
- 命中支付页时必须阻断
- 命中验证码时必须阻断
- 人工审批后可继续执行
- 审批历史可追溯
Phase 4：平台化与多设备
目标：从 demo 变成系统。
交付物
- 设备池调度
- 任务队列
- 运维控制台
- 指标与告警
验收
- 10 台设备并发任务时日志不串线
- 单设备故障不会拖垮全队列
- 任务可以重试、暂停、终止、迁移
测试矩阵
| 类型 | 重点 |
|---|---|
| 冒烟测试 | App 拉起、搜索、返回、截图 |
| 回归测试 | 常用商品路径、固定关键词、固定 SKU |
| 变体测试 | 不同分辨率、不同系统版本、不同语言 |
| 风控测试 | 登录失效、验证码、优惠券弹窗、支付页 |
| 恢复测试 | 页面超时、闪退、网络抖动、误点 |
| 审计测试 | 日志、录屏、截图、审批记录完整性 |
指标目标
业务指标
- 到确认页成功率
- 平均准备订单耗时
- 人工接管次数
系统指标
- 单步失败率
- 平均恢复耗时
- 设备可用率
- 账号异常率
版本边界建议
V1
- 单平台
- 单账号
- 单设备
- 到确认页停机
V2
- 双平台
- 审批后可提交订单但不支付
- 多设备调度
V3
- API + UI 混合链路
- 后台运营任务和采购任务分层
- 多租户隔离
实施建议
研发拆分
- 设备网关
- planner / policy
- 任务编排与审计后台
- 购物业务状态机
先后顺序
- 设备网关
- 任务日志与工件
- 规则式流程
- Agent planner
- 审批与多设备
完成定义
这个项目的“完成”不是“模型能自己下单”，而是：
- 能稳定完成订单准备流程
- 敏感动作前一定停机
- 所有动作可解释、可回放、可审计
- 页面改版时能快速定位是规则问题还是模型问题
做到这四点，才算真正有工程价值。