企业官网建设流程全解析

最近在折腾 OpenClaw 的本地部署，前后踩了几天坑，总算把整个流程理顺了。这篇东西不是官方文档的复述，是我自己从零开始、在 Windows 和 Linux 两台机器上分别跑通全流程的记录，包括环境准备、模型对接、Channel 配置、常见报错排查这些，照着做基本能少走一大半弯路。

如果你正准备把 OpenClaw 跑在本地电脑上，或者已经在部署过程中被各种报错折磨，这篇文章应该能帮到你。先说明一下，OpenClaw 在社区里也有人叫它“龙虾”，是一个开源的 AI Agent 框架，核心作用是把你本地的 LLM（比如通过 Ollama 跑的千问、DeepSeek）接上各种即时通讯渠道，让你用聊天软件就能指挥本地模型干活。适合三类人：想完全离线跑 AI 助手的隐私敏感用户、需要把 Agent 接入飞书/Teams 等团队协作场景的开发者、以及单纯想低成本玩大模型的折腾党。

1. 搭建前必须搞懂的几件事

1.1 为什么选本地部署而不是直接用云 API

在开始动手之前，先聊清楚一个问题：你为什么要本地部署？我最初的目的很简单——不想把对话内容发到第三方服务器，而且本地跑从长期看成本更可控。

本地部署 OpenClaw 最大的优势有两个。第一是数据安全，所有对话记录、Prompt、工具调用日志都留在自己机器上，适合处理内部资料、代码片段这类敏感内容。第二是稳定性，不依赖外部 API 的可用性和限流策略，就算外网断了，局域网内照样能用飞书或 Teams 继续指挥 Agent。

代价也很明显：你需要一台配置还行的电脑，至少 16GB 内存（32GB 更舒服），以及一个量化过的本地模型。别指望本地跑个 7B 模型能有 GPT-4 那样的智能水平，但在特定任务上，比如按照固定格式整理日报、检索本地知识库、执行预设的自动化流程，完全够用。

1.2 OpenClaw 的核心架构：一张图看懂各组件关系

我花了比较长时间才把 OpenClaw 的架构理清楚，其实它不复杂，核心就三块：

• 内核（OpenClaw Core）：负责管理会话、调用工具、编排多轮对话逻辑。你可以把它理解成“大脑中枢”，所有任务调度都在这里完成。
• 通道（Channel）：负责对接各种 IM 平台，比如飞书、Microsoft Teams、Discord、Slack。Channel 的作用是“翻译官”，把平台的消息格式转换成内核能理解的内部消息格式。
• 模型后端（LLM Backend）：通过 Ollama 或其他兼容接口加载本地模型。内核向模型后端发请求，拿到回复后再通过 Channel 发回聊天窗口。

三者之间的关系可以这样理解：你在飞书里发一条消息，飞书 Channel 收到消息后转换成标准格式，交给内核处理。内核判断该调哪个工具、要不要向模型请求回答，然后调用模型后端生成结果，最终原路返回。整个链路是“IM平台 → Channel → Core → LLM Backend → Core → Channel → IM平台”。

这个架构带来的直接好处是解耦——你想换模型就直接改 Ollama 里的模型文件，想换聊天平台就换 Channel 配置，互不影响。

2. 环境准备：Windows 和 Linux 两条路线

2.1 最低硬件要求与系统兼容性

先说硬性条件，这是我在两台不同配置的机器上实测下来的结果：

如果你用的是飞牛（fnOS）这类 NAS 系统，也可以装，但流程稍有区别，后面会单独提。核心思路是一样的：先确认系统里有 Node.js（18 以上）或者 Python 3.10+，然后安装 Ollama，最后部署 OpenClaw 本体。

2.2 Ollama 部署：模型从哪来、怎么下

OpenClaw 本身不带模型，它是一个管理框架，真正干活的是后端模型。我目前主力用的是 Ollama，原因很简单：它把模型管理做到了真正的傻瓜级。

Ollama 的安装不用多说，官网下载对应系统的安装包（Windows 直接装 exe，Linux 用安装脚本），装完以后先验证一下是否正常工作。在终端执行：

ollama list

如果显示空列表，说明安装成功但还没下载模型。下载模型前，先想清楚你更需要中文能力还是通用能力。如果你主要做中文办公场景，千问系列是不错的选择；如果你更看重通用代码能力，DeepSeek 或者 Llama 系可以纳入考虑。

