企业官网建设流程全解析

1. Strix Halo 本地跑 Ollama 为什么总卡在“只会聊天”

如果你手里有一台 Strix Halo 设备，比如搭载 Ryzen AI Max+ 的迷你主机或笔记本，大概率已经试过用 Ollama 拉几个模型跑跑对话。问它写代码、解释概念、翻译文档，体验都还不错。但一旦你想让它“动手”——读取本地某个文件夹里的 Markdown、批量总结会议记录、根据代码库生成一份变更说明——它就开始装傻，要么说“我无法访问你的文件系统”，要么干脆编一段看起来像那么回事但完全不对的内容。

这不是模型笨，而是你只给了它一张嘴，没给它手和脚。Ollama 本身是一个推理引擎，它负责把权重加载进内存、把 token 一个一个吐出来。它不负责调度工具、不负责管理多轮任务、更不负责在上下文快满的时候自动做摘要或检索。这些活需要另一个角色来做，也就是 Agent 框架。OpenClaw 就是干这个的：它把 Ollama 当作一个 OpenAI 兼容的模型提供方，然后在外面套一层任务规划、工具调用和上下文管理的逻辑。

Strix Halo 这个平台有意思的地方在于，它的统一内存架构让 CPU 和 GPU 共享一大块高带宽内存。128GB 的版本意味着你可以把参数量不小的模型几乎全量塞进去，同时还能留出足够空间给上下文缓存。但很多人第一次跑的时候会发现两个典型症状：一是 GPU 利用率上不去，风扇不转，推理速度只有个位数 token/s；二是上下文稍微长一点就报错，Agent 直接断片。前者通常是后端没选对，后者是 Context Length 没配对。

我试过在 Windows 下用 ROCm 和 Vulkan 两种后端分别跑 Ollama，Vulkan 在 Strix Halo 上的稳定性明显更好，模型加载时不容易意外回退到 CPU。所以这篇内容会围绕 Vulkan 后端来写，把 Ollama 的环境变量、OpenClaw 的配置片段、以及验证工具调用链路是否生效的命令都过一遍。目标很简单：让你本地的大模型真正能读文件、能调工具、能处理长文档，而不是停留在对话框里陪聊。

适合谁看？如果你已经能在 Strix Halo 上跑通 Ollama 的基本对话，想进一步做本地自动化、代码库分析、文档批处理，那这篇就是为你写的。如果你还没装 Ollama，也没关系，步骤会从环境变量开始，照着做就行。

2. 前置准备：Ollama 的 Vulkan 后端与 Context Length 环境变量配置

在 Strix Halo 上让 Ollama 正确调用 Radeon GPU，核心不是装什么特殊驱动，而是确保它走 Vulkan 后端而不是默认的 CPU 回退。Ollama 在 Windows 和 Linux 下对 AMD GPU 的支持策略不太一样，但共同点是：如果你不显式干预，它可能在模型加载时悄悄用 CPU 跑，表现就是推理慢、GPU 占用低。

先确认 Ollama 版本。打开终端执行：

ollama --version

建议用 0.5.x 以上的版本，对 Vulkan 后端的支持更完整。如果版本太旧，先去官网更新。更新完之后，不要急着拉模型，先把环境变量配好。

在 Windows 下，环境变量可以通过系统设置里的“环境变量”面板添加，也可以用 PowerShell 临时设置。我习惯在用户变量里加，这样重启终端也生效。需要加的关键变量有这几个：

OLLAMA_VULKAN=1 OLLAMA_KEEP_ALIVE=24h OLLAMA_NUM_PARALLEL=2 OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_CONTEXT_LENGTH=131072

逐个解释。OLLAMA_VULKAN=1是告诉 Ollama 优先使用 Vulkan 后端，这是让 Radeon GPU 真正干活的关键。OLLAMA_KEEP_ALIVE=24h让模型在内存里常驻，避免每次请求都重新加载，对 Agent 场景很重要，因为 OpenClaw 会频繁调用模型。OLLAMA_NUM_PARALLEL=2控制并发请求数，Strix Halo 内存够大，开 2 到 4 都可以，但不要开太高，否则上下文缓存会互相挤占。OLLAMA_MAX_LOADED_MODELS=1限制同时只加载一个模型，避免多个模型抢显存导致崩溃。

