企业官网建设流程全解析

养一只自己的“数字龙虾”，听起来像在说某个休闲游戏，但实际上现在是不少开发者之间的暗号——把一套AI Agent框架通过Docker装进自己的服务器，再让本地大模型当它的“大脑”，最终得到一个完全自主、不依赖外部API、只属于你的智能助理。这套方案的核心就是Openclaw加Docker加本地大模型，我把它叫“养龙虾”，因为那只Agent的外壳确实越看越像一只有钳子的节肢动物，工具调用那一下，也是咔嚓一声，干脆利落。

我不太喜欢那种“又一个玩具项目”的调调，这东西实打实能解决一个问题：你想把AI接进自己的工作流，但又不想每一次对话都被第三方记录下来。Openclaw本身可以理解为一套自带工具调用能力的Agent骨架，加上了Docker之后，整只“龙虾”就被关进一个独立、干净、随时可重建的透明水缸里；而本地大模型则负责真正“消化”指令，推理过程全部发生在你自己的硬件上。如果你也想在本地搭一个真正独立的Agent，又没耐心看那些动不动就上云的项目，这篇文章应该能让你少踩很多坑。

1. 整体思路：为什么是“养一只龙虾”

1.1 “龙虾”到底指什么

先用一句话把概念说清楚：Openclaw是一个开源的Agent框架，你给它一个任务目标，它会自己拆解步骤、调用工具、查看结果，然后继续下一步，直到完成任务。把Agent比作龙虾，其实有三层意思。

第一层是“有钳子”。龙虾最显眼的就是那对大螯，对应到Agent上就是工具调用能力。你喂它一句话，它不只是回复你一句话，而是会自己决定要不要调用搜索引擎、要不要读写文件、要不要执行某段脚本。这跟那种一问一答的聊天机器人完全不同，更像是“带着工具箱的实习生”。

第二层是“养在缸里”。野生龙虾你抓不到，但养在水族箱里你就可以控制水温、过滤、投喂，出了问题还能整个换水。这对应Docker容器的隔离性：Agent的运行环境、依赖、配置都被锁在一个容器里，宿主机再怎么折腾都不受影响。

第三层是“喂食”。龙虾靠吃长大，Agent靠数据和大模型推理“进食”。大模型的每一次推理就是一次消化，产物是回答问题或执行任务。本地大模型方案下，这个“食物”进来、消化过程都在你的机器里完成，没有任何中间的云服务介入。

1.2 Docker这只透明水缸，到底解决了什么

很多人在本地跑过Agent，第一反应往往是直接裸机装依赖，开了个Python虚拟环境，然后装了一堆包，最后系统环境烂得跟被水草缠住一样。我的建议是：从一开始就上Docker，这不是为了追时髦，而是因为Agent项目有一个很麻烦的特点——依赖极度混乱。

Openclaw这类框架通常会牵扯到Python运行时、Node组件、各种SDK、可能还有单独的向量库，加上版本兼容问题，直接在宿主机上安装就像把所有工具都扔在一个工具箱里，找一次扳手要翻十分钟。Docker把这一坨东西整体封进镜像，你只需要告诉它“跑起来”，它就会在一个独立环境里启动，所有依赖互不干扰。升级、回滚、迁移都变得很简单：镜像打一个tag，容器停了再起，毫不费力。

更重要的是可复现性。你在自己电脑上搞出来的环境，换一台机器重新部署很可能会跑不起来。而容器化之后，一个compose文件就能在另一台服务器上还原出一模一样的环境。这个价值在做实验、换机器、给朋友分享方案的时候尤其明显。

1.3 为什么一定要接本地大模型，而不是用现成API

“不依赖外部API”并不是偏执。你想想，Agent跟聊天机器人有一个根本区别：聊天机器人对话内容多半是闲聊和无害提问，而Agent为了完成任务，会频繁读取文件内容、执行命令、访问你的用户信息、访问内部系统，这些上下文如果全部丢给外部API，等于把你服务器的钥匙递给了别人。

我举个实际例子：我把Openclaw接进了一个本地文件管理流程，让它根据我的习惯自动分类下载文件夹。这些文件名和路径本身就是很敏感的信息，里面全是个人资料的痕迹。如果走外部API，这些信息就会作为上下文传出去。而本地大模型方案，所有推理都在本地完成，虽然效果上可能不如超大模型那么惊艳，但隐私边界非常清晰：数据到我机器为止，绝不越界。

