企业官网建设流程全解析

从 Swift 6 发布开始，Apple 在 AI 这条赛道上明显换了一套打法。以前大家聊 Swift，想到的更多是 iOS 开发、SwiftUI、性能和安全；现在聊 Swift，绕不开一个词：MLX。官方把目光从端侧模型的轻量推理框架，一路延伸到本地 Agent 的构建工具链上，补齐了从模型加载、推理调度到 Agent 编排的一整套路径。这篇文章我就结合自己近半年的实测经验，从端侧模型运行、MLX 推理、本地 Agent 架构三个层面，把这条工具链的现状、坑和实操心得一次性捋清楚。

先说结论：如果你已经在 Swift 生态里做 AI 应用，或者打算让大模型在 Apple Silicon 上跑得更省心，现在是最好的入场时机。MLX 框架的出现让 Swift 在统一内存架构下的 AI 推理体验，终于能跟 Python 生态掰手腕，而且端侧部署的逻辑天然契合 Agent 对隐私、延迟和成本的控制需求。

1. 内容整体设计与思路拆解

1.1 为什么是 Swift，为什么是现在

Swift 这门语言过去十几年主要活跃在 Apple 平台，性能对标 C++，内存管理又比 C++ 安全得多。但 AI 领域长期被 Python 统治，Swift 一直没挤进主流工具链。直到 MLX 出现，局面才真正转变。

MLX 是 Apple 机器学习团队开源的一套数组框架，专门针对 Apple Silicon 的统一内存架构设计。传统 GPU 推理需要把数据从 CPU 拷到显存，再拷回来，来回搬运有不可避免的开销。Apple Silicon 的 CPU 和 GPU 共享同一块物理内存，MLX 直接把数组放在统一内存里，计算设备切换时不需要复制数据。这个设计思路照搬了 JAX 的函数式编程风格，但底层用 C++ 实现，暴露给 Swift 和 Python 两套 API。

Swift 在端侧 AI 的价值主要体现在三点：

• 编译型语言，天然适合低延迟场景，启动速度、内存占用都比解释型语言可控；
• 泛型和协议编程让模型调用代码写得非常优雅，调度层和模型层可以解耦；
• 与 Xcode、Core ML、Metal 的集成深度是其他语言无法比拟的。

Apple 官方补齐 Swift AI 工具链，本质上是想告诉开发者：你不需要再为了跑模型去学 Python，不需要再搭一套 Python 服务端，直接用 Swift 就能完成从模型加载到业务逻辑的全链路。

1.2 端侧模型与本地 Agent 的需求匹配

端侧模型的价值从来不是它参数有多大，而是它能在没有网络的情况下工作，能把隐私数据留在设备上，能提供可控的延迟。Agent 恰恰是这些特性的最佳载体。

本地 Agent 意味着决策、工具调用、上下文管理都在本机完成。现在的通用云端 Agent 看起来很聪明，但它依赖于网络传输上下文，延迟不可控，数据要经过第三方服务器，成本也会随调用量线性上涨。端侧 Agent 的优势在于：

• 响应速度快，本地推理没有网络往返，单次决策通常在几百毫秒内完成；
• 隐私安全，用户敏感数据不出设备；
• 离线可用，不依赖外部 API 的稳定性；
• 成本固定，不需要为每个请求付费。

Apple 补齐工具链，正是看中了这个需求闭环。从硬件角度，M 系列芯片的统一内存让中等规模模型可以在本机运行；从软件角度，MLX 提供了高效的推理内核，而 Swift 的并发特性和宏系统则为 Agent 的编排逻辑提供了表达能力。

1.3 我在实际项目中的路线选择

我自己做的几个小项目里，选型经历可以概括为三个阶段。第一版用 Python + PyTorch 跑推理，模型和业务逻辑分在两个进程，通信走 HTTP，调试麻烦，部署体积也大。第二版切到 Core ML，格式转换把模型压得很小，但自定义算子支持有限，碰到需要动态调整输入的情况就很憋屈。第三版换到 MLX + Swift，整个应用变成单一二进制，模型文件和推理代码在同一进程内，工具调用的回调直接走函数调用，不再需要序列化和网络传输。

这个变化最直观的感受是，你可以在 Swift 里用@MainActor直接调度 Agent 的决策循环，GPU 推理结果以数组形式返回，不用通过 Data 转来转去。配合 Swift 的宏，甚至可以做一个简单的声明式 Agent 配置，把工具注册、模型参数、上下文窗口都写在 struct 上，编译期检查，运行期高效。

