OpenClaw 部署实操：接入 DeepSeek V4 与通义千问 3.5，解决高频报错

先交代个背景，方便你判断这篇值不值得读完。OpenClaw 这个开源项目我从它两万星的时候就在盯着，2026 年开年直接冲到 25 万星，GitHub Trending 连续霸榜好几周，社区里已经有人拿它跑完整的"数字员工"业务。但我后台收到最多的求助还是老三样：装不上、配不好、接完模型不回复。

原因其实不复杂——官方 wiki 默认读者有 Agent 框架基础，一篇教程里塞了几十个命令，新手分辨不清哪些是必须的，哪些是绕路。这篇教程我按"部署前要搞懂什么 → 怎么装 → 怎么接 DeepSeek V4 → 怎么接通义千问 3.5 → 怎么选 Channel → 怎么修高频报错"的顺序来写。你不需要有 Agent 开发经验，只要会敲命令、会复制粘贴配置文件，就能跟着跑通。文里所有步骤都是我在 Windows 和 Linux 两台机器上实际执行过的，报错环节也附了完整排查思路。

1. 拆解 OpenClaw：25 万星项目到底解决了什么问题

1.1 它是个 Agent 编排框架，不是聊天软件

很多人第一次听说 OpenClaw，会下意识觉得它是又一个对标 ChatGPT 的聊天工具，这个理解从一开始就跑偏了。OpenClaw 不是模型，不是聊天界面，而是一个开源的 Agent 编排框架，官方定位是"把大模型变成能干活、能调工具、能跨平台对话的自主智能体"。

我习惯用一个类比来解释：模型是大脑，OpenClaw 是身体。没有身体的大脑，只能在网页对话框里一问一答，你让它读文件、查数据库、定时发消息，它全都做不到。OpenClaw 补上的正是这一层——它负责把模型的输出翻译成真实的工具调用，把多轮对话整理成可持久化的会话，把 Telegram、飞书、命令行这些入口统一切换。

所以你会发现，OpenClaw 本身不提供任何模型能力，你接入 DeepSeek V4 也好，通义千问 3.5 也好，它都一视同仁。这种"模型无关"的设计，恰恰是它能在 2026 年爆发的基础。

1.2 三层架构：模型层、Agent 层、渠道层

整个 OpenClaw 的代码结构可以理解成三层，理解了这三层，后面所有配置你都能自己推出来。

第一层是模型层（Model Layer）。这一层管理所有模型提供方，包括 API 地址、密钥、模型 ID、上下文长度这些参数。OpenClaw 对模型的要求是兼容 OpenAI 的接口协议，DeepSeek 官方 API 和阿里云百炼的兼容模式都满足这个条件，所以接入成本极低。你可以同时配五六个提供方，跑的时候再选定用哪个。

第二层是 Agent 层（Agent Layer）。这是核心，负责工具注册、任务规划与执行循环、会话管理、记忆持久化。比如你让它"每天上午十点帮我汇总未读邮件"，就是这层在拆解任务、调用邮件工具、按计划执行。会话管理也在这层，后面会讲到的 session file locked 报错，根源就在会话锁机制上。

第三层是渠道层（Channel Layer）。这一层解决的是"你在哪里和 Agent 说话"的问题。CLI 终端、Web 控制台、Telegram、Discord、飞书、Slack 都属于渠道。渠道层把不同平台的消息格式统一转换成 Agent 内部格式，所以同一个 Agent 配置，既能在飞书群里用，也能在命令行里跑，不需要复制两份。

1.3 爆火背后的三个原因

第一个原因是模型无关带来的自由度。OpenClaw 没有绑定任何一家模型厂商，DeepSeek、通义千问、GLM、Kimi 甚至本地模型都能接，正好赶上国产模型价格战的窗口期，无数想省成本的开发者涌入，直接把社区热度带了起来。

第二个原因是配置化门槛低。整个框架的核心配置就是一个 YAML 文件，模型、渠道、工具全都写在里面，不像很多老牌 Agent 框架要写一堆 Python 代码才能注册一个自定义工具。

第三个原因是渠道生态把 Agent 真正带进了日常工作流。能够在飞书群里直连 Agent，对国内团队来说太有吸引力了，协作场景一下子就打开了。不过也正是因为涌入的用户太多，傻瓜式教程跟不上，所以才有了你看到的这么多安装和配置问题。

2. 部署前必须搞懂的四件事：环境、目录、路由、会话锁

