把本地 Ollama 模型接进 WorkBuddy 踩过的坑

写在前面

事情起因很简单：积分不够用。

WorkBuddy 这类 Agent 工具每轮对话都要烧积分，做深度调研、长代码分析这种任务，一轮下去几百积分就没了。我手上正好有张 RTX 4060 Laptop（8 GB 显存），心里想着能不能把本地跑的 Ollama 模型接进去——routine 类的任务走本地，复杂推理再走云端，积分能省下一大半。

配置过程比想象中顺利，但中间卡在一个非常诡异的现象上，前后折腾了快两个小时。这篇文章把完整的配置步骤和那个坑记录下来，希望能帮后来人省点时间。

本文环境：

• 系统：Windows 11，内存 32 GB
• 显卡：RTX 4060 Laptop，8 GB 显存
• Ollama：0.32.15
• 本地模型：qwen3.5:9b、qwen3:8b、deepseek-r1:8b
• 客户端：WorkBuddy 桌面版

一、先说配置流程

WorkBuddy 支持接入 OpenAI 兼容格式的自定义模型，Ollama 恰好提供了 /v1 兼容接口，所以整条链路是通的。

第一步，确认 Ollama 的兼容接口是活的。

Ollama 默认监听 11434 端口，http://localhost:11434/v1 就是它的 OpenAI 兼容端点。浏览器打开 http://localhost:11434/ 能看到 "Ollama is running" 就说明服务正常。

第二步，在 WorkBuddy 里添加模型。

左下角点头像 → Settings → 左侧导航选 Models → Custom Models 区域点 Add Model：

• Provider：选 Custom
• Endpoint：http://localhost:11434/v1/chat/completions
• API Key：随便填一个，比如 ollama。Ollama 不做校验，但这个字段不能空着
• Model Name：填模型名，必须和 ollama list 输出的完全一致，包括 tag
• Advanced Settings：建议勾选 Tool Calling、Image Input、Reasoning

保存之后，模型选择框里就能看到刚加的模型了。

到这里为止，一切正常。然后我就掉坑里了。

二、诡异的现象：测试通过，派活就废

添加模型时客户端会做一次连接测试，返回绿灯——通了。

我兴冲冲地开了个新任务，让它帮我分析一个本地项目的代码结构。然后它就没反应了。 不是报错，不是崩溃，就是卡在那里，最后要么超时，要么回一句莫名其妙的空内容。

第一反应是模型太小、能力不够。换了个更大的模型，还是一样。再怀疑是端口或者网络，查了一圈都正常。

最让人困惑的地方在于：连接测试明明是通过的。 测试能过，说明链路是通的；真干活就不行，说明问题出在"干活"和"测试"的差别上。

差别是什么？输入长度。

三、排查：ollama show 骗了我

我一开始是这么查上下文窗口的：

输出里赫然写着 context length 是 32768，甚至更大。我心想这没问题啊，三万多 token 的窗口怎么也不该卡死。

后来才知道，这个值来自模型的配置文件，是理论上限，不是运行时实际分配到的窗口。

要看真实值，得用：

输出里有一列 CONTEXT，那才是当前这个模型实例实际拿到的上下文窗口。我看到的数字是——4096。

4096，这是 Ollama 的 num_ctx 默认值。你不去显式设置它，无论模型本身支持多长，运行时都只给你 4096。

四、为什么 4096 对聊天够用、对 Agent 必死

到这一步原因就清楚了。

普通聊天场景下，你的提问加历史回复，几千 token 确实够用，4096 完全撑得住。

但 Agent 类产品完全不是一回事。WorkBuddy 的 system prompt 里塞了整套工具定义——读文件、写文件、执行命令、调用连接器，每个工具的 schema 都要写清楚。这些内容加上角色设定和规则，轻轻松松上万 token。

也就是说，任务还没开始，你的上下文窗口已经被 system prompt 吃掉了一大半甚至全部，剩下给实际任务的空间几乎没有。任务一复杂，必然溢出。

这也解释了那个诡异的现象：连接测试只发一句短提示，4096 绰绰有余，所以绿灯；真实任务一上去就塞满，所以崩。

五、修法：用 Modelfile 重建一个模型

知道原因就好办了。写一个 Modelfile：

然后重建：

