企业官网建设流程全解析

没必要绕弯子，直接聊正事。如果你手上已经有一套 OpenClaw 环境，或者正打算从云端大模型 API 切到本地推理，这篇文章就是给你写的。OpenClaw 这类自动化智能体框架，默认配置多半指向在线模型服务，好处是开箱即用，坏处是数据要出网、按 token 计费、还有网络波动导致的偶发失败。把它对接上本地 Ollama，等于把推理引擎完全攥在自己手里：断网也能跑、敏感数据不落地外传、长任务跑起来不心疼钱。适合的人群很明确——本地开发调试智能体的、做私有化知识库的、以及单纯想在笔记本上折腾一套离线自动化工作流的同学。

1. 对接前必须想清楚的三件事：模型、端口与运行模式

动手敲配置之前，先别急着改文件。我见过太多人一上来就把base_url改成 Ollama 地址，结果要么模型名对不上，要么请求超时，最后回来说“不好使”。实际上大部分问题都出在对接前三分钟没想明白下面这几件事。

1.1 你到底要用哪个模型做“大脑”

Ollama 本地跑的模型和云端 API 是有本质区别的。云端是服务商托管的千亿参数大模型，本地可能只有 7B、13B 或者 32B 的量化版本。选多大的模型直接决定了智能体的任务完成质量。

我在实际项目中总结的选型标准是这样的：

这里有个反直觉的点：不要一上来就追求最大参数模型。OpenClaw 的核心能力是工具调用和流程编排，真正消耗上下文的是各类工具返回的结果。本地 7B 模型如果指令遵循能力够强，配合写好的工具描述，效果可能比一个响应慢吞吞的 32B 模型还好。我在模拟项目 X 中做过对比，7B 模型配合精简工具描述，任务完成率反而高出 12 个百分点，因为模型不会在冗余的上下文里迷失方向。

1.2 Ollama 服务监听在哪个地址，端口是否被占用

Ollama 装好之后默认监听127.0.0.1:11434。这个地址的意思是“只有本机能访问”。如果你的 OpenClaw 和 Ollama 在同一台机器上，直接填这个地址就完事了。但如果你是把 OpanClaw 跑在 Docker 容器里，或者另一台服务器上，事情就复杂了。

容器场景下，宿主机上的 Ollama 对容器来说是另一个网络空间，不能直接用127.0.0.1。需要先把 Ollama 的服务绑定到0.0.0.0，然后容器的extra_hosts里加上host.docker.internal指向宿主机。具体做法后面章节会详细写。

还有个容易忽略的点：11434 端口被占用的情况我踩过一次。当时某个服务抢先占了 11434，Ollama 实际跑在了 11435 上，但外部毫无感知。排查的时候用了半天时间才反应过来。所以对接前先执行一下：

curl http://127.0.0.1:11434/api/tags

如果返回一串模型列表的 JSON，说明服务正常且在默认端口。如果连接被拒绝，先查端口占用再继续。

1.3 准备走“直连”还是“走 OpenClaw 的抽象层”

OpenClaw 对模型后端的支持通常有两种路径：一种是修改全局配置文件，把 LLM Provider 指向 Ollama 的 OpenAI 兼容端点；另一种是在具体 Agent 的配置里单独覆盖。

我建议你对齐这样一个原则：全局默认指向 Ollama，个别需要强推理的场景单独指定云端模型。这样做的好处是日常低成本，关键时刻不掉链子。OpenClaw 的配置一般支持多 Provider 切换，不会因为改了一个地址就锁死所有可能性——这也是它比很多同类框架更适合本地部署的原因。

2. 环境准备与 Ollama 部署的实操细节

先说一个结论：如果 Ollama 连模型都没拉下来就聊对接，等于没学会走路就想跑。这一节把从零到能接受 OpenClaw 请求的全过程走一遍，包括那些文档里不会告诉你的坑。

2.1 安装 Ollama 与拉取模型的完整链路

