多个 AI 怎么「开会不抢话」？AutoGen Group Chat 一文讲透-育师

作者：AI 技术笔记
参考：AutoGen 官方文档 · Group Chat
阅读时间：约 6 分钟

开头说人话

你有没有想过：一个 AI 写文案，一个 AI 画图，一个 AI 当编辑——它们怎么配合，才不会乱成一锅粥？

微软 AutoGen 给出的答案叫Group Chat（群组聊天）。

说白了，就是给多个 AI 建一个「工作群」：

大家看同一份聊天记录
同一时间只允许一个人说话
由一个「群管理员」决定：下一条消息该谁发

就像公司项目群里，Writer 写稿、Editor 审稿、Illustrator 配图，各干各的，但信息是同步的。

一、Group Chat 到底是啥？

1. 不是群聊吹水，是分工协作

Group Chat 不是让几个 AI 闲聊，而是：

把一个大任务拆成小块，交给不同角色的 AI 各做各的。

官方文档举的例子很形象：做一本儿童绘本。

角色	干什么
Writer（作者）	写故事
Illustrator（插画师）	根据描述生成插图
Editor（编辑）	审稿、提修改意见
User（用户）	最后拍板，输入`approve`结束

每个 AI 只专注自己的事，但都在同一个「群」里，能看到彼此说了什么。

2. 核心规则：一次只让一个人说话

这点很重要。

很多新手做多 Agent，最容易踩的坑就是：几个 AI 同时输出，上下文全乱套。

Group Chat 强制顺序发言——当前这位没说完，下一位不能插嘴。

谁来决定下一位？GroupChatManager（群聊管理员）。

二、群聊怎么运转？四步循环

用大白话描述，整个流程就四步：

① 用户/外部 → 往群里丢一条任务消息 ② 管理员 → 点名：「下一位，该你了！」 ③ 被点名的 AI → 发言，消息同步给全群 ④ 重复 ②③，直到任务完成

对应 AutoGen 里的消息类型：

GroupChatMessage—— 发到公共主题的消息
RequestToSpeak—— 管理员发给某位 AI 的「该你发言了」信号

终止条件可以自定义。文档示例里很简单：用户输入approve，群聊结束。

💡小设计细节：官方示例里，管理员会记住「上一个说话的是谁」，尽量不让同一个人连续发言，避免某个 AI 霸屏。

三、重点来了：三种「点名方式」，该用哪个？

这是 Group Chat 的灵魂。

管理员决定「下一位发言者」，大致有三种策略。选错了，要么浪费 Token，要么协作效率低。

策略一：轮询（Round-robin）—— 按顺序轮流

什么意思？

A → B → C → A → B → C……固定排队，谁也别插队。

适合什么场景？

流程固定，顺序不会变
典型例子：写稿 → 审稿 → 改稿 → 再审，循环几轮
每个角色都要公平参与
下一步该谁，跟聊天内容无关

优点：简单、稳定、不花钱（不用额外调 LLM 选人）

缺点：不够灵活。比如插画师已经画完了，轮询可能还轮到它空转。

一句话总结：流水线式协作，选它。

策略二：LLM 选择器（LLM Selector）—— 让 AI 决定该谁说话

什么意思？

管理员把「聊天记录 + 每个角色的职责描述」扔给大模型，问一句：

「看了上面的对话，接下来该谁上场？」

模型返回一个角色名，管理员就@那个人。

官方文档里的 GroupChatManager 就是这么干的——读历史、看角色、选下一位。

适合什么场景？

协作顺序取决于当前聊到哪了
多角色、多阶段任务，没法提前写死流程
绘本例子最典型：刚写完稿 → 该插画师；图画好了 → 该编辑审

优点：灵活、懂上下文，像有个真项目经理在调度

缺点：

每次选人都要调一次 LLM，多花钱、多耗时
模型可能选错人，需要兜底逻辑
官方也说了：Core API 那个示例偏教学，生产环境建议用 AgentChat 的SelectorGroupChat

一句话总结：任务复杂、节奏不固定，选它。

策略三：规则 / 自定义（Rule-based）—— 写死规则，不用 AI 选人

什么意思？

不用大模型猜，直接写规则，比如：

「作者发完言，下一个必须是编辑。」

或者自己写一个函数：if 上一个是 Writer then 下一个是 Editor。

适合什么场景？

流程你心里有数，规则能写清楚
要稳定、可复现，不能接受 LLM 偶尔选错
想省 Token，选人这一步零成本
正式上线的产品，简单规则往往比 LLM 更靠谱（文档原话）

优点：可控、便宜、快

缺点：对话内容变化再大，也跳不出你写的规则

一句话总结：流程有规律但不适合纯轮询，选它。

四、一张表帮你快速决策

策略	怎么选人	花钱吗	灵活性	推荐场景
轮询	固定顺序 A→B→C	否	⭐	反思/评审、固定流水线
LLM 选择器	大模型看上下文决定	是	⭐⭐⭐	多角色动态协作、开放任务
规则/自定义	写死的 if-else 规则	否	⭐⭐	「编辑紧跟作者」这类半固定流程

怎么选？记住这三句

顺序固定、人人都要说话→ 轮询
下一步取决于聊了什么→ LLM 选择器
规则简单、要稳要省→ 自定义规则

五、官方示例教会我们什么？

文档用 Core API 搭了一个「儿童绘本创作群」，几个值得学的点：

① 角色要分清楚

每个 Agent 有明确的system_message和description，LLM 选人才有依据。

② 管理员是调度中心

GroupChatManager不参与创作，只负责：收消息 → 选人 → 发RequestToSpeak→ 判断要不要结束。

③ 人可以留在回路里

UserAgent可以在关键节点介入，比如最后输入approve才收工——这就是 Human-in-the-loop。

④ 可以套娃

文档提到 Group Chat 可以嵌套：某个「参与者」本身也可以是另一个群聊。复杂系统可以分层设计。

六、Core API vs AgentChat：我该用哪个？

Core API	AgentChat API
定位	底层、灵活、自己搭	开箱即用、封装好
Group Chat	自己写 Manager + 订阅	`SelectorGroupChat`/`RoundRobinGroupChat`
适合谁	要深度定制	快速落地、做产品