2.1 环境要求：硬件和系统怎么选

先别急着敲安装命令，花五分钟过一遍你机器的底子。OpenClaw 本身不跑模型推理，所以它对显存没有要求，模型推理全部在 DeepSeek、通义千问这些云端 API 上进行。但 Agent 框架自身有本地运行时，要做工具调度、会话存储、日志处理，这部分仍然需要一定的系统资源。

最容易被忽略的是磁盘空间。会话历史默认全部落盘，跑一个月高强度使用，日志和 session 文件加起来可能超过 2 GB，装之前确认下系统盘剩余空间。

2.2 配置目录：所有关键数据都在 ~/.openclaw

OpenClaw 的配置和数据统一放在用户主目录下的.openclaw文件夹里，Windows 上是%USERPROFILE%\.openclaw，Linux 上是~/.openclaw。

这个目录里的核心内容有这几块：

• config.yaml：主配置文件，模型、渠道、Agent 参数全在这里，改配置基本都是动它。
• sessions/：会话文件，每个对话一个目录，里面包含消息历史、会话锁文件。
• logs/：运行日志，排查报错的第一现场。
• agents/：每个 Agent 的独立定义，包括它的系统提示词、工具白名单。
• plugins/：社区安装的插件。

我强烈建议你在部署前就把这个目录结构搞清楚，因为后面遇到的所有问题，比如 session file locked、模型没生效、渠道连不上，最后都要回到这个目录里找答案。还有个习惯要养成：改配置文件之前，先复制一份config.yaml备份，我就是靠这个习惯避免了无数次配置改坏后的返工。

2.3 模型路由：OpenClaw 是怎么决定用哪个模型的

这里要重点讲一下模型路由，因为很多人在配置里写了多个模型之后就开始迷糊：我到底配哪个？它默认用哪个？

OpenClaw 的模型选择逻辑遵循一个优先级，从高到低是：对话内/model指令 → 启动时的--model参数 → 配置文件里的model.default→ 系统默认值。换句话说，你可以在运行时临时指定模型，也可以把它固定在配置里。

配置文件里每个模型提供方都有一个name和若干models。路由时可以按提供方（provider）选，也可以直接按模型 ID 选。举个例子，你同时配了 DeepSeek 和通义千问，默认用 DeepSeek V4，但某个 Agent 专门跑轻量任务，就可以给它单独指定qwen3.5-turbo，相互不干扰。

这条设计的意义在于：不同任务对模型的聪明程度和响应速度要求完全不同。复杂代码理解用最大的模型，日常闲聊和简单工具调用用轻量模型，能省不少 API 费用。

2.4 会话锁：理解 session file locked 的第一步

会话锁（session lock）是 OpenClaw 为了保证会话数据一致性设计的机制，理解它，你就能秒杀一大堆排错问题。

当一个请求进入 Agent 执行时，OpenClaw 会在对应的 session 目录下创建一个.lock文件，标记"这个会话正在被处理中"。处理完成后释放锁，删除锁文件。这个机制的目是防止两个并发请求同时写入同一个会话文件，导致消息历史错乱或者文件损坏。

锁带有超时时间，默认 60 秒，也就是配置里的timeout 60000ms。如果某个请求在 60 秒内没能完成并释放锁，后续的请求就会等到超时，然后报出你熟悉的那句agent failed before reply: session file locked (timeout 60000ms)。

什么情况会导致锁迟迟不释放？最常见的是进程异常崩溃，锁文件没来得及清理；其次是同一个 session 目录被两个 OpenClaw 实例同时使用；再就是权限问题导致锁文件删不掉。这些排查方法我在第七节详细展开，这里你先记住会话锁的存在和它的作用就行。

3. Windows 与 Linux 双平台安装实操

3.1 Windows 安装：windowshub 是最省事的路线

Windows 上装 OpenClaw 主要有三条路，从省事程度排序是：windowshub 安装 > winget 安装 > 压缩包手动解压。

2026 年，Windows 11 系统自带的 windowshub 已经成了社区最主流的安装渠道。这个软件中心直接集成了大量开源开发工具，不需要额外配置软件源，装完自动配好 PATH 和环境依赖，对零基础用户是最友好的。

打开 PowerShell，执行：

windowshub install openclaw

如果提示找不到 windowshub 命令，说明你的系统版本未启用这个组件，可以用 winget 兜底：

winget install OpenClaw.OpenClaw

安装完成后重启终端，验证一下版本：

