企业官网建设流程全解析

如果你手上有一台在抽屉里吃灰的树莓派，或者正盯着购物车里的树莓派5犹豫要不要下单，这篇部署笔记应该能帮上忙。我的目标很直接：把树莓派变成一台7x24小时在线的AI助手。这里说的AI助手不是那种打开网页一问一答的聊天框，而是能接收指令、按流程执行、调用外部工具、定时触发任务的AI代理程序。实现这套能力，我用的是OpenClaw这个开源Agent框架，再从本地或局域网里接入大模型算力，把部署、配置、调优、稳定性这几个环节完整走了一遍。

文章不会只给你安装命令列表。我会把每一步的选型理由、踩坑过程、实测数据都交代清楚，尽量让零基础的人也敢跟着操作，同时让有Linux和Docker经验的人也能从中找到有用的调试思路。

1. 为什么我的选型是“树莓派 + OpenClaw”，而不是云服务器或主力电脑

1.1 树莓派做AI助手底座的硬性优势

树莓派这个设备最被低估的点不是算力，而是“存在方式”。一台树莓派5的峰值功耗在5到10瓦左右，待机时更低，一年到头电费加起来也就一杯奶茶钱。相比之下，云服务器按年续费是几百到上千的成本，主力电脑跑24小时则既费电又占资源。树莓派还可以直接扔在路由器旁边、电视柜角落，没有噪音，没有风扇狂转的焦虑（前提是你把散热做好），非常适合当“家里永远不关机的那个小盒子”。

另外一个容易被忽略的价值是数据边界。AI助手如果要对接家里的智能家居、内网服务、个人文件，它必然要接触到大量隐私数据。把这些数据放到自己家里的设备上处理，比丢给云端API心里踏实得多。尤其是做本地知识库、家庭监控摘要、自动化脚本执行这类的场景，数据不出局域网这个底线会给你带来很大的自由度。

1.2 OpenClaw这类Agent框架到底解决了什么问题

如果你用过ChatGPT之类的对话模型，会有一个很明显的痛点：大模型本身只能“说”，不能“做”。你想让它帮你定时去抓取某个网页、处理文件、调用接口、跑一条命令，它只能告诉你“你可以这样做”，然后就没有然后了。OpenClaw这类Agent框架做的事情，就是在模型和真实世界之间架一座桥。框架负责接收任务、拆解步骤、调用配置好的工具技能（Skill），最后把结果返回给模型做下一步判断。

打个比方：大模型是大脑，OpenClaw是手和脚，Skill则是你交给它的各类工具。没有这套中间层，模型再强也没法替你执行。这里有个容易混淆的概念，Agent和“聊天机器人”的本质区别在于闭环：聊天机器人答完即止，Agent要负责把任务做完并反馈结果。把Agent框架部署在树莓派上，本质上是给自家网络里的各种设备配了一个“会安排活儿的管家”。

1.3 什么样的场景才值得这么折腾

我承认，不是所有人都需要一台自建的AI代理。这个方案最适合下面几类场景：

• 家庭内网自动化：每天定时抓取局域网里NAS的状态、温度传感器数据、设备的在线情况，汇总成报告推给手机。
• 跨服务协调：AI助手帮你整理邮件、操作日历、调用家里智能设备接口，或者在设备故障时自动执行重启脚本。
• 隐私敏感的个人知识库：基于本地语料做检索增强问答，不把文档送出家门。
• 纯粹想学习Agent开发与部署链路：树莓派是成本最低的练手平台，踩坑成本几乎为零。

如果你只是想要一个“手机上的智能聊天应用”，那真的没必要看这篇文章。但如果你想拥有一个永远在线、还能替你动手干活的设备，这个组合目前是性价比最高的。

2. 动手前的系统底座：Raspberry Pi OS精简安装与远程通道准备

2.1 镜像选择与刷写要点

系统层面我推荐Raspberry Pi OS Lite，64位版本，不选带桌面的完整版。理由很简单：OpenClaw跑的是服务端进程，不需要图形界面。桌面环境不仅多占用几百MB内存，还会引入一堆无关进程，对稳定性和功耗都有负面影响。Lite版本身就是长期支持版本，更新节奏稳定，适合做无人值守服务器。

