企业官网建设流程全解析

最近这条“Android 官方官宣 AI 支持 App Functions，Android 官方 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，至少包含三个系统级组件：

1. 能力登记：App 在安装或者升级时把自己的功能描述上报给系统，不是简单的 BroadcastReceiver，而是结构化、带语义的声明；
2. 能力发现：系统侧维护一份“当前设备上可被 AI 调用的功能清单”，大模型 / Agent 可以直接查询；
3. 能力调度与权限：当 Agent 决定调用某个功能时，系统负责拉起目标 App、传递参数、校验权限、返回结构化结果。

也就是说，AI 调用你的 App 能力，不是“直接包一个 Deep Link 跳过去就完事”，而是像操作系统的进程间通信那样：有注册表、有路由、有鉴权。这恰恰是“系统级”三个字最值钱的地方。

1.3 和“AI+App”过去的做法到底差在哪

往浅了说，过去大家做的“AI 调用 App 功能”，本质上还是“意图映射”。比如语音助手识别到用户想打车，就拼一个 URL Scheme 跳转到滴滴；识别到想查快递，就打开小程序页面。这种老路子的问题很明显：URL Scheme 能带的参数极其有限，返回值基本拿不到，更别说什么权限模型、能力描述、动态路由。

App Functions 如果要一句话概括，就是把过去“跳转链接”升级成了“远程过程调用”。应用给出参数 Schema，Agent 按 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 系统侧：注册、索引、路由三步走

应用侧声明之后，系统要做的事情远不只是“存个文件”。我自己推演下来，系统侧至少要承担下面三个职责：

1. 注册：安装、升级、权限变更时，把这份能力描述同步到系统服务；
2. 索引：系统要把设备上所有已注册的能力收集起来，做成一份“当前设备能力目录”，并按语义去重、分类、排序，方便 Agent 查询；
3. 路由与鉴权：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，不管你换哪个大模型，你的能力层基本可以不动。

另外两个工程上的细节：

1. 幂等性：同一个请求因为网络超时被 Agent 重试，你的功能不能造成重复提交。比如创建订单、发送消息这类操作，必须设计一个请求 ID 或者结果缓存，保证“一次执行，重复确认不重复生效”。
2. 超时与取消：Agent 生成的自然语言可能变更意图，用户可能中途取消，你的能力要能响应取消事件，不能闷头执行到一半卡死，也不能执行完了才告诉用户“其实我没想这么干”。

5.3 测试与灰度建议

接入了新能力，怎么测试？我建议先把“能力调用闭环”跑通，再谈复杂场景。

第一层，用脚本直接调用你的能力接口，传一堆边界值，保证“参数校验、正常执行、异常返回”都符合预期。这一层跟你平时测普通接口没什么区别。

第二层，用标准 MCP 客户端连上你的能力服务，让真实模型自己“发现”并“调用”。这一层主要验证模型的语义理解：它能不能从用户的话里准确抽出title、start_time、end_time？抽错了你要在描述里怎么写才能纠正？

第三层，找几个真实用户做封闭内测，重点看授权交互和失败反馈。比如 Agent 调用失败时，用户是收到一句“抱歉做不到”就完了，还是能看到一个可以手动点击进去重试的按钮？我的经验是，后者对用户信任感的提升是决定性的。

整个灰度过程里，权限和隐私自查要前置。每开放一个能力，就同步更新隐私协议，把“哪个功能会被 AI 调用、调用会传什么数据、用户怎么撤回授权”写清楚，别等合规团队找上门再补。

6. 我的几点实际判断

最后说点不一样的。这波官宣消息出来后，各个群里都在转，但我观察到不少人的兴奋点还停留在“AI 好强啊，又能做新东西了”这一层，很少有人讨论“Android 做这件事到底图什么”。

我的判断是：Android 做 App Functions，核心目的不是给开发者发福利，而是要在“端侧 Agent 生态”里保住平台层的位子。大模型厂商正在疯狂抢占入口，如果 Android 只是冷眼旁观，等 Agent 生态成熟时，应用开放的规则就由别人定了。现在提前把能力注册、权限路由、协议标准握在手里，这才是真正的战略重点。

理解了这层，开发者应对的姿态就很清晰了：把自家 App 的核心能力当成可以被任何 Agent 调用的“公共服务”来设计。这不是给某个语音助手打工，而是提前在人机协同的生态里占一个可发现的位置。

我自己的项目已经开始做能力盘点，第一批只圈了三个场景，代码改动很小，核心工作全在功能声明和边界设计上。等生态真正跑起来，手里已经有一份“可被调用的能力地图”，远好过别人来问你“能不能支持一下”，你再临时加班。

顺着这个思路往下走，以后“App 是不是好用的判定标准”也会变。过去我们看留存、看转化，未来可能还要看“被 AI 正确调用的成功率”。这听起来有点远，但我感觉已经能闻到味道了。现在动手，成本最低。