OpenClaw 飞书多机器人与多 Agent 落地复盘

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

日志里看起来像失败，但最后版本号能查到：

openclaw --version # 2026.2.24

这类场景里，我更看重最终状态而不是中途 warning。安装脚本在 Windows 上的噪音比你想象得多。

另一个常见问题是 Gateway 状态异常：Scheduled Task (missing)，或者 openclaw gateway probe 报 1006、RPC 失败。这个时候先别急着修配置，直接前台跑起来看进程本体：

openclaw gateway run --verbose 

看到 listening on ws://127.0.0.1:18789，说明 Gateway 主进程是活的。很多时候问题不在服务本身，而在系统任务没挂上。

还有一个 Windows 特有的坑：

openclaw gateway run --force --verbose 

会报：

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

这个就别硬拗了。Windows 没有 lsof，直接不用 --force，改回普通启动即可：

openclaw gateway run --verbose 

PATH 也经常出问题。先查：

macOS / Linux：

npm prefix -g && echo "$PATH"

Windows（PowerShell）：

npm prefix -g; $env:Path 

修法也简单：macOS / Linux 把 $(npm prefix -g)/bin 加进 PATH，Windows 把 npm prefix -g 输出目录加到系统 PATH。这个步骤看起来琐碎，但命令找不到的时候，它就是第一嫌疑人。

接入飞书：先通渠道，再做配对

插件先装上：

openclaw plugins install @openclaw/feishu 

然后加渠道：

openclaw channels add

按提示选 Feishu，填飞书开放平台里的 App ID 和 App Secret。之后重启并检查网关：

openclaw gateway restart openclaw gateway status openclaw logs --follow

飞书里第一次私聊机器人，通常会返回一段配对提示，大意是：

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 一一绑死。

角色是这 6 个：

1. 总控，也就是产品经理
2. 技术开发
3. 测试质保
4. 代码评审，负责架构把关
5. 文档与知识库维护
6. 发布运维

路由逻辑不是'一个默认 Agent 顶到底'，而是按渠道账号精确分发：

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

dev / qa / review / docs / ops 也分别对应各自的 Agent。这样做的好处很直接：职责清楚，调试也不会串台。

验证时可以一起看状态、绑定和 Agent 列表：

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 自测正常，到了飞书里却突然答成了默认身份。

排查后通常是两类原因：一类是路由没命中，实际还是走了 main；另一类是 Agent 的身份文件还停留在模板状态，角色没有真正固化。

修复动作基本是这几个：

1. 看渠道日志里的 dispatching to agent (session=...)
2. 核对 bindings 是否真的按 channel + accountId 命中
3. 在对应工作区里写清楚 IDENTITY.md
4. 在 AGENTS.md 里加身份锁定规则
5. 必要时重启 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 

我这次的取舍

如果准备做类似的团队化机器人，我会先把单机器人闭环跑通，再扩到多机器人。每加一个角色，就立刻做配对、路由和身份自检，不要等到最后一次性验收。身份定义最好写进工作区文件，别只靠口头约定；日志检查也最好固定成一套动作：status -> probe -> logs -> bindings。

模型策略也别图省事全员同模。角色不同，模型就该分开，不然最后是大家都能说，但没人真正适合干活。

结尾

这次真正跑通的不是'把机器人接上'这么简单，而是把安装、排障、路由、分工、模型和身份这几层都串起来了。能安装、能排障、能路由、能分工、能稳定运营，OpenClaw 才算从'能聊天'走到了'能协作干活'。

参考来源

• https://docs.openclaw.ai/zh-CN/install
• https://docs.openclaw.ai/zh-CN/channels/feishu