OpenClaw 多飞书机器人与多 Agent 协作落地记录

Windows（PowerShell）：

npm prefix -g; echo $env:Path

修法也很直接：macOS / Linux 把 $(npm prefix -g)/bin 加进 PATH，Windows 把 npm prefix -g 输出的目录加进系统 PATH。

控制台可以直接打开看看：

openclaw dashboard

一般会落在 http://127.0.0.1:18789/。

Feishu 接入不要拖太久，安装完就做，不然后面会出现'本地能跑，渠道不通'的假象。

先装插件：

openclaw plugins install @openclaw/feishu

再加渠道：

openclaw channels add

选择 Feishu，填入飞书开放平台里的 App ID 和 App Secret。

然后重启并观察日志：

openclaw gateway restart openclaw gateway status openclaw logs --follow

飞书里第一次私聊机器人后，会拿到配对码，再审批：

openclaw pairing list feishu --json openclaw pairing approve feishu <配对码>

到这里，安装、网关、渠道、配对才算闭环。

npm error code 1

Windows 安装时一开始碰到过这个报错：

iwr -useb https://openclaw.ai/install.ps1 | iex

表面上看是 npm error code 1，但继续往下查日志，安装最后还是成功了，版本也能查到：

openclaw --version # 2026.2.24

这类问题我一般不会先被中间报错带跑，先看最终状态能不能落地，很多安装脚本本来就会有一段脏输出。

Gateway 状态异常

另一类问题是 openclaw gateway status 显示服务缺失，同时 openclaw gateway probe 报 1006 或 RPC 失败。

这时候我更愿意先把主进程拉起来看：

openclaw gateway run --verbose

只要日志里出现 listening on ws://127.0.0.1:18789，就说明 Gateway 本体能跑，剩下的就是服务注册、任务调度或者历史状态残留的问题。

Windows 下 --force 报 lsof not found

这里也踩到一个很典型的平台差异：

openclaw gateway run --force --verbose

报错是：

Force: Error: lsof not found; required for --force

Windows 没有 lsof，所以这里别硬拧，直接去掉 --force：

openclaw gateway run --verbose

模型连通和会话参数

Agent 命令一开始也不是顺的。

下面这种写法会报错，因为少了会话定位参数：

openclaw agent -m "你好，做一次连通性自检并简短回复"--json

改成带 --agent 就正常了：

openclaw agent --agent main -m "你好，请回复：连通测试通过"--json

还有一种提示是：

Gateway agent failed; falling back to embedded

这不等于失败。我的判断标准很简单：最终 JSON 里有没有 status: ok，有就说明这次请求真的跑通了。

Feishu 配对机制

飞书第一次私聊机器人时，通常会收到类似这样的消息：

OpenClaw: access not configured. Your Feishu user id: ou_xxx Pairing code: XXXXXXXX Ask the bot owner to approve with: openclaw pairing approve feishu XXXXXXXX

审批命令有两种常见写法：

openclaw pairing approve feishu <配对码>

或者按账号审批：

openclaw pairing approve --channel feishu --account <accountId> <配对码>

这里有个细节挺容易误判：有些请求在全局 feishu 队列里能看到，但在 --account 过滤下可能是空的。出现 No pending pairing request found 不一定是真失败，很多时候只是配对码已经被消费了。最稳的做法还是先查：

openclaw pairing list feishu --json

多机器人和多 Agent 团队

这部分才是整个实践里最有意思的地方。我们最后做了 6 个飞书机器人，分别绑定到不同角色。

角色拆分是这样的：

• 总控，也就是产品经理
• 技术开发
• 测试质保
• 代码评审
• 文档与知识库维护
• 发布运维

真正关键的不是'有很多 Agent'，而是路由要按账号精确命中。比如：

{"agentId":"pm-agent","match":{"channel":"feishu","accountId":"pm"}}

dev、qa、review、docs、ops 也按同样方式分别绑定。

验证时我会直接看这些命令：

openclaw channels status --json --probe openclaw config get bindings --json openclaw agents list --json

重点不是命令跑了没，而是三件事有没有同时成立：

• 每个目标账号的 probe.ok = true
• bindings 里能看到 accountId -> agentId
• 各 Agent 能独立响应

模型分工

默认情况下，团队主体用的是：

• openai-codex/gpt-5.2

但文档 Agent 我单独切到了：

• ollama/gpt-oss:20b-cloud

这个取舍很实用。模型能力和任务类型不是一回事，把模型选择下沉到具体 Agent，比全局统一配置更省心。好处也比较直接：成本更好控，职责更清楚，某个 provider 出问题时影响面也更小。

机器人自称错角色

实际最让人警惕的一类问题，是机器人'说错自己是谁'。

我在终端里测 pm-agent 是正常的，但飞书里它却答成了默认小爪。排查下来，通常就两种原因：

1. 路由没有命中目标 Agent，实际进了 main
2. Agent 身份文件只是模板，还没有真正固化

对应的修复动作比较朴素，但有效：

• 看渠道日志里的 dispatching to agent (session=...)
• 检查 bindings 是否真的匹配 channel + accountId
• 在该 Agent 工作区里写清楚 IDENTITY.md
• 在 AGENTS.md 加身份锁定规则
• 必要时重启 Gateway，清掉旧进程缓存

常用运维命令

服务和连通性：

openclaw gateway start openclaw gateway status openclaw gateway probe openclaw channels status --json --probe

Agent 调试：

openclaw agent --agent pm-agent -m "你是谁？只回复名称。" openclaw agent --agent dev-agent -m "你是谁？只回复名称。" openclaw agent --agent review-agent -m "你是谁？只回复名称。"

配对和审批：

openclaw pairing list feishu --json openclaw pairing approve feishu <配对码> openclaw pairing approve --channel feishu --account ops <配对码>

启停：

openclaw gateway stop openclaw gateway restart

我这边的落地建议

如果准备自己搭一套类似的团队，我会先从最小闭环开始，不会上来就铺 6 个机器人。单机器人先跑通，再扩到多机器人，排障压力会小很多。

每新增一个机器人，就马上做三件事：配对、路由、身份自检。这个节奏很土，但省时间。

还有一点比较重要：身份定义不要只停留在口头约定，最好写进工作区文件里。否则机器人今天像产品经理，明天像默认助手，排查起来很烦。

日志检查也别临时想起来才看，固定成一套动作会更顺：status -> probe -> logs -> bindings。

模型策略最好按角色拆，不要图省事把全员都丢到同一个模型里。短期看简单，后面分工一复杂，维护成本会反过来咬你。

结尾

这次实践真正跑通的，不只是'机器人能说话'，而是能安装、能排障、能路由、能分工、能稳定运转。把渠道账号、Agent 角色、模型策略、身份文件和日志验证这几件事放到一条线上，OpenClaw 才算从聊天工具变成了可协作的生产系统。