宜博 / phoneuse

phoneuse-todolist-2026-06-15.md 7.37 KB

Phoneuse Todolist v2 — 2026-06-15

由 claude-yi 通读 phoneuse.md / ARCHITECTURE.md / TASKS.md + 真机地面校验后产出。 用途:评审 → 确认后据此向 task-center 看板派发可执行 worker 任务。

0. 一句话现状

主干(Python/Termux 栈)真实可用,不是 stub;剩余工作的最大障碍不是技术,而是 TASKS.md 已严重过时——它标"未安装/BLOCKED"的 App 现在大多已装好。所以第一优先是做一次真机真实性审计,把进度钉死,再谈后续。

1. 系统目标与阶段(回顾)

Goal:Root 安卓上的 Agentic OS。放弃"截图→VLM→点击",改为 App Runtime Access → 语义抽取 → Personal Memory Graph → Agent 规划 → 执行。 Agent 只操作 Knowledge/Memory/Intent/Tools,UI 自动化仅兜底。

Phase:1 Event Bus → 2 Data Extraction → 3 Memory Graph → 4 Hermes 接入 → 5 Semantic MCP → 6 Frida → (云端) Collective Knowledge Network。 TASKS.md 拆成 11 个 Sprint。

2. 地面校验结果(2026-06-15,实测)

设备:Pixel 8 Pro / Android 16 / Root(Magisk)正常 / ADB 已授权。

代码核查(读源码):

  • Python/Termux 栈是真的:android_mcp.py 1533 行 / 38 个 MCP 工具全有真实现;connectors.py(511)、memory_graph.py(458)、cloud_knowledge.py、persona.py、mitm_proxy.py、frida_bridge.py 均为实代码。
  • "stub 水分"集中在 Kotlin APK 端(实现 B),而架构已选"Hermes 跑 Termux 本机"为基线,APK/gRPC 是低优支线。

运行时核查(连真机):

  • 服务在跑:event_server(uvicorn :8765)、frida-server、mitm_proxy 均存活;notification_monitor 已退场(符合 S1-07 废弃 dumpsys)。
  • App 安装态:WeChat ✅ / Telegram ✅ / Alipay ✅ / Gmail ✅ 全部已装。
  • 登录态:WeChat ✅ 已登录(EnMicroMsg.db 在) / Alipay ✅ 有数据库 / Telegram ⚠️ 装了未登录(无 DB) / Gmail ⚠️ 无 Google 账号。

与 TASKS.md 的冲突(过时点): | TASKS.md 旧标记 | 真机实况 | |---|---| | S6-02 Telegram 未安装 | 已安装(待登录) | | S7-05 / S8-03 Alipay 未安装 | 已安装 + 有数据库 | | S8-04 Mail App 未安装 | Gmail 已装(缺账号) | | S4-04 跨App去重 阻塞(无 Telegram) | Telegram 已装,登录后即可推进 |

结论:TASKS.md 的 BLOCKED/未安装标记已不可信,必须以真机审计为准。

3. Todolist(按"谁能干"分四轨)

🅰 真机供给轨 — 人工(worker 干不了)

编号 任务 解锁 状态
A1 Telegram 登录(已装,需扫码/短信登录) S6-02, S4-04 待你做
A2 Alipay 登录态确认(已有 DB,大概率已登录) S7-05, S8-03 待确认
A3 设备登 Google 账号 S5-02, S5-03, S8-05 待你做

A 轨是装 App/登账号/扫码,本质人工。worker 不做。

🅱 自动开发轨 — worker + adb 真机即可跑(带可验收标准)

B1 全工具真实性审计(地基,最高优先)

  • 目标:对 android_mcp.py 38 个 MCP 工具逐个连真机实跑,记录"工具 → 实测输出 / 报错",据此重写 TASKS.md 的状态标记。
  • 验收:
    1. 产出 38 行对照表(工具名 | 实跑命令 | 真实返回摘要 | 判定 真可用/降级/失效)。
    2. TASKS.md 按实测结果更新,贴 git diff。
    3. 列出"标 [x] 但实测失效"和"标 BLOCKED 但实测可做"两张清单。

B2 Realm / LevelDB 读取器补全

  • 目标:补 phoneuse.md Layer 3 缺口(当前只有 SQLite + MMKV)。
  • 验收:对设备上一个真实使用 Realm/LevelDB 的 App,贴出读出的样本 KV/记录。

