App Intents 是 Apple 通往你应用的全新API

2026年2月8日上午，我把双手伸在厨房水槽下方时，请 Siri 通过 Apple Watch 记录了 8 盎司饮水量。水量记录成功。手表上的对话框显示还剩 32 盎司。我的手指完全没有触碰过任何屏幕。¹

十一周前，我在我的饮水追踪 iOS 应用 Water 中添加了一个 Swift 文件：LogWaterIntent.swift，80 行 AppIntent 加上一个声明三种 Siri 短语变体的 AppShortcutsProvider。这个文件如今成了我所拥有最炙手可热的API接口。²

接下来这部分我花了一段时间才真正理解。App Intents 不是 Siri 的功能。它是第三方应用与 Apple Intelligence——也就是 Apple 从 iOS 18 开始推出、并在 iOS 26 中持续完善的系统级 AI 接口——之间签订的契约。³ 如果您发布过 iOS 应用，却仍把 App Intents 视为”可有可无”的语音功能，那您就误读了 Apple 已经构建的东西。App Intents 是让 Apple 的 AI 能够以您应用的身份代表用户执行操作的API。其他一切（Siri、Spotlight、快捷指令、Apple Intelligence 摘要、Watch 和 Vision Pro 接口）都是这一契约的下游产物。Foundation Models 是 iOS 26 中推出的端侧LLM，它暴露了一套独立的 Tool 协议用于应用内工具调用；它与 App Intents 平行运行，而非通过它运行。

TL;DR

• App Intents 以类型化、结构化的方式声明您的应用能做什么，让 Apple 的 AI 可以直接调用。它们是 Apple 面向第三方应用的工具调用API。
• 一个真实的生产示例：Water 中的 LogWaterIntent。80 行代码，完整的 SwiftData 写入，HealthKit 同步，本地化感知的单位换算，以及结构化的 Siri 对话响应。
• iOS 26 加入了 Foundation Models，Apple 的端侧LLM。Foundation Models 暴露了自己的 Tool 协议用于应用内工具调用；App Intents 仍是 Siri / Spotlight / Apple Intelligence 跨应用调用的标准接口。同一方向，两份平行契约。
• 在 2026 年，没有 App Intents 的应用对 Apple Intelligence 而言是隐形的。AI 网络要么经由您声明的 intent 路由，要么绕过您的应用去找竞争对手。
• Apple 已经向我们传递这一信号三年了。命名（App Intents、App Shortcuts、Apple Intelligence）是有意为之。每一届 WWDC，契约都向技术栈上方推进一层。

App Intents 框架参考图来自 Apple Developer 文档。⁵

App Intent 究竟是什么

LogWaterIntent 在 2026 年 2 月 8 日提交 e398c58 中发布的完整源码：²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

（Water 当前生产版本的该文件在对话部分进一步加入了”达成目标 / 剩余量”的条件分支。上面 2 月 8 日的发布代码才是我在厨房水槽边亲自测试的那一版。）

这里有三件事值得明确指出，因为大多数”App Intents 教程”都一笔带过。

@Parameter 就是 schema。Apple 的 AI 看到的是默认值为 8 的 amount: Int。当 Siri 解析”log 12 oz of water”时，它会生成 LogWaterIntent(amount: 12) 并调用 perform()。我这边不需要做任何字符串解析。类型系统就是 schema。⁵

parameterSummary 是参数的自然语言映射。Apple 用它在快捷指令 UI、对话以及越来越多的 Apple Intelligence 确认面板中渲染该操作。摘要会被读给用户听。写得糟糕，用户听到的就是一句别扭的句子；写得到位，整个接口就有了原生质感。⁶

perform() 返回 IntentResult & ProvidesDialog。这就是结构化的返回值：AI 接口不仅得到成功 / 失败的状态，还能拿到要念给用户听的对话字符串。Apple 越来越期望 ProvidesDialog、ProvidesView 或 ReturnsValue，这样结果才能编排进 Siri、Spotlight、Watch，以及（在 iOS 26 中）Apple Intelligence 的响应链。⁷

底部的 AppShortcutsProvider 区块用于注册 Siri 短语。\(.applicationName) 占位符是 Siri 自动插入”Water”的位置。三种短语变体共用同一个 intent，让 Apple 的自然语言解析器有更大空间匹配用户表达，您也无需自己维护短语字典。systemImageName 是真实的 SF Symbols 名称；Spotlight、快捷指令和 Apple Intelligence 就是据此渲染该操作的图标。

Apple Intelligence 通过 App Intents 路由用户请求，从而提供端侧 AI 功能。来源：apple.com/apple-intelligence。

