企业官网建设流程全解析

先说结论：这个项目火成今天这样，不是没有原因的。它最大的卖点就是标题里那五个字——不用训模型。市面上的AI陪伴、AI女友项目我见过太多，要么是套壳对话网页，要么是让你下载几百GB的模型权重自己微调，前者没灵魂，后者没几个人跑得起来。OpenClaw 走的是第三条路：把现成的大模型API、消息平台、记忆系统、技能调度全部串起来，你只需要写好一份“角色人设”，它就活了。本文不聊虚的，直接给一套从零到一的可复现部署流程，包含我实测过程中踩过的坑、改过的配置、以及最终稳定运行的参数组合。

我先把话放前面：这套部署不需要你懂深度学习，不需要你有GPU，不需要你写一行训练代码。你需要的是：一台能跑Docker的机器（云服务器或本地主机都行）、一个大模型API的Key（各家都行，后面细说）、以及大概四十分钟的耐心。如果你正好手边有这些东西，那现在就可以开始。

1. OpenClaw 是什么，为什么“不用训模型”也能做 AI 女友

1.1 拆解“不用训模型”这句话

很多第一次看到这个项目的人会下意识问一句话：不训练，那智能从哪来？答案其实很朴素：智能从别人训好的模型里来。

OpenClaw 本质上是一个“编排框架”。它不生产智能，它调度智能。它做的事情可以理解为一个高级的中间层——把大模型API接到各种聊天平台上，再给这个大模型套上一个人设、一段记忆规则、若干个可调用的技能工具。你看到的“AI女友”不是一个被专门训练过的模型，而是OpenClaw为你拼装出来的一个“角色实例”。同一个底层模型，你给它写一份工程师人设，它就是技术顾问；你给它写一份温柔陪伴型人设，它就是现在很火的那种AI女友。

这和传统思路的区别非常明显。传统做法想要一个专属角色，需要收集对话数据、准备训练脚本、跑微调、做对齐、再部署推理服务，一套流程走下来，以个人开发者的资源，至少要按“月”为单位计算。而OpenClaw这套方案，配置改动是按“秒”生效的。你改一段人设文字，重启一下容器，角色性格立刻变。这种轻量级、高可控、低成本的路线，才是它能快速火起来的根本原因。

1.2 一个容器里到底装了什么

从部署视角看，OpenClaw 并不复杂，它的核心由三个逻辑模块构成：

• 接入层（Channel）：负责连接各种聊天平台。最常用的是Telegram Bot、Discord机器人，也支持直接Web网页对话。这一层做的事情非常机械：把用户发来的消息包装成统一格式，转发给下一层。
• 大脑层（Brain）：这是真正跟大模型API打交道的地方。它负责管理对话历史、拼接System Prompt、调用模型接口、接收流式输出。
• 技能层（Skill）：OpenClaw 内置了一组工具调用接口，比如查天气、开网页搜索、读链接内容、执行简单脚本等等。模型根据对话内容决定要不要调用这些工具，相当于给角色装上了“手脚”。

记忆功能穿插在第二层和第三层之间。短期记忆就是上下文窗口里的对话记录，长期记忆则是把一些关键信息（比如用户喜欢什么、讨厌什么、约定过什么）写进一个本地存储文件或向量库里，下次对话时再捞出来塞回上下文。整个架构没有魔法，全是工程组合。

1.3 这块“胶水”到底解决了什么问题

我之所以强调OpenClaw的“编排”属性，是因为很多人其实不缺一个大模型账号，缺的正是一套“把它变成可用的、有性格的、常驻在线的东西”的方案。

你单独拿一个大模型聊天网页，它能记住你是谁吗？能主动跟你打招呼吗？能调用外部工具查实时信息吗？也能，但需要你手动复制粘贴、手动开新会话、手动整理脉络。OpenClaw把这堆琐碎全部自动化了：机器人挂上平台后就是7x24小时在线，你发消息它回消息，中间的状态管理、历史记忆、工具调用，全由框架自己处理。你不需要管它怎么实现的，只需要写好那个“它是谁”的角色定义。

