先別急著問它能拿來做什麼。先看一件乍看不合理的事：Apple 自己的 AI 框架，居然能拿來跑 Anthropic 的 Claude。

兩家公司、兩套東西，照理說井水不犯河水。可是 WWDC 2026 之後，你在 iOS app 裡寫的那段呼叫 AI 的程式碼——本來是驅動 Apple 裝置上那顆小模型的——只要改一行，底層跑的就變成 Claude，而且 respond(to:)、streaming、工具呼叫，整套用法一個字都不用改。這怎麼可能？

搞懂這個「怎麼可能」，比記住怎麼裝套件有用一百倍。因為它背後那招，根本不是 iOS 專屬的魔法，是一個你寫任何系統都用得上的老智慧。

先看它收到一個請求之後，第一件事去問誰

把框架打開，最核心的一個東西叫 LanguageModelSession。你跟 AI 講話，都是透過它：

1
2
3
let session = LanguageModelSession(model: someModel)
let response = try await session.respond(to: "幫我想一個送科幻迷的禮物")
print(response.content)

注意那個 model 參數。session 自己其實不知道、也不在乎背後那台模型是誰。它只認一件事：你給它的這個 model，有沒有照規矩來。

這個「規矩」在 Apple 的框架裡叫 LanguageModel protocol——你可以想成一份插座規格書。它白紙黑字寫死：一個能被 session 驅動的模型，必須會回應 respond、必須支援串流、必須能處理工具呼叫……把該有的孔位都列清楚。至於你是哪牌的電器、裡面怎麼發電的，規格書一概不管。

Apple 裝置上那顆 on-device 小模型，符合這份規格。然後 Anthropic 做了一個叫 ClaudeForFoundationModels 的 Swift 套件，做的事就一件——讓 Claude 也符合這份規格。它把 Claude API 包了一層，對外長出 protocol 要求的那些孔位。於是在 session 眼裡，Claude 跟 Apple 自家模型沒兩樣，都是「一個照規矩來的模型」，插上去就能用。

這就是那件怪事的全部真相。不是 Apple 跟 Anthropic 私下談好了什麼，是 Claude 主動把自己「改裝成符合插座規格的電器」。

拆到這裡，那「改一行」就一點都不神奇了

理解了 protocol 這層，下面這段你就會看得很淡定：

1
2
3
4
5
6
7
8
import FoundationModels
import ClaudeForFoundationModels

let model = ClaudeLanguageModel(
    name: .sonnet4_6,
    auth: .apiKey(ProcessInfo.processInfo.environment["ANTHROPIC_API_KEY"] ?? "")
)
let session = LanguageModelSession(model: model)

跟用 Apple 自家模型的差別，就只在 model 那一行：本來放 SystemLanguageModel，現在放 ClaudeLanguageModel。session 以下的程式碼——你怎麼問、怎麼收串流、怎麼掛工具——完全不用動。換模型不是改架構，是換一顆插上去的電器。

這裡有個容易被忽略、但很關鍵的設計：請求是直接從你的 app 打到 Claude API 的，Apple 不在這條路徑上。 它看不到你的 prompt、也看不到回應，費用直接算進你的 Anthropic 帳號、走標準 API 計價。換句話說，Apple 提供的是「插座規格」這個介面，電從哪家買、帳單寄給誰，是你跟 Anthropic 之間的事。

老實講一句：以上我是照官方文件跟 GitHub 上的範例整理的，自己還沒在 macOS 27 beta 上實際跑過一輪——這套件現在還是 beta（targets OS 27 betas），API 在正式版前可能會變。所以下面講到的細節，請以你裝的那版為準。

工具呼叫分兩種，這個分界線值得記住

光能聊天還不夠，真正有用的是讓 AI 動手做事。這套整合把工具拆成兩類，分界線畫得很乾淨。

裝置端工具（client-side）跑在你手機上。你把自己的型別實作成 Tool，丟進 session，當 Claude 決定要呼叫它，框架就在裝置本地執行——這條路跟你用 Apple 模型時一模一樣，沒有任何特殊待遇。