为何这是 SwiftUI 之后最重要的 iOS API

iOS API分两类。一类关乎您的应用如何绘制自身（UIKit、SwiftUI、Metal）。另一类关乎您的应用如何与系统集成（URL Schemes、Universal Links、Widgets）。App Intents 是第三类：它定义了 Apple 的AI如何使用您的应用。

这条演进路径值得追溯。

• iOS 10（2016）引入了 SiriKit Intents（INIntent），第三方应用首次可以被语音调用。当时的接口很狭窄：固定的几个领域（消息、支付、打车）配以严格的 schema。⁸
• iOS 12（2018）通过 Siri 快捷指令拓宽了接口：任何应用都可以捐献 NSUserActivity 或 INIntent，期待 Siri 提示推荐它。
• iOS 13（2019）加入了应用内 intent 处理，应用可以响应快捷指令调用而无需切换到系统 Siri 界面。
• iOS 16（2022）推出了 App Intents 框架：类型化、声明式，带 @Parameter 和 AppShortcutsProvider。前身 INIntent 在新开发中实际上已被取代。⁹
• iOS 18（2024）推出了 Apple Intelligence，并开始尽可能地将 Siri 请求路由经过 App Intents。Apple Intelligence 的”个人语境”功能从 App Entities（App Intents 的数据版本）中读取数据。¹⁰
• iOS 26（2025）推出了 Foundation Models 框架，Apple 的端侧LLM。Foundation Models 暴露了一个独立的 Tool 协议用于应用内工具调用。App Intents 仍是 Apple Intelligence 的标准跨应用接口，而 Tool 是用于直接LLM调用的应用内接口。两份契约平行运行。⁴

每一个版本都让契约沿技术栈向上延伸。最初，App Intent 的消费者是手动点击快捷指令的人。然后是 Siri 语音。再然后是 Spotlight。接着是 Apple Intelligence 摘要。如今，Apple Intelligence 由LLM驱动的系统接口正在用它来响应用户请求。您在 2026 年发布的 App Intent 接口，就是 iOS 27、28、29 的 Apple Intelligence 将要调用的那一个。

上面这条演进就是我说 App Intents 不是 Siri 功能的原因。它们是面向整个 Apple AI 网络的结构化工具调用API。SwiftUI 之所以是最重要的 UI API，是因为它成为了编写 visionOS、watchOS 10+ 和 iOS 17+ 应用的唯一方式。App Intents 在 AI 这一侧正在沿着同样的轨迹推进：这就是 Apple 押下全部赌注的接口。

Foundation Models 发布之后会有什么变化

Foundation Models 是在每一台支持 Apple Intelligence 的设备上都会附带的框架。硬件门槛与 Apple Intelligence 名单一致：iPhone 15 Pro 和 15 Pro Max（A17 Pro）、iPhone 16 系列、iPhone 17 系列、iPhone Air、iPhone 17e、搭载 M1 及以上芯片的 iPad Pro、搭载 M1 及以上芯片的 iPad Air、搭载 A17 Pro 的 iPad mini、搭载 M2 及以上芯片的 Vision Pro，以及搭载 M1 及以上芯片的 Mac。值得注意的是名单中缺席的：基础款 iPhone 15 / 15 Plus。⁴¹²

含义在于：如果 Apple 的系统接口（Siri、Spotlight、Apple Intelligence）确实要调用您的应用，那一定是通过 App Intents 和 App Entities 调用。在系统 AI 网络中，第三方应用没有 setSystemPrompt(...) 这样的API。只有 intent 注册表。Foundation Models 为想要在自家应用内构建端侧LLM功能的开发者添加了一个平行的应用内 Tool 接口。但跨应用契约（Apple Intelligence 和 Siri 用来寻找您应用的那一个）仍然是 App Intents。

对应用开发者而言，这意味着三个具体的后果：

没有相关 App Intent 的应用，在所属类别下无法被 Siri 语音指令触达。Apple Intelligence 会优先把”嘿 Siri，记录我的饮水”这类短语路由到那些已经声明了对应 intent 的应用。我在 2026 年 2 月发布了 Water 的 intent。我对这一框架走向的判断是：在 2027 年才发布 intent 的饮水类应用，将会进入一个路由权重已经向先行者累积的市场。同样的逻辑适用于购物清单、运动记录、日历事件、照片搜索。我预计 intent 声明的先发优势会形成复利，就像 Apple 其他平台级押注API（HealthKit 类目、Spotlight 富文本结果、Live Activities 令牌）那样。

