OpenClaw 多机器人多 Agent 怎么配?一篇讲清 Telegram 机器人绑定方案

OpenClaw 多机器人多 Agent 怎么配？一篇讲清 Telegram 机器人绑定方案

很多人第一次配 OpenClaw，会把“多机器人”和“多 Agent”混在一起，结果就是：机器人是建了，Agent 也建了，但消息就是不按预期走。

这篇我直接用一套统一脱敏后的示例配置，把最关键的几件事讲透：

怎么接入多个 Telegram 机器人
怎么创建多个 Agent
怎么把不同机器人稳定绑定到不同 Agent
为什么一定要把 workspace 分开
哪些地方最容易配错

你可以把它理解成一个最稳、也最容易扩展的配置模板。

1. 先看最终结构：你到底要配成什么样

Agent 列表

当前有 3 个 Agent：

agent_general
agent_content
agent_pm

Workspace 对应关系

agent_general → /path/to/openclaw/workspace-general
agent_content → /path/to/openclaw/workspace-content
agent_pm → /path/to/openclaw/workspace-pm

Telegram 机器人 accountId

tg_general_bot
tg_content_bot
tg_pm_bot

绑定关系

tg_general_bot → agent_general
tg_content_bot → agent_content
tg_pm_bot → agent_pm

2. 配置核心思路：一台机器人，不要抢多个脑子

这套方案最核心的逻辑，其实就一句话：

一个 Telegram 机器人，对应一个 accountId；一个 accountId，对应一个 Agent；一个 Agent，最好对应一个独立 workspace。

拆开来看就是 4 步：

先创建多个 Agent
每个 Agent 尽量使用独立 workspace
在 channels.telegram.accounts 下面配置多个 bot
在 bindings 里按 accountId 把消息路由到指定 Agent

3. 第一步：先把 Agent 结构建好

先别急着配 Telegram。更稳的顺序是，先把 Agent 这一层搭好。

配置文件里的 agents.list 可以长这样：

"agents":{"defaults":{"model":{"primary":"kimi/kimi-code","fallbacks":["openai-codex/gpt-5.4"]},"workspace":"/path/to/openclaw/workspace-general"},"list":[{"id":"agent_general","model":"openai-codex/gpt-5.4"},{"id":"agent_content","workspace":"/path/to/openclaw/workspace-content","agentDir":"/path/to/openclaw/agents/agent_content/agent"},{"id":"agent_pm","workspace":"/path/to/openclaw/workspace-pm","agentDir":"/path/to/openclaw/agents/agent_pm/agent"}]}

这一段怎么理解？

这里最重要的不是字段多，而是你要知道哪些字段真的决定行为：

id：Agent 的唯一标识，后面的 bindings 会直接引用它
workspace：这个 Agent 的工作目录，决定它读写哪套文件
agentDir：这个 Agent 自己的配置目录
model：这个 Agent 默认跑什么模型；没写时可以继承默认值
defaults.workspace：默认 workspace，只会作用在那些没有单独声明 workspace 的 Agent 上

4. 第二步：把多个 Telegram 机器人都接进来

当 Agent 层准备好之后，再去配 Telegram 渠道。

Telegram 相关配置可以这样写：

"channels":{"telegram":{"enabled":true,"dmPolicy":"pairing","allowFrom":["<ALLOWED_USER_ID>"],"groupPolicy":"allowlist","streaming":"partial","groups":{"*":{"requireMention":true}},"accounts":{"tg_general_bot":{"dmPolicy":"pairing","botToken":"<REDACTED>","groupPolicy":"allowlist","streaming":"partial"},"tg_content_bot":{"dmPolicy":"pairing","botToken":"<REDACTED>","groupPolicy":"allowlist","streaming":"partial"},"tg_pm_bot":{"dmPolicy":"pairing","botToken":"<REDACTED>","groupPolicy":"allowlist","streaming":"partial"}},"groupAllowFrom":["<ALLOWED_USER_ID>"]}}