B3 APK Intent broadcast 捕获

  • 目标:补 phoneuse.md Layer 2 的 Intent 采集缺口。
  • 验收:切 App / 收广播时,event bus 出现 intent 类型事件(贴 get_events 输出)。

B4 Telegram connector 落地(A1 登录后)

  • 目标:Telegram 登录后,实现/打通 get_telegram_messages 读真实消息。
  • 验收:贴出从真机 Telegram DB 读出的最近 N 条消息。
  • 前置:A1。

🅲 逆向攻坚轨 — worker 可试,成功率不保证

编号 任务 备注
C1 WeChat 朋友圈 SnsMicroMsg.db 加密 key 推导(S2-05) 独立 key,需逆向
C2 WeChat sendMessage Frida hook(S3-06) 8.x 混淆;已有 Accessibility 降级,ROI 低

🅳 长期 / 低优

编号 任务 备注
D1 云端 Knowledge 服务端(S11-04) 独立后端项目
D2 gRPC protoc codegen(DEBT-01) 当前架构用不到

🅴 设备控制广度补齐(对标 AgentPhone) — worker + 真机可自动开发

来源:对比商业竞品 AgentPhone(agenphone.yunke.ai)。两者路线镜像相反: AgentPhone = 广度·设备控制(免 Root,截图+Accessibility+系统 API,电话/短信/点滑屏/文件媒体); phoneuse = 深度·数据语义(Root,SQLite 直读+Frida+MITM+Memory Graph)。 AgentPhone 的设备控制面我们几乎全空,而这正是 phoneuse.md「执行层 P1 System API / P2 Intent / P3 Accessibility」规划了却没落地的部分。 护城河不能丢:Memory Graph、App 内部 SQLite 直读、Frida 深 Hook、MITM、Connector KB+Discovery、Persona、云端知识——这些 AgentPhone 没有,补广度时不稀释。

编号 任务 AgentPhone 对应 phoneuse 现状 Root 成本
E1 电话/短信工具组(call/send_sms/read_sms/list_call_log) call/hang_up/answer_call/send_sms/read_sms ❌ 全无 低
E2 设备控制原语(tap/swipe/input_text/screenshot/find_element/click_by_text) 同名一组 仅 get_ui_tree + 微信专用发送 低
E3 App+设备管理(open_app/list_packages/force_stop/get_foreground_app + battery/volume/location/lock) 同名两组 仅 list_event_apps 极低
E4 文件/媒体(list/read/write/delete_file、index_media、search_media) 同名一组 ❌ 低
E5 通知/覆盖层输出(post_notification/show_toast/show_overlay) 同名一组 只读通知 中(APK 侧)
E6 语音(speak_tts/play_audio) 同名 ❌ 低
E7 Vision 观察(phone_ai_observe 截图+VLM 兜底) phone_ai_observe ❌(刻意排 P4) 中
E8(探索) AI 外呼任务(agent 自动打电话) ai_outbound_call_task ❌ 高

4. 推荐执行顺序 & 看板派发策略

首批派到 task-center 自动开发(2026-06-15):B1、B2、B3、E1、E2、E3 —— 共 6 张可执行 worker 卡。

  • B1 设 high 优先级作地基(校准现状);E1/E2/E3/B2/B3 都是新增能力,不依赖 B1 的审计结论,可与其并行。
  • 独立性保障:每个新工具组放独立模块文件,android_mcp.py 仅加注册行,降低分支合并冲突;worker 各开独立分支,合并由你定。
  • 单台真机并发:受 maxConcurrent=3 限流;发送/点击类测试均约束在安全目标(文件传输助手 / 桌面 / 无数据 App),避免互相干扰。

暂不派(held):

  • B4(Telegram connector)→ 等 A1 登录后再派。
  • E4~E8 → 第二批,待首批落地评估后再排。
  • 🅒 C1/C2(逆向)→ 成功率低,先不自动开发。
  • 🅓 D1/D2(云端/gRPC)→ 低优,暂缓。
  • 🅐 A 轨 → 人工(装 App/登账号/扫码),worker 干不了,你择时处理;A1/A3 完成后回流解锁 B4 与若干 Sprint。

5. 状态

  • [x] 分轨与优先级已与 bo 确认。
  • [x] 🅴 对标 AgentPhone 轨已补入。
  • [x] 首批 6 卡(B1/B2/B3/E1/E2/E3)已派往 task-center。
  • [ ] A 轨(Telegram 登录 / Google 账号)待 bo 择时处理。