openclaw --version

能正常输出版本号，就说明核心程序装好了。

如果你更喜欢绿色免安装的方式，可以到 GitHub Releases 页面下载对应系统的压缩包，解压后把openclaw.exe所在目录加入系统 PATH。这种方式的好处是升级方便，但首次配置环境变量的过程对新手不太友好，我不推荐零基础用户选这条路。

3.2 Linux 安装：命令行脚本与 systemd 托管

Linux 环境下推荐用官方安装脚本，Ubuntu 22.04 和 Debian 12 上测试都比较稳定：

curl -fsSL https://get.openclaw.sh | bash

脚本会检测系统架构，下载对应的二进制文件到/usr/local/bin/openclaw，并把配套的 Python 运行时装好。装完后执行：

openclaw --version

单机跑着玩，用openclaw serve前台启动就够了。但如果想长期稳定运行，建议直接用内置的 systemd 支持把它注册成系统服务：

openclaw systemd install systemctl enable --now openclaw systemctl status openclaw

注册成服务的好处是开机自启，崩溃后 systemd 会自动拉起，不需要人工干预。我在自己的 Linux 服务器上用的就是这种方式，跑了几个月基本没操心过进程问题。

喜欢容器化的朋友也可以用官方 Docker 镜像：

docker run -d --name openclaw \ -v ~/.openclaw:/data \ -p 8080:8080 \ openclaw/openclaw:latest

需要注意，~/.openclaw挂载进容器后，文件权限可能会变成 root，后续在宿主机上用普通用户操作目录会有问题。解法是启动容器后执行一次chown -R 你的用户名:你的用户组 ~/.openclaw。

3.3 初始化与自检：openclaw init 和 doctor 检查单

安装完成后，先初始化配置目录：

openclaw init

这个命令会创建~/.openclaw目录结构，并生成一份默认的config.yaml。紧接着建议跑一次环境自检：

openclaw doctor

doctor 会逐项检查环境和配置，常见检查项包括：

我见过不少人跳过 doctor 直接配模型，结果模型配好了，服务却起不来，回头查半天发现是运行时版本不对。强烈建议把openclaw doctor跑通再进入下一步。

4. 零基础对接 DeepSeek V4：从申请 Key 到跑通第一句对话

4.1 申请 API Key 与账户准备

OpenClaw 对接 DeepSeek V4，本质就是配置一个符合 OpenAI 协议的服务端点。第一步去 DeepSeek 开放平台注册账户，完成实名认证后，在控制台的 API Key 管理页面创建密钥。

创建后你会看到一串以sk-开头的密钥，复制保存到安全的地方。有两个提醒：一是密钥只显示一次，关闭页面后无法再次查看，忘记只能重新创建；二是千万不要把密钥提交到 Git 仓库或者贴进公开讨论区，泄露后别人可以用你的账户调模型，产生费用。

另外要确认账户里有余额。DeepSeek V4 上线后价格比 V3 有了明显下调，但依然是预付费模式，账户余额不足时接口会直接拒绝调用。充一点小额进去再开始，避免调试到一半因为欠费中断。

4.2 写配置文件：一个最小可用的 YAML 示例

打开~/.openclaw/config.yaml，把模型提供方配置填进去。这里给一个我实际使用的精简配置：

model: default_provider: deepseek default: deepseek-v4 providers: - name: deepseek base_url: https://api.deepseek.com/v1 api_key: sk-你的密钥 models: - id: deepseek-v4 max_tokens: 8192 - id: deepseek-v4-pro max_tokens: 8192

逐项解释一下：

• base_url：API 的入口地址，DeepSeek 官方兼容 OpenAI 协议的地址就是https://api.deepseek.com/v1，注意末尾的/v1不能丢。
• api_key：你申请的密钥，直接明文写在配置里。如果不想明文保存，也可以设置环境变量OPENCLAW_API_KEY，配置里只保留env: OPENCLAW_API_KEY，二选一即可。
• models：这个提供方下可用的模型列表。这里填的id必须和平台实际的模型标识一致，比如deepseek-v4，写成DeepSeek-V4这种大小写混排，很可能会报模型不存在。
• max_tokens：单次生成的最大 token 数，代码任务建议给足 8192。

YAML 配置对缩进极其敏感，provider 列表项必须保持统一的缩进层级。我踩过的教训是：在编辑器和网页文档之间来回复制配置时，Tab 键和空格混用导致解析失败，日志里只提示"config parse error"，不显示行号。现在我都用支持 YAML lint 的编辑器改配置，改完先验证语法再重启服务。