刷镜像用官方的Raspberry Pi Imager最省事。这里有个非常实用的细节：Imager在写卡前可以点击设置按钮，直接预配置hostname、开启SSH、填写WiFi密码。不要小看这几项配置，它能让树莓派第一次通电后就自动联网、可远程登录，省去接显示器键盘的麻烦。

提示：SD卡建议选A2等级的U3卡，写入速度直接决定后续pip install和日志写入的体验。有条件的话，我更推荐用USB3.0移动固态硬盘或树莓派5的NVMe子板做启动盘，后面章节会专门说为什么。

2.2 开机后的基础调校：软件源、Swap和静态IP

第一次SSH登录进去，先做三件事。第一，把软件源换成国内镜像源。具体做法是编辑/etc/apt/sources.list，将默认的deb.debian.org地址替换成你所在地区访问速度快的镜像源地址。树莓派OS新版使用了/etc/apt/sources.list.d/下的文件管理来源，所以raspi.list里的源也要一并处理。换完之后sudo apt update，速度会有质的提升。

第二，扩大Swap分区。树莓派的内存虽然可以到8GB甚至16GB，但编译一些包含C扩展的Python包时仍然可能OOM。我习惯把/etc/dphys-swapfile里的CONF_SWAPSIZE改成2048或更高，执行sudo systemctl restart dphys-swapfile生效。这一步是为了后面pip install大轮子时留出缓冲。

第三，给树莓派一个固定IP。你当然可以在路由器后台做DHCP静态绑定，但我更建议直接在树莓派上配置静态地址，防止路由器重启后IP漂移。编辑/etc/dhcpcd.conf，加上：

interface eth0 static ip_address=192.168.1.100/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1 223.5.5.5

注意你家里的网段可能不同，记得改成你自己的实际值。改完重启网络服务后，后续所有服务配置都指向这个固定IP，省心很多。

2.3 免密SSH登录与时区修正

树莓派作为7x24小时设备，至少应该做到免密登录。在电脑上执行ssh-keygen生成密钥后，用ssh-copy-id把公钥推到树莓派，之后登录就不需要输密码。同时把/etc/ssh/sshd_config里的PasswordAuthentication设为no，降低被爆破的风险。

时区和定时任务直接相关。Agent框架的Skill经常要用到cron式的定时触发，如果系统时区不对，任务执行时间会和你预期差出好几个小时。执行sudo timedatectl set-timezone Asia/Shanghai这类命令切换到你的本地时区，再用timedatectl确认时间同步正常。

3. 部署OpenClaw主程序：源码安装全流程与三种“接入大脑”的姿势

3.1 依赖准备与代码拉取

OpenClaw这类Python系框架，在树莓派上最常见的安装方式是源码部署。容器化方案不是不行，但ARM架构镜像体积大、嵌套层多，对SD卡容量和内存占用都不友好，所以我推荐裸机Python环境。

先安装基础依赖：

sudo apt update sudo apt install -y python3 python3-venv python3-pip git build-essential

然后是克隆代码仓库。OpenClaw的版本迭代很快，安装前先去官方仓库页面看一眼README里的版本说明，确认当前分支和Python版本要求。这里说的步骤是通用流程，不同版本的命令细节可能略有差异，以你拉取到的仓库最新文档为准。

cd ~ git clone https://your-openclaw-repo-url/OpenClaw.git cd OpenClaw python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install -r requirements.txt

这里有一个树莓派特有的关键点：部分依赖包（比如某些数据序列化或HTTP相关的库）在PyPI上没有预编译的ARM64 wheel，pip会现场用gcc编译。整个过程在树莓派4上可能长达十几分钟，CPU温度会明显升高。所以我在上一节反复强调先加Swap、装build-essential，不然你很可能在进度条走到一半时遇到Killed，这种问题特别让人崩溃。

3.2 配置文件里的核心字段长什么样

OpenClaw的主配置文件负责定义两件事：模型从哪里来，以及启用了哪些技能。不同分支的配置格式存在差异，但结构思路是相通的，下面是我项目中实际使用过的配置片段结构，可以按你的版本适当调整：

