Mac mini本地AI实战：Ollama+Hermes Agent搭建个人智能系统

把几千份PDF、几百篇笔记交给云端AI处理，总让人心里不踏实。但如果这些资料能在自己的Mac mini上被自动整理、分析、归档，甚至操作浏览器——这就是本地AI Agent的价值所在。

本文基于B站UP主的实战分享，梳理如何在Mac mini上搭建一套Ollama负责推理、Hermes Agent负责执行工具调用的本地AI系统，并给出分阶段落地的具体建议。

一、先搞懂模型：千问3.6-35B-A3B到底是什么

混合专家架构的"小分队"逻辑

千问3.6-35B-A3B这个名字可以拆成三段理解：千问3.6是模型系列，35B代表总共约350亿参数，A3B是关键——处理每个Token时实际只有约30亿参数参与计算。这背后是混合专家架构（MoE）。

打个比方：一家有350名工程师的公司，传统模型每次接到项目都全体开会；MoE则像只派出一支小分队。总参数多、知识库大，但每次工作只激活一小部分，在计算成本和模型能力之间取得平衡。

MoE 的"小分队"并不是随机派出的，而是由一个路由网络（Router/Gating Network）在每次处理 Token 时打分决定。以千问3.6-35B-A3B 为例，模型内部被切成若干"专家"子网络，路由只挑选其中少数几个（Top-K）参与计算，其余专家保持休眠。这样做的好处是：模型的总参数决定了它见过多少知识、能表达多复杂的函数，而激活参数只决定每次推理的计算量和内存带宽消耗。代价是对显存/内存的"静态占用"依然按总参数量算——专家虽然没被激活，权重还是得常驻在内存里等待被调用，这也是为什么 35B-A3B 跑起来并不比同激活量级的稠密小模型省内存。

理解这一点后，就能明白为什么 MoE 更适合"大而全但每次只干一件事"的本地场景：你花内存换知识面，用路由换速度。

内存账本：文件大小不等于运行内存

一个常见误解是：激活参数只有30亿，那是不是只需要30亿参数的存储空间？并不是。你电脑上必须存着整个模型的权重——原始精度下约70GB，用量化技术压缩后，比如4位量化，文件大小降到23-24GB左右，这也是Ollama上能下载到的千问3.6-35B量化版本大小。

但模型文件大小还不等于运行时占用的全部内存。你还得算上上下文缓存、推理框架、操作系统，以及同时开着的浏览器、视频软件等。

32GB内存的Mac mini能跑35B模型吗？可以，但属于内存比较紧张的配置。一旦开始大量使用硬盘当虚拟内存（交换内存），速度就会明显下降。32GB的Mac mini更适合跑经过量化、上下文长度合理限制的版本。具体能跑多快，最靠谱的方法还是装到自己的电脑上实测——芯片、内存带宽、推理引擎、量化格式都会影响结果。

量化（Quantization） 是让大模型能在消费级设备上跑起来的关键技术。模型权重在训练时通常是 16 位浮点（FP16）甚至更高精度存储，量化就是把这些数值压缩成 8 位、4 位甚至更低的整数表示，用更少的比特近似原来的数值。4 位量化意味着每个权重只占半个字节，理论上能把 70GB 的 FP16 模型压到 17-18GB 左右，实际因为要保留少量高精度参数和元数据，最终文件通常在 23-24GB。

量化必然带来精度损失，但损失多大取决于算法（如 GPTQ、AWQ、GGUF 的 K-quants 等）和模型本身的冗余度。经验上，4 位量化对多数日常任务（总结、分类、问答）的影响很小，但在需要精细推理、长链数学或严格格式输出的任务上，掉点会更明显。所以"能跑"和"跑得好"是两回事——量化等级、上下文长度、推理框架三者共同决定最终体验，建议先用高量化版本测任务质量，再逐步降级换速度。

二、Ollama和Hermes Agent：发动机与驾驶系统

这两个工具经常让人搞混，但它们干的活完全不同。

Ollama是模型运行平台：下载模型、加载、推理、返回结果。它像发动机。

