Document Library

文档总览

所有内容都按「方案判断」「业务决策」「工程蓝图」「来源索引」四层组织，便于直接交给实现团队。

方案全景5 篇

方案全景

先判断用什么栈、什么边界、什么业务模式最合理。

这套文档的核心结论是：安卓手机自动化要分成编排层、执行层、设备层三段设计；购物场景要优先做到“搜索、比价、加购、领券、到提交页”，而不是一开始就追求无人值守自动支付。

截至 2026 年 3 月 29 日，Android 自动化生态可以明确分成“底座执行器”“视觉/脚本自动化”“Agent 编排层”“研究 benchmark / 模拟环境”四类；把它们混成一个概念，会直接导致架构选型错误。

手机自动化里的 Agent，不应该直接拥有“看到页面就决定支付”的绝对权限；它更应该是一个被策略引擎、状态机、确定性执行器和审计系统包住的规划器。

淘宝、1688、京东、拼多多这类购物 App 的自动化，不应该被定义成“自动点击到付款”，而应该被定义成“在严格边界内完成可审计的购物任务状态流转”。

手机 Agent 自动化最容易出问题的，不是模型效果，而是权限、风控、支付和数据边界；如果这几条线不先写死，后面框架再强也会在上线前被卡死。

执行摘要1 篇

给 owner / 投资人 / 合作方看的结论版。

如果目标是做一套“安卓手机自动化调用 Agent”的可交付框架，并且未来能覆盖淘宝、1688、京东、拼多多，那么最合理的产品形态不是纯脚本工具，也不是纯视觉 Agent，而是“Agent 编排 + 确定性执行 + 购物状态机 + 人工确认”的组合。

架构蓝图2 篇

面向实现团队的架构、接口、里程碑与验收标准。

如果要把这套方案交给工程团队实现，应该把它理解为一个“面向真机的任务执行平台”，而不是一个简单脚本仓库。

这套项目不适合一次性做成“大而全自动购物平台”；正确的节奏是先把设备控制、日志、状态机、审批链路做稳，再逐步把 Agent 的权限放大。

来源索引1 篇

本轮调研使用的主要官方资料、仓库与产品文档。

以下来源均在 2026-03-29 核对过入口可访问性，优先使用官方文档、官方仓库或官方平台首页；若某条结论属于我基于多条来源做出的归纳，会在正文里明确写成“判断”而不是“官方原话”。