除此之外还有一个很实际的理由——断网可用。本地模型跑起来后，就算路由器拨号断了、域名解析漂了，你的Agent照样能干活。这个特征对远程服务器场景尤其重要，毕竟你在机房里的机器不一定时刻都有稳定的外网。

2. 动手之前，这几个核心细节必须先想清楚

2.1 硬件最低标准到底是什么

按照我的经验，这件事没有想象中那么吃硬件，但也不能太寒酸。如果你只是跑一个7B到8B量级的量化模型，内存16G是可以实现的，但会比较紧张；如果想要流畅对话并且同时跑Openclaw这个框架本身，最好是24G内存起步。CPU推理的话，过程会慢一些，但也不是不能用，我最初就是在一台只有CPU的旧服务器上调试的，单个指令大约几秒到十几秒，可以接受。

如果手上有NVIDIA显卡，那体验会好非常多。只需要在Docker里配置好GPU运行时，模型推理的响应时间可以由十几秒压到一两秒。其他品牌的显卡也能跑，但配置成本会高一些，建议新手先从CPU方案起步，跑通整个链路之后再考虑加速。

磁盘空间方面，一个中等大小的模型权重文件在4G到8G之间，加上镜像和日志，预留20G到30G比较稳妥。

2.2 两个容器还是一条龙，怎么设计网络

方案里最核心的一个设计决策是：模型服务和Openclaw服务到底要放在同一个容器里，还是分开跑。我的建议是分开跑。

原因有两点：一是模型服务通常需要一个长时间运行的进程，占用大量内存，如果跟Openclaw的进程挤在一个容器里，一个崩溃没准会带崩另一个；二是分开之后，模型服务可以被独立复用到其他项目里，比如你以后写别的脚本也需要调用本地模型，直接把那个容器拉起来就能用。

网络方面，最简单的做法是两个容器都接入同一个自定义bridge网络，这样Openclaw容器可以直接通过服务名访问模型服务，比如llm:11434，不需要关心IP地址变化。如果你想把模型服务跑在宿主机上，只用Docker跑Openclaw，那也可以，但需要在容器里通过host.docker.internal这个特殊域名来访问宿主机。

2.3 哪些数据必须持久化，哪些无所谓

容器最大的风险是：它本身是“临时”的。你随手删掉一个容器，里面所有未持久化的数据都会消失。所以务必提前想好哪些数据需要“活下来”。

必须持久化的东西有三类：一是Openclaw自己的配置文件和会话记录，否则每次重启容器都会失忆；二是模型权重的下载路径，这不是说不能重下，而是没有必要反复下载一个好几个G的文件；三是Agent执行过程中产生的临时文件、知识库索引、向量数据，这些是你可以长期积累的资产。

不需要持久化的是那些运行时临时文件，比如进程缓存、临时日志。这些放在容器内部即可，容器重建时会自动清掉，反而省得你定期清理。

2.4 模型缩放的取舍：不是越大越好

很多新手容易走进一个误区：模型能力越强越好，最好直接上70B。但你要知道，你的Agent是24小时待命的，不是偶尔跑一个脚本。模型越大，内存占得越多，推理越慢，最后很可能变成“喂一次食要等半天”，体验非常差。

基于个人体会，建议先从一个7B到8B的量化模型开始。这个级别的模型在大多数日常任务上表现已经够用，比如文本分类、JSON提取、简单规划、调用工具时解析参数。等你把整套链路跑顺了，再根据自己的空闲内存决定要不要升级到13B级别。很多任务其实不依赖模型的“知识量”，依赖的是框架的工具调用设计，模型太大反而增加延迟。

3. 实操过程：从零拉起你的专属龙虾缸

3.1 先规划好目录结构

不要一上来就写配置文件，先规划目录。我的习惯是创建一个专用目录，比如在~/opclaw下面分三个子目录：

• models：模型权重文件放这里，模型服务容器只读挂载这个目录。
• data：Openclaw的配置与会话数据存这里，方便备份和迁移。
• runtime：Agent运行时产生的临时输出、日志、任务文件。