以我目前的主力配置为例（千问 7B 量化版）：

ollama pull qwen2.5:7b

这一步会下载几个 GB 的文件，网速正常的话大约 10-20 分钟。下完以后立刻验证一下：

ollama run qwen2.5:7b

输入任意问题，如果模型能正常回复，就可以退出并进入下一步。处理不了中文问答，就先检查是不是模型选错（比如选了纯英文优化的版本），或者本地内存不足导致模型加载失败。这一步不验证好，后面 OpenClaw 接上了也是白接。

2.3 Windows 上安装 OpenClaw 的完整流程

Windows 上的安装其实比大多数教程写的更简单，但坑也最多，尤其是路径和权限。官方推荐的 Windows 安装方式是通过 WindowShub（一个 Windows 下的终端管理工具）拉取安装脚本，实际操作分这几步：

1. 以管理员身份打开 PowerShell，执行：

   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

   不执行这一步的话，后面的安装脚本会被系统默认策略拦住。

2. 检查 Node.js 版本：

   node -v

   如果提示找不到命令，去 Node.js 官网下载 LTS 版本，一路默认安装即可。

3. 安装 OpenClaw：

   npm install -g openclaw

   这里注意，如果你之前装过旧版本，先卸载干净再装新的。否则你会碰到各种奇奇怪怪的依赖冲突。卸载命令：

   npm uninstall -g openclaw

4. 验证安装是否成功：

   openclaw --version

   有版本号输出说明装好了。这时候别急着配置，先初始化工作目录——我建议专门建一个openclaw-workspace文件夹，避免配置文件散落各处，后面备份和迁移也方便。

初始化命令：

openclaw init

运行后会在当前目录生成配置文件（一般是openclaw.json或config.yaml，具体看你选择的配置格式），这时 OpenClaw 的本体已经就绪了。

2.4 Linux 服务器部署要点（Ubuntu/Debian）

如果你的运行环境是 Linux，步骤更直接一些。以 Ubuntu 22.04 为例，先确保装了 Git 和 curl：

sudo apt update && sudo apt upgrade -y sudo apt install -y git curl build-essential

然后克隆 OpenClaw 仓库（如果官方仓库更新，以仓库地址为准，我用的社区镜像分支）：

git clone https://github.com/openclaw/openclaw.git cd openclaw

接下来有两种安装方式：直接用 npm 全局安装，或者拉 Docker 镜像。我个人比较推荐 Docker 方式，因为隔离性好，卸载也干净。OpenClaw 提供的容器化部署命令大致是：

docker pull openclaw/openclaw:latest docker run -d --name openclaw \ -p 3456:3456 \ -v /your/config/path:/app/config \ openclaw/openclaw:latest

注意挂载配置目录时，宿主机路径一定用绝对路径，且授权给当前用户可读写。很多人第一次启动容器失败，都是因为配置文件目录权限不对，容器内进程无法读取。

如果你用的是飞牛 NAS，本质也是 Linux，Docker 兼容性没问题，建议直接走 Docker 路线，进飞牛的 Docker 管理界面填一下镜像名，然后把端口映射和目录挂载配好就行。

3. 模型对接：让 OpenClaw 真正会“说话”

3.1 通过 Ollama 接入千问 / DeepSeek

OpenClaw 默认的模型配置是通过环境变量或配置文件里的model字段指定的。我建议直接在配置里写环境变量，方便以后切换模型。

在 OpenClaw 的配置文件中，找到与模型相关的设置项，填入后端地址和模型名：

{ "model": { "provider": "ollama", "baseUrl": "http://localhost:11434", "name": "qwen2.5:7b", "temperature": 0.7 } }

如果你用的是 DeepSeek 本地版：

ollama pull deepseek-r1:7b

然后把上面配置里的name换成deepseek-r1:7b即可。注意一点：不同的 Ollama 模型标签对应不同量化级别和参数量，别只看名字就下，要看清楚是 7B 还是 14B，是 Q4 量化还是 Q8，这直接决定你的内存撑不撑得住。

3.2 调整上下文长度和生成参数，避免答非所问

