Appearance
AOHP：给 Android 装一个「Agent 原生」的操作系统层
论文精读 · 第 2 篇 论文：AOHP: An Open-Source OS-Level Agent Harness for Personalized, Efficient and Secure Interaction arXiv:2606.23449 · 2026.06 · Zhao et al.（OPPO + 港大）· 项目：Android Open Harness Project
与本站 Harness Engineering 系列 直接对话——尤其是 安全、运行时、工具 三篇。
TL;DR
今天的操作系统是给人设计的：一个应用一个图标，人去点。AOHP 反过来——让 agent 成为操作系统的一等公民。它在 AOSP（Android 开源版）上加了三层「agent 原生」机制：个性化服务组合、高效 agent 接口、安全信息流。结果：任务完成率 +21.12%，token 成本 -51.55%，安全策略合规更严。
一句话：它不是又一个 agent 框架，而是把框架该操心的事，下沉到了操作系统。
一、它想解决什么问题
先看清这个 mismatch。
当前的 agent（比如手机上的 GUI agent、电脑上的 computer-use agent）是怎么跑的？架在给人用的操作系统之上。它们靠截图识图、模拟点击、读剪贴板、截屏比对——整套交互是为人类视觉和手指设计的。agent 只能隔着这层「人机界面」去摸系统，像戴着厚手套弹钢琴。
这带来三个工程层面的痛：
| 痛点 | 具体表现 |
|---|---|
| 效率 | agent 要不断截图、识图、推理界面状态，token 和延迟双高 |
| 能力 | 很多系统能力（跨应用编排、后台服务、上下文）对 agent 不开放 |
| 安全 | agent 拿着用户的全量权限乱跑，没有信息流管控 |
业界在喊「agent-native OS」，但没有开源测试床让研究者去验证这些想法。AOHP 填的就是这个空：它不是新做一个 OS，而是改造成熟的 Android，把 agent 该有的支持加进去，同时保住 Android 的软硬件生态。
这个判断很关键：与其从零造 agent OS，不如把一个活着的 OS 改成 agent 原生。 前者注定是玩具，后者能立刻跑在真机上。
二、核心思想：Agent 作为 OS 一等公民
整篇的灵魂是一句话：
把 agent 从「应用之上的外挂」提升为「操作系统内的 actor」。
什么叫「一等公民」？对比一下：
| 维度 | 传统 OS（应用中心） | AOHP（agent 原生） |
|---|---|---|
| UI 主体 | 应用窗口给人看 | UI 自适应：能给 agent 暴露结构化接口 |
| 能力暴露 | 应用 API 面向开发者 | 运行时直接给 agent 暴露原子能力 |
| 调用方式 | agent 隔着屏幕模拟 | agent 走原生接口，免截图 |
| 安全模型 | 应用级权限 | 信息流级权限：数据从哪来到哪去 |
| 个性化 | 应用各自为政 | 服务可被 agent 组合成个性化流程 |
注意「信息流级权限」这一行。它呼应本站 Harness Engineering · 安全 反复强调的原则：
应用级权限太粗，挡不住 agent 把敏感数据搬进非敏感通道。真正要管的是信息流，不是入口。
AOHP 把这件事做进了系统层——不是在 agent 框架里打补丁，而是操作系统本身就知道「这条数据该不该流到那个 agent」。
三层机制是上面这张表的具体落地。
三、三大机制逐个拆
3.1 个性化服务组合（Personalized Service Composition）
传统 Android：一个任务 = 打开一个 app。要「订机票 + 加日历 + 发消息」，你得切三个 app，agent 得模拟三次跳转，中间状态全靠截图记。
AOHP 的做法：把应用能力拆成可组合的「服务」，agent 不再启动 app，而是直接调用服务，还能把多个服务编排成一条个性化流水线。
工程价值：
- 跨应用编排变成原生能力，不是 agent 在外层硬拼
- 个性化不是「记住偏好」，而是「为这个用户动态拼出一条服务链」
- 中间状态由 OS 持有，agent 不必背在上下文里
这跟本站 Harness Engineering · 运行时 里讲的「运行时是 agent 的记忆与编排底座」是同一种工程审美——把状态管理从 agent 上下文里挪出去，交给运行时。
3.2 高效 Agent 接口（Efficient Agent Interfaces）
这是省下 51% token 的关键。
GUI agent 的 token 大头花在哪？截图 + 识图。一张截图喂给多模态模型，几十上百 KB 的 token 就进去了，而且还得让它「理解」按钮在哪。
AOHP 给 agent 暴露结构化接口：界面的可交互元素、状态、语义，直接以 agent 友好的格式提供。agent 不用「看」屏幕，而是查询屏幕。
| 接口方式 | token 成本 | 准确性 |
|---|---|---|
| 截图 + 多模态识图 | 高 | 受视觉模型限制 |
| AOHP 结构化接口 | 低 | 系统直供，无歧义 |
这正对应 Harness Engineering · 工具 的核心论点：
给 agent 的接口越「机器友好」，agent 越省 token、越少出错。把人机界面当 agent 界面用，是在用最贵的带宽传最模糊的信号。
3.3 安全信息流（Secure Information Flow）
最值得展开的一层。
传统 Android 权限模型：app 申请权限，用户授权，app 拿到权限就能读。agent 跑在上面时——它继承用户的全部权限，等于一个能读通讯录、相册、支付的超级实体。
光靠「应用级权限」防不住这类攻击：
agent 把通讯录里的电话号码读出来，写进一个看似无害的消息里发出去。每一步都「合法」，但信息流是泄露。
AOHP 把安全下沉到信息流追踪：系统标记数据的敏感度，追踪它流向哪个 agent、哪个服务、哪个出口。敏感数据想流出非敏感通道，系统层直接拦。
这呼应 Harness Engineering · 安全 的设计准则：
沙箱、最小权限、信息流标记——三件套缺一不可。应用级权限是工业革命前的城墙，挡不住现代的信息流动。
四、架构一览
┌─────────────────────────────────────────────┐
│ Agent（一等公民） │
│ 不再隔着屏幕，走原生接口直接与系统交互 │
└───────────────┬─────────────────────────────┘
│ ① 结构化查询（替代截图）
│ ② 服务组合（替代 app 跳转）
│ ③ 信息流标记（替代粗权限）
┌───────▼────────┐
│ AOHP 层 │ ← AOSP 之上新增的 agent 原生层
│ (Open Harness) │
└───────┬────────┘
│
┌───────▼────────┐
│ AOSP 原生 │ ← 成熟软硬件生态全保留
│ Android 内核 │
└────────────────┘三层不是堆叠的中间件，而是长进系统内核与运行时的机制。这点很关键：如果是中间件，agent 还得多一跳；正因为是系统原生，省下的 token 才是真省。
五、实验结果
AOHP 在一组覆盖 OS agent 关键能力的挑战性任务上评测：
| 指标 | AOHP vs 传统 GUI agent |
|---|---|
| 任务完成率 | +21.12% |
| 执行 token 成本 | -51.55% |
| 安全策略合规 | 明显更严 |
三个数字讲了一个完整的故事：
- +21% 完成率 → 能力下沉后，agent 干得更准
- -51% token → 不靠截图靠接口，成本腰斩
- 安全合规 → 信息流层兜底，不是 agent 自觉
值得注意：51% 的 token 削减不是靠模型变小，而是靠接口改对。这是「harness 工程比模型升级更省」的硬证据。
六、工程对照：AOHP 验证了什么
AOHP 的三个设计，恰好对应本站 Harness Engineering 系列里三个核心论断，等于在系统层给它们做了实证：
| AOHP 机制 | 对应论断 | 系列文章 |
|---|---|---|
| 结构化 agent 接口 | 机器友好接口 > 人机界面 | 工具 |
| 个性化服务组合 | 运行时持有状态，agent 不背 | 运行时 |
| 安全信息流 | 管信息流，不管入口 | 安全 |
更深一层的启发：harness 的边界到底该画在哪？
之前本站的 harness 工程都停在「应用之上」——pi、Claude Code、各种 agent 框架，都是跑在 OS 之上的程序。AOHP 提出：最彻底的 harness 就是 OS 本身。当 agent 成为常态交互方式，OS 必须长出 agent 原生的能力，否则永远在给人机界面打补丁。
七、启发与局限
启发：
- 省 token 的第一杠杆是接口，不是模型。 与其等更小的模型，不如先把 agent 看屏幕改成查接口。AOHP 用系统层改动换了 51% 成本，这是模型压缩很难企及的比例。
- 信息流安全必须下沉。 在 agent 框架层做信息流追踪太晚——数据已经被 agent 读走了。AOHP 在 OS 层做，才是最早的拦截点。
- 「agent-native OS」不是噱头，是真问题。 当一个系统的主要使用者从人变成 agent，它的人机界面设计就过时了，必须长出 agent 界面。
局限：
- 强绑 Android。 AOHP = AOSP 改造，思路难以直接搬到 iOS / 桌面 OS。但作为「概念证明 + 开源测试床」，这个取舍合理。
- 个性化服务的拆分粒度没讲透。 把 app 拆成「可组合服务」听起来美，但谁负责拆？应用开发者配合吗？这是生态问题，论文里偏理想。
- 评测规模待扩。 初步实验显示了清晰优势，但覆盖的任务面和对抗场景还需更大规模验证，尤其是安全层的攻防。
一句话点评： AOHP 把「harness 工程」推到了它的逻辑终点——如果 agent 是未来的主要用户，那最该被改造的 harness 就是操作系统本身。它不是又一个框架，而是给「agent-native OS」这个词填了第一个开源实物。