agent: name: home-assistant backend: type: ollama base_url: http://127.0.0.1:11434 model: qwen2.5:3b temperature: 0.2 max_tokens: 2048 skills: - name: shell_executor enabled: true - name: daily_report enabled: true schedule: "0 8 * * *"

temperature这里我建议调低到0.2甚至0.1。Agent任务和聊天不一样，聊天希望模型有灵气，Agent执行任务希望模型“听话”，调低温度能明显减少脚本执行的随机出错概率。max_tokens也不用给太高，Agent的中间产物通常控制在2K以内就够了。

3.3 三种算力接入方案的实测取舍

很多朋友问过一个问题：这类Agent框架是不是只能用云端API？其实不是。OpenClaw的backend层是抽象出来的，你可以接任何兼容协议的推理服务。我在树莓派上实测过三种方案，结论如下：

树莓派5本机跑qwen2.5:3b的量化版，生成速度大概在每秒十几个token，用来做定时摘要、简单脚本执行还说得过去，但指望它主导多轮复杂对话会等到怀疑人生。更合理的做法是：树莓派上只跑OpenClaw框架，算力交给局域网里另一台有NVIDIA显卡的机器，通过Ollama的HTTP接口暴露给树莓派。这样OpenClaw进程本身只占树莓派几百兆内存，稳得很，算力却一点不打折。

云端API方案我只有在出差、局域网GPU不可用的时候才临时切一下。这里也回应那个常见疑问：OpenClaw不是只能接API，backend类型改成ollama、指向本地地址即可，配置文件里甚至不需要填任何api_key字段，完全走内网调用。

4. 让它“自动干活”：Skill技能体系与一个真实可跑的小任务

4.1 Skill机制是怎么工作的

把大模型接上只是第一步，真正让AI助手产生价值的，是Skill技能体系。你可以把Skill理解为插件，每一个Skill对应一种能力：执行Shell命令、抓取网页、读写文件、调用摄像头、发送消息通知、对接智能家居接口，等等。

Agent的工作方式是循环式的。收到任务后，框架让模型判断“这个任务需要调用哪个Skill、传什么参数”，模型输出一段结构化指令，框架解析指令并调用对应的Python函数，拿到执行结果后再交还给模型分析。这个循环会一直进行到模型认为任务完成。

理解了这个机制，你就会明白两个关键点。第一，模型本身不需要“会做”某件事，它只需要“知道”有某个Skill可以做这件事。所以给模型配备好用的工具描述比模型参数大小更影响效果。第二，Skill的返回信息要尽量结构化，纯文本没关系，但要有明确的结果和状态字段，模型才能做出正确判断。

4.2 实战一个定时任务：每天早上抓取内网状态并推送摘要

纸上谈兵没意思，直接上一个我真实跑着的Skill示例。任务目标：每天早上8点，让AI助手查看家里NAS的磁盘使用率、主路由器在线设备数、树莓派自身CPU温度，然后把这三项数据整理成一段摘要文字推送到我的手机。

实现思路分三层。第一步，写一个Skill脚本，负责收集数据并生成一个简单的JSON结构。第二步，在OpenClaw的Skill配置里注册这个脚本，并声明它的功能描述，方便模型“知道”何时该调用它。第三步，配置定时触发，让框架在每天8点主动发起这个任务。

Skill脚本核心逻辑示意（Python）：

import json import subprocess def collect_system_status(): cpu_temp = subprocess.check_output( ["cat", "/sys/class/thermal/thermal_zone0/temp"] ).decode().strip() disk_usage = subprocess.check_output( ["df", "-h", "/"] ).decode().strip().split("\n")[-1] # 这里可以继续调用NAS API、路由器API等 return json.dumps({ "cpu_temp_celsius": int(cpu_temp) / 1000, "disk_root": disk_usage, })

在Skill配置里，你要给模型一段准确的描述，例如“获取树莓派自身CPU温度和根分区磁盘占用情况，返回JSON字符串”，模型在遇到相关诉求时才会正确调用。

