在 Mac 上用 MLX 运行 Agentic AI

在 WWDC 2026 上，一位 Apple 工程师要求他 Mac 上的本地 agent 拉取 MLX 仓库近期的 pull request，总结这些改动，并标出需要关注之处。模型进行推理，调用了 GitHub CLI，读取 diff，并生成了一份摘要。只有 git 命令访问了网络；模型完全运行在他的硬件之上。¹ 那场演示正是本文的全部论点所在：agentic 循环——也就是模型做出决策、调用工具、观察结果、再做决策的那部分——如今可以借助 MLX 在 Mac 本地运行。无需云端，无需 API 密钥，也没有按 token 计费的成本。Apple 还连同它一起交付了故事的其余部分：如何将该循环扩展到多台 Mac，如何防范针对 agentic 功能的一类新型攻击，以及当循环悄然出错时如何调试它。

本文将走过 WWDC 2026 的四场 session，它们合在一起，让 Mac 上的本地 agentic AI 成为一个真正可工程化的领域，而不只是一场技术演示。下文的一切都直接来自这些 session。

TL;DR

• MLX 通过一套四层架构在 Mac 本地运行整个 agentic 循环：MLX 作为底层基础，MLX-LM 负责模型，MLX-LM Server 作为兼容 OpenAI 的 HTTP 服务器，再加上任何能讲 OpenAI chat completions 协议的 agent 位于其上。¹
• 配置只需三步：用 pip install 安装 MLX-LM，用一个支持工具调用的模型运行 mlx_lm.server，然后把你 agent 的 base URL 指向 localhost。¹
• 当一台 Mac 不够用时，MLX 借助 RDMA 和 Apple 的开源 JACCL 库，通过 Thunderbolt 5 将一个模型分布到多台 Mac 上运行，可运行万亿参数模型，并在一个四节点集群上将推理与微调速度提升约三倍。²
• agentic 功能打开了一个新的攻击面：间接提示注入（indirect prompt injection）。Apple 的缓解思路倚重确定性的防护栏：Foundation Models 中的 .onToolCall 确认与 .historyTransform 聚光（spotlighting），以及 App Intents 中基于风险的确认与锁屏认证。³
• Xcode 27 中的 Foundation Models Instrument 让循环变得可观测：按请求划分的泳道、模型思维链的树状视图，以及你捕捉静默失败和慢速推理所需的各项指标（首 token 时间、每秒 token 数、总延迟）。⁴

本地 agentic 技术栈（Session 232）

来自 MLX 团队的 Angelos 从 2:42 开始讲解这三步配置。

大多数开发者熟悉的聊天体验，把活儿又推回给了人。正如该 session 的表述：“你向语言模型发送一个 prompt。模型把回应发回来。如果你需要根据那个回应去行动——运行一条命令、检查一个文件或修复一个错误——那就得你自己来。”¹ 而一个 agent 弥合了这道鸿沟。agent 与模型对话以决定要做什么，调用工具去执行，观察结果，再回到模型进行下一步。用户到 agent，agent 到模型，agent 到工具，循环往复，直到任务完成。

让这个循环在 Apple silicon 上变得有趣的，是它整个都在本地运行。MLX 将这一能力呈现为四层，自下而上：MLX，“我们专为 Apple silicon 打造的开源数组框架”，负责计算、Metal 加速与内存；MLX-LM，用于从 Hugging Face 加载、运行、量化和微调模型；MLX-LM Server，“一个兼容 OpenAI 的 HTTP 服务器，通过标准 API 暴露你的本地模型”，支持结构化工具调用与推理模型；以及位于顶层的、任何能讲 OpenAI chat completions 协议的 agent，无论它是 Xcode、OpenCode、一个 Pi agent，还是一段自定义脚本。¹ 这个标准接口是承重的选择：“任何 agent 框架都开箱即用”，而 Ollama、LM Studio 和 vLLM 等工具早已构建在 MLX 和 MLX-LM 之上。¹

配置只需三步。用一条 pip install 安装 MLX-LM。用一个支持工具调用的模型启动服务器：

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

然后把 agent 的 base URL 设为 localhost，将其指向本地服务器。正如该 session 所言，“agent 并不知道、也不在乎模型是运行在你的 Mac 上还是在云端。”¹ 在 OpenCode 中，这意味着定义一个本地 provider，其 URL 为 localhost、模型名与服务器期望的一致，然后告诉 OpenCode 一切都使用那个本地模型。