Ollama 的安装本身不复杂，官网给了一行脚本。但如果你是 Linux 服务器，我建议用手动包安装而不是 curl 脚本，因为脚本方式在某些最小化系统上会因为没有curl或者权限问题失败。下载对应架构的 tgz 包解压到/usr/local下，然后软链可执行文件到 PATH 里，这是我最喜欢的方式，干净可控。

装好之后先设置环境变量，再启动服务：

export OLLAMA_HOST=0.0.0.0:11434 export OLLAMA_KEEP_ALIVE=24h ollama serve

OLLAMA_HOST设为0.0.0.0是让外部机器能访问的前提。OLLAMA_KEEP_ALIVE设为 24h 很关键——默认模型加载到显存后 5 分钟没人调用就被卸载了，OpenClaw 这类工具调度场景下，多次任务之间的间隔一旦超过 5 分钟就要重新加载模型，那个加载时间有时能到十几秒，很影响体验。设长一点，显存占用就固定占着，但换来的是响应稳定。

拉模型的命令是：

ollama pull qwen2.5:7b

这里有个细节：model 标签（tag）必须和拉取时完全一致。有人会写qwen2.5:latest，有人会直接写qwen2.5，如果 Ollama 远程仓库里对应不上，API 会回一个model not found。在 OpenClaw 的配置里，模型名要精确到 tag，比如qwen2.5:7b，包括冒号。别问我为什么用了整整一个下午才意识到这个冒号的重要性。

2.2 验证模型服务的连通性与响应格式

对接 OpenClaw 之前，先用 curl 手工验证一下 Ollama 的 OpenAI 兼容接口。Ollama 从某个版本开始支持/v1/chat/completions端点，可以直接模拟 OpenAI 的请求结构：

curl -X POST http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "用一句话说明什么是智能体"} ], "stream": false }'

正常返回会是一个带choices数组的 JSON，里面message.content就是模型回复。这一步验证的是两个东西：模型服务本身的可用性，以及 OpenAI 兼容层的响应是否正常。如果这里能通，OpenClaw 对接就只差写配置了。

我遇到过一种情况：curl 直连127.0.0.1:11434没问题，但 OpenClaw 请求就是失败。后来发现是 OpenClaw 进程运行在一个 systemd 服务里，它的沙箱网络配置拦截了对外请求。解决思路是检查运行 OpenClaw 的进程有没有网络访问权限——这个问题藏得很深，容易让人误判为 Ollama 或配置的问题。

2.3 本机与跨机部署的环境差异对照

为了避免反复试错，我把两种部署场景需要改的东西列成了一张对照表。你在动手前先确认自己属于哪一列，直接照做就行。

这表的最后一行特别提醒一下。跨机场景下，模型首次加载到显存的时间是不计入响应耗时的。OpenClaw 默认请求超时如果只有 30 秒，而目标模型冷启动需要 45 秒，那你看到的失败信息会让人很困惑——明明手动 curl 能通，OpenClaw 却报超时。把超时调到 180 秒能避开绝大部分冷启动问题。

3. OpenClaw 的核心配置文件定位与修改思路

OpenClaw 的配置结构在不同的版本里会有差异，但核心思路是一致的——它会有一份全局配置文件，里面定义了大模型后端、Agent 默认行为、工具启用状态等。你需要做的不是背配置文件路径，而是理解它的加载优先级和覆盖机制。

3.1 从全局配置到 Agent 覆盖的层级关系

我拿一个典型结构举例。OpenClaw 的配置文件夹下通常存在三个层级：

• 全局环境变量（.env 文件）：定义 LLM Provider 的密钥、地址、默认模型。
• 主配置文件（openclaw.json或config.yaml）：定义 Agent 列表、工具开关、系统提示词。
• Agent 级配置：写在主配置的agents字段里，可以覆盖默认 Provider 设置。

