企业官网建设流程全解析

上个月我又被一份云端 API 账单气到不行：只是让 AI 助手帮我写点小脚本、整理几份日志，月底一算居然够我吃好几顿火锅。更别扭的是，工作内容还要先经过别人家的服务器转一圈，数据隐私这块始终心里没底。于是我开始认真琢磨一件事——能不能把大模型变成自己手里一台“随叫随到的私有服务”，既省下订阅费，又完全掌控数据。折腾了一周多，最后落地的方案就是标题里这套组合：虚拟机里的 Ubuntu 长期跑 OpenClaw，再联动 Ollama 加载开源模型，把原来要付费调云端大模型才能干的活，全部搬到本地完成。

这套方案适合谁？我觉得两类朋友最需要：一类是不想再被按量计费 API 账单绑架的人，另一类是对数据敏感、希望所有操作都留在自己环境里的开发者。哪怕你只有一台普通 x86 电脑，没有独立显卡，只要 CPU 凑合、内存有 8GB 以上，就能把 7B/8B 级别的开源模型跑起来，获得相当于云端通用模型的八成体验。

1. 方案拆解：为什么是“虚拟机 + Ubuntu + OpenClaw + Ollama”这套组合

1.1 先聊清楚 OpenClaw 到底解决什么问题

很多人第一次听说 OpenClaw 时会把它和聊天助手搞混。聊几句以后才反应过来，这东西不是“陪你说话”的，而是“帮你把活干完”的。

打个比方：普通聊天模型是一个顾问，你问它问题，它给你建议，但动手还得靠你自己。OpenClaw 是一个代理，它把大模型接上各种工具——终端、文件系统、浏览器、代码编辑器——然后由模型自己拆解任务、依次调用工具、检查执行结果，直到整个目标落地。你可以直接说“把某个目录下所有 .log 文件按日期归档并压缩”，它会自己写脚本、执行、确认输出，而不是只给你一段“你可以这样做”的废话。

这个定位很关键。因为单靠本地开源小模型，和云端旗舰模型直接对话，差距还是有的。但一旦把任务从“开放式问答”变成“工具调用 + 结果验证”，小模型的短板就被结构化的工具协作补掉一大截。OpenClaw 能发挥多少价值，取决于你给它接了多少工具、设置了什么流程，而模型本身的绝对智商反而退居其次。

1.2 为什么要虚拟机，而不是直接在物理机上装

我见过不少朋友一上来就在主力机上直接部署，装完爽了三天，某个代理脚本突然把家目录搞得一团乱，后悔都来不及。所以我在这个项目里坚持用虚拟机，理由很朴素：

一来是隔离。OpenClaw 被赋予了执行命令的能力，它再怎么守规矩，也是由模型驱动的程序，总有意想不到的操作。放在虚拟化环境里，最坏的结果是这虚拟机炸了，宿主机毫发无损。

二来是快照。部署前拍一个干净快照，接下来随便改配置、试新模型、跑激进任务，弄崩了直接回滚，整个试错成本被压到几乎为零。我后来所有实验都是“先快照，再动手”的节奏，心理负担完全不同。

三来是形态接近真实服务器。虚拟机里的 Ubuntu 和云服务器上的环境基本一致，配置 SSH、防火墙、开机自启服务这些操作，全都可以直接迁移到将来可能购买的云主机上。在虚拟机里先练熟，比在生产环境里边哭边学强太多。

1.3 这套组合对硬件的要求没那么玄乎

很多人一听“本地跑大模型”就觉得要买几万块的显卡。其实对 7B/8B 这个级别的量化模型来说，CPU 加内存就能跑，只是生成速度比高端显卡慢一些，但完全可以接受。

