如果你刚看完 WWDC 上关于 Siri AI 的更新第一反应可能是“苹果终于认真做 Agent 了”。但如果你真正在本地部署过大模型或者用 Ollama 搭过自己的“私人 AI”你会意识到另一件事Siri AI 的能力并不来自某个凭空变出来的超级大模型而是来自一套分工清晰的运行时架构——端侧模型负责感知后台 Server 分担复杂推理Agent 逻辑负责把任务拆解、调用工具、再把结果串起来。这和目前开发者圈流行的“本地大模型 Agent”其实是同一个故事模型是大脑Server 是血液循环系统分布式推理是跨设备调度Agent 是那个会主动行动的“人”。WWDC Siri AI 只是把这条路用消费级产品验证了一遍。对普通开发者而言真正值得追赶的机会不是复刻 Siri而是理解这套架构并把它用到自己的本地大模型应用里。这篇文章不会去讨论某个版本的 SQL Server 怎么安装也不是讲传统 Web Server 的并发调优。我要讲的是 Agent 开发中更接近底层的一件事当你准备用本地大模型做 Agent 时为什么要先有一个 Server为什么推理要“分配”到不同端侧和服务器完成以及如何用最少的代码跑通一个“本地大模型 工具调用 Agent 循环”的完整示例。1. 为什么 Siri AI 会让“Server 分布式推理”重新成为焦点1.1 从命令式助手到 Agent 的差距老版 Siri 更像一个“命令解析器”。你给它一句“设置闹钟 7 点”它匹配到系统闹钟 App 的入口然后执行。这个过程没有一个真正的“理解”环节也没有多步推理。但 WWDC 展示的 Siri AI 不太一样。它能在你提问之后把完成任务拆成几个动作跨应用调取当前上下文再根据执行结果做二次判断。从技术形态上看这已经是标准的 Agent 工作流接收用户的自然语言目标。拆解成多个子任务。调用不同应用或工具完成子任务。汇总结果并返回给用户。听上去很简单落地时却有一个绕不开的问题这个“拆解 调用 汇总”的推理过程放在哪里执行放在手机端本地模型参数量受限处理复杂任务容易露馅。放在任意云端又会频繁传出用户隐私无法达到系统级助手的权限和安全要求。于是苹果在公开架构描述中选择了“分层处理”把适合端侧的任务留给端侧小模型把更复杂的推理放到 Apple 芯片构成的 Private Cloud Compute 环境里完成。模型没有被锁死在某一台设备上而是被“分发”到了最合适的位置。这就是分布式推理的价值不一定是把你 100B 模型切到多张 GPU 上算矩阵乘法而是把 Agent 的不同环节分配到不同计算节点。1.2 普通 Agent 项目从这套架构里学到什么如果你把“Siri AI 的架构”等比缩小到自己的项目里会发现它和目前本地大模型 Agent 的开发方式高度相似端侧或本地负责处理敏感数据、快速响应、轻量推理。一台性能较好的本地 Server 负责运行真正的大模型。Agent 框架或自研调度程序负责决定“这一步该问本地小模型还是该调用远程 Server”。工具服务以独立 Server 形态存在例如天气 API 服务、文件系统服务、数据库操作服务。WWDC Siri AI 对开发者的最大启示不是“苹果又发布了新模型”而是它验证了一个趋势Agent 时代的应用不再是单个模型的文件大小竞赛而是模型服务化、任务分配、工具协同三件事的组合。这也是题目中说的“铺垫本地大模型 Agent”真正含义。2. 本地大模型 Agent 到底是什么概念与架构2.1 Agent 不是“聊天机器人换个名字”有些开发者看到 Agent 这个词会把它理解成“支持多轮对话的聊天机器人”。这是最大的误区。多轮对话只是一种交互方式Agent 的核心是“自主调用工具并完成目标”。如果一个系统只能根据用户输入生成一段文本哪怕这段文本很智能它仍然只是一个对话模型。但如果系统能做到下面任意一点才更像 Agent发现当前问题需要查询外部数据自己调用搜索或数据库服务。根据 API 返回结果决定下一步动作而不是机械地一问一答。把一个复杂任务拆成多个步骤并逐步验证。能访问应用上下文或系统权限主动执行操作而不只是“给建议”。Siri AI 的目标就是后者。你告诉它“帮我把刚才拍的照片整理成一个相册并发送给妈妈”它需要调用照片、联系人、相册、消息等多个系统模块。每调用一个模块都是工具调用每次拿到结果后的判断都是一次推理。建立在这个机制上的闭环是一个完整的 Agent 循环。2.2 四层架构与 Server 的位置一个可工作的本地大模型 Agent通常由四部分组成层级负责什么常见落地方案模型层提供语言理解与生成能力Qwen、Llama、Mistral 等开源模型推理服务层把模型包装成 Server提供 APIOllama、llama.cpp、vLLMAgent 调度层决定调用哪个模型、是否调用工具LangChain、Dify、自研 Agent 循环工具服务层为 Agent 提供可复用的外部能力MCP Server、HTTP API、内部函数库这里最容易混淆的是“Server”。在很多传统项目中Server 就是一台部署后端程序的机器或者一个处理 HTTP 请求的进程。在本地大模型 Agent 场景下Server 有三个不同含义必须区分清楚推理 Server比如 Ollama 或 llama.cpp 启动的本地服务模型跑在这个进程里暴露 OpenAI 风格的/v1/chat/completions接口。Agent Server承载 Agent 逻辑的常驻服务接收上游请求调度模型与工具返回最终结果。MCP Server把单个工具能力包装成可复用服务比如文件服务器、数据库服务器、搜索服务器。很多 Agent 项目刚开始能跑通后面变得难以维护原因就是这三个 Server 混在同一个进程里模型调用、工具逻辑、权限控制全部耦合在一起。WWDC Siri AI 的架构在公开层面虽然不完全透明但它体现出的模块独立性非常明确Apple 能随时更新某个 Server 端模型能力而不需要重装用户手机系统。普通项目也应该尽早沿用这个思路把推理服务、Agent 调度、工具服务拆开。3. “分布式推理”的分层路线端侧、本地 Server、云端3.1 分布式推理不等于“多机并行”一提到分布式推理很多人会立刻想到 Tensor Parallelism、模型切分、多 GPU 通信。那是训练和推理框架层面的分布式适合大模型平台团队。对绝大多数做 Agent 应用的开发者来说更值得关注的是另一种分布式把不同任务分发给不同模型和不同服务去执行。Siri AI 的分布式推理大体遵循这种思路。简单请求比如查看本地天气、读取通知可以由端侧小模型完成。复杂请求比如“帮我把这份文档总结成周报再按照我平时邮件风格发给同事”就需要服务器上的大模型来处理甚至还要调用邮件工具。这种按任务拆分、按层级下发的方式就是 Agent 应用里的“分布式推理”。它不追求把模型做大而是追求把模型摆在合适的位置避免把所有计算压力集中到一个点上。3.2 一个本地 Agent 项目里的推理分流策略如果你在自己的电脑上部署了 Ollama又在局域网里放了一台 4 卡 GPU 服务器同时可能还想调用云端大模型做最终润色那么你会遇到一个问题什么请求走哪条路实际项目里常用的分配策略有三种路由策略适用场景优点缺点本地优先隐私要求高、网络不稳定响应快、不依赖公网模型能力有限Server 优先团队共享能力、模型较大统一升级、权限可控对局域网 Server 稳定性要求高云端兜底本地模型不会、结果不满意可获得最强推理能力有数据外传风险成本高更成熟的系统会增加“嵌入模型”这一层。例如输入文档先由本地小模型做向量化再存入本地向量数据库检索、重排序、摘要这些环节都可以在不同的 Server 上执行。从这个角度看Agent 项目的“分布式推理”不是停留在概念上的前沿技术而是你做工程架构时每天都在用的事情。为什么这个主题会在 WWDC 之后被反复提起因为当 Apple 这样体量的公司开始把所有设备上的 AI 能力统一调度开发者的预期就被抬高了我们也应该让 Agent 在不同模型、不同 Server、不同设备之间自由切换。能做到这一点的前提是先把“模型”和“服务入口”分离也就是先有一个标准化的推理 Server。4. 实操准备选择本地推理 Server 与模型从这一节开始文章进入可复现的操作部分。下面所有步骤都围绕一个目标让读者能够有一个本机可访问的“推理 Server”再配合 Agent 代码完成一轮工具调用。版本细节请以实际官方仓库为准这里不写死某些具体版本号重点演示通用链路。4.1 选推理 ServerOllama 还是 llama.cpp本地大模型场景中使用最广的两个推理 Server 是 Ollama 和 llama.cpp。Ollama 是把下载模型、运行服务、暴露 API 打包在一起的开源工具。它的最大优势是上手快一条命令就能启动一个 OpenAI 兼容的服务还内置了模型管理能力。对于只是想先把本地大模型 Agent 链路跑通的开发者Ollama 是最低门槛的选择。llama.cpp 则更偏底层专注 CPU/GPU 混合推理支持量化模型适合需要单独编译优化或部署在低配机器上的场景。它的 server 模式同样也能暴露 OpenAI 风格 API但环境配置要更手动一些。如果要做一个严肃对比可以看这张表对比项Ollamallama.cpp上手难度低中模型管理自带简洁需要自己管理和转换模型文件官方服务接口OpenAI 兼容自带 server 也可提供 OpenAI 兼容接口二次开发自由度中等高适合人群Agent 应用开发者、产品验证推理优化研究者、嵌入式部署做 Agent 开发我更建议先从 Ollama 入手把注意力放在工具调用和调度逻辑上而不是陷进模型格式转换和量化参数调试里。4.2 硬件环境建议本地大模型 Agent 的硬件门槛并没有想象中高。一个通用经验是仅做接口测试和对话验证8GB 内存也能跑量化后的小参数模型。想要稳定支持工具调用建议 16GB 以上内存至少能运行 7B 级别的量化模型。想在本地流畅运行 14B 以上模型建议准备独立显卡或直接把 Server 部署到带 GPU 的机器上。需要注意模型选型必须和 Agent 任务匹配。如果只是做“总结文本”小参数模型表现不差如果要做 Function Calling也就是让模型输出符合 JSON 结构的工具调用参数那么模型本身必须支持 Tool Calling。Qwen 系列、Llama 系列近期的开源模型通常都具备这个能力但仍要以实际运行结果为准。4.3 安装与启动推理 Server以 Ollama 为例安装完成后先启动服务# 启动 Ollama 推理 Server默认监听 127.0.0.1:11434 ollama serve再打开一个新终端拉取一个适合本地 Agent 推理的中小型模型# 拉取 Qwen2.5 7B 指令模型具体标签以 Ollama 官方仓库为准 ollama pull qwen2.5:7b启动完成后你可以用以下命令验证模型是否就绪curl http://127.0.0.1:11434/api/tags如果能在返回 JSON 中看到你刚才拉取的模型名称说明这个本地推理 Server 已经正常工作了。到这里我们就有了一个可以随时被 Agent 程序访问的“模型服务层”。5. 把本地模型升级为“Agent Runtime”验证 OpenAI 兼容接口5.1 为什么 OpenAI 兼容接口很重要Agent 生态里很多框架默认只对接 OpenAI 接口。如果本地推理 Server 也能提供/v1/chat/completions那么你在切换模型时只需要改一个base_url。这也是 WWDC Siri AI 背后逻辑的一种简化版本客户端不需要关心模型跑在哪台 Server 上只需要面向统一接口发起请求。Ollama 只要启动就默认在http://127.0.0.1:11434/v1提供 OpenAI 兼容接口。你可以用下面这个 curl 命令直接测试curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ { role: user, content: 请用一句话介绍什么是 Agent。 } ], stream: false }正常情况下返回 JSON 里会包含choices[0].message.content并且包含完整的响应 ID、模型名和 token 统计字段。看到这个响应就说明你的本地大模型已经可以被任何支持 OpenAI 接口的 Agent 框架调用了。5.2 局域网访问的配置与安全边界如果你的 Agent 程序或前端并不运行在本机而是运行在局域网另一台电脑上那就不能只监听127.0.0.1需要让推理 Server 监听局域网可访问的地址。# Linux 或 macOS 下临时绑定 0.0.0.0具体配置方式依系统版本而定 OLLAMA_HOST0.0.0.0:11434 ollama serve然后局域网内另一台开发机就可以用http://服务器IP:11434/v1作为接口地址。在实际项目中我更推荐通过反向代理加 Token 认证的方式暴露这个地址而不是直接把 11434 端口映射到公网否则本地模型服务容易被任意人调用造成算力被滥用。生产环境里要尽量遵循最小权限原则只对 Agent 服务所在的内网段开放端口并且加上认证层。5.3 配置 Agent 时的模型切换当 Agent 程序要用本地模型时只需要把原来指向云端服务的 API 地址改成base_urlhttp://127.0.0.1:11434/v1 api_keyollamaAPI Key 只是本地占位真实服务不会校验它。这个设置会成为后面所有 Agent 示例的最小连接层。6. 完整示例用本地大模型 Server 驱动一个最小 Agent完成上面的部署后接下来编写一个真实可运行的 Agent 示例。这个示例会模拟一个常见生活场景用户询问“北京今天天气怎么样我要不要带伞”Agent 通过模型判断需要调用天气查询工具工具返回结果后Agent 再组织成自然语言答案。这里能够清晰看到 Agent 闭环的四个环节意图理解、工具调用、结果回传、回答生成。6.1 安装依赖pip install openai这里使用的是 OpenAI Python SDK但接口地址指向本地 Ollama。6.2 Agent 完整代码# agent_min.py # 运行前请确保 Ollama Server 已启动并已拉取 qwen2.5:7b 模型 import json from openai import OpenAI client OpenAI( api_keyollama, base_urlhttp://127.0.0.1:11434/v1 ) # 将 Agent 能调用的工具描述为 JSON Schema模型根据描述决定是否调用 tools [ { type: function, function: { name: get_weather, description: 查询某个城市的天气参数 city 是中文城市名, parameters: { type: object, properties: { city: { type: string, description: 城市名例如北京 } }, required: [city] } } } ] def get_weather(city: str) - str: 真实项目里可以换成天气 API 调用这里用模拟数据保证示例可离线运行 mock_table { 北京: 晴26 摄氏度紫外线中等, 上海: 小雨24 摄氏度建议带伞 } return mock_table.get(city, f暂无{city}的天气数据) def run_agent(user_input: str) - None: messages [{role: user, content: user_input}] # 第一次请求让模型判断是否需要工具以及选择哪些工具 resp client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools, tool_choiceauto, temperature0.2, streamFalse ) message resp.choices[0].message # 模型认为不需要调用工具直接输出回答 if not message.tool_calls: print(Agent 回答, message.content) return # 模型决定调用工具把模型的 tool_calls 消息追加到历史中 messages.append(message) # 执行每一个工具调用并把结果以 tool 消息返回给模型 for call in message.tool_calls: function_name call.function.name arguments json.loads(call.function.arguments) print(fAgent 决定调用工具{function_name}({arguments})) if function_name get_weather: result get_weather(arguments[city]) else: result f未知工具{function_name} messages.append({ role: tool, tool_call_id: call.id, content: result }) # 第二次请求让模型参考工具返回结果生成最终回答 second_resp client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools, tool_choiceauto, temperature0.2, streamFalse ) final_answer second_resp.choices[0].message.content print(Agent 最终回答, final_answer) if __name__ __main__: run_agent(北京今天天气怎么样我要不要带伞)6.3 运行与预期结果执行命令python agent_min.py如果本地模型支持 Tool Calling 且配置正确你会看到类似下面的流程Agent 决定调用工具get_weather({city: 北京}) Agent 最终回答北京今天晴26 摄氏度紫外线中等不需要带伞。但这个预期输出只做参考。受量化精度、模型版本、temperature 设置影响模型可能在问“北京”时误判为不需要工具也可能直接返回一段不带工具调用的文本。如果遇到这种情况可以确认一下模型是否真正支持 Function Calling或者换参数量更大的模型继续测试。6.4 这段代码教会我们的三件事第一Agent 工具调用的本质是“模型的格式化输出”。模型不直接调用 Python 函数它只是在回答中输出一个结构化指令真正执行指令的是我们自己的代码。第二Server 层只是提供推理能力Agent 的决策循环要由应用代码负责。模型输出了一次工具调用不代表任务完成Agent 需要把工具结果再次交给模型才能生成用户可读的回答。第三所有工具调用记录必须按顺序保存在messages中否则模型无法理解上下文。这也是从聊天机器人升级为 Agent 后最容易出错的地方。7. 接入 MCP Server让本地 Agent 摆脱“硬编码工具”手动在tools列表里写 JSON Schema适合教学也适合工具数量很少的场景。一旦工具数量超过十个并且多个 Agent 项目需要复用同一套工具能力硬编码方式就会变得很脆弱。每个项目都复制一份工具定义后面修改接口时容易漏改。MCP也就是 Model Context Protocol提供了一种标准化的工具服务层。你可以把文件读取能力、数据库查询能力、天气服务都包装成独立的 MCP Server然后让 Agent 客户端动态发现这些工具。7.1 MCP Server 的配置样例假设你写了一个本地文件查询 MCP Server并想在一个支持 MCP 的 Agent 框架中使用它配置文件通常类似下面这样// mcp-config.json { mcpServers: { local-filesystem: { command: node, args: [path/to/your/mcp-server/index.js], env: { ALLOWED_PATH: /tmp/agent-data } } } }不同 Agent 框架调用 MCP 的方式并不完全一样但配置文件的结构大体相同。关键点是把“服务器地址”“命令参数”“环境变量”三项定义清楚。MCP 的价值在于让 Agent 学习到哪些工具可用而不是把工具文档塞进系统提示词里。7.2 为什么不推荐把所有工具都写进 Prompt有些团队为了省事会直接把工具说明写进 System Prompt“你现在有工具 A、工具 B、工具 C……请根据用户输入自己调用。”这种方案在小规模试验中能跑通但有几个明显问题模型上下文长度有限工具多了容易互相干扰。每次请求都重复携带全部工具描述浪费 token。工具参数变化后必须同步修改 Prompt 并重新测试维护成本高。没有真正执行能力模型只能“猜测”工具存在无法获得工具返回的结构化结果。MCP 把工具调用过程变成可复用协议既解决动态发现问题也让接口边界更清晰。未来的本地大模型 Agent 会越来越像一套“小系统”模型负责思考MCP Server 负责执行安全策略和结果校验由 Agent 框架负责。这里的“Server”不再是可有可无的进程而是 Agent 生产力的基础设施。8. 常见问题与排查本地大模型 Agent 为什么跑不起来从本地模型部署到 Agent 完整调用中间变量很多报错往往不是一个原因导致的。下面的排查表是根据社区常见实践整理的可以帮助你拿到一条报错信息后快速定位方向。问题现象可能原因排查方式解决方案调用接口超时或连接被拒绝Ollama 没有启动或绑定了错误的地址先 curl/api/tags确认服务是否存活启动ollama serve如果局域网调用则绑定 0.0.0.0模型一直返回普通文本没有 tool_calls 字段模型本身不支持 Tool Calling或提示词不够明确在代码里打印完整 JSON 响应或换一个已知支持工具调用的模型测试换成支持 Function Calling 的模型并加大 instruction 描述Agent 报错工具参数解析失败模型输出 JSON 格式不规范中文引号或多余字符打印message.tool_calls原始内容单独用 JSON 工具校验在解析前做 JSON 清洗或降低 temperature本地模型 Card 上显示支持工具但调用结果质量差模型参数量小量化损失较大用 7B 以上模型做对比选用指令微调和工具调用能力更强的模型版本局域网内其他电脑无法访问Ollama 监听在 127.0.0.1在服务器本机查看监听端口和防火墙规则改为监听 0.0.0.0只在内网或反向代理后暴露Agent 第一次工具调用成功第二次上下文丢失messages 历史没有追加 assistant tool_calls 信息检查发送给模型的 messages 顺序保证 user、assistant、tool 三种消息按发生顺序排列“Agent execution provider did not respond in time”推理 Server 响应过慢上游 Agent 客户端超时查看 Agent 客户端日志与模型服务日志调大超时时间或换效率更高的推理方案这些问题的背后通常都指向同一个设计原则模型是概率系统工具调用的触发永远不会 100% 稳定。因此 Agent 代码必须对“模型不调用工具”“模型调用错了工具”“工具返回异常”这三种情况做兜底。9. 最佳实践与工程建议在理解 Siri AI 的架构之后再结合本地大模型 Agent 的开发经验我觉得有几条建议值得长期遵守。第一把模型服务和 Agent 逻辑拆开部署。模型服务的升级频率比 Agent 业务逻辑更高底层推理引擎也随时可能因为新版本而变化。如果把它们耦合在同一个进程里一次模型升级可能要重启整个服务。更好的做法是维护一个独立推理 ServerAgent 程序通过 API 访问这样既能灰度切换模型也能单独监控推理耗时。第二不要一开始就追求在中低配机器上跑大模型。本地大模型 Agent 的第一目标应该是“跑通完整链路”而不是“得到最强回答”。先用 7B 左右模型跑通工具调用再根据效果决定是否升级到更大模型。升级模型时只需要改服务端配置和模型名称Agent 代码可以完全不动。第三重视工具调用数据记录。Agent 经常会因为模型幻觉选错工具或填错参数。每次调用都应该记录用户输入、模型输出的 tool_calls、工具返回结果、最终回答四段信息。这不仅是排查问题的依据也为后续调优积累了有价值的数据集。第四明确本地模型的服务边界和安全边界。不要在未加认证的情况下把推理 Server 暴露到公网。如果 Agent 要操作文件、数据库、邮件等敏感能力务必采用最小权限原则。工具能读取的数据范围要最小化工具能执行的动作要尽量可撤销。本地大模型不是完全可信的模型它的输出仍然可能被提示词注入利用因此不能把长期记忆、高权限 API Key、免确认执行都交给模型随意访问。第五Agent 与 MCP 的关系需要提前规划。前期项目可能只有两三个工具可以硬编码。但一旦开始做多 Agent 协作或希望其他团队也能复用你的工具服务尽早定义 MCP Server 模式更省力。建议把工具拆分成无状态服务每个服务只开放最窄的输入输出边界。也有人会问做了这么多是不是就能实现一个“本地版 Siri AI”从架构上说你确实把最核心的闭环搭起来了本地小模型负责部分意图判断推理 Server 承载真正的模型计算Agent 代码负责工具调度MCP Server 提供外部能力。接下来还需要补充记忆管理、权限授予、任务规划、用户偏好建模这些都是长期工程。如果今天只记住一句话那就记住这条WWDC Siri AI 让我们看到的不是一个无敌模型而是一条很务实的 Agent 工程路径——把推理放到 Server把任务分到不同层把 Agent 变成服务。本地大模型 Agent 的真正门槛也从来不是“你的显卡能跑多少 B”而是你能不能把模型、工具和服务串成一条稳定、可控、可复用的链路。