Hermes Agent是智能工作系统：能通过工具调用操作文件、执行终端命令，有自己的记忆和流程。它像驾驶系统。

两者不是竞争关系，而是配合关系。Ollama提供推理能力，Hermes Agent根据任务安排动作、利用工具完成工作。

你可能没注意到，Hermes最近也变强了——它现在不仅能连接外部推理服务，也能自己管理本地模型，能自动安装llama.cpp推理运行时并针对硬件优化（比如在苹果M系列芯片上利用Metal加速）。

这带来两条路径：一是Ollama下载运行模型、Hermes连接Ollama；二是Hermes自己管理模型和推理服务。如果你已经装了Ollama，且希望同一个模型服务多个软件（比如Hermes和其他AI客户端或知识库软件），第一条路更合适——Ollama可以作为统一的模型服务入口，避免每个软件重复下载模型。

记住一句话：Ollama解决模型怎么运行，Hermes Agent解决模型如何工作。 用同一个模型，不会因为走Hermes就更聪明——模型的基础能力由模型本身决定，Hermes的价值在于组织工具和任务。

三、三个真实可落地的自动化场景

如果只是聊天，真没必要费劲装本地。本地AI Agent的价值在于自动化工作流。

场景一：个人知识库维护

假设你用Obsidian存了几千篇笔记。以前这些笔记是静态的，得自己搜索阅读整理。现在可以让Hermes Agent连接本地知识库，给出任务："检查知识库，把最近一个月新增的AI Agent技术资料分类，找出内容重复的笔记，建议建立哪些双向链接。"

Hermes读取资料交给千问模型分析，生成整理建议。第一阶段只让它生成方案，别直接覆盖原始笔记——AI也会犯错，等方案验证通过再逐步放开权限。

场景二：内容创作的流水线

假设你运营一个读书解读频道，每隔三天要找话题、挑书、写口播稿、想标题和文案。这套工作可以拆解：用联网工具获取公开信息→Hermes整理成文本→本地千问模型做主题归类、提炼观点、生成初稿→人工审核事实和调整观点。

大量重复性文字整理工作留在本地完成。但要注意：本地模型不会因为装在电脑里就自动知道最新信息，它仍需要搜索工具获取新闻热点；它也不会天然会剪辑视频、发布内容，这些需要Hermes对应工具或外部软件完成。

场景三：文件批量处理

日常整理几十个文件、按类型归档、提取关键信息，这类高频重复任务正是本地模型的用武之地。长期来看，比反复调用云端API更经济。

四、动手搭建：从Ollama到Hermes的三步走

第一步：安装Ollama并下载模型

安装最新Ollama后，打开终端输入下载命令（拉取千问3.6-35B），下载完成后运行，即可在终端与模型对话。第一次测试别搞复杂的——给它一篇长文，让它总结三个核心观点，观察回答质量和速度。如果特别慢，打开活动监视器看内存压力。

第二步：连接Hermes Agent

在终端进入Hermes的模型配置，选择自定义模型接口，设置API地址和模型名称。关键点：Hermes里的上下文长度配置必须和实际运行的Ollama服务匹配。

上下文长度（Context Length） 在这里是个容易被低估的坑。它指模型一次能"记住"的 Token 总量，包括你的输入、工具返回的内容和模型的输出。Ollama 启动模型时可以指定 num_ctx（例如 8192、32768），而 Hermes 里也有自己的上下文预算配置。如果 Hermes 按 32768 去发请求，但 Ollama 实际只加载了 8192，超出部分会被静默截断——表现为模型"忘了"你前面说过的文件内容，或工具调用结果被丢弃，任务莫名失败。

反过来，把上下文设得过大也会吃内存：KV Cache 会随上下文线性增长，长上下文下 32GB 内存很快被撑满。建议做法是：在 Hermes 中把上下文限制设成与 Ollama 一致的较小值（如 16K），把"需要长记忆"的需求拆解成多轮小任务，或依赖 Agent 的检索/记忆工具来补偿，而不是一味加大窗口。

第三步：分三阶段测试执行能力

