这是最适合直接丢给 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 可调用的数据源和能力源。

最终形成：

```text
Android
+
Agent Runtime
+
Personal Memory
+
Multi Agent
+
Semantic Connector Layer
```

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

---

# Core Hypothesis

当前行业路线：

```text
Screenshot
→ VLM
→ Reasoning
→ Tap
```

属于第一代 Agent。

存在：

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

问题。

---

Agent Phone 应该采用：

```text
App Runtime Access
→ Semantic Extraction
→ Personal Memory Graph
→ Agent Planning
→ Action Execution
```

架构。

Agent 不直接操作 UI。

Agent 操作：

```text
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

---

缺失部分：

```text
Universal Android Semantic Layer
```

---

# Architecture

## Layer 1

Android System

```text
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。

例如：

```json
{
  "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 内部对象。

例如：

```java
sendMessage()
queryConversation()
```

---

注意：

Frida 不是主系统。

Frida 是：

```text
Special Forces
```

用于高价值 App。

例如：

* WeChat
* Alipay
* Telegram
* WhatsApp

---

# Semantic Extraction Engine

核心模块。

目标：

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

例如：

微信：

```json
{
 "msg":"hello"
}
```

Telegram：

```json
{
 "message":"hello"
}
```

统一映射：

```json
{
 "entity":"Conversation"
}
```

---

统一实体：

## Person

```json
{
 "id":"",
 "name":""
}
```

---

## Conversation

```json
{
 "participants":[],
 "messages":[]
}
```

---

## Event

```json
{
 "title":"",
 "time":""
}
```

---

## Task

```json
{
 "status":"",
 "deadline":""
}
```

---

## Document

```json
{
 "title":"",
 "content":""
}
```

---

# Personal Memory Graph

所有 App 数据进入统一 Memory。

结构：

```text
Person
Conversation
Task
Document
Event
Location
```

Agent 永远查询：

Memory Graph

而不是：

具体 App。

---

# MCP Architecture

Agent 永远不直接访问 App。

结构：

```text
Agent
 ↓
MCP
 ↓
Semantic API
 ↓
Connector Runtime
 ↓
Android
```

---

统一 API：

```python
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

不采用：

```text
One App = One MCP
```

原因：

不可扩展。

---

采用：

```text
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

实现：

```python
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 的能力越强。

---

## 上传内容

只上传结构性知识，不上传用户数据：

```json
{
  "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 最终成为：

```text
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 内部按优先级自行选择最优实现：

```python
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，存储：

```yaml
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 推理，直接调用：

```python
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：

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

---

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

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

1. `system_design.md`
2. `repo_structure.md`
3. `event_bus_design.md`
4. `memory_graph_schema.md`
5. `android_runtime_poc.md`
6. `90_day_build_plan.md`

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