这个结构的意义是让“哪些东西重要”一眼就能看出来。data和models只要在，这个方案就还在；runtime丢了也无所谓。将来做备份，直接打包这两个目录就行。

3.2 先把本地模型服务弄醒

模型服务是整个系统的发动机，没有它Openclaw就是一副空壳。先用一个本地推理运行时把模型拉起，通常这类运行时都提供了兼容OpenAI格式的API接口，这样Openclaw只需要把请求发到一个通用地址即可。

启动模型服务后，先别急着接Openclaw，用一条简单的curl命令确认模型能正常响：

curl -s http://localhost:11434/v1/models

如果返回了模型列表，说明服务正常运行。再发一条对话请求试试：

curl -s http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "your-model-name", "messages": [{"role": "user", "content": "你好"}]}'

看到正常返回内容之后，这个环节就算通过了。经常有人在这里卡住，因为模型服务虽然在跑，但端口被防火墙拦了，或者HOST配成了127.0.0.1导致其他容器访问不了。标准做法是将模型服务的监听地址设置为0.0.0.0，端口随意，但别跟Openclaw的端口冲突。

3.3 写一份docker-compose配置

这是最核心的一步。我倾向于用Docker Compose来管理，因为它能把两个容器的启动顺序、网络、挂载、环境变量全写在一个文件里，以后想重建整个环境，一条命令就够。

参考配置如下：

services: llm: image: your-llm-runtime:latest container_name: opclaw-llm volumes: - ./models:/models:ro environment: - HOST=0.0.0.0 - PORT=11434 - MODEL_PATH=/models/your-model.gguf ports: - "11434:11434" restart: unless-stopped app: image: openclaw/openclaw:stable container_name: opclaw-app depends_on: - llm volumes: - ./data:/data - ./runtime:/runtime environment: - OPENCLAW_API_BASE=http://llm:11434/v1 - OPENCLAW_MODEL=your-model-name - OPENCLAW_DEBUG=false ports: - "8800:8800" restart: unless-stopped

几个关键点解释一下。llm服务里我把models目录以只读方式挂载进去，只读这个约束能防止模型服务在运行中意外改动权重文件。app服务里设置了depends_on，但它只能保证依赖服务“启动过”，不能保证“已经就绪”，所以启动后如果发现连接失败，最直接的办法是手动查看日志，或者加一个健康检查脚本。

OPENCLAW_API_BASE使用的是http://llm:11434/v1，这里llm就是docker-compose里定义的另一个服务名。自定义bridge网络会自动做DNS解析，所以不需要写死IP地址。如果两个容器是分开用命令启动的，没进同一个网络，就得改成容器IP或者宿主机地址，很容易踩坑。

3.4 启动、看日志、喂第一句话

配置写好后，启动就很轻松了：

cd ~/opclaw docker compose up -d docker compose ps

第一次启动要拉镜像，可能要等几分钟。之后可以用docker compose logs -f观察输出。正常情况下，Openclaw的日志里会显示模型连接成功、Agent初始化完成之类的信息。

然后就可以测试对话了。Openclaw的默认API端口映射在8800，我习惯先用命令行验证：

curl -X POST http://localhost:8800/v1/chat \ -H "Content-Type: application/json" \ -d '{"message": "帮我看看当前系统磁盘使用率，并按占用从高到低列出前五个目录"}'

如果Agent正常理解并调用了工具，你会看到它执行了相应的命令并返回格式化结果。第一次能跑通这个流程时，那种感觉还挺奇妙的——你确实在跟一个“带着工具箱”的实习生对话。

3.5 接入工具与知识库，让龙虾会“夹菜”

对话跑通只是第一步，Openclaw的价值在于工具调用。常见的几个工具方向包括文件操作、命令执行、HTTP请求、数据库查询。拿文件操作来说，我把它配置成只能访问runtime目录，这样Agent在里面随便折腾都不会危及系统其他部分，这是最基础的权限隔离。

如果你的Agent需要特定领域的知识，比如你自己的笔记、某个项目的文档，可以考虑加一个知识库组件。基本思路是启动一个轻量级向量库容器，将文档目录挂载进去，启动时做索引，然后Openclaw在回答问题时先做检索，再把检索结果拼接进上下文。这个过程就是给龙虾“投喂饲料”，喂得好，它干活更准。