我给这套实验环境定的最低配置是 4 核 CPU、8GB 内存、60GB 动态磁盘。模型量化后大概占用 5-6GB 内存，剩下 2GB 左右给 Ubuntu 和 OpenClaw 跑，刚好不卡。如果你有两根 16GB 内存，那就宽裕很多，甚至可以同时常驻两个模型。我实际测试下来，用 CPU 跑 Qwen2.5 7B 量化版，生成速度大约每秒 8-15 个 token，对于“写脚本、改文件、跑命令”这类任务已经足够用。

2. 虚拟机这一步省不得：Ubuntu 环境搭建与安全基线

2.1 创建虚拟机：资源配置真的不需要纠结

虚拟化软件我选的是 VirtualBox，免费开源，跨平台，功能对个人用户完全够用。你要是习惯 VMware 的免费个人版，操作逻辑也差不多。

创建虚拟机时，几个关键参数我按照下面这样填：

网络这块多说一句。默认 NAT 模式下虚拟机可以访问外网，但宿主机和虚拟机之间的互通需要靠端口转发完成。比如你要在宿主机浏览器里访问 OpenClaw 的 Web 管理面板，就设置一条规则：宿主机 8080 端口转发到虚拟机 8080 端口。这样既方便访问，又不会让服务直接暴露到整个局域网，安全性好很多。

2.2 安装 Ubuntu 24.04 LTS 与增强组件

系统镜像我直接选了 Ubuntu 24.04 LTS 长期支持版，从官方渠道下载 ISO 后挂载到虚拟机光驱，开机进入安装界面。安装过程没有特别需要动脑的地方，唯一提醒两点：分区选择“使用整个磁盘”就行，这套环境就是为实验准备的，没必要折腾分区；用户名别设成 root，我习惯建一个叫 deploy 的普通用户，后面所有服务都用这个用户跑，安全基线做起来也顺。

系统装完后第一件事是把 SSH 服务和增强组件装好。增强组件这个容易被忽略，它直接决定你能不能顺畅地缩放窗口、共享剪贴板、共享目录。在 VirtualBox 菜单里选择“安装增强功能”，然后在 Ubuntu 终端里挂载镜像、执行安装脚本，重启即可。重启之后用 SSH 连进去干活，比在虚拟机窗口里操作舒服得多，也顺便验证了 SSH 通路。

2.3 上线前的安全基线：新环境不要裸奔

很多教程装完系统直接开始部署，我不太建议。花十分钟把基础安全做了，后面能省很多麻烦。

第一件是建普通用户并且日常不用 root。Ubuntu 默认禁用了 root 远程登录，我们新建的 deploy 用户走 sudo 提权就够了。第二件是配置 SSH 公钥登录。宿主机上生成一对密钥，把公钥写进虚拟机的~/.ssh/authorized_keys，然后在 SSH 配置文件里把密码登录关掉。以后只有持有私钥的人能登录，暴力破解基本跟你无缘。第三件是打开 UFW 防火墙，默认只放行 SSH 端口和你有服务对外监听的端口，其余全部拒绝。

这三件事做完，一个“能干活但不好惹”的 Ubuntu 环境基础就立住了。后面部署 OpenClaw 和 Ollama，全在这个基础上操作。

3. Ollama 先跑起来：本地模型服务的安装与模型选择

3.1 一条命令装好 Ollama，常用命令顺手过一遍

Ollama 在 Linux 下安装非常省心，官方提供了一行脚本。进到虚拟机终端，确认 curl 已安装，然后执行：

curl -fsSL https://ollama.com/install.sh | sh

脚本会自动下载二进制文件、创建 systemd 服务并设置开机自启。装完以后验证一下：

ollama --version systemctl status ollama

第一行命令能输出版本号说明安装成功，第二行看到 active (running) 说明服务已经常驻。之后可以从官方模型库直接拉模型：

ollama pull qwen2.5:7b ollama list

Ollama 最大的价值就是把“下载模型、起服务、暴露 API”这些繁琐事情全部封装好。它对系统来说只是一个监听在 11434 端口的本地服务，任何程序都可以通过 HTTP 接口调用它。OpenClaw 之所以能和它联动，本质上就是把 OpenClaw 的模型提供方指向这个本地 API。