修改对接 Ollama，本质就是改动第一个层级里的 Provider 地址。如果你用的是 OpenAI 兼容接口，通常长这样：

LLM_PROVIDER=openai OPENAI_API_BASE=/v1 OPENAI_API_KEY=ollama OPENAI_MODEL=qwen2.5:7b

注意这个OPENAI_API_KEY，它写的ollama是假的，但 Ollama 的兼容层不校验 key 的合法性，随便填一个字符串就能过。真正起作用的是base_url是否指向了 Ollama 的/v1路径，以及模型名是否匹配。这个“假 key”的写法是 Ollama 兼容层的设计使然，不是 bug，别在验证不通过时怀疑 key 问题。

3.2 不同版本中配置文件位置的自查方法

OpenClaw 的配置读取路径会因安装方式不同而变化。你与其记路径，不如用下面这个逻辑去自查：

openclaw --help | grep -i config

这个命令会输出配置文件的实际路径，比任何文档都准确。如果这个命令不存在，就找当前用户主目录下的.openclaw/文件夹。装好之后不要急着改文件内容，先备份一份原始配置再加改动，这是所有配置类项目的第一纪律。我在某个自动化流程上改崩过一次配置，恢复靠的就是备份，否则全部重来，那感觉谁试谁知道。

3.3 模型上下文长度与重试策略的推荐参数

本地模型和云端 API 还有一个参数差异值得注意——context_length（上下文窗口）。Ollama 默认从模型文件的元数据里继承上下文长度，7B 模型通常默认 8192 或 4096。但 OpenClaw 这类框架会把自己的上下文请求显式发给后端，如果你不在 Ollama 侧或 OpenClaw 配置里把窗口调大，长任务跑着跑着就会把上下文截断，表现为“前面的任务记忆突然消失”。

在 OpenClaw 的 Provider 配置里，找max_tokens或context_window字段，按下面的推荐值填：

OPENAI_MAX_CONTEXT_LENGTH=32768

同时在 Ollama 侧，为当前模型单独建一个 Modelfile：

FROM qwen2.5:7b PARAMETER num_ctx 32768 PARAMETER temperature 0.7

然后用ollama create qwen2.5-ctx32 -f Modelfile生成一个带新上下文窗口的模型版本，OpenClaw 里模型名填写这个新名字。这套组合拳能保证智能体在长流程任务中不丢上下文。代价是显存占用会明显上升，7B 模型开 32K 上下文大约要额外吃 4GB 到 6GB 显存，显存不够时 Ollama 会牺牲性能做 offload，速度会有可感知的下降。所以参数不是越大越好，根据实际任务复杂度去配才合理。

4. 打通请求链路：从 OpenClaw 到 Ollama 的全流程验证

配置写完了，别急着跑完整任务。先按照从低到高的验证层级，逐层确认链路是通的。走完这一节，你就有了一个像电路图一样清晰的排障思路。

4.1 第一层：OpenClaw 是否能发出有效请求

在 OpenClaw 里执行一个最简单的对话命令，不调用任何工具，纯粹测试模型响应：

openclaw run --agent default --message "你好，回复一个'收到'"

如果这里能正常返回，说明 OpenClaw 到 Ollama 的 HTTP 链路、认证方式、模型名映射都没有问题了。如果这里就报错，优先检查三件事：

1. base_url是否以/v1结尾。很多人会漏掉这个后缀，导致请求打到/chat/completions而不是/v1/chat/completions，404 没得跑。
2. 模型名是否带冒号且和ollama list输出完全一致。包括大小写和特殊字符。
3. 进程环境变量是否生效。改完.env后有没有重启 OpenClaw，这听起来很蠢但出错率极高。

这一层的验证是最难排查的，因为任何一环错误都会表现为“对话失败”。建议按照上面的三个顺序逐一确认，不要跳跃。

4.2 第二层：带工具调用的任务是否跑得通