Apple Intelligence 的个性化机制读取的是 App Entities，而不仅仅是 intents。AppEntity 声明了”这个应用拥有这种形状的数据”。当用户问”我加到阅读清单里的最后一本书是什么”时，Apple Intelligence 会在每一个已安装应用中搜索匹配 Book 的 AppEntity。如果您的应用有阅读清单，但没有声明 BookEntity，那您的数据对 Apple 的 AI 接口就是隐形的。Apple Intelligence 无法检索或引用您的数据。¹¹

IntentResult & ProvidesDialog 这种返回形状越来越关键。Apple Intelligence 正在把 intent 结果编排进 Siri、Spotlight 和 Watch 上更长的响应链。一个仅仅返回成功状态、没有结构化对话的 perform()，系统更难把它整合进一段连贯的回复。ProvidesDialog 和 ProvidesView 不是可有可无的礼貌；它们是您的操作能否成为用户 AI 接口中一条引用的关键。

我会有哪些不同的做法

Water 在生产环境中跑了十一周，让我意识到三件本应更早做到的事。

发布的 intent 数量应该比你以为需要的更多。我只发布了一个。我本应发布四个：LogWaterIntent、CheckTodaysProgressIntent、AdjustGoalIntent、ShowHistoryIntent。每一个都对应一句用户真实会说出口的 Siri 短语（”我今天喝了多少水”会被路由到 Apple 的通用 AI 而不是我应用的数据）。每一个缺失的 intent，都是 Apple Intelligence 绕过我的一次查询。

对话字符串不是邮件正文。我从一开始就用了 ProvidesDialog，但我早期的对话写得像散文。用户透过 CarPlay 或 AirPods 听到时，需要的是简短、具体、事实先行的结构：”已记录 8 oz。还差 32 oz。”Watch 接口尤其会激进截断。会话式对话的用户体验比事实陈述式对话差。第 4 周我重写了对话。²

App Entities 比我想的更重要。我有一个 WaterEntry SwiftData 模型。我还应该声明一个 WaterEntryEntity: AppEntity 以及配套的 WaterEntryQuery: EntityQuery，这样 Apple Intelligence 就能回答”显示我昨天什么时候喝过水”。最小桥接代码：¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

两个小型 Swift 类型，加上 SwiftData 取数胶水代码。要让条目在 Spotlight 中可单独被查找（让搜索”water”的用户落到正确的条目上），需要让 entity 遵循 IndexedEntity 协议，并在写入时主动更新索引。这才是 Apple Spotlight 流水线在裸 AppEntity 暴露之外所期望的做法。

同样的形态适用于我其他的应用。我的购物清单应用 Get Bananas 已经有了一个 SwiftData @Model ShoppingItem，包含 @Attribute(.unique) var id: UUID、name、amount、section、isChecked，外加用于 iCloud Drive 同步的 lastModified 字段。¹³ 把它包装成 ShoppingItemEntity: AppEntity 并发布若干 intent（AddShoppingItem、CheckOffItem、ShowList），就能把 Get Bananas 已经通过其 .mcpb MCP 服务器暴露给 Claude Desktop 的同一份持久化层，同样地暴露给 Apple Intelligence。¹⁴ 两个LLM生态、两份不同的契约，对应同一份购物清单。这就是把”平行契约”命题落到一个已发布应用上的样子：SwiftData 模型是数据，App Intents 是 Apple 的契约，MCP 是 Anthropic 的契约，两个接口操作的都是同一个数据源。

何时不要发布 App Intent

懂得拒绝是设计的一部分。

如果您的应用纯粹是消费驱动的（读取用户照片、显示新闻、播放音频）且没有可变的用户状态，App Intents 可能没什么可暴露的。Apple 的框架支持 OpenIntent（仅仅打开应用到某个语境），但如果唯一有用的操作就是”打开应用”，那这个 intent 就是冗余开销。不要为了拥有它而发布。

如果操作依赖难以抽象的 UI 表现（复杂的多步骤画布工具、3D 编辑应用），那么 intent 必需的 parameterSummary 就会退化成谁也不会真正说出口的、含糊的伪自然语言。Siri 短语”用模糊工具按强度 7 编辑我的照片”理论上可行，但没有人会真的这么说。这种 intent 接口是只有税收没有回报的。

正确的判定标准是：当存在一句用户会自然说出口、并能触发该操作的话时，App Intent 才有存在的价值。”Log 8 oz of water”就是这样一句话。”在第 3 层应用 sigma 2.4 的高斯模糊”则不是。如果您应用的操作集中在第二种模式，那么 intents 就不是您的转化杠杆。

收尾观点

