App Intents 与 App Actions 对比

👆 点击上方「迷斯特的小宇宙」，加「星标」不错过精彩内容

移动端 AI 的下一步，会把 App 的动作、数据和权限边界暴露给系统。App Intents 和 App Actions 讨论的都是这件事，只是 iOS 和 Android 站在不同的系统层上。

上一篇写苹果在 iPhone 上的 AI 布局时，最后留了一个问题：你的 App 准备好被系统理解了吗？

这个问题落到工程上，主线是 App Intents。

如果把视角放到 Android，同一类问题会落到 App Actions、Built-in Intents、App Shortcuts、deep link 和 Google Assistant 这套机制上。两边名字不一样，技术栈不一样，但背后都在处理同一个变化：App 不再只通过图标和页面被打开，系统开始直接调用 App 里的某个能力。

这篇文章拆两件事：

• iOS App Intents 到底在架构上解决什么问题；

• 它和 Android App Actions 的差异，会怎样影响客户端工程分层。

图 1：移动系统调用 App 能力的两条路径

App Intents 的位置

App Intents 是苹果把 App 功能接入系统体验的一套声明式框架。

苹果官方对 App Intents 的定义很明确：让 App 的 actions 和 content 能被 Spotlight、Widgets、Shortcuts、Siri、Controls 等系统体验发现和使用。它从 iOS 16 开始进入系统框架，后续逐步扩到 macOS、watchOS、visionOS。

这句话里有两个关键词：actions 和 content。

以前客户端做系统集成，常见做法是 deep link。系统或外部 App 给你一个 URL，你打开某个页面，后续逻辑回到 App 自己处理。这个模型足够简单，但系统并不知道页面背后的能力是什么，也不知道用户要操作的对象是什么。

App Intents 把这层拆开：

• AppIntent 描述一个可执行动作；

• @Parameter 描述动作需要的输入；

• AppEntity 描述系统可识别的业务对象；

• EntityQuery 让系统能搜索、解析、补全这些对象；

• AppShortcutsProvider 把常用动作暴露给 Shortcuts 和 Siri。

这不是页面路由，而是一层语义接口。

一个极简 App Intent 长这样：

import AppIntents

struct StartFocusSessionIntent: AppIntent {
    static var title: LocalizedStringResource = "Start Focus Session"

    @Parameter(title: "Duration")
    var duration: Int

    func perform() async throws -> some IntentResult {
        try await FocusService.shared.start(minutes: duration)
        return .result()
    }
}

这段代码的重点在 perform()：这里不应该重新写一套业务逻辑，而是调用已经稳定存在的业务 service。否则 App Intents 会变成另一层散落的入口代码，和原来的 deep link 问题没有本质区别。

Siri 变强以后，Intents 会从入口变成能力索引

WWDC24 的 “Bring your app to Siri” 已经把方向说得很清楚：用 SiriKit 和 App Intents 把 App 功能暴露给 Siri 和 Apple Intelligence。

苹果在 App Intents 文档里也写到，随着 Apple Intelligence 增强，Siri 会建议 App actions，并获得在 App 内和跨 App 执行动作的能力。这里还有一个限制要说清楚：Siri 的 personal context understanding、onscreen awareness、in-app actions 仍在开发中，会通过未来软件更新提供。不能把它当成今天所有设备上完整可用的能力。

但方向已经足够明确。

过去 Siri 调用 App，更像“语音打开某个入口”。未来更接近“系统理解当前上下文，选择一个 App 能力，带着参数执行”。这会改变客户端团队对 API 的定义方式。

以前我们常说“页面是产品能力的载体”。在 App Intents 里，页面只是一个结果展示位置。系统真正需要的是：

• 哪些动作可以被外部触发；

• 哪些参数可以由系统补全；

• 哪些业务对象可以被搜索；

• 执行动作前是否需要用户确认；

• 执行完成后返回什么结果，是否需要打开 App。

这套信息一旦稳定下来，App 的能力就不只存在于 UI 树里，而是进入系统索引。

图 2：App Intents 的工程分层

Android App Actions 走的是另一条路径

Android 这边最接近的概念是 App Actions。