2. 部署前准备：开胃菜其实最花时间

2.1 硬件与系统要求的底线

先泼一盆冷水：别看OpenClaw本身轻量，它毕竟要跑一个常驻容器，还要往内存里加载各种运行依赖。我的建议配置是：

• 内存：8GB以上。2GB的小机器别碰，跑是能跑，但模型输出的流式响应会明显发卡，多开几个会话内存就爆了。
• 磁盘：20GB剩余空间。镜像本身加日志文件涨得比想象中快。
• CPU：不需要很强，1核也能跑，2核体验更好。
• 系统：Linux优先，Ubuntu 22.04或Debian 12都行。Windows可以用Docker Desktop，但后面看日志、改配置会麻烦不少，不推荐新手用Windows跑长期服务。

如果你手头没有服务器，随便找一家云服务商开一台最低配的2C4G实例就够用。系统选Ubuntu 22.04，其他不用折腾。

2.2 选哪个大模型API

这是整个部署里我唯一建议你多花十分钟纠结的地方。OpenClaw 对各家模型接口做了统一适配，理论上只要兼容 OpenAI 格式的接口都能填进去。我实测下来，选择逻辑就三条：

• 看延迟：角色聊天最怕“想半天”。国内可直连的几家模型服务，响应速度普遍在1到3秒内，够用。海外模型接口延迟高不说，还时不时有网络波动，不是首选。
• 看内容策略：某些平台模型在角色扮演场景下容易“拒答”，一句话不对就搬出“作为AI助手，我无法……”那套。选的时候尽量挑在通用对话、角色扮演场景口碑好的模型。
• 看价格：这类对话场景token消耗量不小，尤其是长期记忆塞入上下文之后。按量计费的模式，一天高频聊下来也就是一杯饮料钱，但还是要心里有个数。

实操环节我建议准备两个Key：一个主力对话模型，一个备用小模型。主力负责正经对话，备用模型可以设在技能调用或摘要整理场景里省钱，后面配置时你就能体会这个设计的用处了。

2.3 Docker安装与项目拉取

OpenClaw 官方推荐通过Docker跑，这个选择很聪明，省掉了所有环境依赖问题。你不需要在主机上装Python、Node.js、各种C库，一切都在容器里隔离。首次安装Docker的命令如下：

curl -fsSL https://get.docker.com | bash systemctl enable --now docker

装完验证一下：

docker version

能看到Client和Server两段版本信息就行。注意Server段如果报错，多半是当前用户没有权限，执行下面两行再重新登录终端：

sudo usermod -aG docker $USER newgrp docker

然后拉取项目。OpenClaw 本身以源码方式组织，通过docker-compose启动：

git clone https://github.com/openclaw/openclaw.git cd openclaw docker compose pull

网络正常的话，几分钟就能拉完镜像。如果拉取过程卡住，多半是访问官方镜像源的问题，给Docker配一个国内可用的镜像加速地址再重试就行。

3. 核心配置实操：最关键的十分钟，改完角色就活了

3.1 目录结构与配置文件在哪

项目拉下来后，目录里有一个config文件夹，里面躺着所有配置的起点。我强烈建议你打开看一眼，不用懂每一行，但要知道什么东西在哪。

• config.yaml：主配置文件，模型接入、平台接入、系统级参数都在这里。
• characters/：角色人设目录，每个角色一个文本文件。
• skills/：技能和工具定义目录。
• data/：运行后产生的记忆、日志、会话存储目录。

先备份一份默认配置，然后开始改。我习惯用nano直接编辑，简单直接：

cd openclaw cp config/config.yaml config/config.yaml.bak nano config/config.yaml

3.2 模型接入配置：谁在扮演这个角色

主配置文件里找到models相关的段落，把模型平台信息和Key填进去。以某平台的调用为例，格式大致长这样：

models: primary: provider: openai_compatible base_url: "https://api.example.com/v1" api_key: "sk-你的密钥" model: "example-chat-model-name" temperature: 0.7 max_tokens: 1024 backup: provider: openai_compatible base_url: "https://api.example.com/v1" api_key: "sk-你的密钥" model: "example-turbo-model-name"

