Siri AI 怎样调用应用自定义操作

这次变化对应用开发意味着什么

Apple 在 2026 年 11 月 3 日开放 Siri AI Developer Preview。具体变化不是 Siri 自动获得任意应用的控制权，而是应用可以用 App Intents 显式提供自定义操作和内容，让 Siri 用自然语言匹配并调用这些接口；复杂任务还可以通过 App Skills 提供跨多个操作的指导。对开发者来说，原有 App Intents 不再只是 Shortcuts 或系统定义领域的入口，符合预览条件的应用还可以把自己的领域动作交给 Siri AI 编排。

这个能力目前有清晰的边界：它随 iOS、iPadOS、macOS 和 visionOS 27.3 beta 提供，设备必须支持 Apple Intelligence；开发者需要用 Xcode 构建并在设备上测试，或分发给 TestFlight 内部测试者。Apple 的预览文档明确说明，相关功能不会出现在外部 TestFlight 测试者或从 App Store 安装的版本中。因此，现阶段适合验证意图设计、实体检索和多步流程，不适合把它当作所有用户已经能用的生产入口。

把动作显式变成 Siri 工具

接入的第一步不是给所有 intent 加一个标记，而是挑选真正代表用户操作的 intent。Apple 的接入指南要求开发者显式选择哪些自定义动作可供 Siri 调用，并通过 App Intents 提供的工具支持声明它们。若某个 intent 已经符合 Siri 支持的系统 schema，就不应重复添加工具声明；只用于配置 Widget、没有实际执行动作的 intent，也不应伪装成可调用工具。

这个选择过程本质上是 API 面设计。应用需要把“查看订单状态”“取消尚未发货的订单”这样的用户目标映射到语义明确、输入可验证的操作，而不是把内部 CRUD 接口不加筛选地暴露给助手。每个 intent 的标题、描述、参数标题和参数描述都会影响 Siri 对请求的匹配、参数填充和动作区分。比如一个含糊的 Update 不足以表达更新的是地址、时间还是订单状态；参数也应说明需要完整地址、日期还是某个已知实体，而不是只依赖变量名。

动作描述还承担着减少误匹配的责任。开发者可以检查同一应用里多个 intent 是否使用了相似的动词，是否将不同风险的动作混在一个宽泛入口中，以及缺少必要参数时系统能否继续询问。特别是下单、发消息、删除或修改预约等会产生外部影响的操作，应该把可执行范围和需要的输入设计清楚，不能因为自然语言入口更方便，就省掉应用本身对状态和参数的校验。

Apple 文档也指出，用户不总需要在请求里提到应用名称：应用处于前台、Live Activity 活跃，或用户在 Siri 对话中已经提到该应用时，Siri 可以继续发现其自定义内容和动作；应用在后台时，用户需要在请求中提及应用。跨应用请求则可能将一个应用找到的实体交给另一个指定应用处理。开发者应把这些上下文差异纳入测试，而不是假设每次调用都具有相同的发现条件。

内容发现要考虑 Spotlight 与隐私

自定义动作只解决“能做什么”，自定义实体则解决“能找到什么”。Apple 的指南要求为 app entities 补充有助于匹配和展示的信息，并将需要被 Siri 找到的内容提供给 Spotlight。Siri AI 预览还支持 Spotlight 语义索引中的实体，不再只限于已有系统 schema 覆盖的实体类型。这意味着应用可以让自己的领域对象参与自然语言检索，但前提是应用实际提供了可索引的数据，并清楚地定义实体及其属性。

这里不能把“可检索”理解为“所有字段都可以展示”。Apple 文档特别提醒，实体信息默认不一定要求用户先认证，敏感属性需要配置认证策略；没有系统外使用价值或不应该进入 Siri 等系统体验的属性，则应限制可见性。实现时应逐个审查实体字段：哪些可以用于匹配，哪些可以放入回答，哪些只能在用户验证身份后读取，哪些完全不应离开应用边界。否则，自然语言检索虽然能返回正确对象，也可能把不该显示的内容带进 Siri 的卡片回答。

用户界面也会成为上下文来源。App Intents 指南提到，应用可以提供屏幕上下文和行为线索，让用户能用“这个”“刚才那个”等表达引用当前内容；实体还可以在不同 intent 之间以可传递的表示形式流转。开发者应把这些能力视作输入来源，而不是可信授权凭据。即使 Siri 提供了一个实体标识，应用在执行最终动作时仍需重新检查该对象是否存在、当前用户是否有权访问，以及状态是否允许修改。