最重要的是OLLAMA_CONTEXT_LENGTH=131072。Ollama 默认的上下文窗口通常是 4096 或 8192，做 Agent 任务时根本不够用。你让 Agent 读一个几十页的 PDF 或者遍历一个代码库，信息还没读完就被截断了，生成的结果自然缺胳膊少腿。Strix Halo 的统一内存优势就在这里：128GB 的版本可以轻松撑起 128k 甚至更长的上下文。设置成 131072 就是 128k，这是很多模型支持的上限，也是实际测试中比较稳的值。

在 Linux 下，可以把这些写进~/.bashrc或~/.profile：

export OLLAMA_VULKAN=1 export OLLAMA_KEEP_ALIVE=24h export OLLAMA_NUM_PARALLEL=2 export OLLAMA_MAX_LOADED_MODELS=1 export OLLAMA_CONTEXT_LENGTH=131072

然后source ~/.bashrc让配置生效。设置完之后重启 Ollama 服务。Windows 下可以在任务管理器里结束 ollama 进程，然后重新运行ollama serve。Linux 下用systemctl restart ollama或者手动重启。

接下来拉模型。推荐 Qwen2.5-Coder 或 Llama-3.1 的量化版本。量化等级的选择有个经验：不要盲目上 Q6 或 Q8，虽然精度高，但在长时间运行的 Agent 场景下更容易崩。Q5_K_M 是智能程度和稳定性的平衡点。拉模型的命令：

ollama pull qwen2.5-coder:14b-instruct-q5_K_M

如果你的 Strix Halo 是 128GB 版本，可以上更大的参数，比如 32b 的量化版。拉完之后用ollama list确认模型在本地。

验证 Vulkan 后端是否生效，可以跑一个简单请求，同时开另一个终端看 GPU 占用。Windows 下用任务管理器的性能标签，Linux 下用radeontop或nvtop（如果装了）。执行：

ollama run qwen2.5-coder:14b-instruct-q5_K_M "用一句话解释什么是递归"

如果 GPU 占用明显上升，推理速度在 20 tokens/s 以上，说明 Vulkan 后端在工作。如果 GPU 几乎不动、CPU 跑满，回去检查OLLAMA_VULKAN=1是否真的生效，有时候需要重启终端甚至重启系统。

还有一个容易忽略的点：Strix Halo 的驱动版本。较新的芯片可能需要设置HSA_OVERRIDE_GFX_VERSION，但这个变量主要影响 ROCm 路径，Vulkan 路径一般不需要。如果你在 Linux 下用 ROCm 遇到问题，可以尝试加这个变量，但本篇以 Vulkan 为主，先不展开。

3. 可复制配置：OpenClaw 接入本地 Ollama 的 JSON 片段与参数对照

Ollama 跑通之后，下一步是让 OpenClaw 连上它。OpenClaw 是一个开源 Agent 框架，它的作用是接收你的自然语言指令，拆解成步骤，然后调用模型和工具去执行。它需要一个模型提供方，Ollama 的 OpenAI 兼容接口正好可以用。

OpenClaw 的配置文件通常在~/.openclaw/config.json，Windows 下在C:\Users\你的用户名\.openclaw\config.json。如果文件不存在，手动创建一个。下面是一个经过验证的配置片段，你可以直接复制，然后按自己的模型名调整：

{ "models": { "providers": { "ollama-local": { "baseUrl": "http://127.0.0.1:11434/v1", "apiKey": "ollama", "api": "openai-compatible", "models": [ { "id": "qwen2.5-coder:14b-instruct-q5_K_M", "contextWindow": 131072, "maxTokens": 8192 } ] } } }, "agents": { "defaults": { "model": { "primary": "ollama-local/qwen2.5-coder:14b-instruct-q5_K_M" } } } }

这里有几个参数必须和 Ollama 那边对齐。baseUrl指向 Ollama 的 OpenAI 兼容端点，默认端口 11434，路径是/v1。apiKey随便填，Ollama 不校验，但 OpenClaw 要求有这个字段，写ollama就行。api指定为openai-compatible，这样 OpenClaw 会用 OpenAI 的请求格式去调。

contextWindow必须和OLLAMA_CONTEXT_LENGTH一致，都是 131072。如果这里设小了，比如只写 8192，Agent 在处理长文档时会直接报Context window too small，任务中断。maxTokens控制单次生成的最大 token 数，设成 8192 是为了让生成的报告足够详细。如果是简单问答，可以调到 2048 或 4096，响应更快。

agents.defaults.model.primary里的格式是提供方名称/模型ID，要和上面providers里的键名以及models里的id完全对应。写错了会报模型找不到。

