本文用于指导用户在 CountBot 中配置“一个主机器人 + 多个子机器人”的多角色协作方案，并为每个角色分别设置不同的模型、API 与系统提示词。适用于飞书、企业微信等 IM 渠道接入场景，尤其适合搭建 主机器人 + 子机器人A + 子机器人B ... 这类团队式 AI 协作入口。
一、目标效果
完成配置后，你可以实现下面这套工作方式：
- 在同一个 IM 渠道中配置多个机器人账号
- 设定一个主机器人，例如
CEO - 再配置多个子机器人，例如
CTO、coder - 把这些机器人同时拉进一个群聊
- 在群里通过
@不同机器人的方式，把任务分发给不同角色 - 每个机器人都可以拥有各自独立的：
-
-
模型提供商
-
模型名称
-
API Key / API Base
-
温度参数
-
最大令牌数
-
最大工具调用次数
-
思考模式
-
角色名称
-
性格
-
自定义系统提示词
-
推荐理解方式如下：
CEO是主机器人，适合承担总控、汇总、调度、决策类任务CTO是技术架构角色，适合做方案评审、技术设计、复杂系统分析coder是执行角色，适合专注编码、修复、实现与输出
图1：整体架构示意图
二、先理解一个关键概念：会话是按机器人分开的
在 CountBot 里，多机器人不是共用一个完全相同的会话，而是按照不同机器人路由生成不同会话。
你在 Web 界面里通常看到的是类似下面这样的会话名称：
feishu:default:oc_xxxxxxxxxxxxxxxxxxx:20260323_011745
feishu:bot:oc_xxxxxxxxxxxxxxxxxxx:20260320_232309
feishu:bot-2:oc_xxxxxxxxxxxxxxxxxxx:20260320_232253
这些名称的格式可以理解为：
渠道:account_id:聊天对象ID:时间戳
例如：
feishu:default:...表示飞书渠道下的主机器人会话feishu:bot:...表示飞书渠道下bot子机器人的会话feishu:bot-2:...表示飞书渠道下bot-2子机器人的会话
注意区分两个概念：
- Web 会话列表中看到的，是“会话名称”
- 系统内部实际还有一个 UUID 形式的
session_id，例如：
d1f90fc0-3521-402e-82e2-ae1a699c8117
通常用户在界面中主要接触的是前一种，也就是带 feishu:default:... 这种格式的会话名。
图2：Web 会话列表示意图
三、第一步：在 IM 渠道中添加多个机器人
先进入 CountBot 后台：
- 打开
设置 - 进入
IM 渠道 - 选择你要接入的渠道，例如：
-
-
飞书 -
企业微信
-
然后配置多个机器人账号。
推荐示例：
| 角色 | account_id | 用途 |
|---|---|---|
| CEO | default | 主机器人，负责主群上下文与总控 |
| CTO | bot | 技术负责人角色 |
| coder | bot-2 | 编码执行角色 |
…
配置原则
每个机器人账号都应该单独填写自己的渠道凭据。
以飞书为例，每个账号都应分别配置自己的：
App IDApp Secretdisplay_nameaccount_id
以企业微信为例，每个账号都应分别配置自己的：
Bot IDSecretdisplay_nameaccount_id
重要规则
- 主机器人建议使用
default作为account_id - 子机器人建议使用清晰可读的标识，例如
bot、bot-2、cto、coder - 同一个物理机器人不要重复配置成多个账号
- 每个账号都应单独测试并保存
如果你计划做“主机器人 + 多专家机器人”的路由模式，建议这样命名：
default= CEOcto或bot= CTOcoder或bot-2= coder
这样后续在排查会话、定时任务、路由配置时会更直观。
图 3：飞书多机器人配置页
图 4：多机器人配置页
四、第二步：分别给每个机器人发一条消息，触发会话生成
机器人渠道配置完成后，不要立刻去找会话配置。
先要让每个机器人各自“产生一次真实对话”，这样 CountBot Web 才会生成对应的会话记录。
建议操作如下：
- 在飞书或企业微信群里，先给主机器人发一条消息
- 再给 CTO 机器人发一条消息
- 再给 coder 机器人发一条消息
只要消息发送成功，并且机器人已经接收到消息，CountBot Web 的会话列表中就会出现对应会话。
例如你可能看到：
feishu:default:oc_xxxxxxxxxxxxxxxxxxx:20260323_011745
feishu:bot:oc_xxxxxxxxxxxxxxxxxxx:20260320_232309
feishu:bot-2:oc_xxxxxxxxxxxxxxxxxxx:20260320_232253
如果没有发过消息，对应会话通常不会自动出现。
这一步非常重要，因为后面的“会话自定义配置”是挂在具体会话上的。
图 5：首次发消息后出现的会话列表
五、第三步：进入对应会话的“会话配置”
当会话已经生成后，回到 CountBot Web：
- 打开顶部
会话管理 - 在右侧会话列表中找到目标会话
- 找到对应会话后的
设置图标 - 点击进入
会话配置
你会进入当前会话的独立配置面板。
这里的核心开关是：
使用自定义配置
- 勾选：当前会话使用独立配置
- 不勾选：当前会话继续使用全局默认配置
也就是说：
- 全局配置管“默认行为”
- 会话配置管“当前这个机器人会话的特殊行为”
这正是多角色自定义模型的核心能力。
图 6：会话配置入口
六、第四步：为每个角色单独配置模型
进入会话配置后，首先处理的是 模型设置。
你会看到类似这些字段：
选择提供商模型名称温度 (Temperature)最大令牌数 (Max Tokens)最大工具调用次数启用思考模式
示例配置
下面是一个典型示例：
- 选择提供商：按你的接入情况选择，例如
zhipu、openai、anthropic等 - 模型名称：
glm-5 - 温度：
0.7 - 最大令牌数：
4096 - 最大工具调用次数：
25 - 启用思考模式：按需要开启或关闭
这些参数分别意味着什么
1. 选择提供商
决定当前会话使用哪个模型服务商。
例如：
- 主机器人使用一个偏综合推理的模型
- coder 使用一个偏代码能力更强的模型
- CTO 使用一个偏规划和分析的模型
2. 模型名称
决定当前会话具体调用哪个模型，例如：
glm-5gpt-4.1claude-sonnet- 其他你已接入的模型
3. 温度
温度越低，回复越稳定；温度越高，回复越发散。
4. 最大令牌数
控制单次输出的最大长度。
如果你希望角色能生成较长方案、较长代码或完整文档，可以适当调大。
5. 最大工具调用次数
控制当前会话一次任务中最多允许调用多少轮工具。
对于 coder 这种执行型角色，通常可以设得比普通聊天角色更高。
6. 启用思考模式
开启后，模型可能返回更完整的推理内容，但首字等待时间通常更长。
关闭后，通常响应更快，适合追求低延迟对话。
一个关键点：模型 API 也可以按会话独立配置
会话级模型配置不仅可以改：
- provider
- model
- temperature
- max_tokens
- max_iterations
- thinking_enabled
还可以独立覆盖：
api_keyapi_base
这意味着：
- CEO 可以走 A 服务商的 API,使用Claude模型
- CTO 可以走 B 服务商的 API,使用GLM模型
- coder 可以走 C 服务商的 API，GPT模型
互相不影响。
也就是说，真正实现的是“按角色配置不同模型 API”。
图7：模型设置面板
七、第五步：为每个角色单独配置人设和系统提示词
除了模型参数，每个角色还可以在 角色设置 中配置各自的人设。
常见字段包括：
AI名称用户称呼常用地址性格展开更多性格自定义系统提示词
推荐写法
CEO 主机器人
- AI名称：
CEO - 用户称呼：
主人 - 性格：
直率 / 温柔 / 暴躁 / 吐槽中选一个基础风格 - 自定义系统提示词：写成总控型角色
示例：
你是 CEO 角色，负责全局任务理解、问题拆解、汇总结论和分配工作。
你说话要简洁、果断、像一个真正的负责人。
当任务适合交给技术角色或 coder 时，你应该明确给出分工建议。
CTO 子机器人
- AI名称：
CTO - 用户称呼：
主人 - 性格：偏理性、直接
- 自定义系统提示词：写成架构师角色
示例：
你是 CTO 角色，专注技术选型、系统设计、架构评审、风险分析和工程规划。
你不要承担 CEO 的总控风格，而要像技术负责人一样提供方案、权衡和边界条件。
coder 子机器人
- AI名称：
coder - 用户称呼：
主人 - 性格：偏直接、执行型
- 自定义系统提示词：写成编码执行角色
示例：
你是 coder 角色，专注编码实现、修复问题、输出可执行方案和落地步骤。
你应少讲空话，优先给出代码、命令、修改点和验证方法。
关于“性格”和“自定义系统提示词”的关系
这里一定要注意：
- 如果只选性格，不填自定义系统提示词，则系统使用性格生成默认提示词
- 如果填写了自定义系统提示词，则会完全覆盖默认性格提示词
也就是说，一旦你写了自定义系统提示词，就应该把角色职责写完整，不要只写一句很短的话。
图8：角色设置面板
八、把多个机器人拉进同一个群聊后，会发生什么
这是整个方案里最重要的一部分。
当你把 CEO（default）、CTO（bot）、coder（bot-2） 同时拉入一个群聊后，可以通过 @ 来唤醒不同角色。
例如：
@CEO 帮我拆一下这个需求@CTO 给我出技术方案@coder 按这个方案写代码
1. CEO 主机器人拥有主群上下文
主机器人使用的是主群共享上下文。
你可以把它理解为：CEO 更适合做“这个群的总控大脑”。
在飞书、企业微信、钉钉、QQ 这类支持主机器人群共享上下文的渠道里：
- 主机器人会基于主群会话工作
- 更适合承担持续上下文理解、汇总和调度
2. 子机器人拥有独立会话
当你 @CTO 或 @coder 时：
- 它们会进入自己的独立机器人群会话
- 它们不会直接共享 CEO 的主群上下文
- 它们更像“按需被唤醒的专用专家”
通俗理解就是：
- CEO 看的是“主战场”
- CTO / coder 看的是“派给自己的那条线”
3. 子机器人仍然会把结果回复到同一个群
虽然子机器人拥有独立会话，但它们的回答仍然会发送回当前群聊。
所以用户表面上看到的是一个群里多个角色协同工作，实际上 CountBot 内部已经为它们拆开了上下文。
4. 主机器人会保留更完整的群聊语境
对于飞书、企业微信等多机器人群聊场景，可以把主机器人理解为“最完整的上下文拥有者”。
这也是为什么建议把：
- CEO 设为
default - 其他专家设为子机器人
因为主机器人更适合承担：
- 汇总
- 回顾
- 接力
- 继续追问
- 跨子角色整合结果
图9：群聊里 @CEO / @CTO / @coder 的示意图
九、一个完整的实战流程示例
下面给出一个典型使用方式。
场景：做一个新项目
你可以在同一个群里这样安排：
第一步：找 CEO 做总控拆解
@CEO 我要做一个支持飞书和企业微信的智能客服系统，你先帮我拆成实施阶段。
CEO 可以负责：
- 拆解项目阶段
- 识别关键模块
- 列出优先级
- 决定哪些部分要交给 CTO 或 coder
第二步：找 CTO 做方案设计
@CTO 根据 CEO 的拆解，给我出一个技术架构方案，重点讲多机器人会话隔离和模型路由。
CTO 可以负责：
- 技术方案
- 会话设计
- 接口边界
- 选型比较
- 风险评估
第三步：找 coder 做代码落地
@coder 按这个方案，先给我实现渠道多机器人会话路由和会话级模型覆盖。
coder 可以负责：
- 写代码
- 给 patch
- 列出修改文件
- 给出验证步骤
这种协作方式的优势在于：
- 每个机器人都“像一个固定岗位”
- 每个岗位都能用最合适的模型和提示词
- 用户仍然只需要在一个群里工作
十、推荐的配置顺序
为了避免配置混乱，建议严格按下面顺序操作：
- 先在
IM 渠道中配置多个机器人账号 - 确保主机器人使用
default - 保存并测试每个机器人
- 在 IM 中分别给每个机器人发送一条消息
- 回到 Web，会话列表中确认已经出现对应会话
- 进入每个会话的
设置图标 - 打开
会话配置 - 勾选
使用自定义配置 - 分别设置每个角色的模型参数
- 分别设置每个角色的系统提示词
- 把这些机器人拉进同一个群聊进行协作测试
按这个顺序做，最不容易出问题。
十一、常见问题
1. 为什么我配置了多个机器人，但 Web 里没有出现多个会话？
通常原因是：
- 机器人虽然配置了，但还没有真正收到消息
- 没有给每个机器人分别发送过消息
- 渠道保存后未真正生效
解决方法：
- 给每个机器人各发一条消息
- 确认渠道测试通过
- 确认配置已保存
2. 为什么主机器人和子机器人看起来没有完全共享上下文？
这是设计结果，不是异常。
多角色方案的目的本来就是：
- 主机器人承担主群上下文
- 子机器人承担独立专家会话
如果所有机器人都完全共享同一份上下文，角色边界会变弱，也更难做模型隔离。
3. 为什么我填了“自定义系统提示词”后，性格好像不生效了？
因为自定义系统提示词会完全覆盖默认性格提示词。
这属于正常行为。
4. 为什么同一个机器人不能配置成两个账号？
因为系统会校验重复机器人配置。
同一个物理机器人身份不能重复复用为多个账号，否则会导致路由和会话归属混乱。
5. 为什么建议主机器人使用 default？
因为 default 是主账号语义，整体更符合主机器人群共享上下文的设计习惯，也更利于后续排查会话和路由。
