在 Mac 上以 MLX 執行代理式 AI

在 WWDC 2026，一位 Apple 工程師請他 Mac 上的本機代理去抓取 MLX 儲存庫近期的 pull request、摘要其變更，並標示出需要留意之處。模型進行推理、呼叫 GitHub CLI、讀取 diff，並產生出一份摘要。唯有 git 指令觸及網路；模型完全在他的硬體上執行。¹ 這場示範正是本文的核心論點：代理式迴圈——也就是模型決策、呼叫工具、觀察結果，然後再次決策的那個環節——如今可在 Mac 上以 MLX 於本機執行。無需雲端、無需 API 金鑰、無需按 token 計費。而 Apple 也一併交付了故事的其餘部分：如何將該迴圈擴展至多台 Mac、如何保護代理式功能免於一類新型攻擊，以及當迴圈悄無聲息地做錯事時該如何除錯。

本文走過四場 WWDC 2026 議程，這些議程合在一起，讓 Mac 上的本機代理式 AI 成為一個真正的工程領域，而非僅止於技術展示。以下所有內容皆直接取自這些議程。

TL;DR

• MLX 透過四層堆疊在 Mac 上於本機執行完整的代理式迴圈：底層是 MLX、模型層是 MLX-LM、MLX-LM Server 作為相容於 OpenAI 的 HTTP 伺服器，最上層則是任何能說 OpenAI chat completions 協定的代理。¹
• 設定只需三步：以 pip install 安裝 MLX-LM、以支援工具呼叫的模型執行 mlx_lm.server，再將代理的 base URL 指向 localhost。¹
• 當一台 Mac 不夠用時，MLX 會透過 Thunderbolt 5 以 RDMA 及 Apple 的開源 JACCL 函式庫將模型分散到數台 Mac 上，可執行兆級參數模型，並在四節點叢集上將推理與微調速度提升約三倍。²
• 代理式功能開啟了一個新的攻擊面：間接提示注入。Apple 的緩解策略仰賴確定性防護機制：Foundation Models 中的 .onToolCall 確認與 .historyTransform 聚光標示（spotlighting），以及 App Intents 中以風險為基礎的確認與鎖定畫面驗證。³
• Xcode 27 中的 Foundation Models Instrument 讓迴圈變得可觀測：每次請求各成一條時間軸、模型思考鏈的樹狀檢視，以及你用來捕捉無聲失敗與緩慢推理所需的各項指標（Time to First Token、Tokens per Second、Total Latency）。⁴

本機代理式堆疊（Session 232）

MLX 團隊的 Angelos 從 2:42 開始講解這套三步設定流程。

多數開發者熟悉的聊天體驗，把工作推回給了人類。正如議程所述：「你把一個提示送給語言模型。模型把回應送回來。如果你需要根據那則回應採取行動——執行某個指令、檢查某個檔案，或修正某個錯誤——那都是你的事。」¹ 代理彌平了這道落差。代理與模型對話以決定該做什麼、呼叫工具去執行、觀察結果，再回到模型進行下一步。使用者到代理、代理到模型、代理到工具，如此循環直到任務完成。

這個迴圈在 Apple silicon 上之所以有趣，在於它全部都在本機執行。MLX 將其能力呈現為由下而上的四層：MLX，「我們專為 Apple silicon 打造的開源陣列框架」，負責運算、Metal 加速與記憶體；MLX-LM，用來載入、執行、量化並微調來自 Hugging Face 的模型；MLX-LM Server，「一個相容於 OpenAI 的 HTTP 伺服器，透過標準 API 將你的本機模型對外開放」，並支援結構化的工具呼叫與推理模型；最上層則是任何能說 OpenAI chat completions 協定的代理，無論是 Xcode、OpenCode、Pi 代理，或是自訂腳本。¹ 這套標準介面是承重的關鍵抉擇：「任何代理框架皆可開箱即用」，而 Ollama、LM Studio 與 vLLM 等工具已經建立在 MLX 與 MLX-LM 之上。¹

設定只需三步。以單一道 pip install 安裝 MLX-LM。以支援工具呼叫的模型啟動伺服器：

mlx_lm.server --model <a-tool-calling-model>

