裝置端 Foundation Models LLM：Tool 協定

類型： 前沿論述。本文點明 Apple 在 WWDC 2025 推出的裝置端 LLM 契約，並走過路由問題：何時該選擇 LanguageModelSession、何時該選擇 AppIntent、何時該選擇 MCP、何時三者皆非。

iOS 26 在每一台支援 Apple Intelligence 的裝置上都搭載了一個 30 億參數的語言模型。¹ Apple 將這個框架稱為 Foundation Models。框架在本機運行。推論針對 Apple silicon 進行最佳化並在裝置上執行；網路不在呼叫路徑上。模型存放在 SystemLanguageModel.default，您的應用程式取得一個 LanguageModelSession，而讓該 session 完成有用工作的型別化介面，就是 Tool 協定。

對應用程式開發者而言，Tool 協定才是真正重要的部分。沒有它，裝置端 LLM 不過是個沒有連接到您應用程式資料、使用者資料或系統其他部分的聊天補全端點。有了它，模型便能呼叫型別化的 Swift 函式、取得型別化的結果，並在下一輪推理中針對答案進行思考。工具增強的裝置端生成才是這個框架真正的能力。聊天介面只是 demo。

TL;DR

• Foundation Models 在每一台符合 Apple Intelligence 條件的裝置上，於 SystemLanguageModel.default 提供一個 30 億參數的 LLM。模型在本機；推論針對 Apple silicon 進行最佳化並在裝置上執行；網路不在呼叫路徑上。
• Tool 協定是模型與您應用程式之間的契約。一個工具宣告型別化的 Arguments、回傳型別化的 Output，並在建構時繫結到一個 LanguageModelSession。
• Generable 與 Guide 註解讓模型可直接產出型別化的 Swift 值，而非只是字串。解碼器是框架的一部分，不是您的程式碼。
• Foundation Models、App Intents 與 MCP 之間的路由規則是誰執行模型，又在哪裡執行。Foundation Models = 您的應用程式在裝置上執行模型。App Intents = Apple Intelligence 在裝置上執行模型並路由至您的應用程式。MCP = 由外部主機在任意位置執行模型，並透過工具伺服器伸入您的應用程式。

框架實際提供的內容

三個基本元件構成這個框架：模型、session 與工具。²

SystemLanguageModel。 對裝置端基礎模型的參考。預設實例與使用者裝置綁定，可在符合 Apple Intelligence 條件的硬體上使用，並提供能力檢查，讓應用程式於執行時讀取以判斷模型是否可用。框架支援透過 SystemLanguageModel(useCase:guardrails:)、自訂 adapter 與 GenerationOptions 進行配置，但您不能像在使用 OpenAI 或 Anthropic 時那樣任意挑選雲端模型 ID；Apple 會隨 OS 釋出版本配發並更新裝置端模型，框架交給您的就是當前安裝的版本。

LanguageModelSession。 一個跨呼叫保留對話狀態的有狀態物件。session 在建構時接收系統提示、隨時間累積使用者/助理輪次,並提供用於生成回應的非同步方法。建立 session 的成本低、可拋棄;每項任務建立一個 session,而非整個應用程式共用一個。冥想計時器為「總結我過去 7 天的練習」建立一個 session;食譜應用程式則為「將這份食譜改成兩人份而非四人份」建立另一個 session。

Tool(協定)。 一個 Swift 協定,宣告 Arguments 型別、Output 型別,以及一個非同步的 call(arguments:) 函式。工具在建構時繫結到 session(LanguageModelSession(tools: [...], instructions: ...))。當模型判斷需要使用工具時,會發出結構化的呼叫;框架解碼參數、執行工具、編碼結果,並將其回饋至 session 供下一輪使用。模型看不到 Swift;框架負責編組工作。

Tool 協定的精簡形貌如下:

import FoundationModels

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."

    @Generable
    struct Arguments {
        @Guide(description: "Start date in ISO-8601 format")
        let startDate: String

        @Guide(description: "End date in ISO-8601 format")
        let endDate: String
    }

    func call(arguments: Arguments) async throws -> ToolOutput {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        return ToolOutput(GeneratedContent(properties: [
            "count": entries.count,
            "total_ml": entries.reduce(0) { $0 + $1.amountMl }
        ]))
    }
}

模型看到的是工具描述和一個 JSON 形式的參數 schema。Swift 程式碼看到的是型別化的輸入與型別化的輸出。解碼/編碼這道邊界,正是 Apple 所負責的部分。

Generable 與 Guide:不需要解析器的型別化輸出

讓工具參數型別化的同一套註解系統,也讓模型可直接產出型別化的 Swift 值。³ 一個 @Generable 結構宣告其形狀;框架會限制模型輸出以符合該形狀。

