博客 • AI / Agent

Siri AI 会成为 AI Agent 吗？Apple Intelligence、App Actions、API 与 JSON 工作原理

预计阅读 12 分钟

听到 Siri AI，很容易把它想成 ChatGPT 那种能自己选工具、自己拼 API 的 Agent。Apple 在 WWDC 2026 发布的，不是这一类。

Siri AI 正在变成系统级 Agent：能理解个人上下文、看见屏幕上的内容、跨 App 执行 App Actions。它不是开放 Agent。模型不能发明 REST 路径，也不能往你的服务器随便写 JSON。

本文将说明：

先记住这一点：Siri AI 的智能在操作系统这一层，约束在工具这一层。模型只在你声明过的动作里选；JSON 是这些动作离开进程之后的运行时契约。下面按「答案 → 产品分层 → App Actions → 数据流 → JSON → 对照」拆开。

先给答案：系统 Agent，不是开放 Agent

Agent 这个词现在被用滥了。有人把它当成「会聊天的助手」，有人当成「能循环调用工具直到办完事的运行时」。Siri AI 靠近后者，但工具从哪来，和开放 Agent 完全不同。

开放 Agent（ChatGPT、Claude、自建 Runtime）通常是：模型看一段对话，从一份 tools 列表里选出 name 和 arguments，Runtime 执行，再把结果塞回对话。工具目录由你写，JSON Schema 是入参契约，MCP 常常负责发现和执行。本站另一篇把这四层拆开了：

2026 AI Agent 技术栈：LLM、MCP、Function Calling、JSON Schema 如何组合？

Siri AI 的循环发生在系统里。用户对 Siri 说话，或指着屏幕上的「这个」。系统侧的模型（设备上，或 Private Cloud Compute）理解意图，再从设备上已安装 App 暴露的动作目录里选。你的 App 不是会话主人，只是被路由到的能力提供方。

对照 Siri AI（系统 Agent） 开放 Agent
谁跑模型 Apple（本机或 Private Cloud Compute） 你或第三方主机
工具目录 App Intents + App Schemas tools 数组或 MCP tools/list
参数形状 Swift 类型 + assistant schema JSON Schema
能不能发明 API 不能 只有你暴露了对应工具才行
跨 App 系统编排 你自己接线
JSON 出现在哪 perform() 之后，打 HTTP 时 几乎每一跳

所以答案不是「是」或「不是」。Siri AI 会编排、会填槽、会跨 App 连续做事，这已经是 Agent 行为。它不会变成一个你可以随便挂 MCP Server 的开放运行时。两条链都能碰到 App、API 和 JSON，但谁拥有会话、谁生成参数，并不一样。

Apple Intelligence 和 Siri AI 分别是什么

先把产品名拆开。混在一起，后面的 App Actions 和 JSON 就没有落点。

Apple Intelligence 是平台：把生成式模型嵌进 iPhone、iPad、Mac 的系统能力。写作、图像、通知摘要、Visual Intelligence，以及一部分要出设备的推理，都挂在这层。出设备的请求走 Private Cloud Compute，而不是普通公有云日志。官方入口见

Apple Intelligence。

Siri AI 是 2026 年 6 月 WWDC 发布的新一代 Siri，由下一代 Apple Intelligence 驱动。Apple 自己的表述是：更会对话、有个人上下文、有世界知识、能感知屏幕，并且能在系统范围调用更多 App Actions。同时多了一个独立的 Siri 应用，用来跨设备回看对话。新闻稿见

Apple 介绍 Siri AI。

开发者测试从 WWDC 当天开始，覆盖 iOS 27、iPadOS 27、macOS 27、visionOS 27。截至 2026 年 9 月初，它仍在秋季系统的测试周期里（8 月底已到 iOS 27 developer beta 8）。写这篇文章时，不要把它当成已经在所有用户设备上默认开启的成品。

还有第三条链，不要和 Siri 混：你的 App 里用 Foundation Models 自己起会话。那时模型在你的进程里跑，工具由你注入，系统不会替你选「打开哪个 App」。框架说明见