2. 核心细节解析与实操要点

2.1 MLX 框架的核心概念：统一的数组、懒惰计算与图重放

MLX 的编程范式可以总结为三个关键词：统一内存数组、惰性求值、计算图自动重放。这三个特性分别解决了不同层次的问题。

统一内存数组不用多讲，这是 MLX 的基础。你在 Swift 里写MLXArray，它可能存在于 CPU 上也可能存在于 GPU 上，具体位置由 MLX 根据计算需求决定。你不需要手动管理设备上下文，框架自动迁移。

惰性求值是 MLX 极快的一个重要原因。当你执行let c = a + b时，MLX 并不会立刻算，而是把它记录为一个操作节点，构建出一张计算图。只有当你真正需要读取结果，比如把它转成 Swift 的[Float]数组，或者传给输出层时，它才执行整张图。这样做的效果是，框架可以对整个计算流程做算子融合，减少中间结果的生成。

图重放则是训练场景下的关键特性。在反向传播时，MLX 可以把正向计算图重放以计算梯度，这跟 PyTorch 每次动态构建图的方式不同。MLX 把图保存下来，在反向传播时重用，减少了构建开销。对于端侧微调和 Agent 的强化学习实验，这个特性很实在。

实操上当心一个坑：惰性求值意味着你可能在调试时发现某个变量的值没有更新。如果你习惯了 Python 里的即时数值，用 MLX 时老觉得结果不对，其实是因为还没触发求值。最简单的调试方法是调用.item()方法强取标量值，或者用print(array)触发求值。

2.2 量化与内存预算：4-bit 推理的参数选择

端侧跑模型，绕不开量化。目前主流方案是 4-bit 量化，即在保证相对可用性的前提下，把权重的内存占用降到原来的八分之一。M 系列芯片的内存是统一的，这意味着模型能占多少内存，直接决定了它是否能在当前设备上跑起来。

量化参数的选择涉及两个维度：精度损失和内存节省。4-bit 量化通常牺牲少量精度，换来更大的上下文窗口和更高的并发度。如果你跑的是 Qwen3 这类模型，4-bit 版本在 8GB 内存的 MacBook Air 上也能流畅运行，但 8-bit 可能就需要 16GB 以上内存才能跑出合理的吞吐。

我在实测中用的配置大致如下表：

注意，内存占用只算了模型权重，跑推理还得留出 KV Cache 和中间激活值。上下文越长，KV Cache 占用越高。所以实际内存预算通常要按模型权重的 1.5 倍来算。如果你只有 8GB 内存，还想跑 7B 模型，就得把上下文限制在 2048 token 以内，否则会吃满内存触发磁盘交换，推理速度骤减。

MLX 自带量化工具，不需要自己写算子。加载模型时指定量化位宽即可，比如ModelConfiguration.quantizedParameters里的bits: 4，框架会自动把权重转成 4-bit 存储，run 时再反量化计算。这里也要注意，反量化过程会消耗额外计算资源，所以 4-bit 模型的生成的 token 速度通常略低于 8-bit，因为需要额外做一个浮点转换。但节省下来的内存能让你跑更大的模型或者更长的上下文，综合收益是正的。

2.3 Swift 端模型加载的路径选择

在 Apple 平台加载模型，有两条主流路线：Core ML 和 MLX。两者不是互斥的，而是各有适用场景。

Core ML 的优势在于与系统框架深度集成，支持通过自然语言处理、视觉等系统 API 直接使用模型，也能让模型跑在 Neural Engine 上。它是 Apple 官方推荐的模型部署格式，工具链成熟，但让你自定义底层计算策略的空间有限。如果你要跑的模型可以顺利转化到 Core ML，且主要是处理标准任务，那这条路会非常省电、省内存。

MLX 的优势在于动态性和灵活性。它不是一个部署格式，而是一个计算框架。你可以加载 PyTorch 或 Hugging Face 的权重，动态构建网络结构，支持自定义的注意力实现、采样策略、工具调用循环。MLX 也能调用 Metal 跑在 GPU 上，但它的加速主要来自融合的算子实现和惰性求值优化，不是依赖 Core ML 的图优化。

