App Intents 與 MCP：路由該怎麼分

App Intents 與 MCP 這兩種協定，都能讓外部代理程式操作一個應用程式的領域能力。但兩者並不會併成一個。真正的問題是：哪項能力該走哪條路，以及為什麼每種協定對自己的呼叫方而言都是正確答案。

Apple 推出 App Intents，是為了給 Apple Intelligence 一個型別化的宣告式介面，讓它不必碰到使用者介面就能操作第三方應用程式。¹ Anthropic 推出 Model Context Protocol，是為了給任何 LLM 一個型別化、由伺服器居中的介面，讓它不必碰到使用者介面就能操作任何工具。² 形狀相似，呼叫方卻不同。把兩者當成同一個介面看待，只會得到一套兩頭都不討好的架構。

本系列前兩篇文章分別單獨談了這兩種協定：App Intents 見〈App Intents 是 Apple 通往你的應用程式的新 API〉，MCP 見〈兩套代理程式生態，一份購物清單〉。這一篇談的是路由問題。一項能力什麼時候該做成 AppIntent，什麼時候該做成 MCP 工具，什麼時候兩者都要，又有哪些只該留在應用程式內部？

TL;DR

• App Intents 是通往 Apple Intelligence、Siri、Shortcuts 以及系統建議堆疊的唯一路徑。系統從安裝那一刻起、並透過應用程式更新讓它們持續可用，App Shortcuts 的 donation 與索引則把它們帶到 Spotlight 與 Siri 建議之中。
• MCP 工具是通往所有非 Apple 大型語言模型（Claude、ChatGPT、Gemini、本機模型）的路徑。傳輸方式為 stdio 或 Streamable HTTP，.mcpb 則是一種封裝格式，通常內含一個本機 stdio 伺服器；主機在工作階段開始時載入工具。目前的規格修訂版是 2025-11-25，2026-07-28 的候選發行版則圍繞無狀態核心重寫了這套協定⁶⁷。
• 兩種協定在型別化 schema、entity → action → result 的形狀以及參數解析上是一致的。分歧出現在身分、持續性、延遲與渲染介面上。
• 路由規則是這樣的：如果使用者可能會問 Siri 或從 Spotlight 喚起這項能力，就用 App Intents。如果開發者可能把它接進 Claude Code 的工作階段或外部代理程式的執行流程，就用 MCP。多數應用程式對同一套領域能力兩者都需要。

兩種協定，同一種形狀

兩種協定所定義的，都是外部呼叫方與應用程式領域之間的操作契約。契約由三個部分組成：schema（呼叫方能要求什麼）、解析器（應用程式如何找到 schema 所指的實體），以及動作（執行什麼、回傳什麼）。

App Intents 用 Swift 表達這份契約。協定介面是 AppIntent、AppEntity、AppEnum，由 @Parameter 巨集驅動 schema，func perform() 回傳結果。³ schema 在編譯期產生，隨安裝一併封裝進應用程式。Apple Intelligence、Siri、Shortcuts 與 Spotlight 讀的是同一份 schema，並把型別化的請求送進同一個 perform() 進入點。

MCP 用 stdio 或 Streamable HTTP 之上的 JSON-RPC 表達這份契約。協定介面是 tools/list 與 tools/call 兩個方法，每個工具宣告名稱、描述與 inputSchema（2025-06-18 規格為結構化回傳值加入了選用的 outputSchema，2025-11-25 修訂版把 JSON Schema 2020-12 確立為預設方言，加入作為中繼資料的工具圖示，並把治理結構正式化到 Anthropic 之外）。⁴⁶ MCP 主機（Claude Desktop、Claude Code、Cursor、ChatGPT 桌面應用程式）在工作階段開始時發現工具，並以 JSON 酬載按名稱呼叫。跑模型的是主機，跑工具的是伺服器。這套協定本身也正處於過渡期：2026-07-28 的候選發行版把 MCP 重建在一個能跑在一般 HTTP 基礎設施上的無狀態核心之上，把長時間執行的工作移進 Tasks 擴充，並透過 MCP Apps 加入了伺服器端渲染的介面⁷。下文關於路由的論證在這次修訂之後依然成立，因為其中沒有任何一點改變了呼叫方是誰。