Foundation Models。

WWDC 2026 还把 Gemini 加进了可选用的外部基础模型，和此前的 ChatGPT 并列。这对用户是「问世界知识时多一个出口」，对开发者几乎不改变 App Actions 的契约：外部模型仍然碰不到你没声明的 Intent。

App Actions：Siri 怎么调用你的 App

用户听到的是 App Actions：Siri 能对这个 App 做什么。开发者落地的是 App Intents。要把动作交给 Siri AI 编排，还要按 App Schema（assistant schema）对齐，系统预训练模型才认得出「这是哪一类动作」。

Apple 在 WWDC26 的说法很直接：Siri 变强，靠的是 Apple Intelligence；开发者参与 Apple Intelligence 的方式，是 App Intents。会话

Build intelligent Siri experiences with App Schemas

把 Siri 的能力收成三件事：访问你的实体、通过 Intent 执行动作、理解屏幕上的上下文。

App Intents 是能力目录

对系统 Agent 来说，App 不是「打开看看」，而是一份可发现的能力目录。你用 AppIntent 声明动作名称、自然语言描述、参数类型和结果。Spotlight、快捷指令、Siri 和 Apple Intelligence 共用这套目录。用户说「把这张发票标成已付」，系统要映射到你的 MarkInvoicePaidIntent，而不是让模型在界面上乱点。

文档入口：

App Intents

以及

把 actions 接到 Siri 和 Apple Intelligence。

App Schemas 让 Siri 认得类别

普通 App Intent 已经能出现在快捷指令里。要让 Siri AI 用自然语言调用，还要把 Intent、Entity、Enum 标成某个 assistant schema，例如 photos.openAsset、notes.createNote。Schema 有固定的参数形状。Xcode 在编译期检查你有没有对上。

这就是和开放 Agent 最大的差别。开放 Agent 的工具名是你自己起的；Siri AI 的工具名要落进 Apple 预先训练过的领域词汇。你换一个更「创意」的动作名，系统可能根本选不中。

App Intent 对齐 assistant schema（示意，不是完整工程）
@AppIntent(schema: .finance.markInvoicePaid)
struct MarkInvoicePaidIntent: AppIntent {
    @Parameter var invoice: InvoiceEntity
    @Parameter var paidAt: Date

    func perform() async throws -> some IntentResult {
        try await InvoiceService.markPaid(
            id: invoice.id,
            paidAt: paidAt
        )
        return .result()
    }
}

上面这段里没有 JSON。Siri 交给你的是类型化参数。你在 perform() 里做业务。若要打网络，领域服务再编 JSON。

测试不要从 Siri 开始。Apple 提供 AppIntentsTesting，可以在隔离环境里调用 Intent、传入参数、断言结果。再放到快捷指令里看形状，最后才交给 Siri 做端到端。排障顺序反了，你会觉得「模型胡来」，其实是 schema 没对上。

一次跨 App 任务的数据流

用一个具体请求把层串起来。用户在信息里看到「周五聚餐，你带沙拉」，指着这段话对 Siri 说：记到备忘录，再在购物清单里加上生菜和橄榄油。

  1. 1
    屏幕上下文进系统

    Siri 通过 onscreen awareness 知道「这个」是一条消息。你的视图要能连到 App Entity，系统才能解析指代，而不是靠模型猜像素。

  2. 2
    模型只做计划和选型

    系统模型把话拆成两步：Notes 的创建动作，Shopping 的添加条目动作。它不拼 URL，也不写 SQL。

  3. 3
    按 Schema 填参数

    标题、日期、条目名称被收成类型值。缺槽时 Siri 会再问一句。这一步的契约是 assistant schema，不是你的 OpenAPI 文档。

  4. 4
    各 App 执行 perform()

    Notes 和 Shopping 各自跑自己的 Intent。需要同步到服务器时，这里才出现 HTTP JSON。

  5. 5
    结果回到系统会话

    Siri 用 Intent 的结果组织答复。跨 App 传递实体可以走 Transferable，而不是把整份 JSON 倒进对话。

