OpenClaw 多 Agent 实战：腾讯云部署到 Telegram 群聊分身协作

这篇文章记录了我如何把 OpenClaw 从单 Agent 使用，升级成一套真正可落地的多 Agent 工作台：在腾讯云上部署、拆分多个 Agent、接入 Telegram 私聊与群聊，并完成路由、排错和安全收口。

如果你也想把 OpenClaw 从演示环境做成长期可用的实战系统，这篇可以直接参考。

文中我会重点拆开这几部分：

• 为什么我最后放弃单 Agent，转向多 Agent
• 目录结构、人格文件和模型绑定应该怎么拆
• Telegram 多机器人入口怎么配
• 群聊不回、消息转圈、allowlist 告警这些坑怎么排

先说结论

这次实践让我确认了三件事：

• 多 Agent 的核心不是多起几个名字，而是模型、工作区、人格、会话、入口这几层一起隔离
• Telegram 多 bot + 同群 @ 提及，是当前最直观、最容易跑通的多 Agent 入口
• 真正决定能不能长期稳定用下去的，不只是“跑起来”，而是 allowlist、requireMention 和插件最小化

一、为什么我放弃单 Agent，转向多 Agent

我最开始使用 OpenClaw 时，实际上已经能跑单个 Agent 了，也可以接 Telegram 机器人使用。

但随着我的使用场景逐渐明确，我发现单 Agent 模式虽然“能用”，却很难“好用”。

我的实际需求并不是一个万能机器人，而是多个分工明确的智能体：

• 一个主会话 Agent，负责总入口、通用对话和轻度任务分诊
• 一个交易分析 Agent，负责选股、盘前盘后分析、持仓逻辑、量化交易风格输出
• 一个写作 Agent，负责账号运营、公众号文章、知识体系化、专题内容输出

如果把这些职责全部塞进一个 Agent 里，会出现几个明显问题：

1. 一个 Agent 越做越重，prompt 很快失控

一个 Agent 既要懂交易、又要懂写作、还要承担通用入口，很容易导致 prompt 过长、人格混杂、输出风格不稳定。

2. 写作、交易、通用会话会互相污染

写作任务和交易任务天然不是同一个上下文。单 Agent 会导致前一个任务的上下文干扰后一个任务，尤其是在连续对话时表现更明显。

3. 不同任务，本来就该配不同模型

不同任务适合的模型并不相同：

• 写作更看重长文本组织与表达
• 交易分析更看重结构化推理与总结
• 主会话更看重均衡性与通用性

如果所有任务都绑定一个模型，效果通常不是最优。

所以，我最终决定在 OpenClaw 上落地多 Agent 架构，让不同 Agent 各司其职，并通过 Telegram 实现私聊和群聊中的分身式协作。

---

二、这次落地的环境和前提

这次的部署环境很明确：

服务器环境

• 云平台：腾讯云服务器
• 系统：Linux
• OpenClaw 版本：2026.3.7
• 运行方式：systemd 托管的 gateway service

外部接入方式

• 聊天入口：Telegram

• 使用方式：

  • 私聊不同机器人
  • 群聊中通过 @机器人名 唤醒不同 Agent

我当前可用的模型

我当前可用的模型主要有这些：

• qwencode/glm-4.7
• qwencode/glm-5
• qwencode/kimi-k2.5
• qwencode/MiniMax-M2.5
• qwencode/qwen3-coder-plus
• qwencode/qwen3-max-2026-01-23
• qwencode/qwen3.5-plus

这些模型已经足够支撑我的多 Agent 规划。

---

三、我最终采用的多 Agent 架构

最终，我没有继续单独保留一个无意义的 main，而是把 jayce 直接作为默认主会话 Agent。

我当前的结构是：

• jayce：默认主会话 Agent
• rich：交易分析 Agent
• write：写作与知识体系化 Agent

这样设计的理由很简单：

jayce

负责：

• 日常问题
• 通用任务
• 总入口
• 对复杂任务进行轻度分诊

rich

负责：

• A 股量化交易分析
• 盘前盘后复盘
• 选股逻辑
• 风控与持仓思路

write

负责：

• 账号运营
• 知识体系化
• 技术文章写作
• 系列专题规划
• 公众号内容生成

这三个 Agent 各自独立，互不干扰。

---

四、多 Agent 真正要隔离的，不只是名字

多 Agent 不是只多建几个名字不一样的机器人那么简单。真正有价值的多 Agent，要做到至少三层隔离：

1. 模型隔离

不同 Agent 配不同模型，而不是共用一个默认模型。

2. 工作区隔离

每个 Agent 有自己的 workspace、agentDir、session、auth profile。

3. 人格与功能隔离