4.3 验证：跑通第一句对话的三种方式

配置保存后重启服务，然后用三种方式逐级验证：

第一种，命令行直连测试，确认模型接口本身没问题：

openclaw chat --provider deepseek --model deepseek-v4 "你好，请简短介绍一下你自己"

能收到正常回复，说明 API 密钥和模型配置都没问题。

第二种，通过 Agent 跑一个真实任务，验证工具调用链路：

openclaw agent --session test "帮我写一个 Python 快速排序函数，并解释每行作用"

如果 Agent 能正常规划、调用代码生成工具并给你完整回复，说明 Agent 层也通了。

第三种，观察日志确认请求确实是发到 DeepSeek 的：

openclaw logs --follow

日志里能看到请求对应的模型标识。这一步很多人会跳过，其实很有用，它能帮你确认配置里的模型路由是否真的生效，排查"我以为用的是 V4，实际跑的是另一个模型"这类问题。

4.4 鉴权与调用报错速查

对接过程中最容易碰到下面这些报错，我按频率排序：

这里额外说一句 429 的处理。OpenClaw 默认支持并发请求，如果你的 Agent 同时接到多个飞书群消息，瞬间的请求量可能会触发平台限流。遇到这种情况，要么在配置里把并发数调小，要么按请求量购买更高的配额，单纯把超时时间调大并不能解决问题。

5. 通义千问 3.5 接入与多模型切换

5.1 申请 DashScope API Key

通义千问系列的接口由阿里云百炼平台（DashScope）提供。登录阿里云百炼控制台，在 API-KEY 管理页面创建密钥，密钥格式同样是sk-开头。开通服务时注意勾选"兼容 OpenAI 客户端访问"这个选项，这个开关决定了你是否能用 OpenAI 协议直接对接。

通义千问 3.5 系列的模型标识分三档：

• qwen3.5-max：旗舰版，复杂推理和代码生成能力最强，价格最高。
• qwen3.5-plus：均衡版，适合多数日常任务。
• qwen3.5-turbo：轻量快模型，适合工具调用和简单问答。

5.2 兼容模式配置：OpenAI 协议直接对接

通义千问和 DeepSeek 的接入方式几乎一模一样，区别只在base_url和模型 ID。在config.yaml的 providers 列表里追加一个提供方：

- name: qwen base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: sk-你的百炼密钥 models: - id: qwen3.5-max max_tokens: 8192 - id: qwen3.5-turbo max_tokens: 4096

注意base_url里/compatible-mode/v1这一段是阿里云专门为 OpenAI 协议客户端准备的兼容端点。如果你误用了原生 DashScope 的地址格式，OpenClaw 会发出去一堆无法识别的请求，直接报连接失败。

配置好之后同样用openclaw chat --provider qwen --model qwen3.5-max "你好"验证一遍。能通就说明兼容模式没问题。

5.3 多模型切换的三种姿势

接了两家模型最大的好处就是可以按场景切换，OpenClaw 一共给了三种切换方式：

第一种，在对话里直接下指令切换。打开 Web 控制台或支持指令的渠道，输入/model qwen3.5-turbo，当前会话立刻切换模型，不影响其它会话。适合临时想让 Agent 快点回复的场景。

第二种，启动时指定。用--provider和--model参数临时指定，适合跑一次性任务：

openclaw chat --provider qwen --model qwen3.5-max "帮我分析这段代码的性能瓶颈"

第三种，在配置文件里设默认值。把model.default改成你想长期使用的模型，这个适合确定某个模型为主力后固定下来。

5.4 千问系模型的选型经验

用了一段时间 qwen 系模型，我总结出一条比较实用的选型经验：区分"思考型任务"和"执行型任务"。比如代码架构设计、长文档总结、复杂逻辑分析这类，用qwen3.5-max保底；而调用工具、查询信息、格式化输出这类执行型任务，qwen3.5-turbo的响应速度快且质量完全够用。

OpenClaw 本身支持给不同职责的 dispatch 配置不同模型，你可以把规划模型设为 max，把执行工具调用的模型设为 turbo，这样既保证复杂任务的效果，又不会白白烧掉太多 API 费用。这条对比我在第八节的调优清单里会再展开。

6. Channel 选择逻辑与飞书输出截断修复

6.1 Channel 到底怎么选

