AOHP虚拟显示服务：Android Agent四大交互能力

AOHP深度解读：当操作系统开始为AI Agent设计

当前主流的各类操作系统，不管是移动平台的Android、iOS，还是桌面端的Windows、macOS，本质上都是围绕「人-应用」的交互逻辑打造的，这套模型包含几个核心隐含前提：

• 单应用前台独占：用户一次只能在一个应用中进行操作，操作系统负责切换当前前台窗口到正在使用的应用
• GUI为主要交互界面：用户主要通过视觉观察和触控操作来完成交互
• App边界即权限边界：每个应用的权限在安装时由用户授予，跨应用的数据传递需要用户手动参与，比如通过分享菜单、Intent选择器等方式
• 瞬态交互无状态：用户离开应用后，系统不会保留操作意图，下次打开应用时一切都需要重新开始

这些设计对于人类用户来说是合理且高效的，但当交互主体换成AI Agent时，每一个前提都成了阻碍。

AI Agent在传统操作系统上的适配困境

AI Agent的核心工作流程是接收自然语言指令、拆解为多步操作序列、调用工具执行、观察反馈并调整下一步，但在传统OS上运行时，这个流程存在三类结构性矛盾：

• 仅能通过截图+视觉理解+模拟点击操作：就像蒙眼的人靠触觉摸索设备，每一次操作都需要先截图识别界面、再推理点击位置，再执行点击，不仅消耗大量计算资源，还容易在动态UI变化时失败，比如简单的“在淘宝搜索跑鞋再到京东比价”，Agent需要反复截屏、识别按钮、定位输入框，整个过程充满冗余和不确定性。
• 安全模型与Agent需求冲突：当前的方案要么是应用内Agent，只能调用自身API无法跨应用协作，要么是全局高权限Agent，将系统调用、文件读写、进程操作全部交给大模型，缺乏细粒度的安全隔离，两者都无法兼顾全系统操作能力和细粒度安全管控。
• 交互低效且缺乏个性化：Agent每次执行任务都需要从零开始，重新枚举已安装应用、识别UI布局、推理操作路径，没有持久化的记忆能力，无法记住用户的使用习惯，比如常用的文件存储位置、常用邮箱、偏好的支付方式，每次都重复相同的推理过程，消耗大量计算资源和Token。

传统操作系统是以应用为中心的，用户需要手动编排不同应用之间的协作流程；而AI Agent则需要以任务意图为中心，操作系统应当主动组合跨应用的服务能力来满足用户的需求。AOHP的核心洞察正是：与其让Agent去适应现有操作系统，不如让操作系统来适配Agent，将Android从“以应用为中心”改造成“以Agent为中心”。

AOHP的三大设计原则

AOHP将上述问题转化为三条核心设计原则：

• 按需组合用户界面：系统Agent应当打破应用和服务的孤岛，通过发现并重组跨服务提供者的能力，构建基于用户意图、上下文和状态的个性化交互界面。
• 兼容高效的Agent交互：操作系统应当提供统一的基座，既保留对传统Android应用交互的兼容性，又支持面向Agent的服务逻辑，让Agent能够以更低的开销和更高的精度获取系统能力。
• 默认隔离敏感数据：Agent默认不应当接触隐私明文，系统在整个任务流程中强制执行细粒度的信息流追踪、审批和审计机制。

AOHP的整体设计与能力体系

一句话定义AOHP

AOHP全称Android Open Harness Project，本质上是一个带有平台签名的priv-app，名为AOHPAgentDriver，它将AOSP分支中8个IAohp*系统服务的能力整合为一个基于ws://:6666的JSON-RPC接口。上层的CLI工具或Agent不需要关心底层的Binder通信、无障碍服务、Shell调用、容器管理等细节，只需要发送包含{method, params}的请求即可，底层通过switch(method)表将请求分发到对应的处理模块，包括6个Binder客户端、无障碍服务 fallback、Shell调用、文件桥、UDA引擎、Overlay等。

AOHP并非什么