形狀是一樣的：schema、解析器、動作。差別在於每一部分由誰執行，以及信任邊界落在哪裡。App Intents 跑在應用程式行程內、使用者的裝置上、應用程式自身的授權之下，呼叫路由由系統居中。MCP 伺服器跑在開發者選定的地方（本機 stdio、代管 HTTP、內嵌套件），而跨越一組沒有邊界的工具集合的呼叫路由，則由主機端的大型語言模型居中。

還有第三個形狀相同的呼叫方值得一提，它讓整幅圖像完整起來：Apple Foundation Models 框架背後的裝置端模型，透過 Tool 協定呼叫應用程式的程式碼，同樣是一項有名稱、有描述、有型別的能力。一個形狀良好的領域層，能在不知道是誰在呼叫的情況下同時餵養這三個介面。

兩種協定的分歧所在

除了表層形狀之外，還有四項運作層面的差異會左右路由。

身分與持續性。 App Intents 說的是 AppEntity 型別，系統可以儲存、呈現它，並在日後重新解析。我今天透過嘿 Siri，在 Water 裡記錄 250ml 所存下的一筆飲水記錄，能跨重新開機留存，在使用者的 iCloud 裝置之間同步，日後還能被其他意圖引用（給我看昨天的飲水記錄）。系統會在這些呼叫之間追蹤實體 ID，³ 而 iOS 27 把這個故事延伸到硬體之間：遵循 SyncableEntity 的實體會帶著一個在使用者各裝置間保持一致的識別碼，於是 Siri 能把關於同一個物件的對話從 iPhone 交給 Mac，再交給 Watch。⁸ MCP 本身也是一種帶生命週期管理的具狀態協定，Streamable HTTP 支援以工作階段 ID 維持連線的連續性；但持久的領域身分屬於伺服器自己的職責，協定層面並沒有一個能與 AppEntity 識別碼相提並論、可讓主機端模型跨工作階段倚賴的東西。MCP 提供 resources 來承載持久的參考資料，2025-11-25 規格又加入了用於追蹤持久請求的實驗性 tasks，但領域物件的身分仍是伺服器端的責任，而不是一等的協定契約。⁴⁶ 底層的紀律，與應用程式自身資料層適用的那一條相同：使用能活過行程生命週期的穩定識別碼，SwiftData 的部分見〈schema 紀律〉。

延遲與電力。 App Intent 的 perform() 主體在裝置上的應用程式或應用程式擴充功能的環境中執行。若有網路存取，也來自應用程式自身的程式碼，或外圍的 Apple Intelligence／Siri 層，而非意圖契約本身。一個型別化的裝置端動作回傳一個型別化的結果，在常見情形下很快。MCP 工具即使是本機的，也要經過 stdio 的 JSON-RPC 分框並跨過一道獨立的行程邊界，遠端 MCP 工具還要付出 HTTP 往返的代價。延遲預算並不相同。一個記錄 250ml 的 App Intent 可以在 Siri 一輪對答的視窗內完成；一個遠端 MCP 工具卻可能成為 Claude Code 工作階段的瓶頸。

渲染介面。 App Intents 回傳的結果由 Apple Intelligence 渲染進系統介面：鎖定畫面橫幅、Siri 回應、Shortcuts 輸出、Spotlight 結果。應用程式無法控制結果如何呈現。MCP 工具回傳的是內容區塊（文字、影像、音訊、內嵌資源或結構化內容），由主機端模型讀取後決定怎麼呈現。一個 Claude Code 工作階段可能把結果原樣引述給開發者，也可能做摘要，或者把它餵進下一次呼叫。渲染的決定權落在模型這一層。

可發現性。 Apple Intelligence 從安裝那一刻起就讓 App Intents 可用，App Shortcuts 的 donation 與索引會依使用者行為把意圖帶進 Spotlight 搜尋與 Siri 建議；應用程式更新與動態實體則讓這個介面隨時間調整。使用者從來不必鍵入工具名稱。MCP 主機在工作階段開始時讀取工具，模型能看到哪些工具則由使用者（或系統提示）決定。發現在 MCP 這一側是明確的設定，在 App Intents 那一側則是隱含的系統推論。

