phoneuse.md 11.4 KB

Edit Raw Blame History


这是最适合直接丢给 Codex、Claude Code、Cursor Agent 开始干活的版本。

我建议不要发完整聊天记录。

因为 AI Coding Agent 不擅长从 5000 字对话中提炼架构。

你应该把它整理成：


Vision
Problem
Architecture
Milestone
Technical Decisions
Open Questions


这种形式。

下面这个 Markdown 基本可以直接作为项目的 ARCHITECTURE.md。


Agent Phone Runtime
Vision
构建一个运行在 Root Android 上的 Agentic OS。

目标不是实现传统意义上的 Phone Use（截图 + OCR + 点击）。

目标是：

将 Android 上所有 App 虚拟化为 Agent 可调用的数据源和能力源。

最终形成：
Android
+
Agent Runtime
+
Personal Memory
+
Multi Agent
+
Semantic Connector Layer


成为下一代 Agent Phone 的基础设施。


Core Hypothesis
当前行业路线：
Screenshot
→ VLM
→ Reasoning
→ Tap


属于第一代 Agent。

存在：


慢
不稳定
UI变化即失效
无长期记忆


问题。


Agent Phone 应该采用：
App Runtime Access
→ Semantic Extraction
→ Personal Memory Graph
→ Agent Planning
→ Action Execution


架构。

Agent 不直接操作 UI。

Agent 操作：
Knowledge
Memory
Intent
Tools


UI 仅作为最后执行层。


Agent Formula
Agent = LLM × Tools × Data × Persona

目前已有：
LLM
Hermes Agent Runtime

提供：


Planner
Executor
Reflection
Multi-Agent


Persona
用户画像

包含：


Preference
Goal
Style
Relationship


Data
Personal Memory

包含：


Vector Memory
Timeline Memory
Graph Memory


缺失部分：
Universal Android Semantic Layer


Architecture
Layer 1
Android System
Android
Kernel
HAL


Layer 2
Event Collection Layer

负责采集系统级事件。

数据来源：
Accessibility
获取：


UI Tree
Text
Window State
Event


Notification
获取：


Message
Alert
Incoming Events


Intent
获取：


App Activity
Broadcast
Service


Clipboard
获取：


User Context


App Lifecycle
获取：


Foreground App
User Behavior


输出统一 Event Stream。

例如：
{
  "type":"message_received",
  "app":"wechat",
  "sender":"zhangsan"
}


Layer 3
Data Extraction Layer

目标：

绕过截图。

直接获取结构化数据。
SQLite
支持：


WeChat
Telegram
Mail
Notes


MMKV
支持：


Tencent Apps


Realm
支持：


Many Android Apps


LevelDB
支持：


Browser
Cache


输出：

统一数据模型。


Layer 4
Network Layer

获取：


HTTPS
WebSocket
gRPC


Root环境安装系统证书。

支持 MITM。

目标：

发现 App Runtime Data Schema。


Layer 5
Deep Runtime Layer

使用：


Frida
LSPosed
Xposed


目标：

获取 App 内部对象。

例如：
sendMessage()
queryConversation()


注意：

Frida 不是主系统。

Frida 是：
Special Forces


用于高价值 App。

例如：


WeChat
Alipay
Telegram
WhatsApp


Semantic Extraction Engine
核心模块。

目标：

把任意 App 数据映射为统一语义。

例如：

微信：
{
 "msg":"hello"
}


Telegram：
{
 "message":"hello"
}


统一映射：
{
 "entity":"Conversation"
}


统一实体：
Person
{
 "id":"",
 "name":""
}


Conversation
{
 "participants":[],
 "messages":[]
}


Event
{
 "title":"",
 "time":""
}


Task
{
 "status":"",
 "deadline":""
}


Document
{
 "title":"",
 "content":""
}


Personal Memory Graph
所有 App 数据进入统一 Memory。

结构：
Person
Conversation
Task
Document
Event
Location


Agent 永远查询：

Memory Graph

而不是：

具体 App。


MCP Architecture
Agent 永远不直接访问 App。

结构：
Agent
 ↓
MCP
 ↓
Semantic API
 ↓
Connector Runtime
 ↓
Android


统一 API：
send_message()

search_memory()

create_event()

create_task()

read_document()


Agent 不关心：


微信
Telegram
邮件


具体实现。


Execution Layer
优先级：
P1
System API


P2
Intent


P3
Accessibility


P4
Vision

最后使用。


Strategic Decision
不采用：
One App = One MCP


原因：

不可扩展。


采用：
One Android Runtime
↓
Universal Semantic Extraction
↓
Memory Graph
↓
Generic MCP APIs


架构。


Milestone
Phase 1
Android Event Bus

支持：


Accessibility
Notification
Intent
Clipboard


输出 Event Stream。


Phase 2
Data Extraction Engine

支持：


SQLite
MMKV
Realm
LevelDB


输出统一实体。


Phase 3
Memory Graph

构建：


Person
Conversation
Event
Task
Document


图谱。


Phase 4
Hermes Runtime Integration

接入：


Planner
Executor
Reflection


Phase 5
Semantic MCP

实现：
send_message()
create_task()
create_event()
search_memory()


Phase 6
Frida Runtime

针对：


WeChat
Telegram
Alipay


实现深度能力。


Collective Knowledge Network
定位
Layer 1-5 描述单台 Phone 本地的数据访问能力，是纵向的。

Collective Knowledge Network 是跨设备的云端层，是横向的。两者是不同维度：
云端
┌─────────────────────────────────────┐
│     Collective Knowledge Network    │  ← 横向，跨所有 Phone
└─────────────────────────────────────┘
         ↑ 上传经验      ↓ 下发知识