我的选择策略很直白：如果模型结构固定、输入输出规范，用 Core ML；如果需要自己控制采样、需要动态处理 Agent 工具调用的字段、需要随时在 CPU/GPU 间切计算，用 MLX。Apple 补工具链也印证了这一点，那些官方发布的端侧示例，大多也同时提供 Core ML 和 MLX 两版代码，让开发者按需选择。

3. 实操过程与核心环节实现

3.1 搭建 Swift + MLX 项目：从包依赖到第一个推理

新建 Swift 项目不需要 Xcode 的模板，直接命令行初始化也行。

mkdir swift-mlx-agent cd swift-mlx-agent swift package init --type executable

在Package.swift里加入 MLX 依赖：

// swift-tools-version:5.10 import PackageDescription let package = Package( name: "swift-mlx-agent", platforms: [ .macOS(.v14) ], dependencies: [ .package(url: "https://github.com/ml-explore/mlx-swift", from: "0.0.10"), ], targets: [ .executableTarget( name: "swift-mlx-agent", dependencies: [ .product(name: "MLX", package: "mlx-swift"), .product(name: "MLXNN", package: "mlx-swift"), .product(name: "MLXLMCommon", package: "mlx-swift"), ] ) ] )

MLX 的 Swift 包拆得很细，MLXNN提供神经网络层，MLXLMCommon提供语言模型的公共加载和生成逻辑。官方还提供了MLXLLM模块，内置了从 Hugging Face 拉取权重的代码。

加载一个模型并跑一次生成，核心代码非常短：

import MLX import MLXNN import MLXLMCommon import MLXLLM // 加载模型的配置文件与权重 let modelConfiguration = ModelConfiguration(id: "mlx-community/Qwen3-8B-4bit") let loader = ModelLoader() let modelContainer = try await loader.loadModel( configuration: modelConfiguration ) let generator = ModelGenerator(modelContainer: modelContainer) // 生成回复 let prompt = "你是一个帮助用户处理任务的助手。请用简短语言回答。" let result = try await generator.generate(prompt: prompt, maxTokens: 512) print(result.output)

这里有几处细节值得注意。mlx-community是 Hugging Face 上的一个组织，专门放 MLX 格式的量化权重，模型 id 直接写组织名加模型名，加载器会自动拼接地址下载。如果网络慢，可以先手动下载权重放到本地缓存路径，加载器支持本地路径读取。

第二个细节是generate内部的采样参数。默认配置可能跟你期望不同，如果你想要更稳定的输出，可以手动构造GenerateConfiguration：

var config = GenerateConfiguration() config.temperature = 0.7 config.topP = 0.9 config.maxTokens = 1024 let result = try await generator.generate( prompt: prompt, configuration: config )

maxTokens不仅限制输出长度，也间接限制 KV Cache 占用的内存。如果你的设备内存紧张，把它设成 256 或者 512，能明显降低峰值。

3.2 构建本地 Agent 的工具调用核心循环

真正的 Agent 不是简单的“一问一答”，而是要让模型感知到它可以调用外部工具，并在适当的时机返回一个结构化的调用请求。在 MLX 上完成这个流程，核心是一个解析循环。

我在 Swift 里的实现思路是这样的：

1. 定义工具协议，每个工具包含名称、描述、参数 schema 和调用逻辑；
2. 将工具的 JSON schema 拼进系统提示词，让模型知道可用工具；
3. 模型生成回复时，可能返回普通文本，也可能返回工具调用标记；
4. 解析到工具调用标记后，停止生成，执行相应工具函数，把结果拼接进对话历史；
5. 带着更新后的消息列表再次调用模型，直到模型不再请求工具。

用伪代码表示：

struct Agent { var model: ModelGenerator var tools: [any Tool] var messages: [Message] mutating func run(userInput: String) async -> String { messages.append(.user(userInput)) while true { let output = try await model.generate( prompt: buildPrompt(from: messages), maxTokens: 512 ) if let toolCall = extractToolCall(from: output) { let tool = tools.first { $0.name == toolCall.name } let result = try await tool.call(parameters: toolCall.arguments) messages.append(.assistantToolCall(...)) messages.append(.toolResult(result)) } else { return output } } } }

