主站

知识库

chatgpt

21分钟阅读

核心判断

Humon 不应被定义成“更强的 Android 监控 MCP”，而应是一个“人类状态感知与建模系统”。

你整理的“全视窗”路线解决的是：

AI 如何看见、理解、操作手机。

Humon 真正要解决的是：

手机里发生的事情，与人的注意力、疲劳、情绪、活动、睡眠、社交状态和生活节律之间，究竟是什么关系？

因此更合适的结构是：

Humon
├── Phone Sense        手机行为与界面感知
├── Body Sense         活动、睡眠、心率等身体数据
├── Environment Sense  位置、时间、网络、环境
├── Self Report        用户主动表达与状态标注
├── State Engine       人类状态推断
└── Hermes Bridge      向 Manas 暴露状态，而非倾倒原始数据

你所说的“全视窗”，应当成为 Humon 的 Phone Sense 子系统，而不是 Humon 的全部。

一、对现有生态总结的校准

Codex 核验（2026-10-10）：Android 官方读取文档 区分前台读取与需要额外用户权限的后台读取；还要检查设备/SDK 支持和每类数据权限。Health Connect 主要整合已有数据，不代表普通手机能自行测量心率、睡眠或皮肤温度，也不保证持续后台采集。2026 年 6 月起设备步数来源采用设备特定 Synthetic Package Name；Android 14 且 SDK Extension 20+ 可提供设备步数。本文人的疲劳、情绪等推断是产品研究假设，未作医学有效性验证。

1. RikkaHub：适合作为 Android AI 外壳，不是监控系统

RikkaHub 当前公开仓库约 6.1k stars，定位仍是多模型 Android LLM 客户端，支持 MCP、类似 ChatGPT 的记忆、Agent 定制，以及基于 proot 的 Linux workspace。公开功能中并没有持续读取其他 App、通知流或人类状态监控能力。(GitHub)

对 Humon 的可借鉴部分：

  • Kotlin + Compose 的成熟 Android 架构

  • Room/DataStore 数据层

  • MCP 客户端与多模型配置

  • 本地 workspace

  • Agent 与记忆 UI

  • Android 后台任务管理经验

不建议：

  • 直接 Fork RikkaHub 改成 Humon

  • 把聊天数据库当作人类状态数据库

  • 把 Humon 的感知逻辑耦合进 LLM 客户端

评价：交互壳参考价值高，感知核心参考价值低。

2. Screenpipe：Humon 最值得借鉴的架构，但不能直接移植

Screenpipe 当前已约 20k stars，而不是清单中的 5k。它采用事件驱动采集：应用切换、点击、输入停顿、滚动等事件发生时，才保存截图和无障碍树；无障碍数据不可用时再回退 OCR。它还采集音频、键盘输入和应用切换，使用本地 SQLite/FTS，提供 REST API、MCP 和基于权限策略的 Pipes。(GitHub)

它对 Humon 最重要的启发是：

不要连续录制全部屏幕
而要：
事件触发 → 结构化采集 → 去重 → 关键帧 → 可检索时间线

尤其值得继承：

  • Accessibility-first，OCR fallback

  • 关键事件触发，而非固定高频截图

  • 原始帧、结构化文本、音频转录分层存储

  • App 和窗口黑名单

  • 每个 Agent 独立数据权限

  • “当天回顾”“时间分布”“工作状态”等派生任务

  • 本地优先、可删除、可导出

但它目前公开支持的是 macOS、Windows 和 Linux桌面端，并非 Android；另外当前许可证是 source-available，商业使用有额外限制，因此适合参考架构，不宜直接复制核心代码。(GitHub)

评价：最佳架构导师，不是 Android 现成底座。

3. Mobile MCP：非常适合“操作手机”，不适合长期监控人

Mobile MCP 已经提供了一套比较成熟的手机 MCP 工具：

  • 列设备、应用

  • UI 元素树

  • 截图与录屏

  • 点击、长按、滑动

  • 输入文字

  • 启动、停止和安装 App

  • 硬件按键

  • 崩溃报告

它优先读取 Accessibility Tree，必要时才用截图坐标。真实 Android 手机依赖 ADB、USB 调试和授权。(GitHub)

它可以直接充当 Humon 的：

  • 调试工具

  • UI 树格式参考

  • MCP 命名参考

  • 主动探索手机 App 的执行器

  • Humon 开发期间的真值验证器

但它不是理想的 Humon 常驻采集层，因为：

  • 主要是 PC 通过 ADB 驱动手机

  • 偏请求—响应，而不是持续事件流

  • 没有基线、状态推断和长期时间线

  • 更接近“手机上的 Playwright”

评价：适合复用工具层，不适合担当 Humon 大脑。