有趣的部分在于，MLX 究竟是如何专门在 agentic 工作负载上立得住脚的。该 session 点出了三项挑战。第一项是 prompt 处理：“agentic 会话通常包含数十万个 token，而其中大多数并非生成出来的。”¹ 模型每次收到工具输出，都要在进一步推理之前处理那一整片新上下文，而这项成本会贯穿整个循环反复出现。M5 芯片专用的 Neural Accelerators 让矩阵乘法比 M4 上快四倍，再配合 MLX 的专用 kernel，“这几乎原封不动地转化为 prompt 处理的提速”，且无需任何特殊参数或代码改动。¹ 第二项挑战是并发：agent 会派生出子 agent，而 MLX-LM Server 通过连续批处理（continuous batching）来处理这些同时到来的请求，动态地将它们分组，好让子 agent“不必排队空等”。¹ 第三项挑战是模型大小，而这正是下一场 session 接续的话题。

Angelos 以一场超越“读取并报告”的演示收尾：从一个空白的 Xcode 工程出发，他让 agent 为 iPad 构建一个 SwiftUI 绘图应用。agent 检视目录，制定计划，写出代码，并用 xcodebuild 编译并修复自己的错误，约两分钟内便产出了一个可用的应用，随后又应要求迭代，加上了圆角端帽。¹ 最后一场演示，把同一个运行中的 MLX 服务器接入 Xcode 的 Intelligence 设置，作为一个本地托管的聊天 provider，于是 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 进行远程直接内存访问（RDMA），将数据从一台机器的内存直接搬到另一台，同时“规避大部分 CPU 与操作系统开销”。² 通信后端：JACCL，“一个由 Apple 构建的开源集合通信库”，运行在 Thunderbolt 上的 RDMA 之上，提供集合原语而无需你去管理传输；它“不限于机器学习”，“可以不依赖 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 支持两种分片策略：流水线并行（按深度切分，通信简单但没有提速）和张量并行（按宽度切分，所有机器同时处理同一个 token 以求提速，代价是频繁的逐层通信——“这正是网状拓扑至关重要的原因”）。² 张量并行是默认策略。该 session 在集群上运行了万亿参数的 Kimi 2.6（8 位下约一 TB 的权重，它“在单台 M3 Ultra 上塞不下，但跨四台就能放下”）。² 同样的方法也能加速微调：通过 mlx_lm.lora 进行数据并行的 LoRA 训练，让原本约每秒 180 token 的单台 M3 Ultra 在集群上达到约每秒 600 token，“提速三倍多”。² MLX 通过 Python、Swift 和 C++ 暴露同一套原语，以便将分布式工作流嵌入应用。

加固这个循环（Session 347）

Willy 在 4:01 引入间接提示注入；Akshay 从 11:55 开始讲解框架 API。

赋予模型调用工具的能力，等于打开了一扇门。正如 Willy 的表述：“LLM 在你的应用内引入了一个新的概率引擎，它既强大，又有被欺骗的风险。”³ 这个新风险就是间接提示注入，该 session 将其定义为“嵌入在提供给模型的额外上下文中、意图改变控制流的指令”。³ 该 session 的示例应用 Loose Leaf 增加了一个“组织一场茶会”的功能，它会读取你的日历和好友动态，并能下单买茶。攻击是这样的：用户要求规划一场茶会、并附上了自己的日历，但其中一条日历事件包含一条注入的指令，告诉模型转而去删除用户的敏感数据。³

注入会产生两种效应。数据投毒（data poisoning），即“攻击者影响某个被执行动作的参数”，把一条本该发给你妈妈的消息变成发给攻击者的消息。动作投毒（action poisoning），即攻击者“影响要执行哪个动作”，把一个“总结这封邮件”的请求，引导成附上邮件内容去打开一个恶意 URL。³ 该 session 用 Simon Willison 的“致命三要素”（Lethal Trifecta）来落实这一危险：当一个 agentic 系统同时具备访问私有数据、接触不可信内容、以及对外通信这三者时，用户面临的风险最高——并将其推广为“任何带副作用动作的风险”。³ 这一表述很坦诚：“解决间接提示注入是一个活跃的研究领域”，所以现实的目标是了解你应用的风险并加以缓解。³

方法是一次威胁建模演练。第一，对馈入 prompt 的一切做数据流分析，把“任何来自外部实体的输入”标记为不可信——对 Loose Leaf 而言，这意味着日历内容和好友动态。³ 第二，盘点 agent 的各项动作及其副作用：下单买茶的工具带有财务风险，发布动态的工具带有数据外泄风险，甚至一个看似人畜无害的冲泡计时器也有风险，因为它那个可选的标签“可能让一次提示注入写下更多指令、为日后的攻击埋伏”。³ Apple 明确表示倾向于“以确定性缓解作为基线，因为其安全保证更易于审计与推理”，再在其上叠加概率性缓解。³

