mola
我现在的工作方式已经变了，一个任务交代给 Codex 或者 Claude Code，说完就去干别的，过一会儿回来看结果。Agent 真正改变我的地方跟它会写代码关系不大，变化在于任务从我的注意力里消失了，我不需要一直盯着它，甚至不需要记得它还在跑。
然后就是手机，这一年手机上的 Agent 也逐渐铺开了，打开 App、点击、滑动、输入，点外卖、整理相册等，看起来手机也终于进入 Agent 时代了，但我实际用下来的体验还是割裂感很严重：我本来是让 AI 替我做事，最后却变成我拿着手机，看它替我点，手指悬在屏幕上方不敢往下碰，怕一碰就打断它，那几十秒里，手机既不属于我，也不完全属于它。
所以我想问各家手机厂商和手机 Agent 开发者一句：一个真正的手机 Agent 究竟应该是怎样的？今天我打算讨论讨论自 Agent 从电脑进入手机之后，它的运行环境、通用能力和对用户的理解究竟应该发生什么变化，顺便谈谈我的理解。
把手机还给我！
很多早期 GUI Agent 的逻辑其实就是一个 ReAct 循环：理解屏幕，点击，截图，再理解，再点击或者滑动。到了现在，豆包手机这类系统级 Agent 已经可以把应用放进独立的虚拟屏，在后台获取界面并执行任务，但底层逻辑仍然没变：Agent 每走一步，都需要重新观察这个原本设计给人类的界面反馈出来的答案，这个思路解决的是 AI 究竟会不会直接操作手机，并没能完全解决 AI 能不能稳定地替我工作的问题。电脑 Agent 好用，很大程度上来自另一套流程：交代任务，Agent 自己执行，人继续做别的事，需要确认时再回来看看。
手机其实比电脑更需要这一点，电脑前的人可以连续两小时不切换窗口，手机不行，手机随时被抢占，回微信、刷信息流、锁屏等等，一天几百次，一个必须独占前台的 Agent，天生与大多数用户对手机的操作理念和使用习惯八字不合。
不过似乎大家也注意到了这个缺点，最新的华为的小艺帮帮忙把 GUI 任务藏到了后台，官方文档写得很明白，为避免打扰用户使用手机，任务会默认在后台执行，执行时底部导航条会变成流光彩条，遇到需要人类审批或是决定的关键场景，点击胶囊里的跳转箭头进入决策页面，这已经是一个像样的可以实现后台执行的任务状态机了。
我的看法是，手机 Agent 的头号基础设施不该只是一个更聪明或者更底层的无障碍服务，它应该是一套真正的基于 Task 的 Runtime，任务在里面有自己的生命周期：运行中、等待用户审批、等待外部事件、暂停、恢复、完成、失败。手机上大量任务天生就要等，等对方回消息，等一个明天才会发生的日程，电脑上的长任务多半是在等计算和命令的输出，手机上的长任务基本都在等世界。
Agent 真正开始替人做事的标志，跟它能操作多少个 App 关系不大，而是用户能不能把任务交出去之后然后“忘掉它”。
屏幕即通用能力
电脑上为什么能冒出 Codex 等如此强大的 Agent？原因很简单，几十年下来，电脑上已经沉淀出一套极其适合机器操作的通用接口：Shell、文件系统、进程、命令行、代码。模型只要拿到一个代码执行环境，就能现场组合出大量开发者从来没有预定义过的能力。我在之前的文章里讲 Harness 的时候说过，同一个模型放进不同的 Harness 时，表现很多时候会出现很大差异，代码沙箱、MCP 等工具调用本身就是模型和现实之间的行动组织层，Shell 是这一层里性价比最高的接口，因为它把无穷多种能力压缩成了同一种能力。
手机就完全不是这么回事了，普通人在手机上干的事情是发微信、订票、点外卖、导航、找照片、查快递等等，这些事情就算给 Agent 一个完整的 Shell 环境也解决不了大部分。桌面 Agent 的通用能力来自 Shell 和代码，而手机 Agent 的通用能力则是来自屏幕和 GUI。
这让我联想到了 Computer Use，Codex 之类的 Agent 内置的这类功能可以给模型提供直接操作电脑的能力，但是我想说的是电脑的 Computer Use 对电脑 Agent 的意义和手机端的 Phone Use 对手机 Agent 的意义并不对等。手机端的操作能力在整个能力结构里的位置反而更接近电脑上的 Shell，虽然在技术分类上还是 GUI 自动化，但它承担的是通用执行面这个角色，而 Computer Use 在电脑上很多时候只是兜底或者一个锦上添花的功能。
在电脑上，Shell 是主接口，GUI 是兜底；在手机上，GUI 是最后的通用接口，代码执行只是特殊能力，并且 Android 从一开始就把应用隔离作为基本的安全模型，每个 App 都运行在自己的应用沙箱里，拥有独立的 UID、进程和私有数据目录。正常情况下，一个 App 无法直接读取另一个 App 的数据库和内部文件，这种隔离后来又通过 SELinux 等机制进一步强化。
也就是说，即使我们在 Android 上给 Agent 塞进一个功能完整的 Linux 环境，让它拥有 Shell、Python 甚至各种熟悉的命令行工具，它得到的首先也只是一个很强的计算环境，而不是整台手机。
也正因为这样，我并不认为手机 Agent 需要机械复制电脑 Agent 的代码沙箱，代码执行当然有用，但它在手机上的低位不会像在电脑上一样高，手机真正缺少的是一套属于移动操作系统自己的通用执行面。
一个很强，但又很“弱”的 Shell
GUI 的价值在于它覆盖很多边界条件，比如有一个从来没有接入过任何 Agent 生态的 App，只要人能点，理论上 Agent 也能点。开发者不需要提前替淘宝、小红书这些软件分别设计接口，也不需要等这些 App 主动配合，只要人能点，理论上 Agent 也能点，这是一种近乎天然的跨应用泛化能力，也是 GUI Agent 最大的、很难被完全替代的价值。但如果把它类比成手机上的 Shell，就会发现这真的是一个很“弱”的 Shell.
Shell 天然就适合给机器使用：命令有明确参数，执行后有输出、状态和返回码，结果也可以继续交给下一个命令处理；GUI 可不是，因为它是给人类使用的，模型看到的只是某一时刻的屏幕，一个点击有没有真正生效很多时候只能继续截图再判断，这就又回到了原始的 ReAct 执行逻辑上，这也是为什么 GUI Agent 的任务链一长可靠性就会迅速下降，页面上随便出点什么岔子都可能让后续操作一起跑偏。
例如 MobileWorld 这类做手机 Agent 的文章和基准说明了 GUI Agent 在受控场景里的成功率其实提升得很快，但一旦任务变长、跨应用、混入用户确认和工具调用，可靠性就会明显下降，问题很多时候并不在模型多模态能力上，而是 GUI 本身就不是为机器执行设计的接口。
绕过入口的代价
除了技术上的痛点，还有高手：生态和权限。9 月 14 日，豆包手机助手消费者版发布，同时推出了 SAEP，也就是屏幕自动化操作声明协议，第三方 App 可以声明哪些页面和操作允许 Agent 介入，比如允许生成草稿，但最终发布必须由用户完成。
生态和权限上最大的矛盾就是 GUI Agent 原本就是在绕过应用接口去直接复用原本给人使用的入口。对一个人来说，拥有一个账号，就意味着可以打开 App 并点击里面的按钮；但当一个 Agent 以“我”的身份每分钟点击几十次、跨应用汇总数据、自动发布内容时，风控系统会把它看成异常行为，因为这样一来现在各种 App 所谓的内容护城河就很容易被打破了。各种第三方平台也有话讲的，我们的账号、数据和责任最后算在谁头上？去年豆包手机助手技术预览版遇到多款 App 风控本质上就是这组矛盾的第一次集中体现。
与此同时，大量第三方 GUI Agent 赖以生存的无障碍接口本身也越来越尴尬。Android 17 开始有意限制非无障碍用途调用 Accessibility Service，因为各种钓鱼软件和手机 Agent 用的恰恰是同一套能力。对于操作系统来说，一个替用户点击按钮的 Agent 和一个替攻击者点击按钮的恶意程序，在底层行为上并没有什么不同的地方，话说难听点 GUI Agent 就是一种合法的“木马”。
能力可以很多，工具不该很多
虽然但是，就算有这么多限制 Phone Use 也永远不会消失，它仍然会是手机 Agent 面对超出边界的场景时最后的通用能力。不过，能通过结构化接口稳定完成的事情，没有必要每次都重新操作点击。于是，问题就变成了：如果高频的操作能力真的都应该变成结构化接口，那一台手机里最终可能会出现成百上千种能力，难道我们要把它们全部声明成 Tool 或者 MCP 服务器然后一股脑塞给模型吗？
vivo 三天前那场 AI 战略发布上宣布了蓝心 Harness，宣传是“把系统里六千多项原子技能变成智能体可以调用的工具”，这就让我有点担心他们的处理方式了，千万不要一股脑把工具全部声明出来口牙！
把电脑的实现和手机对比一下，电脑上那几个高度通用的工具，Shell、文件系统、浏览器、代码，四个就覆盖了极大的能力空间；但手机天生就碎片化严重：相册、通讯录、短信、日历等系统 App，还有各种第三方应用都是我们的数据来源，但这些 App 很多时候数据都完全不互通。
所以手机 Agent 的潜在工具数量一定会非常多，这是设备形态决定的，但我们绝对不能把很多碎片化的工具一次性塞给模型，几百个甚至上千定义灌进上下文，模型选错的概率和消耗的 token 全都会大幅上升。
首先，工具本身要保持合适的抽象层级。与其分别提供“发微信消息”“发 QQ 消息”“发 Telegram 消息”，不如把它们抽象成类似 send_message(channel, recipient, content) 的能力，由底层负责不同 App 的适配；但也不能把所有手机操作都压进一个巨大的 phone_action(action)，那只是把几百个工具藏进了参数列表里，复杂度并没有消失。
更重要的是，能力库可以很大，但模型当前看到的工具集应该很小。 手机可以拥有成百上千种能力，系统根据当前任务先检索，利用 Tool_Search 能力只把少数真正相关的工具暴露给模型。
Android 今年推出的 AppFunctions 允许 App 可以把自己的部分能力注册成结构化工具，Android 平台使用统一的工具注册管理，系统 Agent 根据任务查询这些能力再直接在后台调用，在这其中 App 像本地 MCP Server，系统负责发现和调度。
这样一来，GUI 的位置也就明确了，稳定、高频、适合后台执行的事情尽量走结构化工具；没有接口、没有适配的少数场景再退回 GUI，一个只有 GUI 的手机 Agent 很难真正快起来，一个只有结构化工具的手机 Agent 又永远覆盖不全。
答案其实已经在手机里了
假设这么一个场景，老板 A 今天给你发消息，让你周六出差，通讯录里存着 B，其中有标注是你的下属，你自己的备忘录里还有一条：B 周六请假。
收到这个任务之后，你对 Agent 说：“老板今天让我周六出差，拟个邮件通知一下相关人员。”
现在绝大多数 Agent 很可能会先问：需要通知哪些人？这个动作从逻辑上来讲完全没错，但问题是这个问题的答案其实早就散落在这台手机里了。Agent 应该知道 A 是谁，B 是你的下属，B 原本可能和这件事有关，同时又知道 B 周六请假，所以这次安排需要特殊处理。
它拥有所有信息，只是不知道这些信息都和这件事情相关，我认为这可能才是未来手机 Agent 最独特的能力：重建用户所处的那个世界，这或许可以叫它 Personal World Model，即个人世界模型。
这和现在常说的 Agent 记忆不是一回事，现行的记忆机制更多是在保存“用户喜欢什么”“用户以前说过什么”这种用户洞察或者偏好，个人世界模型则需要知道谁是谁、谁和谁是什么关系、什么时候发生了什么、哪些事情仍然有效、哪些已经过期，以及这些零散事实和当前任务到底有什么关系。
而手机恰好最有条件做这件事，短信、通讯录、日历、备忘录、照片、位置、文件和各种 App 实际上一直在记录一个人的工作、关系和生活，只是这些信息被切碎在几十个应用里彼此看起来互不关联罢了。
写到这里，我发现它又绕回了之前我文章里讲的认知界面，现实必须先经过感知入口和行动组织，才能变成大模型可以处理的材料，到了手机上就是一个人每天留下的数字足迹，这本身就是模型所面对的现实，它已经是时间、地点和人名和具体的事，只差有人把这些碎片重新拼起来，让我惊喜的是有不少人意识到了这个点，Apple 今年上线的 Siri AI 已经把 Personal Context 放到了核心位置，可以跨短信、邮件、照片等内容寻找和用户当前需求有关的信息。
但我觉得收集到很多个人信息，离真正理解一个人还有很远，就算 Agent 能知道“B 周六请假”那只说明系统找到了这条信息，真正有用的是它还能继续往下判断：这里的 B 和通讯录里的 B 是同一个人，B 是我的下属，这次出差和他有关，而周六请假意味着他这次不能按正常情况参与。并且这些信息并不是永久有效的，一条昨天还成立的事实，今天可能已经被新的消息覆盖，所以 Agent 不仅要记住发生过什么，还要知道这些信息现在还算不算数，以及它们和眼前这件事到底有没有关系。
做到这一步，它面对的就不再是一堆可以搜索的聊天记录、联系人和备忘录，而是一个会随着时间不断变化的个人世界，写到这里我突然发现这要实现了这 tm 就是 AGI 啊！手机可能是目前最接近这个目标的设备，因为它几乎持续记录着一个人怎么生活、和谁联系、接下来准备做什么。而这也会带来另一个老生常谈的问题：当一台设备真的开始这么理解一个人，它究竟应该知道多少个人信息？
把碎片拼成一个人
传统的隐私保护关心的是一个很清楚的问题：这个 App 能不能看我的通讯录？随着 Agent 的发展，往后大概率会出现一个更难回答的问题：把每条数据拼起来之后，系统究竟知道了什么？
Agent 可以利用通讯录知道 A 和 B 是谁，利用聊天记录知道他们说了什么，利用位置知道用户去过哪里... 分开看，每一条都平平无奇，合起来之后，就是一份相当完整的工作关系、社交关系、生活习惯和未来安排。而一个真正有价值的手机 Agent，偏偏必须拥有这种组合能力，没有这种能力，它最后还是只能问你一句：需要通知哪些人员？这和之前的 Siri 就没什么区别了。
我在之前的文章中里都数次写过一个类似的判断：让 Agent 有用的能力，很多时候和让它危险的能力来自同一个地方，这令人毛骨悚然。
提示词注入那一套这里就不重复了，个人世界模型更让我在意的是另外一些东西：它必须知道每个判断是从哪里来的，哪些信息允许彼此关联，哪些事实已经过期；用户也应该能够纠正甚至删除它对自己的理解。工作关系和医疗记录不应该默认出现在同一个检索面里，一条已经取消的行程更不能几年之后还继续影响 Agent 的判断。
我尤其在意的是可解释性，Agent 如果因为某条个人信息做出了会影响结果的判断，最好能直接告诉我它凭什么，比如一个理想的例子是：
...用户可见的思维链和工具调用过程...
正式回答：“我没有把 B 列入周六出差安排，因为你 9 月 16 日的备忘录里记录了他的请假。”
后面追加一个引用卡片，用户可点击直接跳转到备忘录，例如：“依据：9 月 16 日备忘录「B 周六请假」〔查看原文〕”
错误的点击通常很容易看见，错误的推断却可能悄无声息地进入后面的每一步行动里，如果 Agent 对某段关系或者某条旧信息形成了错误理解，用户甚至可能根本不知道后面的结果为什么会变成这样。
让 App 退到幕后
把前面几件事放在一起：异步任务、屏幕操作、个人世界模型，大概就是现在很多人说的 Agentic OS 成形的样子，那时候用户不再先想“我要打开哪个 App”，而是直接表达目标：“把周六出差安排一下。”
后面的事情由系统自己拆开，读老板的消息，理解当前处境，检查相关人员，核对请假和日历，查询交通，安排出行，起草通知，需要人确认的时候停下来等人确认，确认之后继续回到后台执行，这样一来，以往的 App 在这套关系里的位置就会发生某种变化。以前是用户打开 App，然后寻找功能。以后更多时候可能是用户先告诉 Agent 自己想完成什么，再由 Agent 去调用 AppFunctions、API、GUI 或者其他服务，App 逐渐从一个必须被用户亲自进入的界面，变成 Agent 可以调用的能力提供方。
在 Android 的 AppFunctions 能力加持下，开发者可以把 App 中的部分功能注册给系统，Agent 可以直接发现并调用，而不是每次都重新打开界面点击，有这套来自安卓原生的能力之后在技术上这件事就是一件很简单的事情了，真正麻烦的是生态：到底有多少 App 愿意把自己的能力变成可以被其他 Agent 调用的 Tool？因为这意味着 App 需要让出一部分自己一直掌握的所谓流量入口和各种数据护城河。
电脑更像一个工作空间，汽车、眼镜和手表分别提供环境、视觉和身体状态，而手机长期贴着一个人，同时连接通信、位置、照片、日程和大量现实服务，它天然适合成为把这些信息汇在一起的地方，成为一个中枢或者网关。
最后
回到开头那个出差的例子，现在的 Agent 会问：你要通知谁？我期待的那个 Agent 会这么说：
“我准备通知项目里的 C 和 D。B 原本也在相关人员里，不过你之前貌似批准了他周六请假，所以我没有把出差安排给他。邮件已经拟好，你看一下。”
也许所谓 AI 手机真正到来的那天，标志不会是手机终于学会替我点完所有按钮，那天的样子可能更加平淡：我说了一句很含糊的话，它知道我为什么这么说；我感冒之后手机上的 Agent 通过手表上报的信息自动问我需不需要就医和生病之后的生活提示。
人之所以是 Agent 的刹车，靠的是写到一半停下来的那三秒，可手机恰好是这个世界上最擅长消灭那三秒的设备，小屏幕、碎片化的使用，人在这种状态下审批 Agent 的操作跟坐在电脑前把 diff 从头看到尾然后批准完全是两种质量，更别说接下来它要处理的更敏感的内容，从代码库变成了我这些年的聊天记录、照片、日程和关系，代码写坏了可以 git 直接撤销改动，我的社会关系和人际交往上可没有 git 命令。
我大概还是会第一时间去装那些新的手机 Agent，毕竟这是我这几年最兴奋的技术方向之一，但我可能会多花点时间去看它的授权列表和隐私白皮书，而不是只看它能不能替我点完一杯咖啡（没有用任何优惠券）。
发表回复