这个循环听起来简单，但真正的坑在解析环节。主流模型在工具调用上并不统一输出格式，有的输出 JSON 包裹，有的输出 markdown 代码块，还有的直接输出函数调用语法。如果你只依赖字符串匹配，很容易解析失败。我的经验是，先用正则提取可疑的 JSON 片段，再做一次 JSON 解码校验；如果失败，把原始输出直接丢给模型，让模型自行纠错，或者把它当作纯文本回复返回给用户。

有一个通用的技巧：在系统提示词里强制要求模型只输出严格的 JSON。虽然会损失一点点对话的自然度，但对 Agent 来说稳定性优先。如果模型不遵守，你还可以在采样配置里降低 temperature，减少随机性，模型更倾向于按照格式输出。

3.3 使用宏系统简化 Agent 的声明式编写

Swift 的宏系统是 5.9 引入的重型武器。你可以在编译期生成大量样板代码。对于 Agent 而言，最实用的场景是自动把 Swift 函数转换成工具描述。

比如，你可以这样定义工具：

@Tool func getWeather(city: String) -> String { // 调用某个天气 API return "\(city) 的天气：晴，24 度" }

在宏展开时，编译器自动把函数名、参数名、注释解析成 JSON schema，并注册到工具列表中。这样程序员不需要手写和维护两份描述，函数签名变了描述自然跟着变。

宏实现的核心是用 SwiftSyntax 解析函数的定义，提取函数名、参数列表、文档注释，生成添加描述信息的代码。虽然写宏本身有一点学习曲线，但在 Agent 工具数量超过五个之后，收益非常明显，因为手写 schema 极容易漏掉参数说明，导致模型生成错误的参数。

另一个实用宏是自动生成上下文管理代码。你可以给 struct 添加@Context宏，让它自动管理消息数组的读写，以及裁剪超长历史。这样，Agent 的核心业务逻辑不会被一堆历史管理代码淹没。

3.4 与 AppleScript / 本地应用的集成

本地 Agent 最强大的地方在于它可以操纵你本机的应用。在 macOS 上，最常见的做法是通过 AppleScript 或者指令接口控制应用。Swift 里可以直接调用NSAppleScript执行脚本，或者通过Process调用可执行文件。

这里要特别提醒权限问题。macOS 的沙盒机制和隐私保护会影响 Agent 调用本地应用的权限。如果你的 Agent 以命令行工具方式运行，需要配置 App Sandbox；如果没有正确处理权限，执行 AppleScript 时会遇到“not authorized”错误。调试时最省事的方法是暂时关闭沙盒，在entitlements文件中删除 sandbox 声明，但在正式发布时必须谨慎处理。

我的经验是，对系统敏感资源（比如通讯录、邮件）的访问要设计成显式授权模式，Agent 每次调用前弹出确认窗口，不要让模型自动读取敏感数据。这是产品设计上的底线，也是安全审计的基本要求。

4. 常见问题与排查技巧实录

4.1 内存暴涨与设备交换

在端侧跑模型，最典型的故障是刚开始速度正常，几个回复后突然变慢，甚至进程被杀。根因通常是 KV Cache 累积超出预期，或者历史上下文没有裁剪。

MLX 的生成器会在每次调用时根据当前消息列表构建输入，如果你把全部历史消息都传给模型，token 数就会线性增长。当输入 token 超过某个阈值，上下文占用内存会显著上升，触发系统内存压缩。

这在长会话尤其是 Agent 多轮工具调用的场景里很容易发生，工具返回的文本越长，情况越糟。我的处理方式是每次生成后，统计当前输入 token 数，超过设定上限时，将最早的消息裁剪掉，只保留系统提示词和最近几轮对话。核心代码就是一个简单的数组操作，但收益很明显。

还有一个小技巧：工具调用的结果不需要完整传入下一轮模型。你可以让工具只返回一个摘要或者压缩后的状态。比如一个天气查询工具，下一轮模型关心的是结果是否可用，而不是完整的 response body。在工具调用逻辑里增加description字段，只把它的前 200 个字符拼入消息，能大幅减少 token 消耗。

4.2 模型输出的格式不稳定

工具调用的格式解析可以说是本地 Agent 开发里最磨人的问题。即使模型是同一个版本，temperature 稍作调整都有可能影响输出格式。更不用说不同模型厂商微调后的行为差异。

我在项目中尝试过几种策略：

• 强制系统提示词：用非常明确的措辞要求模型输出 JSON，并且提供正反例；
• 设置较低 temperature：比如 0.3，让模型倾向于高概率路径，减少随机输出；
• 后处理纠错：检测到输出不是合法 JSON 时，尝试提取{}包裹的部分，甚至是反引号里的代码块；
• 失败重试：将“你的输出无法解析，请严格按照提示词格式输出”作为用户消息追加，再次调用模型；
• 模板化输出：让模型先输出“调用工具名”，再进行 JSON 参数解析，减少嵌套的复杂性。

这些策略的具体优先级要看你的模型选型。如果你用的是 Qwen 这类对工具调用做了特别训练的模型，那么模板化的成功率会很高。如果你用的是通用对话模型，就需要更强的后处理兜底。

4.3 编译错误与 Xcode 版本不一致

MLX Swift 包更新速度很快，偶尔会引入 API 破坏性更新。我在升级过程中遇到过几次因为方法签名变化导致的编译错误，比如generate的参数从GenerateConfiguration变成GeneratePrompt，或者ModelGenerator的初始化方式改变。

解决这类问题最直接的方法是锁定依赖版本，不要用from: "0.0.10"这种宽松范围，而应该用.upToNextMajor或者直接指定精确版本。如果升级到了一个新版本，可以先去看 GitHub 仓库的 Release Notes，大多数破坏性更新都有迁移说明。

另外，Xcode 的版本也会影响 Swift 宏的使用。宏功能依赖 Swift 编译器前端，如果你还在用旧版本的 Xcode，可能连依赖的编译都无法完成。建议保持 Xcode 至少 15.3 以上，Swift 语言版本 5.10 以上。

4.4 工具调用超时与并发问题

本地 Agent 调用外部 API 时，可能遇到网络超时、进程阻塞。Swift 的并发系统用async/await可以很好的处理超时，但要注意不要在 GPU 推理线程里直接做网络请求。GPU 推理本身是阻塞调用，如果你在同一个任务里既做推理又做网络请求，Agent 的响应时间会叠加，体验变差。

我的做法是每个工具单独封装成async函数，并通过Task并发调用。如果某个工具响应慢，在超时时间到之后主动取消任务，将错误信息反馈给模型，让模型决定如何处理。这在多层工具调用时非常关键，因为某一层失败不应该导致整个 Agent 崩溃。

在并发上还有一个注意点：ModelGenerator不是线程安全的。多个Task同时调用同一个生成器实例可能会触发数据竞争，导致崩溃或者输出错乱。我的方案是为 Agent 加一个串行执行队列，或者每轮对话创建一个新的生成器实例。考虑到模型加载成本较高，更优方案是用 actor 隔离：

actor ModelExecutor { let generator: ModelGenerator func generate(prompt: String, config: GenerateConfiguration) async throws -> String { try await generator.generate(prompt: prompt, configuration: config) } }

这样即使外部多个并发任务同时调用，ModelExecutor内部的执行仍然是串行的，从根源上规避了数据竞争。

4.5 排查清单速查表

下面是我在日常调试中使用的快速定位表：

5. 工具选型与生态现状

5.1 MLX 与核心工具链的对比

面对一个具体的端侧 AI 任务，开发者可能会在 MLX、Core ML、PyTorch 之间犹豫。我自己的结论是：

• 如果你想快速做原型验证，用 PyTorch + Hugging Face，生态最全；
• 如果你想部署到生产且使用固定模型结构，用 Core ML，能耗最优；
• 如果你想深度集成 Agent 逻辑，且希望代码简洁、运行高效，MLX 是综合最优解。

MLX 和 Core ML 甚至可以直接配合。比如先用 Core ML 做语法分析和文本预处理，然后把核心生成任务交给 MLX。这比单纯用某一端更有弹性。

关于性能，MLX 的 token 生成速度在 Apple Silicon 上表现不俗。7B 模型实测大约每秒 20-40 token，取决于批大小、上下文长度和设备型号。这个速度在 Agent 场景下已经可用。如果你需要每秒上百 token 的高速推理，那只能选择更小的模型或者低精度量化，或者等待 Apple 不断优化 Metal 内核。

5.2 Agent 框架与编排

生态里已经出现了多种 Swift 原生的 Agent 编排库，虽然比 Python 生态少，但质量在快速提升。官方库的演进方向，也看得出 Apple 在刻意让 Swift 成为端侧 Agent 的首选语言。

当前主流的编排思路跟 LangChain 类似，但在 Swift 里更强调编译时安全和并发隔离。我自己比较喜欢在一个 struct 里定义整个 Agent 的依赖和工具，然后通过 protocol 注入模型和服务。这样测试时可以用 mock 工具替换真实 API，方便做单元测试。

当然，Agent 编排不仅仅是工具调用。你还需要考虑记忆持久化、会话恢复、多 Agent 协作。Apple 的工具链现在还没有一个统一的方案，但 Swift 生态里的 SQLite 集成、Swift 语言自带的 Codable 编码，已经足够支撑这些需求。我目前的做法是把会话历史编码成 JSON 存到本地文件，启动时重新加载，Agent 的决策状态也可以序列化，保证进程被杀后还能恢复。

5.3 从端到端：一套比较完整的项目结构

最后分享一个我比较推荐的 Agent 项目分层：

• 模型层：负责加载 MLX 模型、统一发消息、生成 token，只关注模型和文本；
• 工具层：定义工具协议，实现具体的 API 调用和本地应用指令，每个工具是独立模块；
• Agent 编排层：负责循环决策、格式解析、上下文管理，不关心具体工具实现；
• 入口层：命令行交互或者 SwiftUI 界面，负责向用户展示状态，接收输入。

这种分层的好处是每一层都可以单独测试。模型层可以只验证推理结果；工具层可以脱离 Agent 单独测试调用；Agent 编排层可以注入假工具来模拟各种分支；入口层只需要处理 UI 状态。经过几次重构，我把几乎所有 bug 都挡在了单测里，线上出错的概率大大降低。

6. 实操心得与避坑经验

聊点更容易被忽略但实际影响很大的细节。

第一，MLX 的加载权重会占据大量内存，所以如果你在一个大型 SwiftUI 应用里集成 Agent，不要让 Agent 常驻。建议用延迟加载的方式，在用户真正进入 AI 功能页时才初始化模型；退出页面时主动释放缓存，包括modelContainer对象。这能显著降低内存峰值，避免被系统杀掉。

Second，用 MLX 跑 Agent 时，尽量把采样参数设置成稳定模式。Agent 的核心是完成任务，不是写诗。temperature 0.3 到 0.7 之间通常效果最好，太高容易瞎编。上下文窗口短一点不要紧，关键是每次输出都符合预期。

Third，优先保证工具调用的失败率低。你可以写一个专门的单元测试，给定各种模型输出，验证解析函数能否正确提取工具名和参数。这类测试占用的时间极少，但能给你后续开发省下大量排查时间。

第四，不要在模型提示词里放太多无关内容。很多新手为了让模型表现得“聪明”，系统提示词写了一长串，导致模型反而忽略了工具 schema。我的经验是，把系统提示词压缩到必要的最小范围，将工具 schema 作为用户消息注入，或者放在独立字段，这样模型更关注工具调用。

最后，如果你准备发布一个端侧 Agent 的 MVP，做一个命令行版本就够了，不需要先搭 UI。命令行版本调试方便，能迅速验证模型行为。等决策循环稳定后再套一个 SwiftUI 外壳，才是最务实的路线。

关于安全这条线也得专门提一句。Agent 的能力越强，越需要谨慎管理它的权限边界。不要让 Agent 自动执行危险命令，不要让它读取全盘文件。可以给每个工具设计权限等级，在用户界面上展示工具的调用历史和消耗。尤其当模型通过工具拿到系统信息后，它可能把敏感内容拼进后续提示词，从而被另外一个工具发送出去。这种数据流动风险在本地 Agent 里看起来没有网络传输，其实依然存在，因为模型可能在输出里泄露上下文。最稳妥的做法是每个工具内部不要返回原始敏感内容，而只返回脱敏后的摘要，同时在不必要时剥离敏感字段。

这一波 Apple 补齐 Swift AI 工具链，对开发者来说是一个明确的信号。MLX + Swift 的组合已经足够支撑端侧模型运行和本地 Agent 构建，而且整个生态正在快速完善。如果你愿意多花一点时间研究 MLX 的惰性求值和量化细节，用 Swift 写 Agent 的体验会比预期顺畅得多。我现在的主力项目已经完全切换到这条路线上，实际跑下来的稳定性和开发效率都超出我的预期。接下来我计划继续把多 Agent 协作和记忆持久化做扎实，让本地 Agent 在无人值守的情况下也能长时间稳定工作。