最近这条“Android 官方官宣 AI 支持 App FunctionsAndroid 官方 MCP 和系统级 OpenClaw 雏形”的消息我刷到的时候第一反应不是“又一个新 API”而是赶紧去翻了一遍自己的老项目看哪些地方能直接接住这波能力。简单说App Functions 是 Android 官方给应用开的一条“面向 AI Agent 的能力通道”Android 官方 MCP 是让大模型和 Android 设备按统一协议对话的中间层而所谓“系统级 OpenClaw 雏形”在我看来更像是 Android 把“AI 助手只能聊天”往“AI 助手能直接操作 App”推进的完整布局。这篇文章我不想做新闻复读而是想把“这到底是什么”、“对开发者意味着什么”、“现在能做什么”这三件事讲透。适合正在做 Android App、做 AI 应用/Agent或者正在考虑怎么让自家 App 被大模型调用的团队当一份决策参考。1. 这条“官宣”的分量不是又发了个 AI 功能而是 Android 自己站到了 Agent 这边1.1 App Functions 三个字覆盖了用户、开发者、平台三方过去几年Android 上做 AI 基本都是两条路要么在 App 里塞一个模型要么在云端接一个大模型接口。这两种方式里AI 和 App 的关系都是“从属关系”——AI 是 App 里的一个功能模块模型再聪明也只能在你给它画好的对话框里转圈。App Functions 把这件事翻转了AI Agent 变成了“请求方”App 里面一个个具体能力变成了“可被请求的服务”。用户对大模型说“帮我创建一个半小时后的会议”大模型不再只是给一段文字回复而是真的会去调用你 App 里那个“创建日程”的功能完成后的结果再回到对话里。这里有三方利益被重新定义用户得到的是“能做事”的助手而不是“只会说话”的聊天框开发者手里的业务能力多了一个全新的分发入口而且是系统级的入口Android 平台本身则拿到了“能力注册、能力发现、能力鉴权、能力调用”的完整编排权。理解这一层你就能明白为什么这次消息会让很多做端侧 AI 的人兴奋因为入口从“开发者自己接入某个模型 SDK”上升到了“厂商在系统层面帮你把能力路由给所有 Agent”。1.2 为什么说这次是“系统级”而不是“库级”做 Android 的老人应该都有印象以前谷歌塞 AI 能力进来最常见的形式是给你一个 SDK、一个库你在 build.gradle 里引一下然后在代码里调用。这次不一样的地方在于整个链路里有“系统服务”的概念。我理解中的 App Functions至少包含三个系统级组件能力登记App 在安装或者升级时把自己的功能描述上报给系统不是简单的 BroadcastReceiver而是结构化、带语义的声明能力发现系统侧维护一份“当前设备上可被 AI 调用的功能清单”大模型 / Agent 可以直接查询能力调度与权限当 Agent 决定调用某个功能时系统负责拉起目标 App、传递参数、校验权限、返回结构化结果。也就是说AI 调用你的 App 能力不是“直接包一个 Deep Link 跳过去就完事”而是像操作系统的进程间通信那样有注册表、有路由、有鉴权。这恰恰是“系统级”三个字最值钱的地方。1.3 和“AIApp”过去的做法到底差在哪往浅了说过去大家做的“AI 调用 App 功能”本质上还是“意图映射”。比如语音助手识别到用户想打车就拼一个 URL Scheme 跳转到滴滴识别到想查快递就打开小程序页面。这种老路子的问题很明显URL Scheme 能带的参数极其有限返回值基本拿不到更别说什么权限模型、能力描述、动态路由。App Functions 如果要一句话概括就是把过去“跳转链接”升级成了“远程过程调用”。应用给出参数 SchemaAgent 按 Schema 传参App 执行完以后把结果按结构化格式返回。整个交互对模型友好对开发者可控对系统透明。做一个表格对比会更直观维度传统 Intent / URL SchemeApp Functions 的思路调用方语音助手“猜”意图后拼链接AI Agent 按语义读取能力描述参数传递靠 URL 参数弱类型、易失效结构化 Schema强约束返回值基本拿不到支持结构化结果回传权限管控App 自己处理容易被绕过系统参与鉴权和路由可发现性靠预置名单或搜索索引系统统一维护能力清单光这四条就足以改变 AI 应用的产品形态。以前智能助手做不到“跨 App 连续做事”卡就卡在每次跳转都是一次有去无回的深链现在有了系统级能力注册和结果回传多步任务才真正有了闭环的土壤。2. App Functions 落地以后应用功能是如何被 AI“看见”的2.1 应用侧一个“声明”背后到底在描述什么按我目前的理解App 如果想开放能力给 AI第一步不是写死一个接口而是先写一份“功能声明”。这份声明里大概要包含这么几件事这个功能叫什么它是做什么的适合在什么场景下被调用它需要哪些参数每个参数是什么类型、可选的还是必填的调用成功或者失败以后返回什么结构。拿一个会议 App 举例如果我打算把“创建日程”这个能力开放出去声明的“灵魂”大概长这样{ function_id: com.example.meeting.create_schedule, name: 创建会议日程, description: 根据参会人、会议主题和开始时间在日历中创建一条会议日程并返回会议链接, parameters: { title: { type: string, required: true, description: 会议主题例如季度产品评审 }, start_time: { type: string, required: true, description: ISO 8601 格式的开始时间 }, end_time: { type: string, required: false, description: ISO 8601 格式的结束时间 } }, output: { meeting_url: { type: string }, calendar_event_id: { type: string } } }注意看这个声明里没有任何“绑定某个大模型”的痕迹。它不关心调用方是 Gemini、GPT、Claude还是某个本地跑的模型只要对方能读懂这份 JSON能按参数约束传值就完成了最基本的对接条件。这也是我特别喜欢这套设计的一点它把“人和 App 的交互界面”和“模型与本机能力的交互界面”分开了。前者仍然是你精心设计的 UI后者则是这份机器可读的能力描述。2.2 系统侧注册、索引、路由三步走应用侧声明之后系统要做的事情远不只是“存个文件”。我自己推演下来系统侧至少要承担下面三个职责注册安装、升级、权限变更时把这份能力描述同步到系统服务索引系统要把设备上所有已注册的能力收集起来做成一份“当前设备能力目录”并按语义去重、分类、排序方便 Agent 查询路由与鉴权Agent 发来调用请求时系统要判断这个请求是不是有足够权限然后决定是直接拉起应用执行还是先弹窗让用户确认最后把结果回传。这里面最值得开发者关注的是“权限”两个字。以前 App 暴露一个 BroadcastReceiver任何应用都能往里面丢广播安全性全靠开发者自己把关。现在如果系统接管了登记和路由那“谁可以调用我的能力”、“需不需要用户二次确认”、“能传哪些数据”这些规则就有了统一的落点。从实操角度讲我建议所有打算接入的团队一定要在能力声明的设计阶段就把“敏感能力”和“非敏感能力”分开。比如“获取当前天气”这种低风险能力可以走静默调用“读取用户通讯录并发送消息”这种高风险能力必须设计成需要用户确认最好还要有清晰的可视化提示。2.3 它会不会取代 Intent我认为短期不会很多开发者看到这类消息第一反应是是不是以后 Intent、Deep Link 都要被淘汰了我个人的判断是短期不会。Intent 是 Android 最底层的组件间通信机制覆盖面极广而且 App Functions 的执行最终大概率还是要依赖 Activity、Service、ContentProvider 这些基础组件去落地。App Functions 更像是在 Intent 之上加了一层“面向 AI 语义理解”的适配层它解决的是“模型怎么知道该调哪个能力、参数怎么填、结果怎么看”的问题。而且别忘了Intent 的“隐式匹配”本身就是一种能力发现机制只是它的格式不适合直接喂给大模型。你把 App Functions 理解成“Intent 的 AI 友好化封装”可能更准确。所以我的建议是不要动现有架构不要推翻 Deep Link先把新能力按新规范接入再观察系统侧和生态侧的支持力度。过早重构的风险远大于收益。3. Android 官方 MCP把“工具箱”变成标准接口3.1 MCP 解决的是 Agent 时代的“接口爆炸”问题聊完 App Functions必须得聊 MCP因为它俩是配套出现的。MCP 的全称是 Model Context Protocol我不打算把它讲得太玄一句话它定义了一个大模型和外部工具之间的标准通信方式。在这个协议之前每个大模型厂商都有自己的工具调用格式你给 A 模型写一个工具插件换到 B 模型就得重写一遍应用侧也一样被 10 个 Agent 集成就要适配 10 种私有协议。MCP 的玩法是把“工具”描述成统一格式通过tools/list和tools/call这两类标准方法完成“发现工具”和“调用工具”。模型侧和应用侧只要各自实现 MCP 客户端/服务端就能互相理解。打个比方这像把各种奇形怪状的充电口统一成了 USB-C。Android 官方这次往 MCP 靠拢信号非常明确他们不打算只服务自家模型而是要做整个生态的连接器。3.2 官方实现里我注意到的几个细节从目前能看到的信息推断Android 官方提供的 MCP 支持主要有两个层面。第一个层面是“设备能力通过 MCP 暴露给 AI”。比如屏幕状态、当前前台应用、截图、控件信息、点击/输入事件、日志等这些过去靠 UIAutomator 或者 ADB 才能拿到的能力未来可以打包成标准的 MCP 工具让 Agent 像调用普通函数一样去操作设备。这对自动化测试、自动化运维、端侧 Agent 调试都很有价值。第二个层面是“App 内部能力通过 MCP 与 Agent 互通”。这就是 App Functions 和 MCP 结合的地方App 的能力声明可以映射为 MCP 的 tool 描述参数 Schema 复用 MCP 格式调用链路也走同一套 JSON-RPC 风格。理论上同一个 Agent 既可以调用本机另一个 App 的能力也可以调用一个远程服务的 API开发者侧需要维护的逻辑是统一的。我看到这个“设备工具化 应用工具化”组合的时候第一反应是做端侧自动化测试的人要高兴坏了。以前脚本里全是findElementById、waitForWindow这种脆弱的写法现在模型可以直接理解“当前屏幕上有一个确认按钮点击它”然后通过标准工具完成操作。测试用例的写法会从“代码”变成“自然语言动作描述”。3.3 开发者现在应该做的别只当观众MCP 对普通 App 开发者的直接影响可能没有 App Functions 那么快但有两件事现在就可以开始做。第一件熟悉 MCP 协议本身。去跑一个本地 MCP Client把自家 App 的某个数据接口包成一个 MCP Server哪怕只是内部工具。这个过程会让你理解参数描述、错误处理、上下文管理这些细节。别等官方 SDK 完全稳定了再学那时候已经晚了。第二件盘点自己的“可脚本化能力”。说白了就是哪些功能闭着眼睛也能被人说一句话就触发比如“切换深色模式”、“清空缓存”、“导出上周账单”、“把当前页面分享到某个群”。这些以后大概率都能被 Agent 接管现在先列清单标记优先级和风险等级。有一个坑我强烈建议避开不要把 ADB 级别的操作直接暴露成工具给 Agent。比如搞一个“执行 shell 命令”的 MCP 工具模型一旦误用后果难以控制。工具要拆细一个工具只做一件明确的事“命令执行”这种万能钥匙式的工具只能留在调试环境绝不能进正式系统。4. “系统级 OpenClaw 雏形”意味着什么Android 想做的不是语音助手是“能动手的 Agent”4.1 OpenClaw 这类项目给业界放了什么信号标题里提到的“系统级 OpenClaw 雏形”我理解不是指某一个开源项目被内置而是指类似 OpenClaw 这类“本地操控系统”的开源 Agent 能力正在被 Android 官方用更规范的方式重新实现。这类开源项目此前的做法一般是通过无障碍服务读取屏幕内容通过模拟点击完成操作再通过一套记忆/计划机制让模型“看到—理解—操作—验证”。它确实能做很多事比如自动填写表单、自动点赞、自动整理文件但问题也很明显无障碍服务权限极大几乎等于用户把手机的操作权交给了 App隐私风险高屏幕坐标点击方案脆弱分辨率一变、UI 一改就失效跨 App 操作没有统一的状态管理多步任务容易“走到一半迷路”因为没有官方能力登记Agent 只能靠“读屏猜”效率低下还不稳定。OpenClaw 们的存在证明了“用户确实需要一个能代替双手的助手”但技术路径上靠无障碍模拟点击走不长远。这时候 Android 官方推 App Functions MCP本质就是用系统能力替代第三方黑科技。4.2 从“技能”到“系统”的三步棋我按自己的理解把 Android 这套布局拆成三步棋第一步能力登记。App 把自己的功能以结构化方式告诉系统这一步解决的是“AI 知道有什么可以用”。没有这步Agent 只能靠猜。第二步协议统一。用 MCP 这种标准接口承载能力发现和调用这一步解决的是“AI 怎么用”。不绑定单一模型未来谁都能接入。第三步权限与身份。系统在 Agent 和应用之间保留鉴权节点这一步解决的是“允不允许用”。用户一次授权后续所有 Agent 调用都在可控边界内。三步棋走完一个系统级 Agent 的雏形就出来了它既不是传统语音助手那种“只会调起几个预装应用”的封闭系统也不是 OpenClaw 那种“绕过系统权限硬控制”的野路子而是一个“每个能力都登记在案、每次调用都有据可查”的开放平台。坦率地说这个雏形目前肯定还不完善。App Functions 的覆盖面、第三方应用的接入意愿、用户授权交互的体验都还在早期。但我判断方向已经定了未来的 Android 助手一定具备“跨应用执行任务”的能力而这个能力不会靠软件层叠而是靠系统底层。4.3 边界问题授权边界、数据边界、成本边界系统级 Agent 听着很美好但有几条边界绕不过去我在这波热度里看到不少团队过于乐观所以专门列一下。授权边界Agent 要调用你的支付功能时是逐次确认还是免密系统现在有没有提供一个标准的“用户确认界面”如果每个 App 都自己弹一次 Dialog体验会很割裂。这件事不做标准化Agent 在真实场景里根本跑不起来。数据边界Agent 把要处理的用户数据放在哪里如果云端模型要读取本地日程、通讯录、短信验证码数据链路是否加密端侧处理和云端处理怎么分流这直接决定用户敢不敢真正授权。成本边界多步任务意味着多轮模型调用token 消耗会指数级上升。系统级 Agent 如果每次执行任务都让每个模型重新读一遍“当前设备所有能力目录”延迟和成本都受不了。所以未来一定会有“能力索引缓存”、“筛选优先级”这类机制开发者做能力声明时越精炼越容易被选中也越省成本。我的建议是做能力声明时不要堆砌。把二十个低频能力都开放出去远不如把三个高频场景做扎实。Agent 会倾向调用描述清晰、参数简洁、失败率低的功能这跟应用商店的推荐逻辑本质相同。5. 现在可以动手做的“最小接入”方案5.1 先圈定两三个高价值功能接新东西最忌讳“全面拥抱”我建议团队里开会先盘点一轮从三个维度筛功能用户多这个功能每天都有人用任务感强它本身就是一个完整任务而不是一个中间步骤参数简单输入可以用三五个字段讲清楚。我随便列几个例子闹钟类 App 的“设置一个 xx 分钟后提醒”、记账类 App 的“记一笔 xx 元 xx 分类的支出”、工具类 App 的“把当前页面内容导出成 PDF”。这种功能用户天天用参数又简单非常适合第一批接入。选好功能之后把它拆成“能力输入—执行—输出”三段每一段都写成结构化描述。这个过程会比写代码更痛苦因为你会发现很多功能其实根本没有明确的“完成状态”。5.2 抽象能力接口而不是写死给某个大模型我特别强调一点无论你想用哪家模型能力层一定要抽象成“面向所有 Agent”的样子不要跟某个模型绑定。最稳妥的做法是把每个能力设计成独立的“函数”输入输出全部用 JSON Schema 描述内部逻辑与模型协议无关。这样未来不管 Android 官方怎么更新 SDK不管你换哪个大模型你的能力层基本可以不动。另外两个工程上的细节幂等性同一个请求因为网络超时被 Agent 重试你的功能不能造成重复提交。比如创建订单、发送消息这类操作必须设计一个请求 ID 或者结果缓存保证“一次执行重复确认不重复生效”。超时与取消Agent 生成的自然语言可能变更意图用户可能中途取消你的能力要能响应取消事件不能闷头执行到一半卡死也不能执行完了才告诉用户“其实我没想这么干”。5.3 测试与灰度建议接入了新能力怎么测试我建议先把“能力调用闭环”跑通再谈复杂场景。第一层用脚本直接调用你的能力接口传一堆边界值保证“参数校验、正常执行、异常返回”都符合预期。这一层跟你平时测普通接口没什么区别。第二层用标准 MCP 客户端连上你的能力服务让真实模型自己“发现”并“调用”。这一层主要验证模型的语义理解它能不能从用户的话里准确抽出title、start_time、end_time抽错了你要在描述里怎么写才能纠正第三层找几个真实用户做封闭内测重点看授权交互和失败反馈。比如 Agent 调用失败时用户是收到一句“抱歉做不到”就完了还是能看到一个可以手动点击进去重试的按钮我的经验是后者对用户信任感的提升是决定性的。整个灰度过程里权限和隐私自查要前置。每开放一个能力就同步更新隐私协议把“哪个功能会被 AI 调用、调用会传什么数据、用户怎么撤回授权”写清楚别等合规团队找上门再补。6. 我的几点实际判断最后说点不一样的。这波官宣消息出来后各个群里都在转但我观察到不少人的兴奋点还停留在“AI 好强啊又能做新东西了”这一层很少有人讨论“Android 做这件事到底图什么”。我的判断是Android 做 App Functions核心目的不是给开发者发福利而是要在“端侧 Agent 生态”里保住平台层的位子。大模型厂商正在疯狂抢占入口如果 Android 只是冷眼旁观等 Agent 生态成熟时应用开放的规则就由别人定了。现在提前把能力注册、权限路由、协议标准握在手里这才是真正的战略重点。理解了这层开发者应对的姿态就很清晰了把自家 App 的核心能力当成可以被任何 Agent 调用的“公共服务”来设计。这不是给某个语音助手打工而是提前在人机协同的生态里占一个可发现的位置。我自己的项目已经开始做能力盘点第一批只圈了三个场景代码改动很小核心工作全在功能声明和边界设计上。等生态真正跑起来手里已经有一份“可被调用的能力地图”远好过别人来问你“能不能支持一下”你再临时加班。顺着这个思路往下走以后“App 是不是好用的判定标准”也会变。过去我们看留存、看转化未来可能还要看“被 AI 正确调用的成功率”。这听起来有点远但我感觉已经能闻到味道了。现在动手成本最低。