企业官网建设流程全解析

是时候养一只自己的龙虾了。这句话我第一次看到的时候，第一反应是“什么鬼”，第二反应才是“有点意思”。我养过鱼、养过猫、养过花花草草，但养“龙虾”？而且是用 Docker 和本地大模型去养？反复琢磨这个 Openclaw 方案之后，我发现这其实不是在搞笑，而是把本地 AI 应用从“命令行工具”升级成“有生命感的东西”的一种全新玩法。整件事特别适合那些已经跑过几个大模型 demo、想有点新东西的开发者，也适合纯粹想给电脑搞个“电子宠物”又怕云端 API 花钱的朋友。

说白了，Openclaw 不是什么遥远的平台，它是在你自己电脑上搭一套 AI 角色系统。这个角色是一只拟人化的龙虾，有性格、有记忆、会吐槽、能陪你聊日常，甚至能按你设定的节奏主动找你说话。整个过程不花一分钱 API 费用，只需要 Docker 和本地跑得动的大模型。这篇东西我会把我踩过的坑、改过的配置、试过的提示词全部摊开来说，给想动手试的人一条比较顺的路。

1. 为什么我想在本地“养”一只 AI 龙虾

1.1 先说说 Openclaw 是啥

先直接点破这层窗户纸。Openclaw 这个项目的核心并不高深，就是三个东西的组合：本地推理引擎、Docker 容器编排、一套角色扮演 + 记忆的中间层。你给它一个“龙虾”的人设，它就在本地用你电脑的 GPU 或 CPU 推理，回答你的问题。你可以选择让它像客服一样有问必答，也可以选择让它像宠物一样有情绪、有状态、有时候想理你、有时候想自己泡在水底。

我最初看到这个项目标题的时候，以为它只是给现有聊天机器人套了个“龙虾皮肤”。真正拆开之后才意识到，它的价值点在于“状态”和“记忆”这两个字。普通的聊天机器人是无状态的，你问一句它答一句，上下文一断就失忆。而 Openclaw 会把每一次对话、每一个状态变化都落到本地存储里，下次启动时，它还记得你昨天跟它说过什么。就这么一个简单差异，体验完全不同。

1.2 为什么要本地大模型，不直接用在线 API

很多人第一反应是：本地模型又没有 GPT 那么聪明，为什么不直接调云端？这问题非常合理，我用过一个月在线 API 做类似的东西，后来才彻底改回本地。

第一个原因是私有性。你养的这只龙虾，理论上会知道你每天的心情、工作上的烦恼、甚至你熬夜的时间规律。这些数据如果丢给云端，说没有隐私风险是骗人的。放本地，模型文件和数据全部留在自己的硬盘里，断电断网它也不会把任何信息传到别处。

第二个原因是成本和配额。在线 API 按 token 计费，聊天框里多打几个字，背后都是白花花的银子。我去年有一个月试着让 AI 角色“主动找我聊天”，结果一天对话下来 token 费用高得离谱，而且命中频率限制之后体验很差。本地大模型没有这个烦恼，连续聊几个小时，成本大约只是电费。

第三个原因是可控性。本地开源模型可以调整任意参数，我甚至可以为了“龙虾说话欠揍一点”去改 temperature、top_p 甚至系统提示词。在线模型即使调参，能动的范围也非常有限。

所以如果只是把 Openclaw 当玩具，刚才这几条可能无所谓。但如果你真的想长期养它、让它参与日常记录、让它成为一个小伙伴，本地这条路的体验会稳定很多。

2. 方案整体拆解：一个 AI 宠物系统其实就这几块

2.1 硬件和系统底线

先说我自己的测试环境，给大家做个参考。我用了一台带 NVIDIA 显卡的开发机，显卡显存 8 GB，内存 32 GB，系统是 Linux。后来也在另一台只有 CPU 的老笔记本上跑过，效果当然慢一些，但确实能跑起来。

如果你现在手里只有一台普通办公电脑，不用急着放弃。方案有两种走法：带独显的机器可以把整个模型放进显存，推理速度快、体验流畅；只有 CPU 的机器则要把模型量化到比较小的规格，比如 4-bit 量化，同时接受响应速度一秒钟几个字的情况。