3.2 模型怎么选：先跑 7B/8B，别一把梭上 70B

本地模型的选择直接决定体验，我踩过“贪大求全”的坑，也总结出一个很朴素的原则：先跑你机器跑得动的最小可用模型，把整套链路调通，再考虑升级。

内存估算可以用一个很粗糙的公式：量化后的模型体积大约是参数量的 0.5-0.6 倍（以 Q4 量化为例），再加上运行时的 KV Cache 缓冲，所以 7B 模型大概要 5-6GB。写作时我第一推荐 Qwen2.5 7B，它在中文场景下的工具调用、代码生成表现都不错，而且社区反馈和 OpenClaw 这类代理框架的兼容性比较稳定。

还有一个容易被忽略的点：模型名称必须精确匹配。Ollama 里同一个系列会区分qwen2.5:7b和qwen2.5:7b-instruct，如果填错名字，调用时直接报 404。后面配置 OpenClaw 的时候，这个细节最好先记下。

3.3 按需开放访问地址：默认只监听本机，够用就别乱改

Ollama 装完以后默认只监听127.0.0.1:11434，也就是说只有虚拟机内部能访问。如果你的 OpenClaw 也跑在同一个虚拟机上，那保持默认就好，安全性最好，不需要任何改动。

但如果你打算把 OpenClaw 跑在宿主机上的 Docker 容器里，或者想从宿主机直接用 API 调试，就需要让 Ollama 监听在非回环地址上。改法是通过 systemd 覆盖配置：

sudo systemctl edit ollama

在编辑器里填入：

[Service] Environment="OLLAMA_HOST=0.0.0.0"

保存后重启服务：

sudo systemctl restart ollama

改完以后记得通过 UFW 放行 11434 端口，并且用端口转发规则映射到宿主机，不要直接把整个虚拟机网络改成桥接。等于把 Ollama 服务“藏”在虚拟机里，只对需要的地方开一条窄路，而不是大门敞开。

4. OpenClaw 部署与联动 Ollama：核心配置全过程

4.1 安装 OpenClaw：依赖不多，装法很随意

OpenClaw 的安装方式比较灵活，可以用官方提供的脚本，也可以直接下载发布包手动部署。我选择手动方式，因为更容易看清文件装到了哪里，后续排查问题时心里有数。

依赖方面，核心其实只需要 curl、git、以及一个能找到可执行文件的 PATH。如果后续想让 OpenClaw 调用 Docker 工具，还需要装 Docker，但最开始没必要。进入虚拟机的 deploy 用户环境，下载对应平台的压缩包，解压后把二进制文件移动到/usr/local/bin，验证版本：

openclaw --version

初次运行时，OpenClaw 会在当前用户的家目录下生成配置目录，我这里的路径是~/.openclaw/。里面包含配置文件、日志目录和会话记录。整个设计对运维很友好：所有状态都在一个目录里，备份、迁移、回滚都很容易。

4.2 Provider 配置是关键：base URL、模型名、上下文窗口

OpenClaw 本身不带模型能力，它需要连接某个模型服务来获得“大脑”，这个连接点叫 Provider。我们要做的就是把 Provider 指向本机 Ollama 提供的 API。

在~/.openclaw/下找到主配置文件，把默认的 provider 段改成下面这样：

provider: ollama model: qwen2.5:7b base_url: http://localhost:11434 context_window: 8192 temperature: 0.3

这里几个字段的含义我展开说一下：

base_url是 Ollama 服务的地址。因为 OpenClaw 和 Ollama 在同一台虚拟机里运行，所以 localhost 即可。如果你把 OpenClaw 装在宿主机、Ollama 装在虚拟机，那这里的地址要换成虚拟机的 IP，同时确保 11434 端口已开放。