兩種協定在身分、延遲、渲染與發現這四項性質上分歧，而這四項都源自同一個根本差別：App Intents 服務的是一個使用者不曾設定過的系統層級代理程式，MCP 服務的是一個開發者設定出來的工作階段層級代理程式。呼叫方不同，義務也不同。

路由規則

一個同時具備兩種協定的應用程式，其能力地圖看起來是這樣：

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

路由規則是依序要問的三個問題。

這項能力是使用者會去問 Siri、或從 Shortcuts 呼叫的嗎？ 如果是，這項能力就需要一個 App Intent。記錄 250 毫升的水、開始一次冥想、把香蕉加進我的清單、我昨天體重多少都屬於意圖，因為使用者可能會把它們說出口、打進 Spotlight，或在 Shortcuts 裡串起來。對這類能力而言，App Intent 不是選項——沒有別的途徑能讓你抵達 Apple Intelligence 的第一方代理程式介面。

這項能力應該讓外部代理程式能夠驅動嗎？ 如果是，這項能力就需要一個 MCP 工具。從 Claude Code 工作階段往購物清單加一項、把 Get Bananas 的狀態讀進 Cursor 代理程式的脈絡、從遠端一個會用工具的 LLM 觸發工作流程都屬於 MCP 工具，因為呼叫方不是 Apple Intelligence，而是開發者接上的那個大型語言模型。MCP 工具可以包裝 App Intent 所呼叫的同一個領域層 Swift 函式，但協定介面是開發者選定傳輸方式之上的 JSON-RPC。

這項能力是否需要帶著系統已知的穩定身分，活過單一工作階段？ 如果是，App Intent 這條路天然合適，因為系統免費給了你 AppEntity 身分、查詢支援與持續性語意。如果不是，MCP 工具可以回傳一個內容區塊，把持久身分交給伺服器自行斟酌，並省下建模實體的成本。

多數不那麼簡單的應用程式能力都落在兩者皆需那一欄。Water 裡的飲水記錄能力既有 AppIntent（好讓 Siri 接下口述），也有 MCP 工具（好讓 Claude Code 工作階段從匯出的記錄回填資料）。兩條路徑共用一個 Swift 函式，而這個函式並不知道是哪個呼叫方觸發了它。⁵

落到程式碼上，形狀就是一個領域方法，加上兩個都呼叫它的轉接器包裝：

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

兩個轉接器看起來不一樣，是因為它們的呼叫方不一樣。它們呼叫的函式是同一個。

哪些能力該留在應用程式裡

有一小群但很重要的能力，應當只留給應用程式自己。把它們交給任何一種協定都是錯的。

使用者介面狀態類的能力。 「打開第三個分頁」「捲到最底」「把這一列標示起來」不是領域操作，而是互動的基本元素。App Intents 透過 OpensIntent 與 Shortcuts 在某種程度上支援這類事情，但類型上並不契合；使用者通常想要的是一個結果，而不是一次導覽。MCP 對介面導覽的支援更差：模型驅動的不是畫面，而是工具。

必須有人的身體在迴路裡的能力。 拍照、生物辨識驗證、敏感個資輸入，以及任何需要使用者看著畫面並點按的流程。Apple 的 CameraCaptureIntent 是為相機流程而存在的，但其設計意圖是啟動一個前景拍攝活動，而不是把背景相機存取權交給代理程式。對兩種協定都成立的誠實規則是：相機、生物辨識與敏感輸入流程，應當以帶有明確使用者確認的前景介面來執行，而不是作為靜默的意圖呼叫或工具呼叫。請把這些能力留在應用程式介面之後，讓代理程式把使用者引到畫面前，而不是替他穿過畫面。

