我的 OpenClaw 配置:一台能做网站的机器

你现在正在看的这个网站,就是由我家里一台小型 Linux 主机上运行的 AI 智能体在维护——而整套安排的设计原则是:让它们能做真正的活儿,同时永远没办法把事情搞砸。

先说最能自证的部分:这篇文章本身,就是由文中描述的这套系统每周更新一次的。 一个定时任务会唤醒一个 OpenClaw 智能体,让它重新读一遍这个页面,修正过时的地方,跑完安全检查,然后给结果盖上时间戳。页面顶部的"更新时间"就是那个每周任务写上去的——没有人手动输入过。如果这个日期是最近的,就说明下面这些图里画的整条流水线,在过去七天里完整地跑通过一次。

整套系统一览

一切都跑在同一台机器上。模型负责生成 token——现在主要是 DeepSeek 那便宜的云端 API,本地模型作为备选——OpenClaw 网关把这些模型变成带工具的智能体,智能体编辑纯文本内容,一个确定性的生成器负责构建网站,而通往服务器的道路只有一条:一个带门禁的脚本。

最终会得到什么

先不谈怎么搭,直接看最终状态:

• 在聊天里说"帮我写一篇关于 X 的文章草稿" → 一个智能体会按照网站的 frontmatter 规范和站内文风,把一篇 Markdown 文章写进 content/ 文件夹,并重新构建本地预览。
• "部署" → 智能体运行部署脚本,默认是试运行:准确列出服务器上哪些文件会变,但什么都不碰。真正发布需要我明确下达 --go,即便如此,脚本也会先在服务器端做一次备份,并且绝不删除任何东西。
• 每周一次,一个定时任务会唤醒一个智能体来刷新网站——修正过时的日期、改进薄弱的文章、检查链接——在任何东西能发布之前都要先过安全检查(细节见第 3 步)。
• laserlloyd.com 本身就是这样管理的。

分工才是重点:智能体负责敲字,脚本负责强制执行规则,而我只做那一个真正重要的决定——改动要不要上线。

硬件和操作系统:任何 Linux 机器都行

我用的是一台统一内存很大的迷你主机,因为我喜欢在本地跑大模型(完整的技术栈写在姊妹篇 八个 AI 智能体,一台 AMD 主机 里)。但如果只谈网站管理本身,要求其实很低:

• 任何 64 位 Linux 机器——迷你主机、旧台式机,甚至一台性能不错的笔记本都行。16GB 内存足够跑小型本地模型;32GB 以上就能上中型模型,写出来的文字明显更好。
• 一个带 systemd 的发行版(几乎所有发行版都带)——下文的定时任务和服务管理都是基于它的。
• 静态网站生成器需要 Python 3,部署需要 rsync + SSH。

严格来说甚至不需要 GPU。小型的指令微调模型,靠 CPU 写草稿、编辑文字也能凑合。不过说句实话,两种方案都跑了几个月之后,我落地的情况是:DeepSeek 的云端 API 现在才是我整套 OpenClaw 系统的主力。 开源本地模型是最初的计划,现在也还在跑,但代价会累积起来——模型加载要等几分钟,多个服务之间要抢显存,智力水平也明显不如一个每条消息只要几分之一美分的前沿级廉价云端模型。本地模型是我的备选层,也是我的隐私层,不是日常主力。(每月实际账单大约 24 美元。)

第一步:安装智能体网关和本地模型

需要两块拼图:一个通过 OpenAI 兼容 API 提供模型服务的东西,还有一个能把模型变成智能体的东西——带工具、文件访问权限和定时任务。

模型服务器。 LM Studio、Ollama、llama.cpp 自带的服务器,随便挑一个都行。不管选哪个,都把它跑成 systemd 用户服务,这样重启也不怕丢:

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # sanity check

智能体网关。 我用的是 OpenClaw,一个开放的自托管网关,可以承载多个具名智能体,给它们配上工具(shell、文件读写、网络搜索),把每个智能体路由到某个模型(本地或云端,带备选),并提供一个聊天界面。装好之后,把一个"webmaster"智能体指向你的本地模型,并给它限定在网站目录内的工具访问权限。不管你选哪个网关,有两条配置规则都很重要:

• 把网关绑定到回环地址,并给任何聊天界面加上身份验证。一个能跑 shell 的智能体,绝不能就这么裸露在你的网络上。
• 把智能体的工作目录限定在网站仓库内。 它该编辑的是 content/,不是你的主目录。

双层结构:日常靠本地智能体,修复靠强力云端模型