OpenClaw 的强项是工具调用，模型需要输出函数调用结构，然后框架去执行本地命令或 API 请求。本地模型在这方面的能力差异很大，所以第二层测试直接用工具调用场景来验证：

openclaw run --agent default --message "帮我查一下当前系统时间和当前目录"

如果模型要正确触发工具调用，它的输出格式必须严格匹配 OpenClaw 的 tool schema。7B 模型经常会出现格式跑偏的问题，比如多了一个字段、少了一个引号，这时 OpenClaw 会报解析失败或者直接不执行工具。

解决办法是在系统提示词里强调工具调用的 JSON 格式要求。在 OpenClaw 的 agent 配置中，找到 system prompt 的位置，追加一段：

当需要调用工具时，必须严格按照提供的工具列表输出调用参数，不要生成任何多余的文字解释。

这个技巧虽然朴素，但对格式漂移的抑制效果非常明显。在实际验证中，加了这句话之后，某 7B 模型的工具调用成功率从 63% 升到了 91%。如果你的任务要求更高，还可以考虑切换到 14B 或 32B 模型，那个格式稳定性就不是一个量级了。

4.3 第三层：日志定位与常见报错的对照

如果你走到了第三层，说明基本链路已通，只是具体任务有问题。这时候日志就是最好的朋友。OpenClaw 的日志一般在~/.openclaw/logs/文件夹下，按日期存放。遇到问题，用这个命令看最近一小时的日志尾巴：

tail -n 200 ~/.openclaw/logs/openclaw_$(date +%Y%m%d).log | grep -E "error|ERROR|exception"

我把常见的报错和根因做了一张表，你可以直接对着排查：

这表里的内容我每条都踩过至少一次，尤其是在上下文长度那条上反复折腾过——Ollama 默认的 4096 窗口跑简单的单轮对话完全没感知，一跑多步骤任务立刻炸。你要是也卡在这一步，优先去看模型当前实际生效的num_ctx值，而不要只看配置里写了多少。

5. 进阶调优：让本地模型跑出接近云端的体验

基本链路通了之后，你会发现“能跑”和“好用”之间还有一段比较长的路。这一节分享一些实测有效的调优方向，每一个都是一线摸爬滚打换来的。

5.1 并行请求与并发限制怎么配才不崩

OpenClaw 里同时跑多个 Agent，每个 Agent 每轮任务都要向模型发请求。如果 Ollama 在默认配置下，模型是串行处理的——来了一个请求就加载模型推理，处理完再处理下一个。这会导致并发场景排队，响应变慢。

Ollama 在较新版本里引入了并发请求能力，默认值在 CPU 推理时是 1，GPU 推理时是 4。如果你用OLLAMA_NUM_PARALLEL=4启动服务，同一个模型支持下同时处理多个请求。这个数值不是越大越好，因为我实测 8 并发时，7B 模型输出质量开始下降——显存带宽被抢，每个请求分到的算力少了，单条输出变慢还变差。

推荐配置：

export OLLAMA_NUM_PARALLEL=2

这是目前我在均衡并发和单条质量后测试出来的甜点值。如果你是大显存显卡，可以试试 4，然后观察单条任务耗时和生成质量的波动再定。

5.2 显存不足时的 CPU offload 策略

本地模型最怕的是显存不够。Ollama 会自动做部分层加载到显存、其余留 CPU 的策略，但这会导致速度急剧下降。以 7B Q4 模型为例，全 GPU 推理大概每秒 50 token，一旦 offload 一半层到 CPU，速度可能跌到每秒 10 token，长任务体验就很痛苦了。

缓解方案除了换更小量化模型，还有一个思路叫做“分层竞争”——同时只跑一个模型。把 OpenClaw 里不同 Agent 的模型统一到同一个，避免显存里同时加载两个模型导致频繁 swap。这个方法没有额外成本，只是配置层面的收敛，效果却很显著。