接着 Akshay 展示了这些 API。在 Foundation Models 中，生命周期事件修饰符是“在一次 session 执行的某些生命周期节点上确定性触发的回调”，可用作安全检查点。.onToolCall 修饰符在执行器运行某个工具之前运行，而“如果这个回调抛出错误，那么该工具就永远不会被执行”，这“使它成为强制确认的绝佳位置”：检查当前工具是否为那个财务工具，若是则先要求用户确认。³ .historyTransform 修饰符“在 transcript 被渲染给模型进行推理之前触发”，让你能把不可信的工具输出用聚光分隔符包裹起来，并在模型看到之前，通过把敏感片段替换为 [REDACTED] 占位符来脱敏 PII。³ 有一点要注意：这些 transform“仅作用于当前这一次推理迭代”，所以你要在每次调用时重新应用它们，或者对想要持久化的变换使用 @SessionProperty 注解。³

对于通过 App Intents 与 Siri 集成的应用，有两道系统级防护栏适用。确认是“基于风险的”且“上下文相关的”：当一个 intent 采用某个 schema 时，它会继承那个 schema 的风险元数据（删除照片是破坏性的，外泄数据是有风险的），而一个风险评估系统会把这份静态元数据与“系统的动态状态”结合起来，决定在执行前是否要询问用户。³ 第二道是锁屏认证：因为在锁定的设备上也能触达 Siri，你要把一个 intent 的 authenticationPolicy 设为 .requiresAuthentication，让破坏性动作无法在锁屏状态下运行；一个 schema 的默认策略“只能被覆盖得更严格”，更弱的覆盖会产生编译错误。³

调试这个循环（Session 243）

Erik 从 1:58 开始诊断他 Craft 应用中一次静默的 agentic 失败。

循环的灵活性，也正是它在调试上的难题。正如 AI Tools 工程师 Erik 所说：“传统代码是可预测的。LLM 是非确定性的；同样的输入可以产生不同的输出。”⁴ 他点出了传统开发中不存在的三项挑战：概率性输出（于是“标准的单元测试就失效了”，你转而去评估质量与意图）、模型到模型的通信，以及可观测性——“当一条多模型流水线里有东西出错，往往很难知道究竟是哪儿出了问题。”⁴ Xcode 27 中的 Foundation Models Instrument 正是为回答最后这个问题而存在。

Erik 在他的 Craft 应用上做了演示，其中一个头脑风暴功能用到了两套指令集——头脑风暴和教程生成——头脑风暴这套提供了一个 GenerateCraftIdeaTool 和一个 SwitchToTutorialModeTool。⁴ 在这条 trace 里，该功能失败了：它一直在给点子，而不是切换到教程。Instructions 泳道立刻道出了缘由，它显示“整个 session 里只有一套指令是激活的，但这个功能本应使用两套，所以交接过程中出了岔子”。⁴ 那个把一切组织进“session、请求、模型推理、指令、prompt 和响应”的树状视图，揭出了根因：“prompt 引用了 switchToTutorialMode 工具，但那个工具其实并没有随这套指令一同配置。”⁴ 模型不断地发起工具调用却从不抛出错误：“这是一次静默失败”，是最难捕捉的那一类。⁴ 把缺失的工具加进工具集就修好了它，重新跑出的 trace 显示出两套各自分明、均被激活的指令集，而交接也在一次 switchToTutorialMode 工具调用之后正确发生了。⁴

这个 Instrument 也让性能变得清晰可读。Model Inference 泳道用黄色条表示输入 prompt 的处理，用橙色条表示响应生成。⁴ 三个指标驱动优化：首 token 时间（“首 token 时间偏高意味着人们在盯着一块空白屏幕；要降低它，就缩短你的 prompt”）、每秒 token 数（用来“在不同的 prompt 配置间对性能做基准测试，并在改动后捕捉回退”），以及总延迟，“人们最直接感受到的那个数字”——通过更早地流式输出部分结果，可在感知上减轻它。⁴ 一条运维提示：该 Instrument“会从你的设备捕获 prompt 和响应数据，其中可能包含敏感信息”，所以在生产中日志是关闭的，仅在 trace 期间开启，而你要把 trace 文件存放在某个安全之处。⁴

如何上手

这四场 session 组合成一条序列，你可以在自己已经拥有的硬件上照着走：