这里有个好消息：FROM 指向本地已有的模型时，Ollama 不会复制权重，只是在原有模型基础上叠加一层配置，几乎不额外占磁盘。

重建完再 ollama ps 看一眼，CONTEXT 那列应该已经变成 32768 了。

六、8 GB 显存的账怎么算

num_ctx 不是越大越好，上下文窗口是要吃显存的。我当时最大的顾虑就是 8 GB 显存够不够。

算法是这样的：

• Qwen3.5-9B 每个 token 的 KV cache 大约 72 KB
• 32768 token 的 KV cache ≈ 32768 × 72 KB ≈ 2.4 GB
• 模型本身（9B 量化版）大约占 5.5 GB

5.5 + 2.4 = 7.9 GB，对 8 GB 显存来说基本卡在悬崖边上，稍微有点别的占用就 OOM。

解决办法是给 KV cache 做量化。设置两个环境变量：

q8_0 会让 KV cache 大致减半，2.4 GB 降到 1.2 GB 左右，显存压力一下就松了。OLLAMA_FLASH_ATTENTION 开启 Flash Attention，进一步省显存、提速度。

Windows 上设置完环境变量后需要重启 Ollama 服务才生效。

给个参考思路：先算出你的模型权重占多少，再用剩余显存倒推能开多大的 num_ctx。8 GB 卡跑 9B 模型，32768 配 q8_0 是个比较稳的组合；如果显存更紧张，可以退到 16384。

七、WorkBuddy 侧还有三个坑

改完 num_ctx 还不算完，客户端这边还有三个地方容易翻车。

坑一：模型名必须完全匹配，包括 tag。

ollama list 里显示的是 qwen3.5:9b，你就必须填 qwen3.5:9b。填成 qwen3.5 会导致匹配失败——它不会智能帮你补 tag。

坑二：Agent 模式下 supportsToolCall 必须打开。

这个字段决定了客户端会不会把工具定义注入请求。不打开的话，模型收不到工具 schema，Agent 就成了普通聊天机器人，干不了任何实际操作的活。在 UI 里对应的是 Advanced Settings 里的 Tool Calling 选项。

坑三：改完配置要完全退出客户端再重启。

不是关掉窗口，是要把进程真正退干净（托盘图标也要退出）。只关窗口的话，进程可能还驻留在后台，配置不会重新加载。

如果你习惯直接改配置文件，自定义模型存在 ~/.workbuddy/models.json，OpenAI 兼容的 JSON 格式。新版客户端支持热更新，但保险起见还是重启一次。

八、怎么验证真的通了

别再用一句短提示测试了——那是陷阱。正确的验证顺序是：

1. ollama ps 确认 CONTEXT 列的值符合预期
2. 在 WorkBuddy 里选好自定义模型，开一个真正需要读文件、调用工具的任务
3. 观察它能不能正常完成工具调用循环

只有第三步过了，才算真正配好。

九、说点实话：什么时候不该用本地模型

配通之后我用了一段时间，说说真实的感受和边界。

适合走本地的：格式转换、批量提取、简单翻译、代码格式化、 routine 的文档整理。这些任务对推理能力要求不高，本地 9B 模型完全够用，而且不消耗积分，速度也快。

不建议走本地的：复杂的多步推理、长文档深度分析、需要大量外部知识的调研。这类任务本地小模型的效果和云端大模型差距明显，而且显存有限导致上下文还是上不去，长任务容易翻车。

我现在的使用习惯是混着来：routine 任务切本地模型，遇到硬骨头再切回云端。这样积分消耗能压下来不少，产出质量也不会掉。

另外数据隐私也是个实打实的好处——敏感文档走本地，内容不出机器。

最后

回头看，整个坑的核心就一句话：Ollama 的默认上下文窗口是 4096，而 Agent 类产品光是 system prompt 就能把它吃光。

ollama show 给的是理论值，ollama ps 才是运行时真相。如果你也在把本地模型接进 WorkBuddy 或者类似的 Agent 工具，遇到"测试通过但干活就崩"，先去看一眼 ollama ps 的 CONTEXT 列，大概率就是它。

希望这篇能帮你少走点弯路。

本文基于 Windows 11+ RTX 4060 Laptop（8 GB）+ Ollama 0.32.15 实测。模型和客户端版本不同，具体数值可能有出入，以自己的环境为准。