不过要提醒一句：知识库不是必须的。如果你的场景只是让Agent帮忙处理日常任务，那模型自身的知识已经足够；盲目加知识库会让整个架构多出好几个服务，排查问题时复杂度会高很多。

4. 常见问题与排查技巧实录

这套方案看起来简单，但真正跑起来时，十个问题里有八个都出在细节上。我把实际踩过比较有代表性的问题整理成了一张速查表，后面一个个说透。

4.1 一启动就崩，多半是模型服务没“真正”就绪

depends_on只控制容器启动顺序，不保证模型服务可以接受请求。所以新手经常遇到Openclaw起来后马上退出，日志里写连接被拒绝。这时候最快的排查方法不是去翻Openclaw配置，而是单独验证模型服务，直接在宿主机上curl模型API，如果能通，再确认容器之间的网络连通性。

4.2 模型大不大，直接决定体验爽不爽

我在实践中发现一个规律：模型心理上越大越稳，但实际用起来延迟影响很大。尤其是Agent需要多轮工具调用时，一次任务可能要来回调用三四次模型，每次都要几秒甚至几十秒的话，整个体验就很崩溃。与其上大模型，不如在提示词设计和工具设计上优化，把任务拆细，减少不必要的上下文。

如果你有NVIDIA显卡，记得在docker-compose里给模型服务加上deploy段的资源限制，或者使用独立的GPU runtime。没配置的话，Docker默认只用CPU，你会发现显存明明够用，但推理就是不走显卡，白白浪费了硬件。

4.3 端口冲突的问题，一次说清楚

11434和8800这两个端口我故意写得很常见，实际使用中非常容易撞车。如果你本机已经有别的服务占用其中任意一个，最简单的办法是只改宿主机侧映射，容器内部端口尽量不动。比如把openclaw端口映射成9900:8800，把模型端口映射成11435:11434，然后同步修改Openclaw的API_BASE地址。

另外提醒一下：如果开了防火墙，除了容器内部端口之外，还要放行宿主机映射出去的端口，不然外部访问不到。

4.4 持久化目录权限太紧，也会让你“进不去”

有时候你发现容器启动后，写入./data目录时报权限拒绝。这多半是因为宿主机目录的属主跟容器内进程的属主不一致。处理方式不复杂：进到目录里，把属主调成容器内运行用户的UID，或者给目录设置更宽容的权限。这种事很小，但会浪费不少时间，提前注意一下比较好。

4.5 上下文过长导致废回答

本地模型受限于KV Cache，上下文越长，推理越慢，还可能“遗忘”最开始的内容。如果你发现Agent做着做着开始答非所问，多半是上下文窗口被你塞爆了。Openclaw通常有上下文压缩或者截断的机制，但保底做法是设定一个最大上下文长度，超过的部分做摘要压缩。日常任务里不要一股脑往上下文里堆日志，该清理就清理。

5. 我的实际体验与后续扩展

整套方案跑通之后，我最大的感受是：拥有一个“完全属于自己”的Agent，和用别人的API，心态上是完全不同的。因为不必担心有一天服务涨价、接口变动或数据泄露，这只龙虾养熟了就是你的，越用越了解你的习惯。刚开始调试的时候确实会有点手忙脚乱，但只要把Docker这只“水缸”里的逻辑理顺，后面就很稳。

后续我还想做的扩展有三个方向：一是把知识库从简单的向量检索升级成自动更新，让它能持续学习新文档；二是接入更多工具，比如让它直接帮我操作一些测试环境，充当自动化助手；三是把整个方案接上定时任务，让“龙虾”每天固定时间主动汇报服务器状态，而不是等我开口问。这些方向其实都不需要推翻现有架构，在Docker外面再加一个定时触发器就行。

最后分享一个小技巧：所有环境变量尽量都写进docker-compose文件里，同时准备一份.env.example模板放同一目录，后面换机器部署时，复制改一个文件就搞定。我真切体会到，这套方案的健壮性不是靠某个天才配置，而是靠一开始把每条数据流向都理清楚。好好照顾你的龙虾，它会给你回报的。