Channel 是 OpenClaw 里最容易让新手困惑的概念，因为你给它取的"渠道"这个名字实在过于抽象。一句话解释：Channel 就是你和 Agent 对话的入口，OpenClaw 启动后会同时监听你开启的多个渠道，任何渠道收到消息，都会转成 Agent 的统一输入去处理。

查看当前支持哪些渠道，执行：

openclaw agent --list-channels

常见的渠道包括cli、web、feishu、telegram、discord、slack等。新人配置的时候只需要按自己的使用场景做取舍：

• 自己一个人用，追求最快上手：选cli和web，不需要任何额外注册。
• 团队协作、日常办公沟通：选feishu，在飞书群里直接喊 Agent，交付完全融入现有工作流。
• 个人跨平台使用，手机电脑都要能触达：选telegram。

我个人的建议是：不要一开始就贪多把所有渠道全部打开。渠道越多，报错排查面越大，光每个渠道的 token 和回调配置就能让你怀疑人生。先用 cli 或 web 跑通 Agent 本身，再加一个你团队真正在用的办公渠道，够用就好。

6.2 飞书渠道接入的完整配置

最近问飞书接入的人非常多，我把这套流程完整走一遍。先在飞书开放平台创建一个企业自建应用，拿到 App ID 和 App Secret。然后在应用的能力配置里开启机器人能力，并在事件订阅中添加接收消息事件，配置请求地址时选择长连接模式，可以免去公网回调地址的部署。

接着在config.yaml里追加飞书渠道配置：

channels: feishu: enabled: true app_id: cli_你的AppID app_secret: 你的AppSecret chunk_output: true max_msg_len: 28000 output_format: markdown

配置完成后重启服务：

openclaw restart

到飞书群里 @机器人 发一条消息测试。如果机器人没有反应，先看日志：

openclaw logs --follow

日志里能看到飞书事件是否推到了 OpenClaw。最常见的失败原因是 App Secret 复制不完整，或者机器人没有发布上线，应用权限还没生效。记住：飞书自建应用改完配置需要在开放平台后台点"发布版本"，否则线上版本还是旧的。

6.3 飞书输出截断的根因分析

"OpenClaw 在飞书输出容易被截断"这个问题，社区里已经被问滥了。我相信不少人踩过这个坑：Agent 在 cli 里回答得好好的，到了飞书群里，长回复总是话说到一半就没了，也没有报错提示。

根因不在 OpenClaw 的推理过程，而在飞书的消息体限制。飞书机器人单条消息的文本长度上限大约是 3 万字节，中文字符在 UTF-8 编码下占 3 字节，所以实际能发出去的中文大约 1 万字左右，再长就会被飞书自动截断。

而 OpenClaw 默认会尝试把 Agent 的完整回复一次性发出去，特别是启用了 Markdown 格式输出时，表格、代码块这些都会额外占用字节数，于是长回复被飞书服务端直接砍掉，看起来就是"输出被截断"。

6.4 截断问题的修复方案

修复方式有两个层面。第一个层面是真正的修复，开启自动分块输出：

channels: feishu: enabled: true chunk_output: true max_msg_len: 28000 msg_splitter: sentence

chunk_output: true表示超长回复自动拆成多条消息发送，msg_splitter: sentence表示按句子边界拆，避免一段文字从中间被切断。改完重启，长回复就会变成连续多条消息发出来，内容完整不丢失。

第二个层面是思路上的规避。如果 Agent 经常要输出超长内容，我建议在 Agent 的系统提示词里加上输出约束，比如"回答控制在 500 字以内，如果需要展示细节，用分点列表而不是长段落"。这样既降低被截断的概率，也强制 Agent 提高回答的凝练度，实际使用体验反而更好。

飞书对 Markdown 表格的兼容性也比较有限，如果你发现表格格式在群里渲染异常，把output_format改成text可以绕过大部分格式问题。

7. 高频报错排查：session file locked 的完整链路

7.1 session file locked 的现场还原与排查步骤

这个报错值得单独用一个章节来讲，因为它是 OpenClaw 社区被搜索频率最高的错误，完整报错是：

agent failed before reply: session file locked (timeout 60000ms)

按我的经验，这个报错 80% 的情况都不是配置写错，而是会话锁文件没有被正确释放。完整的排查链路如下。