模型接上之后，我发现一个实际问题：OpenClaw 在长对话中容易“失忆”。具体表现是，前面聊得好好的，几轮以后它开始重复问你已经给过答案的问题。这个问题通常不是模型本身笨，而是上下文窗口太短，或者是配置里的maxTokens限制太紧。

在 Ollama 里，你可以在启动模型时指定上下文长度：

ollama run qwen2.5:7b --num-ctx 8192

如果是通过 OpenClaw 的配置文件控制，找到生成参数相关字段：

{ "model": { "maxTokens": 2048, "temperature": 0.7, "topP": 0.9, "stream": true } }

这几个参数的经验值：日常对话温度用 0.7 比较自然，但如果你用它跑代码生成或结构化整理，温度调到 0.2-0.3 会更稳定。topP保持 0.9 就好，太高容易啰嗦。maxTokens决定了单次回复的最长长度，如果模型经常说到一半被切断，可以把值往上调。

3.3 macOS 本地跑模型需要注意的地方

在 macOS 上部署的思路其实和 Linux 一脉相承，但有几点体验差异很大。首先是 Ollama 的安装，Mac 版有专门的应用包，装完之后菜单栏会常驻一个小图标，那是 Ollama 的后台服务，别手滑退掉；其次是模型选择，Mac 的 GPU 是共享显存，理论上内存够大就能跑比较大的模型，但实际跑起来会发现降频发热是常态，建议 M 系列芯片从 7B 模型起步，别一上来就挑战 32B。

如果你还打算在 Mac 上给 OpenClaw 装代理通道，比如接 Teams，那么建议不要用系统自带的网络设置去搞全局代{过}理，直接在 OpenClaw 的 channel 配置里指定网络出口，更干净，也不会影响其他程序。

4. Channel 配置：打通飞书、Teams、Discord

4.1 怎么选 Channel，核心逻辑是什么

OpenClaw 里一个很容易搞混的概念是“Agent”和“Channel”。简单来说，Agent 是逻辑主体，Channel 是连接渠道。一个 Agent 可以同时在多个 Channel 上工作，也就是说，你可以在飞书里和它聊天，同时也通过 Teams 向同一个 Agent 发任务。

选择 Channel 的维度其实就四句话：团队用什么聊天软件就用什么通道；一个人用 IM 效率最低，配合 Web UI 更顺手；需要隐私隔离就选自建通道；调试阶段宁可先跑本地控制台通道。

我的建议是：刚开始调试时，先只开一个本地测试通道，确认模型响应正常后再接飞书或 Teams。这样可以避免把“模型配置问题”和“消息通道问题”混在一起排查。

安装一个 Channel 本身的步骤，在 OpenClaw 里通常是用一句命令完成的，比如：

openclaw channel add <channel-name>

这个命令会引导你进行授权，不同平台的授权逻辑不同：飞书需要你创建一个企业自建应用并配置权限；Teams 需要你在 Azure 门户注册一个 bot 应用；Discord 则是创建一个 Bot 并粘贴 Token。授权完成后，OpenClaw 会把凭证信息加密存储在配置目录里，不会二次问你要。

4.2 接飞书的具体步骤和常见坑

我在飞书上的接入过程比较顺利，大体上四个步骤：

1. 进入飞书开放平台，创建企业自建应用
2. 在应用权限里开启“接收消息”和“发送消息”两个权限
3. 配置事件订阅，URL 填 OpenClaw 暴露的公网地址或局域网地址（按你的实际部署方式）
4. 在 OpenClaw 里执行openclaw channel add feishu，然后按提示填入 App ID 和 App Secret

之后就可以在飞书里私聊你的机器人试试效果了。

坑点主要有一个：很多人以为事件订阅 URL 填完就万事大吉，其实飞书会发送一个验证请求，如果你的 OpenClaw 服务没有正在运行，验证永远不通过。所以顺序应该是“先启动 OpenClaw，再配置事件订阅 URL”，启动后立刻去飞书后台点击验证。

另一个我遇到过的坑是飞书消息长度限制。OpenClaw 在飞书里输出长文时容易被截断，原因是飞书对单条消息长度有硬性限制，超过之后会直接切断。这个问题的解决办法不是去改 OpenClaw 的源码，而是开启消息分段发送功能。在配置文件里找到 channel 相关设置，开启消息分段（大概字段名是enableMessageSplitting或者类似含义的开关），并且在飞书后台确保机器人有“发送富文本”的权限，不然分段以后的消息可能变成纯文本格式。