每个 Agent 都有自己的文件体系，用来定义：

• 它是谁
• 它负责做什么
• 它如何回答
• 它的风格、规则、边界是什么

如果只是“多建几个 agent 名字”，但没有隔离工作区和提示文件，那本质上还是在复用同一个脑子。

---

五、我采用的 OpenClaw 多 Agent 目录结构

我最终采用的是这种结构：

~/.openclaw/
├── openclaw.json
├── workspace/                  # jayce
│   ├── IDENTITY.md
│   ├── SOUL.md
│   ├── AGENTS.md
│   ├── USER.md
│   └── OUTPUT_RULES.md
├── workspace-rich/             # rich
│   ├── IDENTITY.md
│   ├── SOUL.md
│   ├── AGENTS.md
│   ├── USER.md
│   ├── STRATEGY.md
│   ├── RISK.md
│   └── REPORT_TEMPLATE.md
├── workspace-write/            # write
│   ├── IDENTITY.md
│   ├── SOUL.md
│   ├── AGENTS.md
│   ├── USER.md
│   ├── STYLE_GUIDE.md
│   ├── CONTENT_SERIES.md
│   └── PUBLISH_RULES.md
└── agents/
    ├── jayce/
    │   ├── agent/
    │   │   └── auth-profiles.json
    │   └── sessions/
    │       └── sessions.json
    ├── rich/
    │   ├── agent/
    │   │   └── auth-profiles.json
    │   └── sessions/
    │       └── sessions.json
    └── write/
        ├── agent/
        │   └── auth-profiles.json
        └── sessions/
            └── sessions.json

这个结构的好处是非常清晰：

• workspace 管上下文文件
• agentDir 管 agent 自身目录
• sessions 管各自历史会话
• 不同 agent 之间相互独立

---

六、不同 Agent 的文件怎么写，才算长期可维护

这一部分是多 Agent 成败的关键。

1. IDENTITY.md

定义这个 Agent 是谁。

适合放：

• 名称
• Emoji
• 身份设定
• 总体主题

例如 write 的 IDENTITY.md 可以写成：

# Identity
name: Jayce Write
emoji: ✍️
theme: 内容运营、知识体系化、技术长文创作

2. SOUL.md

定义这个 Agent 的灵魂，也就是人格和核心风格。

例如 rich 的 SOUL.md：

你是专注交易分析与选股的研究型智能体。
擅长盘前机会梳理、热点跟踪、个股催化、交易计划和风险提示。
输出必须结构化，避免模糊结论。

3. AGENTS.md

定义它怎么做事。

例如 write 的 AGENTS.md：

任务处理流程：
1. 判断是选题规划、专题设计，还是直接成文。
2. 若要求文章，优先输出标题、摘要、正文、总结。
3. 正文优先体系化、可落地、可沉淀。
4. 能做系列的内容优先做成专栏。
5. 若有发布动作，最后补充适配草稿箱的版本。

4. USER.md

定义用户长期偏好。

例如：

用户希望做公众号、知识体系化、知识星球和长期内容资产。
偏好实战案例、完整流程、落地经验和长期可复用内容。

5. 专属补充文件

根据不同 Agent 再加专属规则文件：

rich

• STRATEGY.md
• RISK.md
• REPORT_TEMPLATE.md

write

• STYLE_GUIDE.md
• CONTENT_SERIES.md
• PUBLISH_RULES.md

这些文件不是可有可无，而是为了让 Agent 长期稳定输出，不至于每次都靠临时对话去重建风格。

---

七、不同 Agent 怎么绑定不同模型

这是我这次部署里非常重要的一步。

我不是让所有 Agent 都用同一个模型，而是按任务类型做了拆分：

jayce

我给它配置的是：

• 主模型：qwencode/glm-5
• 备选：qwencode/glm-4.7

原因是主会话 Agent 需要的是均衡能力，而不是极端偏写作或偏代码。

rich

我给它配置的是：

• 主模型：qwencode/qwen3-max-2026-01-23
• 备选：qwencode/glm-5

原因是交易分析更依赖强推理、结构化总结和长上下文能力。

write

我给它配置的是：

• 主模型：qwencode/kimi-k2.5
• 备选：qwencode/glm-5

原因是写作任务更需要中文长文能力、表达和组织能力。

这样配置之后，三个 Agent 的表现明显比“全都用一个模型”更稳定。

---

八、openclaw.json 我是怎么收敛到最小可用配置的

我最终把配置收敛到了只保留 Telegram 的最小可用版本。

核心思路是：

1. 多 Agent

使用 agents.list 定义三个 Agent。

2. 多账号 Telegram Bot

使用：

• channels.telegram.accounts.default
• channels.telegram.accounts.rich
• channels.telegram.accounts.write

