孔小哥OpenClaw 装好之后，大部分人做的第一件事不是去研究模型参数，而是想把微信接进来。原因很直接：模型和命令行界面离生活太远，只有在微信里随手发一句话、立刻得到 AI 回复，才是大多数人认知里“AI 助理”该有的样子。这篇文章就围绕 OpenClaw 安装微信 ClawBot 这件事，把这套流程完整拆开。内容包括底层原理、两种微信接入路线的差异、企业微信后台配合 OpenClaw 的配置过程、模型绑定时的经典报错，以及 exec-approvals.json 和 Control UI 这两类你最可能碰到的运行期问题。适合刚开始接触 OpenClaw、想尽快把一个能聊天的微信机器人跑起来的人，也适合那些已经部署过却卡在各种日志报错里的人。我在 Linux 服务器和 Windows 机器上都实际跑过，文里会尽量把环境差异也讲清楚。
1. 动手前先确认三个关键选择：账号类型、运行环境、模型入口
从零开始安装微信 ClawBot，最容易犯的错误是直接搜索安装命令然后照着敲，敲到一半才发现自己连最基础的方向都没确认。实际上有三件事必须在动手装之前就想明白，它们会影响后面每一个配置项到底填什么。
1.1 你想接入的到底是个人微信还是企业微信
ClawBot 是一个统称，它指的是 OpenClaw 面向微信生态消息通道的机器人入口。微信侧其实可以拆成个人微信和企业微信两条完全不同的接入路线，但两条路线的稳定性、合规性和配置成本差得非常多。
个人微信路线的特点是上手极快。OpenClaw 安装好之后，如果你选择个人微信的通道适配器，启动时屏幕会打印一个二维码，拿一个用于测试的小号扫一下，消息就能被转发给 AI 代理。适合临时验证功能，也适合自己一个人玩玩。但它归根结底依赖非官方登录方式，本质上是让普通微信号充当消息收发器，所以会持续面临平台风控、登录态失效、接口调整等一系列问题。
企业微信路线则完全不同。它走的是企业微信官方应用接口，服务商开放平台会提供固定的应用凭证和回调机制。配置过程比个人微信多一点，需要在管理后台创建应用、配置回调 URL、拿到 CorpId、AgentId、Secret 这些信息，但一旦接好，稳定性高得多，也适合多人使用。
我自己的判断是：追求长期可用就一开始走企业微信，个人微信只用来做 30 分钟内的连通性测试。很多社区里的人把一个主力微信号长年挂在机器人上，某天突然被限制登录，整个服务就瘫痪了，那种体验很不值得。还有一个容易被忽略的点：如果未来你想把同样的机器人能力开放给别人用，个人微信根本无法跨账号，企业微信则天然支持企业内多人访问。
所以你在看下面所有步骤前，先回答自己一个问题：这个 ClawBot 是长跑还是临测。临测就选个人微信小号，长跑就选企业微信。
1.2 机器选本机还是 7×24 服务器
确定账号类型后，第二个选择是运行环境。很多人一开始图省事，把 OpenClaw 装在日常办公用的 Windows 笔记本上，然后发现两个问题：一是电脑一关机，微信机器人就失联；二是企业微信回调到本地时，需要本机始终保持网络可达，这在实际办公环境里很难做到。
我的建议是：只要想让 ClawBot 在手机上随时能用，就一开始就部署到一台 7×24 运行的 Linux 服务器上。原因不只是开机时间，服务器还有固定公网 IP、更稳定的网络环境和更少被系统自动睡眠打断的可能。企业微信的 Webhook 回调天然需要公网可达地址，本地回调配置起来很容易在验证阶段卡住。如果只是局域网内测试，Windows 本机也不是不行，但要意识到后面每做一步都可能被网络环境绊一下。
1.3 模型入口：云 API 还是本地模型
第三个选择容易被忽略，它会直接决定后面怎么配置。ClawBot 本身不包含“智能”，它只是把微信消息转给 OpenClaw 里的 AI 代理，再由代理调用你指定的大模型来生成回复。所以装 OpenClaw 之前，手里至少要有一个可用的模型入口。
模型入口常见两类：一类是云 API，比如 DeepSeek、OpenAI 兼容接口，优点是开箱即用，缺点是需要在配置里填 API Key，且调用会产生费用；另一类是本地模型，比如通过 NVIDIA NIM 或者本地推理服务暴露一个 OpenAI 兼容接口，优点是数据不出内网、没有按量计费的压力，缺点是对机器配置要求高。
这个选择会在第 4 节反复出现。现在只需要记住一点：不要在没有任何模型凭证或本地推理服务的情况下就开始装 OpenClaw，否则装完以后你发消息给 ClawBot，它会回复一句让你完全摸不着头脑的“unknown model”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装 OpenClaw 本体并用最短路径把它跑起来
环境和方向确定后，就可以安装 OpenClaw 本体了。
2.1 安装前的依赖准备与版本选择
OpenClaw 官方提供了一键脚本，但我还是要提醒一句：OpenClaw 迭代速度很快，不同版本的配置字段和命令名称都调整过，所以一定先去看当前版本文档里的一键脚本入口。安装命令的大致形态是下面这样。
Linux / macOS 环境：
bash复制# 具体地址请以当前官方文档为准，下面只是安装形态示意
curl -fsSL https://get.openclaw.dev/install.sh | bash
Windows 环境用 PowerShell 执行：
powershell复制iwr -useb https://get.openclaw.dev/install.ps1 | iex
依赖方面，如果只是跑微信通道加一个云端 OpenAI 兼容模型，内存 4GB 的机器就很从容。如果你打算跑本地小模型，就要为推理进程额外预留内存或显存，具体看模型体积。安装前检查两件事：目录权限是否正常，以及机器上的 3000 等端口是否被占用。端口占用这个问题特别常见，后面 Control UI 起不来，一半原因都出在这。
2.2 一键脚本之后必须做的三个验证
脚本执行结束时显示“安装成功”并不代表万事大吉。我见过很多人安装完成后立刻去翻微信配置，结果卡了一整天，回头才发现是 OpenClaw 本体的某个组件没起来。所以安装完一定要做三次验证。
第一次验证版本号和环境：
bash复制openclaw --version
openclaw doctor
如果 doctor 不存在，说明你的版本分支可能不同，去看帮助里的自检命令。
第二次验证配置目录是否初始化好。OpenClaw 的所有重要状态都放在用户主目录下的 .openclaw 隐藏目录中。执行：
bash复制openclaw init
ls -la ~/.openclaw/
正常情况下，你会看到包含配置文件、workspace 工作目录、日志目录和一些后续才会出现的资源文件。workspace 目录尤其重要，AI 代理执行日常任务时产生的临时文件都在里面。
第三次验证是启动主服务并看日志。第一次启动时不要加后台运行参数，这样能直接看到标准输出里有没有报错。有些安装版本的服务启动命令是 openclaw start，有的是 openclaw serve，以你的版本帮助信息为准。
2.3 首次启动时 Control UI 和通道服务的关系
OpenClaw 启动后会拉起来几个独立的子服务。Control UI 只是其中之一，它主要提供可视化管理界面，让你在浏览器里查看任务、调整配置、观察日志。微信通道进程是另一套独立运行的东西。看到 Control UI 没起来就认为整个 OpenClaw 失败了，是比较常见的误判。
实际操作中，你完全可以先跑通微信通道，再去处理浏览器界面。Control UI 坏了不会阻断消息转发，因为你发给 ClawBot 的消息不经过它，而是直接走消息通道进 AI 代理。这个认知能帮你节省大量排查时间。
3. 微信 ClawBot 接入实操：企业微信后台到 OpenClaw 配置
如果你决定走官方接口路线，下面这段是最核心的实操部分。OpenClaw 里负责微信 ClawBot 的配置节点一般叫 channel。每个 channel 定义一种消息来源，比如微信、企业微信、钉钉、Telegram。把 channel 填好并启用，OpenClaw 启动后就会自动监听对应来源的消息。
3.1 企业微信应用的创建顺序，别把 AgentId 和 Secret 填反
第一次创建应用的人最容易在数据填写上翻车。打开企业微信管理后台后，进入“应用管理”，创建一个自建应用。创建成功后会进入应用详情页，在这里能看到 AgentId 和 Secret。还有一个 CorpId 需要从“我的企业”页面底部获取。
这里提醒三个容易搞混的点。
第一，CorpId 是企业的唯一标识，整家公司只有一个，它不是应用的 ID。第二，AgentId 是企业微信应用自己的 ID，你在 OpenClaw 配置中填的是 AgentId，不是应用 Secret 的前几位。第三，Secret 是一个很长的字符串，和应用一一对应，如果误把另一个应用的 Secret 填进来，验证阶段就会一直报签名错误。
拿到三个值之后，到应用详情页找到“接收消息”相关的配置入口，这里需要填写 URL、Token 和 EncodingAESKey。Token 可以自己生成一串随机字符，EncodingAESKey 如果企业微信后台没有自动生成，就手动生成一个 43 位字符串。OpenClaw 启动后，日志里通常会给出一条回调路径，把回调 URL 填进去即可。
3.2 OpenClaw 侧 channels 配置与回调地址自检
OpenClaw 的配置文件通常是 ~/.openclaw/openclaw.json，也可能是同名的 yaml 文件，取决于版本。少部分版本支持在启动后通过 Control UI 直接操作配置，但底层的 JSON 结构你得看懂，因为排错时绕不开它。
一个最小可用的企业微信 channel 配置类似这样：
json复制{
"channels": {
"wecom": {
"enabled": true,
"corp_id": "ww1234567890abcdef",
"agent_id": "1000002",
"secret": "在这里填应用Secret",
"callback": {
"token": "自定随机字符串",
"encoding_aes_key": "43位EncodingAESKey"
}
}
}
}
配置字段名在不同的 OpenClaw 版本中可能略有变化，但最终需要的信息就是上面这几项。
配置保存后重启 OpenClaw，到企业微信管理后台点“验证回调”。如果返回失败，先看 OpenClaw 日志里有没有收到验证请求。收不到请求，说明回调 URL 根本不可达，重点检查公网访问路径和端口放行；收到了但校验失败，则优先检查 Token 和 EncodingAESKey 是否与配置一致。
提示：回调 URL 必须是公网可达的 HTTP 或 HTTPS 地址。很多人把 OpenClaw 装在家里或办公室电脑上，填写 URL 时用了 localhost 或者局域网 IP，企业微信服务器自然无法访问，验证就会一直卡住。这是该环节最常见的失败原因。
3.3 个人微信“小号扫码”路线：只建议测试不建议生产
我没有在这篇文章里展开个人微信的完整接入配置，因为它涉及绕开官方登录机制的方案，实际使用中有账号风控风险。OpenClaw 社区里会有相关的实验性适配器，启动后通常会为了扫码登录提供一个人机验证交互。测试时务必遵守两条原则：一是只用你准备丢弃的小号，绝不要把日常主力微信号挂上去；二是只做连通性验证，不要基于这种模式搭建面向他人的服务。
另外提醒一点，个人微信消息格式、图片、语音等内容的处理逻辑和企业微信完全不同，如果你后续要扩展文件收发能力，尽早切换到官方接口路线会更省心。
一切配置完成并验证通过后，给企业微信应用发一条消息试试。正常情况下，OpenClaw 日志中会出现消息推送记录，ClawBot 识别到消息后会交给 AI 代理处理。如果消息能收到但 AI 没回话，问题大概率出在第 4 节的模型配置上。
4. 把模型接回微信：unknown model 与 API 配置不一致的修复经验
微信通道通了，ClawBot 也收到了消息，结果它没有回复，日志里只有一行冷冰冰的 agent failed before reply: unknown model: deepseek。这是社区里出现频率最高的一个问题，尤其是使用 zero token 这类快速体验安装方式的人，几乎都会碰到。
4.1 错误发生在“第一次回复前”意味着什么
这句话的关键不是 “agent failed”，而是 “before reply”。它告诉我们：消息已经成功进入 AI 代理流程，中途没有任何优先级问题，模型调用这一步失败了。也就是说，微信通道是健康的，问题被隔离在模型配置层面。
模型调用失败最常见的原因是 OpenClaw 配置里的默认模型名，和实际模型供应商提供的模型名不一致。举例来说，你在配置里写的是 deepseek，但 DeepSeek API 实际暴露的模型名可能是 deepseek-chat 或者某个带日期版本的推理模型名。OpenClaw 会拿着这个名字去供应商的模型列表里比对，比不到就报 unknown model。
4.2 以 DeepSeek 为例梳理 provider / model 两层配置
OpenClaw 的模型配置通常是两层结构：provider 和 model。provider 定义“去哪个服务商调用、用什么 API 地址、读哪个环境变量里的密钥”；model 定义“默认使用这个 provider 下的哪个模型”。
一个常见的 DeepSeek 接入配置长这样：
json复制{
"providers": {
"deepseek": {
"base_url": "https://api.deepseek.com/v1",
"api_key_env": "DEEPSEEK_API_KEY",
"models": ["deepseek-chat", "deepseek-reasoner"]
}
},
"agent": {
"default_model": "deepseek-chat",
"provider": "deepseek"
}
}
配置时先把环境变量设好：
bash复制export DEEPSEEK_API_KEY="你的API Key"
然后重启 OpenClaw 再试。我遇到的那种日志报错，本质上就是因为 default_model 写成了模型供应商不认识的别名。填不确定时，先查一下该供应商的文档，确认模型列表里到底叫什么。
如果你是快速安装模式且本意是接入 DeepSeek，还有一个隐蔽问题：安装时环境变量没有正确注入，导致 provider 的 API Key 是空的。此时日志可能不会直接提示 key 缺失，而是绕一圈报成一个不好理解的错误。处理方式是在启动 OpenClaw 的终端里先确认环境变量真的存在。
4.3 本地模型入口怎么接：NVIDIA NIM 和 OpenAI 兼容协议
如果你想把模型完全放在本地跑，就不用填云服务商 key，而是把 provider 指向本地推理服务。OpenClaw 对 OpenAI 兼容协议支持得比较好，本地只要有一个暴露 OpenAI 风格 API 的推理服务，它就能当 provider 使用。
以 NVIDIA NIM 为例，NIM 在本地启动后一般会暴露一个 http://127.0.0.1:8000/v1 这样的接口。OpenClaw 里增加一个 provider：
json复制{
"providers": {
"local_nim": {
"base_url": "http://127.0.0.1:8000/v1",
"api_key_env": "NIM_API_KEY",
"models": ["meta-llama-3.3-70b-instruct"]
}
},
"agent": {
"default_model": "meta-llama-3.3-70b-instruct",
"provider": "local_nim"
}
}
NIM 如果部署在同一台机器上，就不需要复杂的网络配置，直接用回环地址就行。要注意的是，本地推理服务的并发能力有限，当微信群里多个消息同时进来时，请求会被排队，反馈速度远不如云 API。如果是多人使用场景，我建议云 API 和本地模型并用，让 ClawBot 支持多模型路由：日常闲聊走延迟更低的轻量模型，复杂任务才切到更大的本地模型。
模型这一层调通后，ClawBot 才真正具备“对话能力”。但不要高兴得太早，OpenClaw 的 AI 代理不只是聊天，它还能操作 shell、读写文件。接下来这个配置如果不处理，等于把一个能执行命令的入口直接暴露给了消息来源。
5. 升级后弹出的 exec-approvals.json 迁移提示：先读懂再执行
很多人在 OpenClaw 升级后第一次启动时，会看到这样一行日志：
code复制legacy exec approvals exist at /root/.openclaw/exec-approvals.json.
run `openclaw migrate approvals` to migrate them to the new format.
有些人直接忽略了，结果 AI 代理执行命令时发现原有授权全部失效；有些人又太着急，看都不看就跑了迁移命令，把危险命令的授权也带到了新版本。这两种处理方式都有问题。
5.1 OpenClaw 凭什么拦截你的命令
exec-approvals.json 是 OpenClaw 的执行审批文件。所谓 exec，就是 AI 代理调用工具去执行外部命令。ClawBot 收到了微信消息，如果这条消息被解析为“帮助我整理目录并生成报告”，AI 代理就会尝试执行 shell 命令、读写 workspace 文件。此时 OpenClaw 会检查这条命令是否在允许名单里，如果不在，就要求人工审批。
这个机制非常重要，因为它把“AI 能做什么”和“AI 被允许做什么”这两件事拆开了。模型本身只是生成指令，真正落地到系统操作时，还需要经过权限层过滤。如果没有这个审批机制，任何一个能向 ClawBot 发消息的人，都可能诱导 AI 代理执行危险命令。
老格式的 exec-approvals.json 会把授权规则以扁平结构存起来，新版本则引入了更细的规则对象，比如区分允许、拒绝和询问三种策略。这就是迁移提示出现的原因：旧文件里的规则虽然能读，但表达兼容出了问题，需要转换成新格式。
迁移之前，我建议你先打开文件看看内容：
bash复制cat /root/.openclaw/exec-approvals.json
这个文件通常包含规则列表，每条规则会有匹配模式、策略类型和备注。如果是自己手动维护过的文件，迁移前最好备份一份：
bash复制cp /root/.openclaw/exec-approvals.json /root/.openclaw/exec-approvals.json.bak
5.2 迁移命令的完整风险和操作顺序
备份完成后，再执行日志里提示的迁移命令：
bash复制openclaw migrate approvals
如果执行后没有任何提示，可以用 openclaw migrate --help 查看可用参数，不同版本迁移命令的完整名称略有不同。迁移完成后，重新检查新文件里每条规则是否符合你的预期。
提示：如果你发现文件里都是类似删除文件、格式化磁盘、重启服务这类高危险命令的授权，迁移前先把这些规则删掉。新版本把授权策略单独成行，更利于审计，但也意味着旧的高危授权一旦被继承，反而更难被注意到。
我自己的维护习惯是让默认策略保持“询问”状态。也就是说，只要不在允许名单里的命令一律卡住，每次由我去确认。一开始会觉得烦，但跑过一段时间后，你会发现 AI 代理发出的命令频率并不高，审批一次的成本远低于误操作带来的恢复成本。尤其是 ClawBot 接入微信群后，你无法预判群成员会发出什么类型的问题，审批机制是最后一道防线。
6. Control UI did not start：一次从日志到复现的排查记录
如果你在网上搜索过 OpenClaw 的运行问题，大概率看过这行日志：openclaw control ui did not start。说句实话，这个问题本身并不难解，但因为排查时容易方向跑偏，经常把简单事情复杂化。我把自己的一次排查过程完整写出来，希望你能顺着这个思路走，而不是上来就乱重启服务。
6.1 先确认 UI 崩溃是否影响微信消息
遇到 control ui did not start，第一件事不是修 UI，而是先给企业微信应用发一条消息，看看 ClawBot 会不会回复。会回复，说明消息通道和 AI 代理运行正常，UI 只是一个附属服务挂了；不会回复，才需要把关注点移到整个 OpenClaw 主进程上。
这个判断顺序能省很多时间。我第一次遇到这个问题时，下意识以为 UI 是核心依赖，围着前端依赖排查了半天，结果发现微信消息一直能正常收发，UI 挂掉只是因为在升级过程中前端构建产物没有更新成功。
6.2 从日志到端口的排查顺序
确认 UI 单独挂了之后，按下面的顺序排查。
先用 OpenClaw 自带的日志命令看 UI 进程的实时输出。不同版本的日志命令可能是 openclaw logs 或 openclaw ui logs，具体看帮助。日志里最常见的是端口占用：
bash复制ss -tlnp | grep 3000
如果 3000 端口已被其他进程占用，OpenClaw 的 UI 服务自然无法绑定。这时需要决定是杀掉旧进程，还是修改 UI 的端口配置。我遇到过一个情况，某个旧版 OpenClaw 的 UI 进程残留了，新版本启动后一直报端口冲突，杀掉旧进程后立刻正常。
端口没问题，再查 UI 依赖。OpenClaw 的 Control UI 通常依赖 Node 运行时，如果系统里 Node 版本太低，UI 构建时就会中断。这时打开 OpenClaw 的详细日志，能看到具体是哪一个依赖加载失败。针对性升级 Node 或者重装依赖就能解决。
依赖没问题，再看浏览器缓存。有时候服务其实已经起来了，只是本地浏览器缓存了旧的静态页面，造成 UI 没启动的错觉。换成无痕窗口访问一次，或者清掉浏览器缓存，现象就会消失。
6.3 恢复手段与“不要动不动重启”的教训
如果上面都查了还是起不来，最后的手段才是重启 UI 进程。OpenClaw 多数版本支持单独重启 UI 服务，不用重启整个主服务。运行类似这样的命令前先看帮助确认存在该参数：
bash复制openclaw ui restart
如果你找不到单独的 UI 服务管理命令，再选择重启整个 OpenClaw。但我必须强调一个教训：不要因为一条 UI 报错就立刻重启整个服务。在微信群场景中，重启意味着短暂消息丢失，如果你的 ClawBot 正在处理一个长任务，重启还可能打断任务的执行状态。每一次重启前，先估算一下中断成本。
Control UI 本质上是一个可观测系统。它能让你看清楚 AI 代理每一步在做什么、调用了哪些工具、产生了多少 token。UI 挂掉虽然不影响消息收发，但会让你变成“盲人摸象”——任务跑失败了却看不到内部过程。所以我仍然建议修好它，但要用最小范围操作去修。
7. 跑满一周之后，我建议补上的三个长期配置：限流、会话隔离、Skill
ClawBot 刚接通的前两天，你大概率会觉得很新鲜。新鲜感退了之后，它开始暴露一些真实使用中的问题：微信群里的消息可能造成刷屏、AI 代理在不同会话间把上下文串了、同样的问题反复问却没有积累。以下三个配置是我对稳定性要求较高的项目建议补上的。
7.1 给消息源加限流
一旦把 ClawBot 拉进一个活跃的微信群，消息洪峰是真实存在的。群成员一人一句，AI 代理可能同时收到几十条消息，如果每条都触发大模型调用，首先反应慢，其次费用飙升，极端情况下还可能被模型服务商限流。在 OpenClaw 的 channel 或代理配置中，通常会提供类似每用户每分钟最大消息数、全局并发数这样参数。先把全局并发数限到一个模型服务商能承受的数值，再给单用户设频率上限。限流对用户侧的观感影响很小，最多就是机器人回复节奏稍慢，但能避免服务雪崩。
7.2 群聊与私聊的会话隔离
ClawBot 天然支持多个会话源，问题是有不少版本默认按联系人区分会话上下文，却没自动区分“同一个群里的不同主题”。如果你的 ClawBot 服务一个企业微信群，群成员 A 问技术方案时上下文里残留了成员 B 的闲聊，答案质量就会变得很奇怪。
解决办法是在代理配置里按来源类型定义不同会话策略：私聊可以保持较长上下文，适合连续深度对话；群聊则缩短上下文窗口，甚至每次只取最近几条消息。这样既能保证多轮对话的效果，也避免群聊里不同人的提问互相污染。这类配置通常体现在 session 或 memory 策略参数里，具体名称需看版本文档。
7.3 用 Skill 把高频指令固化成可复用能力
OpenClaw 的 Skill 机制值得好好利用。它的核心思想是，把描述清楚的一段指令、对应的工作流、需要的外部工具整合成一个可复用的技能包。举个例子，如果你经常让 ClawBot 汇总每日待办，与其每次发一条长篇指令，不如创建一个 Skill：让代理先读取指定文档，再按固定模板生成摘要，最后发回微信群。Skill 的日常维护也很简单，一般是在 .openclaw 目录下的 skills 文件夹里加一个子目录，里面用描述文件声明触发条件，再加一个指令文本。配置完成后，在微信里发一句带技能关键词的话，ClawBot 就会自动走对应流程。
技能包的价值是减少重复性 token 消耗。每次都用长指令驱动模型，实际上是在浪费上下文窗口；把固定流程固化成 Skill 之后，代理只需要传入少量变化参数，不仅更省，回复质量也更稳定。
这三项配置做完，ClawBot 才算从一个“能聊天的测试机器人”变成真正可托付日常任务的工具。我在整个接入过程中最大的体会是，ClawBot 这类项目的前期难点往往不在微信登录或界面花哨，而在怎么把一个消息入口、一个模型入口和一个受限的执行环境安全地串起来。先把第 3 节的通道跑通，再处理第 4 节的模型，接着认真对待第 5 节和第 6 节的运维问题，你的 ClawBot 大概率能比大多数人跑得更久、更稳定。