4. Mobilerun / Droidrun：适合作为 Agent 执行参考

Mobilerun 通过手机 Portal Runtime 提供 UI 树、截图、输入、手势、App 启动和设备状态，并支持视觉模式、规划模式、轨迹保存和 App Cards。(GitHub)

与 Mobile MCP 相比，它更接近：

Android Portal App
        ↓
远程 Agent Runtime
        ↓
自然语言任务执行

Humon 可以参考它的：

  • 手机端 Portal 常驻服务

  • UI 树与截图统一事件格式

  • 轨迹保存

  • App-specific knowledge

  • Agent 调试和回放

但同样，它研究的是完成任务，不是理解人类。

5. Beiwe：比绝大多数 Android MCP 更接近 Humon 本质

Beiwe 的公开定位就是智能手机数字表型研究平台，也就是根据手机传感和行为数据，研究人的生活、活动和状态。(GitHub)

它代表了另一条技术传统：

Mobile MCP / Droidrun
关注：手机当前页面上有什么，下一步点哪里
 
Beiwe / 数字表型
关注：这个人最近睡眠、活动、社交和生活节律发生了什么变化

Humon 应当融合两条路线：

Screenpipe 的数字生活记录 + Beiwe 的人类状态建模 + Mobile MCP 的手机操作能力。

二、你原来的 T1→T4 权限梯度需要修正

T1 “零权限”并不能稳定获取当前 App

Android 的 UsageStatsManager 可以提供应用使用时长、使用事件、屏幕交互和锁屏事件，但需要用户授予特殊的 PACKAGE_USAGE_STATS 使用情况访问权限。它不属于普通运行时弹窗权限，更不能称作真正的零权限。(Android Developers)

更准确的划分是：

P0：普通应用、最低权限

可获得：

  • 本 App 自身状态

  • 电量、充电、网络

  • 时间、时区

  • 屏幕方向

  • 用户主动录入

  • 部分普通硬件传感器

不能稳定获得：

  • 当前前台 App

  • 其他 App 内容

  • 通知内容

  • 全局 UI 树

P1：特殊授权

包括：

  • Usage Access

  • Notification Access

  • Activity Recognition

  • Health Connect

  • 可选位置权限

这一级其实已经足够构建 Humon 的第一版。

T2：无障碍服务是 Phone Sense 的主力

AccessibilityService 可以接收焦点变化、按钮点击等 UI 状态事件，还可以请求读取活动窗口的节点树，包括窗口、文本、控件类型、坐标和可操作状态。Android 官方也提醒，节点树可能发生变化或包含过期信息，因此不能把一次 UI dump 当作绝对真值。(Android Developers)

它适合获取：

  • 当前 App 与窗口

  • UI 树

  • 页面文本

  • 点击、滚动、焦点和文本变化

  • 页面切换路径

  • 交互节奏

  • 可选的自动点击与手势

但 Humon 不应逐事件全部上传，而应在手机端先做：

原始 AccessibilityEvent
    ↓
500–1000ms 合并窗口
    ↓
UI 树哈希去重
    ↓
语义差异提取
    ↓
生成 PhoneEpisode

例如：

{
  "app": "com.xingin.xhs",
  "started_at": "01:22:14",
  "ended_at": "01:37:51",
  "activity": "browsing_feed",
  "content_topics": ["AI", "情感"],
  "interaction": {
    "scrolls": 84,
    "clicks": 7,
    "typing_seconds": 0
  }
}

而不是保存 84 次滚动的完整 UI 树。

T3：Shizuku 是高权限桥，不是“准 Root”

Shizuku 让普通 App 通过一个由 ADB 或 Root 启动的服务，以较高权限调用部分系统 API。官方明确说明：ADB 权限本身仍然有限，而且不同 Android 版本和厂商实现可能不同。(GitHub)

无 Root 情况下，通过无线调试启动 Shizuku，Android 11 以上通常每次重启后都要重新启动服务。(Shizuku)

适合 Humon 的功能包括：

  • 查询进程和任务栈

  • dumpsys 系列状态

  • 更完整的包与组件信息

  • 部分系统设置

  • ADB shell 命令

  • 调试 UIAutomator / screencap

  • 开发与故障诊断

不适合把它当作核心依赖，因为：

  • 手机重启后可能失效

  • 厂商限制差异很大

  • ADB 权限不等于系统权限

  • 普通用户部署复杂

因此应设计为：

Humon Core
不依赖 Shizuku
 
Humon Shizuku Adapter
检测到可用时，增加增强字段

T4：Root 只能作为实验扩展

Root 可以提供更多系统状态、文件和日志，但不应成为 Humon 的默认路径。