第一阶段：读几个文件、整理报告。第二阶段：对一个文件夹里的文件提分类建议。第三阶段：得到确认后再执行实际修改。

为什么要分这么细？因为要区分两件事：模型能不能理解任务和智能体能不能安全准确地执行任务。AI犯错难免，涉及文件删除、安装软件等操作时必须有确认机制。

五、模型选择：35B不一定比27B快

大模型不是越大越适合个人电脑，必须同时考虑质量、速度和稳定性。

• 9B左右小模型：占用资源少、响应快，适合快速分类、提取关键词
• 27B左右模型：需要更多资源，但综合分析能力更强，适合长文解读、代码分析
• 35B-A3B混合专家模型：用较少激活参数获得大模型的部分能力，但在Mac mini上仍需不小内存

35B不一定比27B快——如果它让电脑频繁使用交换内存，体验可能还不如小模型。建议先用小模型把工作流程跑稳定，再测试35B，确认内存、速度和任务完成率都可接受后，再考虑设为主力模型。

六、本地还是云端？分层系统才是答案

没必要把所有任务都转移到本地。

本地优势：数据控制权、适合高频重复任务、长期比反复调API省钱。

云端优势：复杂推理、困难工程问题，能力更强的云端模型效率更高。

更推荐建立分层系统：

• 第一层：本地小模型负责快速分类、简单总结
• 第二层：本地千问3.6-35B负责知识库分析、程序辅助
• 第三层：云端高能力模型负责疑难问题和重要结果复核
• Hermes Agent作为统一操作入口

七、三个容易被忽略的问题

第一，所谓的完全隐私。 用本地模型处理本地文件，推理过程确实在本地。但如果Hermes调用了搜索服务、云端模型或第三方插件，数据仍可能离开电脑。真正的隐私保护要看整个工具调用流程。

第二，成本问题。 存储和维护成本也要算。如果用得少、偶尔分析一次，云端服务可能反而更划算。

第三，稳定性远比参数重要。 我们容易被参数和排行榜吸引，却忽略任务完成率。一个模型能解高数题，不代表它执行十次文件操作不出错。真正决定AI Agent实用性的是工具调用格式、错误恢复、上下文管理这些能力。

测试本地模型时，别光问它答得聪不聪明，更该问：给它十个真实任务能完整完成几个？执行中需要频繁人工干预吗？出错了能自己修正吗？这些指标远比参数规模更接近真实生产力。

结语

Ollama + Hermes Agent + 千问3.6-35B在Mac mini上值不值得部署？值得尝试。但最值得尝试的不是追求运行最大的模型，而是建立一套能长期使用的个人AI系统——让Ollama或Hermes负责运行模型，让Hermes Agent负责调用工具处理任务，让本地文件夹成为知识资产中心，让云端AI负责本地暂时搞不定的复杂工作。

这套系统不会因为装了某个模型就突然无所不能，但它能随着工具完善、流程优化和知识库积累逐渐变得实用。未来个人AI的竞争，也许不只是看谁有最强的模型，而是看谁能把模型、工具、数据和真实工作流程结合得更好。

背景补充

工具调用（Tool Calling / Function Calling） 是 Agent 区别于聊天机器人的核心能力：模型不再只输出自然语言，而是按约定的 JSON 结构输出"我要调用哪个工具、传什么参数"，由外部程序执行后再把结果喂回模型。这要求模型经过专门的后训练，能稳定地产出格式正确的调用指令。

本地小模型常在这一环掉链子——格式漏括号、参数类型搞错、该调用时闲聊、不该调用时乱调，都会让整个流程崩掉。这就是为什么评测 Agent 实用性的关键指标是任务完成率和错误恢复能力：前者衡量 N 个真实任务里能端到端跑通几个；后者衡量一次工具调用失败后，Agent 能否读取报错、修正参数、重试而不是卡死。这些能力与参数量并非线性相关，一个经过工具调用微调的 9B 模型，往往比未调优的 35B 在这种场景下更可靠。选模型时，优先看它在你的真实任务集上的完成率曲线，而不是通用榜单分数。