4.3 接入 Microsoft Teams 的实操记录

Teams 的接入比飞书麻烦一些，要在 Azure 门户走一圈。我第二次配的时候大概花了半小时，主要时间都耗在权限理解上。

核心流程是：到 Azure 门户注册一个应用 → 启用 Bot Channel → 获得 App ID 和 Client Secret → 回到 OpenClaw 配置。

{ "channels": { "teams": { "enabled": true, "appId": "your-app-id", "appSecret": "your-client-secret", "tenantId": "your-tenant-id" } } }

注意一个细节：Teams 的 Bot 认证里tenantId是可选项，但如果你的组织启用了条件访问策略，不填就有可能导致认证失败。填了以后，如果出现代{过}理或防火墙报错，优先检查网络出口策略。

接完 Teams 以后我测试了一下私聊和群聊场景。私聊场景下，Teams 默认会给机器人发所有消息；群聊场景下，需要你手动在团队里添加机器人，并且标签机器人的方式是在消息中@Bot名称。很多群聊没反应的原因，其实就是忘了 @，或是 Bot 没有被加到那个频道里。

4.4 其他 Channel（Discord/Slack）简述

Discord 和 Slack 的接入思路都是一样的：创建一个 Bot → 拿到 Token → 在 OpenClaw 里加 Channel → 把 Bot 拉进服务器/频道。只不过 Discord 的 Token 是在 Discord Developer Portal 里创建 Bot 后拿到的，而 Slack 需要你先建一个 App 并开启 Socket Mode。

从我的实际体验看，自建本地 Agent 最常用的其实还是飞书和 Teams。Discord 更适合个人玩家或者小圈子的极客环境，Slack 则是海外团队用得比较多。如果你的使用场景是纯自用，我更推荐用 OpenClaw 自带的 Web Chat 界面（如果支持的话），省去授权和公网暴露的麻烦。

5. 实战运行：第一次启动到稳定跑起来

5.1 初始化配置与目录结构

弄完了模型和 Channel 配置，接下来就是正式启动了。第一次启动之前，建议先把配置内容完整检查一遍。

我的配置文件最终长这样（省略敏感信息版）：

{ "agent": "openclaw", "model": { "provider": "ollama", "baseUrl": "http://localhost:11434", "name": "qwen2.5:7b" }, "channels": { "feishu": { "enabled": true, "appId": "...", "appSecret": "..." } }, "storage": { "sessionDir": "./sessions", "logDir": "./logs" } }

注意这个sessionDir字段，这就是后面要重点处理的会话文件目录。OpenClaw 会把每个对话会话记成一个文件，如果有人没有正常退出，文件就会一直处于锁定状态，这个后面会解释。

检查完毕以后，首次启动：

openclaw start

如果是 Docker 部署，则：

docker start openclaw docker logs -f openclaw

看到类似“started”或“listening on port 3456”的日志，就说明主程序正常了。

5.2 验证模型响应和 Channel 连通性

主程序起来了，不代表一切正常。我习惯分四层验证：

• 第一层：本地控制台测试。看 OpenClaw 的控制台日志里有没有报错。
• 第二层：直接调用模型接口测试。在浏览器访问http://localhost:11434/api/generate或检查 Ollama 日志，确认模型服务正常。
• 第三层：通过测试 Channel 向 Agent 发消息。这一步能确认内核消息路由没问题。
• 第四层：通过真实 IM 平台发消息。确认 Channel 到平台的链路是通的。

我建议至少跑通前三层再继续，否则遇到问题的时候很难定位到底出在哪一环。

第一次跑通飞书对话的时候，我确实有一种“世界被打开”的感觉。在飞书里跟自己的本地模型聊天的体验，跟网页版聊天完全不一样——更像是跟一个接入你工作流的同事说话，可以直接在聊天窗口里让它整理纪要、查资料、输出结构化内容。

5.3 让它跑在后台：systemd 和 Docker 的守护配置

本地部署要想长期稳定跑，不能每次都开一个终端窗口挂着。Linux 下最稳的方式是配置 systemd 服务。新建一个服务文件openclaw.service：

[Unit] Description=OpenClaw Service After=network.target [Service] User=yourusername WorkingDirectory=/path/to/openclaw ExecStart=/usr/bin/openclaw start Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl enable openclaw sudo systemctl start openclaw

