4.2 群组对话（Group Chat）机制与管理

4.2 群组对话（Group Chat）机制与管理

群聊是多人协作的容器。你把几个 Agent 放进 GroupChat，由 GroupChatManager 决定下一轮谁发言——这正是"对话即编排"最直观的形态：你定角色和规则，具体谁先说让对话自己涌现。先上时序图。

基本结构

GroupChat 持有 agents 列表和 messages 历史；GroupChatManager 包着它，负责按策略选下一发言者。你把一个消息发给 manager，它就启动轮转。

from autogen import GroupChat, GroupChatManager, ConversableAgent
import os
cfg = {"model": "gpt-4o-mini", "api_key": os.environ.get("OPENAI_API_KEY")}

coder = ConversableAgent("coder", llm_config=cfg, system_message="你写代码。")
reviewer = ConversableAgent("reviewer", llm_config=cfg, system_message="你审代码。")
tester = ConversableAgent("tester", llm_config=cfg, system_message="你测代码。")

group = GroupChat(agents=[coder, reviewer, tester], messages=[], max_round=6)
manager = GroupChatManager(group=group, llm_config=cfg)
# 把任务丢给 manager，它驱动三个角色轮转
manager.initiate_chat(coder, message="写一个判断素数的函数。", max_turns=6)
​

发言者选择策略

speaker_selection_method 有几个值：

• auto（默认）：让模型根据上下文决定下一发言人。
• round_robin：按列表顺序轮流，最可控。
• manual：每轮问你选谁。

我们主张：原型用 auto 看涌现效果，定型要可复现时切 round_robin。

group = GroupChat(agents=[coder, reviewer, tester], messages=[],
                  max_round=6, speaker_selection_method="round_robin")
# 顺序固定：coder->reviewer->tester->coder... 便于复现和调试
​

角色在群里的边界

群聊里每个 Agent 仍只听到共享历史，看不到别人的私有状态（见 3.5）。所以"reviewer 要挑 coder 的刺"，刺得写在共享消息里，coder 才能在下一轮看到。

群聊的代价

角色越多，每轮要喂给模型的上下文越长（全历史），成本和延迟随角色数上升。我们经验：群聊角色控制在 4 个以内最经济，再多建议拆成"群套群"或转顺序。

Manager 选人策略背后的代价

speaker_selection_method 不只是一个开关，它直接决定群聊的"可控性"和"成本"。auto 让模型根据历史挑下一个发言者，灵活但不可复现——同样的输入可能因为模型这次的随机性选中不同人，调试时你没法稳定重现"为什么那一轮是 tester 说话"。round_robin 把顺序焊死，可复现、好调试，但牺牲涌现：角色再默契也只能按固定节拍走，不擅长应对突发分歧。manual 把选择权交给你，可控性最高，但每轮都要人介入，不适合生产。

这里的权衡可以用交通信号来理解：auto 像自适应信号灯，车流顺但偶尔莫名放行；round_robin 像固定配时信号灯， predictable 但高峰期死板；manual 像交警现场指挥，最稳但离不开人。选型取决于你对"可控"和"自动"的取舍。我们的经验法则：原型期用 auto 看角色能不能自然配合，一旦进入要交付的阶段，切 round_robin 或显式指定发言序列，让行为可预期。

还有个和收敛强相关的点：auto 模式下群聊"没有主持人收尾"，角色可能互相接话停不下来，所以必设 max_round 兜底，再配合 4.4 的终止条件。Manager 只负责"谁说"，不负责"聊到哪算完"——这个分工一定要记牢，否则你会以为群聊自己会收敛，结果账单一夜爆掉。

群聊太大时的拆分信号

前面说角色控制在 4 个以内最经济，但业务复杂时难免想加人。什么时候该拆而不是硬加？信号一：每轮上下文已经长到模型开始"忘掉"开头的要求——这是上下文窗口被历史撑爆的前兆，该把群聊按子任务拆成"群套群"，外层顺序、内层群聊。信号二：多个角色其实在干相近的活（比如三个审稿 Agent 观点高度重叠），说明角色冗余，合并或改为单人多视角更省。信号三：auto 模式下角色经常"抢话"或"冷场"，说明职责边界模糊，先用 round_robin 固定节拍，等边界清晰再考虑放自动。

拆分不是退步，是成熟。一个 8 人乱聊的群，往往不如"两个 3 人群 + 一个协调顺序"来得又稳又省。用交通类比：一条八车道的无序路口，不如两个四车道配信号灯的交叉口通畅。群聊设计的终局不是"人越多越智能"，而是"每个角色都有不可替代的视角，且数量刚好够覆盖这些视角"。

⚠️ 群聊角色超过 4 个且仍用 auto，成本和不可控性会同时飙升，务必先评估能否拆分。

本节要点回顾

• GroupChat 存历史，Manager 选下一发言者。
• auto 看涌现，round_robin 可复现。
• 群聊角色建议不超 4 个，否则成本和延迟飙升。
• 选人策略决定可控/成本，auto 必配终止条件，Manager 不负责收敛。
• 超员按上下文撑爆、角色冗余、抢话三信号拆分，群套群更稳。

⚠️ auto 模式下群聊可能不收敛，必须配 max_round 和终止条件（见 4.4），否则烧钱。

💡 GroupChat 就是"对话即编排"的样板间：你摆好角色，让对话自己决定怎么协作。