多步任务用 App Skills 编排

单个 intent 适合边界明确的动作；当用户请求要组合多个动作、需要领域规则或存在多种合理路径时，Apple 提供 App Skills。一个 skill 是随应用资源打包的 Markdown 文件，包含元数据和自然语言指引。Xcode 会验证并编译 skills bundle，支持预览的设备会索引应用、扩展和内嵌框架中的 skill。系统先根据元数据判断某项技能是否与请求相关，之后才读取 Markdown 正文中的具体指导。

这一机制更接近面向模型的任务说明，而不是可执行脚本。官方文档规定，skill 正文最多 10,000 个字符；frontmatter 只支持 name 和 description，不支持其他字段，也不能附带脚本或引用文件。每项技能应位于以小写字母、数字和连字符组成的目录中，目录只包含对应的 Markdown 文件。技能名称在应用、扩展和内嵌框架之间必须唯一；重名时系统采用哪一个没有定义，因此不能依赖构建顺序解决冲突。

编写技能说明时，应把它限制在“如何组合已有工具”而不是另造一个绕过应用校验的执行通道。描述清楚任务适用范围、需要先收集哪些信息、哪些步骤必须依序执行，以及遇到缺失数据时应如何澄清。真正改变数据的工作仍应落到明确的 intent 上，由应用执行授权、业务规则和错误处理。这样可以单独测试每个动作，也可以调整技能说明而不把状态修改逻辑藏在自然语言提示里。

用 Siri Evaluations 验证行为

自然语言接口的测试不能只检查一个固定句子。Apple 新提供的 Siri Evaluations framework 可以把请求写成包含多个用户轮次的场景，并检查 Siri 调用了哪些 intent、传入了哪些参数、找到了哪些实体以及返回了什么文本。测试可以将每一步的实际行为与预期作确定性比较，适合放进应用集成测试，观察意图或实体更新后是否改变了 Siri 的处理路径。

较实用的验证方式是从端到端的简单请求开始：确认一个明确表达的动作能选中预期 intent，必需参数能正确传入，返回实体符合当前用户的数据范围。随后逐步加入间接表达、缺失参数、同名实体、用户改口和多轮上下文，重点覆盖应用前台、后台和 Live Activity 等不同发现情境。对有副作用的动作，还应覆盖无权限、对象状态已变化和重复请求等应用层边界。

Apple 同时提醒，Siri 的响应可能因运行而变化，因此应多次执行场景并逐步改善 intent 参数名与描述、实体信息和 App Skills。评估结果并不替代设备上的真实交互测试：文档建议在支持预览的设备上构建运行，也可以交给 TestFlight 内部测试者。测试记录应保留系统 beta、Xcode 和应用构建版本，这样遇到行为变化时才知道它来自应用代码、接口描述还是预览版系统。

当前适用范围与落地顺序

截至 2026 年 11 月 4 日，Apple 公告列出的 Siri AI 语言包括英语、法语、日语、韩语、葡萄牙语和西班牙语；需要支持 Apple Intelligence 的设备和受支持语言设置。公告同时列明，Siri AI 在欧盟的 iOS、iPadOS 和 watchOS 上暂不可用，13 岁以下用户不可用。功能还处于 Developer Preview，API 和 Siri 行为可能变化，Apple 表示稍后还会提供由 Siri AI 能力启用的体验相关条款与使用政策细节。

因此，应用团队可以按这个顺序验证：先挑一两个低风险、高频的自定义动作；补齐 intent、参数和实体描述；明确哪些字段可索引或展示；需要跨动作协作时再加 App Skill；最后用 Siri Evaluations 覆盖直接请求、歧义表达和权限边界，并在支持的设备上做人工验证。应用自己的鉴权、业务校验和失败处理仍然是最终边界，Siri 负责理解与编排，不等于应用可以信任未经复核的自然语言输入。

若团队也在梳理 AI 助手与工具之间的职责边界，可以对照编码代理的独立 Agent Host 架构；涉及模型与服务接入选择时，可从平台目录核对实际支持范围。两者关注点不同，但都提醒开发者不要把“系统能够调用”误认为“整个工作流的约束已经消失”。