@Generable
struct PracticeSummary {
    @Guide(description: "Single-sentence headline summarizing the user's week")
    let headline: String

    @Guide(description: "Total practice duration this week in minutes")
    let totalMinutes: Int

    @Guide(description: "Three short observations as bullet points")
    let observations: [String]
}

let session = LanguageModelSession(instructions: "You are a meditation coach.")
let summary = try await session.respond(
    to: "Summarize this week of practice given the entries.",
    generating: PracticeSummary.self
)

模型回傳的是 PracticeSummary 值。您的程式碼裡沒有 JSON 解析、沒有針對「headline:」的字串比對、也不需要在模型回傳格式錯誤物件時準備備援路徑。框架透過受限解碼,讓模型逐 token 的輸出在結構上始終與 schema 對齊,因此結構不合法的輸出不會越過邊界。

Swift 型別化介面正是此框架與雲端 LLM SDK 之間的差異所在。雲端 SDK(OpenAI Structured Outputs、Anthropic tool use 等)同樣支援受限解碼,但開發者收到的型別化值是一個經 schema 驗證的 JSON 物件,接著再以另一步驟解碼為 Codable 的 Swift 型別。Foundation Models 將這些步驟合而為一:@Generable 巨集與框架的解碼器直接回傳型別化的 Swift 值,而每個欄位上的 @Guide 註解則將意圖帶入生成限制。輸出之所以是型別化的,是因為生成本身就針對 Swift schema 進行型別約束,而不是針對開發者在 Swift 中重建的 JSON 規格。

@Guide 註解是您將每個欄位的意圖傳達給模型、又不必寫進提示詞中的方式。生成的描述會成為生成限制的一部分。欄位層級的 guide 讓提示詞保持簡潔,讓 schema 緊貼資料。

路由問題的三種解法

Apple 現在提供了三種協定介面,讓應用程式向語言模型開放自身領域。它們各自路由到不同的執行者。

Foundation Models(LanguageModelSession)。 您的應用程式載入裝置端模型並執行推論。session 可呼叫的工具,是您應用程式程式碼中所定義的工具。模型從不離開裝置。使用者不會透過 Siri 啟動;啟動者是您應用程式的程式碼。其使用情境發生在應用程式之內:冥想 app 用 LLM 總結一週、食譜 app 將食譜改成更少份數、飲水追蹤 app 把「我午餐配了一杯水」轉換為結構化記錄。

App Intents。 Apple Intelligence 代表使用者運行 LLM(Apple 的第一方 agent),並將能力呼叫路由到您應用程式的 AppIntent 型別。您的應用程式不執行模型。您透過 App Intents 框架宣告型別化動作,Apple 的系統堆疊則根據使用者請求、Spotlight 查詢、Siri 輸入或 Shortcuts 編排,決定何時呼叫這些動作。詳細內容請見 App Intents 是 Apple 通往您 App 的新 API。⁴

MCP。 由外部主機(Claude Desktop、Claude Code、Cursor、ChatGPT)執行開發者所選擇的任一模型。您的應用程式對外開放一個伺服器,讓主機的模型可以呼叫。模型運行於主機的所在位置;工具呼叫跨越 JSON-RPC 傳輸層。詳細內容請見 兩個 Agent 生態系,一份共用購物清單,以及 App Intents vs MCP 中的路由問題綜合分析。⁵

路由決策可歸結為誰才是 agent。

                  ┌──────────────────────────────────┐
                  │  Who is the language model?       │
                  └────┬─────────────┬─────────────┬──┘
                       │             │             │
              ┌────────┴────┐ ┌──────┴──────┐ ┌────┴──────┐
              │ Your app's  │ │   Apple     │ │  External │
              │ own use of  │ │ Intelligence│ │   host's  │
              │   LLM       │ │   agent     │ │   agent   │
              └──────┬──────┘ └──────┬──────┘ └────┬──────┘
                     │               │             │
                     ▼               ▼             ▼
              Foundation Models  App Intents     MCP
              + Tool protocol   + AppEntity    + tools/list
              (on-device, your  (system runs   (host runs
               app runs model)   the model)     the model)

冥想 app 在總結使用者一週的練習時會選用 Foundation Models,因為應用程式本身就想呼叫模型,並在 app 內呈現結果。同一個 app 的「記錄一段 5 分鐘的冥想」能力則使用 App Intents,讓 Siri 可以呼叫。同一個 app 的「顯示我最近的冥想紀錄」能力,若由 Claude Code session 使用,則採用 MCP。三種不同的執行者、三種不同的責任歸屬,底層共用一套領域層。

推論預算:框架對您的要求