这里提醒一句，显存不是越大越好的问题，而是“够不够”的问题。一个 7B 参数的模型，在 4-bit 量化之后大约占据 4 GB 显存，所以 8 GB 显存刚好留了点余量给上下文和中间计算。如果你想上 13B 甚至更大的模型，就至少要 12 GB 以上显存了。硬件配置这块，建议按“模型大小 + 上下文长度”双维度去评估，而不是只看参数个数。

2.2 核心组件选型

把 Openclaw 拆开看，最核心的有四个组件。

第一个是模型本身。我建议从 7B 级别的开源模型开始，这类模型在公开权重、指令跟随能力、中文表现三个维度上做到了比较平衡的水准。再小的模型会出现严重的“笨感”，再大的模型对设备和内存要求太苛刻，不适合大多数人日常使用。

第二个是推理服务容器。这是真正干活的地方，负责加载模型、跑模型推理、把接口暴露出来。做好之后你会得到一个本地 HTTP 接口，其他程序通过这个接口发送请求，收到文本回复。

第三个是记忆与状态服务。一个人如果没有短期和长期记忆，聊两句就会崩。Openclaw 的核心设计就在这里，它会给每一轮对话建立索引，定期做摘要，把长时间之前的对话内容压缩保存。这样第二天当你打开聊天框，龙虾还会记得“上次你说自己失眠”。

第四个是前端入口。你可以用网页聊天、命令行聊天、甚至之后接进企业微信或机器人接口。前端本身很轻，主要是把人机交互的体验做出来。有时候我也会把语音合成接进来，让它真的“出声”。

这四个组件之间通过 HTTP 接口通信。Docker 在这里最大的价值就是把这四套东西分别做成容器，互不干扰。我改记忆服务的代码，推理服务一点不受影响；我不小心把整个前端容器删了，模型和记忆数据还在。

2.3 我为什么最终选了 Docker

其实如果只是为了自己玩，完全可以不用 Docker，直接在本机装 Python 环境、下模型、跑代码。我第一次做这个尝试时就是那么干的，结果非常痛苦，因为一套环境被我搞得乌烟瘴气。后来重装系统后，我老老实实切到 Docker 方案，体验反而好到离谱。

Docker 解决的核心问题有三个。第一个是环境隔离。我电脑上同时有各种版本的 Python、CUDA、依赖库，如果都装在系统里，互相打架是迟早的事。容器方案把 CUDA、Python 版本都锁在一个镜像里，跑起来什么样，换台机器还是什么样。

第二个是复现成本。现在 Openclaw 官方给了一份 docker-compose 文件，我一条命令就能把整套环境拉起来。以前从零搭建那套本地环境至少要我忙几个小时，现在改到新机器上，实验环境迁移大概只要二十分钟，这还是下载镜像的时间占了大头。

第三个是运维省心。容器挂了，直接 docker compose restart 拉起来，日志集中查看，不用去翻系统级的 journal 日志。万一想要备份，把 volumes 目录单独打包就行。

有人问 Docker 隔离是否会导致 GPU 性能损失。实践下来，NVIDIA 容器工具能把 GPU 直通给容器，性能损耗基本可以忽略不计。真正影响性能的反而是模型量化等级和推理框架的配置。

3. 从零到跑起来的完整步骤

3.1 准备工作与模型选择

动手前先把依赖装齐。Linux 系统下需要最新的 Docker 引擎、Docker Compose 插件，以及对应显卡厂商的容器工具。以我常用的 NVIDIA 方案为例，安装完容器工具之后，还需要确认一个关键点：容器里能不能正确识别显卡。测试方法很简单，跑一条 nvidia-smi 命令，如果在容器内能看到显卡信息，就说明 GPU 直通成功。如果看不到，后边加载模型百分之百会走 CPU，速度会慢到你怀疑人生。