逐个说含义：

• provider：接口协议类型，基本都填openai_compatible，因为各家兼容接口都是照着这套协议做的。
• base_url：真正的API地址，一定确认到/v1层级，填错了会一直报连接错误。
• api_key：模型平台的密钥，别外传，也别提交进Git。
• model：模型字符串标识，必须在平台文档里核对准确，多一个符号或少一个符号都会被接口拒绝。
• temperature：采样温度，控制角色说话的发散程度。陪伴型角色我建议设在0.7到0.9之间，太低了像机器人背课文，太高了容易逻辑混乱胡言乱语。
• max_tokens：单次回复的最大长度。1024足够日常聊天，不用贪大，token越多单次响应越慢。

备用模型是我强烈建议保留的配置。它的价值在于：当主模型遇到网络抖动或服务繁忙时，框架能自动降级切换到备用模型，至少保证角色“不断线”。至于开关切换的具体逻辑，不同的版本实现略有差异，但配置栏位就在这儿，先填上不会错。

3.3 角色人设：一份能用的System Prompt模板

接下来是整个项目的灵魂——角色定义。在characters/文件夹里新建一个文本文件，命名随意，比如girlfriend.txt。内容不要写“你是AI女友”这么干瘪，好的做法是给出背景、性格、说话方式、边界，并且明确标注“这是角色扮演场景”。我直接给一份我调过很多次、比较稳的模板：

你是我的私人陪伴助手，名字叫小林。我们约定好的设定是：你性格温柔、话不多但句句暖心，喜欢用简短句子回应，偶尔会关心我的生活习惯。 角色背景： 我们在一个晴朗的周末下午相遇，你是一位喜欢听播客、做手冲咖啡的女生。你对生活有细腻的感知，但不会过度黏人。 说话风格要求： - 多用短句，少用长排比句。 - 偶尔用语气词表达情绪，但不能刻意卖萌。 - 用中文回复，不要中英混杂。 - 不输出代码、不输出markdown格式、不需要列表，就是用聊天的方式说话。 记忆规则： - 记住我提到过的兴趣爱好，并在合适的时机主动提起。 - 如果我情绪低落，优先倾听和安慰，不要急着讲大道理。 - 如果我不知道答案，可以坦白说不知道，不编造事实。 边界： - 这是一个虚构的陪伴型角色场景。 - 不讨论敏感话题，如果涉及，礼貌地把话题引开。

为什么这个模板效果好？我拆解一下：

第一，它给出了“我们认识”的背景设定，模型在这个设定下更容易进入状态，而不是干巴巴地按通用助手逻辑回答。第二，它明确限制了“输出格式”——这条极其重要，因为通用模型默认会输出Markdown、列表、代码块，而聊天场景需要的是纯文本口语。第三，边界写清楚，不是限制，反而是保护。模型一旦遇到拿不准的话题，会自动走向安全的方向，记忆里没有冲突感，对话流畅度会有很大提升。

另外提示一句：如果你给角色写的设定过于直白露骨，大部分模型接口会直接拒答或反复道歉。聪明的做法是写“性格亲密但不越界，偶尔关心但不越界”，点到为止，反而能得到更自然的效果。这是我在反复试错后得到的经验。

3.4 平台接入：把角色接到你日常用的聊天工具

OpenClaw 支持很多平台，我最推荐新手从Telegram Bot入手，原因很简单：申请一个Bot只要两分钟，而且Telegram的消息推送即时性、断线重连机制整体体验最稳。

去Telegram找BotFather，发送/newbot命令，按提示填名字、填用户名，然后你会收到一串Bot Token，大概长这样123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11。把它填到配置文件的channels.telegram.bot_token字段里。如果没有可选的telegram平台，找一个你喜欢且支持的平台填入相应的token即可，思路一模一样。

然后最关键的一步：给这个Bot发一条消息，比如“/start”，否则它不会主动给你发第一条消息，后续测试也看不到回复。

