App Intents是Apple为您的应用打造的全新API

2026年2月8日清晨,我双手正在厨房水槽下作业,通过Apple Watch请求Siri记录8盎司饮水量。水量已记录。手表对话框显示还剩32盎司。整个过程我未曾触碰任何屏幕。¹

十一周前,我向我的饮水追踪iOS应用Water中添加了一个Swift文件:LogWaterIntent.swift,80行AppIntent代码加上一个声明了三种Siri短语变体的AppShortcutsProvider。如今该文件已成为我所拥有的最炙手可热的API表面。²

下面这一点我花了好一阵子才真正理解透彻。App Intents并非Siri的功能。它们是第三方应用与Apple Intelligence签订的契约,而Apple Intelligence正是Apple从iOS 18开始推出、并在iOS 26中持续构建的系统AI表面。³如果您发布iOS应用,却仍将App Intents视为”锦上添花”的语音功能,那您就误读了Apple构建的体系。App Intents是让Apple的AI能够以您的应用身份代表用户行事的API。其他一切(Siri、Spotlight、Shortcuts、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网络要么通过您声明的intents路由,要么绕过您的应用转向竞争对手。
• Apple三年来一直在告诉我们这件事。命名(App Intents、App Shortcuts、Apple Intelligence)是有意为之。每一届WWDC,这份契约都向技术栈上层推进一层。

App Intent究竟是什么

LogWaterIntent的完整源代码,即2026年2月8日在commit 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即架构。Apple的AI看到的是默认值为8的amount: Int。当Siri解析”log 12 oz of water”时,会生成LogWaterIntent(amount: 12)并调用perform()。我这边无需做任何字符串解析。类型系统就是架构。⁵

parameterSummary是参数的自然语言映射。Apple用它在Shortcuts界面、对话框中渲染该操作,并日益用于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、Shortcuts和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),这是第三方应用首次能被语音调用。表面非常狭窄:固定的领域列表(消息、支付、叫车),且架构严格。⁸
• iOS 12(2018)通过Siri Shortcuts拓宽了表面:任何应用都可以贡献一个NSUserActivity或INIntent,期待Siri给出建议。
• iOS 13(2019)新增了应用内intent处理,让应用无需切回到系统Siri界面后台即可响应快捷指令调用。
• iOS 16(2022)引入了App Intents框架:类型化、声明式,带有@Parameter和AppShortcutsProvider。INIntent前身在新开发中实质上已被取代。⁹
• iOS 18(2024)引入了Apple Intelligence,并开始尽可能通过App Intents路由Siri请求。Apple Intelligence的”个人上下文”功能从App Entities(App Intents的数据版本)读取信息。¹⁰
• iOS 26(2025)引入了Foundation Models框架,即Apple的端侧LLM。Foundation Models公开了一个独立的Tool协议用于应用内工具调用。App Intents仍是Apple Intelligence跨应用的标准表面,而Tool是直接调用LLM的应用内表面。两份契约并行运行。⁴

每一次发布,契约都在沿着技术栈向上延伸。最初,App Intent的消费者是点击Shortcuts的人。然后是Siri语音。再到Spotlight。再到Apple Intelligence摘要。如今Apple Intelligence的LLM后端系统表面也通过它们来响应用户请求。您在2026年发布的App Intent表面,就是Apple Intelligence将在iOS 27、28、29中调用的那一份。

上述模式正是我所说”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会优先把”Hey Siri, log my water”这样的短语路由到首先声明了匹配intent的应用。我在2026年2月发布了Water的intent。我对该框架走向的判断是:在2027年才发布intent的饮水类应用,进入的将是一个路由权重已向先行者倾斜的市场。同样的逻辑也适用于购物清单、健身记录、日历项、照片搜索。我预计intent声明上的先行者优势会复利累积,正如其他Apple平台押注的API(HealthKit类别、Spotlight富结果、Live Activities令牌)那样。

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

IntentResult & ProvidesDialog的返回形态愈发重要。Apple Intelligence正在Siri、Spotlight和Watch上把intent结果组合成更长的回复。一个仅返回成功标志、没有结构化对话的perform(),系统更难将其编织进连贯的回复。ProvidesDialog和ProvidesView并非可选的礼貌之举;它们决定了您的操作能否成为用户AI表面中的一处引用。

我会做出哪些不同的选择

Water十一周的生产日志告诉我三件本该更早做的事。

多发布几个intent,比您想象的要多。我只发布了一个。本应发布四个:LogWaterIntent、CheckTodaysProgressIntent、AdjustGoalIntent、ShowHistoryIntent。每个都映射到用户实际会尝试的Siri短语(“how much water have I had today”被路由到了Apple的通用AI而非我的应用数据)。每一个缺失的intent,都是Apple Intelligence绕过我的一次查询。

