OpenClaw 技能扩展实战指南：从安装 Skills 到 Tavily 联网 + 多维表格自动化
2026/9/29 6:48:49
1. 为什么我最终把 Ollama 装进了工作流
AI大模型本地部署这件事，我一开始是拒绝的。理由很简单：云端模型已经够用，何必折腾自己的机器。直到有一次出差在高铁上，想改一段 RAG 检索的 prompt，网络断断续续，云端接口一直转圈，我才意识到本地部署的价值——不是替代云端，而是给高频、隐私敏感、离线场景兜底。
Ollama 是目前把这件事做得最顺手的工具之一。它把模型权重、推理引擎、服务端口打包成一个命令行程序，你不需要懂 CUDA、不需要配 Python 环境，一条ollama run就能跑起 Deepseek 或 Qwen。适合谁？三类人：一是手里有 32G 内存以上机器的开发者，二是需要处理涉密文档、不想把内容传到云端的团队，三是想低成本做模型对比实验的人。
这篇教程聚焦完整落地路径：环境准备、模型拉取、推理测试、性能对比，同时给出可复制的配置骨架和 TaoToken 统一 Key/API 通道的接入示例。本地跑模型负责隐私和离线，TaoToken 负责在需要更强模型或联网时做统一出口，两者配合才是完整方案。
2. 环境准备与 Ollama 安装
2.1 硬件与系统要求
本地部署的第一道门槛是内存。模型参数量决定显存/内存占用，粗略对照如下：
| 模型 | 量化后硬盘占用 | 建议运行内存 |
|---|---|---|
| deepseek-r1:7b | 约 4.7G | 8G |
| deepseek-r1:32b | 约 19G | 32G |
| qwen2.5-coder:32b | 约 19G | 32G |
| qwen2.5:14b | 约 9G | 16G |
Mac 用户看统一内存，Windows/Linux 用户看显存加内存。如果内存不够，Ollama 会退到 CPU 推理，速度会慢一个数量级，但不会崩。
2.2 安装 Ollama
macOS 和 Windows 直接去 ollama.com 下载安装包，双击即可。Linux 用一行脚本：
curl -fsSL https://ollama.com/install.sh | sh安装完成后验证版本：
ollama --version看到版本号输出就说明服务已经注册为后台进程。macOS 上它会常驻菜单栏，Windows 上会出现在系统托盘。
2.3 配置模型存储路径
默认模型存在系统盘，32b 模型动辄 19G，很容易把 C 盘撑爆。建议改到数据盘。macOS/Linux 设置环境变量：
export OLLAMA_MODELS=/data/ollama/modelsWindows 在系统环境变量里新增OLLAMA_MODELS，指向D:\ollama\models。改完重启 Ollama 服务生效。
3. 拉取 Deepseek 与 Qwen 模型
3.1 拉取命令
Ollama 的模型库直接支持 Deepseek 和 Qwen 系列。拉取 deepseek-r1 的 32b 量化版：
ollama pull deepseek-r1:32b拉取 Qwen 的代码专用模型：
ollama pull qwen2.5-coder:32b如果内存只有 16G，换成 14b 或 7b：
ollama pull qwen2.5:14b ollama pull deepseek-r1:7b拉取过程会显示分层下载进度，支持断点续传。国内网络下 19G 大概需要十几分钟到半小时，取决于带宽。
3.2 确认安装结果
ollama list输出会列出模型名、ID、大小、修改时间。看到刚拉的两个模型都在清单里，说明安装完成。
3.3 用 Modelfile 固化参数
想让模型每次启动都带固定参数（比如温度、上下文长度），可以写一个 Modelfile：
FROM deepseek-r1:32b PARAMETER temperature 0.6 PARAMETER num_ctx 8192 PARAMETER top_p 0.9然后构建自定义模型：
ollama create my-deepseek -f ./Modelfile ollama run my-deepseek这样每次运行my-deepseek都自动带上你调好的参数，不用重复输入。
4. 可复制的配置骨架与 TaoToken 通道
4.1 Ollama 服务端配置
Ollama 默认监听127.0.0.1:11434。如果要让局域网内其他机器调用，设置：
export OLLAMA_HOST=0.0.0.0:11434 export OLLAMA_KEEP_ALIVE=30mOLLAMA_KEEP_ALIVE控制模型在内存里驻留多久，默认 5 分钟，调大可以避免频繁冷启动。
4.2 settings.json 骨架（VS Code 插件场景）
如果你用 Continue 或 Cline 这类 VS Code 插件接本地模型，配置大致如下：
{ "models": [ { "title": "Local Deepseek", "provider": "ollama", "model": "deepseek-r1:32b", "apiBase": "http://127.0.0.1:11434" }, { "title": "TaoToken Qwen", "provider": "openai", "model": "qwen-max", "apiBase": "https://taotoken.net/api", "apiKey": "sk-你的TaoToken密钥" } ] }本地模型走127.0.0.1，云端模型走 TaoToken 统一通道，插件里一键切换。
4.3 config.toml 骨架（命令行客户端场景）
部分 CLI 工具用 TOML 配置：
[providers.ollama] base_url = "http://127.0.0.1:11434" model = "qwen2.5-coder:32b" [providers.taotoken] base_url = "https://taotoken.net/api" api_key = "sk-你的TaoToken密钥" model = "deepseek-chat"TaoToken 的 API 地址是https://taotoken.net/api，兼容 OpenAI 格式，所以任何支持自定义 base_url 的客户端都能接。密钥在控制台的 API Keys 页面生成：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
4.4 统一 Key 的意义
本地模型不需要 Key，但当你需要调用云端更强模型时，TaoToken 提供一个 Key 打通多个模型。这样你的配置文件里只有一套鉴权，切换模型只改 model 字段。对于长期做 coding 或 Agent 开发的场景，可以考虑 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
5. 推理测试与性能对比
5.1 测试任务设计
我用一个制冷循环计算任务做对比：给定冷凝温度、过冷度、蒸发温度、过热度，要求模型分析循环过程并计算制冷系数 COP。这个任务需要查物性参数、套公式、做多步推导，能同时考察模型的推理能力和数值准确性。
测试命令用asitop（macOS 上监控 CPU/GPU/内存/功耗的工具）：
sudo asitop5.2 三个模型的表现
deepseek-r1:32b：从收到任务到输出结果用时约 15 分钟。10 颗 GPU 全部占用，GPU 峰值功率 19.91W，CPU 峰值 4.46W，内存占用 26.9G/32G。运行初期 GPU 平均功率 12.75W，后期降到 8.94W。计算结果 COP=2.38，状态点温度压力计算准确，但物性参数取值有偏差。
qwen2.5-coder:32b：用时约 3 分钟。GPU 峰值 20.46W，CPU 峰值 1.24W，内存 26.7G/32G。运行初期 GPU 平均 14.5W，后期 10.85W。计算结果 COP=0.389，状态点温度和压力都不准确，偏差较大。
gemma3:27b：用时约 4 分钟。GPU 峰值 19.61W，CPU 峰值 3.89W，内存 26.6G/32G。计算结果 COP=8.28，压力计算不准确。
5.3 对比结论
| 模型 | 求解时间 | 内存占用 | GPU 均值 | 结果准确度 |
|---|---|---|---|---|
| deepseek-r1:32b | 15min | 26.9G | 12.75W | 状态点准确，物性有偏差 |
| gemma3:27b | 4min | 26.6G | 14.2W | 压力取值不准 |
| qwen2.5-coder:32b | 3min | 26.7G | 14.5W | 温度压力均不准 |
deepseek-r1 最慢但最靠谱，适合需要严谨推导的场景。qwen2.5-coder 最快但数值推理弱，适合代码生成而非物理计算。gemma3 居中。选型建议：做代码补全用 qwen2.5-coder，做逻辑推理用 deepseek-r1，做通用对话两者都可以。
5.4 用 API 方式验证
除了命令行，也可以用 curl 直接调 Ollama 的 API：
curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:32b", "prompt": "用一句话解释什么是制冷系数", "stream": false }'返回 JSON 里的response字段就是模型输出。这个接口和 OpenAI 格式不同，但很多客户端做了适配。
如果你更想先在线验证模型效果再决定本地部署哪个，可以用模型对话页面直接试：https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
6. 常见报错排查
6.1 拉取模型卡住或超时
现象：ollama pull进度条长时间不动。原因通常是网络到模型仓库的连接不稳定。解决：先确认能访问 ollama.com，然后重试，Ollama 支持断点续传，中断后重新执行同一条命令会从断点继续。
6.2 运行时报 out of memory
现象：ollama run后模型加载失败，提示内存不足。原因：模型大小超过可用内存。解决：换更小的量化版本，比如把 32b 换成 14b 或 7b；或者关闭其他占内存的程序；Mac 用户检查统一内存是否被其他应用占用。
6.3 端口 11434 被占用
现象：Ollama 启动失败，提示 address already in use。原因：已有 Ollama 实例在运行，或其他程序占用了端口。解决：
lsof -i :11434找到占用进程后 kill 掉，或者改 Ollama 监听端口：
export OLLAMA_HOST=127.0.0.1:114356.4 客户端连不上本地模型
现象：VS Code 插件配置了127.0.0.1:11434但请求失败。原因：Ollama 服务没启动，或客户端在容器/远程环境里，127.0.0.1指向的不是宿主机。解决：先ollama list确认服务活着；容器场景把地址改成宿主机 IP；远程场景设置OLLAMA_HOST=0.0.0.0:11434并放行防火墙。
6.5 模型输出乱码或截断
现象：返回内容不完整或出现奇怪字符。原因：num_ctx设置过小，上下文被截断。解决：在 Modelfile 里调大num_ctx，比如 8192 或 16384，然后重新 create 模型。
6.6 TaoToken 通道返回 401
现象：配置了 TaoToken 的 Key 但请求被拒。原因：Key 复制不完整或已失效。解决：去控制台重新生成，确认请求头是Authorization: Bearer sk-xxx。接入文档在这里：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
7. 把本地和云端串起来
本地部署解决的是隐私、离线、零成本高频调用的问题；云端解决的是模型能力上限和弹性扩容的问题。两者不是二选一，而是分工。我的做法是：日常代码补全、文档摘要走本地 qwen2.5-coder；遇到复杂推理或本地模型明显吃力时，切到 TaoToken 通道调云端模型。
如果你也在做 Claude Code 或 Anthropic 风格的 Agent 开发，TaoToken 提供了对应的接入方式：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code&utm_campaign=rewrite
配置改完后，跑一条最简单的验证请求确认链路通：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的密钥" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"ping"}]}'返回正常 JSON 就说明通道可用。本地和云端都跑通之后，你的开发环境才算真正完整。