• 并非跨桌面平台的Agent框架：仅基于Android 16 QPR2版本的AOSP，依赖Binder IPC、Accessibility Service、priv-app签名等Android特有的机制，无法直接在Windows、macOS或Linux桌面平台使用。
• 并非内核级Hook安全方案：安全机制运行在Android用户态，通过AOSP分支中新增的系统服务、SELinux规则和priv-app权限来实现。
• 并非自带三层推理调度器：论文中提到的“分层推理调度器”仅为理论蓝图，当前代码中并未实现，实际的效率提升主要依赖Skills知识注入、结构化UI和并行虚拟显示技术。
• 并非已实现完整的个性化记忆引擎：论文中描述的向量库和行为图谱在当前代码中并未出现，当前的个性化功能主要通过UDA生成/缓存和Skills模板来体现。

三层核心能力体系

AOHP在AOSP之上构建了三层核心能力，分别解决不同维度的Agent适配问题：

1. 个性化服务组合

在系统层面聚合多个应用、API、CLI的能力，让系统能够根据用户意图自动组合跨应用的服务，包含三个子组件：

• 生成式服务入口：包含任务Schema（定义用户意图）、服务图谱（映射到具体的系统能力）、呈现策略（决定向用户展示哪些中间结果），为用户生成基于任务的个性化界面。
• 能力发现与组合：跨API、CLI、GUI通道发现系统服务能力，使用输入/输出Schema、前置条件、副作用和策略标签来描述每个能力，Agent可以将这些能力组合为更高层的工作流。
• 跨服务个性化：将系统记忆分为持久化偏好记忆、任务局部记忆和敏感记忆三类，让个性化能力能够跨越应用边界，比如用户在购物应用中设置的偏好可以在其他应用中复用。

2. 高效Agent接口

通过五个核心机制，解决Agent在传统操作系统上运行缓慢、资源消耗高的问题：

• 并行后台交互：解决传统OS前台独占的问题，Agent无法并行操作多个应用的问题，通过轻量级虚拟显示，让Agent可以在后台并行执行多个任务。
• Agent感知UI增强：减少GUI截图的冗余信息，将UI抽象为结构化UI树，也就是增强版的Accessibility Tree，同时保留截图作为 fallback 方案，降低Token消耗。
• 原生沙箱运行时：为Agent提供本地执行环境，让Agent可以在容器中执行计算、转换等操作，不需要依赖云端执行，避免延迟和隐私风险。
• 统一文件快捷方式：将文件作为一等任务对象，让GUI操作自动反映为结构化的文件观察，Agent不需要通过截图来推断文件路径。
• 事件流抽象：让Agent可以订阅系统通知和传感器数据流，不需要反复轮询来捕获瞬态事件，比如Toast、弹窗或传感器数据。

3. 安全信息流

通过四个核心机制，让Agent能够操作敏感数据但不会接触到明文信息：

• 敏感源脱敏：在敏感内容进入Agent上下文之前，将其替换为类型化占位符，比如<phone_number>或<email_address>，真实值存储在系统数据保险库中，Agent只能看到引用句柄，即使泄露也无法反查明文。
• 可信保险库执行：Agent使用占位符提交操作意图，保险库检查策略、获取用户授权后，在可信环境中执行操作，Agent自始至终不会接触到明文数据。
• 数据流污点追踪：基于TaintDroid的移动端污点追踪体系，敏感数据在复制、转换、组合和传输过程中始终携带污点元数据，在系统出口自动对敏感字段进行脱敏处理。
• 五维策略执行：每次敏感操作都会在数据源、请求目的、目标、操作敏感度和授权状态五个维度进行评估，高危操作需要用户进行二次确认。

核心痛点与解决方案对照

对AOHP的分析与评价

值得肯定的核心价值

• Agent作为一等公民的设计理念：当Agent成为主要的交互模式时，操作系统提供原生的Agent接口就像当年提供GUI框架一样自然，这是一次操作系统设计视角的转变。
• 安全信息流设计：将TaintDroid污点追踪和vault reference结合，在“Agent需要处理隐私数据”和“Agent不应看到隐私明文”之间找到了平衡点，既满足了Agent的操作需求，又保护了用户隐私。

改进与发展方向

短期可优化方向

• 自动化能力推断：利用大模型自动从应用的界面描述、用户评论、使用手册中推断服务能力Schema，减少人工标注的工作量。
• 分级安全策略：根据操作的风险等级，比如查看、修改、支付，采用不同的授权粒度，低风险操作静默通过，高风险操作需要用户确认。
• 更全面的基准测试：加入自定义渲染应用、游戏、金融类应用等薄弱场景，测量回退模式下的性能表现。