model必须和ollama list里显示的名字完全一致，包括冒号后面的标签。我之前写的是qwen2.5而不是qwen2.5:7b，结果调用直接失败。这个坑后面还会再强调。

context_window决定模型一次能干多少事。8K 是最低建议，太小的上下文会导致任务拆解到一半就丢信息，尤其是需要反复看日志、改文件的场景。内存如果宽裕，可以设置 16K，效果会好不少。

4.3 首次对话与工具调用验证：让模型真正“动手”

配置改完，先做个最小验证。我在终端里启动 OpenClaw 的交互模式，然后输入一句简单任务：

帮我用 Python 写一个脚本，在 /tmp/demo.txt 里写入一行文字：hello from openclaw

如果是普通聊天工具，它大概率会直接输出代码，然后把写文件的活丢回给你。但 OpenClaw 会真的去执行：调用 shell 工具、创建脚本、运行脚本、确认文件内容。整个过程在终端里可以看到一行接一行的工具调用日志，比如Running command: python3 /tmp/xxx.py，最后告诉你结果。

第一次看到这个“模型自己动手把事办完”的完整链路，还挺有成就感的。这一步验证通过，相当于 OpenClaw 和 Ollama 的联动已经打通，后面所有花哨功能都是在这个基础上叠加。

4.4 如果 OpenClaw 在容器里跑，连通 Ollama 要注意网络

我一开始也试过用 Docker 方式跑 OpenClaw，省得在虚拟机上直接装。但那时候 Ollama 是直接装在虚拟机里的，两者之间的网络一开始没对上，遇到典型的“容器里 localhost 和宿主机的 localhost 不是同一个”的问题。

三个解法按优先级排列：

最简单的是让 OpenClaw 容器直接使用 host 网络模式，容器内的 localhost 就等同于虚拟机的 localhost。代价是端口冲突时比较难办，但单机环境无所谓。

次选是让 OpenClaw 容器和 Ollama 都跑在同一个自定义 Docker 网络里，然后 base_url 填 Ollama 容器的服务名。

最麻烦的是用宿主机在 Docker 默认网桥中的网关地址，比如 172.17.0.1，这个办法容易因为 Docker 版本不同而翻天覆地，我最后没有采用。

我的建议很直白：如果 Ollama 已经直接用 systemd 跑在虚拟机上了，那 OpenClaw 干脆也直接跑在虚拟机里，别绕一圈 Docker。减少一层网络，少一堆头疼。

5. 实测几个真实任务：它到底能帮我干什么活

5.1 任务一：给一个本地小项目生成单元测试

模型跑通以后，我第一个想到的最实用的场景是给项目写测试。我把一个模拟项目 X 的源码目录放到虚拟机的/home/deploy/work/demo下，然后给 OpenClaw 下指令：“分析这个项目的结构，找出核心模块，给核心函数生成单元测试，并且运行给我看。”

它做的比我预想中更稳：先用ls -R和读取文件内容了解项目，然后识别出一个工具函数模块，生成对应测试文件，调用python3 -m pytest运行，发现一个断言失败后又自己读了报错信息，修正了测试数据，最后输出全绿的结果。

整个流程里我只发了一条指令，后面全是它自己决策。虽然第一次跑花了两分多钟，但省下的手动写测试时间远不止这些。对这个体验，我的评价是：小模型在“有明确目标 + 能反复试错”的任务里，表现得比“开放式问答”好得多。

5.2 任务二：把混乱的下载目录按扩展名归档

另一个我经常用到的场景是文件整理。我把一个塞了几十种文件的目录丢给它：图片、PDF、代码文件、压缩包全混在一起，让它“按扩展名分类到对应文件夹，并且每个分类加一个清单文件说明有哪些内容”。

它会先列出目录内容，再创建一个 shell 脚本来完成归档。运行完成后还主动检查了每个子目录的文件数量，确认没有遗漏。最后它在原始目录里生成了一份SUMMARY.md，把每个文件夹的文件列表都写了进去。