接著將代理的 base URL 設為 localhost，把它指向本機伺服器。如議程所述，「代理並不知道、也不在意模型是跑在你的 Mac 上而非雲端。」¹ 在 OpenCode 中，這意味著定義一個本機供應者，其 URL 為 localhost、其模型名稱與伺服器預期的一致，然後告訴 OpenCode 在所有事情上都使用該本機模型。

有趣之處在於 MLX 如何在代理式工作負載上實實在在地發揮價值。議程點出三項挑戰。第一是提示處理：「代理式工作階段通常由數十萬個 token 組成，而其中大多並非由模型生成。」¹ 每當模型收到工具輸出，它都得在進一步推理前先處理那一整批新的脈絡，而這項成本會在整個迴圈中反覆出現。M5 晶片專屬的 Neural Accelerators 讓矩陣乘法比 M4 快上四倍，搭配 MLX 的專用核心，「這幾乎能原封不動地轉化為提示處理的加速」，且無需任何特殊參數或程式碼變動。¹ 第二項挑戰是並行處理：代理會衍生出子代理，而 MLX-LM Server 以連續批次處理（continuous batching）應對這些同時湧入的請求，動態地將它們分組，讓子代理「不必停滯地在佇列中排隊等候」。¹ 第三項挑戰是模型大小，這正是下一場議程接續探討的重點。

Angelos 以一場超越「讀取並回報」的示範作結：從一個空白的 Xcode 專案出發，他請代理為 iPad 打造一個 SwiftUI 繪圖 App。代理檢視目錄、擬定計畫、撰寫程式碼，並運用 xcodebuild 編譯並自行修正錯誤，在約兩分鐘內產出一個可運作的 App，接著又依要求迭代，加上了圓角端點。¹ 最後一場示範把同一個正在執行的 MLX 伺服器接進 Xcode 的 Intelligence 設定，作為本機代管的聊天供應者，讓 Xcode 本身得以找出並修正一個被刻意植入的 bug。「本機 AI 意味著你的程式碼永遠不會離開你的 Mac。」¹

跨 Mac 擴展（Session 233）

Tatiana 從 2:21 開始，一步步建構出一個四台 Mac 的叢集。

終究，一台機器會空間用罄。正如 MLX 團隊的研究科學家 Tatiana 所言：「終究，單一機器上的記憶體、運算或頻寬會成為瓶頸。」² Session 232 中最具代表性的案例，是一個根本塞不下的模型：最新的 DeepSeek 模型「擁有高達 1.6 兆個參數，光是權重就需要超過 800GB 的記憶體。」¹ Session 233 則深入探討如何將那份工作分散到你自己擁有的多台 Mac 上。

分散式 MLX 底下的堆疊有三個部分。互連與傳輸：自 macOS 26.2 起，支援透過 Thunderbolt 5 進行 Remote Direct Memory Access（RDMA），將資料直接從一台機器的記憶體搬移到另一台，同時「避開大部分的 CPU 與作業系統開銷」。² 通訊後端：JACCL，「一個由 Apple 打造的開源集合通訊函式庫」，在 Thunderbolt 上的 RDMA 之上執行，提供集合原語（collective primitives）而無須你親自管理傳輸，而且它「不限於機器學習」，「無需 MLX 也能建構」，並對外開放一套 C++ API 供任何分散式工作負載使用。² MLX 坐落於最上層，運用 JACCL 在叢集間進行低延遲協調。

Tatiana 以四台 M3 Ultra 建構了一個叢集。拓樸至關重要，因為通訊時間會拆分為延遲（每次操作的固定成本）與傳輸時間（隨訊息大小增長）。JACCL 支援網狀（mesh）拓樸，其中「每台機器都直接連到其他每一台」以達最低延遲；也支援環狀（ring）拓樸，其中每個節點連到兩個鄰居，釋出連接埠以便對每個鄰居拉多條纜線換取更高頻寬。以網狀方式接線後，JACCL「會依訊息大小與通訊操作自動挑選最佳拓樸——延遲要緊時用網狀，頻寬要緊時用環狀。」² 你在「設定」中啟用 RDMA，然後用指向某個 JSON hostfile 的 mlx.launch 啟動工作；輔助腳本 mlx.distributed_config 會產生該 hostfile，並在加上 --auto-setup 後，自行設定好 Thunderbolt 網路。²