中长期发展方向

• 与应用开发者的协作协议：设计一种应用可以自愿暴露“Agent友好接口”的声明式规范，类似Android的Intent Filter，让AOHP从逆向工程变为原生支持。
• 联邦式个性化：实现用户偏好和记忆的跨设备同步与隐私保护，当前的设计仅假设单设备场景。
• Agent到Agent的协作协议：当多个Agent同时运行时，定义它们之间协调资源和优先级的机制。
• 移动端完整底层适配：将当前基于Cuttlefish虚拟设备的方案扩展到真实硬件，适配更多的Android设备形态。

总体评价

AOHP本质上是改造后的AOSP、设备端Agent服务（基于WebSocket的RPC）、主机侧CLI工具、UDA生成流水线以及Overlay、沙箱、信息流安全等组件的集合，共同构成了让Agent成为操作系统一等公民的基础设施，能够安全地代替用户完成跨应用的任务。

AOHP的核心贡献不在于某个基准测试的分数提升，而在于提出了“Agent-native OS”这一研究议程，并给出了可复现的开源实现。它将Agent的研究从“如何让大模型更好地操作现有操作系统”推进到了“操作系统本身应该如何为Agent而设计”，这一视角转换的意义，类似于从“如何让程序更好地操作硬件”到“设计操作系统来管理硬件资源”的跨越。

不过AOHP最大的局限也在于此：操作系统层面的改造需要整个生态的配合，而生态的惯性是巨大的。AOHP展示了“可以做什么”，但“如何让它真正落地”这个问题，论文并没有回答，也几乎不可能由一篇学术论文来回答。

对于开发者来说，AOHP最有价值的不是某个基准测试的分数，而是它展示了一套完整的Agent-OS交互范式。理解这套范式后，开发者可以在AOHP框架上接入自己的大模型和技能集合，参考其JSON-RPC接口设计构建类似的控制面，借鉴其安全信息流设计在自己的Agent系统中实现数据隐私保护。

附录：核心模块深度解析

个性化服务组合模块

AOHP最显著的变化是交互界面变得个性化且动态生成，而非完全由开发者预定义。传统应用暴露的是开发者预先选择的功能，而AOHP让系统Agent围绕用户的重复性目标合成服务入口，将交互从应用导航转变为任务级服务访问。

生成式入口是由系统管理的服务组合支撑的用户界面壳层。比如一个购物入口可以聚合多个服务提供者的商品搜索、商品属性归一化、用户偏好应用，比如尺寸和预算，并暴露一个用于比较和购买的任务特定界面。每个入口包含三个部分：任务Schema，定义用户试图完成的目标；服务图谱，将任务映射到具体的服务能力；呈现策略，决定哪些中间结果应展示给用户，哪些可以保留在Agent内部。这种分离使AOHP能够在不隐藏重要决策的前提下个性化入口。

当前代码中，UDA体系的实现包括：用户输入自然语言指令后，大模型生成HTML/JS/CSS前端和mock后端，然后安装到设备桌面，Agent在后台调用display.*、app.*、ui.*等接口组合真实的系统服务。具体的实现文件包括udagen/pipeline.py，负责三阶段流水线，从draft_prd到draft_design再到build_app；UdaManager.java作为门面，编排整个生成流程；UdaGenerationEngine.java负责在Alpine容器中执行python3 -m udagen run命令；UdaAppActivity.java通过WebView加载生成的前端，并通过AohpUdaJsBridge代理到mock server；UdaInstallManager.java负责将生成的UDA固定到设备桌面。

当前实现的弱点在于生成成本较高，每次生成UDA都需要完整的大模型流水线，且生成的应用是静态的，无法在运行时动态添加新的服务提供者。未来的改进方向包括开发服务能力注册表、实现运行时动态组合、支持增量生成等。

高效Agent接口模块

AOHP将执行环境、UI语义、存储和事件作为Agent原生原语暴露，这些抽象减少了Agent中介工作流中的视觉处理开销、刚性串行执行和脆弱的跨应用交接。