以后就不用管了，开机自启、崩溃自动拉起。

Windows 下没有 systemd，我一般用两种方式：一种是任务计划程序（开机触发或登录触发），另一种是开一个专门的 PowerShell 窗口跑openclaw start，用 NSSM（Non-Sucking Service Manager）把它注册成 Windows 服务也很省心。

6. 高频报错与排查技巧实录

6.1 “session file locked”报错：起因和解决

热词里有一个很典型的报错：agent failed before reply: session file locked (timeout 60000ms)。我第一次遇到这个报错的时候完全懵了——明明什么都没干，怎么就锁定了？

实际上，OpenClaw 的会话管理机制是：每个会话对应一个 JSON 文件，当某个进程正在处理这个会话时，文件会被加锁，防止并发写坏数据。如果你的上一次对话进程没有优雅退出（比如直接关掉终端、机器强制重启），锁没有释放，新请求进来时发现锁文件还在，就会出现这个报错。

解决办法分三个层次：

• 最简单：删掉锁文件。在会话目录下找到对应的.lock文件或同名的锁标记，删掉后重启 OpenClaw。
• 更稳妥：查一下是不是真的还有 OpenClaw 进程在跑。用ps aux | grep openclaw（Linux）或任务管理器（Windows）确认没有残留进程后再删。
• 治本：在配置里开启会话空闲自动释放。把sessionTimeout调整到一个合理值（比如 300 秒），让长时间没有活动的会话自动释放锁。我用的是 300 秒，太短会导致长任务被误杀，太长则可能堆积很多死锁。

如果你用的是 Docker 部署，这个报错的频率更高，因为容器异常退出时，文件锁往往来不及释放。你可以在启动容器时加--restart unless-stopped，或者加一个启动时清理锁文件的脚本。

6.2 飞书输出截断：分段发送与富文本

前面已经提到了飞书单条消息长度限制导致的截断问题，这里再补充一下具体的操作过程。

首先在 OpenClaw 的配置里找到飞书 Channel 的设置，开启消息分段发送（如果配置文件里没有这个字段，说明当前版本支持得比较隐晦，需要手动在feishu配置块里加enableMessageSplitting: true）。

有个细节很容易忽略：飞书机器人默认权限只允许发纯文本，导致分段后每段被当作文本消息发送，长段落中的换行、加粗全部丢失。解决办法是到飞书开放平台为机器人添加“获取群组中所有消息”“发送消息”等完整权限，同时在事件订阅里开启im.message.receive_v1。权限没到位，就算 OpenClaw 里配置了分段也没用。

6.3 启动时报错找不到模块与基本排查套路

无论 Windows 还是 Linux，npm 全局安装后概率遇到的一个问题就是——明明装好了，启动时报 “Cannot find module ‘xxx’”。这种问题绝大多数情况下是 Node.js 版本和依赖版本冲突，或者全局包的路径没有被系统识别。

两个排查命令：

# 检查全局安装路径 npm config get prefix # 检查路径是否在环境变量里 echo $PATH

如果全局路径不在 PATH 里，Linux 可以临时加上：

export PATH="$PATH:$(npm config get prefix)/bin"

Windows 则在系统环境变量里把 Node.js 的全局node_modules目录添加进去，然后重开终端。如果还是不行，干脆换个思路：用npx openclaw start直接调用，能绕开大部分路径问题。

6.4 高频问题速查表

这些坑我都一个个踩过，而且很多问题在中文社区找不到答案，只能对着日志一步一步试。所以我在文中尽量把报错信息和当时的环境写清楚了，方便你搜索时对号入座。

7. 从能用到好用：OpenClaw 的进阶玩法

7.1 多个 Channel 协同与独立 Agent 配置

当你跑通了一个 Agent 和一条 Channel，下一步通常是多 Channel 协同。OpenClaw 本身支持在配置里定义多个 Agent，并为每个 Agent 指定不同的模型、不同的场景描述、不同的 Channel 权限。比如：

{ "agents": [ { "name": "daily-assistant", "model": { "provider": "ollama", "name": "qwen2.5:7b" }, "channels": ["feishu"], "systemPrompt": "你是一个帮团队写周报和日报的助手" }, { "name": "code-helper", "model": { "provider": "ollama", "name": "deepseek-r1:7b" }, "channels": ["teams"], "systemPrompt": "你是一个代码审查助手，专注解释和生成代码" } ] }