Google 的定义更偏 Google Assistant：用户可以通过“Hey Google, start a run on Example App”这类语音指令启动 App、执行任务、访问内容。开发者使用 Google Assistant 的开发框架和测试工具，在移动设备、汽车、Wear OS 等 Android 支持平台上提供更深的语音控制。

App Actions 的核心是 Built-in Intents，简称 BII。

开发者在 shortcuts.xml 里声明 capability，告诉 Google Assistant：我的 App 支持某个预定义语义动作。Assistant 解析用户自然语言，从 query 里抽取参数，再通过 Android intent、deep link 或 URL template 把请求交给 App。

概念结构大概是这样：

<shortcuts xmlns:android="http://schemas.android.com/apk/res/android">
    <capability android:name="actions.intent.START_EXERCISE">
        <intent
            android:action="android.intent.action.VIEW"
            android:targetPackage="com.example.app"
            android:targetClass="com.example.app.StartExerciseActivity">
            <parameter
                android:name="exercise.name"
                android:key="exerciseName" />
        </intent>
    </capability>
</shortcuts>

这套机制的优点是很务实：它沿用 Android 既有的 intent/deep link 模型，开发者不需要把整个业务对象体系重建一遍。只要你的 deep link、Activity、参数解析和任务入口足够稳定，就能把一部分能力交给 Assistant 调用。

代价也在这里：Android App Actions 更像“把语音语义映射到现有入口”。它对 App 内部实体、跨 App 上下文、系统级搜索索引的要求，没有 App Intents 那么强。它解决的是 Assistant 触发问题，不天然等价于一个系统范围的 App 语义层。

两边最大的差异：一个在塑造系统语义层，一个在复用执行入口

把 iOS App Intents 和 Android App Actions 放在一起看，不能只对比“都能被语音调用”。那会低估两边架构差异。

维度	iOS App Intents	Android App Actions / Shortcuts
主要入口	Siri、Shortcuts、Spotlight、Widgets、Controls、Action Button、未来 Apple Intelligence	Google Assistant、App Shortcuts、Launcher/Assistant surfaces
声明方式	Swift 类型系统：`AppIntent`、`@Parameter`、`AppEntity`、`EntityQuery`	XML `capability` + BII + Android intent/deep link
语义中心	App 能力和内容成为系统可理解资产	用户语音 query 通过 BII 映射到 App 执行入口
数据模型	强调 entity、query、display representation	强调 fulfillment、参数传递、URL template、Activity/deep link
AI 趋势	Apple Intelligence 会把 Siri 推向 context-aware 调用层	Gemini/Assistant 有演进空间，但 App Actions 文档本身仍偏 Assistant 时代接口
客户端改造重点	业务 service 分层、实体索引、intent metadata、权限与确认	deep link 稳定性、BII 选择、`shortcuts.xml`、参数映射和回归测试

我的判断是：App Intents 更像未来系统 AI 的能力索引层；App Actions 更像 Assistant 对 App 既有入口的语义映射层。

这不是先进与否的问题。它们服务的系统结构不同。

苹果控制 OS、Siri、Shortcuts、Spotlight、Widgets、Controls 和 Apple Intelligence 的统一体验，所以它有动力把 App 能力沉到一个系统框架里。Android 生态更开放，Assistant、Launcher、App Shortcuts、Intent、厂商系统服务之间不是单一控制面，Google 更倾向于先用 BII 和 shortcuts 把高频任务接起来。

客户端团队真正要改的是能力边界

如果团队只是把 App Intents 或 App Actions 当成“多加一个入口”，大概率会做出一层脆弱胶水代码。

更合理的改造顺序是反过来：先整理业务能力，再决定暴露给哪个系统入口。

1. 把页面行为下沉到业务 service

典型坏味道是：按钮点击逻辑都写在 ViewController、Fragment、ViewModel 或 React 组件里。

这种结构下，App Intents 只能重新拼一套逻辑；Android App Actions 只能打开页面再让页面自己处理参数。表面上接入了系统能力，实际还是 UI 驱动。

更稳的结构是：

UI / Widget / Shortcut / Siri / Assistant
            ↓
Action Adapter 层
            ↓
业务 Service
            ↓
Repository / Network / Database