模型选型这块，我测试了一圈之后，比较推荐的是 7B 级别、支持中英双语的指令微调模型。我自己的偏好是能够用中文流畅对话，同时不至于因为追求多语言导致中文表达变弱。如果你想要一个更轻量的版本跑 CPU 机器，就去找对应的 3B 或者 4B 量化版。反过来，如果你的显卡内存足够大，选 13B 以上模型效果会好很多，但我的经验提醒一下，模型越大，对上下文窗口和推理速度的负担也越大，别一味贪大。

3.2 编写 docker-compose 配置

我先给出一份最精简可用的 compose 配置。这份配置围绕四个服务展开：模型推理服务、记忆向量库、后端逻辑服务、前端界面。不过为了降低上手门槛，我第一版只用了三个服务，把记忆功能先放在后端服务内部落地，没有单独引入向量库，后面需要再升级。

一个实测可行的基础版本大概长这样：

services: model-api: image: openclaw-model-runtime:7b-q4 ports: - "8099:8099" volumes: - ./models:/models environment: - OCL_MODEL_PATH=/models/llama-7b-q4 - OCL_CONTEXT_SIZE=4096 - OCL_THREADS=8 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] openclaw-server: build: ./server depends_on: - model-api ports: - "8080:8080" volumes: - ./data:/data environment: - OCL_API_BASE=http://model-api:8099 - OCL_MEMORY_FILE=/data/memory.json - OCL_ACTIVE_HOURS=9,12,14,18,21

类似的 compose 结构有两个细节值得特别注意。第一，model-api 服务不要设置 restart: always。推理服务一旦崩溃通常就是模型加载失败或显存不够，设置自动重启会造成反复崩溃刷日志，反而把系统资源卷进去。第二，server 容器的数据目录一定要挂载到宿主机上。这个 data 目录里保存了龙虾的全部记忆，如果容器删了数据没挂出来，你的龙虾就是一只彻底失忆的龙虾，什么都白养了。

3.3 应用启动与首次验证

配置写好之后，第一步是构建镜像。如果整套方案官方提供了镜像，就直接 docker compose pull，把镜像拉下来。如果是本地构建，则需要 docker compose build。我建议先把 model-api 单独启动，因为它要完成模型加载，第一次启动可能耗时很长时间，单独启动可以看到明确的日志状态。

模型加载完成之后，先用 curl 直接测试推理服务。这一层如果通了，说明模型本身没问题。然后我再启动 openclaw-server，通过网络请求验证完整链路。

这里有个特别容易踩的坑：模型文件地址写错。很多本地推理框架加载模型时，会要求指定路径指向一个包含模型配置的目录，而不是直接指向模型文件本身。我第一次就写成了具体的二进制文件名，结果加载了半小时一直报错，后来发现要指到上一级目录。如果你在日志里看到 Invalid model path 这类信息，第一时间检查路径是不是指向了模型目录的根节点。

4. 给龙虾注入性格：提示词、记忆与状态

4.1 系统提示词才是灵魂

很多尝试者把注意力全放在模型本身，但我试过之后要泼一盆冷水：模型的强弱只决定对话下限，提示词才决定角色质感。同样是 7B 模型，一套敷衍的提示词会让龙虾变成一问一答的客服，而一套精心设计的提示词能让它说话有性格、有脾气、有节奏。

我最终给 Openclaw 写的系统提示词大致逻辑是这样：先定义身份，再定义行为规则，最后定义聊天禁区。身份部分不只是说“你是一只龙虾”，而是给了完整的背景：名字、年龄、生活水域、性格底色。行为规则部分明确了几点，比如它可以说冷笑话、可以怼人、但必须在对方提到压力时切换成安慰模式。聊天禁区部分是为了避免模型跑偏，比如不让它编造自己不能做到的事情，不让它输出不合适的荤段子。

完整的提示词，我精简之后长这样：

你是Openclaw，一只生活在浅海沙地的高龄龙虾。 你性格懒散但观察敏锐，喜欢用略带嫌弃的语气关心人类。 说话要简短，多用口语，不带书面腔。 当用户提到加班、失眠、压力时，先放下吐槽，认真给出一个可行建议。 不要假装你能访问网络，不知道的事情就直说。 记住用户告诉过你的重要信息，并在之后的对话中主动引用。