長時間執行的背景工作。 兩種協定在這裡都長出了真正的基本元素，於是判斷也從「絕不」變成了「藉助協定自身的機制，刻意去做」。在 Apple 這一側，iOS 27 的 LongRunningIntent 讓意圖能突破系統 30 秒的背景限制，條件是它必須回報進度（這個協定細化自 ProgressReportingIntent），進度則由 Live Activities 渲染⁸。在 MCP 這一側，2025-11-25 規格加入了面向持久請求的實驗性 tasks，支援輪詢與延後取回結果，並在 2026-07-28 候選發行版中升格為 Tasks 擴充⁶⁷。如今誠實的界線是：當呼叫方自己發起了這項工作、並期待看著它完成時，就使用這些基本元素；當消費端需要的「進度」比一個百分比更豐富，或者主機端模型會在等待中讓推論鏈逾時時，就把工作留在應用程式自己的介面之後。對任何開放式的工作而言，請求已排入佇列，這是狀態畫面仍然是正確的回傳值。

任何觸及他人資料的操作。 兩種協定的信任邊界都是發出呼叫的代理程式。Apple Intelligence 跑在使用者的 iCloud 帳號之下，MCP 跑在開發者接上的那組憑證之下。跨使用者的操作（分享、多帳號存取、管理者動作）透過任何一種協定都不安全，因為呼叫端的身分並不是正確的身分。

如果重做，我會怎麼做

知道了上面的路由規則之後，我會用現在設計服務邊界 API 的方式，來設計 Swift 應用程式的領域層：領域方法接受型別化的輸入、回傳型別化的輸出，不把任何協定假設寫死進去。App Intents 用 @Parameter schema 與 perform() 的黏合程式碼，薄薄地包一層領域方法。MCP 工具用 JSON schema 與 stdio 分框，薄薄地包同一批領域方法。兩種協定都是薄轉接器，功夫都在領域層。

由此有兩個推論。

呼叫方身分是領域層的事，不是協定層的事。 App Intent 的主體收到的是系統解析好的參數，並跑在使用者已走完系統意圖喚起流程的脈絡裡。MCP 工具的主體收到的是主機備妥的任何憑證。兩者都以一個明確的 caller 引數往下傳給領域方法，由領域方法來落實授權、確認提示，以及其他領域不變條件。任何一種協定都無權假裝呼叫方就是使用者。

兩個轉接器所呈現的，是同一組可供性。 哪些能力要開放給哪一類呼叫方，這個決定寫在兩份清單裡，而不是散落在協定程式碼中。新增一項能力，就是一個領域方法、兩個轉接器包裝、兩筆清單條目；移除一項能力同樣對稱。上面那張矩陣圖會變成一個真實存在的檔案。

未來幾年 Apple 平台的前沿，不在於二選一，而在於把兩者視為在同一個領域層上組合的正交契約。Apple Intelligence 的代理程式對使用者負有一組義務（在裝置端執行、用 Siri 說話、透過系統渲染）。外部大型語言模型的代理程式對開發者負有另一組義務（在任何地方執行、用 JSON-RPC 說話、透過開發者選定的模型渲染）。兩者都值得擁有一個通往你應用程式的型別化介面，而兩者都不該成為唯一的介面。

什麼時候不該兩個都做

這個論證是雙向的。有些應用程式只需要其中一種協定，不需要另一種。

沒有開發者面向的純消費型工具。 手電筒。鳥鳴辨識程式。擴增實境的捲尺。使用者或許想透過 Siri 喚起它（App Intents 有用），但沒有開發者會把它接進 LLM 的工作流程（MCP 只是裝點門面）。

沒有終端使用者面向的純開發者工具。 一個程式碼格式化的 MCP 伺服器。一個儲存庫搜尋工具。一個套件版本檢查器。這裡的使用者就是 Claude Code 工作階段裡的開發者，Siri 與 Apple Intelligence 沒有用武之地。

兩類代理程式都服務不好的應用程式。 高度互動的遊戲、即時多人應用程式，以及價值就在於讓人留在程式內、盯著畫面的應用程式。兩種協定都不合適，正確答案是做一個出色的應用程式，不簽任何代理程式契約。

要決定的不是預設做一個還是兩個，而是這個應用程式是為了什麼而做，還有誰可能想操作它的領域能力。答案可能是都不做、只做一個，或者兩個都做。只要領域層形狀良好，做一個的成本很小；在同一個領域層之上再做另一個，成本同樣很小。真正昂貴的，是在使用情境明確需要時卻不做——那意味著這項能力在那個代理程式介面上徹底缺席。

這套模式對 iOS 26 以後的 Apple 技術堆疊意味著什麼