以并行后台交互为例，传统移动操作系统将应用的生命周期与物理显示器绑定，而AOHP通过轻量级虚拟显示将执行与屏幕解耦，允许Agent在后台运行密集型或独立的工作流，而不会抢占前台的用户会话。传统系统中只有前台Activity能够接收输入事件，Agent同时操作两个应用时必须反复切换前台，导致串行等待，而OpenClaw的评测显示，使用AOHP后并行执行时间从33.94分钟降到18.93分钟，效率提升了44.21%。

代码层面，AOHP通过AohpVirtualDisplayService.createVirtualDisplay()方法创建带有OWN_FOCUS标志的虚拟显示，每个虚拟显示拥有独立的输入焦点；使用ImageReader保活虚拟显示，确保其始终处于STATE_ON状态，避免WindowManager添加sleep token导致Activity暂停；IMAGE_READER_USAGE参数包含GPU_COLOR_OUTPUT、GPU_SAMPLED_IMAGE、COMPOSER_OVERLAY等标志，确保GPU能够正常渲染；每次创建虚拟显示时自动调用AohpVirtualDisplayPolicy.registerSession()，绑定displayId、uid和packageName的映射关系。

安全信息流模块

AOHP将敏感数据视为操作系统控制的状态，而非Agent可见的上下文。默认情况下，私有明文在到达Agent上下文之前会被替换为类型化引用，受信的系统组件负责中介明文的操作、外部传输和审批，同时保留审计证据。这一模型的必要性在于Agent任务会跨越应用、工具、记忆和服务的边界，而传统的应用权限无法追踪私有数据的传播路径。

以策略执行为例，AOHP在运行时对数据使用执行隐私策略，而非仅对静态权限或应用身份执行策略。每次敏感操作都会评估数据源、请求目的、目标、操作敏感度和审批状态五个维度，普通的非敏感数据流可以正常通过，而涉及私有数据的传输和状态变更操作则需要用户同意或被阻止。相同的策略上下文使授权对用户更可理解，当需要审批时，AOHP可以用数据源、目的、目标和下游影响来解释所请求的使用，而非弹出不透明的权限提示，因此执行策略与任务中私有数据的具体使用直接挂钩。

当前实现的弱点在于安全与效率的平衡，过多的策略检查会降低执行效率，且当前仅支持二元的ALLOW/DENY策略，缺少分级机制，策略的维护成本也较高，无法规模化适配所有应用场景。未来的改进方向包括开发分级安全策略、实现上下文感知的授权、自动生成策略规则等。

AohpVirtualDisplayService核心解析

AohpVirtualDisplayService是AOHP在AOSP分支中新增的私有系统服务，注册在system_server中，服务名为"aohp_virtual_display"，它是整个AOHP架构中最核心的系统服务，承担了Agent的“眼睛”，也就是UI树获取、“手”，也就是输入注入，以及“并行工作台”，也就是虚拟显示管理的功能。

这个服务直接解决了四个核心Agent痛点：

1. 无法获取UI结构：传统系统中只能通过截图和OCR识别，AOHP通过dumpUiTree方法将Accessibility Tree导出为结构化JSON，并经过安全过滤后返回给Agent。
2. 只能串行操作多个应用：传统系统中只有前台Activity能接收输入事件，AOHP通过创建轻量级虚拟显示，让Agent可以在后台并行操作多个应用。
3. 输入注入不稳定：传统的adb shell input tap命令只能注入到默认显示，且无法指定目标显示，AOHP通过一系列精确的输入注入方法将操作发送到指定虚拟显示，并带有安全策略检查。
4. 敏感操作缺乏细粒度控制：传统系统无法区分普通按钮和支付按钮等敏感操作，AOHP在每次注入前都会进行五维策略评估，拦截高危操作。

其四大核心机制分别是：

• 虚拟显示创建：通过OWN_FOCUS标志让每个虚拟显示拥有独立输入焦点，使用ImageReader保活显示状态，确保GPU渲染正常，并绑定显示与应用的映射关系。
• 精确输入注入：使用合成设备ID避免路由错误，添加防御性的displayId重设，通过InputManagerService等待注入完成，模拟真实的滑动和文本输入行为。
• 安全策略检查：在每次输入注入前获取前台包名并调用安全策略检查，仅允许通过评估的操作执行，拦截高危敏感操作。
• 结构化UI树导出：将原始Accessibility Tree经过安全过滤后返回，让Agent直接获取结构化界面信息，而非依赖像素级识别，同时支持通过无障碍API直接操作UI组件，比坐标点击更可靠。