这个任务对模型智力要求不高，但对工具调用和任务拆解能力要求很高。以前我都是自己写 shell 命令慢慢处理，现在一句指令就完事。而且因为所有操作都发生在虚拟机内部，就算它某次归档逻辑写错了，文件挪错位置，快照一还原就回来，没有任何心理负担。

5.3 任务三：分析应用日志，帮我定位报错原因

第三个场景是排障。虚拟机上登录了一个测试服务的日志目录，里面有几份大小不一的滚动日志。我让 OpenClaw “找出这段时间服务报错最频繁的类型，统计出现次数，并给出三个最可能的修复方向”。

它的做法是先读取日志文件，用正则统计关键字，识别出数据库连接超时是最高频错误，然后依据时间分布特征猜测可能是因为连接池太小或慢查询导致连接被占满。最后还给出一条具体的排查命令：查看数据库最大连接数以及当前活跃连接数。

虽然它的分析和资深运维的结论还有差距，但它把“人肉读日志半小时”压缩成了“两分钟出报告”。这种价值在大模型和人工之间形成了很直接的互补——复杂判断人来做，耗时翻页的活交给代理工具。

6. 踩坑清单：部署环节最容易卡人的六个细节

6.1 模型名不带版本标签，调用失败

Ollama 的模型名是qwen2.5:7b这种“名称 + 冒号 + 标签”的格式。我在 OpenClaw 配置里图省事写了qwen2.5，结果调用提示找不到模型。跨系统方可能觉得不就是一个名字，但对 Ollama 来说这属于精确匹配，少一个标签就完全不同。解决方法是任何时候都以ollama list的输出为准，把 model 字段填成完整名字。

6.2 Ollama 只监听 127.0.0.1，远程和容器都连不上

这是把 Ollama 当作后端服务时最经典的问题。默认监听回环地址，本机一切正常，但凡是换了网络命名空间或者从其他主机访问，都会失败。排查思路很直接：用curl http://127.0.0.1:11434验证服务在线，再curl http://<虚拟机IP>:11434验证监听地址。如果内网 IP 访问不通，就按前面讲的方法设置OLLAMA_HOST=0.0.0.0。

6.3 虚拟机内存分配太小，系统直接卡死

我开始偷懒给虚拟机分配了 6GB 内存，以为够用。结果模型加载完，OpenClaw 一跑工具，内存瞬间见底，系统开始疯狂交换，虚拟机的窗口连鼠标都动不了。最后只能强制重启，重新调大内存。经验就是：跑 8B 模型的话，内存预算至少 8GB，并预留一定的交换空间。内存是这套系统里最重要的资源，宁多勿少。

6.4 OpenClaw 调系统命令被权限卡住

代理执行命令的账户是普通用户 deploy，有些操作需要读取/var/log或写特定目录，会碰到 Permission Denied。解决思路是给必要的命令配置 sudo 免密，而不是把整个 OpenClaw 进程丢进 root 用户。我通常的做法是限制deploy用户只能免密执行特定命令集合，比如systemctl和一些日志检索命令，这样既方便工具调用，又不至于把所有权力交给模型。

6.5 上下文窗口设太小，任务做到一半丢信息

一开始我把 context_window 设成 4096，处理文件整理任务时，它读到第三十个文件的路径列表就把最早的内容“忘光”了，后面的操作逻辑开始混乱。换了 8192 之后，任务完成明显流畅起来。如果你的任务是大量文件操作或长日志分析，模型又扛得住，直接把窗口开到 16K 更好。

6.6 没做基线快照，出问题只能重装

我头几轮实验时因为偷懒没打快照，某次 OpenClaw 生成的脚本误删了虚拟机上部分系统文件，我花了一个多小时修复。后来我把“部署完成、Ollama 跑通、OpenClaw 联动成功”的那一刻设为一个里程碑，打完快照之后再做危险实验。从此再也没有需要重装系统的经历。这个习惯推荐所有人养成，性价比极高。