三年来，Apple 一直在释放信号：iOS 的系统 AI 网络是经由 App Intents 运作的。WWDC 2024 加入了通过 App Intents 路由的 Apple Intelligence。WWDC 2025 加入了 Foundation Models 作为一个独立的应用内工具调用接口与之并行，让 App Intents 仍然是 Siri / Spotlight / Apple Intelligence 持续使用的跨应用契约。所有信号都指向同一个方向：类型化、声明式的 App Intent，就是第三方应用如今与系统签订的契约。

大多数 iOS 应用仍然把 App Intents 视作 Siri 快捷指令：一个有时间再发布的功能。我的判断是这种定位会很快显得落伍。随着 Apple Intelligence 的系统接口持续延伸（如今已经覆盖 Siri、Spotlight、快捷指令和 Apple Intelligence 摘要），没有声明 intents 的应用很可能会发现自己被排除在路由图之外。从我观察 Apple 其他平台级押注的经验看，先发接口会产生复利。

Water 已经发布了 LogWaterIntent 整整十一周。一个 App Intent 的代码量小到可以放进单个文件。每一次 Apple Intelligence 的新版本发布，不发布 App Intent 的代价都会增长。

如果您在 2026 年发布 iOS 应用，却还没有声明至少一个 App Intent，那您的路线图里就少了一项。把它加进去。

常见问题

iOS 开发中的 App Intent 是什么？

App Intent 是一种类型化、声明式的 Swift 结构体，把您应用的某个操作暴露给 Apple 的系统 AI 接口。它通过 @Parameter 声明参数，通过 parameterSummary 给出自然语言摘要，并以异步的 perform() 主体完成实际工作并返回结构化结果。Apple 的 Siri、Spotlight、快捷指令和 Apple Intelligence 都可以调用它。Foundation Models（Apple 的端侧LLM）使用一个独立的 Tool 协议来直接进行应用内工具调用。

App Intents 与较旧的 INIntent 有何不同？

App Intents（在 iOS 16，即 2022 年推出）取代了 INIntent，成为 Apple 的主要 intent 框架。新框架完全 Swift 原生，使用 @Parameter 等属性包装器，通过 AppEntity 支持类型安全的实体查询，是 Siri、Spotlight、快捷指令和 Apple Intelligence 调用的接口。较旧的 INIntent 仍受支持，但不再有新功能加入。

我必须用 iOS 26 才能发布 App Intent 吗？

不需要。App Intents 从 iOS 16 起就可用了。iOS 26 在其旁边新增了 Foundation Models 框架，但 App Intent 声明本身在 iOS 16+ 上就能工作。上面的示例代码使用了 SwiftData（iOS 17+），因此部署目标取决于您的 perform() 主体引入了什么。裸 App Intents 可以追溯到 iOS 16；基于 SwiftData 的则需要 iOS 17。

App Intent 与 App Entity 之间有什么区别？

App Intent 是一个操作（动词）。App Entity 是您应用所知道的数据（名词）。LogWaterIntent 是一个 intent。让 WaterEntry 成为可查询类型则是一个 entity。Apple Intelligence 两者都用：用 intents 执行操作，用 entities 在响应中检索和引用数据。

App Intents 与 Foundation Models 工具调用有何关系？

Foundation Models 暴露了自己的 Tool 协议用于直接的应用内LLM工具调用。App Intents 仍是 Apple Intelligence、Siri 和 Spotlight 调用的标准跨应用接口。同一方向（类型化、声明式的工具调用），两份平行契约。一个想要被系统 AI 接口触达的应用要发布 App Intents；一个想要用自定义工具调用自家端侧LLM的应用则要发布 Tool 实现。许多应用会两者都发布。

App Intents 不是一个功能。它是契约。先发布 intent 的应用拿到接口；后发布的应用会发现接口已经被路由到了别处。十一周前我在 Water 中发布了一个。复利已经开始累积。

Apple 生态系列其他文章

本文是入口。其余四篇覆盖架构栈的其他部分：

• 两个智能体生态，一份购物清单：Get Bananas 如何通过 iCloud Drive 中的同一个 JSON 文件，把同一份数据同时暴露给 Apple Intelligence（App Intents）和 Claude Desktop（MCP）。
• SwiftUI 中的 Liquid Glass：Return 发布过程中沉淀的三种模式：iOS 26 视觉层的生产实践模式。
• 五大 Apple 平台，三份共享文件：多平台发布策略，何时共享代码、何时分叉目标。
• iOS 26 上的 HealthKit + SwiftUI：授权流程、样本类型，以及那个会把用户锁在您应用之外的陷阱所组成的数据源层。

或者直接跳转到完整专题页：Apple 生态系列。如需了解更宏观的 iOS 与 AI 智能体语境，请参阅 iOS 智能体开发指南。

参考资料