Siri AI 会成为 AI Agent 吗？Apple Intelligence、JSON、API、Tool Calling 与 App Actions 详解

先回答：会做事，但不是开放 Agent

用工程定义收束，不要用发布会形容词。Agent 最少要有目标、感知和行动：模型决定下一步调哪个工具、填什么参数；运行时执行并把观察写回。旧 Siri 大多是「听懂一句、打开一个快捷指令或系统能力」，中间几乎没有「看结果再决定」的循环。2026 年的 Siri AI 开始补上这一环：它能在 App Intents 目录里选动作，能带着屏幕上下文解析「把这个存进备忘录」，也能在跨 App 请求里把一个实体交给下一个 Intent。从行为上看，它正在变成系统级 Agent。

它仍然不是你在 IDE 或客服后台里搭的那种开放 Agent。差别不在模型聪不聪明，而在谁画工具边界。开放 Agent 的工具清单是你注入的：OpenAI tools[]、Anthropic tool_use、MCP tools/list，arguments 几乎总是 JSON。系统 Siri 的清单是设备上已声明、且尽量贴合 App Schema 的 Intent；参数是 Swift 类型，不是一段你自己 parse 的自由文本。隐私边界也不同：设备端与 Private Cloud Compute 决定哪些上下文出得了机，不是你在系统提示词里写一句「可以读通讯录」。把 Siri 理解成「又一个可以随便挂函数的 ChatGPT」，会做出错误的迁移——删掉 App Intents，或在 iOS 里直接调 Gemini API「对齐官方」。

一句话：Siri AI 会成为系统里的 Agent，不会成为你拥有的 Agent 运行时。你能控制的是暴露给系统的动作形状，以及动作落到 HTTP 之后的 JSON。后面两节把产品层和契约层拆开，避免把「会做事」读成「开放工具循环」。

2026 年 Siri AI 实际多了哪三件事

Apple 开发者文档和 WWDC26 的口径，把 Siri 在 App Intents 上的能力收成三件事。它们解释「为什么看起来像 Agent」，也解释「为什么你还是得写 Intent，而不是挂一段 JSON Schema 就完事」。

1. 访问你的内容：把业务对象建成 App Entity，并尽量贴合 Entity Schema，交给 Spotlight 语义索引。Siri 才能在个人上下文里找到「那张已支付订单」，而不是只打开 App 首页。
2. 执行动作：Intent 贴合 Intent Schema（例如商务、照片、通信等预训领域）后，自然语言可以直接打到 perform()，不必再为每个说法写一套触发短语。这就是官方反复写的 app actions。
3. 理解屏幕：用 View Annotations 或 NSUserActivity 把眼前的视图标成实体，用户才能说「这个」「那个」。跨 App 请求往往从这里起步，而不是从你自己的多步 planner。

这三件事叠在一起，用户体感就是「Siri 会办事了」。开发者体感则是：你的 App 第一次真正成为系统 Agent 的工具箱。WWDC26 的 Build intelligent Siri experiences with App Schemas 把测试顺序也写死了——先隔离测 Intent 业务逻辑，再进快捷指令看参数形状，再进 Spotlight 看索引，最后才拿 Siri 做端到端。跳过前三步，只拿语音碰运气，排障会非常贵。

模型层同时在变，但不要把它读成产品替换。2026 年 1 月联署声明把下一代 AFM 的基础挂到 Gemini 技术上；6 月 Private Cloud Compute 扩到 Google Cloud，用来跑更重的 agentic tool-use。用户看见的仍是 Siri / Apple Intelligence，不是 Gemini 品牌，更不是 Google Assistant。战略拆解见 Apple 为什么依赖 Gemini；和 ChatGPT 扩展怎么分层，见 三家对比。对你来说，变的是云端模型有多敢编排多步动作，不是参数表改姓。

三层：Apple Intelligence、模型、开发者表面

把「Siri 变成 Agent」压成一层，后续决策全会歪。最少拆三层：用户看见的产品、推理跑在哪、你的代码接到哪条契约。

Foundation Models 是另一条线。它让 App 在设备上（以及文档写明的 PCC 路径上）跑 LanguageModelSession，用 Tool 做 App 内 tool calling，用结构化生成约束输出。这是「你的 App 自己当 Agent 运行时」，和「系统 Siri 当 Agent、打进你的 Intent」不是同一条请求。很多 App 会两条都做：要被 Siri / Spotlight / 快捷指令发现，就出 App Intents；要在 App 里让 on-device 模型查库存、填表，就出 Tool。详细接法见 Apple AI Agent 如何连接 App 与 API。

快捷指令把两层粘在一起。Apple Intelligence 可以根据自然语言拼多步自动化；Adopt 了 App Intents 之后，你的动作会进入这套生态，和 Use Model 一类能力并列。用户可以描述「先查已支付订单，再写进备忘录」——编排者仍是系统，不是你在服务器上写的 planner。你要保证每一步 Intent 的参数都能独立成立，因为系统可能只跑其中一跳，也可能换序。

App Intents、App Schemas 与 App Actions

App Intents 不是「给 Siri 加语音」。它是第三方 App 和 Apple Intelligence 之间的合同：你声明能提供什么内容、能执行什么动作，系统再决定何时调用。从 iOS 18 铺开，到 2026 年它已经同时喂给 Siri、Spotlight、Widget、快捷指令和系统 Agent。还把 App Intents 当成可选项的团队，是在误读系统 AI 的入口。