这一段最关键看什么？

enabled: true：启用 Telegram 渠道
accounts：多机器人配置入口，每个 key 本身就是一个 accountId
botToken：对应 Telegram 机器人的 token
dmPolicy: pairing：私聊走配对策略
groupPolicy: allowlist：群聊采用 allowlist 策略
groups["*"].requireMention = true：群里默认要 @ 机器人它才响应
allowFrom / groupAllowFrom：允许哪些发送者触发

5. 第三步：真正决定消息走向的，是 `bindings`

前面两步只是把“机器人”和“Agent”分别准备好了。

真正让它们一一对应、开始按预期工作的，是 bindings：

"bindings":[{"agentId":"agent_general","match":{"channel":"telegram","accountId":"tg_general_bot"}},{"agentId":"agent_content","match":{"channel":"telegram","accountId":"tg_content_bot"}},{"agentId":"agent_pm","match":{"channel":"telegram","accountId":"tg_pm_bot"}}]

`bindings` 到底在干嘛？

每一条 binding 的意思都很直接：

在 telegram 渠道下
如果消息来自某个 accountId
那就把它交给指定的 agentId

所以它本质上就是一张路由表。

当前这套示例跑起来之后，效果就是：

Telegram accountId	目标 Agent
`tg_general_bot`	`agent_general`
`tg_content_bot`	`agent_content`
`tg_pm_bot`	`agent_pm`

这就是最直接、也最不容易出幺蛾子的多机器人分流方式。

你不用先判断群，不用先判断用户，也不用写一堆额外逻辑，直接按 accountId 分流就够了。

6. 为什么我强烈建议：每个 Agent 单独一个 workspace

当前这套示例里，每个 Agent 都用了不同 workspace：

agent_general：通用助理 workspace
agent_content：公众号/内容方向 workspace
agent_pm：产品经理方向 workspace

这样配的价值，不只是“整洁”，而是能真正把角色隔开：

隔离 identity / prompt
隔离本地文件和说明文档
隔离 memory
避免不同业务场景互相污染

如果多个 Agent 共用一个 workspace，表面上你是配了多 Agent，实际上很容易变成“多个入口共享同一个脑子”。

短期看似省事，长期一定乱：提示词串味、记忆串味、文件也串味。内容助手和产品助手一旦互相污染，后面你自己都分不清它为什么会这样回复。

7. 这样配完之后，你会得到什么效果

当角色、workspace、bindings 都拆开之后，这套结构就不再只是“多个 bot 入口”，而是会变成真正意义上的多角色系统：

`agent_general`

名称：General Assistant
定位：通用助理 / 技术支持

`agent_content`

名称：Content Assistant
定位：内容、选题、热点方向

`agent_pm`

名称：PM Assistant
定位：产品分析、需求梳理、结构化输出

你会发现，这时候它已经不是简单的“3 个机器人”，而是“3 个入口 + 3 套角色 + 3 套上下文”。

这才是多 Agent 真正有价值的地方。

8. 最容易踩的坑，我直接帮你标出来

1. 只创建了 Agent，没有配置 Telegram `accounts`

这样 Telegram 入口实际上还没建出来，机器人根本接不到消息。

2. Telegram `accounts` 已配置，但没有写 `bindings`

这样 bot 虽然接进来了，但不会按预期路由到目标 Agent，最后看起来就像“配置明明都在，为什么不工作”。

3. `binding` 里的 `accountId`，和 `accounts` 里的 key 对不上

比如：

accounts 里是 tg_content_bot
binding 里写成 tg_content

这种情况下就不会正确命中，路由会直接失效。

4. 多个 Agent 共用一个 workspace

这会直接导致角色、记忆、文件和规则互相污染，是后期最难查的一类问题。

5. 群聊没有设置 mention 策略

多机器人一旦进群，如果没有 requireMention 限制，容易误触发