如果你用的是 Cline 或者 Claude Code 这类工具，配置逻辑类似，都是填 Base URL、API Key、Model ID 三件套。Base URL 填http://127.0.0.1:11434/v1，API Key 填ollama，Model ID 填你拉下来的模型名。有些工具要求填完整的模型路径，比如ollama-local/qwen2.5-coder:14b-instruct-q5_K_M，注意区分。

配置写完后，重启 OpenClaw 服务。如果是命令行启动的，Ctrl+C 停掉再重新运行。然后检查日志，看它有没有成功加载配置、有没有报连接错误。正常的话会看到类似Loaded provider ollama-local和Agent default model set to ...的输出。

这里有个细节：OpenClaw 在启动时会尝试连接模型提供方做健康检查。如果 Ollama 没在运行，或者端口不对，会报local proxy failed或connection refused。所以确保 Ollama 服务先起来，再启动 OpenClaw。

另外，如果你在 OpenClaw 里配置了多个提供方，比如同时有云端 API 和本地 Ollama，注意primary指向的是本地那个。Agent 默认走 primary，除非你在具体任务里覆盖。

4. 验证工具调用链路：从读取文件到生成报告的完整命令与预期输出

配置写完只是第一步，真正要确认的是工具调用链路有没有生效。也就是说，Agent 能不能真的读到本地文件、能不能把文件内容塞进上下文、能不能调用模型生成结果。下面用一个具体任务来验证：让 Agent 读取当前目录下所有.md文件，总结核心观点，生成一份新的汇报文档。

先准备测试环境。新建一个目录，放几个 Markdown 文件进去：

mkdir -p ~/agent-test && cd ~/agent-test echo "# 项目周报\n本周完成了登录模块的重构，修复了三个历史遗留 bug。" > report1.md echo "# 技术调研\n对比了三种向量数据库的检索性能，Qdrant 在本地部署场景下表现最稳。" > report2.md echo "# 会议记录\n讨论了下一阶段的排期，决定优先做工具调用链路的稳定性验证。" > report3.md

然后启动 OpenClaw，给它下指令。具体命令取决于 OpenClaw 的 CLI 用法，假设它支持openclaw run或者交互式对话。在交互式模式下输入：

读取当前目录下所有 .md 文件，总结每份文件的核心观点，然后生成一份汇总报告保存为 summary.md

预期行为是：OpenClaw 先调用文件读取工具，遍历目录，把三个文件的内容读进来。然后把这些内容作为上下文发给 Ollama，让模型做总结。模型返回总结后，OpenClaw 再调用文件写入工具，把结果保存成summary.md。

如果链路正常，你会在终端看到类似这样的日志：

[agent] Planning task: read files, summarize, write report [tool] list_files: found 3 files [tool] read_file: report1.md (86 bytes) [tool] read_file: report2.md (102 bytes) [tool] read_file: report3.md (98 bytes) [model] ollama-local/qwen2.5-coder:14b-instruct-q5_K_M [model] tokens: prompt=412, completion=256 [tool] write_file: summary.md (512 bytes) [agent] Task completed

然后cat summary.md看结果，应该能看到三份文件的要点汇总。如果只看到模型在胡编，或者报Context window too small，说明上下文配置没对齐。如果报tool not found或permission denied，说明工具权限没开。

验证工具调用是否真的走了模型，而不是 OpenClaw 自己拼字符串，可以看日志里的[model]行。有 prompt 和 completion 的 token 计数，说明确实调了 Ollama。如果这一行没有，或者显示skipped，那模型根本没参与。

另一个验证方式是故意给一个需要多步推理的任务，比如：

读取 report1.md，找出里面提到的 bug 数量，然后乘以 2，把结果写进 math.md

这个任务需要模型理解“三个历史遗留 bug”这句话，提取数字 3，做乘法，再写文件。如果 Agent 能正确输出 6，说明模型和工具链是打通的。如果输出的是原文复制或者乱码，说明模型没理解或者上下文没传对。

在 Strix Halo 上跑这个流程，速度取决于模型大小和上下文长度。14B Q5_K_M 在 Vulkan 后端下，128k 上下文的首次加载可能需要十几秒，之后每个请求的响应在几秒到十几秒之间。如果发现特别慢，先检查 GPU 占用，再检查OLLAMA_NUM_PARALLEL是不是设太高导致上下文缓存频繁换出。

5. 常见报错排查：401、local proxy failed、Context window too small 与 OAuth 问题

实际跑的时候，大概率会遇到几个典型报错。下面按报错信息逐个拆。