因为 Humon 的目标不是“突破一切边界”，而是获得稳定、可解释、长期连续的人类状态信号。一个重启后容易失效、不同 ROM 行为不同、系统升级后可能断裂的深度采集路径，反而会损坏长期数据的一致性。

Root 层应只用于：

  • 私人研究机

  • 验证系统内部数据

  • 特定厂商兼容补丁

  • 高级日志

  • 实验性传感器

三、MediaProjection 不适合作为隐形常驻录屏底座

标准 Android MediaProjection 要求每个录屏会话都获得用户同意。Android 14 以上，一个授权 token 只能用于一次 createVirtualDisplay()；锁屏、用户停止、另一个投屏会话启动或进程死亡，也会终止当前会话。(Android Developers)

所以 Humon 不应把“持续录屏”设计成默认能力。

更合理的是：

Accessibility UI tree
    ↓ 无法理解
Accessibility screenshot
    ↓ 仍无法理解
用户主动开启 MediaProjection
    ↓
短时视觉采集

截图策略建议：

  • UI 树有足够文本时：不截图

  • 页面哈希未变化：不截图

  • FLAG_SECURE 或敏感 App：不截图

  • 银行、密码管理器、身份验证器：默认永久黑名单

  • 图片、视频、游戏等非结构化页面：按关键帧截图

  • 原始截图短期保存，提取完语义后自动删除

四、Humon 应使用“感知深度”，而不是单纯“权限深度”

我建议把梯度改成：

层级名称回答的问题
H0Presence人是否在使用手机、设备是否在线
H1Rhythm什么时候用、用了多久、切换多频繁
H2Activity在走路、静止、乘车、睡眠还是运动
H3Semantics正在看什么、写什么、处理什么任务
H4State注意力、疲劳、压力、情绪可能怎样
H5Pattern相比个人长期基线，最近发生了什么变化

这比 T1–T4 更接近 Humon 的目标。

五、Humon 应监控的核心信号

1. 手机行为

  • 屏幕亮灭与解锁次数

  • 前台 App 与使用时长

  • App 切换频率

  • 单次连续使用长度

  • 夜间使用

  • 通知数量及来源

  • 通知到打开 App 的延迟

  • 滚动、点击、输入节奏

  • 输入后大量删除或反复修改

  • 页面内容类别

2. 身体活动

Android Activity Recognition 可以低功耗识别静止、步行、跑步、骑车和乘车等活动，并提供进入/离开某种活动的 transition 事件。Google 也建议优先用 transition API，而不是持续读取容易产生噪声的原始分类。(Google for Developers)

3. 睡眠与健康

Health Connect 在用户授权后可以整合心率、步数、睡眠 session、运动、皮肤温度和其他健康数据，在支持的设备上、额外获准后台读取权限后允许后台读取对应数据。(Android Developers)

Humon 不一定自己采集心率，而应优先：

手表 / 健康 App
        ↓
Health Connect
        ↓
Humon

这样兼容性远高于逐个适配小米、三星、华为或 Garmin。

4. 主动自报

机器推断永远需要校准。

建议悬浮球或通知提供极短输入：

现在状态：
精力  1–5
情绪  1–5
压力  1–5
正在做什么？

自报不是多余数据，而是训练个人状态模型的标签。

六、状态模型不能直接让 LLM“看截图猜心情”

正确的数据管道应是：

Observation 原始观察
    ↓
Feature 数值特征
    ↓
Episode 连续事件片段
    ↓
State Hypothesis 状态假设
    ↓
Human Confirmation 用户校正
    ↓
Personal Baseline 个人基线

例如：

{
  "state": "attention_fragmented",
  "confidence": 0.76,
  "window": "last_45_minutes",
  "evidence": [
    "18次App切换",
    "7次通知打断",
    "最长连续专注仅4分12秒",
    "输入任务中断3次"
  ],
  "counter_evidence": [
    "当前正在主动查找多个资料来源"
  ]
}

Humon 输出的应该是：

“疑似注意力碎片化，置信度 0.76。”

而不是：

“你现在焦虑。”

尤其不能把行为代理指标直接当作心理诊断。

七、推荐的系统架构

┌──────────────────────────────┐
│ Android: Humon Node          │
│                              │
│ Usage / Notification         │
│ Accessibility / Activity     │
│ Health Connect / Device      │
│ Optional Shizuku             │
└──────────────┬───────────────┘
               │ 加密事件流
               ▼
┌──────────────────────────────┐
│ PC/WSL: Humon Gateway        │
│                              │
│ 事件接收 / 去重 / 时间线     │
│ 特征计算 / 状态模型 / 策略   │
│ SQLite/Timeseries/Object     │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Humon MCP                    │
│ Resources / Tools / Events   │
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ Manas                        │
│ 理解、判断、是否干预         │
└──────────────────────────────┘