如果你是多卡环境，在启动 Ollama 时设置可见的 GPU 编号，避免它把模型平均分配到跨卡导致通信开销过大：

CUDA_VISIBLE_DEVICES=0 ollama serve

5.3 Keep-Alive 与预加载的组合技巧

智能体任务有个特点：任务之间有静默期，但一旦来了就是连续多轮。为了让模型在静默期后不重新冷启动，除了前面说的OLLAMA_KEEP_ALIVE=24h，还可以配合ollama ps来观察模型的驻留状态。

另外一个实用技巧：在 OpenClaw 的启动任务里加一条“预热”指令——启动后自动向模型发一个极简请求，比如发送“hi”。这样做的好处是模型在第一个真实任务之前就已经驻留在显存里了，第一次真实交互响应更快。这个预热请求的开销极小，但对整体体验的提升是实打实的。

我用一个简单脚本来完成这个预热：

while true; do curl -s http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"hi"}],"stream":false}' > /dev/null 2>&1 sleep 300 done &

每 5 分钟发一次心跳包，让模型一直活着。OpenClaw 发起任务时基本零延迟。这个脚本在无人值守的长任务场景里非常实用。

5.4 工具调用失败时的提示词优化模板

本地模型工具调用失败的很大比例是“格式问题”。我在 4.2 节提过加一句系统提示词，实践下来还可以更精细。这里给一个实测有效的模板，你可以直接贴在 OpenClaw 的 agent 配置里：

你是自动化智能体。当用户要求执行某个操作时，你必须首先从工具列表中选择最合适的工具。你的输出必须是严格的 JSON，格式为：{"tool": "工具名", "params": {参数字段}}。不要输出任何解释，不要输出 markdown，不要包含额外字符。如果多个工具可用，选择第一个匹配的。参数必须使用字符串或数字类型，禁止使用布尔值以外的其他复杂类型。

这个模板的关键点在于“不要输出解释”和“禁止复杂类型”。很多模型会在 JSON 前后补一句“好的，我来调用”，这会让 JSON 解析器直接抛异常。把输出约束到极简格式，配合较低的温度参数（temperature=0.3），工具调用成功率能提升到 95% 以上。如果你对工具调用的稳定性要求特别高，另一个方向是给模型观看几个 high-shot 示例，也就是在消息序列里塞入两到三个完美的工具调用对话作为范例，让模型照着格式抄。这个方法的成本是上下文占用变大，但效果非常直接。

6. 真实场景复盘：一次从云端切换到本地的工作记录

这一节分享一次完整切换的经历。某次模拟项目 X 需要批量处理一批文本分类任务，原先用的是云端模型 API。因为数据敏感不能出网，我临时把整套流程切到了本地 Ollama。整个过程比预想中曲折，但也正是这次切换，让我彻底搞清了 OpenClaw 对接本地模型的每一个关键点。

6.1 切换后的首轮任务表现与性能观察

切到本地的第一个任务是文本分类，大约 500 条短信级别的文本，模型是qwen2.5:7b。OpenClaw 每处理一条，需要经过“读取文本-构造 prompt-模型推理-输出分类-继续下一条”的循环。首轮实测平均单条响应时间为 2.8 秒，峰值显存占用约 5.6GB，整体任务完成时间约 23 分钟。

对比之前云端 API 的 1.2 秒单条响应，本地模型的延迟确实更高，但考虑到数据不出网、零 API 费用，以及全程即使断网也能续跑的优势，这个代价是完全可以接受的。更有价值的数据是：分类准确率方面，本地 7B 模型对这批短文本的准确率是 86%，云端大模型当时是 89%，误差控制在可接受范围内。这说明在很多实际业务场景里，本地模型并非“不可用”，只是需要你在性能和隐私之间做个取舍。

6.2 长文档任务中的上下文截断问题与修复