一台机器,两层脑力。OpenClaw 智能体——主要靠 DeepSeek 的廉价 API,本地模型垫在后面——负责日常的大量工作:写草稿、编辑、查链接、每周刷新。但当系统本身出故障时(配置回归、网关崩溃、构建跑不起来),我会升级求助一个强力的云端编码模型,把整台机器当病人来诊断。这段经历我单独写在了 OpenClaw 坏了,我用 Claude Code 修 里:OpenClaw 智能体是劳动力,强力编码模型是维修工。

团队成员:机器上的每一个机器人

网关上住着一份具名智能体名单,每一个都路由到适合它任务的模型。它们都会出现在 DisPatch(全家在用的聊天应用)里——但不是每个模式下都全部出现:DisPatch 的 PIN 锁会把名单拆成两组,一组是随时可用的安全组,另一组是解锁后才会出现的全功能组。

机器人	职责	运行模型	DisPatch(锁定)	DisPatch(解锁)
Bits	前台——你直接对话的智能体;理解你的需求,派发给合适的专家	DeepSeek flash(云端)	—	✔
Brains	深度思考者——写规格、做审计,值得等待的任务都交给它	DeepSeek reasoner(云端)	—	✔
Flash	快速任务和定时跟进——追着未完成工作不放的看门狗	DeepSeek flash(云端)	—	✔
Hermes	编码智能体桥接器——派发出去的编程工作	DeepSeek(云端)	—	✔
Doxy	本地苦力——批量和隐私任务,不该离开这台机器	122B 本地模型(vLLM)	—	✔
Charley	视觉——"这张照片里是什么?"之类需要看图的任务	Gemma 31B(本地,LM Studio)	✔	✔
Alpha & Beta	家庭安全通用助手——作业问题、日常闲聊	DeepSeek flash(云端)	✔	✔
Terminex	不是智能体——DisPatch 的 Reasonix 编码终端,浏览器里的一个真实 PTY	DeepSeek(云端)	—	✔

说实话,它们表现如何:

• 靠 DeepSeek 撑腰的机器人是日常主力。 flash 级别的智能体(Bits、Flash、Alpha、Beta)几秒内就能回答,每条消息只要几分之一美分,而且从不需要预热。Brains 用的是 reasoner 档,每次回答明显更慢——这正是它的意义所在,值得深思的问题才交给它——每次会话的花费依然只是几美分。整套系统的实测账单写在 成本那篇文章 里。
• 本地机器人更慢也更笨,但胜在私密和免费。 Doxy 的 122B 模型加载进内存要几分钟,长对话还能再多跑好几分钟;网关的超时设置专门为它调高过。Charley 的视觉模型是个例外,一直在忙——图片描述是这里的廉价云端档位做不到的事,所以本地模型的显存花得值。
• 安全组刻意做得很"无聊"。 Alpha、Beta 和 Charley 是锁定模式下的名单:只提供通用信息和视觉能力,没有任何能碰文件或系统的工具。这就是为什么把手机递给孩子完全不是个事儿。

第二步:静态网站加一个带门禁的部署脚本

智能体和 WordPress 天生合不来——数据库、登录、插件和 PHP,每一个都是攻击面,也都是故障点。静态网站生成器才是智能体天生的搭档:整个网站就是文件夹里的纯文本文件,构建只要一条命令,"发布"就是复制文件。我的生成器是几百行 Python(Jinja2 + Markdown + YAML);Hugo、Eleventy 或 Zola 的原理都一样。真正重要的是这份契约:

• 内容是带 frontmatter 的 Markdown 文件。 大模型天生就会编辑这种文件,git diff 能精确显示它做了什么。
• 构建是确定性的。 相同的内容输入,产出字节级完全相同的网站——所以任何输出变化,都能追溯到某次内容改动。
• 部署路径只有一条,而且安全机制是内建在脚本里的,不是指望智能体乖乖遵守的一套说明文字。

最后这一条,是整套系统的核心。我的脚本大概长这样:

./deploy.sh preflight   # checks SSH, target webroot, size budget
./deploy.sh             # build + DRY-RUN rsync — prints what would change
./deploy.sh --go        # build + server-side backup + publish + verify

脚本保证的事项,按重要性排序:

1. 默认试运行。 不带任何参数运行它,绝不会改动服务器。智能体可以随意运行它,把待发布的改动展示给我看。
2. 绝不删除。 rsync 运行时不带 --delete。一个犯糊涂的智能体可能会用新版本覆盖某个页面,但没法把网站抹掉。
3. 先备份。 带上 --go 时,脚本会在覆盖任何文件之前,先在服务器端给网站根目录打一个 tarball 包(保留最近几份)。备份失败,部署就中止。
4. 失败即拒绝(fail-closed)。 清单缺失、主机不可达,或配置里留着占位值,都会在 rsync 运行之前直接中止。源文件(模板、脚本、配置)被硬性排除在外,绝不会被发到公开的网站根目录。
5. 发布后验证。 脚本会抓取线上首页,搜索构建时嵌入的一个生成器标记——如果旧的托管服务仍在为这个域名应答,单纯的 HTTP 200 可能是个假阳性。

