企业官网建设流程全解析

1. 项目背景：为什么非得把 WorkBuddy 接上本地 Ollama

1.1 真实需求：免费、私密、还能离线用

先说结论：我折腾 WorkBuddy 接 Ollama，是因为受够了云端模型的三件事——按量计费烧钱、隐私数据不敢往上传、断网就歇菜。WorkBuddy 本身是个偏向智能体工作台的工具，日常用来做任务拆解、写文献综述、整理项目材料，经常会暴露个人信息和代码片段；如果长期走云端 API，第一是不放心，第二是一趟活干完账单感人。还不如在本地部署一个 Ollama，跑一个中等体量的开源模型，把 WorkBuddy 的推理后端切成普通模型，既保住了数据不出本机，也把高频的简单任务从“按 token 计费”变成了“电费”。

Ollama 的优势在于它把编译、量化、加载、缓存全都包了，一个命令就能拉起一个兼容 OpenAI 格式的本地服务，对 WorkBuddy 这类需要 HTTP 调用大模型接口的工具来说非常友好。不需要自己手搓推理框架，也不用折腾 Python 环境，只要把 API 地址从云端换成http://localhost:11434/v1，理论上就已经完成了接入。

1.2 核心链路：WorkBuddy、Ollama、模型之间怎么连线

整个接入过程其实是一条很直接的数据链路：

WorkBuddy（发指令、收文本） ↓ OpenAPI 风格的 /v1/chat/completions Ollama 本地服务（监听 11434 端口） ↓ llama.cpp 推理引擎 本地开源模型（GGUF 量化格式）

WorkBuddy 只负责做任务编排和状态管理，真正回答问题的能力来自模型。所以排查问题的时候要先分层：是 WorkBuddy 参数没配对，是 Ollama 服务没起来，还是模型本身回答不出来。我在这次踩坑里学到最值钱的一句话就是——不要一上来就怀疑模型，先验证链路每一段是否通。后面的所有排查记录，基本都围绕这句话展开。

2. 安装部署：先让 Ollama 自己跑得足够稳

2.1 下载安装、存储路径和环境变量

Ollama 的安装本身没什么技术含量，官方页面下载对应系统的安装包，或者用包管理器装都行。但有两个细节容易被忽略。

第一个是模型存储路径。Ollama 默认把模型放在用户目录下，Windows 是C:\Users\<用户名>\.ollama\models，Linux 是/usr/share/ollama或者~/.ollama。如果你图形工作站只有一块硬盘，默认路径通常无所谓；但如果系统盘是 256G 的小固态，一个大模型动辄 5~8G，用不了几个就把系统盘塞满了。所以我的建议是装完第一时间改存储目录：Windows 在系统环境变量里新增OLLAMA_MODELS=D:\ollama\models，Linux 则是export OLLAMA_MODELS=/data/ollama/models，改完重启服务。这一步看起来 trivial，但真等到硬盘报警再迁移就全是泪。

第二个是镜像站下载。如果你在下载安装包时发现速度很慢，别硬等，可以去国内一些开源镜像站下载安装包，体验会好很多。无论从哪里下载，装完都要记得校验一下服务是否正常。

2.2 模型选型与首次运行

模型选型我走了不少弯路。最开始图省事，直接ollama run qwen2.5:1.5b想快速跑通链路，结果发现 WorkBuddy 里的任务稍微复杂一点，1.5b 的回答质量就不够用了，经常答非所问，而且一旦要求它做“工具调用”，它根本接不上。后来换成qwen2.5:7b，效果好了很多。这里想顺便说一个教训：在算力允许的情况下，模型规模至少 7B 起步，1.5B 和 3B 用来做本地 API 连通性测试可以，拿来干正经活就太勉强了。

执行下面的命令可以先把模型拉下来：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

首次运行会完成加载，之后就可以在终端里直接对话，测试一下模型的“基本智商”。如果终端里都答不出来，那问题在模型层；如果终端正常但 WorkBuddy 连接后没反应，问题就在集成层。

2.3 先验证 Ollama 服务本身可用

模型跑起来之后，用 curl 直接打一下接口，确认服务是真的对外可用：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "你好", "stream": false }'

正常情况下会返回一小段 JSON，里面包含response字段和 token 消耗统计。这一步的意义是把 Ollama 从疑犯名单里摘出去，后续出问题的时候，就能笃定问题是出在 WorkBuddy 这一侧。

3. WorkBuddy 侧配置：把后端从云端切成 localhost

3.1 添加自定义模型服务的操作路径

WorkBuddy 默认接的是云端服务，但它的模型管理里留了自定义端点入口。不同版本的菜单位置会略有差异，但逻辑是一致的：进入“设置 → 模型服务 / 自定义端点”，然后添加一个新的服务配置。

主要填这几个参数：