在裝置上跑 LLM 並非無償。Apple silicon 負責推論,但模型仍有其上下文視窗、token 預算,以及取決於裝置的牆鐘延遲。三項限制決定了您如何使用此框架進行設計:⁶

可用性因裝置而異。 並非每一台 iOS 26 裝置都支援 Apple Intelligence。較舊的 iPhone、受限制的裝置,以及使用者已停用 Apple Intelligence 的裝置,會在 SystemLanguageModel.default.availability 回傳不可用狀態。沒有檢查可用性就直接呼叫 LanguageModelSession 的程式碼,會在執行時拋出生成錯誤;正確做法是事先依可用性狀態分支 UI,在不可用時提供一條無 LLM 的路徑。把模型當作功能旗標看待,而非保證可用。

延遲並非微不足道。 iPhone 16 Pro 的首 token 延遲對 app 內互動來說堪用;較長的生成內容與工具呼叫鏈則並非即時。適用於雲端 LLM 串流的 UI 模式在這裡同樣適用;不要阻塞主執行緒,要呈現漸進式輸出,並為使用者中途離開頁面的情境進行設計。

上下文視窗比雲端更小。 裝置端模型的上下文視窗比 GPT-4 等級的雲端模型更小。長文件需要摘要或切塊處理。長對話歷史需要修剪。回傳大型結構化負載的工具輸出,應只回傳一個參考(ID 或 key),讓下一輪需要時再重新取得,而非把整份負載塞進 inline。

整體限制較接近為低階邊緣執行環境設計,而非為前沿雲端模型設計。框架的便利性讓體驗更愉悅;但底層的物理限制並未因此消失。

何時該選擇 Foundation Models

此框架最適合的情境,是裝置端、低摩擦生成本身就是產品的時候:

重新格式化與改寫。 把使用者的自由格式筆記轉換為結構化記錄、潤飾草稿訊息、總結擷取下來的逐字稿。對延遲容忍度中等;資料敏感度高;雲端推論在此屬於殺雞用牛刀。

對私人資料進行本地綜合。 健身 app 將使用者的訓練歷史轉化為「本週」摘要;理財 app 解釋使用者的消費模式;日誌 app 在一季的記錄中梳理出主題。資料不應離開裝置;答案應該在 app 內呈現;提示詞範圍有界。

輕量級的 app 內自動化工具呼叫。 一個讓使用者說「顯示週二的冥想記錄」的 app,透過工具取得底層紀錄並格式化答案。agent 是 app 本身,工具是 app 自己的資料層,模型在本機。

型別一致的生成。 凡是 app 原本得手寫 JSON 解析器或字串模板的地方,@Generable 加上 @Guide 都是更耐用的選擇。

何時不該選擇 Foundation Models

下列幾種常見情境,框架並非正確答案:

任何使用者可能會問 Siri 的事情。 「記錄 250ml 的飲水」、「開始 5 分鐘的冥想」、「把香蕉加到我的清單」 屬於 App Intents。Apple Intelligence 是執行者;您的應用程式是目的地。Foundation Models 服務的是 app 內的生成,而非 Siri 路由的動作。如果同一項能力被實作了兩次(App Intent + 帶工具的 LanguageModelSession),那麼 App Intent 會勝出,因為使用者啟動的是 Siri,不是您 app 內的畫面。

任何應由外部 LLM agent 驅動的事情。 Claude Code session 伸入您應用程式領域的情境,屬於 MCP 的範疇。應用程式不執行 LLM;主機才執行;模型存在主機所放置的地方。Foundation Models 無法服務外部 agent。

對大型文件的繁重推理。 裝置端模型體積較小。一份 200 頁的合約、一個冗長的程式碼脈絡,或在多張照片上進行的多模態推理,都應交給雲端推論(您自家的或廠商的),那裡的上下文視窗與參數量才符合工作負載。超出框架信封的任務會產生具體錯誤:超出上下文視窗、護欄違規、不支援的語系。請刻意把這些錯誤呈現出來,而不是設計依賴模型處理超出信封工作的流程。

跨裝置與跨使用者的工作流程。 裝置端模型只能存取應用程式傳入 session 的內容。跨裝置同步(從 Watch 到 iPhone 的計時器狀態)、跨使用者協作(共用清單、共用文件),以及任何受惠於伺服器端協調的流程,都需要伺服器。模型不是網路原語。

我會在自己的技術堆疊裡換個方式來建構

此框架獎勵一項在初版設計時很容易做錯的特定架構選擇:使用者透過 app UI 啟動的能力,以及 LLM 應該以工具形式取用的能力,不該成為兩條重複的散文式路徑。

