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 / 缺字段 / 錯誤枚舉。模型商標會變，動作形狀不該跟着變。