• API 地址：填http://localhost:11434/v1。有人只填http://localhost:11434，那会走 Ollama 原生路由，WorkBuddy 如果用 OpenAI 客户端格式请求会解析不到路径，直接报 404，这是第一坑。
• API Key：Ollama 本地服务默认不鉴权，随便填一个，比如ollama或local-key，只要不空着就行。
• 模型名称：要填qwen2.5:7b。这个名称必须和ollama list里显示的 tag 完全一致，大小写和后缀都要对上。
• 是否支持工具调用：如果 WorkBuddy 的代理任务里需要用“工具调用”去操作文件、查数据库，那么要勾选支持。qwen2.5 系列对工具调用的支持还行，后面性能优化章节会展开讲。

填完保存，在模型下拉框里选中刚加的本地模型，顺手把“目标模型”切过去，就可以开始试了。

3.2 几个容易跟云端 API 混淆的参数

用云端服务的时候，很多参数都是平台侧帮你兜底的；换成本地 Ollama 之后，这些参数全部暴露给你了，含义完全不一样。我列一张表供参考：

我后来遇到“无输出”问题，本质上就是参数设置不协调导致的，这块在下一章展开。

4. 排查记录：从“无输出”到正常识别的完整过程

4.1 故障现场：状态正常，回复面板空空如也

接入完成后的第一次实操，我卡了整整一个晚上。现象非常诡异：WorkBuddy 显示已经连接上了本地模型，任务列表也在正常推进，但回复内容一直是空白，既没有报错，也没有卡死的迹象，就像模型在“装死”。

一开始我以为是模型加载慢，等了 10 分钟还是空的。后来我用 WorkBuddy 的日志功能抓取请求记录，发现在每个任务的回包里，内容字段确实是空的。这说明模型服务其实响应了，但吐出来的内容有问题，问题不在“通不通”，而在“格式对不对”。

日志里最关键的一行错误是这样的：

Invalid response: content field is None or empty. finish_reason: null.

看到这个报错，我反而踏实了——不是网络断了，而是 WorkBuddy 收到的响应结构不符合预期。

4.2 分层排查：从模型到服务再到客户端

排查的顺序按照之前说的链路来：

第一步，直接在终端里跑 Ollama 原生对话，确认模型本身能正常生成文本。这一步很顺，证明模型没问题。

第二步，用 curl 以 OpenAI 兼容端点测试：

curl http://localhost:11434/v1/chat/completions -d '{ "model": "qwen2.5:7b", "messages": [ { "role": "user", "content": "说一句你好" } ], "stream": false }'

这次返回正常，能看到choices[0].message.content里有明确的文本。那我基本可以断定问题出在 WorkBuddy 的请求构造上。

第三步，回头去检查 WorkBuddy 的发送参数。我打开日志中的请求体，发现 WorkBuddy 默认给请求里加了一段“工具函数定义”，也就是告诉模型它可以调用哪些函数。而 qwen2.5:7b 在收到这种格式时，如果参数里没有正确的tools声明，或者工具定义太过复杂，模型会直接回一个空的内容字段，转而尝试“调工具”却调了个寂寞。

4.3 真正的坑：工具调用和流式响应叠加

真相大白之后，修复方案就很明确了。问题出在两部分：

第一，Ollama 的上下文长度太小。默认num_ctx是 4096，WorkBuddy 的一次任务会塞入系统提示词、历史记录、工具定义，还没轮到真正的问题就已经接近上限。模型在生成时感觉“上下文是满的”，就直接吐了个啥内容都没有的响应。这个现象特别隐蔽，因为日志里没有任何显式报错，只是空内容。

解决方式是在启动 Ollama 服务时，通过环境变量调大上下文：

set OLLAMA_CONTEXT_LENGTH=16384 # 或者 Linux： export OLLAMA_CONTEXT_LENGTH=16384

重启服务后再测，空响应出现的频率明显下降。之后我又在 WorkBuddy 的请求参数里手动加了num_ctx: 16384，把这个参数固定下来。

第二，禁用或精简工具调用。WorkBuddy 默认把它能用的工具全部塞给模型，数量一多，本地小模型的选择压力就大。我在实验阶段直接关掉了“自动工具调用”选项，让它先走“纯对话”模式跑通链路；确认正常之后，再逐步打开文件操作、代码搜索这类高频工具。这样既保证链路可跑，又不至于一开始就被复杂的工具定义怼懵。

另外还有一个隐藏点：WorkBuddy 默认开启流式输出，而 Ollama 在流式输出时，如果是通过代理转发，就很容易出现“首帧为空”的现象，客户端解析时会把首个空帧当作“结束帧”，从而显示空白。我当时的处理方式是先把流式关闭，确认模型能一次性吐完文本；跑稳定之后再开启流式。如果一定要开着流式，请确认 WorkBuddy 的底层 HTTP 客户端能正确聚合多个delta帧，而不是一见空帧就中断。

4.4 修复后验证与效果对比

修复完这三个点（上下文长度、工具调用、流式帧处理），再跑同一个任务，输出已经正常。首轮完整对话的实测数据是：

虽然已经能用了，但 30 tok/s 只能算“凑合”，离舒服还差得远。于是下一阶段进入性能调优。

5. 性能调优：从 30 tok/s 一路跑到 70 tok/s

5.1 先确认 GPU 加速有没有生效