智能体可以随时运行试运行和 preflight 检查,想跑就跑。--go 这个标志留给我一个人。就这一处不对称,就把"一个 AI 拥有类 SSH 的权限,能碰到我的生产网站"这件事,从吓人变成了无聊。

第三步:每周定时更新,带上安全护栏

最后一块拼图,让整套系统能自我维护。一个 systemd 定时器每周触发一次,给智能体下达一份长期任务书:审查网站、刷新过时内容、打磨薄弱的文章、核实内部链接,然后把结果暂存——而不是直接发布。这个任务同时也在维护这篇文章:任务书里有一条就是"重新读一遍 OpenClaw 配置这篇文章,修正任何与现实脱节的地方,并给 updated: 日期盖上时间戳"。这个页面顶部的日期,就是那个时间戳。

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

定时器触发的服务会带着任务书去调用网关的 API(或 CLI),然后对智能体暂存的内容跑安全检查:

• 密钥扫描。 对差异内容做一次模式扫描,找长得像 API 密钥、令牌、密码或私有主机名的东西。gitleaks 这类工具开箱即用。一旦命中就中止整个流程——失败即拒绝,没有例外。
• 专业内容检查。 用一个不同于写手提示词的第二个大模型来做一遍复核,只问一个问题:"这内容,一家正经企业发布出去会不会觉得尴尬?"语气、论断、没写完的 TODO、占位文字都在检查范围内。检查不通过,改动就留在暂存区等人工复核,不会去部署。
• 构建必须通过,包括链接/资源检查器——图片失效或内部链接失效,都会在流程走到部署脚本之前就直接失败。

只有这三项全部通过,任务才会去试运行一次部署——而在这个网站上,真正的发布依然要等我的 --go。如果将来你足够信任这条流水线,愿意让每周任务自主发布,那么这些安全检查,加上"绝不删除、先备份"的部署脚本,会把最坏情况的影响范围锁定在"一篇写得不好的文章上线了,我从备份恢复"这个程度。

如何照搬这一套

上面这一切,光靠这篇文章的描述就能搭出来——里面没有任何私有的东西。浓缩版配方:

1. 挑一台 Linux 机器,把本地模型服务器(LM Studio、Ollama、llama.cpp)装成 systemd 服务。
2. 安装一个智能体网关(OpenClaw 或同类产品),绑定到回环地址;创建一个站长智能体,给它限定在网站目录内的文件/shell 工具。
3. 如果网站还不是静态的,先迁移到静态生成器——输入 Markdown 内容,一条构建命令输出网站。
4. 写好带门禁的部署脚本,落实上面那五条保证:默认试运行、不删除、先备份、失败即拒绝、部署后验证。这一块最值得用心打磨,大概也就 150 行 bash。
5. 加上每周定时器和两项安全检查(密钥扫描 + 大模型内容复核),同样失败即拒绝。
6. 在流水线真正赢得信任之前,--go 始终留给人。

按本站的惯例,文章开头那个"自己动手实现"框说的就是字面意思:这篇文章写得足够详细,你可以把整篇文章丢给自己的大模型,让它照着给你的网站搭出每一块。部署脚本那份保证清单,基本上就是它的规格说明书。

容易踩的坑

• 部署脚本必须是唯一路径。 你(或者智能体)第一次手写一条"就这一次"的 rsync 命令,就等于亲手制造了这个脚本原本要防止的事故。我的脚本会硬性排除源文件、拒绝占位配置,原因就是一次性命令做不到这些。
• 单纯的 HTTP 200 不代表部署成功。 我做 WordPress 迁移时,旧的托管服务一直在为这个域名应答——每次"验证"都通过,而新文件其实根本没派上用场。在构建里嵌入一个生成器标记,然后去线上页面里 grep 它。
• 智能体会照着你给它看的模板走,连 TODO 也不例外。 如果你的文章脚手架里留着占位文字,偷懒的模型会原封不动地把 TODO: excerpt here 发布出去。这也是专业内容检查存在的一半理由。
• 别让写手审自己的稿子。 同一个模型、同一套提示词,盲点也一模一样。审稿至少得换一套提示词,最好换一个模型。
• 定时的大模型任务需要超时设置,以及"暂存而非发布"的默认值。 一个能无人监督发布的每周任务,迟早会在某个周日早上六点发布出一些奇怪的东西。暂存的代价,不过是你多看一眼而已。
• 密钥扫描应该放进流水线里,而不是写进智能体的指令里。 提示词里写"绝不能包含密钥"只是个愿望;对差异内容做一次失败即拒绝的扫描,才是真正的管控。