以 2026 年 4 月 27 日郭明錤关于 OpenAI 手机的产业链消息为起点，从 Android 手机从业者视角，推演手机与 AI 融合之后的系统形态。
引言：这不是一台新手机的问题
郭明錤这条消息最值得关注的地方，不在 2028 年量产这个时间点，也不在联发科、Qualcomm、立讯分别处在什么供应位置。
它把问题推到了系统层：
如果用户的主要目的从打开 App 转向完成任务，手机操作系统应该长什么样？
这句话听起来像 UI 变化，但站在 Android 从业者视角，它牵动的是一整套系统结构：Launcher、通知、权限、IPC、App 能力声明、模型运行时、TEE、端云同步、任务状态机、审计记录、支付确认、开发者分成，都会被重新审视。
过去几年，AI 手机的讨论大多停在功能层。厂商讲 AI 修图、AI 消除、AI 摘要、AI 搜索、AI 助手、AI 简报，这些都能放进现有 Android 或 iOS 架构里。
OpenAI 如果真的按 AI Agent 手机去做，它会把问题从“手机里还能塞多少 AI 功能”，推到“手机的第一入口还要不要从 App icon 开始”。
主线是：Agent OS 更像移动 OS 在图形界面之后的一次结构迁移。前台从 App 网格迁移到任务流，后台从 App 独占能力转为可授权能力，系统从管理进程和窗口转向管理任务、上下文与责任。
OpenAI 做手机不一定基于 Android，但概率很高，因为它能继承硬件适配、驱动、应用兼容和供应链经验。但如果 OpenAI 想完全按 Agent OS 设计第一屏、权限和任务流，它也可能走一条“Android 兼容但不完全是 Android”的路，甚至用 Linux 自建系统，再用 Web、云端执行和应用兼容层补齐服务。
不同 OS 选择会改变进入市场的速度，却不会改变 Agent OS 必须解决的五件事：
- 手机要持续理解用户的当前状态。
- App 要从前台入口变成后台能力提供者。
- 系统要有可恢复、可取消、可审计的任务运行时。
- 端侧与云端要按数据敏感度和实时性分工。
- 所有跨 App、跨设备、跨云的执行都要有权限、责任和回滚边界。
这五件事没有完成，AI 手机就只是“手机里装了一个 AI 助手”；它们一旦形成系统约束，手机才会朝 Agent OS 走。
文章目录
全文按六个大问题推进。
一、问题起点：OpenAI 做手机改变的不是硬件。先拆清楚 OpenAI 做手机的几种 OS 路线，再解释为什么手机仍然是 Agent 的状态中心。
二、入口迁移：从 App 网格到任务流。App 不会消失，但入口会降级；变化落在 Task、Capability、Context、Artifact、Grant、Audit 这些 OS 对象上。
三、Android 路线：从超级 App 到系统服务。Android 短期不会推倒重来，它更可能从系统服务、A2A、AppFunctions、GUI Agent 和 Capability Router 里长出 Agent OS。
四、OpenAI 的分叉：基于 Android 与不基于 Android。非 Android 路线更干净，但要补齐应用、身份、支付、服务网络和责任边界；Android 路线更快，也更容易被旧 App 模型拖住。
五、端云、硬件、产业与时间表。端云分工、数据分级、端侧模型、SoC、五类玩家、产业链和 2026 到 2032 时间表，会决定 Agent 手机能不能从 demo 进入日常使用。
六、产品形态、市场分化与责任分配。最后回到第一屏、中国市场、开发者关系、责任分配，以及 Android 从业者该如何观察这轮变化。
一、问题起点：OpenAI 做手机改变的不是硬件
郭明錤的消息里有几个明确方向：OpenAI 与联发科、Qualcomm 合作开发手机处理器，立讯承担组装与系统集成，可能参与硬件协同设计，规格和供应商可能在 2026 年底或 2027 年一季度收敛，目标是 2028 年量产。
如果把这条消息只理解成“OpenAI 要做 iPhone 竞品”，容易走偏。手机硬件已经是成熟产业，OpenAI 做手机的难点很少在堆料、摄像头、工业设计或代工厂。难点在于：一个没有 App 分发权、没有本地生活网络、没有支付网络、没有运营商渠道、没有长期手机售后经验的 AI 公司，凭什么让用户把主设备交给它？
答案不可能只是“模型更强”。手机不是模型跑分设备。用户每天在手机上处理的是身份、钱、工作、社交、交通、健康、家庭和内容消费。OpenAI 的机会在另一侧：绕开每一个 App 的停留时间争夺，直接争“任务解释权”和“任务执行权”。
但“做手机”可以拆成四种不同选择。
第一种是基于标准 Android。OpenAI 可以拿 AOSP/GMS 体系，深度改 Launcher、SystemUI、权限、通知和默认助手，保留 Android App 兼容性，把 Agent 作为系统级入口。这条路最快，也最像手机。风险是控制力不足。Android 的安全模型、后台限制、应用权限、Play 政策、OEM 定制边界，都会限制它一步到位地重写用户体验。
第二种是基于 AOSP 深度分叉。它仍然运行 Android App，但系统框架、默认入口、能力注册、任务管理、云端同步由 OpenAI 自己定义。海外可以谈 Google 服务，国内几乎需要另起服务体系。这条路在工程上可行，商业上很难。因为 Android App 兼容涉及 APK、Google Play、推送、地图、支付、账号、订阅、反作弊和厂商认证。
第三种是“Android 兼容层 + 自建 Agent OS”。底层可能仍是 Linux，前台是任务流系统，Android App 运行在隔离容器或兼容环境里，像过去桌面系统运行移动 App 那样。OpenAI 在这个系统里拥有更大设计自由，可以把 App 视作能力容器，弱化它的 UI 主体地位。代价是兼容成本、功耗、后台限制和应用厂商反制都会上升。
第四种是完全不基于 Android 的新 OS，甚至第一代设备不是传统手机。OpenAI 与 Jony Ive 团队早前的硬件方向一直被外界理解为更“AI 原生”的设备，这和郭明錤所说的手机并不冲突。OpenAI 可以先做一个屏幕更弱、对话更强、云端更重的随身设备，也可以做一个有手机形态但不追求完整 App 兼容的设备。它更纯粹，但很难成为用户第一手机。
更倾向的判断是：若目标是 2028 年量产并承接高阶换机需求，OpenAI 大概率不会完全抛开 Android 生态。更现实的路径是 AOSP 或 Android 兼容分支，加上强定制的 Agent OS 前台。但这只是概率判断，不是前提。下文先分析 Android 路线，再看非 Android 路线。
在进入路线分析前，还要分清一个概念：OpenAI 不一定想“做 Android 手机”，它更可能想“做一个让 Android 和 iOS 看起来过时的任务入口”。只要这个入口被用户接受，硬件首代销量就不应成为唯一指标。它会逼所有手机厂商回答同一个问题：
为什么用户还要从几十个 icon 里找入口，而不是直接看到正在发生、等待确认、已经完成和可以继续的任务？
手机为什么仍是 Agent 的状态中心
“Agent 在云端就够了”这个判断，只看到了推理能力，没有看到手机在用户生活里的位置。云端模型更大，工具更多，成本也能集中优化，但它缺少用户当下状态。
Agent 完成任务依赖语言理解，也依赖用户此刻的状态。状态超出一句 prompt 和通讯录、日历、相册这些静态数据，指向“现在正在发生什么，以及用户愿意让系统在多大范围内替他行动”。
手机刚好是这个状态最完整的设备。
它知道用户在哪里，正在看什么，刚收到什么通知，上一分钟打开了哪个 App，蓝牙耳机是否连接，手表是否检测到运动，屏幕是否锁定，支付凭据是否可用，用户是否刚进入机场，车是否停在附近，下一场会议还有多久，家人是否在同一个位置共享圈里。
这些状态不是云端能自然拿到的。云端可以拥有长期记忆、知识库、浏览器、代码沙箱和高强度模型，但它看不见用户手里的现场。它不知道用户此刻是否方便说话，不知道当前屏幕里哪个按钮可点，也不能直接完成生物识别确认。云端如果想做得像“人在场”，必须通过手机取得现场状态。
这也是 OpenAI 想做手机的合理之处。ChatGPT App 再强，仍然只是 App：打开才出现，关闭就离场。它没有系统级通知入口，没有默认支付确认权，没有相机和屏幕的持续语义访问，没有跨 App 任务状态，也没有长期管理设备状态的权限。
Agent 手机和 AI App 的分界，正在这里。
AI App 等用户打开它。Agent 手机在系统层观察事件、组织任务、等待合适时机、请求授权、执行动作、记录结果。前者像一个能力很强的工具，后者像一个被系统约束的代理人。
普通用户不会这样描述，但他的行为会推动这个变化。一个人让手机“下周三帮我订去东京的机票和酒店，预算不要超过 8000，避开红眼航班，顺便把行程发给同事”，目标是让一个任务被拆解、比较、确认、支付、同步和跟踪，而不是在携程、飞猪、地图、日历、微信、邮箱和公司报销系统之间来回切换。
一个父母让手机“帮我看一下孩子班级群里这周要交什么材料”，目标是从群消息、学校小程序、相册、日历和待办里形成一张可执行清单，并且在截止前提醒，而不是打开微信翻 200 条消息，或让模型总结一段聊天。
一个内容创作者让手机“把今天拍的素材剪成三条不同平台的短视频，分别适配抖音、小红书和视频号”，他要的不是打开剪映点按钮。他要的是素材理解、平台规格、文案生成、风格选择、版权检查、发布计划和数据回看。
这些任务都不是单 App 问题。它们跨越 App、账号、设备、云端工具和真实世界履约。手机是入口，因为手机掌握状态；云端是放大器，因为云端承载长任务；App 是能力来源，因为服务仍在 App 背后。
所以 App → Agent 描述的是 App 前台地位下降、能力地位上升，App 本身仍然会存在。
二、入口迁移：从 App 网格到任务流
很多关于 Agent OS 的讨论把话说得很满：Agent 会替代 App。这个判断太粗。
上一章已经说过 App 不会消失。原因很简单：App 承载账号体系、商业关系、支付风控、内容版权、私域关系、会员权益、客服责任和监管义务。一个 Agent 可以替用户操作外卖 App，但餐厅供给、配送网络、售后规则、优惠券、发票和食品安全责任仍在平台手里。一个 Agent 可以帮用户订酒店，但库存、价格、取消政策和信用担保仍在 OTA 和酒店集团手里。
变化发生在入口层。
过去的手机是 App icon 网格：用户先选 App，再到 App 里找功能。这个模型适合“人主动操作软件”的时代。Agent OS 的前台更像任务流：用户先表达目标，系统再选择能力。App 从“目的地”变成“能力来源”。用户不一定知道最后调用了哪个 App，但系统必须知道，并且要能解释、授权、审计和追责。
郭明錤那张概念图把这件事压缩成三句话：
- App → Agent
- Icon → Task
- Grid → Stream
这三句话可以作为产品方向，但工程上要拆开。
App → Agent 的关键不在于给每个 App 包一层聊天 UI。Agent 需要理解 App 暴露的能力、输入约束、输出格式、执行风险和收费规则。对 Android 来说，这对应 AppFunctions、Intent、ContentProvider、ShareSheet、Shortcut（含 App Shortcuts 与 Sharing Shortcuts）、Notification Action、Credential Manager、Wallet/Payment SDK、Web API 和厂商私有接口的组合（Slice 已被 Google 标注 deprecated，可不再纳入新设计）。
Icon → Task 的关键不在于把 App 图标换成任务卡片。任务要有状态机：创建、计划中、等待授权、执行中、等待外部响应、失败、取消、完成、回滚。它还要有 Artifact：机票、订单、文档、日程、图片、发票、会议纪要、路线、代码 diff。用户不能只看到一个聊天气泡转圈。
Grid → Stream 的关键不在于把主屏做成信息流。任务流必须可控、可折叠、可静音、可暂停、可追溯。否则它会变成更吵的通知中心。一个能主动出现的 Agent，如果没有预算和节制，很快就会被用户关掉。
手机 OS 的变化就藏在这三个转换背后。
过去 OS 管的是进程、窗口、权限和通知。Agent OS 还要管任务、上下文、能力、记忆和责任。App 可以继续存在，但用户每天面对的第一层界面，可能不再是 App 的陈列柜，而是任务的工作台。
从一个任务看 OS 对象模型
如果只说 App → Agent，很容易变成抽象判断。换成 Android 工程语言，一个跨 App 任务在系统里至少会被拆成下面几个对象。
第一个对象是 Intent。这里指用户目标，不指 Android Intent。它来自语音、文字、截图、相机、通知、剪贴板或外部设备。用户说“帮我把这张发票报销掉”，系统不能只把这句话丢给模型，而要先识别任务类型、涉及的 App、需要的账号、可能的凭据、是否有公司策略、是否需要联网、是否需要用户在场确认。
第二个对象是 Context。这里指任务所需的最小现场信息，不指 Activity Context。报销任务可能需要发票图片、企业微信或飞书里的审批入口、公司报销规则、发票抬头、用户身份、最近一次同类报销模板。系统要把这些信息裁剪到足够完成任务，但又不能把整个相册、整个聊天记录、整个公司文档都交给云端。
第三个对象是 Capability。系统要知道哪些能力能完成这个任务：OCR、发票查验、企业 App 的报销 AppFunction、浏览器表单填写、公司内网 API、文件上传、消息通知。每个能力都有来源、权限、成本、可靠性、执行时长和风险等级。
第四个对象是 Plan。Agent 会把任务拆成步骤，但 Plan 不应该只存在于模型上下文里。它应该被系统记录成可检查的结构：读取发票、提取字段、查验真伪、打开报销入口、填写表单、上传附件、等待用户确认、提交、保存回执。这样用户、系统和开发者才知道任务现在走到哪里。
第五个对象是 Permission Grant。传统 App 权限是“这个 App 能不能访问相机”。Agent 权限是“本次报销任务能不能读取这张发票、能不能访问公司报销入口、能不能提交表单、提交前是否必须确认”。它比 App 权限更短、更细、更依赖任务状态。
第六个对象是 Artifact。任务的产物包括报销单草稿、提交回执、发票字段、审批编号、失败截图、操作日志，而不止一句回答。这些 Artifact 要进入历史记录，也要能被后续任务引用。
第七个对象是 Audit。Agent 做了什么、调用了谁、用了哪些数据、哪一步由用户确认、哪一步自动执行、失败发生在哪里，都要可追溯。没有 Audit，Agent 一旦做错事，用户和厂商都无法判断责任。
这套对象模型和 Android 现有对象有关系，但不能完全复用。
Activity 面向界面，Service 面向后台执行，Broadcast 面向事件分发，ContentProvider 面向结构化数据，Intent 面向组件调用。它们解决的是 App 之间如何协作，不解决“一个跨 App 目标如何持续执行、如何等待用户确认、如何在云端与端侧之间迁移、如何在失败后恢复”。
Agent OS 需要在这些传统对象之上增加任务对象，把 Activity 和 Service 包进一个更高层的任务语义里。
可以把关系理解成这样：
1 | 旧 Android 对象： |
这也是为什么 Agent OS 不能由一个独立 App 完成。第三方 App 可以维护自己的 Task，但无权把所有 App 的能力、权限、上下文与审计统一管理起来——只有系统层能做。
任务流和通知中心的关系
系统层要做的第一件事，就是把碎片事件组织成任务，这一点最容易和通知中心混淆。
很多厂商会先从通知中心改起，因为通知天然就是“事情发生了”的入口。三星 Now Brief、Now Bar 这类方向有价值，原因就在这里。它们在尝试把碎片事件组织成“用户今天要处理的事”，价值也来自事件到任务的重新组织。
但任务流不能简单等同于通知中心。
通知是 App 发给用户的事件。任务是用户或系统要完成的目标。通知可以触发任务，任务也可以产生通知，但两者不是同一个东西。
举例说，航司 App 推送“航班延误 2 小时”是一条通知。Agent OS 接到这条通知后，可以生成一个任务：“是否调整接机时间、酒店入住、会议日程和同事通知”。这个任务会读取日历、地图、酒店订单、聊天对象、公司会议安排，再让用户确认。通知只是起点，任务才是系统要管理的对象。
再比如，学校群里发了 20 条消息，里面只有一条和明天交材料有关。传统通知中心只能显示 App 推送；AI 摘要可以帮你总结；Agent OS 要进一步生成任务：“今晚 9 点前打印并填写表格，明早带到学校”。它要能关联文件、打印机、日历、提醒和家庭成员。
所以任务流更像一个轻量项目管理器，对象是生活和工作的待办事项，而非通知列表。
这也带来一个产品约束：任务流必须克制。一个每天主动创建 30 个任务的手机，用户会很快关闭它。系统需要有提醒预算、打扰等级、安静时段、家庭/工作模式和用户反馈。任务流的难点在于筛掉不该出现的任务。
三、Android 路线：从超级 App 到系统服务
Android 在 Agent OS 上有天然优势，也有明显负担。
优势是开放、可改、硬件覆盖广、厂商能拿到系统权限，现有框架里已经有很多可复用部件。Binder 适合同设备内高频 IPC，PackageManager 适合能力登记，PermissionController 适合授权，ActivityTaskManager 和 WindowManager 适合前后台状态，NotificationManager 适合长任务可见化，AppSearch 适合本地索引，Keystore 和 StrongBox 适合凭据保护，JobScheduler 适合长任务调度，ContentProvider 适合结构化数据访问。
负担是碎片化、权限历史包袱、Google 服务和 AOSP 的分裂、厂商私有接口太多、后台限制复杂、头部 App 对自动化调用天然警惕。一个 Android Agent 想从“能点屏幕”走到“能稳定完成任务”，必须越过三条技术路线。
第一条是 GUI Agent。它通过截图、无障碍、输入注入、Virtual Display、UI hierarchy、OCR/VLM 来模拟人操作 App。优点是能覆盖长尾 App，不需要开发者配合。缺点也明显：慢、易受 UI 改版影响、容易触碰安全边界，支付、社交、银行、游戏平台会天然防范它。
豆包手机把这条路线推到真实设备上，让行业看到了它的可用性，也看到了它的边界。系统级权限、Virtual Display、端侧视觉理解、云端 OpenClaw/ArkClaw，组合起来确实能完成很多跨 App 动作。但第三方 App 的限制也说明，靠“像人一样点屏幕”不能支撑长期主线。
第二条是结构化能力。Android AppFunctions、Apple App Intents、各家 SDK、MCP tool、私有 API 都属于这一类。它要求 App 主动声明“我能做什么”，并给出参数、权限、返回值和风险等级。优点是稳定、快、可审计，适合支付、发消息、创建日程、生成文档、提交订单这类需要责任边界的操作。缺点是需要开发者配合，且头部 App 不愿轻易把前台入口让出去。
第三条是 Agent 协议。A2A 解决 Agent 之间如何发现、委托任务、传递消息和交付 Artifact；MCP 解决 Agent 如何使用工具和数据源。放到手机里，它们不会替代 Android IPC，而是会在不同层级共存：同设备内更适合 Binder，跨设备和云端更适合网络协议。
更合理的 Android 短期结构可以理解成一个路由器：
1 | 用户目标 |
这也是 Android 厂商短期最该避免的误区：把 Agent OS 做成一个拿满权限的超级 App。超级 App 能做 demo，撑不起系统架构。长期可扩展的做法是把 Agent 拆进系统服务、能力声明、任务状态机、数据分级和用户可见控制里。
Android 现有组件能迁移到哪里
Android 并不是从零开始。站在平台工程角度，Agent OS 的很多部件可以从现有系统抽象迁移而来。
PackageManager 可以继续负责发现已安装应用，但它需要扩展能力索引。过去 PackageManager 关心 Activity、Service、Receiver、Provider、Permission、Feature。Agent OS 还要知道 App 声明了哪些 AppFunction，是否提供 AgentCard，哪些 schema 可被系统调用，哪些能力需要人工确认，哪些能力只能在企业策略下使用。
PermissionController 可以继续负责授权 UI 和权限记录，但它需要支持任务级授权。传统权限常常是“允许某 App 访问相机”。Agent 权限更像“允许本次任务读取这三张图片并上传到这个服务，上传前必须展示预览”。这类授权不应该永久挂在 App 身上，而应该绑定 Task、Step 和 Artifact。
ActivityTaskManager 可以继续提供前后台状态、任务栈和窗口信息，但 Agent OS 需要的是可用语义快照，而不是用户当前屏幕的粗暴复制。对外提供的应该是结构化摘要：当前 App、页面类型、可操作元素、敏感区域、用户是否正在输入、是否有支付/验证码/隐私界面。直接把屏幕原始内容暴露给云端会带来很高风险。
NotificationManager 可以成为任务状态的自然出口。一个长任务不应该只停在助手 App 里，它应该进入系统通知、锁屏、手表和车机。但通知也要升级：不仅有标题和正文，还要有状态、进度、下一步动作、风险提示、暂停/取消/确认按钮。
AppSearch 可以成为本地语义索引的一部分。端侧需要快速查找笔记、文件、日历、联系人、历史任务、常用地点和用户偏好。AppSearch 适合做本地索引，但敏感数据要按策略切分，不能把所有内容一股脑放进可被 Agent 任意读取的索引库。
ContentProvider 仍然是结构化数据访问的基础，但它的权限模型需要更细。一个 App 可以允许 Agent 读取某个订单状态，却不允许读取全部订单历史；可以允许读取一条聊天中的附件，却不允许读取整段聊天上下文。
Keystore、StrongBox、TEE 和安全元件的权重会上升。Agent 手机里，凭据、支付、Passkey、企业证书、私密记忆、敏感向量索引，都需要硬件级保护。Agent 可以准备动作，但最终签名和确认应该发生在安全边界内。
JobScheduler、WorkManager、AlarmManager 和 Push 可以支撑长任务调度，但 Agent 任务比普通后台任务更复杂。它可能在云端运行，端侧只是等待回调；也可能端侧执行一半断网，恢复后继续；还可能跨设备迁移。系统需要把任务状态和调度系统连接起来。
RoleManager 和默认助手角色会成为入口竞争的关键。Android 过去通过 RoleManager 管理默认拨号、短信、浏览器、助手等角色，输入法走单独入口（InputMethodManager）。Agent OS 时代可能需要“默认 Agent”“默认任务管理器”“默认能力路由器”。这会引发平台、OEM 和第三方助手之间的新博弈。
把这些组件放在一起，Android 短期可以走出一个务实的演进版本：
1 | SystemUI / Launcher |
这套结构并不要求 Android 立刻推倒重来。它更像在现有 Android 体系中增加一组高权限系统服务，再逐步把开发者接口开放出去。短期由 OEM 私有实现，长期才可能被 AOSP、GMS 或行业协议吸收。
A2A 在 Android 上的合适位置
A2A 需要先单独讲清楚，因为它不是又一个“调用工具”的协议。
A2A 全称 Agent2Agent，2025 年 4 月由 Google 联合 50+ 合作伙伴推出，2025 年 6 月移交 Linux Foundation 治理。官方给它的定位很明确：让不同厂商、不同框架、不同运行环境里的 Agent 能够互相发现、互相委托任务、交换进度和交付结果。
它的设计前提是：Agent 彼此是黑盒。一个旅行 Agent 不需要知道另一个报销 Agent 内部用了什么模型、什么 prompt、什么工具、什么数据库；它只需要知道对方能做什么、如何鉴权、如何提交任务、任务现在是什么状态、最后会返回什么结果。
这和 MCP 的位置不一样。MCP 解决的是 Agent 如何调用工具、资源和数据源。比如一个 Agent 通过 MCP 调文件系统、数据库、浏览器、Jira、飞书文档。A2A 解决的是 Agent 如何调用另一个 Agent。前者更像“工具插座”，后者更像“任务委托语言”。
放到手机里，这个区分很有用。
用户说“帮我安排下个月去东京的行程，预算 8000 以内，避开红眼航班，顺便把行程发给同事”。手机端系统 Agent 可以读取日历、位置、支付确认状态和联系人，但它不一定自己完成全部事情。它可以把航班酒店比较交给旅行 Agent，把签证材料检查交给文档 Agent，把公司差旅规则交给企业 Agent，把最后确认和支付留在手机端。
如果每个 Agent 都有一套私有接口，这件事很快会失控。A2A 试图提供一套公共名词。
第一个名词是 AgentCard。它可以理解成 Agent 的“能力名片”：我是谁，我能做什么，我支持哪些输入输出，我需要什么认证方式，我是否支持流式返回，我是否支持任务完成后的 push。放到 Android 里，它很像 Manifest 的 Agent 版本。一个 App 或系统服务可以声明“我有一个旅行 Agent”“我有一个图片编辑 Agent”“我有一个企业报销 Agent”，系统把这些名片索引起来。
第二个名词是 Task。A2A 里的 Task 是一个有状态工作单元，不等同于一次 API 请求。它可以处在 submitted、working、input-required、auth-required、completed、canceled、failed、rejected、unknown 等状态。这个设计很适合手机，因为手机上的真实任务经常跨时间：订票要等价格，外卖要等骑手，审批要等上级，视频导出要等处理，报销要等提交。用户需要看到任务状态，而不是只看到一段模型回复。
第三个名词是 Message / Part / Artifact。Message 是任务过程里的对话回合，Part 可以是文字、文件、结构化数据，Artifact 是任务交付物。手机 Agent 需要传图片、PDF、表格、订单、日程、定位、凭据引用和操作结果。Artifact 这个概念尤其适合 Agent OS，因为任务结果要能被保存、分享、审计和后续引用。一次旅行任务的 Artifact 可以是行程单、酒店候选表、预算表、日历事件和支付确认记录。
第四个能力是 Streaming 和 Push。很多手机任务不是秒级完成。用户不能一直盯着聊天窗口等待云端 Agent 做完资料整理、比价、审批或视频处理。A2A 的流式更新和异步回调语义，适合把“任务已开始、需要补充信息、需要授权、已完成、失败原因”推回手机通知、锁屏和任务流。
所以，A2A 对 Agent OS 的价值不在于“又多了一种网络协议”，而在于它把 Agent 协作里最难统一的几个对象标准化了：谁能做、任务是什么状态、过程怎么沟通、结果如何交付。
但 A2A 也不能被放大成 Android Agent OS 的全部答案。
第一，A2A 原生面向跨系统、跨网络、跨厂商的 Agent 通信。它适合手机端 Agent 调云端 OpenClaw、ChatGPT Agent、企业 Agent、车机 Agent、家居 Agent，也适合两个不同公司提供的 Agent 互相委托任务。
第二，同一台 Android 设备内，A2A 的语义值得借用，但传输层不该照搬 HTTP/JSON-RPC。Android 本地 IPC 的正路是 Binder。让本机多个 Agent 每次都绕 loopback HTTP，不仅增加延迟，也绕开了 Android 原有 UID、SELinux、permission、lifecycle 等安全模型。更合理的是 A2A over Binder：保留 AgentCard、Task、Message、Artifact 这些语义，但传输层用 Binder，权限和审计由系统服务处理。
第三，A2A 需要和 AppFunctions 分工。AppFunctions 是“系统 Agent 调本地 App 的结构化函数”，适合 createNote(title, content)、searchPhotos(query)、sendMessage(contact, text) 这种明确动作。A2A 是“一个 Agent 委托另一个 Agent 完成任务”，适合“帮我整理这批照片并做成旅行相册”“帮我按公司规则处理报销”这类需要自主判断、多轮追问、长时间执行的任务。
可以把 Android 上更合理的栈写成这样：
1 | 用户目标 |
第四，A2A 还缺少手机 OS 需要补的部分。它能描述 Task 状态，但不负责 Android 的权限 UI；它能支持异步回调，但不保证所有实现都有严格事件回放；它能传 Artifact，但不替系统定义数据分级、端云边界、支付确认和失败回滚。Agent OS 必须在 A2A 之上增加 Policy、Consent、Audit、Retry、Idempotency 和用户可见控制。
因此，A2A 在 Android 上更合适的位置是：它不替代 Binder，不替代 AppFunctions，也不替代权限系统。它应该成为 Agent 协作的公共语义层。Android 要做的，是把这套语义翻译进自己的系统服务、IPC、任务流和权限模型里。
三条技术路线会长期并存
前面分别讲了 GUI Agent、AppFunctions 和 A2A 的位置。把它们放在一起看，结论是：三者会长期并存，只是位置不同。
GUI Agent 是兼容层。它解决“开发者没配合、App 没暴露能力、用户现在就要完成任务”的问题。它适合长尾和过渡期，也适合用户可见的低风险操作。它不适合作为支付、发消息、改设置、删数据、下单等高风险动作的默认路径。
AppFunctions / App Intents 是本地能力层。它让 App 用结构化方式告诉系统：我能创建笔记、发消息、建日程、搜索商品、提交订单、生成图片、导出视频。它需要开发者配合，但一旦形成规模，可靠性、速度和安全性都比 GUI Agent 好。
A2A / MCP 是协作和工具层。MCP 面向工具和数据源，A2A 面向 Agent 之间的发现、委托和交付。手机端的 Agent 要和云端 Agent、车机 Agent、电脑 Agent、企业 Agent 协同，就需要类似协议。协议不会取代本地 API，但会让跨设备和跨云端任务变得可描述。
这三条路之间需要 Capability Router。用户只表达目标，系统根据任务类型、风险等级、可用能力、网络状态、隐私等级和成本，决定走哪条通路。
比如“把这张照片修亮一点”，端侧模型就可以做。
“把今天会议录音整理成纪要并发到飞书群”，优先走录音转写、文档、飞书 API 或 AppFunction，最后由用户确认发送。
“帮我比较三条暑假亲子游路线，预算 2 万以内，考虑老人不能走太多路”，云端可以长时间查询和比较，手机端负责同步家庭日历、位置偏好、支付确认和最终选择。
“帮我取消一个快过期的订阅”，如果 App 暴露结构化能力最好；如果没有，GUI Agent 可以操作设置页或网页；涉及付款和账户变更时必须要求用户确认。
这才是 Agent OS 比助手 App 更难的地方。助手 App 只需做一个模型入口，失败了说一句抱歉；Agent OS 一旦承诺执行，就要面对真实世界的副作用——不能只追求聪明，还要可控、可解释、可恢复。
Android 短期 Agent OS 架构：系统服务是主战场
前面讲完 Android 的三条路径，就可以把它们收束到一套系统架构里。
这套结构不能被当成“Agent OS 终局架构”。它更像 Android 在 2026 到 2028 年比较务实的演进方式：保留 Android 和 kernel 主线，在 SystemUI、Framework、权限、通知、端侧模型运行时和云端 Agent Runtime 之间，增加一组围绕 Task 的系统服务。
这套架构的读法很简单。
第一层是 Agent UI / Task Stream。用户看到的是任务状态：正在执行、等待确认、已完成、失败、可恢复，而不是模型调用。主屏、锁屏、通知、悬浮入口和多设备续接，都会变成任务状态的不同出口。
第二层是 Agent Runtime。这是 Android 短期最缺的语义层。TaskRuntime 负责状态机、Artifact、取消、恢复和回滚；ContextService 负责提供最小化现场快照；CapabilityRouter 负责在 AppFunctions、A2A、MCP 和 GUI Agent 之间路由；MemoryService 负责短上下文、长期偏好和可删除记忆；Policy / Consent / Audit 负责授权、同意、风险分级和责任记录。
第三层是 Android Framework。Android 不需要从零写 OS。PackageManager、PermissionController、ActivityTaskManager、NotificationManager、AppSearch、ContentProvider、Credential、Keystore、StrongBox、JobScheduler、RoleManager 都能继续发挥作用。变化在于：这些旧对象会被更高层的 Task 语义包起来。
第四层是 Sandbox & Runtime。ART 仍然承担 Java/Kotlin 应用运行，native runtime 仍然承担高性能执行，isolated process、Privacy Sandbox SDK Runtime、Microdroid 或类似虚拟化能力可以承载更强隔离。端侧模型运行时、embedding、VLM 前处理和 GUI 自动化沙箱，也应该在这一层被统一调度。
第五层是 HAL / Kernel / Hardware。这里提供 NPU/GPU/CPU、内存分层、低功耗 sensor hub、TEE/SE、Binder、SELinux、cgroup、seccomp、mmap CoW、TEE driver 等资源和安全基础。kernel 不应该承载 Agent 任务语义，它应该负责资源、安全、隔离和性能。
右侧是 Cloud Agent Runtime。Agent 手机一定是端云共同体。云端负责长任务沙箱、浏览器、代码工具、文档工具、长期记忆、A2A 网关、push 回调和数据策略。端侧负责现场、隐私、确认和刹车。两者之间同步的是 Task、Artifact、授权、审计和状态，而不是一段无边界的聊天记录。
这套结构有几个关键取舍。
第一，把 Task Runtime 放到一等位置。Agent OS 的前台是任务流，聊天框只是入口之一。系统必须管理任务状态、Artifact、进度、失败、取消、回滚和历史。没有 Task Runtime，Agent OS 很容易退回“助手 App + 通知”的形态。
第二，把 Policy / Consent / Audit 从 Access manager 里拆出来。Agent 操作手机不是普通权限申请。它需要回答“本次任务是否允许”“这一步是否要确认”“结果是否可追溯”“用户是否能撤销”“责任归谁”。支付、发消息、删文件、提交订单、对外发布内容，都需要审计和同意机制。权限系统只能回答“能不能访问”，不能完整回答“是否应该执行”。
第三，区分 Android、GMS 和厂商自建能力。AICore 是 Google 在 Pixel 与合作 OEM 上以系统 App 形式提供的端侧基础模型服务（Gemini Nano 宿主），不属于 AOSP，中国 ROM 不天然具备。需要注意 Apple Private Cloud Compute（PCC）与 Android 侧 Private Compute Core（同样缩写 PCC，宿主 Android System Intelligence）是两个不同体系，使用时需区分；中国厂商更可能由自建模型服务和本地合规云替代。
第四，不把 ART 写成 Agent Runtime。ART 会继续承担应用运行、JIT/AOT、Profile 优化和进程模型的一部分，但 Agent Runtime 不太可能由 ART 直接演化而来。更可能的结构是：Agent Runtime 作为系统服务和沙箱运行环境，建立在 ART、native runtime、isolatedProcess、SDK Runtime、Microdroid/虚拟化能力之上。
第五，把 Memory 拆开。Agent 的“记忆”至少有四类：当前上下文快照、用户长期偏好、任务运行中的中间状态、模型 KV/cache 与 embedding 索引。这几类在安全等级、生命周期、存储位置、删除机制上都不一样。把它们都叫 Semantic memory，会掩盖工程边界。
Android 短期 Agent OS 的基本判断是：主战场不在 kernel，不在 Launcher 单点，也不在某个超级助手 App，而在 Framework/SystemUI/privileged services 与云端 Agent Runtime 之间。
拆到工程服务，至少需要四组能力
如果把这套架构进一步拆成 Android 工程服务，可以在 Framework 层补四组服务。
第一组是 Task 服务组：
1 | TaskManagerService |
TaskManagerService 负责创建、恢复、取消和调度任务。TaskStateStore 保存任务状态和步骤。ArtifactProvider 管理任务产物。TaskHistoryProvider 让用户和系统能查询历史。TaskNotificationAdapter 把任务同步到通知、锁屏、手表和车机。
这一组服务决定 Agent OS 是否只是聊天 UI。没有它，系统无法把“帮我办一件事”变成可见、可控、可恢复的对象。
第二组是 Capability 服务组：
1 | CapabilityRegistryService |
CapabilityRegistryService 汇总所有可调用能力。AppFunctionIndexer 负责 Android AppFunctions。AgentCardRegistry 负责本地和远端 Agent 声明。McpToolBridge 连接工具服务。GuiAutomationBroker 管理 GUI 自动化的临时授权与执行边界。
这一组服务决定系统能不能从“用户目标”找到“可执行能力”。如果没有统一索引，Agent 只能靠模型猜，最后又会回到不稳定的屏幕点击。
第三组是 Context 和 Memory 服务组：
1 | ContextSnapshotService |
ContextSnapshotService 提供当前现场的最小语义快照。SemanticIndexService 管理本地索引。PreferenceMemoryService 保存长期偏好。EphemeralTaskMemory 保存任务运行中间状态。MemoryDeletionService 提供可见删除和可验证删除。
这一组服务决定 Agent 是否“懂用户”，也决定用户是否愿意被它理解。记忆一旦黑盒化，信任会快速下降。
第四组是 Policy 和 Security 服务组：
1 | AgentPolicyService |
AgentPolicyService 处理数据分级和执行规则。ConsentManager 管理每次确认。AuditLogService 记录调用和副作用。RiskClassifier 判断动作风险。EnterprisePolicyAdapter 接入公司 MDM 或合规策略。SecureExecutionBroker 把支付、凭据、签名、Passkey 和高敏动作放入安全边界。
这一组服务决定系统能不能承担责任。没有它，Agent 每多一个权限，就多一个事故入口。
这四组服务可以和 Agent scheduler、Memory manager、Context manager、Access manager 这类宏观模块并存。宏观架构负责让人看懂层次，工程拆解负责说明系统里到底要增加哪些服务。Agent OS 的系统服务是一组围绕任务、能力、上下文、策略协同工作的服务集，不宜被简化成四个大盒子。
对 kernel 层的判断
架构里可以出现 “Linux kernel / Agent OS kernel support” 这类表述，但措辞要谨慎。
Agent OS 短期不需要一个“Agent kernel”。它需要的是现有 Linux/Android kernel 能力被更好地使用：cgroup 控制资源，SELinux 约束访问，seccomp 限制系统调用，Binder 保证本地 IPC，mmap CoW 共享模型权重，mmap+madvise 或 io_uring 帮助权重按需加载，userfaultfd 等机制服务于 ART GC 与更细粒度的内存管理，TEE driver 连接安全硬件。
Agent 语义不该塞进 kernel。kernel 只应该回答资源、安全、隔离和性能问题。Task 是什么、Artifact 是什么、用户确认在哪里、哪类数据能不能上云，这些应该在 Framework、系统服务和云端策略层处理。
这个判断需要 Android 厂商提前说清。不要为了“Agent OS”去大改 kernel 主线。短期更值得投入的是 System Server、HAL runtime、端侧模型服务、SystemUI、权限 UI 和云端协议。kernel 优化应该服务于模型权重共享、低功耗常驻、沙箱隔离和安全执行，而不是承载业务语义。
四、OpenAI 的分叉：基于 Android 与不基于 Android
Android 路线讲清楚之后，再回头看 OpenAI。这里不能默认 OpenAI 一定用 Android。
如果 OpenAI 不基于 Android，它会获得更干净的设计空间。主屏可以从第一天就是任务流，权限可以从第一天按 Agent 任务设计，App 不再是默认中心，云端长期记忆和订阅也可以深度绑定。它不用向 Android 历史兼容妥协，也不用让每个功能都套进 Activity/Intent/Service/Broadcast 的旧模型。
但它会立刻面对一个更硬的问题：用户每天要用的服务从哪里来？
手机 OS 的难度从 kernel、UI、驱动和系统 API 延伸到应用与服务网络。微信、WhatsApp、Instagram、TikTok、YouTube、Uber、DoorDash、Google Maps、支付宝、美团、银行、公司 MDM、运营商服务、政务 App、校园 App、门禁 App、医疗 App，这些软件同时也是现实生活入口。
一个非 Android 的 OpenAI 手机如果想成为主设备，必须选择几条补偿路径。
第一，走 Web/PWA。很多服务可以通过 Web 完成，云端 Agent 可以操作浏览器，手机端提供确认和凭据。但 Web 在支付、通知、离线、性能、传感器、后台和本地能力上仍然不如原生 App。头部平台还可能限制自动化访问。
第二，走云端 App 代理。Agent 在云端打开网页、调用 API、运行浏览器或模拟终端，手机只做任务入口和确认。这适合研究、办公、购物比较、内容处理、轻量服务，不适合高敏支付、IM、银行、游戏、打车实时位置和本地设备控制。
第三，走 Android 兼容层。系统前台不是 Android，但能运行 Android App。这样可以保留服务覆盖面，但工程难度和法律/商业协商都会很重。应用厂商也可能通过设备认证、完整性检查、风控策略限制这种环境。
第四，先做副设备。让 OpenAI 设备成为任务入口、语音入口、记忆入口和云端 Agent 入口，仍然依赖用户现有 iPhone/Android 完成敏感操作。这条路可以避开主设备替换压力，但它也会被问到：用户为什么不直接用手机里的 ChatGPT？
第五，做企业或高端窄场景设备。比如面向高频商务、创作者、开发者、销售、医生、律师、研究员的 AI 工作手机。它不需要立刻覆盖所有生活服务，只要在高价值任务上胜出，就能验证 Agent OS 的产品形态。
所以，非 Android 路线可行，但必须接受一个现实：没有应用兼容，很难成为第一手机；保留应用兼容，又会被旧 App 模型拖住。OpenAI 如果要走新 OS，更现实的路径是先把任务流、云端 Agent、订阅和少数高价值服务做穿，再逐步扩大可调用能力。
从系统架构看，非 Android 路线也绕不开类似模块：
1 | Task Stream Shell |
名字可以不叫 Android，底层原理仍然相近。OS 要管理身份、权限、进程、存储、网络、显示、输入、传感器、安全和开发者接口。Agent OS 只是把“任务”和“能力调用”抬到更高优先级，不会取消这些基础工作。
换个角度说，Android 与非 Android 的分歧不在“有没有 Agent”，而在“用什么方式承接旧世界”。Android 路线用兼容承接旧世界，再在前台加任务流。非 Android 路线用任务流定义新世界，再用 Web、云端和兼容层补旧世界。
前者更稳，后者更干净。前者容易渐进，后者更容易做出范式样本。OpenAI 的优势恰恰在于它没有 App Store、没有 Launcher、没有 OEM 历史包袱，所以它敢让任务流站在第一屏。它的劣势也来自这里：没有那些包袱，也没有那些资产。
非 Android 路线的三种样机
如果 OpenAI 真的不基于 Android，它大概率不会一上来做“完整手机 OS”。更可能先出现三类样机。
第一类是任务终端型手机。
它有屏幕、有蜂窝网络、有相机、有语音入口，也许能打电话和收短信，但第一屏完全不是 App 网格。它的主界面是 ChatGPT Task Stream：待办任务、正在运行任务、等待确认任务、已完成 Artifact。App 兼容靠 Web、云端浏览器和少量原生服务。它像手机，但不试图完整复制 Android 手机。
这种设备适合高端用户和高价值任务。比如商务差旅、研究写作、创作剪辑、销售跟进、个人助理、开发者工作流。它不一定能覆盖全部生活场景，但可以在“减少跨 App 操作”上建立样板。
第二类是手机伴随设备。
它不争第一手机，而是绑定用户现有 iPhone 或 Android。它负责语音、记忆、任务发起、云端 Agent、拍照理解和轻量确认。涉及支付、IM、银行、公司 MDM 的动作，仍然回到主手机确认。
这种设备的好处是进入门槛低，不必一次性解决 App 兼容。坏处是用户会问：为什么不用手机上的 ChatGPT App？所以它必须在常驻、低打扰、随身捕获和任务持续上明显胜出。
第三类是企业/专业设备。
OpenAI 可以先面向高价值职业做 Agent OS 设备：医生查资料和写病历，律师整理案例和合同，销售跟进客户，研究员做资料搜集，记者做采访整理，创作者做素材处理，开发者做代码任务。这类设备不需要所有消费 App 都兼容，只需要和专业工具、企业系统、浏览器和文件系统深度协作。
这条路线听起来不像大众手机，但更符合 Agent OS 初期的经济逻辑。普通用户愿意为“少打开几个 App”付多少钱并不确定，专业用户愿意为“每天省一小时高价值工作”付多少钱更容易计算。
OpenAI 不用 Android 的代价
非 Android 路线的代价可以拆成六类。
第一是应用可用性。没有 Android/iOS 原生 App，很多服务只能走 Web 或云端代理。用户日常生活里最难替代的是那些带支付、风控、消息、地理位置、推送和本地设备能力的 App，而不是浏览器能打开的网页。
第二是账号和身份。手机是身份容器。Passkey、SIM/eSIM、运营商、银行证书、公司 MDM、政府服务、家庭共享，这些需要长期积累和认证。新 OS 要重建这些关系。
第三是开发者动机。开发者为什么为 OpenAI Agent OS 暴露能力？是为了新增用户、获得分成、降低客服成本，还是因为不接入会被用户抛弃？在没有装机量前，这个问题很难回答。
第四是平台责任。Agent 代用户提交订单、发送消息、发布内容、处理账单，一旦出错，责任归用户、OpenAI、服务 App 还是第三方商家？传统 OS 可以说“App 自己负责”；Agent OS 很难这样切割。
第五是供应链与售后。手机是低容错硬件。基带、天线、射频、散热、续航、跌落、维修、备件、地区认证、运营商测试，都不是 AI 公司擅长的领域。立讯这类系统制造伙伴能帮忙，但产品责任仍在品牌方。
第六是用户迁移。用户不会因为一个新入口就放弃 iMessage、微信聊天记录、相册、钱包、健康数据、会员权益和车钥匙。OpenAI 必须给出“先并存、后迁移”的路径。
所以非 Android 路线更适合做定义样本，而不是第一天就做全球主力手机。它可以证明任务流和云端 Agent 的价值，然后逼 Android 和 iOS 吸收它的形态。
OpenAI 如果基于 Android，反而要解决什么
基于 Android 并不轻松。
第一，它要决定自己和 Google 的关系。是否使用 GMS？是否预装 Play Store？默认助手如何与 Gemini 竞争？AppFunctions、AICore、Android AI APIs 是否能被 OpenAI 深度使用？如果不用 GMS，海外应用可用性会受影响；如果用 GMS，系统入口又会受到平台规则影响。
第二，它要决定 Android App 在任务流里的地位。是保留传统 Launcher，还是把 Launcher 放到二级入口？是允许用户始终回到 App 网格，还是强推 Task Stream？第一代产品大概率必须保留 fallback，否则用户会在关键时刻失去安全感。
第三，它要解决权限可信度。一个 OpenAI 系统助手如果要求读取屏幕、通知、日历、位置、相册、消息，用户会高度敏感。它必须给出比普通 Android 权限更清晰的解释：哪些数据在端侧处理，哪些数据上云，哪些只在本次任务使用，哪些会被记忆，哪些永不记忆。
第四，它要和头部 App 谈合作。没有结构化能力，OpenAI 手机只能靠 GUI Agent 点屏幕；靠 GUI Agent 点屏幕，头部 App 很快会限制。OpenAI 必须给服务商一个理由：让 Agent 调用你，会给你带来更多交易、更少客服、更高转化，且责任可分。
第五，它要做硬件与模型的功耗管理。ChatGPT 级体验如果持续占用网络、NPU、麦克风、相机和屏幕，用户会先感受到发热和耗电，而不是智能。Agent 手机的第一条硬指标可能会变成“常驻一天后，用户还愿意开着它”，模型排名只占一部分。
这就是 Android 路线的难处：它能更快成为手机，但也更容易被旧手机范式拖住。非 Android 路线能更像 Agent OS，但更难成为手机。
五、端云、硬件、产业与时间表
豆包手机与 OpenClaw/ArkClaw 这类端云组合，提供了一个很好的观察角度：AI 手机需要端云共同工作，不能停留在端侧模型加云端聊天。
端侧的职责不是跑一个小模型装样子。端侧要做五件事。
第一，实时感知。屏幕、通知、位置、相机、麦克风、蓝牙、传感器、前台 Activity、剪贴板、系统设置，这些只有端侧知道。
第二，低延迟判断。唤醒词、意图分类、风险判断、简单总结、端侧 embedding、端侧 VLM 前处理，都需要低功耗、低延迟，不适合每次上云。
第三，隐私封闭。支付凭据、生物识别、健康数据、IM 私密内容、相册敏感内容、精确位置、公司受管数据，不能被云端随意读取。端侧要有私密计算区和最小上下文裁剪。
第四，最终确认。Agent 可以建议和准备，但钱、消息、订单、删除、发布、授权，很多动作要在端侧由用户确认。确认承担责任边界功能，不能被当成普通 UI 细节。
第五，中断和刹车。用户随时可以停止任务、撤销授权、查看历史、删除记忆。这个控制权应该由端侧系统持有，而不是藏在云端会话里。
云端的职责也不是“更大的模型”。云端要承担端侧不适合做的长任务。
第一，长时运行。订旅行、做资料整理、整理合同、写报告、剪视频、跑代码、比价、联系多个服务，这些任务不是一次请求。它们可能持续几分钟、几小时甚至几天。
第二，工具环境。浏览器、代码沙箱、文件系统、数据抓取、文档处理、表格、图像生成、音视频处理，端侧可以启动，但不该全部承重。
第三，长期记忆。用户偏好、风格、常用路线、工作习惯、家庭关系、项目上下文，需要跨设备、跨会话、跨年累积。端侧可以保存索引和敏感真值，云端可以保存经过策略过滤后的记忆图谱。
第四，Agent 协作。复杂任务会被拆成多个子任务：研究、比较、执行、校验、写作、排程、通知。云端更适合同时运行多个受隔离的子 Agent。
第五，跨设备连续性。用户在手机上发起任务，在电脑上继续编辑，在耳机里听进度，在车机上确认路线。Agent 不应该绑定单设备，而应该绑定用户身份和任务状态。
端云之间需要协议层，它要包含任务状态、消息、Artifact、权限、数据分级、推送回调、失败恢复和审计标识——单纯 HTTPS API 不够。A2A 的 Task、Message、Part、Artifact、streaming、push notification 等设计，可以作为参考。Android 本地不一定用 HTTP A2A，但这些抽象很适合迁移到 Binder 或系统服务内部。
从端云分工看，未来 Agent 手机的 SoC 设计也会变。过去手机芯片强调 CPU/GPU/NPU 峰值、影像 ISP、基带和功耗。Agent 手机会增加几个持续压力：
- 持续上下文理解带来的低功耗 NPU 使用。
- 多任务状态、embedding、KV cache、索引带来的内存压力。
- 相机、麦克风、传感器与模型前处理的常驻调度。
- TEE/StrongBox/安全元件对凭据、支付、私密记忆的托管。
- 端云任务往返带来的网络、推送、断点续传和后台唤醒。
这解释了为什么 OpenAI 如果认真做 Agent 手机，会关心处理器协同设计，而不是只采购现成旗舰 SoC。AI Agent 手机处理器需要面向持续上下文、内存分层、低功耗感知和安全执行重新分配预算，不能只理解成“更大 NPU 的手机芯片”。
数据分级决定端云路由
端云分工不能只按“模型大小”决定。更合理的方式是按数据敏感度、实时性、任务时长和副作用风险共同决定。
可以把手机里的数据粗略分成五层。
L0 是公开数据。天气、公开网页、公开商品信息、公开交通信息，可以直接让云端处理。
L1 是低敏个人数据。比如用户主动提供的一段需求、当前城市、偏好的酒店类型、公开日程标题。这类数据可以在授权后上云，但要有使用目的和过期时间。
L2 是中敏个人数据。比如完整日历、购物历史、常用联系人、位置历史、文件摘要、工作项目名称。这类数据可以上云，但应该经过裁剪、脱敏或按任务临时授权。
L3 是高敏数据。比如聊天内容、相册原图、健康数据、精确位置、公司文件、家庭关系、财务信息。这类数据默认端侧处理，只有在用户明确确认并且任务需要时，才传最小片段。
L4 是不可出端数据。比如生物识别、支付密钥、Passkey 私钥、银行验证码、企业证书、设备密钥。这类数据只能在端侧安全边界内使用，云端最多拿到“用户已确认”或“签名完成”的结果。
端云路由应该像下面这样工作：
1 | 用户任务 |
这套机制听起来繁琐，却是 Agent 手机能否被信任的前提。过去用户授权一个 App 访问相册，已经足够敏感；Agent 手机会读取更多上下文，若没有数据分级，会比任何 App 都更像黑盒。
这里 Android 厂商有一个机会：用系统 UI 把数据边界可视化。比如任务卡上明确显示：
- 本次任务使用了 2 张图片、1 条日程、3 条公开网页。
- 上传到云端的是发票字段，不是原始相册。
- 支付凭据未离开设备。
- 任务完成后，临时上下文将在 24 小时后删除。
- 用户可以在任务历史中删除 Artifact 和记忆。
这种 UI 不一定华丽，但会比一句“重视隐私”的口号更有说服力。
云端 Agent 不是无状态 API
很多手机团队习惯把云端看成 API：端侧发请求，云端返回结果。这种模型不适合 Agent 手机。
复杂任务需要云端保持状态。用户让 Agent 研究旅行方案，云端会打开网页、记录候选酒店、比较航班、保存预算表、等待价格变化、生成行程文档。这些中间状态不能每次都塞回 prompt，也不能每次都重新开始。
云端 Agent 更像一个用户专属工作空间。它可以是容器、microVM、浏览器会话、文件系统、向量数据库、任务队列、工具集合的组合。每个用户的任务需要隔离，每个任务的文件和凭据需要隔离，任务结束后需要可清理。
OpenClaw/ArkClaw 这类云端 Agent 方案的价值就在这里：云端给用户提供一个长期在线的执行环境，而非只帮手机跑大模型。它可以运行浏览器、代码、文档、表格、图像工具，可以在用户离线时继续工作，也可以在需要确认时推回手机。
但这种云端形态也有三个风险。
第一是成本。一个常驻或准常驻的云端 Agent 比普通 API 请求贵得多。订阅制、硬件绑定、任务额度、企业付费，会成为商业模型的一部分。
第二是安全。云端 Agent 拿到的工具越多，越需要沙箱隔离、网络访问控制、文件访问控制、凭据最小化和 prompt injection 防御。它不能因为读到网页上的恶意指令，就替用户泄露文件或下单。
第三是可解释。用户不能只知道“云端帮你处理了”。他要能看到任务步骤、调用来源、生成依据和最终确认点。否则长任务越长，用户越不放心。
所以端云架构不能简化成“端小云大”：端侧负责现场、隐私、确认与刹车，云端承担长任务、工具、记忆与并发，协议层管理状态、授权、Artifact 与审计。
端侧模型的角色不要被夸大，也不要被低估
端侧模型不会在短期内替代云端模型。手机上的功耗、内存、热设计和成本限制决定了它不适合承载所有复杂推理。但端侧模型也不是配角。
端侧模型最适合做五类工作。
第一是唤醒和意图分类。用户一句话进来，端侧先判断是否需要上云、是否涉及隐私、是否是本地可处理任务。
第二是上下文裁剪。端侧把屏幕、通知、日历、相册、文件裁剪成任务所需的最小片段，再决定哪些能上云。
第三是隐私敏感理解。比如通话诈骗识别、验证码识别、健康异常提示、私密照片分类、公司文件摘要，这些可以在端侧完成或预处理。
第四是快速反馈。翻译、摘要、改写、简单问答、图片局部编辑、语音转文字，用户对延迟敏感，端侧模型有优势。
第五是失败兜底。断网、弱网、云端拥塞、用户关闭云端权限时，端侧要提供最低可用能力。
这也是处理器协同设计的价值。Agent 手机不只需要大算力，还需要低功耗常驻模型、快速冷启动、模型权重共享、embedding 索引、KV/cache 管理和安全内存。NPU 峰值只能说明一部分，持续运行体验才决定用户是否愿意开启 Agent。
五类玩家的不同位置
OpenAI 的位置最特殊。它拥有模型、消费端品牌、订阅关系和全球开发者关注度，没有传统手机包袱。它可以激进地把 Task Stream 放在第一屏，把 App 看成后台能力，把订阅与硬件绑定，把云端长任务作为差异。它的问题也清楚：缺少本地服务、支付、地图、社交和渠道；中国市场几乎必须找本地伙伴；App 的可调用权要重新谈；第一代硬件的可靠性压力很大。
Apple 的优势是端侧硬件、系统权限、隐私品牌、App Store、App Intents 和用户信任。它不需要激进改主屏，就能把 Siri、Spotlight、通知、快捷指令、App Intents、Private Cloud Compute 逐步织在一起。Apple 的约束是它不愿伤害 App Store 和现有使用习惯。它会慢，但慢不代表弱。只要 Apple 把任务建议、App Intents 和系统确认做好，用户迁移成本很低。
Google + Samsung 是 Android 阵营的标准化路径。Google 有 Android、Gemini、AppFunctions、A2A 和云；Samsung 有高端硬件、Galaxy AI、Now Brief、Bixby、Now Bar 和全球用户。Samsung 愿意把系统入口交给多 Agent 组合，是 Android 阵营很重要的试验场。难点是 Android 阵营利益分散：Google、Samsung、Qualcomm、MediaTek、OEM、运营商、头部 App、地区监管都在影响系统选择。
字节豆包是中国市场最有参考价值的样本之一。豆包手机、系统级权限、Virtual Display、UI-TARS、OpenClaw/ArkClaw 等内部方案（公开口径上对应 Coze Space 方向的云端 Agent 环境），把“AI 代用户操作 App”从 PPT 推到了设备上。它的价值不在销量，而在于让行业提前看到两件事：Agent 手机可行，且第三方 App 会反制。字节拥有中文内容、视频创作、办公、模型、广告和电商服务，但没有主流手机 OS 主导权。它若要继续向前，必须从“能点屏幕”走向“协议调用、可审计授权和商业分配”。
华为、小米、OPPO、vivo、荣耀拥有系统权限、硬件、渠道、本地服务和合规能力。它们很适合做中国版 Agent OS，但也最容易各做一套。如果每家都有自己的技能协议、记忆格式、AgentCard、支付确认和任务状态，开发者会重新经历一遍适配地狱。中国 Android 阵营要把握住这次机会，不能只靠 ROM 里多一个 AI 助手，而要在能力声明、权限授权、任务状态、数据分级和审计记录上形成相对稳定的共同语言。
还有一类玩家不能忽略：头部 App。它们不一定愿意被 Agent 调用。对微信、淘宝、支付宝、美团、抖音、银行和游戏来说，前台入口就是商业资产。Agent 如果把入口拿走，平台会担心用户关系、广告、交易分成、风控和责任都被改写。未来几年，Agent OS 最大的谈判会发生在系统厂商、AI 厂商与头部 App 之间，问题是入口、数据和责任如何重新分配。
五类玩家的真实约束
为了避免把每家公司的路径写成口号，可以把它们都放进同一张约束表里看。
| 玩家 | 最强资源 | 最大约束 | 更可能先做出的形态 |
|---|---|---|---|
| OpenAI | 模型、品牌、订阅、云端 Agent | App 可调用权、本地服务、硬件售后 | 任务流优先的 AI 手机或高端任务设备 |
| Apple | 端侧硬件、系统、隐私、App Store | 不能伤害 App Store 和既有习惯 | Siri + App Intents + 系统任务建议 |
| Google + Samsung | Android 标准、Gemini、硬件、全球渠道 | 阵营分散、OEM 利益不同 | AppFunctions + Galaxy AI + Now Brief |
| 字节豆包 | 中文内容、云、模型、视频/办公/电商 | 没有主流 OS 主导权、头部 App 反制 | 系统级助手 + 云端 OpenClaw + 自家服务 |
| 中国 OEM | 系统权限、渠道、本地合规、硬件 | 协议碎片、模型和服务差异 | ROM 级 Agent + 本地服务合作 |
这张表里，OpenAI 的优势和其他玩家相反。传统手机厂商有手机，却缺一个足够强的 Agent 入口；OpenAI 有 Agent 入口，却缺手机世界里最麻烦的服务关系。它做手机，是从任务入口走向硬件；其他厂商做 Agent OS，是从硬件和系统权限走向任务入口。
两边会在 2028 年前后相遇。
如果 OpenAI 做得足够好，它会证明“任务流优先”可行。传统厂商会吸收它的交互和任务模型。
如果 OpenAI 硬件失败，它也会留下边界经验：哪些任务用户愿意交给 Agent，哪些服务必须回到 App，哪些权限用户无法接受，哪些硬件形态不适合常驻。
这就是它“搅局”的价值。它不一定要成为最大手机厂商，才会改变手机行业。
产业链信号为什么值得看
郭明錤消息里把联发科、Qualcomm 和立讯放在一起，已经超出普通供应链八卦。如果这件事成立，OpenAI 的目标会覆盖两层：找制造伙伴，也介入系统设计、SoC 定义和制造协同。
手机 Agent 化会改变 SoC 需求。
传统旗舰 SoC 很重视峰值：CPU 单核、多核、GPU、NPU TOPS、ISP、基带。Agent 手机当然也需要这些，但它更看重持续负载。
常驻 Agent 不会每十分钟跑一次大模型就结束。它会持续监听低功耗事件，持续维护小上下文，频繁做 embedding 和 rerank，时不时调用 VLM 看屏幕或相机，后台同步云端任务，等待推送，再把确认卡拉到前台。
这会把压力转向几个地方。
第一是低功耗感知。语音、运动、位置、蓝牙、日历、通知这些事件要被持续处理，不能每次唤醒大核和大模型。Sensor hub、DSP、小 NPU、always-on island 的权重会更高。
第二是内存分层。模型权重、KV cache、embedding 索引、任务状态、屏幕语义快照，会和传统 App 争内存。8GB、12GB、16GB 内存的差异会体现在后台保活，也会体现在能不能同时承载多个 Agent 子任务。
第三是安全存储。Agent 会接触凭据引用、支付确认、私密偏好、公司资料、身份令牌。StrongBox、TEE、安全元件、加密存储和远程证明会从“安全规格”变成体验的一部分。
第四是网络与推送。端云任务往返比普通 App 请求更频繁，也更依赖可靠推送。任务中断、重试、弱网恢复、漫游、飞行模式恢复，都要考虑。
第五是热和电池。用户不会接受一个因为 AI 常驻而明显发热、掉电的手机。Agent 手机的产品成败，可能会被一个很朴素的问题决定：默认开启一天，续航还能不能让用户放心。
联发科和 Qualcomm 在这里各有位置。Qualcomm 强在高端 Android、基带、NPU、全球旗舰合作。联发科强在成本、集成、与部分 OEM 的合作灵活性。OpenAI 同时接触两家，合理解释是它在比较不同 SoC 定义路径，而不是已经锁定某个传统手机方案。
立讯的位置也值得看。它不是简单代工。AI Agent 手机如果要重写硬件交互，可能涉及新按键、新麦克风阵列、新传感器布局、新散热、新天线空间、新安全元件位置、新屏幕常显策略。系统协同设计会比普通 ODM 更重要。
但也要克制判断。供应链消息成立，不代表产品一定成功。硬件产业里，样机、EVT、DVT、PVT、量产、渠道、售后，每一关都可能改变方向。对 Android 从业者来说，更有价值的观察对象是它如何定义 Agent 手机的 SoC、权限、入口和端云分工，而不是押 OpenAI 手机销量。
2026 到 2032：更可能发生什么
2026 到 2027 年，是“助手前置、App 网格保留”的阶段。
这一阶段，厂商会把长按侧键、语音、耳机、锁屏、通知、悬浮入口交给 AI 助手。Now Brief、Now Bar、系统简报、智能通知、跨 App 摘要、屏幕问答、端侧修图、实时翻译、会议纪要会继续铺开。GUI Agent 会在部分任务里出现，AppFunctions / App Intents 会从头部场景开始扩展。
这个阶段的体验会混杂。很多功能看起来像 AI 手机，实际仍是旧 OS 加助手。用户会觉得“好用的任务很惊艳，不好用的任务很尴尬”。它会优先暴露四类工程缺口：任务状态、权限确认、能力路由和失败恢复。
2028 年可能是外部参照出现的窗口。
如果 OpenAI 手机按郭明錤消息进入量产，它未必会立刻抢走 iPhone 或 Galaxy 的主流份额。但它会提供一个行业参照：主屏能不能不从 App 开始？任务能不能成为 OS 第一对象？硬件订阅能不能和云端 Agent 合并？手机 SoC 能不能围绕持续上下文设计？用户能不能接受一个更主动的任务流？
OpenAI 的第一代手机即使销量有限，也可能像早期 Surface、Pixel 或 Vision Pro 那样，承担定义样本的角色。它会把评测指标从“相机、续航、屏幕、跑分”扩展到“任务完成率、等待确认设计、隐私分级、长任务恢复、跨设备连续性、App 可调用性”。
2029 到 2030 年，App 入口会开始明显退到后台。
这个判断不等于 App icon 消失。更可能发生的是，用户的高频操作逐步被任务流承接。主屏可能出现三种常驻视图：对话、任务、记忆。通知中心会变成任务状态面板。App Store 会增加能力商店属性。开发者不只提交 App，也提交可被 Agent 调用的函数、schema、价格、权限和结果格式。
这时手机厂商会发现，Launcher 的问题已经从桌面布局扩大到任务操作系统。谁能更好地理解用户状态、调度能力、控制风险，谁就能掌握下一层入口。
2031 到 2032 年，多设备 Agent 会开始超过单手机 Agent。
手机仍在中心，但它不再是唯一入口。眼镜负责视觉，耳机负责语音，手表/戒指负责生理信号，车机负责出行，电脑负责复杂编辑，电视负责家庭内容，家居设备负责空间状态。手机会成为身份、授权、确认和高算力本地节点。
到这个阶段，Agent OS 的对象不再是一台设备，而是一个用户的设备群。任务在手机上发起，在电脑上继续，在耳机里提醒，在车机上确认路线，在家里通过音箱播报。OS 的边界会从“设备操作系统”扩展到“个人任务系统”。
用几类真实任务检验时间表
时间表如果只按年份写，会显得像预测列表。更好的方式是看几类任务什么时候能做稳。
第一类是信息整理任务。会议纪要、网页摘要、通知整理、邮件草稿、旅行方案比较、资料收集。这类任务不太依赖高风险动作，也不一定要调用头部 App 深层接口。2026 到 2027 年就会快速成熟。它们会成为用户接受 Agent 手机的第一批理由。
第二类是轻执行任务。创建日程、生成待办、保存文件、发给自己、整理相册、设置提醒、简单购物比价。这类任务需要系统权限和少量 App 配合，但风险较低。它们适合 AppFunctions、App Intents 和系统能力组合，2027 前后会进入高频。
第三类是交易任务。订票、订酒店、点外卖、打车、买商品、取消订阅、报销、缴费。这类任务牵涉支付、价格、售后、责任和风控。GUI Agent 可以先做演示，但要做稳，必须有平台合作和结构化能力。大规模稳定可能要到 2028 之后。
第四类是社交和内容发布任务。发微信、回邮件、发微博、发小红书、发抖音、评论、私信。这类任务风险不只在技术，也在语气、关系和后果。Agent 可以起草和建议，但直接代发会很谨慎。用户信任建立前，确认步骤很难取消。
第五类是高敏任务。银行、证券、保险、医疗、政务、公司审批、合同签署、身份认证。这类任务会最晚开放，也最能检验 Agent OS 的权限和审计设计。没有强确认、强审计、强责任边界，平台不会让它接入。
这五类任务的发展节奏，会比“哪一年出现 Agent OS”更有判断价值。
2026 到 2027 年，信息整理和轻执行会成熟。
2028 到 2030 年，交易任务会开始被系统级 Agent 稳定承接。
2030 之后，社交代办和高敏任务才可能在特定边界内开放。
这也解释了为什么 OpenAI 第一代手机即使存在，也不会一开始就替代所有 App。它更可能先把信息整理、长任务、研究、创作和轻执行做得很强，再逐步触碰交易和高敏任务。
六、产品形态、市场分化与责任分配
如果把 2028 到 2032 年的 Agent OS 手机收束成一种产品形态，它大概率不会是一个全屏聊天机器人。
聊天仍然需要保留，因为自然语言是低成本入口。但聊天不是终点。用户不想和手机聊一整天，他想让手机少打扰、少切换、少遗忘、少重复输入。
更可能的第一屏，是任务流。
早上，手机显示今日需要确认的任务：航班改签建议、会议材料摘要、孩子学校材料、账单到期提醒、健身计划、昨晚云端完成的资料整理结果。每个任务都有状态、来源、下一步、风险和确认按钮。
白天，用户说“把这份 PDF 里的合同风险标出来，下午三点前给我一个可转发版本”。手机把文件交给云端沙箱处理，端侧保留敏感字段索引，云端生成报告，完成后推回任务卡。用户确认后，系统调用办公 App 发出。
晚上，用户说“下个月带父母去云南，别太累，预算 1.5 万”。云端跑路线和酒店，端侧读取家庭日历和天气偏好，系统在几小时后给出三套方案。用户不用一直守着聊天窗口。
这些体验背后有三个界面层级。
第一层是 Task Stream。它是主屏、通知和锁屏的结合体，管理等待确认、执行中、已完成和失败任务。
第二层是 Capability View。用户或开发者可以查看哪些 App、服务、Agent 能被调用，能做什么，权限范围是什么，价格和风险是什么。
第三层是 Memory View。用户可以查看 Agent 记住的偏好、项目、关系、常用信息，也可以编辑和删除。
这三个视图会逐步取代一部分 App 网格使用时间。App 网格仍在，像文件系统仍在、命令行仍在一样。只是不再是大多数用户完成任务的起点。
第一屏会变成什么样
第一屏不太可能只有一个大聊天框。纯聊天入口有两个问题：一是用户需要不断表达，二是任务状态不可见。
更合理的第一屏可能分成四块。
第一块是当前任务。显示正在运行、等待确认、即将到期的任务。每个任务卡有来源、状态、下一步和风险提示。
第二块是今日状态。把日历、天气、出行、健康、消息、账单、家庭事项整理成短摘要，但不把所有信息都塞满屏幕。
第三块是快速表达。用户可以语音、文字、截图、拍照或分享内容给 Agent，创建新任务。
第四块是 App fallback。用户仍然可以打开传统 App 网格，尤其是在 Agent 不可靠、用户想亲自操作、或任务涉及高风险时。
这四块的比例会随用户变化：重度用户大量使用任务流，保守用户仍以 App 网格为主。系统不应强迫每个人立刻进入 Agent 模式。
Generative UI 的位置
未来手机界面不会只在 App UI 和聊天 UI 之间二选一。Generative UI 会成为任务结果的一部分。
用户说“给我三套云南亲子游方案”，系统不应该只回一段文字，也不应该跳到某个 App。更好的结果是生成一个可交互面板：预算、路线、酒店、交通、老人友好程度、取消政策、天气风险、需要确认的选项。用户可以在面板里调整偏好，Agent 再继续执行。
用户说“把这份报告改成给老板看的版本”，系统可以生成对比视图、修改建议、引用来源、风险提示和一键导出，而不是只在聊天里吐出一段新文本。
Generative UI 的关键在于把任务的中间状态变成可操作界面，而非炫技。这样用户能参与决策，而不是把判断全部交给模型。
对 Android 来说，Generative UI 会给现有 View/Compose/WebView 带来新问题：界面从哪里来，谁负责安全，是否能调用系统能力，是否能嵌入第三方服务，是否能被截图审计，是否能在离线时恢复。它最终仍要回到 Task、Capability、Policy、Artifact 这些对象上。
记忆界面会成为信任入口
AI 手机越聪明，用户越会问一个问题：你为什么知道？
这会让 Memory View 变得关键。用户需要看到 Agent 记住了哪些偏好、哪些项目、哪些联系人关系、哪些常用地址、哪些写作风格、哪些旅行禁忌。用户还要能编辑、删除、暂停记忆。
记忆界面不应该像设置页里的隐私清单那么难找。它应该成为 Agent OS 的常用界面之一。记忆承担的是用户和 Agent 之间的长期契约，后台技术只是其中一部分。
一个好的记忆界面应该支持几件事：
- 按主题查看：旅行、工作、家庭、健康、购物、写作。
- 按来源查看：来自对话、来自日历、来自文件、来自用户手动添加。
- 按敏感度查看：普通偏好、高敏信息、不可出端信息。
- 支持过期：某些偏好只在本次旅行、本个项目、本个月有效。
- 支持纠错：用户可以说“这不是我的偏好，只是上次临时情况”。
没有记忆界面，Agent 会逐渐变成不可解释的黑盒。有了记忆界面，用户才可能把更多任务交给它。
中国市场会走出独立路径
产品形态讲完，还要单独看中国市场。中国市场不会简单复制 OpenAI 手机路线。
第一，OpenAI 很难直接进入中国手机主设备市场。模型合规、数据跨境、应用商店、本地支付、地图、IM、本地生活、政务和运营商关系，任何一项都足够复杂。
第二，中国用户高频服务集中在少数超级 App 和本地平台里。Agent 想完成任务，必须和微信、支付宝、淘宝、美团、抖音、京东、滴滴、银行、政务服务打交道。这里同时有技术问题、商业问题和合规问题。
第三，中国 Android 厂商有更强 ROM 定制能力，也有更复杂的厂商碎片。每家都能做自己的 AI 助手，但如果没有共同能力标准，开发者和头部 App 不会愿意为每家单独适配。
第四，豆包路线会继续有参考价值。它把系统级权限、中文内容、云端 Agent、GUI 自动化和自家 App 网络连接起来，说明中国公司有机会做出不同于 Apple/Google/OpenAI 的 Agent 手机。但它也提醒所有人：被其他 App 合法调用的权利，可能比模型参数更稀缺。
中国市场更可能出现的是多方并存：
- 华为在 HarmonyOS NEXT 上走自有系统和自有服务。
- 小米、OPPO、vivo、荣耀在 Android/AOSP 体系上加强系统 Agent。
- 字节、腾讯、阿里、美团等服务平台提供自己的 Agent 能力和开发者工具。
- 头部 App 对 GUI 自动化保持防范，但会在商业收益明确时开放结构化能力。
- 国内协议会参考 A2A/MCP/AppFunctions，但加入本地合规、数据分级、实名、支付和风控字段。
这条路径不会像 OpenAI 设想的那样干净，但会更贴近中国用户的服务现实。对 Android 手机从业者来说，更值得观察的是系统权限、端侧模型、国产云、头部 App、支付确认和任务审计能不能组合成可信的执行体系，而不是“再造一个 ChatGPT”。
中国市场的三条产品线
中国市场更可能同时出现三条产品线，而不是单一 Agent OS。
第一条是 OEM 系统助手线。华为、小米、OPPO、vivo、荣耀都会继续把助手放到系统层，接入相册、通知、日历、文件、车、家居、穿戴设备。它们的优势是系统权限和硬件入口。短板是模型与服务覆盖不一定最强。
第二条是服务平台 Agent 线。字节、腾讯、阿里、美团、百度、京东等平台会把自己的内容、交易、办公、本地生活能力封装成 Agent 或 tool。它们的优势是服务和用户行为。短板是拿不到完整系统权限，也不一定能成为默认入口。
第三条是企业和行业 Agent 线。金融、医疗、政务、教育、制造、零售都会有自己的受控 Agent。它们更重视合规、数据边界和审计，不会轻易接入消费级通用助手。
这三条线会互相合作，也会互相防备。OEM 想当默认入口，服务平台想保护自己的用户关系，行业系统想守住数据边界。Agent OS 在中国能不能做大，不只看模型水平，还看这三条线能不能形成可接受的合作方式。
对用户来说，最好的体验是一个系统级 Agent 能调用多个平台服务。对平台来说，最安全的方式是只开放受控能力，不开放全部数据和 UI。对监管来说，最可接受的是每次高风险动作都有身份、授权、审计和责任。三方都能接受的交集，才是中国 Agent 手机的可行区域。
豆包手机给行业的提醒
豆包手机最大的价值不在“做了一台 AI 手机”，而在把一组隐藏问题提前暴露出来。
第一，系统级权限很有用。没有系统权限，Agent 很难理解屏幕、操作 App、接收通知、保持后台任务。AI App 和系统 Agent 的能力差距很大。
第二，GUI Agent 很有冲击力。它让用户第一次看到“手机真的能替我操作 App”。哪怕不稳定，也足够改变想象。
第三，头部 App 会反制。平台不会无条件接受一个外部 Agent 进入自己的交易、社交和内容场景。它们会从安全、风控、用户体验、商业利益多个角度限制。
第四，自家服务网络很关键。字节能把豆包、抖音、剪映、飞书、火山、内容和广告连接起来，所以它做 Agent 手机比纯硬件厂更有服务支撑。其他 OEM 如果只靠模型和系统权限，服务深度会不足。
第五，用户接受度可能比预期高，但信任建立比想象慢。用户会被“它能帮我点 App”吸引，也会担心“它到底看到了什么、会不会乱点、会不会泄露”。
这五点对所有 Android 厂商都有参考意义。Agent 手机不会一直停留在宣传片里的顺滑执行，它会在系统权限、第三方关系、用户信任之间反复权衡。
几个边界判断
讲完产品和市场，还需要把边界先放在桌面上。
第一，Agent 不会一次性替代 App。它会先替代入口，再替代一部分跨 App 操作，最后才会改变 App 的商业形态。App 仍然是服务提供者，只是要接受被系统级 Agent 调用。
第二，GUI Agent 是必要过渡，不是长期答案。它可以证明用户需求，可以覆盖长尾，但它不适合承载高风险动作。长期答案是结构化能力、系统级授权和可审计任务。
第三，端侧隐私会成为品牌差异。用户可以接受 Agent 变聪明，但不能接受它偷偷学习和偷偷执行。哪些数据不出端，哪些数据上云，谁能审计，如何删除，发生错误如何追踪，这些要从产品第一天就说清楚。
第四，OpenAI 的硬件价值未必来自销量。它更像一个行业压力源。只要它做出一个每天可用的任务流，Android 厂商和 Apple 都会被迫解释自己的 OS 为什么还从 App 网格开始。
第五，Android 阵营的机会在标准。AppFunctions、A2A、MCP、端侧模型服务、权限系统、任务状态、通知入口，如果能形成稳定组合，Android 不需要每家都做一套私有 Agent OS。反过来，如果每家都私有化，开发者会逃回 Web 和头部平台。
第六，非 Android 路线有机会，但很难直接成为主手机。它可能先作为高端 AI 设备、副设备或窄场景工作手机出现。只有当应用兼容、服务覆盖和信任机制补齐后，才有机会进入第一手机位置。
第七，Agent OS 的竞争会从模型扩展到系统。模型决定理解和规划上限，OS 决定它能否看见状态、调用能力、取得授权、执行动作、恢复失败和承担责任。没有 OS 权限的模型，只能等待用户把问题带给它；有 OS 约束的 Agent，才能在用户生活里持续工作。
回到 OpenAI：它出来搅局为什么值得重视
到这里再回看 OpenAI 做手机，重点已经不止于硬件真假。它会把行业问题重新摆到台面上。如果这件事最后被证实，大致会有两种结果。
一种结果是它基于 Android 或 Android 兼容体系做出一台 AI Agent 手机。那它会直接给 Android 阵营一份作业：为什么一个外来者能把任务流放到第一屏，而传统 OEM 还在把 AI 功能塞进设置页、相册和助手 App？
另一种结果是它不用 Android，做出一台更像 Agent OS 的新设备。那它会给行业另一份作业：如果不背 App 网格历史包袱，手机或随身设备应该如何组织任务、记忆、权限和云端执行？
无论哪条路，它都会让手机行业把问题问准。
过去十几年，手机 OS 的竞争围绕屏幕、App、影像、性能和服务。接下来几年，竞争会逐步转向：谁能管理用户状态，谁能组织任务，谁能让 App 可靠暴露能力，谁能在端云之间划清隐私边界，谁能让用户信任一个会主动执行的系统。
站在 Android 手机从业者视角，Agent OS 不会在一夜之间推翻 Android 或 iOS。更可能的情况是，Android 和 iOS 都会长出 Agent OS 的一部分；OpenAI、字节、Google、Apple、Samsung、华为、小米、OPPO、vivo、荣耀，各自从自己的资源位置出发，争夺任务入口。
更需要警惕的问题是，行业会不会继续把 AI 手机理解成几个功能点。如果行业仍然只做 AI 摘要、AI 修图、AI 搜索、AI 语音助手，那么 OpenAI 只要做出一个可用的 Task Stream，就会把问题推进到系统层。
这种压力不会停在 OS 厂商内部。只要 Task Stream 要进入主屏，App 就要回答自己愿不愿意被调用，服务平台要回答交易和归因怎么分，系统要回答出错后谁负责。所以下一步要看的，是开发者、商业和责任会怎样重新分配。
开发者、商业与责任会重新分配
Agent OS 会改变开发者和平台的关系。
在 App 时代，开发者争的是安装、打开、停留、付费和复访。App icon 是入口，Push 是召回，应用商店是分发，广告和订阅是变现。
在 Agent OS 时代，开发者还要争一件新东西：被 Agent 选择。
用户说“帮我订一束花”，系统会选择哪个服务？看价格、距离、口碑、履约、历史偏好、平台合作、佣金，还是用户过去常用？这个选择权过去属于用户和搜索/应用商店，现在可能转移到 Agent 和系统。
这会带来新的开发者接口。
App 需要声明能力：我能订花、查库存、预约、取消、退款、开发票。
App 需要声明约束：哪些城市可用，哪些动作需要登录，哪些动作需要用户确认，哪些时间不能取消。
App 需要声明价格和分成：Agent 带来的订单如何归因，系统或 AI 平台是否抽成，优惠券能否使用。
App 需要提供责任接口：订单失败谁负责，退款如何处理，客服入口在哪里，审计日志如何对接。
这不是单纯技术 API。它会改变 App 的商业位置。
头部 App 会担心入口被拿走，所以它们会要求保留品牌展示、用户确认、交易归因和风控控制。中小 App 可能更愿意接入，因为 Agent 可以给它们带来新的流量。系统厂商会想把能力商店做起来，AI 厂商会想把任务入口掌握在自己手里。
开发者平台也会变化。未来的开发者文档不只教你怎么写 UI，还要教你怎么写能力 schema、怎么定义可调用动作、怎么返回 Artifact、怎么处理 Agent 带来的错误、怎么提供沙箱测试、怎么参与分成。
Android AppFunctions 是这个方向的开端。它让 App 把能力暴露给系统和 Agent。但要支撑完整 Agent OS，还需要更复杂的商业和责任层。
新的排名问题
Agent OS 会出现一个类似搜索排名的问题。
用户说“帮我找一家附近适合带孩子吃饭的餐厅”，Agent 选哪一家？是因为用户偏好、朋友推荐、平台排名、广告、佣金，还是模型判断？如果 Agent 的结果影响交易，它就会面对透明度和公平性问题。
搜索时代，用户还能看到多个链接。App 时代，用户能自己打开多个 App 比较。Agent 时代，如果系统直接给出一个建议，选择过程会变得更不透明。
这会引发新的产品要求：
- 对商业推荐做标识。
- 允许用户查看候选项。
- 允许用户指定偏好和禁用平台。
- 对高价值交易给出比较依据。
- 对企业和监管场景保留审计记录。
OpenAI、Google、Apple、Android OEM、字节、阿里、腾讯、美团，都会在这个问题上面临压力。Agent 帮用户省时间，但不能把选择权变成不可见的商业分配。
责任会从 App 扩散到系统
传统 App 出错，责任相对清晰。外卖错了找外卖平台，支付失败找支付平台，导航错了找地图。OS 更多负责提供能力和安全边界。
Agent OS 出错，责任会更复杂。
如果 Agent 误解用户需求，订错了酒店，责任在模型还是用户？
如果 Agent 正确理解需求，但调用了一个价格更高的服务，责任在系统推荐还是服务平台？
如果 Agent 在 GUI 自动化时点错按钮，责任在执行器、App UI 变化，还是系统没有二次确认？
如果云端 Agent 被网页 prompt injection 诱导，泄露了用户文件，责任在云端沙箱、模型、网页还是用户授权？
这些问题会倒逼系统设计。不是所有动作都能自动执行。不是所有数据都能进入模型。不是所有结果都能直接提交。Agent OS 必须把“风险动作需要确认”作为基础规则，而不是产品上线后补一个弹窗。
高风险动作会长期保留用户确认。支付、发消息、发布内容、删除数据、签合同、提交政务、金融交易、医疗建议，都不会很快全自动。Agent 可以准备、比较、填表、解释，但最后一步要把控制权还给用户。
把高风险动作的确认权留给用户，是 Agent OS 长期可持续的前提。
站在 Android 手机从业者视角，几个观察点
这里不需要写成行动方案。专业团队对侧键入口、权限 UI、端侧模型、云端任务、开发者接口这些方向都很清楚。更有价值的是把观察角度收敛一下：未来几年，Android 阵营的检验点会从“有没有 AI 助手”转向 AI 能不能进入系统对象模型。
第一个观察点是 Task。任务如果仍然只存在于聊天记录里，Agent 就很难进入系统层。只有当任务有状态、进度、Artifact、取消、恢复和历史，它才可能进入主屏、通知、锁屏、车机和手表。
第二个观察点是 Capability。GUI Agent 会继续存在，但它更像兼容路径。能撑起稳定体验的，是 AppFunctions、AgentCard、MCP tool、系统私有能力和头部 App 合作接口能否被统一索引、路由和审计。
第三个观察点是权限和记忆。Agent 手机越强，越需要把“这次任务用了什么数据、哪些上云、哪些留在端侧、哪些会被记住、哪些可以删除”讲清楚。它要落到系统界面和审计记录里，不能停在隐私口号上。
第四个观察点是端云状态。云端 Agent 如果只是无状态聊天 API，就承接不了长任务。端侧也不能只做入口，它要负责现场、确认、刹车和敏感数据边界。两边同步的应该是任务、Artifact、授权和审计，而不是一段越来越长的聊天上下文。
OpenAI 手机如果出现，对 Android 阵营的意义也许就在这里：它未必每个问题都答得好，但会让行业重新看见这些系统对象的重要性。对从业者来说，这一节更像抛砖引玉：不要只看发布会上多了几个 AI 功能，要看任务、能力、权限、记忆和端云状态有没有变成 OS 可管理的对象。
最后的判断
回到引言提出的五件事——状态理解、能力提供者、任务运行时、端云分工、跨边界执行——再把整篇文章压缩成六句话。
第一，手机不会被 Agent 取代，手机会成为 Agent 最关键的状态节点。
第二，App 不会消失，但 App 的前台入口会逐步降级，能力接口的权重会上升。
第三，Android 的短期路径会保留现有体系，在 Framework/SystemUI/权限/通知/端侧模型/云端协议上增加任务系统。
第四，OpenAI 不一定基于 Android；如果不用 Android，它会更自由，也会更难承接应用服务；如果用 Android，它会更快进入手机市场，也会被旧系统约束。
第五，Agent OS 的胜负不只看模型，而看任务运行时、能力路由、数据分级、用户确认、审计、端云协作和开发者关系。
第六，2028 年前后如果 OpenAI 手机出现，它最大的影响可能来自“任务流优先的手机”这个样本，销量反而不是唯一指标。
对 Android 手机从业者来说，这不是远处的概念。现在做的每一个系统 AI 入口、每一个权限弹窗、每一个 AppFunction、每一个端侧模型服务、每一个通知改造，都会决定未来能不能把 Agent OS 接住。
如果仍然把 AI 手机理解成相册、搜索、摘要和语音助手的集合，就会低估这次变化。
如果把它理解成“手机开始管理任务”，问题就清楚很多。
下一代手机的第一屏，未必会马上没有 App。
但它会越来越不像一个 App 陈列柜。
它会更像一个被系统约束、被用户授权、能持续工作的任务入口。
参考与资料来源
- 郭明錤关于 OpenAI、联发科、Qualcomm、立讯与 2028 年 AI Agent 手机的产业链消息：Frandroid、Techritual、Qore
- OpenAI 与 Jony Ive / io 的硬件合作背景：OpenAI - A letter from Sam & Jony、NPR
- Android AppFunctions 官方文档：Android Developers - AppFunctions
- A2A 协议官方资料与 Linux Foundation 新闻：A2A Protocol、Linux Foundation A2A project
- Samsung Galaxy AI 与系统入口方向：Samsung Newsroom、Samsung MWC 2026
- 豆包手机、Nubia M153 与第三方 App 限制事件：SCMP、TechNode、Business Standard