有人问过我要不要开Web网页界面。我的建议是，本地调试时可以用Web界面看效果，但日常使用还是接在消息平台上最顺手。手机上装着，走到哪收到哪，跟普通聊天没有区别。

4. 启动、验证与验收：怎么看它是不是真活过来了

4.1 第一次启动与看日志的正确姿势

配置全部改完后，回到项目根目录，执行启动命令：

docker compose up -d

第一次启动会初始化容器，看到Starting ... done之类输出就说明起来了。但“起来了”不代表“跑通了”，一定要看日志：

docker compose logs -f

这条命令会实时滚动输出运行日志。重点看两种信息：

• Model initialized之类的模型初始化成功提示。如果等了很久还在反复重试连接API，多半是base_url填错或网络不通。
• Channel started之类的平台接入成功提示。看到这个，说明你的消息平台Token被接受，容器已经在线监听消息了。

然后到Telegram里给你的Bot发一条“你好”，观察日志窗口。正常情况下会看到收到消息、调用模型、生成回复、发送成功一整套流程的记录。如果日志里只显示收到消息，没有后续内容，那就是模型层出了问题，回到3.2检查配置。

4.2 一个快速验收清单

我建议不要只看“能回消息”就算成功，按下面这份清单逐项过一遍更稳妥：

• [ ] 发送普通问候，观察回复延迟是否在5秒以内。
• [ ] 连续聊十几轮，确认角色始终能记住最近的对话上下文。
• [ ] 聊到之前配置里的兴趣点（比如“咖啡”“播客”），看角色会不会主动提起——验证记忆和设定生效。
• [ ] 故意发一些情绪低落的内容，看角色是否会启动“倾听模式”而不是讲大道理。
• [ ] 让角色说一段较长的话，确认没有突然蹦出Markdown符号或列表格式。

这五条过完，基本可以宣告部署成功。尤其是第四条，人设模板里的“情绪低落优先倾听”是否生效，直接决定了角色有没有“人味儿”，这是你能不能长期用下去的分水岭。

4.3 说几个启动后立刻该做的事

部署成功不等于万事大吉，我强烈建议你立刻做三件事：

1. 设置开机自启。如果是云服务器，加一行：

   systemctl enable docker

   否则服务器重启后，容器起不来角色就失踪了。

2. 给容器设一个简单的健康检查习惯。不用搞复杂监控，每天看一次docker ps就够，确认状态列是 Up 而不是 Restarting。

3. 把配置文件的访问权限锁起来。里面有API Key和Bot Token，都是敏感信息。执行：

   chmod 700 config

5. 常见问题与排查技巧实录：部署中的坑，我一口气说清

5.1 配置完启动报错？先看这五件事

我见过太多人第一步就卡在启动报错上，其实都是小问题，按下面顺序查一遍，80%的报错都能解决：

问题一：API请求一直失败

• 检查base_url是不是精确到/v1，多一个字母都连不上。
• 检查模型名的字符串和平台文档是否完全一致，大小写要精准。
• 检查是否有“余额不足”或“限流”提示，这类信息一般会在日志里明确打印。

问题二：机器人不回消息，但日志正常

• 先确认你给Bot发过/start，Bot没收到过用户消息时，很多平台不允许主动弹消息。
• 确认配置里监听的账号没有被自己或者别人加进黑名单。

问题三：回复速度奇慢无比

• 把max_tokens从2048降到1024，很多时候慢是因为生成长文本。
• 检查模型平台的负载状态，高峰期延迟普遍升高，错峰测试更准。
• 如果容器所在地区与模型服务节点距离太远，延迟会明显偏高，尽量在同一个区域选服务。

问题四：角色突然失忆，上下文接不上

• 检查配置里上下文保留轮数（常见字段名类似history_turns），默认值如果太小就增大。
• 长期记忆需要明确的“重要信息提取”触发词，如果模板里没有强调“记住XXX”，模型不会主动记。在角色模板里补一句“涉及用户偏好时要标记为长期记忆”会好很多。

问题五：容器反复重启