4.3 调试Skill的实用套路

Skill开发最容易踩的坑是你以为模型能理解你的代码，实际上它经常传错参数。我总结出一个固定调试顺序：先脱离模型，直接命令行执行Skill脚本，确认返回数据格式正确；再通过框架的控制台手动触发一次，观察框架是否正确解析了模型输出；最后才配置定时任务，让它自动驾驶。

调temperature的作用在这里会非常明显。同样是“调用Shell命令”的任务，temperature为0.8时模型可能突然决定给你加一段解释文字，破坏指令格式；调到0.1之后，输出稳定得像是机器人。记住，Agent场景下让模型“更有创造性”基本都是反效果。

5. “24小时在线”的硬功夫：systemd守护、开机自启与掉电恢复

5.1 让OpenClaw作为系统服务常驻

用nohup或者screen跑OpenClaw，开机不会自动拉起来，程序崩了也没人管。正确做法是把它注册成systemd服务。下面是一个我在用的unit文件模板，可以存到/etc/systemd/system/openclaw.service：

[Unit] Description=OpenClaw Agent Service After=network-online.target Wants=network-online.target [Service] User=pi WorkingDirectory=/home/pi/OpenClaw ExecStart=/home/pi/OpenClaw/.venv/bin/python -m openclaw start Restart=always RestartSec=10 Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target

关键看两个参数。Restart=always表示任何异常退出都会自动拉起，这是7x24小时设备的心脏。RestartSec=10是重启前的等待秒数，防止进程不断崩溃时疯狂重启刷日志。After=network-online.target配合Wants，确保开机时网络已经就绪再启动OpenClaw，避免第一次请求模型接口时网络还没起来。

保存后执行：

sudo systemctl daemon-reload sudo systemctl enable --now openclaw sudo systemctl status openclaw

enable --now是一步到位的组合拳：设置开机自启并立即启动。以后任何时候想查看状态，用systemctl status openclaw；想看实时日志，用journalctl -u openclaw -f。

5.2 日志、温度与SD卡寿命：三个必须提前做的动作

24小时在线最容易被低估的威胁不是程序崩溃，而是小问题长时间累积。第一是日志膨胀。systemd默认的日志存储上限其实不算高，但OpenClaw的调试日志如果长期不清理，依然可能写满根分区。在/etc/systemd/journald.conf里设置SystemMaxUse=200M，然后重启systemd-journald，日志占用就永远可控了。

第二是散热。树莓派5在持续跑Agent进程加编译任务时，CPU温度可以轻松冲到80度以上。别指望裸片靠空气散热就能压住，加一个主动散热风扇壳或者至少贴好散热片。我自己实测，温度从85度降到60度左右之后，SD卡的读写稳定性也明显变好，设备死机频率大幅下降。你可以用vcgencmd measure_temp随时查看温度。

第三是SD卡寿命。Linux系统对SD卡的频繁小文件写入非常不友好，尤其是Agent框架的会话记录、日志、临时文件都在写卡。我的解决方案是系统依然从SD卡启动，但把OpenClaw的整个工作目录和日志目录挂到内存盘或者外置SSD上。如果预算允许，直接让树莓派从SSD启动是最彻底的解决办法，这样“掉电损坏文件系统”的概率也会低很多。

5.3 断电与异常重启后的自愈

树莓派作为家用设备，最大的敌人是家里有人不小心碰掉电插头，或者小区突然跳闸。断电本身不可怕，可怕的是断电后文件系统损坏、服务起不来、IP变了找不到设备。

自愈策略分三档。第一档是SD卡文件系统自动修复：树莓派OS默认在启动时会检查文件系统，遇到非正常关机后的标记会自动进入修复流程，一般情况下等待片刻就能正常进入系统。第二档是服务的自启：前面配置的systemd服务会在系统起来后自动把OpenClaw拉起来。第三档是异常状态的自我监测：在Agent里加一个Skill，定期检查系统时间、关键服务状态和IP地址，一旦发现异常就把诊断信息推送出来。

