本文来自微信公众号： AIGC从0到1 ，作者：王零壹
当AI开始替人看屏幕、读日程、调用支付、发消息、跨应用下单，它究竟是在手机里多装了一个助手，还是在手机之上长出了一套新的操作系统？
两者差别很大。
如果只是前者，竞争仍然是模型、语音、影像和几个看起来惊艳的功能。这是“AI手机”的延长线。
Agent手机讨论的是后一件事。用户不再自己打开App、逐页点击、在不同服务之间搬运信息。他交代一个目标，系统接住这件事，拆开它，找到需要的能力，必要时征求确认，完成后留下可回看的结果。
它是在重写移动操作系统的执行模型。
传统手机OS管理的是App、窗口、通知、文件和权限。它默认每个动作的执行者是人。Agent手机需要开始管理另一组对象：任务、能力、记忆、策略和责任。它默认会有一部分工作由Agent来推进。
所以，Agent手机最困难的地方是：怎样让一个概率性的模型，在身份、权限、支付、应用生态和责任边界都很确定的世界里，安全地执行事情。
把这个问题看明白，才能看懂为什么豆包、Google、Apple、手机厂商和模型公司都在往手机里塞Agent，也才能看懂这会给创业公司留下什么位置。
一、手机为什么会成为Agent的关键设备
今天大模型已经可以在云端做研究、写代码、处理表格。那为什么还要做Agent手机？
因为手机是个人数字生活里权限最密集的设备。
它有用户的身份认证、SIM卡、支付工具、通讯录、位置、相册、日程、通知、蓝牙设备、健康数据和几乎所有服务的登录态。它也一直跟在人身边，知道一个人正在去哪儿、即将见谁、是否在开会、刚刚看过什么、此刻能不能被打扰。
PC的生产力更强，车机拥有路况与驾驶场景，可穿戴设备更贴近身体。但只有手机同时拥有上下文、身份和执行入口。它既看得见用户的生活现场，也摸得到大部分服务的按钮。
这正是Agent最需要、也最危险的东西。
一个真正能完成任务的Agent，至少要拿到四种条件：理解目标的能力、与现实服务交互的能力、判断何时该行动的上下文，以及可以被用户认可的授权。手机恰好把四者放在了一起。
因此，所谓Agent手机并不必然意味着“手机会取代所有其他设备”。更可能的结果是，手机成为个人Agent网络里的授权节点。任务可以在手表上发起，在手机上完成身份校验，在PC上继续处理，在车机上收到结果。但涉及用户身份、支付、隐私和最终确认时，手机很可能仍是那个最重要的控制面。
这也解释了为什么新一轮竞争不只发生在硬件厂商之间。模型公司想借手机拿到真实上下文，OS平台想借Agent重夺任务入口，应用方则担心自己从一个完整产品，被压缩成后台的一项能力。
二、App中心的手机，和Task中心的手机
传统手机的使用方式，是一串由人来完成的界面跳转。
想订一次出差，人得打开日历确认时间，进入机票App搜航班，去酒店App看价格，再翻公司报销规则，最后回到聊天软件通知同事。每个App都把自己做成一座完整的岛，用户负责在岛与岛之间摆渡。
Agent手机要把这件事改写成一个任务。
用户只说：“下周去上海参见WAIC，周五上午十点前要到，按公司的差旅标准安排，预算控制在两千元以内。最后付款前叫我确认。”
在App中心的系统里，这句话只会触发一个聊天回答。在Task中心的系统里，它会生成一个有身份、有状态、有期限的任务对象。
这个任务并不等于一段Prompt。它至少要包含目标、约束、依赖、当前进度、需要的数据、允许调用的能力、风险等级、用户确认点和完整的执行记录。
第一步，是建立任务。
系统把自然语言转成一个任务卡片：目的地是上海，抵达时间是周五十点前，人数是一人，预算上限两千元，付款必须确认。它同时标明哪些地方仍然含糊，例如出发地、是否需要酒店、优先选直飞还是低价。该问的就问，不该默认猜的就不猜。
第二步，是拿到最小化的现场上下文。
它需要读一眼日历，确认客户会议的地点和时间；需要读取企业差旅政策，知道经济舱、酒店标准和报销范围；可能还要检查用户的常用出发机场和座位偏好。它不需要因此把所有聊天记录、相册和浏览历史都打包上传。
这里有一个很容易被忽略的原则：Agent的上下文必须与当前任务相称。系统能力的分水岭，在于它能否判断为了完成这一件事，最少需要哪些数据。
第三步，是规划任务图。
“订出差”通常不是线性操作。搜索航班、查询酒店、读取政策可以并行；选定航班之后，酒店位置和入住时间才会确定；支付要等到用户确认；出票成功之后，日历、报销和通知才能继续。
因此，系统内部需要的是一张任务图，而不是一串聊天记录。每个子任务都有前置条件、负责人、状态和失败处理方式。搜索失败可以换供应商，支付失败必须停下来，网络中断后可以恢复到上一个安全状态。
第四步，是能力路由。
系统会遇到一个关键选择：这一步应该调用谁？
查日历，优先调用系统或日历App已暴露的标准能力；查航班，可以调用旅行服务提供的API；读取公司规则，调用企业知识库；如果某个服务没有开放能力，才考虑在受限环境里使用GUI Agent去读屏和点击。
第五步，是确认和执行。
系统可能在十分钟内找到了两个符合条件的方案。它可以自动完成搜索、比较和预填信息，但到了支付节点，必须把价格、退改规则、付款对象和使用的数据摊开，让用户确认。确认不是一个笼统的“是否授权Agent”，而应该针对一次具体、可理解、可撤销的动作。
第六步，是回写和交付。
出票后，任务不能只显示“已完成”。它需要把订单号、发票入口、酒店地址、日历事件、报销材料和异常处理方式写入任务记录。下次航班变动，系统知道该从哪里续上；用户质疑某一次选择，它也能解释当时调用了什么能力、依据了哪条规则、谁在什么时刻确认了付款。
这才是一条完整的Agent手机任务链路。
从用户角度看，变化只是少点了几次App。从系统角度看，手机里多了一层任务调度器。它要管理的已经不再是图标，而是现实世界里的委托关系。
三、四个一等对象：Task、Capability、Memory、Policy
如果说传统OS的基础对象是App、进程和权限，那么Agent手机也会逐渐形成自己的四个基础对象。
第一个是Task，也就是任务。
任务需要有状态机。创建、规划、执行、等待确认、挂起、完成、失败、回滚，这些状态必须由系统明确管理。否则所谓“长期任务”只是一个容易丢失上下文的聊天窗口。
任务还需要跨设备存在。用户在手表上说“帮我把下午会议往后推半小时”，手机可能负责检查参会者日历，PC上的工作日程页面负责展示冲突，最终确认又回到手机通知。没有统一任务ID、现场快照和事件日志，这种连续体验不会成立。
第二个是Capability，也就是能力。
对Agent来说，应用不再只是一张UI，而应该暴露出可被调用的动作：创建日程、查询库存、发送消息、申请报销、生成合同、发起支付。每一项能力都要带上输入、输出、权限、价格、服务等级、风险等级和审计字段。
Google在Android上推出AppFunctions，Apple通过App Intents让应用动作可被系统发现，方向都很清楚：应用需要从“请用户打开我”变成“在用户授权下，让系统能调用我的某项能力”。
这会改变应用开发者的思维方式。过去，一个产品团队主要设计界面和用户路径；以后还要设计自己的能力接口，决定哪些业务规则可以交给Agent，哪些必须保留在自己的产品里，什么情况下必须回到人的界面确认。
第三个是Memory，也就是记忆。
Agent手机的记忆，不能只是“把聊天记录存得更久”。它至少包括当前任务的工作记忆、近期事件和偏好的情景记忆，以及可长期复用的程序性经验。
例如，系统记得用户通常从虹桥出发，这是一条偏好；记得上一次出差因为航班取消改签过一次，这是一个事件；记得公司报销要求优先选可开票的酒店，则是一条可执行规则。三者不能混在一起，更不能无差别塞进模型上下文。
一个可用的记忆系统更像账本。原始事件以可追溯的方式保存，系统在其上生成不同用途的视图，策略层决定什么应该写入、什么只能临时使用、什么必须删除。用户要能看到“系统为什么知道这件事”，也要能删除某段记忆，而不是只在设置页看到一句“我们会持续改善体验”。
第四个是Policy，也就是策略和治理。
Policy决定Agent在什么边界内行动。它需要综合用户授权、设备安全状态、企业制度、应用方规则、当地监管和任务风险。查询航班和展示比价可以自动完成；创建订单、发消息、修改日程可能需要一次轻确认；支付、共享联系人、开启新的系统权限，则需要强确认与身份验证。
这层不应该只是一个弹窗生成器。它应该参与任务规划。系统知道“这一步最终必须由用户确认”，就不该在此前调度一连串会造成不可逆影响的动作。真正成熟的Agent不是先跑到终点，再在门口问一句“要不要付款”；它会在规划阶段就把风险闸口设计进去。
Task、Capability、Memory、Policy缺一个都不行。
只有Task，没有能力，Agent只是会列待办；只有能力，没有任务，系统只是另一套快捷指令；只有记忆，没有策略，会变成一个对用户知道得太多的助手；只有策略，没有可恢复的任务和审计记录，出错后仍然说不清发生了什么。
这四层组合起来，才接近一个移动端Agent Control Plane。
四、GUI、API和混合架构：三条路的真正差别
今天市场上最显眼的演示，通常来自GUI Agent。
它像人一样看屏幕，理解按钮、输入框和页面层级，再模拟点击、滑动和输入。它最大的优点是兼容。应用不开API，服务不愿合作，甚至页面设计很陈旧，GUI Agent仍然可以尝试完成任务。
这也是为什么GUI路线看起来进展很快。它绕开了漫长的生态谈判，能直接在存量App上展示“跨应用操作”。
但GUI从来不是一条足够稳的主干道。
界面改版、弹窗、广告、登录态失效、验证码、人机校验、网络异常和深层业务规则，都会让一个看似简单的操作变形。更麻烦的是，它会模糊责任：Agent到底是按用户意图做事，还是在绕过应用原有的交互、风控和商业规则？
API和系统能力路线路径更慢，却更接近工程终局。
当应用把“查航班”“创建日程”“取消订单”做成带权限和数据结构的能力时，系统不必猜一个按钮在哪里，也不必用视觉模型去判断页面是否加载完毕。调用可以被限制、被验证、被记录，也可以在服务端获得确定的成功或失败结果。
Apple的App Intents与Android的AppFunctions，本质上都在做这件事：把过去只能由人点开的功能，变成系统可发现、可声明、可调用的能力。
但API路线也有自己的问题。它要求应用方主动开放，而且每一个能力都会牵涉到数据、支付、风控、品牌和分成。对平台而言，开放得太少，Agent体验做不起来；开放得太多，又可能把App降格成没有入口和议价能力的后台服务。
所以，现实可行的答案大概率是混合架构。
让模型负责理解意图、拆分任务、处理例外；让系统能力和API负责高价值、高风险、可验证的操作；GUI Agent只在没有标准能力可用时进入受限兜底，并且有更严格的权限、时间和审计限制。
一个好比喻是：模型适合当项目经理，不适合当没有规章制度的万能实习生。
它应该知道任务该往哪里走，也要知道哪些动作必须交给确定性的系统接口。越接近支付、身份、医疗、金融、企业数据，越不能把成功率寄托在“模型今天有没有看懂这个按钮”。
五、真实世界的难题，不在发布会演示里
Agent手机现在最容易被低估的，是可靠性工程。
演示里，一条指令往往从干净的桌面开始，网络正常、账号已经登录、页面没有更新、没有电话打进来、没有弹出权限框、没有库存变化，也没有别的家庭成员同时使用同一个服务。
真实手机不是这样。
同一个“帮我订票”任务，可能在航班筛选完成时被通知打断，在支付前遇到验证码，在确认后因为风控被取消，在出票后发现公司政策不允许该航司。用户不会把这些看成模型的小瑕疵。他只会记住，自己把一件本来能办成的事交给了系统，结果还得从头来过。
因此，Agent手机不能只用任务成功率来评测。
它还要看多余操作率。系统为了完成任务做了多少不必要的点击、读取和页面跳转。
还要看越界率。它是否读了任务不需要的数据，是否在没有确认时触发了高风险操作。
还要看恢复率。网络断开、App崩溃、页面变化后，它能否从安全节点继续，而不是重新开始或把状态弄乱。
还要看交接质量。当Agent停下来请求人类帮助时，用户能否在十秒内看明白它已经做了什么、现在卡在哪里、自己确认后会发生什么。
这会进一步带来一个不那么显眼的创业方向：训练、仿真与评测环境。
移动Agent不能只在干净的模拟App里训练。行业需要大量可重置、可验证、带有登录态变化、网络波动、权限弹窗和业务例外的真实世界模拟环境。它也需要任务回放工具，把一次失败还原成可分析的轨迹，而不是留下一段“模型调用异常”的日志。
谁能提供这些环境、评测和故障复盘工具，谁就可能成为Agent手机时代的基础设施公司。这类公司不直接抢用户入口，却决定哪些Agent敢进入高价值场景。
六、一次任务的钱，到底该怎么分
当任务开始替代App成为入口，商业问题会变得很具体。
过去的手机商业模式围绕安装、停留时长、广告展示、应用内购买和平台抽成运转。用户打开哪一个App，谁就有机会把他留在自己的页面里完成交易。
在Agent手机里，用户可能根本不打开任何一个App。他说“给我订一张符合差旅政策的机票”，任务调度器可能同时调用日历、企业政策、航旅平台、支付工具、电子发票和消息服务。
这笔交易到底算是谁带来的？
一种最粗暴的答案，是让默认Agent或OS平台成为新的总入口，所有任务都向它缴一笔“调度税”。这会把App Store的抽成逻辑搬到任务层，只是把“30%的应用内购买”换成“每一次能力调用都要过平台”。
这条路对平台很有诱惑力，对生态却很危险。应用方会担心自己交出能力后失去品牌、用户关系和定价权；创业公司会发现自己辛苦做出的垂直能力，最后只是被一个通用Agent当作可替换零件。
更合理的分账基础，应该是一张任务收据。
每一项可调用能力都要声明：它提供什么输入输出，收费方式是什么，是否带来交易，服务等级如何，发生错误时谁负责。任务调度器则记录这次任务实际调用了什么、贡献了什么结果、在哪个环节被用户确认、最后是否完成。
仍然用订差旅举例。一笔订单至少可能包含五类价值。
航司、酒店或旅行服务商提供商品，获得主要交易收入。
航旅App或API提供搜索、库存、改签和出票能力，可以按API、订单或成交效果获得服务收入。
企业差旅系统提供政策、预算和审批能力，它未必参与交易分成，却让任务能在公司规则内执行。
默认Agent或OS负责理解目标、编排步骤、管理授权和交付结果，它可以收取订阅费、任务服务费，或从经用户同意的效果分成中获得收益。
在高风险任务里，验真、风控、保险和争议处理也可能成为独立收费项。因为当Agent负责执行，用户买的不只是效率，也是在购买一次可被担保的委托。
这里有三条原则，应该比“谁能抽更多”更重要。
第一，分账不能反过来操纵推荐。
如果Agent因为某个服务给的平台佣金更高，就把它排在更合适、更便宜的选项前面，任务入口会很快失去用户信任。排序应优先服从用户的偏好、价格、质量、履约能力和已有会员关系。任何商业激励都要明确披露，不能藏进“AI为你推荐”的黑箱里。
第二，不能只按调用次数计价。
调用一次天气接口和完成一次跨应用改签，消耗的价值完全不同。对用户而言，最有意义的单位可能是一次被成功交付的任务；对能力提供者而言，可能是一次合规调用或一笔成交订单；对平台而言，则可能是订阅和任务保障。单一的token或调用次数，承载不了这套复杂关系。
第三，用户的上下文不能成为默认货币。
Agent手机很容易走向一种危险的商业化：平台免费替你办事，代价是持续收集你的跨应用数据，再把这份画像卖给广告和服务方。短期看，这能补贴模型成本；长期看，它会摧毁用户对“个人代理”的信任。用户可以授权数据用于完成任务，但这不等于平台自动拥有把个人生活变现的权利。
成熟的任务经济，应当让每一笔收入都能在任务收据里被看懂，而不是把抽成藏进路由规则里。
七、新创业公司会出现在哪些位置
Agent手机看起来像巨头的游戏。OS、芯片、模型、支付、应用商店，任何一个都不是小公司轻易能碰的领域。
但它重构的是一条很长的链路。链路一旦被拆开，创业机会反而会变多。
最直接的一类，是垂直能力提供者。
未来很少有创业公司需要自己造一台Agent手机。更现实的机会，是把某个行业里真正复杂、真正需要判断的步骤封装为可调用能力。比如采购合同的条款风险识别与修改建议，或一个品牌在特定平台上的活动预算校验、素材合规和投放复盘。
这类公司的护城河不在提示词，而在数据、规则、客户系统接入、效果评测和对例外情况的处理。它们要把自己做成任务图里一个不可轻易替换的节点。
第二类，是任务产品。
很多行业真正的价值不在一个原子动作，而在一整段流程的编排。例如企业销售的“线索进入到合同签署”，医疗服务的“预约到随访”，出海团队的“选品到投放”，都包含多个系统、多个角色和多次确认。
创业公司可以拥有一类任务的任务模板、策略、验收口径和异常处理能力。它们最终出售的是一条可以稳定交付的业务结果。
第三类，是权限、身份和审计基础设施。
当Agent代人执行，企业需要回答的问题会变成“它凭什么这么做”。谁授权的？用了什么数据？能不能撤销？用户离职后权限怎么办？一次任务跨过多个SaaS后，日志该留在哪里？
这会催生面向Agent的权限代理、任务级身份令牌、审计账本、数据最小化工具和策略引擎。它们未必显眼，却可能比一个通用助手更容易进入企业预算。
第四类，是可靠性与评测工具。
Agent手机需要大量真实任务的回放、沙箱、模拟环境、异常注入和能力评测。一个垂直能力不应只宣称“能完成”，还要能给出成功率、成本、平均人工介入次数、越权情况和失败恢复表现。谁能把这些指标做成企业采购时看得懂的证据，就有机会成为新一代Agent的质量基础设施。
第五类，是面向Agent的新用户界面。
当用户不再逐页操作App，界面不会消失，只是从“操作面板”变成“任务确认、过程解释和结果交付”。如何让用户在几秒内判断一个任务是否值得确认，如何展示Agent的证据、选项和风险，如何在任务失败时快速接管，这会成为新的交互设计题目。
对创业者来说，更关键的判断是：在一条真实任务里，我是否掌握独有的数据源、业务规则、执行接口、验收标准或结果责任中的至少一项。
没有这些，产品很容易沦为另一个可以被通用模型复刻的聊天壳。
八、模型公司、OEM、平台和应用，分别在抢什么
模型公司最想要的是上下文与高频调用。
模型能力再强，如果只待在一个独立App里，就很难知道用户正在做什么，也很难替他完成最后一步。进入手机系统，意味着模型有机会接触真实任务、持续反馈和长期记忆。阶跃星辰、豆包这类模型公司看中手机，并不只是硬件出货量，更是希望从“被打开的AI App”变成“参与调度的系统Agent”。
OEM最想要的是不被重新硬件化。
如果未来用户的第一交互入口变成某个云端Agent，而手机厂商只负责供电、屏幕和摄像头，手机会更快沦为同质化载体。OEM必须争夺默认Agent、设备侧上下文、系统权限和多设备协同，否则再强的硬件参数也很难换来新的议价能力。
OS平台最想要的是规则制定权。
它决定什么能力可以被发现，谁拥有执行权限，用户如何确认，任务日志如何保存。Google通过AppFunctions把应用能力纳入系统级的发现与执行框架，Apple通过App Intents把应用动作接到Apple Intelligence、Siri和快捷指令里，都是在提前占住这张规则表。
应用方最想保住的是三件事：品牌、数据和交易。
一旦用户只对Agent说“帮我买”，应用方担心自己变成没有名字的履约方。因此应用不会无条件拥抱Agent调度。它们会要求能力调用保留品牌露出、用户会员权益、价格和售后关系，也会优先支持能归因、能审计、能遵守业务规则的受控接口，而不是任由GUI Agent在页面上模拟人工操作。
这也是为什么Agent手机的终局不会是“系统把所有App吃掉”。更可能是App的形态发生变化：一部分能力被开放给系统调度，另一部分高价值交互仍然保留在自己的界面和服务关系里。边界怎么划，取决于每个行业的风险、监管、交易和用户信任。
九、安全之后，还有责任与保险
传统隐私问题关注的是：谁拿到了我的数据。Agent手机还要面对另一个问题：谁用我的身份做了什么。
它会遇到提示注入。恶意网页、消息或页面文字，可能诱导Agent忽略原本任务，转而发送信息、泄露数据或点击不该点的链接，如同openclaw遇到提示词毒丸的例子。
它会遇到权限聚合。一个Agent同时拥有读屏、消息、支付和系统API的能力，相当于把过去分散在多个App的权限集中到了一个执行者手里。
它还会遇到代理责任。Agent误下单、误发合同、错过退票期限、误把企业数据传给第三方，损失该由谁承担？用户、模型公司、手机厂商、OS平台、能力提供者，还是服务商？
技术上可以用最小权限、任务级授权、分级确认、沙箱执行和全链路日志降低风险。商业上，责任仍然需要被重新划分。
未来高风险任务很可能需要新的保障机制。它可以是平台的赔付承诺，可以是企业内部的审批责任，也可能出现围绕“任务执行失败”的保险与争议处理服务。没有责任边界，企业不会把关键流程交给Agent；没有可回放的证据，平台也很难证明自己已经尽到合理注意。
因此，一台成熟的Agent手机应当让用户看到的不只是“它能做什么”，还要看到“它此刻拥有什么权力、正在使用什么数据、下一步准备做什么、出问题后如何撤销和追责”。
边界清晰本身就是产品能力。
十、Agent手机的终局，不是一台孤立的手机
最后还要避免一个误解：Agent手机并不一定会成为一个独立、封闭的新物种。
真正的变化，可能是所有设备开始共享同一条任务链。手机负责身份、感知和最终确认，PC负责复杂编辑和长时工作，手表负责快速发起和提醒，车机负责场景交互，家庭设备承担局部执行。用户看到的是一个持续推进的任务，而不是一堆设备之间来回同步的碎片。
在这个网络里，手机的特殊性仍然存在。它不是唯一的屏幕，却很可能是最重要的个人代理授权器。
所以，Agent手机的成败不取决于它能否在发布会上替人点一杯咖啡。
它取决于它能否把一次真实委托变成一个可信的系统过程：理解目标时不乱猜，读取上下文时不过界，调用能力时有规则，执行交易时能确认，出现意外时可恢复，完成之后说得清楚钱去了哪里、数据用了什么、责任由谁承担。
如果这些问题没有答案，Agent手机只是一个更高权限的演示工具。
如果它们被解决，手机的中心地位会被重新定义。人们不再只是用它打开应用，而会用它把一部分生活和工作，交给一套可以被授权、被约束、也被追责的代理系统。