跨叢集執行一個模型，與在單一機器上執行幾乎一模一樣。你以 mlx.launch --hostfile 包住同一道 mlx_lm.chat 指令，「MLX LM 便會替你將模型分片並協調分散式推理。」² 兩相對照，一個 270 億參數的 Qwen 3.6 在四台 M3 Ultra 上生成 token 的「速率幾乎是單一機器的三倍」。² MLX 支援兩種分片策略：管線平行（pipeline parallelism，依深度切分，通訊簡單但無加速）與張量平行（tensor parallelism，依寬度切分，所有機器同時處理同一個 token 以換取加速，代價是每層頻繁的通訊——「這正是網狀拓樸至關重要的原因」）。² 張量平行是預設值。議程在叢集上執行了一兆參數的 Kimi 2.6（以 8-bit 計約一兆位元組的權重，它「塞不進單一台 M3 Ultra，但分散到四台就塞得下」）。² 同樣的做法也能加速微調：透過 mlx_lm.lora 進行的資料平行 LoRA 訓練，讓單一台 M3 Ultra 從每秒約 180 個 token 提升到叢集上的每秒約 600 個，「加速超過三倍」。² MLX 透過 Python、Swift 與 C++ 開放同一套原語，以便將分散式工作流程嵌入 App 之中。

保護迴圈（Session 347）

Willy 在 4:01 介紹間接提示注入；Akshay 自 11:55 起講解框架 API。

賦予模型呼叫工具的能力，等於開了一扇門。正如 Willy 所言：「LLM 在你的應用程式中引入了一個全新的機率引擎，它既強大，卻也有被誆騙的風險。」³ 新的風險是間接提示注入，議程將其定義為「嵌入在提供給模型的額外脈絡中、意圖重導控制流程的指令」。³ 議程的範例 App「Loose Leaf」新增了一項「籌辦茶會」功能，它會讀取你的行事曆與好友動態，並可訂購茶品。攻擊手法是：使用者要求規劃一場茶會並附上自己的行事曆，但某則行事曆事件中藏有一道被注入的指令，反而要模型去刪除使用者的敏感資料。³

注入會產生兩種效果。資料中毒（data poisoning），即「攻擊者影響某個已執行動作的參數」，會把一則本要寄給你媽媽的訊息變成寄給攻擊者。動作中毒（action poisoning），即攻擊者「影響要執行的是哪個動作」，會把一個「摘要這封電子郵件」的請求，引導成開啟一個附帶該郵件內容的惡意 URL。³ 議程以 Simon Willison 的「致命三要素」（Lethal Trifecta）為這份危險立下根基：當一個代理式系統同時結合了存取私密資料、暴露於不受信任內容，以及對外通訊的能力時，使用者面臨的風險最高——這還可推廣為「任何具有副作用之動作的風險」。³ 這番框架坦率以對：「解決間接提示注入是一個活躍的研究領域」，因此務實的目標是理解你 App 的風險並加以緩解。³

方法是一場威脅建模演練。首先，對所有餵入提示的內容進行資料流分析，將「任何來自外部實體的輸入」標記為不受信任——對 Loose Leaf 而言，這意味著行事曆內容與好友動態。³ 其次，盤點代理的各項動作及其副作用：訂茶工具帶有財務風險、發布動態的工具帶有資料外洩風險，就連看似無害的沖泡計時器也有風險，因為它那個選填的標籤「可能讓一次提示注入寫入更多供日後攻擊使用的指令」。³ Apple 明言的偏好是「以確定性緩解措施作為基準，因為其安全保證較易稽核與推理」，再於其上層疊機率性的緩解措施。³

接著 Akshay 展示了那些 API。在 Foundation Models 中，生命週期事件修飾器是「在工作階段執行的特定生命週期點上確定性觸發的回呼」，可作為安全檢查點使用。.onToolCall 修飾器會在執行器執行工具之前先行運作，而「若此回呼擲出錯誤，該工具便永遠不會被執行」，這「使它成為強制執行確認的絕佳位置」：檢查當前工具是否為那個涉及財務的工具，若是，便先要求使用者確認。³ .historyTransform 修飾器「會在謄本被渲染交給模型進行推理之前觸發」，讓你能以聚光標示的分隔符包住不受信任的工具輸出，並在模型看到之前，以 [REDACTED] 佔位符替換敏感片段以遮蔽 PII。³ 有一點要留意：這些轉換「僅作用於當前的這一輪推理迭代」，因此你得在每次呼叫時重新套用，或對你希望持久保留的轉換使用 @SessionProperty 註解。³