这样就可以实现飞书里跑日常办公助手、Teams 里跑代码助手，相互之间隔离，互不干扰。这对团队场景非常实用，每个人各用各的机器人，但底层模型都在同一台机器上，资源利用更高效。

7.2 结合 RAGFlow 做本地知识库问答

如果你已经有一套本地知识库（比如公司内部文档、产品手册），可以考虑把 OpenClaw 和 RAGFlow 或者其他知识库引擎搭在一起。基础思路是：OpenClaw 收到问题时，先用 RAGFlow 检索相关知识片段，再把这些片段作为上下文附带发送给模型。

我用下来的体验是，这个组合能大幅减少模型失真回答。没有本地知识库的时候，模型遇到不清楚的问题就是一本正经地编；接上知识库以后，至少知道在文档里找依据。

配置方式不复杂：在 OpenClaw 里加一个知识库工具调用，然后把 RAGFlow 的 API 地址和 API Key 填进去就行。如果你只是想快速体验这个能力，也可以先手动把文档塞进 Prompt 上下文里，但别试太长，文档一旦超过上下文长度，模型就开始胡言乱语了。

7.3 OpenClaw 与 WorkBuddy、MiniMax H3 的横向对比

最近社区里很多人问 OpenClaw 和 WorkBuddy 怎么选，MiniMax H3 本地部署能不能接 OpenAI 接口。我的判断是：OpenClaw 的优势在于开源、配置灵活、Channel 多，适合自己折腾；WorkBuddy 那种集成度高的工具更适合不想花太多时间在配置上的人，但可定制性弱不少。

MiniMax H3 的情况比较特殊，它对中文优化做得很好，如果你有充足的内存（起码 32GB），非常建议拿它跑一个专门的 Agent 来处理中文长文任务。只要它提供兼容 OpenAI 的 API 格式，接 OpenClaw 就是改baseUrl和name两个字段的事。

7.4 后续可以这样扩展

这里先分享一个我个人常用的扩展方向：让 OpenClaw 定时干活。比如每天早上 9 点自动整理昨天的项目日志，或者每小时轮询某个接口并把变化推送到飞书群里。这个思路利用的是 OpenClaw 作为 Agent 的任务调度能力，不需要额外写复杂代码，在配置里加一个定时任务描述就能开始尝试。

不过别一上来就搞太复杂的自动化，先让它干一件最简单的事，比如每天定时在工作群里说一句“早上好，今日待办已生成”，跑几天确认稳定了，再逐步加更多能力。我刚开始就是贪多，结果一次加了五个任务，排查起来费了很多时间。

最后再给你几个经验总结

OpenClaw 这套东西，如果你只是照着一篇教程从头到尾跑一遍，大概率会遇到教程里没写的问题。我这里分享几个自己摸索出来的经验。

第一，所有配置文件改完以后，重启 OpenClaw 之前先做语法检查。JSON 格式多一个逗号少一个括号，启动时就报错，有时候错误信息还特别隐晦。用openclaw config validate（如果有这个命令）检查一下，能省掉大量查错时间。

第二，日志永远是你最好的老师。不要一上来就上网搜报错信息，先看 OpenClaw 自己的日志，找到出错的组件到底是模型还是 Channel 还是内核，再去解决问题。排查工具分清了“链路”之后，绝大多数问题都能在十分钟内定位。

第三，如果你有 NAS 或闲置的 Linux 小主机，强烈建议把 OpenClaw 部署在上面而不是主力电脑。因为本地模型一旦跑起来，风扇狂转、内存吃紧是常有的事，放在 NAS 或远程小主机上，体验会舒服很多。飞牛上部署 OpenClaw 就是大众做法，只要你的 NAS 支持 Docker 就能跑起来。

最后一句话收束一下吧：本地 AI Agent 的真正价值不在于它能回答多难的问题，而在于它把大模型的力量收敛到了一个你可以完全控制的边界里。这台机器只属于你，模型只属于你，对话记录也只属于你。在折腾 OpenClaw 的这个过程中，你真正获得的不是一个跑通的机器人，而是一套属于你自己的 AI 工具箱。