伺服器端工具（server-side）跑在 Anthropic 那邊，在同一個 round-trip 裡完成，目前有網頁搜尋、網頁抓取、程式碼執行三種。設定方式是建模型時掛上去：

1
2
3
4
5
6
7
8
let model = ClaudeLanguageModel(
    name: .sonnet4_6,
    auth: auth,
    serverTools: [
        .webSearch(maxUses: 5),
        .codeExecution,
    ]
)

為什麼要分這兩種？回到第一性想：要讀你手機相簿、要存本地檔案的事，只能在裝置上做；要連網搜尋、要跑一段沙箱程式碼的事，留在伺服器端做最省事也最安全。工具該在哪跑，看的是「它需要碰到誰的資料」——這個判斷，比背 API 名稱重要得多。

上線前，有一個坑你非知道不可

開發階段，直接 .apiKey("你的金鑰") 最方便。但這顆金鑰只能用在開發，原因很硬：你打包進 app 的金鑰，是可以從上架的 binary 裡被挖出來的。等於你把家裡鑰匙黏在門上，再貼張紙條說「請別開」。

官方給的解法分兩段。現在能用的，正式環境走 .proxied 模式——金鑰放你自己的後端，app 透過你的 proxy 轉發，金鑰不落地到使用者手機。另外官方說「即將推出」一個 production 模式，不用自己架後端，每次安裝用 Apple 的 App Attest 驗證、用量算進你的 Anthropic workspace。在那個之前，記住一條鐵律就好：**.apiKey 只進開發機，永遠不上架。**

錯誤處理也順手提一下。對應不到 Foundation Models 既有錯誤型別的供應商錯誤，會以 ClaudeError 冒出來，你可以 pattern-match 來決定產品流程，例如抓到 ClaudeError.missingCredential 就跳出來請使用者填金鑰。

如果你不能要求 iOS 27，還有別條路

這套整合最大的限制，是它吃 OS 27 才有的 server-side language model API——你的 app 要是還得支援舊系統，這條路就走不了。

這時候有個社群方案叫 AnyLanguageModel（Hugging Face 出的），定位是 Foundation Models 框架的「drop-in 替代品」，往回相容到 iOS 17，而且同一套 session API 後面能接的後端更雜——MLX、llama.cpp、Ollama、Core ML，還有 Anthropic、OpenAI、Gemini 這些遠端供應商。你發現了嗎，它能存在、能「drop-in 替代」，靠的還是同一招：用一個統一的 session 介面，把背後一堆五花八門的模型藏起來。protocol 這層抽象一旦立住，誰都能來補一塊。

把這篇真正的重點帶走

這篇從頭到尾，表面在講 iOS 怎麼接 Claude，但你真正該帶走的不是那行 import。

是這個：Apple 沒有為 Claude 寫任何特例程式碼，Anthropic 也沒求 Apple 開後門。能無痛換模型，純粹是因為中間擺了一份 LanguageModel protocol——把「會變的東西」（今天用哪台模型、跑在裝置還是雲端）藏在一個穩定的介面後面，讓上層程式碼對下面的變化無感。這招在後端叫 interface、在資料層叫 repository pattern、在系統設計叫 ports and adapters，名字一堆，骨子裡是同一件事：找出系統裡最會變的那塊，用一道介面把它隔離起來。

哪天 Sonnet 4.6 退場、出了新模型，你也只是改 name: 那一行。會痛的人，是當初把模型呼叫硬寫進每個畫面的人。

想往下練，給你一條路徑：先把這個官方範例在 macOS 27 上跑起來（ANTHROPIC_API_KEY=<key> swift run ClaudeExample "京都該看什麼"），親手感受「換 model 不換邏輯」是什麼手感；接著回頭翻 WWDC26 那場 session 339，它不只教你怎麼「呼叫」模型，還教你怎麼「做一個自己的 provider 套件」——當你哪天想把公司內部的自家模型也包成符合這份規格的電器，那一場就是你的起點。

參考來源：Claude support for Apple’s Foundation Models framework - Claude Blog
官方文件：Apple Foundation Models - Claude API Docs
程式碼：anthropics/ClaudeForFoundationModels - GitHub