冥想 app 可能會新增一個由 LLM 摘要的「每週回顧」面板。最直白的做法是一條提示詞:「以下是使用者本週的記錄,寫一段話。」更好的做法是定義一個 WeeklyEntries 工具,讓模型在需要知道一週內容時呼叫,並透過 @Generable 提供結構化的 WeeklySummary 輸出。第一種做法很脆弱(模型每次呼叫都得吞下冗長的記錄列表),token 成本高,輸出的也是非結構化散文。第二種做法則耐用(工具呼叫把「發生了什麼」與「該怎麼說它」分開)、便宜(模型只取它需要的部分),且結構化(結果是型別化的 Swift 值)。

這個模式可與 App Intents 和 MCP 乾淨地組合。同一個 WeeklyEntries 查詢,也是某個 AppIntent 參數解析器與某個 MCP 工具處理器的本體。一個 Swift 函式;三個介面。模型呼叫的是與使用者呼叫的同一個函式。

另一項架構決策:工具描述是提示詞的一部分。模型會閱讀 Tool.description 來決定是否呼叫、何時呼叫。請把描述當成您真心希望未來的協作者去讀的 docstring;而模型,正是那位未來的協作者。

此模式對 iOS 26+ Apple 技術堆疊的意義

三個重點。

1. 裝置端 LLM 是一項執行階段功能,而非後端服務。 把它當成具有上下文視窗與裝置端推論預算的系統框架,而不是遠端服務。架構決策聚焦於可用性、延遲、上下文視窗紀律,以及結構化輸出。

2. Tool 協定就是介面。 沒有工具,模型只是個與您領域毫無連結的聊天補全端點。有了工具,模型就成為您應用程式資料之上的結構化查詢層。

3. Foundation Models、App Intents 與 MCP 之間的路由規則是「誰執行模型」。 App 內的生成交給 Foundation Models。Apple Intelligence 路由的能力交給 App Intents。外部 agent 的能力交給 MCP。同一個 Swift 領域函式可以被這三個介面共同呼叫。

完整的 Apple 生態系叢集:供 Apple Intelligence 使用的型別化 App Intents;供跨 LLM agent 使用的 MCP 伺服器;兩者之間的路由問題;用於鎖定畫面狀態機的 Live Activities;打造視覺層的 Liquid Glass 模式;實現跨裝置觸達的多平台發佈。系列總入口請見 Apple 生態系列。若想了解更廣泛的 iOS 與 AI agent 脈絡,請見 iOS Agent 開發指南。

FAQ

iOS 26 中的 Foundation Models 框架是什麼?

Foundation Models 是 Apple 提供的框架,用於存取 iOS 26(以及 iPadOS 26、macOS 26、visionOS 26)中,符合 Apple Intelligence 條件的裝置所搭載的裝置端語言模型。框架公開了 SystemLanguageModel、LanguageModelSession 與 Tool 協定,讓應用程式無需網路存取,即可進行型別化的裝置端 LLM 呼叫。

Tool 協定如何運作?

Tool 是一個 Swift 型別,宣告一個 Arguments 結構(以 @Generable 與 @Guide 註解)、一個非同步的 call(arguments:) 方法,以及供模型決定何時呼叫所用的 name 與 description。工具在建構時繫結到 LanguageModelSession。當模型判斷需要使用工具時,框架會解碼參數、執行呼叫,並把型別化的輸出回饋到 session。

Foundation Models、App Intents 與 MCP 之間有什麼差別?

Foundation Models 用於您的應用程式在裝置上執行 LLM 以進行 app 內生成。App Intents 則供 Apple Intelligence(系統 agent)呼叫您應用程式的型別化能力。MCP 則供外部 LLM 主機(Claude、ChatGPT 等)透過 JSON-RPC 傳輸呼叫您應用程式的型別化工具。三個協定的差異在於誰執行模型。同一個 Swift 領域函式可同時服務這三者。

Foundation Models 可以呼叫 MCP 工具嗎?

不行。LanguageModelSession.tools 僅接受符合 Apple Tool 協定的型別,而非 MCP 工具伺服器。若要橋接兩者,您可以撰寫一個 Foundation Models Tool,讓它的 call 方法呼叫 MCP 用戶端。Apple 並未提供內建轉接層;這座橋必須由 app 端的程式碼搭起。

裝置端模型的能力足以投入正式環境嗎?

針對此框架所設計的使用情境(重新格式化、摘要、針對本地資料的結構化生成、輕量工具呼叫)而言,是的。針對在大型上下文中進行前沿推理、大規模多模態理解,或跨文件推理而言,則不是。裝置端模型是一個 30 億參數的模型,上下文視窗也比雲端 LLM 更小;請挑選符合此信封大小的工作負載。

參考資料