对话字符串不是邮件正文。我从一开始就用了ProvidesDialog,但早期对话写成了散文风。用户透过CarPlay或AirPods听到的对话需要简短、具体、事实先行的结构:”8 oz logged. 32 oz to go.”Watch表面尤其会激进截断。对话式的措辞比”自信陈述事实”式的措辞用户体验更差。我在第4周重写了它。²

App Entities的重要性超出我的预想。我有一个WaterEntrySwiftData模型。我还应该声明一个WaterEntryEntity: AppEntity以及配套的WaterEntryQuery: EntityQuery,这样Apple Intelligence才能回答”show me when I drank water yesterday”。最简桥接代码:¹¹

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())")
    }
    var amount: Int
    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”的用户落在正确的条目上),需让该实体遵循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已经通过其.mcpbMCP服务器暴露给Claude Desktop的同一持久层,同时暴露给Apple Intelligence。¹⁴两个LLM生态、两份不同的契约、同一份购物清单。这就是单一已发布应用中并行契约论的具体体现:SwiftData模型是数据,App Intents是Apple的契约,MCP是Anthropic的契约,两个表面在同一份真实数据源上运行。

何时不应发布App Intent

拒绝也是设计的一部分。

如果您的应用纯粹由消费驱动(读取用户照片、展示新闻、播放音频),没有可变的用户状态,App Intents可能根本无可暴露。Apple的框架支持OpenIntent(只是把应用打开到某个上下文),但如果唯一有用的操作就是”打开应用”,这个intent就成了多余开销。不要为发布而发布。

如果操作依赖难以抽象的UI可供性(复杂的多步画布工具、3D编辑应用),那么必需的parameterSummary就会退化为没人会真正说出口的、含糊的伪自然语言。Siri短语”edit my photo with the blur tool at strength 7”理论上可行,但没有任何人类会说这句话。该intent的表面就成了没有回报的负担。

正确的标准是:当存在一句用户会自然说出、并由此触发该操作的话时,App Intent才值得发布。”Log 8 oz of water”就是那种句子。”Apply Gaussian blur with sigma 2.4 to layer 3”则不是。如果您应用的操作大多落在第二种模式上,那么intents就不是您的转化杠杆。

收尾观点

三年来,Apple一直在传达:iOS的系统AI网络通过App Intents运转。WWDC 2024加入了通过它们路由的Apple Intelligence。WWDC 2025引入了Foundation Models作为另一个独立的应用内工具调用表面,而App Intents继续作为Siri/Spotlight/Apple Intelligence所使用的跨应用契约。所有信号都指向同一方向:类型化、声明式的App Intent,正是第三方应用如今与系统签订的契约。

大多数iOS应用至今仍把App Intents视为Siri Shortcuts:有时间再做的功能。我的判断是,这种定位不会在时间长河里站得住脚。随着Apple Intelligence的系统表面持续延伸(如今已涵盖Siri、Spotlight、Shortcuts和Apple Intelligence摘要),没有声明intents的应用很可能发现自己处于路由图谱之外。根据我观察Apple其他平台押注的经验,先行者表面会持续复利。

Water的LogWaterIntent已发布十一周。一个App Intent的发布代码量足以装入单个文件。而不发布它的代价,会随着Apple Intelligence的每一次发布而增长。

如果您在2026年发布iOS应用,却尚未声明哪怕一个App Intent,那您的路线图就缺了一个条目。把它补上。

常见问题

iOS开发中的App Intent是什么?

App Intent是一种类型化、声明式的Swift结构,将您应用的某个操作暴露给Apple的系统AI表面。它通过@Parameter声明参数,通过parameterSummary声明自然语言摘要,通过异步perform()方法执行实际工作并返回结构化结果。Apple的Siri、Spotlight、Shortcuts和Apple Intelligence都可以调用它。Foundation Models(Apple的端侧LLM)使用一个独立的Tool协议进行应用内的直接工具调用。

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

App Intents(于iOS 16,2022年推出)取代了INIntent,成为Apple的主要intent框架。新框架完全Swift原生,使用@Parameter等属性包装器,通过AppEntity支持类型安全的实体查询,并且是Siri、Spotlight、Shortcuts和Apple Intelligence调用的表面。较旧的INIntent仍受支持,但不再获得新功能开发投入。

发布App Intent需要iOS 26吗?

不需要。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中发布了一个。复利已经开始了。

参考资料