對於透過 App Intents 與 Siri 整合的 App，有兩道系統防護機制適用。確認是「以風險為基礎」且「依脈絡而定」的：當一個 intent 採用某個結構描述（schema）時，它便繼承該結構描述的風險中繼資料（刪除照片屬於破壞性、外洩資料屬於高風險），而風險評估系統會將那份靜態中繼資料與「系統的動態狀態」結合，以決定在執行前是否要詢問使用者。³ 鎖定畫面驗證是第二道：由於 Siri 在鎖定的裝置上也能觸及，你會把一個 intent 的 authenticationPolicy 設為 .requiresAuthentication，使破壞性動作無法在鎖定狀態下執行；結構描述的預設政策「只能改得更嚴格」，若改得較弱則會產生建置錯誤。³

為迴圈除錯（Session 243）

Erik 從 1:58 開始，診斷他的 Craft App 中一次無聲的代理式失敗。

迴圈的彈性，也正是它的除錯難題。正如 AI 工具工程師 Erik 所說：「傳統程式碼是可預測的。LLM 是非確定性的；同樣的輸入可能產生不同的輸出。」⁴ 他點出三項傳統開發中不存在的挑戰：機率性的輸出（因此「標準的單元測試會失靈」，你改為評估品質與意圖）、模型對模型的通訊，以及可觀測性——「當多模型管線中有東西壞掉時，要知道是哪裡出了錯可能非常困難。」⁴ Xcode 27 中的 Foundation Models Instrument 正是為了回答最後那一項而存在。

Erik 以他的 Craft App 進行示範，其中有一項腦力激盪功能使用兩組指令——腦力激盪與教學生成——腦力激盪那組提供一個 GenerateCraftIdeaTool 與一個 SwitchToTutorialModeTool。⁴ 在這次追蹤中，該功能失敗了：它不斷提供點子，而非切換到教學模式。Instructions 這條時間軸立刻道出了原委，顯示出「整個工作階段只有一組指令處於作用中，但這項功能本應使用兩組，所以交接過程中出了某種差錯」。⁴ 樹狀檢視——它把一切組織成「工作階段、請求、模型推理、指令、提示與回應」——浮現出根本原因：「提示參照了 switchToTutorialMode 工具，但該工具其實並未在這道指令中被配置。」⁴ 模型不斷進行工具呼叫卻未擲出任何錯誤：「這是一次無聲的失敗」，最難捕捉的那種。⁴ 將缺漏的工具加進工具集便修好了它，而重新追蹤顯示出兩組各自獨立的指令處於作用中，交接也在一次 switchToTutorialMode 工具呼叫後正確地發生了。⁴

這個 Instrument 也讓效能變得清晰可讀。Model Inference 這條時間軸以黃色條代表輸入提示的處理、橘色條代表回應的生成。⁴ 三項指標驅動著最佳化：Time to First Token（「過高的 Time to First Token 意味著人們盯著一片空白的螢幕；要降低它，就把你的提示縮短」）、Tokens per Second（用來「在不同的提示配置間對效能進行基準測試，並在變動後捕捉效能退化」），以及 Total Latency，「人們最直接感受到的那個數字」，可藉由更早串流出部分結果來在感知上加以縮短。⁴ 有一則操作上的提醒：這個 Instrument「會從你的裝置擷取提示與回應資料，當中可能包含敏感資訊」，因此記錄在正式環境中是關閉的、僅在追蹤期間開啟，而且你要把追蹤檔案存放在安全的地方。⁴

如何起步

這四場議程合成一道你可以在自己既有的硬體上依循的流程：