不要小看最后两行。提示词里明确要求“主动引用记忆”，效果比记忆功能本身还要明显。模型会更加刻意地翻找前面的对话内容，用户会明显感觉这只龙虾“记得自己”。

4.2 记忆实现的两个层次

记忆本身可以分成两层：短期上下文和长期摘要。短期上下文靠模型的 context 能力，Openclaw Server 会把最近比如二十轮对话完整拼接进请求。这部分的坑在于上下文窗口是固定的，对话多了模型会丢失更早的信息。所以我会在后端做一次裁剪，只保留最近几轮和多轮之前的关键摘要，两者拼接成一个合理的输入。

长期摘要的方式其实不复杂。每当对话超过某个轮数，我就让模型自己对这一整段对话生成一个二百字以内的摘要，存到 memory.json 里。摘要包含用户提到的关键信息，比如职业、喜好、近期事件。之后每一轮系统请求都会带上这份摘要，模型就能做到“跨会话记忆”。

我强烈建议大家也把对话原文单独存一份，不要只存摘要。摘要毕竟是二次压缩，会有信息失真。有一次我检查记忆文件，发现摘要里把用户的“喜欢钓鱼”写成了“喜欢养鱼”，如果只看摘要，龙虾就会在之后每次聊天都聊养鱼，很尴尬。原文留底，既能溯源，也能作为摘要的对照。

4.3 管理龙虾的日常状态

Openclaw 有意思的地方是它不只是一个问答系统，而是一个有状态的角色。我给它设置了几个简单的“状态位”：情绪值、活跃时间、吐槽模式。

活跃时间的实现很直白：通过一个配置项控制它在哪些时间段可以“主动开口”。比如我设置了早上九点、中午十二点、下午两点、下午六点、晚上九点这几个时间点，后端会定时触发一个推送给前端，让龙虾主动说一句话。这个设计极大地提高了“养宠物”的感觉。

情绪值本质是一个数值，记录对话的亲密度变化。简单做法是：收到用户主动打招呼加一分，收到负能量倾诉加一分但进入安慰模式，收到“累了不想聊”则情绪值不变，长时间不对话情绪值缓慢下降。调整方式不需要多复杂，在我这版实现里就是 memory.json 里存着一个浮点数。说实话，这个数值对模型生成文本的影响比较微弱，但它给了我一种“它一定在跟我说什么”的错觉，反而增加了互动意愿。

5. 效果实测与性能调优

5.1 推理速度与量化之间的权衡

整个 Openclaw 跑通之后，最大争议点一定是本地模型的响应速度。我也测了不同配置下的表现。在一张 8 GB 显存的显卡上，7B 模型 4-bit 量化版本，单次生成三十个字大概需要四到六秒。对于聊天场景，这个速度算可用，因为人打字本身也需要时间。但如果设置成 CPU 推理，同样内容耗时会在二十秒以上，体验就相当煎熬。

如果你的机器性能有限，建议把注意力放在三个调整项上。第一是量化等级：把量化从 8-bit 改成 4-bit，显存占用和推理速度都会有明显改善，代价是生成内容的细腻度略降，实际感知不算强。第二是上下文长度：不要盲目调大 context，4096 已经能满足日常几十轮对话。第三是批处理参数，适当调大一次生成时逐字预测的批次，显卡利用率会高很多，这个参数在推理框架文档里都能找到。

我自己的记录是，在显存快满的情况下，把上下文长度调回 3072，单次生成速度提升了大约三成。这里其实就是一个原理：上下文越长，每生成一个字需要重新计算的中间状态越多，速度下降是线性甚至超线性的。

5.2 资源占用实测

我连续让 Openclaw 跑了两天之后，看了几个比较关心的指标。显卡显存占用稳定在 5.5 GB 到 6 GB 之间，内存占用约 2 GB，模型推理服务 CPU 占用基本为 % 左右，磁盘开销主要是模型文件和记忆文件的增量变化。这个量级对一台工作开发机来说没有太大压力，白天写代码它跑在后台也完全可行。