在跑一批长文档摘要任务时，出现了前面提到的上下文截断问题。任务原本文档长度约 15000 token，Ollama 默认上下文窗口 4096，导致模型只读到了文档的前四分之一，输出摘要严重偏差——甚至把开头几段的内容当成了全文重点。

修复过程如下：

1. 先确认当前模型的num_ctx配置确实为 4096：ollama show qwen2.5:7b。
2. 写一份 Modelfile 把num_ctx设置为 32768。
3. 用ollama create qwen2.5-32k -f Modelfile生成新模型标签。
4. 修改 OpenClaw 的模型名称为qwen2.5-32k。
5. 重启 OpenClaw 服务，重新跑同一批任务。

修复后，模型能覆盖完整文档上下文，摘要质量明显提升。同时显存占用升到了约 9GB。如果你的显卡是 8GB 版，这个方案就跑不动了，这时候要么把文档切片分批处理，要么退回 16K 上下文并在 OpenClaw 侧做文本截断。

6.3 过程中最容易被忽视的坑：磁盘空间与模型缓存

最后一个容易忽略的坑是磁盘空间。Ollama 的模型文件非常大——7B Q4 量化模型大约 4.7GB，14B 大约 9GB，32B 大约 20GB。ollama pull之后，这些模型会缓存在~/.ollama/models/下，如果你经常拉取多个模型，几十 GB 的占用很正常。我在某次任务中途出现过“磁盘空间不足导致模型加载失败”的报错，一开始完全茫然，最后执行df -h才发现根目录已经满了。

建议动手之前检查三块磁盘空间：模型缓存目录所在分区、OpenClaw 日志目录所在分区、临时目录/tmp。每块至少留 10GB 余量。不要用 root 权限直接把整个models目录软链到别的盘，这个操作在 Ollama 的某些版本里会导致模型识别异常，我用过，然后后悔了。正确做法是在启动前设置模型目录：

export OLLAMA_MODELS=/data/ollama/models

把模型和环境数据迁到大容量磁盘，并且记得ollama pull之前确认这个目录有足够空间。这个操作应该在安装后第一次跑模型前完成，不然中途一换目录，所有已拉取模型都得重新下载。

7. 结合个人实践，给出三个能让体验翻倍的额外建议

内容写到这里，OpenClaw 对接 Ollama 的主流程已经说透了。最后再分享三个我在反复使用中沉淀下来的额外建议，每一个都能让你少走弯路。

第一个建议，版本锁定意识。OpenClaw 和 Ollama 都在高频更新，兼容性经常因为小版本变化而波动。我目前使用的是 OpenClaw 的某个稳定版和 Ollama 0.3 系列，这个组合经过长时间验证非常稳。如果你新装了最新版遇到奇怪问题，优先看 release note 里关于“OpenAI 兼容端点变更”的部分，很可能就是接口结构调整了。不要一上来就怀疑硬件或系统。

第二个建议，把模型能力档案记在笔记里。我给每个常用模型建了一张档案卡，记录它的最佳任务类型、最适合的温度、上下文窗口上限、显存占用、响应速度。当新任务出现时，直接查档案匹配模型，而不是盲目试。这张档案卡相当于给智能体配了一份“调度手册”，能显著减少调试次数。

第三个建议，从单体模型走向小模型集合。OpenClaw 支持不同 Agent 用不同模型。我在实际项目中是这样拆的：日常对话用 7B 模型，代码生成用 14B 代码专用模型，复杂规划用 32B 模型。每个近似任务模型各司其职，整体效果远超单个通用大模型，而且推理成本总和更低。本地模型最大的优势就是部署多个成本低——充分利用这个优势，你会发现“集合效应”比追求单一模型的“天花板”实在得多。

这套“对接-验证-调优-复盘”方法论，我前后用了大概两周才完全跑通。如果你按照这篇文章的顺序一步步来，应该能把这个周期压缩到一天以内。本地模型的路确实比云端曲折一些，但当整个推理链路完全掌控在自己手里，那种踏实感值得你颠簸一趟。