第一步，检查有没有多个 OpenClaw 进程同时运行。如果你之前用openclaw serve起过一个实例，后来又用 systemd 或 Docker 起了一个，两个进程同时访问同一个 session 目录，锁冲突几乎是必然的。Windows 下打开任务管理器看openclaw进程数量，Linux 下执行：

ps aux | grep openclaw

如果有多余进程，全部停掉，只保留你计划使用的那一个。

第二步，检查 session 目录下有没有残留的锁文件：

ls -la ~/.openclaw/sessions/*.lock

正常情况下锁文件在请求结束后自动删除，如果看到.lock文件躺在那，多半是上一次请求时进程崩溃，锁没来得及释放。把这些残留锁文件手动删掉：

rm -f ~/.openclaw/sessions/*.lock

第三步，检查目录权限。如果 OpenClaw 是以 root 身份启动过，生成的会话文件和锁文件属于 root，之后再用普通用户启动，进程没有权限删除锁文件，就会一直等到超时。遇到这种情况，把整个.openclaw目录归属改回当前用户：

sudo chown -R $USER:$USER ~/.openclaw

第四步，排查共享存储。如果你把.openclaw放在了 NFS 这类网络共享文件系统上，网络文件系统的文件锁语义和本地文件系统不一致，OpenClaw 的锁机制很容易失效。这种场景下，把 session 目录挪回本地磁盘是最省心的方案。

第五步，如果以上都排除了，仍频繁出现锁冲突，可以适当调大锁超时时间。在配置文件里：

session: lock_timeout: 120000

把 60000ms 调成 120000ms，给长时间运行的工具调用留更多余量。

这个报错给我们的教训是：session 锁机制本质是保护数据一致性，但异常崩溃留下的锁文件必须及时清理。养成每次启动前看一眼 session 目录的习惯，能省去很多排错时间。

7.2 其它高频报错与解决办法

除了 session file locked，我把部署阶段遇到的高频报错整理成一个速查表：

context length exceeded也很常见，特别是用轻量模型跑长会话时。OpenClaw 默认保留最近若干轮对话作为上下文，如果 Agent 长期跑同一个会话，历史消息会累积到超出模型的上下文窗口。碰到这种情况，开一个新会话，或者在配置里调整上下文保留策略，比硬着头皮继续聊更实际。

8. OpenClaw 与 WorkBuddy 对比 + 部署后的调优经验

8.1 开源自由与开箱即用怎么选

社区里另一个高频问题就是"OpenClaw 和 WorkBuddy 哪个好"。这两个产品走的是完全不同的路线，放在一起比的其实是两种使用哲学的取舍。

我的结论是：如果你本身有技术基础，或者公司对数据安全有要求，OpenClaw 是唯一合理的选择，数据不出内网这个点在国内企业场景里价值极大。如果你只是想让业务同事快速用起来，且不介意模型绑定，WorkBuddy 的开箱即用确实省时间。但注意一点，一旦你的使用规模上来，商业 SaaS 的按量收费和模型切换成本都会变成约束，反而是 OpenClaw 这种自托管的方案可以长期控成本。

8.2 部署后的性能调优清单

最后分享一份我部署生产环境时的调优清单，每一项都是经过实际验证的：

第一，并发控制。默认 Agent 串行处理请求，如果你同时接入多个渠道，可以开启并发：

agent: max_concurrency: 4

设置太高容易触发模型 API 限流，我建议从 2 开始观察，稳定再往上加。

第二，工具调用超时。部分工具执行慢会拖垮整个 Agent 的响应，给工具调用单独设置超时：

tool: timeout: 30

超过 30 秒的工具调用直接判失败，释放会话锁，避免请求堆积。

第三，日志轮转。长期运行日志文件会非常大：

logs: rotate_size: 50MB retain_days: 14

超过 50 MB 自动切割，保留 14 天，磁盘压力小很多。

第四，例行体检。把openclaw doctor和openclaw stats加进自己的例行操作，每两周跑一次，观察内存和调用量变化，很多小问题在变成事故前就能发现。

最后再分享一条个人经验。部署 OpenClaw 这件事，最忌讳的就是一开始就想把全功能配齐，模型五六个、渠道七八个、插件装一堆，最后任何一个环节出问题，排查成本都远超收益。我的做法是先搭一个最小系统：一个模型（DeepSeek V4）、一个渠道（飞书）、一个 Agent，跑通核心链路后再逐步扩展。等你对配置和报错模式都熟悉了，再放开手脚加模型、加渠道，那时候你会发现自己已经不怎么需要看教程了。