注意：如果你发现树莓派断电重启后卡在文件系统检查的界面，可以检查/etc/fstab里有没有把errors=remount-ro这类参数配置到根分区，或者直接把启动介质迁移到SSD。SD卡在使用两三年后本来就是消耗品，出现这种情况不要怀疑是自己操作错了。

6. 我踩过的坑和实测数据：帮你省下两到三天的排查时间

6.1 编译依赖时的“内存不足”窘境

装Python依赖看起来是流水线操作，但树莓派上绝不是。我第一次在树莓派4B上执行pip install -r requirements.txt，跑到某个包含C扩展的依赖时，终端直接卡死，SSH断开，过去一看进程被OOM Killer干掉了。树莓派的内存管理很老实，不会像台式机那样疯狂换页，内存不够就杀进程。

解决方案就是我前面埋下的伏笔：先扩容Swap。如果Swap也救不了，就把requirements.txt里的依赖分组安装，每装完一组确认没报错再进行下一组。还有一个技巧是优先尝试pip download到本地，手动检查哪些包有ARM64的wheel，手动装那些需要编译的包时耐心等待，不并行安装，能减少OOM概率。

6.2 模型推理速度的真实数据

本地推理速度直接决定Agent的可用性，我实测的数据给你做个心理建设。树莓派5（8GB版）跑Ollama上的qwen2.5:3b量化模型，单并发生成速度约为15到20 token/s。这个速度做定时汇总、短命令调用是勉强能用的，但一次生成2000字的任务可能要等两分钟以上。

树莓派4B则只有大概5到8 token/s，基本只适合“一句话回答”级别的任务。所以我的明确建议是：如果你是认真的想用它干活，别指望靠树莓派裸跑模型获得好的体验，老老实实接局域网GPU。GPU机器上同样的3B模型能跑到80到120 token/s，7B模型也能有四五十，这个差距是代差级的。

6.3 设备跑几天后突然“变哑巴”的排查链路

我遇到过最诡异的现象是OpenClaw跑了两三天后，状态栏显示服务正常，但问它什么都是“无法连接模型服务”。排查过程爬了挺久，最后确定是树莓派的无线网卡进入了省电模式，在低流量状态下自动断开WiFi，而服务本身没有感知到网络异常。

解决办法有三个：第一，在/etc/NetworkManager/conf.d/下创建一个配置文件，禁用WiFi省电模式；第二，给OpenClaw服务加上Restart=always，网络恢复后进程会自动重连；第三，如果你有以太网口，直接插网线，家庭服务器这类的角色能用有线连接就不要纠结无线。排查这种问题有个通用思路：先看systemctl status openclaw确认进程，再journalctl -u openclaw -n 50看日志，最后curl对应的模型接口确认网络连通性，一层层排除。

6.4 版本兼容性：Skill目录、配置文件与模型名的小坑

OpenClaw这种快速迭代的项目，最坑的不是代码多难，而是GitHub上README跟你拉下来的代码版本经常不同步。我曾经按文档截图配置了Skill目录，结果框架根本不识别，最后发现新版改了默认目录结构。遇到这种问题，唯一可靠的办法是进项目源码里找settings.py或用grep搜配置加载逻辑，看它到底读哪个路径。

模型名也要格外小心。Ollama本地拉取的模型名必须和配置文件完全一致，多一个标签后缀或者少一个版本号，请求都会直接报错。我建议启动OpenClaw之前，先单独用ollama list确认模型确切名称，再复制粘贴到OpenClaw配置里，不要手打。

最后一个不算坑但值得说的问题：OpenClaw支持对接的模型后端繁多，但不同后端的参数风格差异很大。换模型后端时不要只改base_url，模型名称规范、上下文长度上限、工具调用方式都可能不同。每次切换后，跑一个最长链路的任务做回归测试，是最稳妥的习惯。

从开始刷系统到整个Agent稳定跑了几天，我最大的感触是：这套方案真正考验人的不是单个环节有多难，而是你有没有把“在线”两个字当回事。树莓派这种小设备，只要把系统底座打好、服务守护配好、日志管住，剩下的知识积累完全能支撑你把它越用越顺手。希望这篇踩坑笔记能让你少折腾几个通宵，直接体会到自建AI助手的乐趣。