博客 • 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 完整解析

← 返回博客