App Intents、Shortcuts、Assistant fulfillment 都应该是 adapter，不应该成为业务逻辑本体。

2. 给业务对象补上可识别身份

App Intents 对 AppEntity 和 EntityQuery 的要求，会倒逼团队思考：系统到底能不能识别一个项目、联系人、笔记、订单、播放列表、训练计划？

如果业务对象只有 UI 层临时状态，没有稳定 ID、展示名称、查询方式和权限判断，它就很难被系统可靠调用。

Android 这边即使不要求完整实体模型，也会遇到相同问题。Assistant 抽取了参数以后，App 必须把字符串、枚举或 URL 参数映射回内部对象。如果对象体系不稳定，参数解析会变成一堆分支判断。

3. 把确认、权限和失败路径产品化

系统级调用比页面内点击更容易触发边界问题。

用户让 Siri 删除一个任务，是否需要确认？Assistant 启动一次训练，参数不完整怎么办？Spotlight 里搜索到某个私密对象，是否应该展示？Widget 触发动作时，App 是否需要解锁？

这些不是接入层细节，而是产品行为。客户端团队需要和产品、安全、后端一起定义。

跨端框架会遇到一个尴尬点

React Native、Flutter、KMP 或自研跨端框架很容易把这个问题低估。

原因很简单：App Intents 和 App Actions 都是平台能力，不是纯 UI 能力。你可以共享业务逻辑，但很难完全共享系统语义声明。

iOS 侧要写 Swift AppIntent、AppEntity、EntityQuery；Android 侧要维护 shortcuts.xml、BII、deep link、Activity 或 intent fulfillment。跨端层如果只包 UI，很难覆盖这些系统入口。

比较现实的做法是三层拆分：

• 跨端层维护业务 service、状态机和领域模型；

• 平台层维护系统语义声明和权限确认；

• 测试层覆盖“系统入口 → adapter → service → 结果”的完整路径。

这对大前端团队是一个提醒：未来移动端 AI 集成不是在 JS 层加一个 SDK 就结束。系统级 AI 调用会重新抬高 native integration 的价值。

图 3：跨端团队接入系统语义能力的三层模型

什么时候该投入做这层？

不是所有 App 都需要马上重构。

如果你的 App 主要是信息流、内容消费、交易浏览，系统级 intent 的价值可能先体现在搜索、分享、收藏、打开特定内容上。先把 deep link、Spotlight、App Shortcuts 做稳，比追完整 App Intents 更现实。

如果你的 App 有大量明确动作，比如待办、笔记、健身、日程、邮件、出行、财务、音乐、智能家居，就应该尽早梳理 intent 层。因为这些 App 的核心价值不是页面，而是可被调用的任务。

我的建议是按这个顺序推进：

先列出 5 个最高频用户任务，不要超过 5 个；

每个任务确认输入参数、业务对象、权限边界和失败返回；

iOS 侧用 App Intents 建一条完整路径；

Android 侧用 deep link / shortcuts / App Actions 对齐同一任务；

做自动化回归，覆盖系统入口触发，而不是只测页面按钮。

这套投入不会立刻带来炫酷 demo，但它会让 App 具备一个新能力：系统和 AI 可以稳定地调用你，而不是只能打开你。

结语

App Intents 和 App Actions 的共同方向，是把 App 从“页面集合”推向“能力集合”。

iOS 的变化更激进，因为 Apple Intelligence、Siri、Spotlight、Shortcuts 和系统控件会逐步共享同一套语义资产。Android 的路线更分散，App Actions 先围绕 Assistant 和 BII 解决语音触发，App Shortcuts 和 deep link 继续承担系统入口角色。

对客户端团队来说，最值得提前做的不是追某个 API，而是整理自己的能力边界：哪些动作可以被系统调用，哪些对象可以被系统识别，哪些权限必须由用户确认，哪些失败路径必须被清楚返回。

移动端 AI 会先调用那些已经把能力整理清楚的 App。系统不会替你理解一团散在页面里的业务逻辑。

迷斯特的小宇宙，客户端技术背景，大前端技术、AI前沿技术分享，偶尔写写生活日记。

如果这篇文章对你有启发，点个「在看」或转发给朋友，是对我最大的支持 🙏