分别接入三个机器人。

3. 路由绑定

通过 bindings 把不同 Telegram bot 路由到不同 Agent：

• default -> jayce
• rich -> rich
• write -> write

这样，在 Telegram 里不同机器人就是不同 Agent 的入口。

---

九、Telegram 多机器人入口，我是怎么建起来的

这一步我是通过 BotFather 完成的。

创建三个机器人

我分别创建了：

• 主会话机器人
• Rich 交易机器人
• Write 写作机器人

然后把它们的 token 配置到 OpenClaw 的 channels.telegram.accounts 中。

为什么要多机器人

因为我希望在 Telegram 群里实现非常直观的体验：

• @Jayce_AI_BOT
• @Jayce_richbot
• @jayce_writebot

不同 bot 名字天然就是不同 Agent，不需要用户再去记复杂命令。

---

十、私聊和群聊里，怎么使用这套多 Agent

私聊使用

私聊哪个 bot，就进入哪个 Agent：

• 私聊主 bot：进入 jayce
• 私聊 rich bot：进入 rich
• 私聊 write bot：进入 write

群聊使用

我最终把三个 bot 都拉进了同一个群。

然后群里使用方式非常简单：

• @Jayce_AI_BOT 你现在对应的是哪个 agent？
• @Jayce_richbot 你能做什么？
• @jayce_writebot 帮我写一篇文章大纲

为了避免群里串话，我保留了：

"groups": {
  "*": {
    "requireMention": true
  }
}

也就是说，在群里必须明确 @机器人 才会触发。

这是多 bot 同群时最稳妥的方式。

---

十一、部署过程中，我踩过的几个典型坑

这次部署并不是一次成功，中间有几个典型问题。

问题 1：openclaw gateway 启动失败

我一开始以为 gateway 没启动，结果执行 openclaw gateway 报错：

• gateway already running
• port already in use

后来确认原因是：

• OpenClaw 已经通过 systemd 在后台运行
• 我重复执行了前台启动命令

解决方法

不要重复启动，而是用状态命令确认：

openclaw status
openclaw channels status --probe
openclaw agents list --bindings

如果改完配置需要重启，就执行：

openclaw gateway stop
systemctl --user restart openclaw-gateway.service

---

问题 2：群聊里消息发不出去，发送按钮一直转圈

我一开始在 Telegram 群里 @机器人 后发送，发现消息按钮一直转圈。

当时容易误判成 OpenClaw 没响应，但实际上更像是 Telegram 客户端没有把消息成功发到服务器。

后面验证发现：

• 私聊是通的
• 群里第一次有点卡
• 后续正常了

这类情况通常和以下因素有关：

• bot 刚被拉进群，Telegram 侧同步有延迟
• 首次 mention 才建立该群与 bot 的交互上下文
• 客户端缓存还没刷新
• 网络不稳定

最后在实际测试中，三个 bot 都在群里正常响应，说明问题不是 OpenClaw 配置本身。

---

问题 3：群消息被静默丢弃

我在 doctor 里看到过这样的告警：

• groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is empty

这意味着如果白名单没配好，群消息会被直接丢弃。

解决方法

我最终明确配置了：

"allowFrom": [我的Telegram用户ID],
"groupPolicy": "allowlist",
"groupAllowFrom": [我的Telegram用户ID]

这样做之后，就只有我本人可以私聊和在群里触发这些机器人，其他群成员无法调用。

---

十二、我怎么确认这套多 Agent 已经真正跑通

我不是只看服务是否启动，而是按以下几个维度验收。

1. 看 channel 状态

openclaw channels status --probe

检查三个 Telegram bot 是否都显示 works。

2. 看 Agent 路由

openclaw agents list --bindings

确认：

• jayce -> telegram accountId=default
• rich -> telegram accountId=rich
• write -> telegram accountId=write

3. 看 Telegram 实际回复

我在群里分别发送：

• @Jayce_AI_BOT 你现在对应的是哪个 agent？
• @Jayce_richbot 你现在对应的是哪个 agent，你能做什么
• @jayce_writebot 你现在对应的是哪个 agent，你能帮我做什么

最终三个机器人都按各自身份正确回复，这才说明整个链路真正打通。

---

十三、跑通之后，我怎么继续做安全加固

这一部分很重要，尤其是 Telegram 群接入之后。

1. 只保留 Telegram

既然我当前只用 Telegram，就没必要保留其他 channel 和大量无关插件。

我后面做的方向就是：

• 删除或禁用飞书、企业微信、钉钉、QQ Bot 等当前不用的插件
• 只保留 Telegram

这样做的好处是：

• 配置更简洁
• 状态页噪音更少
• 降低不必要的插件暴露面
• 减少安全风险