很多人装了 Ollama 之后以为默认就会用显卡，其实不一定。如果是纯 CPU 环境，跑 7B 模型的 Q4 量化，速度大概在 5~15 tok/s 之间，体验非常难受。想要 70 tok/s，关键就是把模型加载到 GPU 显存里去。

一般情况下，Linux 上直接执行ollama ps，能看到模型当前跑在哪个设备上。输出里如果显示100% GPU，说明已经走了 GPU 路径；如果显示100% CPU，就需要排查。

Ollama 在 NVIDIA 显卡上基本不用额外配置，装好驱动就能用。但 AMD 显卡用户需要设置环境变量：

set HSA_OVERRIDE_GFX_VERSION=11.0.0 set OLLAMA_NUM_GPU=1

在 Windows 上，还有一个常见坑：OpenGL 和显卡驱动冲突导致 Ollama 识别不到显卡。我在自己机器上就遇到过，更新显卡驱动之后立刻从 8 tok/s 跳到 45 tok/s，提升巨大。

5.2 三个关键参数：num_ctx、num_predict、batch size

跑通之后，我又在 WorkBuddy 和 Ollama 两层配置里做了几个针对性调整：

第一，把num_ctx固定为 8192。上下文太大，显存占用暴涨，而且首 token 延迟也会变长；太小则容易截断导致生成质量下降。经过实际对比，7B 模型在 8192 上下文下，显存占用大概 6~7GB，正好合适。

第二，合理设置最大输出 token。WorkBuddy 里默认的max_tokens有时只有 1024，对于写文献综述这种任务根本不够用。我改成 4096 之后，长文本能一次写完，不用中途重试，减少了大量重复开销。

第三，调整并发请求参数。如果你用的是 16G 以上显存，GPU 还有余量，可以考虑开启并行：

set OLLAMA_NUM_PARALLEL=2 set OLLAMA_MAX_LOADED_MODELS=2

但 8G 显存建议不要碰并发，否则多个请求争抢显存，反而互相拖慢。我试过开 4 并行，速度直接掉到 25 tok/s，谁插队谁倒霉。

5.3 实测记录与最终效果

调优过程我记录了几个典型的数字：

最终能到 70 tok/s，其实是模型量化格式、驱动、上下文参数三者共同配合的结果。我在ollama pull的时候特意指定了qwen2.5:7b-q4_K_M，这个量化等级的精度和速度平衡最适合日常任务。注意一个细节：不要为了速度盲目上 Q2 量化，那会让模型回答质量肉眼可见地下降，节省的那些毫秒不值得。

现在日常我用 WorkBuddy + 本地 Ollama，单轮对话的响应速度体感上不比云端慢多少，而且完全离线，访问记录也不会被任何平台收集，这一点对我来说比 70 tok/s 更重要。

6. 高频坑位速查与经验沉淀

6.1 问题排查速查表

把这段时间踩过的坑汇总成一张表，遇到同样问题可以直接对号入座：

6.2 日常使用中容易忽略的细节

有几个细节是排查时非常容易忽略的，单独拎出来说：

第一，修改 Ollama 环境变量之后，必须重启服务，不是重启 WorkBuddy 就行的。而且如果在 Windows 上，要把 Ollama 托盘图标彻底退出，再从终端启动，环境变量才会重新加载。我至少有一次改了OLLAMA_CONTEXT_LENGTH但忘了重启，结果白调了半天。

第二，WorkBuddy 侧的日志开关一定要打开。出问题时没有日志就是瞎子。在设置里把日志等级调到debug，排查完再调回去，这个动作其实能省大量时间。

第三，本地模型对“长指令”的容错能力较弱。在 WorkBuddy 里写 prompt 的时候，尽量把任务拆成小而明确的步骤，不要一句话里既有背景又有要求还带着三个问题。本地模型不像云端大模型那样能一次消化复杂提示词，合理的任务拆解能明显提升输出质量。

第四，一定要区分“请求通没通”和“回答好不好”。这两个问题经常被混为一谈。如果请求通了但回答质量差，那是模型能力问题，换更大的模型或者更好的量化版本才对；如果请求都没通，那是链路和配置问题。用这个标准去判断，排查思路会清晰很多。

6.3 我对 WorkBuddy + Ollama 这套组合的几点判断

这套组合适合什么场景呢？我自己的核心场景是日常知识工作自动化：让 WorkBuddy 帮我整理项目文档、写初稿、做资料汇总，这些任务不需要顶级云端模型的理解力，但需要大量次数，用本地模型低成本反复跑非常合适。

不适合的场景则是高难度全局推理任务，尤其是涉及跨章节关联的复杂分析。7B 模型的推理深度确实有限，这时候我会把任务切回云端大模型，形成本地、云端双通道。实践下来最佳的使用模式是——简单高频任务全部丢给本地，复杂任务才走云端，两边各司其职，成本和工作效率都最优。

最后再分享一个小操作。日常使用中如果发现模型响应变慢，不要急着重启 WorkBuddy，先到 Ollama 所在机器的终端执行：

ollama stop qwen2.5:7b ollama run qwen2.5:7b

手动把模型从显存里卸载再重新加载，很多时候速度就回来了。这个操作比重启整个服务要快得多，也是我调优之后用得最多的技巧。