先交代个背景方便你判断这篇值不值得读完。OpenClaw 这个开源项目我从它两万星的时候就在盯着2026 年开年直接冲到 25 万星GitHub Trending 连续霸榜好几周社区里已经有人拿它跑完整的数字员工业务。但我后台收到最多的求助还是老三样装不上、配不好、接完模型不回复。原因其实不复杂——官方 wiki 默认读者有 Agent 框架基础一篇教程里塞了几十个命令新手分辨不清哪些是必须的哪些是绕路。这篇教程我按部署前要搞懂什么 → 怎么装 → 怎么接 DeepSeek V4 → 怎么接通义千问 3.5 → 怎么选 Channel → 怎么修高频报错的顺序来写。你不需要有 Agent 开发经验只要会敲命令、会复制粘贴配置文件就能跟着跑通。文里所有步骤都是我在 Windows 和 Linux 两台机器上实际执行过的报错环节也附了完整排查思路。1. 拆解 OpenClaw25 万星项目到底解决了什么问题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 框架自身有本地运行时要做工具调度、会话存储、日志处理这部分仍然需要一定的系统资源。项目最低要求推荐配置说明CPU2 核4 核及以上并行处理多个渠道消息时需要多核内存4 GB8 GB主要给运行时和本地缓存用磁盘5 GB 可用空间20 GB SSD会话记录和日志会逐渐增长系统Windows 10 1809Windows 11 / Ubuntu 22.04Linux 下运行更稳定运行时Python 3.10 - 3.12与安装包捆绑windowshub 安装无需单独配最容易被忽略的是磁盘空间。会话历史默认全部落盘跑一个月高强度使用日志和 session 文件加起来可能超过 2 GB装之前确认下系统盘剩余空间。2.2 配置目录所有关键数据都在 ~/.openclawOpenClaw 的配置和数据统一放在用户主目录下的.openclaw文件夹里Windows 上是%USERPROFILE%\.openclawLinux 上是~/.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 doctordoctor 会逐项检查环境和配置常见检查项包括检查项说明失败时的处理运行时版本Python/运行时是否符合要求重新执行安装脚本配置文件语法config.yaml 能否被正确解析检查 YAML 缩进目录权限.openclaw是否可读写执行 chown/chmod网络连通性能否访问 API 端点检查网络与 DNS端口占用Web 服务端口是否被占用释放端口或改配置我见过不少人跳过 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_urlAPI 的入口地址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 鉴权与调用报错速查对接过程中最容易碰到下面这些报错我按频率排序报错现象根本原因处理方式401 UnauthorizedAPI Key 错误或已失效重新复制密钥检查前后空格402 Payment Required账户余额不足到平台充值404 Model Not Found模型 ID 与平台标识不符核对平台文档的模型标识429 Too Many Requests触发限流降低并发或用 deepseek-v4 而不是 pro500 Internal Server Error服务端临时故障等待几分钟重试这里额外说一句 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: sentencechunk_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我把部署阶段遇到的高频报错整理成一个速查表报错信息原因解决config parse errorYAML 缩进或格式错误用 YAML lint 校验检查 Tab 与空格connection timeoutAPI 端点不可达检查 base_url 和网络连通性context length exceeded会话历史超过模型上下文清空会话或调低保留轮数channel not ready渠道配置未完成检查对应渠道的 token/密钥plugin load failed插件和版本不兼容停用插件或升级版本context length exceeded也很常见特别是用轻量模型跑长会话时。OpenClaw 默认保留最近若干轮对话作为上下文如果 Agent 长期跑同一个会话历史消息会累积到超出模型的上下文窗口。碰到这种情况开一个新会话或者在配置里调整上下文保留策略比硬着头皮继续聊更实际。8. OpenClaw 与 WorkBuddy 对比 部署后的调优经验8.1 开源自由与开箱即用怎么选社区里另一个高频问题就是OpenClaw 和 WorkBuddy 哪个好。这两个产品走的是完全不同的路线放在一起比的其实是两种使用哲学的取舍。对比维度OpenClawWorkBuddy开源属性MIT 协议完全开源可自托管商业闭源以 SaaS 为主模型接入支持十几个模型提供方自由路由主推接入自家绑定的几家模型部署位置数据完全在自己机器上数据经过云平台界面体验CLI Web 面板朴素但灵活图形化界面精致上手快二次开发插件机制 开放 API仅支持低代码流程编排适合人群开发者、注重数据自主的团队不想折腾配置、要快速见效的团队我的结论是如果你本身有技术基础或者公司对数据安全有要求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跑通核心链路后再逐步扩展。等你对配置和报错模式都熟悉了再放开手脚加模型、加渠道那时候你会发现自己已经不怎么需要看教程了。