兩點收穫。

1. 把 App Intents 與 MCP 當成同一個領域之上的正交契約，而不是彼此競爭的協定。 Apple Intelligence、Siri、Shortcuts 與 Spotlight 是一類帶著系統層級義務的呼叫方；Claude、Cursor、ChatGPT 與其餘則是第二類帶著工作階段層級義務的呼叫方。兩者都值得擁有型別化的存取方式，而它們之下的領域層並不因此改變。

2. 路由規則看的是誰在呼叫，而不是執行的是什麼。 App Intent 與 MCP 工具可以呼叫同一個 Swift 函式。它們的差別在於呼叫方所承擔的義務、拿回去的渲染方式，以及對持續性的預期。把函式做對，讓協定層保持輕薄。

完整的 Apple Ecosystem 系列是這樣的：面向 Apple Intelligence 的型別化 App Intents、面向跨模型代理程式的 MCP 伺服器、面向鎖定畫面狀態機的 Live Activities、面向視覺層的 Liquid Glass 模式，以及面向跨裝置觸及的多平台發行。系列首頁在 Apple Ecosystem 系列。若想了解 iOS 與 AI 代理程式更寬廣的脈絡，請參閱 iOS 代理程式開發指南。

常見問題

同一項能力，我該做 App Intent 還是 MCP 工具？

如果這項能力應當抵達 Apple Intelligence、Siri、Shortcuts 或 Spotlight，就做 App Intent。如果它應當抵達外部的大型語言模型（Claude、ChatGPT，以及 Claude Code 或 Cursor 裡的代理程式），就做 MCP 工具。對於兩類呼叫方都該服務的領域能力，就在一個共用的 Swift 領域方法之上，把兩者都做成薄轉接器。

App Intents 與 MCP 伺服器彼此競爭嗎？

不。App Intents 是通往 Apple 第一方代理程式堆疊的路徑，MCP 是通往其他所有大型語言模型的路徑。Apple Intelligence 不會呼叫 MCP 工具，外部的大型語言模型代理程式也無法直接喚起 App Intents（它們要經過系統）。兩種協定服務的是不同類別的呼叫方，帶著不同的信任模型、不同的延遲預算與不同的渲染介面。

一個應用程式可以透過兩種協定同時開放它的領域能力嗎？

可以，而且多數想要完整代理程式觸及範圍的複雜應用程式都該這麼做。Get Bananas（見 MCP 伺服器那一篇）與 Water（見 App Intents 那一篇）就是早期的例子。模式是：下面一個領域層，上面並排放 App Intent 轉接器與 MCP 工具轉接器。兩個轉接器呼叫的是同一批 Swift 函式。

Apple Intelligence 會追蹤、而 MCP 不會追蹤的狀態是什麼？

Apple Intelligence 會跨呼叫、跨工作階段、跨重新開機追蹤 AppEntity 身分，藉助 iOS 27 的 SyncableEntity 還能跨使用者的各台裝置追蹤⁸。實體模型給了系統持久的參照，使用者可以據此把多個意圖串起來。MCP 本身是一種帶生命週期管理的具狀態協定，Streamable HTTP 中也有工作階段 ID，但持久的領域身分是伺服器端的責任，而不是一等的協定契約；主機端模型無法從協定介面拿到與 AppEntity 等價的識別碼。MCP 的 resources 概念與 2025-11-25 規格的實驗性 tasks，分別支撐持久的參考資料與持久的請求，但兩者都運作在伺服器自己擁有的那一層⁶。

有沒有哪些能力兩種協定都不該開放？

有。使用者介面狀態類的能力（打開這個分頁、捲到這裡）、必須有人的身體在迴路裡的能力（拍照、生物辨識驗證、敏感輸入），以及跨多位使用者資料的操作，都該留在應用程式介面之後——兩種協定都沒有攜帶跨使用者安全操作所需的信任訊號。長時間執行的背景工作是那個已經挪動了的例外：iOS 27 的 LongRunningIntent 與 MCP 的 tasks 擴充如今給了它真正的基本元素，所以請透過這套機制刻意地開放，只把開放式、比進度條更豐富的工作留在你自己的介面之後。

參考資料