1. 把本地循环立起来。 用 pip install 安装 MLX-LM，先用一个小型、支持工具调用的模型运行 mlx_lm.server 来验证配置，再把你 agent 的 base URL 指向 localhost。在让 agent 写文件或跑构建之前，先从“读取并报告”这类任务起步。¹ 一旦放手让它干活，就给它一处隔离的地方去做：容器机（container machines）能在 Mac 上为 agent 提供一个快速、持久的 Linux 环境，以 VM 隔离并把你的主目录挂载进去，于是构建和安装都跑在一道真正的边界之后，而非直接冲着宿主机来。
2. 只在一台 Mac 不够时才扩展。 如果一个模型塞不进内存、或推理太慢，就用 Thunderbolt 5 把多台 Mac 连起来，在“设置”中启用 RDMA，用 mlx.distributed_config 生成一个 hostfile，再用 mlx.launch 跑同样的命令。为了速度选用张量并行（默认），并为它所需的低延迟选用网状拓扑。²
3. 在交付 agentic 功能之前先做威胁建模。 列出每一个不可信的上下文来源和每个动作的副作用。在有副作用的工具上加 .onToolCall 确认，在不可信的工具输出上加 .historyTransform 聚光与脱敏；对 App Intents，审查每个 intent 的风险元数据，并设置 authenticationPolicy，让破坏性动作需要一台已解锁的设备。³
4. 在信任它之前先剖析它。 在 Xcode 27 的 Instrument 中剖析你的 Foundation Models 功能，读 Instructions 和 Model Inference 泳道来查静默失败，并用首 token 时间、每秒 token 数和总延迟来找出慢步骤。⁴

Session 232 中的一切都是“开源的，现在就能用”。¹

FAQ

我真的能在自己的 Mac 上完整运行一个 AI agent 吗？

能。WWDC 2026 的 Session 232 演示了完整的 agentic 循环借助 MLX 在本地运行：模型推理、调用工具、观察结果、迭代，而只有那些确实需要网络的工具调用才会伸出机器之外。这套技术栈是 MLX、MLX-LM、兼容 OpenAI 的 MLX-LM Server，以及位于其上的任何能讲 OpenAI chat completions 协议的 agent。¹

我如何把 agent 连到一个本地的 MLX 模型？

三步。用 pip 安装 MLX-LM，用一个支持工具调用的模型启动 mlx_lm.server，然后把你的 agent 框架的 base URL 设为本地服务器在 localhost 上的地址。agent 对待这个本地服务器，与对待一个云端 LLM API 别无二致，因为 MLX-LM Server 是一个可直接替换、兼容 OpenAI 的 HTTP 服务器。¹

如果模型对一台 Mac 来说太大了怎么办？

MLX 借助 RDMA（从 macOS 26.2 起支持）和 Apple 的开源 JACCL 通信库，将一个模型分布到多台通过 Thunderbolt 5 连接的 Mac 上。你用 mlx.launch 加一个 hostfile 启动作业；MLX 会自动分片模型。Apple 的 session 在四台 M3 Ultra 上运行了一个万亿参数模型，相比单台机器，推理与微调速度提升约三倍。²

对于 agentic Mac 应用，主要的新安全风险是什么？

间接提示注入：藏在不可信上下文（一条日历事件、一条社交动态、一个工具结果）里的恶意指令，会把模型引向用户从未要求过的动作，比如删除数据或将其外泄。Apple 建议做一遍威胁建模，再配上确定性的防护栏：Foundation Models 中的 .onToolCall 确认与 .historyTransform 聚光及 PII 脱敏，以及 App Intents 中基于风险的确认与锁屏认证。³

我如何调试一个静默失败的 agent？

用 Xcode 27 中的 Foundation Models Instrument。它把每一次模型推理、每一套指令集、每个 prompt 和每个响应都捕获进时间线泳道和一个树状视图，于是你能确切看到每一步都有哪些工具可用、以及交接是在哪里出的岔子——哪怕模型从未抛出过错误。它还会呈现首 token 时间、每秒 token 数和总延迟，供性能调优之用。⁴

在 Apple silicon 上运行你自己的模型，是这个循环立身的根基：参见 MLX on Apple Silicon：当你需要的是自己的模型，而非 Apple 的 与 用 Core AI 在 Apple silicon 上运行模型。塑造 agent 如何触及一个 Swift 应用的“运行时与工具链”之分，见 Foundation Models 的 agentic 工作流。一旦循环跑起来，下一步就是衡量它的质量，这在 Apple 的 Evaluations 框架 中有所讲述。整个系列的主页是 Apple 生态系统系列，而更宽广的构建背景见 iOS Agent 开发指南。

References