App Schema 是这份合同的「预训形状」。Entity Schema 告诉系统这是订单、照片还是会话，好进语义索引；Intent Schema 告诉系统这是查找、打开还是分享，好让自然语言直接打中，而不必你维护一份触发语料。Xcode 用宏生成符合 schema 的样板，并在编译期核对。领域对不上，Siri 仍可能把你的动作当普通快捷指令，而不是系统 Agent 优先选中的工具。WWDC26 还补了更长生命周期的 Intent、可取消、跨设备同步实体——这些让「办事」更像循环，但循环仍由系统调度。

App Actions 这个词最容易写飞。Apple 开发者页上的 app actions，指的是经 App Intents 暴露、可被 Siri AI 和系统表面执行的能力，不是 Google Assistant 历史上的 App Actions 协议，也不是 Android 上另一套 intent filter。两套产品都叫「让助手调用 App」，字段、清单和隐私模型完全不同。写方案时请写「App Intents / App Schema」，把「App Actions」留作面向用户的说法。混用会让后端同学去找一份并不存在的 Google 风格 JSON-RPC。

Tool Calling：系统 Agent 与 App 内 Tool

业界说的 Tool Calling / Function Calling，机制只有一句：模型不直接碰数据库，而是发出「请调用某某函数、参数如下」，由运行时执行。2026 年各家外壳不同，arguments 都是 JSON object。Siri 这一侧把同一件事收成了类型化 Intent：系统模型选中 findOrders，填好 email / status / limit，再进你的 perform()。你在 perform() 里如果要打自己的 HTTP API，再把这些字段编成 JSON。两跳不要共用一份「随便解析」的逻辑。

建议在日志和联调夹具里存「意图层」载荷，而不是存模型商标。下面这段 JSON 只描述：谁发起、贴了哪条 schema、调了哪个动作、参数是什么。runtime.onDevice 可以记，不要拿它做业务校验——设备端兜底和云端全量必须接受同一份 arguments。

{
  "source": "siri-ai",
  "schema": "commerce.findOrders",
  "intent": "findOrders",
  "arguments": {
    "email": "ada@example.com",
    "status": "paid",
    "limit": 5
  },
  "runtime": {
    "surface": "siri",
    "onDevice": false
  }
}

同一组业务字段，若出现在你自己的开放 Agent 里，外壳会变成各家 tool_calls。注意 arguments 经常是字符串：先 JSON.parse，再按同一份 Schema 校验。Siri 打进来时你拿不到这段外壳，只能拿到已经类型化的参数；出网到自己的 API 时，才重新看到 JSON。

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "findOrders",
    "arguments": "{\"email\":\"ada@example.com\",\"status\":\"paid\",\"limit\":5}"
  }
}

对照很清楚：名字都叫 findOrders，键都该同源。系统路径没有 tool_call id，开放路径没有 App Schema 域名。不要把 Gemini generateContent、OpenAI tools[] 和 App Intent 参数表抄成互为默认值。Structured Output 管的是最终答复形状，不是这一跳工具入参；分文件的理由见 AI Structured Output。

JSON、API 与本地校验

Siri 变得更像 Agent 之后，失败模式也更像 Agent：多跳、可选字段被填上、枚举写飞、设备端降级少两个键。模型更强不会减免校验，只会让漏检更贵。每个出网 hop 仍是三步：parse → Schema → 业务规则。

1. 把 Intent 参数编成 JSON 后立刻 parse；失败则记下 intent 名与原始字段，返回可重试的错误，而不是把 Swift 报错原文丢给用户。
2. 用同一份 Draft 2020-12 Schema 卡类型、枚举和 required。additionalProperties 建议 false，避免云端档多填的键漏进下游。
3. 业务门：权限、外键、日期范围。通过后再打订单服务。系统 Agent 重试时，你的 API 必须幂等。

联调时并排三份：Siri / 快捷指令打进来的参数对象、你发给 HTTP 的 body、服务器实际使用的对象。形状不一致，问题几乎总在适配层。浏览器里用JSON 格式化看字段；JSON Schema 校验卡类型；JSON 对比看设备端兜底和云端全量少了哪些键。固定 fixture：valid、missing-field、wrong-enum，CI 与 Siri 真机排查共用。

延伸阅读：Apple AI Agent 与 JSON、AI Agent 是什么、AI 生成 JSON 错误指南、MCP 与 JSON Schema。

常见问题 FAQ

总结与下一步

Siri AI 会成为 AI Agent——在系统边界之内。Apple Intelligence 提供个人上下文、app actions 和屏幕感知；模型层可以借 Gemini 技术和更重的 PCC；开发者仍通过 App Intents 交出动作，通过 Foundation Models Tool 做 App 内循环。开放 Tool Calling 的 JSON 外壳不会出现在系统请求里，但会出现在你自己的 API 上。

下一步很具体：列出要对齐的 App Schema，把 Intent 参数和 HTTP body 写成同一份 Schema，用 JSONVue 跑通 valid / 缺字段 / 错误枚举。模型商标会变，动作形状不该跟着变。