开发者在这条链上最常踩的坑：把 Intent 写成「什么都干」的万能函数；description 写得太宽，模型遇事都调；或者在 perform() 里直接把整份订单 JSON 回传，撑爆系统上下文。更好的做法是返回摘要，细节用第二个动作按 id 再取。

JSON 在这条链上的三层角色

Swift 类型是编译期契约，JSON 是运行期契约。Siri 那一跳可以没有 JSON。动作一旦跨出当前进程——打后端、写文件、给测试夹具回放、给另一个 Agent 复用——形状就要变成语言无关的文本。

JSON 至少扮演三层角色。混用其中两层，就会出现「能 parse，但字段全错」。

层 JSON 在干什么 不该干什么
1. 动作参数的交换格式 把 Intent 参数写成可序列化对象，供日志、回放、服务端校验 把自然语言整段塞进一个 prompt 字段
2. HTTP API 的载荷 perform() 调用领域服务时的请求体和响应体 把系统 Intent 的内部类型名直接当 REST 路径
3. 给外部 Agent 的契约 同一套领域函数用 JSON Schema 暴露给 Function Calling 或 MCP 和 Siri 侧的 schema 各写一份、互不同步

第一层最容易被忽略。Xcode 的 App Intents Console 会打出调用和参数。你要能把同一次调用写成 JSON 对象，排障才有回放。第二层是账单和鉴权真正发生的地方。第三层是很多团队 2026 年已经在做的：同一个 markPaid，既给 Siri，也给公司内部的 Claude Agent。

JSON Schema 不替代 App Schema。App Schema 是给系统模型看的领域合同；JSON Schema 是给你的后端、测试和外部模型看的数据合同。两者字段应对齐，但不要幻想 Siri 会读取你的 OpenAPI 文件。为什么 AI 侧普遍需要这份契约，见

AI 为什么需要 JSON Schema？

和 Function Calling / MCP 比什么

对照只看一件事：决策被序列化成什么。

开放 Agent 里，模型 API 返回的是一段 JSON：选中的工具名，加上符合 parameters 的 arguments。Runtime 校验后再执行。MCP 再把同一份形状放到 inputSchema / structuredContent 上。细节见

AI Agent 为什么需要 JSON Schema？从 Tool Calling 到 Structured Output。