为什么 MCP 服务放在 PC，不放在手机

手机更适合作为传感器节点：

  • 后台网络可能被 ROM 杀死

  • MCP stdio 不适合 Android App

  • 手机入站连接复杂

  • Hermes 本来就运行在 WSL

  • 状态推断和历史检索会消耗更多资源

因此使用手机主动发起的：

HTTPS / WebSocket / gRPC stream

把事件推送至 PC。

PC 上的 Humon Gateway 再向 Hermes 提供 MCP。

八、Humon 与现有 Agent/记忆体系的关系

建议明确边界：

Humon
观察人类，生成状态证据
 
Manas
理解目标、判断是否需要回应或干预
 
Alaya / gbrain
保存长期规律与已经确认的个人模式
 
scope-recall
只保存近期有用的状态摘要
 
Keeper / Anchor
维护 Humon 服务健康，不读取全部私人内容

尤其不要把原始截图、完整通知和分钟级传感数据直接塞进 gbrain 或 scope-recall。

正确方式是：

Humon 专用事件库
    ↓
每日/事件级摘要
    ↓
经过确认的重要模式
    ↓
Alaya / gbrain

例如可以写入长期记忆的是：

用户通常在凌晨连续切换短视频与聊天 App 时，第二天自报精力显著下降。

不应该写入的是：

01:34:21 打开微信，01:34:25 收到某人的具体消息内容。

九、MCP 不应只是 18 个截图和点击工具

建议分成三类。

Resources

humon://now
humon://timeline/today
humon://state/attention
humon://state/energy
humon://state/sleep
humon://baseline
humon://anomalies

读取工具

humon_get_current_state
humon_get_timeline
humon_get_evidence
humon_get_app_usage
humon_get_attention_metrics
humon_get_notification_load
humon_get_activity_summary
humon_get_sleep_summary
humon_get_health_summary
humon_get_current_ui_context
humon_compare_baseline
humon_detect_anomalies

用户控制工具

humon_submit_checkin
humon_mark_episode
humon_pause_capture
humon_resume_capture
humon_set_capture_policy
humon_redact_interval
humon_delete_interval
humon_exclude_app
humon_explain_state

其中默认给 Manas 的应当主要是读取和解释工具。

删除、策略修改、恢复录制之类的操作，应要求明确授权。

十、最合理的实施顺序

第一阶段：不做全视窗

先实现：

  • 屏幕开关与解锁

  • Usage Stats

  • App 使用 session

  • Notification Listener

  • 电量、充电、网络

  • Activity Recognition

  • 主动状态自报

  • 本地事件库

  • Humon Gateway

  • humon_get_current_state

  • humon_get_timeline

这一版已经可以得到：

  • 作息

  • 手机依赖程度

  • 注意力碎片化

  • 夜间使用

  • 通知压力

  • 活动与静止节律

第二阶段：无障碍语义层

加入：

  • 当前 UI 树

  • 页面变化事件

  • 关键文本

  • 点击、输入、滚动模式

  • App 内页面类别

  • 敏感字段过滤

  • 事件驱动关键帧

第三阶段：身体状态层

加入：

  • Health Connect

  • 心率

  • 步数

  • 睡眠

  • 锻炼

  • 可穿戴设备数据

第四阶段：增强权限

加入：

  • Shizuku adapter

  • dumpsys

  • 进程和任务状态

  • 更完整设备诊断

  • Mobile MCP / Mobilerun 执行桥

第五阶段：视觉与音频

最后才考虑：

  • 短时 MediaProjection

  • OCR

  • 环境音事件

  • 语音活动检测

  • 屏幕视觉模型

最终定位

你原来的描述：

全视窗是“AI 能理解手机里正在发生的一切”。

可以保留为 Humon Phone Sense 的愿景。

但 Humon 整体更准确的一句话应该是：

Humon 不是监视手机，而是以手机和可穿戴设备为感官，持续建立对人的状态、行为和生活节律的可解释认识。

在现有项目中：

  • Screenpipe：借鉴时间线、事件驱动和权限治理

  • Mobile MCP / Mobilerun：借鉴 Android UI 与操作接口

  • RikkaHub：借鉴 Android Agent 外壳和 MCP 客户端

  • Beiwe / 数字表型体系：借鉴真正的人类状态建模

  • Shizuku：只作为可选增强层

  • 全视窗：作为 Humon 的视觉与手机语义子系统

这条路线比单纯堆到“18+ MCP Tools、UI 树、录屏、ADB、Root”更接近一个真正可长期使用的 Humon。

关系图谱