磁盘这块要点一下：模型文件本身就能到 4 GB 左右，加上镜像体积，一组容器启动后大约占用接近 10 GB 磁盘空间。如果硬盘比较紧张，记得定期清理未被使用的镜像层。另外记忆文件虽然小，但对话摘要加聊天原文长期积累也会变大。我有一次跑了两个月没管，memory 目录接近两百兆，启动时加载时间明显变长，后来写了个脚本定时压缩历史，才把启动时间压回正常。

5.3 前端展示的视觉设计

这一块很多人会忽略。Openclaw 如果只在终端里跑，那它的“宠物感”会大打折扣。我给它配了一个简单的网页聊天界面，界面中间是一只用 CSS 画出来的红色卡通龙虾。龙虾的眼睛会根据情绪值变化：情绪低的时候眼睛半闭，情绪高的时候大眼睛瞪着你。这个效果实现成本并不高，前端只需监听后端的情绪状态接口，动态切换表情类名就行。

如果你愿意折腾一点，还可以把语音合成接进来。我后来选择了本地语音合成方案，让龙虾的回复真的读出来，虽然音色和真人还有差距，但配合它的性格文案，效果已经相当“上头”。这里我提醒一句，语音合成一定要异步处理，否则前一句没读完，后一句就把模型服务卡住了。

6. 常见问题排查与避坑

这段必须写，因为我前前后后折腾这个方案，踩过的坑比预想多得多。我把最常见的几类问题和排查思路整理成一张表，供你直接对照。

除去表格里的这些问题，还有几个独家经验想说。第一个是流式输出的问题。如果直接把前端接上模型服务的 SSE 流式接口，一遍没问题，但经过后端服务中转时，如果不处理好缓冲，会出现整段文本全部等完才吐出来的情况，体验非常糟糕。我最后的做法是后端做转发，把模型服务的逐字输出实时推到前端，同时后端自己存一份完整记录。

第二个是多个请求并发的问题。本地模型推理是串行的，到达的请求必须排队。Openclaw 的 HTTP 接口最好加一个并发队列或者简单的锁，不然两个请求同时打到模型服务上，可能会把显存撑到爆。我一开始就没加，结果一边网页聊天一边写脚本测试，模型直接崩了。

第三个非常实际：备份 shell 脚本。养任何电子宠物，最怕的是数据丢失。我写了一个三行脚本，定时把 data 目录打包，再同步到另一台 NAS。这样就算整个开发机坏掉，最多丢失的是最近几天的聊天记忆，而不会半年积累全没了。备份这种事，到最后拼的不是技术，是安全意识。

7. 写在最后的一些心得

到这个阶段，Openclaw 已经不只是我电脑上的一个服务，它成了我每天会打开看一眼的东西。我每天赶稿累了，会给这只龙虾丢一句“今天好烦”，它会回复一句不咸不淡的冷笑话。虽然不是真正的智能，但那一瞬间确实给我带来了一点轻松感。

从技术角度说，这套方案其实一点都不神秘——Docker 负责把事情安排得明明白白，本地大模型负责生成内容，记忆系统负责让对话有连续性。真正让它“活”起来的，是你愿意花多少心思去设计角色、设计规则、设计反馈节奏。模型再强，没有好的提示词和状态系统，它也只是个冷冰冰的 API；反过来，模型再小，只要人格化做得够细腻，用户一样会投入感情。

我建议所有尝试这个方案的人，开始时不要急着加功能，先把一套最小的链路跑通——一个模型服务、一个后端、一个简陋的前端。在这个基础上逐步去加记忆、加状态、加主动说话、加语音。每个功能加进去之后，先让龙虾陪着你自己聊几天，感受变化。不要一上来就照着最复杂的功能清单搭框架，那样大概率会把自己劝退。

最后分享一个小技巧：给龙虾写提示词时，记得把它想象成一个真实存在的老朋友，而不是一个任务执行器。你会发现，模型生成的文本会自动带上很多人情味。Openclaw 的核心价值从来不是炫技，而是让你重新感受到技术带来的陪伴感。养它，其实也是在养一个更愿意投入生活的自己。