为什么是现在做这件事

单 Agent 的天花板很明显：一个上下文窗口，对话积累到一定长度后角色混乱、记忆错位。你本质上在用一个"全能助手"硬撑所有任务，这在简单场景下够用，但一旦任务链条变长，效率急剧下降。

多 Agent 架构解决的是分工问题。PM Agent 拆需求，工程师 Agent 写代码，QA Agent 跑验证，主 Agent 统筹分发。每个角色的记忆保持干净，不会出现"你让它写测试用例，它突然开始讨论产品方向"的荒唐场面。

而 OpenClaw 提供了一个足够轻的 Gateway 层来实现这件事，不需要自己从零搭路由。配合 Telegram 的群组机制做天然隔离，整套方案的搭建成本其实很低。

第一步：在 Telegram 配置主 Agent

前提是你已经在云服务器上安装并运行了 OpenClaw。

  1. 打开 Telegram，搜索 BotFather（官方 Bot 管理账号）
  2. 发送 /newbot，给机器人取名字，再取一个以 bot 结尾的唯一 username（username 后续不可修改）
  3. BotFather 返回一个 token，复制保存
  4. 在服务器终端选择 Local → Channels → Telegram，粘贴 token
  5. 回到 Telegram 打开机器人对话，发送 /start，获取配对码，在服务器上完成配对

整个过程五分钟以内。主 Agent 上线后就可以在 Telegram 私聊中直接对话了。

关于模型选择：Claude Opus 4.6 在这套架构下表现很强，但成本不低。如果追求性价比，可以考虑 GPT-5.3-Codex，走 OpenAI Codex 认证登录，适合高频调用场景。选模型这件事没有标准答案，取决于你的任务复杂度和预算。

第二步：通过 Telegram 群组创建子 Agent

这一步是整套架构的关键设计——每个子 Agent 对应一个独立的 Telegram 群组。主 Agent 加入群组后，以"影分身"的形式存在：同一个 Gateway，但独立工作区、独立人设。

先配置 BotFather 权限：

  • 进入 BotFather → /mybots → 选择你的主 Agent
  • Allow Groups → 开启（Enabled）
  • Group Privacy → 关闭（Disabled）

创建并绑定群组：

  1. 新建一个 Telegram 群组，把主 Agent 机器人拉进来
  2. 在群里提及主 Agent，让它返回群组 ID
  3. 复制群组 ID，准备用于下一步的路由配置

第三步：用 Prompt 模版完成多 Agent 路由配置

这里有一个关键细节：不同模型的"聪明程度"不同，有些一次就能配好，有些需要非常明确的指令。以下这套 Prompt 模版几乎适用于所有 OpenClaw 支持的模型。

将 Prompt 发送到主 Agent 的私聊对话框（不是群组），内容分四个部分：

第一部分：Agent 基本信息。 包括 Agent 名称、使用的大模型、独立的 workspace 路径、身份与性格设定。

第二部分：群组绑定与路由配置。 同一个 Agent 需要配置两个 peer，差别只在 kind 字段——一个设为 group，一个设为 channel。这是因为 Telegram 的群在路由层可能被识别为不同的 peer.kind，两个都配上更保险。accountId 要设置为 main_bot，确保所有消息先路由到主 Agent，这是单 Gateway 架构下的必要配置。

第三部分：群消息策略。 默认设置所有群都需要明确提及才回复。但针对新建的子 Agent 群组，可以单独覆盖：requireMention 设为 false（不需要提及也回复），groupPolicy 设为 true（Agent 接收所有群消息）。

第四部分：防止主 Agent 抢消息。 单独配置主 Agent 只在私聊时响应，避免它在子 Agent 的群组里抢答。

配置完成后，进入群组测试："你是什么角色？你用的是什么模型？"——如果返回了你指定的 Agent 名称和模型，绑定成功。

第四步：通过主 Agent 调度整个团队

多个子 Agent 上线后，主 Agent 就变成了协调者。在私聊中发送调度指令，比如：

"调用产品经理 Agent、全栈工程师 Agent 和 QA Agent，协同完成一个开发 to-do list 应用的任务。"

主 Agent 会自动拆解任务、分发给各子 Agent、汇总结果。你不需要手动在多个窗口之间切换。

按照第二步和第三步重复操作，可以持续添加新的子 Agent，整套模版天然支持横向扩展。

这套架构真正值得关注的点

坦率说，多 Agent 协作这个方向目前还没看到真正的壁垒。OpenClaw 提供的是一个开源的 Gateway 层，Telegram 提供的是免费的消息通道和群组隔离，模型能力来自第三方 API。任何人都可以复制这套架构。

但这恰恰是它对一人公司有价值的地方——你不需要自建基础设施，不需要团队，用现成的工具组合就能搭出一套有分工、有隔离、可扩展的 AI 工作流。真正的护城河不在工具本身，而在你用这套架构解决什么问题、积累了什么独特的 Agent 配置和 Prompt 资产。先跑起来，在实际业务中打磨每个 Agent 的角色定义和协作流程，这才是难以被复制的部分。