开放 Agent 侧：Function Calling 的工具声明（节选）
{
  "type": "function",
  "function": {
    "name": "mark_invoice_paid",
    "description": "Mark one invoice as paid.",
    "parameters": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string" },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  }
}

Siri AI 侧没有这份 JSON。等价物是 @AppIntent(schema:) 加上 @Parameter。模型仍然在「选动作、填槽」，只是序列化格式换成了系统内部的类型化调用。

因此不要把 App Intent 再包一层「让 Siri 输出 JSON」。多一层提示词不会让系统更稳，只会让排障失去类型检查。你要的稳定发生在 perform() 之后：领域服务接收到的对象，能否无损编码成上面那份 arguments。

选择也很具体。用户已经在苹果设备上、动作能收成系统目录，走 Siri AI。动作要给 Android、Web、内部 Slack 机器人复用，走 Function Calling 加 MCP。不要为了「我们也有 Agent」把两条链画成一张万能图。

接到 HTTP API 时 JSON 长什么样

Intent 要不要直接打网络？短动作可以在 perform() 里做完。一旦涉及鉴权、分页、幂等，perform() 只做「校验参数 + 调用领域服务」，领域服务再发 JSON 请求。

下面是一次「标记发票已付」落到后端时的载荷。字段名是内部计费系统的典型写法，数字是示例，不是某家银行的真实接口。

Siri 触发后，领域服务发给 API 的 JSON（示例）
{
  "action": "invoices.markPaid",
  "source": "siri-ai",
  "idempotency_key": "inv_1842:paid:2026-09-09",
  "arguments": {
    "invoice_id": "inv_1842",
    "paid_at": "2026-09-09T02:14:00Z",
    "currency": "USD",
    "amount_cents": 12800
  }
}

有了这个对象，你能回答三个问题：谁触发的、能不能重放、钱有没有对上。缺了 idempotency_key，Siri 重试一次就会标两次已付。amount_cents 变成字符串，后面的账都会漂。

同一份动作的 JSON Schema 草稿
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["action", "source", "idempotency_key", "arguments"],
  "properties": {
    "action": { "const": "invoices.markPaid" },
    "source": { "type": "string", "enum": ["siri-ai", "shortcuts", "app"] },
    "idempotency_key": { "type": "string", "minLength": 8 },
    "arguments": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string", "minLength": 1 },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

系统 Agent 不需要知道你的 REST 路径，它只需要 Intent 成功或失败。你需要知道路径，因为审计和重试都在 API 这一层。把 Intent 参数设计成「能写成 JSON 对象」的字段集，后面接开放 Agent 会省掉一整层适配。

用 JSONNote 校验 Action 参数

慢的部分很少在 Swift 宏。慢的是两次调用的 JSON 对不上：Siri 重试多了一个字段，快捷指令少了一个枚举，内部 Agent 把 amount_cents 写成了 128.00。JSONNote 在浏览器本地处理：

  1. 1
    先格式化一次调用

    把 App Intents Console 或后端日志里的对象贴进JSON 格式化，去掉缩进和语法噪音。

  2. 2
    用 Schema 钉死必填字段

    把上面的草稿贴到JSON Schema页，确认 action、idempotency_key、invoice_id 还在。

  3. 3
    对比 Siri 和开放 Agent 两次调用

    用JSON Diff看 source 是否从 siri-ai 换成了 mcp，以及 arguments 有没有漂。

  4. 4
    只在同事需要时分享

    用Hash 分享把样例（永远不要放密钥）放进 URL fragment。服务器收不到这段数据。

常见问题

Siri AI 就是 AI Agent 吗？

它是系统级 Agent，不是开放 Agent。能跨 App 选动作、填参数、串流程，但工具目录由 App Intents 和 App Schemas 钉死，模型不能自己发明 API。

App Actions 和 App Intents 是一回事吗？

不是一个产品名。App Actions 是用户和系统侧的说法：Siri 能对 App 做什么。开发者落地的是 App Intents，再按 App Schema 对齐，Siri 才认得出这类动作。

Siri 会直接打我的 REST API 吗？

不会。Siri 只调用你声明的 Intent。perform() 里再打自己的 HTTP。系统 Agent 要的是成功或失败语义，账单、鉴权和重试都在你的 API 层。

Apple 用 Swift 类型，为什么还要 JSON Schema？

Swift 类型管编译期。动作一旦离开进程——打后端、写日志、给测试回放、给外部 Agent 复用——形状就要变成语言无关的 JSON。Schema 校验的是这一跳，不是 Siri 那一跳。

该用 Siri AI，还是自己搭 Function Calling Agent？

用户已经在 iPhone 上、动作能收成系统目录，用 Siri AI。动作要跨云、跨平台、或要自己选模型，用 Function Calling 加 MCP。同一套领域函数可以同时服务两条链，只换适配层。

总结

Siri AI 会成为 Agent，但成为的是操作系统里的 Agent，不是你可以随便挂工具的开放 Runtime。

Apple Intelligence 提供模型，App Actions（App Intents + App Schemas）提供可编排的动作，JSON 是这些动作离开设备之后的契约。

先把 Intent 参数设计成能写成 JSON 对象的字段，再让 Siri 链和 Function Calling 链挂同一份 Schema。模型和系统入口还会变，校验层是从演示走到生产的护城河——这些 JSON 可以在 JSONNote 本地格式化、校验和对比，不必上传。

下一步

粘贴动作 Schema，校验参数 JSON 格式化 JSON Diff Hash 分享

相关文章

2026 AI Agent 技术栈：LLM、MCP、Function Calling、JSON Schema 如何组合？ AI 为什么需要 JSON Schema？Structured Output、Function Calling 与 JSON Schema 完整解析 AI Agent 为什么需要 JSON Schema？从 Tool Calling 到 Structured Output 完整解析

← 返回博客