7. 长期跑下去：安全加固、性能调优与扩展方向

7.1 安全加固：把默认配置再收紧一圈

一套环境要长期运行，光靠初始基线还不够。运行一段时间后，我建议做三件事：

第一，OpenClaw 和 Ollama 都用普通用户跑，不用 root。第二，定期更新系统补丁，OpenClaw 这类带工具执行能力的组件更新更勤一点。第三，所有服务对外暴露的端口越少越好。如果只有你自己用，OpenClaw 的 Web 管理面板完全可以只映射到宿主机上的localhost:8080，而不要映射到局域网所有地址。

说到快照，我现在的习惯是每周打一次快照，配置改动前再打一次。磁盘空间多占一点，但换来的是一键回滚的安心感。OpenClaw 的执行能力一旦出现问题，边界就是这台虚拟机本身，这是整套架构最让我踏实的地方。

7.2 性能调优：让 Ollama 吃更少内存、干更多活

Ollama 有几个环境变量值得花时间理解，它们决定了模型服务的资源占用和并发表现。

OLLAMA_KEEP_ALIVE控制模型在内存中常驻的时间，默认是 5 分钟。如果你经常反复调用同一个模型，把时间拉长到哪怕 30 分钟，可以省去频繁加载模型的等待时间。OLLAMA_MAX_LOADED_MODELS默认值有时候是 3，如果内存不够，我直接设成 1，让单个模型独占资源，避免多个模型轮流加载把内存撑爆。OLLAMA_NUM_PARALLEL控制并行请求数量，CPU 跑模型的话，我建议设 1 或 2，太高的并行会导致每个请求都变慢。

除了环境变量，模型本身的量化版本也同样重要。Ollama 官方列表里的模型默认多为 Q4 量化，对个人用户来说性价比最高。不要盲目追求满精度，在 CPU 环境下那点精度提升换来的速度下降非常不值。

7.3 扩展方向：多模型调度、内部脚本、知识库

现在这套环境已经能满足我大部分自动化需求，但它的上限远不止于此。我目前在看几个方向。

一个方向是让 OpenClaw 根据任务类型切换模型。轻量任务用 7B 模型，省时间省内存；复杂任务切换到 14B 模型。Ollama 支持同时管理多个模型，OpenClaw 的 provider 配置里也可以按会话切换，这就相当于一个用代码控制的多档位大脑。

另一个方向是把公司内部的运维脚本接进来。比如我写了一些日常备份、健康检查的 shell 脚本，OpenClaw 可以在收到指令后直接调用它们，把本地模型变成一个能用自然语言指挥的运维入口。这个扩展对个人开发者尤其友好，不需要写复杂的服务框架。

还有一个方向是知识库。我尝试过把常用的内部文档做向量化存储，然后在提问前把相关内容检索出来，塞进 OpenClaw 的上下文，这能明显缓解小模型知识不足的问题。实现起来需要引入一个本地向量数据库，但整套架构依然可以全部留在虚拟机里，数据不出这台机器。

7.4 算一笔账：这套方案到底省了什么

最后聊聊钱。如果我继续用商业大模型 API，按照我的使用量估算，每个月写脚本、整理日志、辅助排障，大概会花掉 200 到 400 元人民币。一年下来就是三四千元。

而这套虚拟机方案的直接成本：软件全部开源，模型下载免费，电费一个月增加几十块。维护成本方面，我每周花不到半小时打快照、看版本更新、微调配置。对比结果很明显，虽然牺牲了一部分云端旗舰模型的“聪明程度”，但换来的是支出从几百元变成几十块，以及数据完全不出自己机器的安全感。

这对我来说是值得的。如果你也经常用大模型处理真实工作任务，而不是只把它当聊天玩具，我强烈建议复刻这套环境跑一周试试。把它当作一个可以随时推倒重来的沙盒，你会突然发现，原来本地开源模型离“替自己干活”这么近。