1. 架起本機迴圈。 以 pip install 安裝 MLX-LM、先以一個小型且支援工具呼叫的模型執行 mlx_lm.server 來驗證設定，再將代理的 base URL 指向 localhost。在讓代理寫入檔案或執行建置之前，先從「讀取並回報」的任務開始。¹ 一旦它要這麼做，就給它一處隔離的地方來做那份工作：container machine 能在 Mac 上為代理提供一個快速、持久的 Linux 環境，以 VM 隔離並掛載你的家目錄，讓建置與安裝在一道真正的邊界之後執行，而非直接針對主機。
2. 唯有一台 Mac 不夠用時才擴展。 若一個模型塞不進記憶體，或推理太慢，就透過 Thunderbolt 5 把多台 Mac 串接起來、在「設定」中啟用 RDMA、以 mlx.distributed_config 產生 hostfile，再以 mlx.launch 執行相同的指令。為求速度採用張量平行（預設值），並為其所需的低延遲採用網狀拓樸。²
3. 在推出代理式功能之前先做威脅建模。 列出每一個不受信任的脈絡來源，以及每項動作的副作用。對具副作用的工具加上 .onToolCall 確認，對不受信任的工具輸出加上 .historyTransform 聚光標示與遮蔽；至於 App Intents，逐一檢視每個 intent 的風險中繼資料，並設定 authenticationPolicy，使破壞性動作需要裝置處於解鎖狀態。³
4. 在信任它之前先做效能剖析。 在 Xcode 27 的 Instrument 中對你的 Foundation Models 功能進行效能剖析、判讀 Instructions 與 Model Inference 兩條時間軸以找出無聲的失敗，並運用 Time to First Token、Tokens per Second 與 Total Latency 來找出緩慢的步驟。⁴

Session 232 中的一切都是「開源的，而且現在就能取得」。¹

FAQ

我真的能完全在自己的 Mac 上執行一個 AI 代理嗎？

可以。WWDC 2026 Session 232 示範了透過 MLX 於本機執行的完整代理式迴圈：模型進行推理、呼叫工具、觀察結果並迭代，唯有那些確實需要網路的工具呼叫才會觸及機器之外。這套堆疊是 MLX、MLX-LM、相容於 OpenAI 的 MLX-LM Server，以及最上層任何能說 OpenAI chat completions 協定的代理。¹

我該如何把代理連到本機的 MLX 模型？

三步。以 pip 安裝 MLX-LM、以一個支援工具呼叫的模型啟動 mlx_lm.server，再把你的代理框架的 base URL 設為本機伺服器在 localhost 上的位址。代理對待這個本機伺服器的方式，與對待一個雲端 LLM API 一模一樣，因為 MLX-LM Server 是一個可直接替換、相容於 OpenAI 的 HTTP 伺服器。¹

如果模型對一台 Mac 來說太大，該怎麼辦？

MLX 會將模型分散到透過 Thunderbolt 5 連接的多台 Mac 上，運用 RDMA（自 macOS 26.2 起支援）與 Apple 的開源 JACCL 通訊函式庫。你以 mlx.launch 搭配一個 hostfile 啟動工作；MLX 會自動將模型分片。Apple 在議程中於四台 M3 Ultra 上執行了一個一兆參數的模型，相較於單一機器，在推理與微調上見到約三倍的加速。²

代理式 Mac App 主要的新型安全風險是什麼？

間接提示注入：藏在不受信任脈絡中的惡意指令（一則行事曆事件、一段社群動態、一個工具結果），會把模型重導到使用者從未要求過的動作，例如刪除或外洩資料。Apple 建議進行一輪威脅建模，並搭配確定性的防護機制：Foundation Models 中的 .onToolCall 確認與 .historyTransform 聚光標示及 PII 遮蔽，以及 App Intents 中以風險為基礎的確認與鎖定畫面驗證。³

我該如何為一個無聲失敗的代理除錯？

使用 Xcode 27 中的 Foundation Models Instrument。它會把每一次模型推理、每一組指令、每一個提示與回應擷取到各條時間軸與一個樹狀檢視中，讓你能精確看出每一步有哪些工具可用、交接又是在哪裡出了錯，即使模型從未擲出任何錯誤。它也會呈現 Time to First Token、Tokens per Second 與 Total Latency 以供效能調校。⁴

在 Apple silicon 上執行你自己的模型，正是這個迴圈賴以立足的根基：請見 MLX on Apple Silicon：當你需要的是自己的模型，而非 Apple 的 與 以 Core AI 在 Apple silicon 上執行模型。那道形塑代理如何觸及 Swift App 的「執行階段與工具鏈」之別，則在 Foundation Models 代理式工作流程 中。一旦迴圈跑起來，衡量其品質便是下一步，這在 Apple 的 Evaluations 框架 中有所涵蓋。完整的系列中樞是 Apple Ecosystem 系列，而更廣的建構脈絡則是 iOS Agent Development 指南。

參考資料