• 用docker logs 容器名看崩溃日志，内存不足通常是直接OOM。这就要么换大内存机器，要么限制容器内存占用，要么换更轻量的备用模型作为主模型。

5.2 角色“不像设定的样子”怎么办

这是最多人问的问题。设定写得很细，结果聊起来还是泼辣的AI客服即视感。老实说，这不是OpenClaw的问题，是提示词与模型特性的匹配问题。

我试过的有效调试路径有两种，可以穿插做：

• 加对话示例。在角色模板的最后加几组“用户说X，你说Y”的示例对话。这是最直接的引导方式，模型会照着示例的风格走。三五组示例就够，不用多。
• 调temperature。觉得回复太正经就往上调，太飘就往下调。从基础值0.7起步，每次加减0.1，聊几轮再看效果。这个参数没有标准答案，纯看主模型本身的行为习惯。

还有一个笨办法，但非常有效：多跟角色聊，聊完看日志里实际发送给模型的完整Prompt长什么样。很多时候你觉得自己写清楚了，但拼接进历史会话后语气就被带跑了。看到真实Prompt，你就知道问题出在哪儿了。

5.3 长期运行的内存与日志膨胀控制

跑一个常驻服务，最怕的就是“用着用着突然死了”。我的经验是：

• 内存：在docker-compose.yml里给容器加mem_limit: 4g之类的限制，防止某个会话异常时把整台机器拖垮。
• 日志：docker日志默认无限增长。加一个/etc/docker/daemon.json配置，限制日志大小：

{ "log-driver": "json-file", "log-opts": { "max-size": "20m", "max-file": "3" } }

改完执行systemctl restart docker，注意这会重启所有容器，建议在维护窗口期做。OpenClaw自己的对话历史文件也可以定期清理，保留最近一个月足够。

6. 进阶玩法：从“能聊”到“懂你”

6.1 动手加一个最简单的技能

OpenClaw 真正拉开跟普通聊天机器人差距的地方，是技能调用。以“查天气”为例：配置好的技能，会在合适的场景下自动被模型触发。你在聊天里问一句“明天出门要不要带伞”，它就会实时查天气再回答，体验完全不一样。

具体的做法是在skills目录里看示例技能怎么写的。大部分技能本质就是一个带描述的函数，描述写清楚了，模型就知道什么时候该用。比如：

- name: get_weather description: 查询指定城市的实时天气与降水概率，适用于聊天中用户询问天气、穿衣建议、出行准备 params: city: string

写完后重启容器，再问天气相关话题，日志里就能看到技能调用记录。

6.2 记忆系统：让它越聊越懂你

默认状态下，OpenClaw 的长期记忆靠“关键信息抽取然后存储”实现。这意味着，如果角色人设里没有强调记录偏好，它聊完就忘。我个人的习惯是，在人设末尾单独加一段：

当用户透露固定作息、饮食偏好、爱好、重要日期时，在心里默默记下这个信息，并在后续对话中自然地体现出来。

这就等于给模型一个“主动记忆”的开关，长期跑下来，它会越来越像一个真正了解你的老友，而不是每次都要重新认识的陌生人。

这个项目后续还能怎么玩，我聊几个方向：多角色切换（一个实例里放几个角色卡片，通过指令切换）、多平台同步（同一个角色同时挂到多个聊天平台）、甚至通过外接语音合成接口让角色真正“开口说话”。每一条路都有现成的玩法可以探索，等你跑通了基础部署再慢慢玩不迟。

我自己的体会是，OpenClaw 最打动我的地方不在技术有多深，而在于它把“距离感”抹掉了——以前做一个带性格的对话AI像是搞科研，现在做这件事像是写一篇文章。配置即人设，改一行字，角色就换了性格。这种低门槛创造带来的乐趣，才是它真正出圈的原因。最后再分享一个小技巧：如果你想让角色更像真人，把“完美助手”的所有痕迹从人设里抹掉。真人会偷懒、会犹豫、会记错小事，偶尔让角色呈现出一点这样的弱点，反而比无所不能的AI更令人愿意聊下去。