单台 Phone（纵向）
  Layer 5 — Frida Deep Runtime
  Layer 4 — Network MITM
  Layer 3 — Data Extraction
  Layer 2 — Event Collection
  Layer 1 — Android System


核心机制
每台 Phone 既是贡献者，也是受益者。

一台 Phone 成功探索了 WeChat 8.0.47 的 hook，全网所有 Phone 立刻受益。App 更新版本时，最快探索成功的 Phone 经验迅速扩散到全网。网络越大，每台 Phone 的能力越强。


上传内容
只上传结构性知识，不上传用户数据：
{
  "intent": "send_wechat_message",
  "app": "wechat",
  "app_version": "8.0.47",
  "execution_path": [
    {"method": "frida_hook", "target": "sendMessage", "success_rate": 0.98}
  ],
  "validated_by": 143
}


用户的消息内容、联系人等隐私数据不上传，只上传"用这个方法能成功"这一事实。


云端流程
收集 → 去重 → 清洗 → 验证 → 分发


验证机制：单台 Phone 上报不足以信任，需要 N 台 Phone 交叉验证后才升级为可信知识下发全网。


分发模式


模式
触发时机
适合场景


Pull（执行前查询）
Phone 执行某个意图前，先查云端
实时获取最新经验


Push（定期下发）
云端验证完成后主动推送
高频操作，减少延迟


实际采用混合模式：本地优先走缓存，缓存缺失或过期时触发云端 Pull。


护城河
这是产品真正的壁垒，不是技术本身，而是网络效应：
Phone 数量越多
→ 上传经验越多
→ 云端知识越丰富
→ 每台 Phone 能力越强
→ 吸引更多 Phone 加入


Long-term Goal
构建：

Agent Hypervisor for Android

让 Android 负责运行 App。

让 Agent Runtime 负责运行 Agent。

所有 App 最终成为：
Tool Provider
+
Memory Source


而不是用户直接操作的对象。


Technical Decisions
核心区分：读数据 vs 执行操作
App 数据采集和操作是两件性质完全不同的事：


目标
最优方案
原因


读数据（消息、联系人、日历）
SQLite 直读
稳定，App 更新不破坏 DB 结构


执行操作（发消息、创建任务）
Frida Hook
直调内部 API，毫秒级，不依赖 UI


Frida 的核心价值在操作，不在读数据。


读数据优先级
ContentProvider（系统级）
> SQLite 直读
> Accessibility Tree
> MITM 网络拦截
> Frida Hook（最后手段）


大多数 App 数据直接存在本地文件：
WeChat   → /data/data/com.tencent.mm/MicroMsg/*.db
Telegram → /data/data/org.telegram.messenger/files/
Gmail    → ContentProvider
Calendar → ContentProvider
Contacts → ContentProvider


Root 环境下 SQLite 直读比 Frida Hook 稳定 10 倍。App 更新会改函数签名，但很少改 DB 结构。


执行操作优先级
System Intent
> Frida Hook
> Accessibility Automation
> Vision（最后手段）


以发微信消息为例：
Option A: Accessibility 模拟点击 → 慢、脆、UI 依赖
Option B: Intent 调起 Activity  → 只能打开界面，无法直接发送
Option C: Frida hook sendMessage() → 直接调内部 API，毫秒级


Option C 是正解。


App Connector 模式
不建立"per-app Frida hook 数据库"，而是每个 App 一个 Connector。

Connector 内部按优先级自行选择最优实现：
class WeChatConnector:
    def read_messages()   # → SQLite
    def read_contacts()   # → SQLite
    def send_message()    # → Frida Hook
    def search_chat()     # → Frida Hook


Frida 只负责其他方式无法实现的操作能力。


Connector Knowledge Base vs Sub-agent
这是两个不同的概念，不要混淆。

| | 用途 | 形态 |
|--|------|------|
| Connector Knowledge Base | 记录如何操作这个 App | 配置文件 + DB，持久化 |
| Connector | 日常读写操作 | 代码驱动，不需要 Agent |
| Discovery Sub-agent | App 更新后重新探索 | 临时启动，用完退出 |
Connector Knowledge Base
每个 App 一个 Knowledge Base，存储：
wechat:
  version: 8.0.47
  messages_db: /data/data/com.tencent.mm/MicroMsg/xxx.db
  messages_table: message
  content_field: content
  send_hook: com.tencent.mm.sdk.platformtools.ab.sendMessage
  known_issues:
    - 8.0.45 之后 content 字段改名为 msg_content


这是经验积累，不是 Agent。
日常操作：Connector 直接驱动
发一条消息不需要 Agent 推理，直接调用：
WeChatConnector.send_message(to="zhangsan", content="hello")

Sub-agent：只用于探索
App 版本更新、旧 hook 失效时，临时启动 Discovery Sub-agent：
Discovery Sub-agent（临时）
  → 扫描新版本 DB 结构
  → 验证已知 hook 是否有效
  → 更新 Connector Knowledge Base
  → 退出


探索完成后退出，结果写入 Knowledge Base，下次直接复用。


高价值 App 优先级
Phase 1 只覆盖 5 个核心 App：


WeChat — 消息、联系人、朋友圈
Alipay — 支付、账单
Telegram — 消息、群组
Calendar — 日程、提醒
Mail — 邮件读写


这个版本已经接近一个创业项目的 Architecture RFC v0.1。

下一步我建议直接让 Claude Code 或 Codex 基于这个文档生成：


system_design.md
repo_structure.md
event_bus_design.md
memory_graph_schema.md
android_runtime_poc.md
90_day_build_plan.md


这样它就能从“想法讨论”进入“工程落地”阶段。