2. 显式配置 allowlist

我最终不再用开放群模式，而是改成：

• groupPolicy: "allowlist"
• allowFrom: [我的用户ID]
• groupAllowFrom: [我的用户ID]

这样只有我可以触发这些机器人。

3. 继续保留 requireMention: true

群里必须 @机器人 才会触发，避免误触发和串话。

4. 最小化插件白名单

如果只用 Telegram，建议 plugins.allow 只保留 Telegram 相关内容，避免其它扩展被自动加载。

---

十四、遇到问题时，我建议按这个顺序排查

后面如果再遇到问题，我会按这个顺序排查。

1. 先确认是不是服务没起

openclaw status

2. 再看 Telegram channel 是否健康

openclaw channels status --probe

3. 看 agent 路由是否正确

openclaw agents list --bindings

4. 看日志

openclaw logs --follow

5. 区分“消息没发出去”和“消息发出去了但 bot 没回”

这两个问题完全不同：

• 如果 Telegram 客户端发送按钮一直转圈，优先看客户端、网络、群权限
• 如果消息已经发出但 bot 不回，优先查 OpenClaw 配置、allowlist、bindings、日志

6. 区分“私聊不通”和“群聊不通”

• 私聊不通：多半是 bot token、pairing、账号配置问题
• 群聊不通：多半是 groupPolicy、groupAllowFrom、requireMention、Privacy Mode 等问题

---

十五、这次落地后，我对 OpenClaw 多 Agent 的最终理解

这次部署之后，我对 OpenClaw 多 Agent 有几个非常明确的结论。

1. 多 Agent 的核心不是“多建几个名字”

而是：

• 不同职责
• 不同模型
• 不同文件
• 不同会话
• 不同入口

2. 工作区文件非常关键

IDENTITY.md、SOUL.md、AGENTS.md、USER.md 这些文件，决定了 Agent 长期是否稳定。

3. Telegram 多 bot 是非常适合多 Agent 的入口

尤其是同群 @不同机器人 的体验，非常直观，几乎不需要额外培训。

4. 安全配置必须在跑通后尽快收紧

调试时可以临时放开，但长期一定要：

• 只保留需要的插件
• 开启 allowlist
• 只允许指定用户触发
• 保持 mention 触发

---

十六、这套方案现在已经实现了什么

到这里，我已经实现了以下目标：

• 在腾讯云服务器上完成 OpenClaw 多 Agent 部署
• 规划并创建了 jayce / rich / write 三个独立 Agent
• 给不同 Agent 配置了不同模型
• 给不同 Agent 配置了不同 workspace 和文件体系
• 通过 Telegram 创建了三个独立机器人
• 实现了私聊不同机器人进入不同 Agent
• 实现了同一 Telegram 群里通过 @不同机器人 唤醒不同 Agent
• 完成了 allowlist 和插件收敛方向的安全加固

这套方案对我来说已经不是一个“玩具演示”，而是一套可以持续扩展的 Agent 工作台。

后面我可以继续做的事情包括：

• 让 write 深度接公众号草稿箱工作流
• 让 rich 对接交易日报或分析链路
• 让 jayce 作为统一入口，承担更多调度角色
• 继续增加新的专业 Agent，比如 coder、ops 等

---

十七、如果你也要快速复刻，我建议从这条最小路径开始

如果有人和我一样，也想在 OpenClaw 上快速做出可用的多 Agent，我的建议是：

先不要上来就搞很多 Agent。 先做好这三个：

• 一个主会话 Agent
• 一个交易/分析 Agent
• 一个写作 Agent

然后先接 Telegram，多 bot 同群跑通，最后再做安全加固和后续自动化链路接入。

这条路线最稳，也最容易快速看到成果。

---

结尾：如果你也在做 OpenClaw，欢迎继续关注这个系列

如果你也想把 OpenClaw 从“能跑一个 Agent”，升级成“能长期协作的多 Agent 工作台”，欢迎关注我的公众号。

接下来我会把 OpenClaw 作为一个系列持续更新，重点会继续写这些主题：

• 多 Agent 的权限边界和安全收口
• 自动化写作流水线：从素材到公众号草稿箱
• 研究型工作流模板化与质量门禁
• 不同 Agent 的规则文件怎么持续迭代

如果你想先拿到这篇配套资料，关注公众号【数字卢语】发送关键词：「OpenClaw」，领取我整理的 openclaw.json 模板、多 Agent 目录结构参考，以及 IDENTITY.md / SOUL.md / AGENTS.md / USER.md 配置文件示例，如果有需要帮忙部署的也欢迎联系我。

后续这个系列的更新，我也会优先在公众号里第一时间发布。