401 Unauthorized。这个通常出现在 OpenClaw 连接 Ollama 的时候。Ollama 本身不校验 API Key，但 OpenClaw 的 OpenAI 兼容客户端可能会因为apiKey字段为空或者格式不对而报 401。检查config.json里的apiKey是不是写了ollama，不要留空。如果用的是其他工具，比如 Cline，同样填一个非空字符串就行。有些工具要求 Key 以sk-开头，但 Ollama 不认这个，填ollama反而能过。如果还是 401，检查baseUrl是不是写成了http://127.0.0.1:11434而漏了/v1。

local proxy failed。这个报错说明 OpenClaw 尝试连接本地模型提供方时失败了。最常见的原因是 Ollama 服务没启动，或者端口被占用。先执行ollama list确认服务在跑。如果没跑，ollama serve启动。如果端口 11434 被别的程序占了，改 Ollama 的监听端口，同时改 OpenClaw 的baseUrl。Windows 下可以用netstat -ano | findstr 11434查占用。另一个可能是防火墙拦了本地回环请求，但这种情况少见，一般只在某些企业安全软件下出现。

Context window too small。这个报错最典型，也最容易解决。原因是 Ollama 的OLLAMA_CONTEXT_LENGTH和 OpenClaw 的contextWindow不一致。比如 Ollama 设了 131072，但 OpenClaw 里只写了 8192，Agent 在处理长文档时就会报这个错。两边必须完全一致。改完之后重启两个服务。如果改完还报，检查模型本身支持的最大上下文。有些量化版模型在导出时限制了上下文长度，比如只支持 32k，那你设 128k 也没用，模型加载时会截断。换一个支持长上下文的模型，或者把两边都降到模型支持的上限。

OAuth 相关报错。如果你在 OpenClaw 里同时配了云端提供方，比如某些需要 OAuth 的服务，可能会在启动时尝试刷新 token 失败，然后报错。如果你只用本地 Ollama，可以把云端提供方的配置删掉，或者在agents.defaults.model.primary里明确指向本地模型，避免它去走 OAuth 流程。如果报错信息里出现OAuth token expired或refresh failed，检查是不是有残留的云端配置在干扰。

模型加载崩溃或推理中断。Strix Halo 内存虽然大，但如果你同时加载了多个模型，或者OLLAMA_MAX_LOADED_MODELS设成了大于 1，上下文缓存会互相挤占，导致崩溃。设成 1，只加载当前用的模型。另外，量化等级太高（Q6/Q8）在长时间运行下更容易出问题，降到 Q5_K_M 或 Q4_K_M 试试。如果还是崩，检查 NVMe 剩余空间，Ollama 在加载大模型时可能需要磁盘做交换缓存，空间不足会直接失败。

GPU 利用率低、推理慢。回去检查OLLAMA_VULKAN=1是否生效。可以在 Ollama 启动日志里找vulkan字样，如果没有，说明后端没走 Vulkan。Windows 下有时候需要把 Ollama 的安装目录加到 PATH，或者用管理员权限启动。Linux 下检查用户是否在render和video组里，没有的话加进去再重启。

排查的时候，日志是最好的朋友。Ollama 的日志在 Windows 下通常在%LOCALAPPDATA%\Ollama\，Linux 下在journalctl -u ollama或~/.ollama/logs/。OpenClaw 的日志在它的运行目录或~/.openclaw/logs/。先看报错关键词，再对照上面的情况定位。

6. 把本地 Agent 跑顺之后，下一步可以做什么

链路验证通过之后，你可以把 OpenClaw 接到更多工具上。比如让它调用 shell 命令做文件批量重命名，或者接一个简单的 HTTP 工具去查本地服务的状态。Strix Halo 的算力足够支撑这些轻量级自动化任务，而且所有数据都在本地内存里流转，不经过外部网络。

如果你想让模型能力再上一个台阶，可以考虑用 TaoToken 的模型对话功能来对比不同模型在工具调用场景下的表现。本地 Ollama 跑的是开源模型，TaoToken 那边可以快速切换不同提供方的模型，看看同样的任务在别的模型上是不是更稳。接入方式很简单，把 Base URL 换成https://taotoken.net/api，API Key 在控制台生成，模型 ID 按文档填就行。对于长期做编码和 Agent 任务的场景，Coding Plan 会更划算，不用每次单独算 token。

本地 Agent 的价值在于可控和可重复。你调好一次配置，之后每次跑任务都是同样的环境、同样的模型、同样的上下文长度，不会因为云端服务的波动而受影响。Strix Halo 的统一内存让这种稳定性有了硬件基础，剩下的就是慢慢把工具链打磨顺。