GroupChatManager：多Agent调度策略

可视化演示

展示四种调度模式：轮询、随机、手动指定、LLM自动裁决，以及共享对话历史与消息路由机制。

调度器角色定位

回到那场圆桌会议。没有主持人时，四个人各说各话，讨论变成灾难。多智能体系统面临同样的困境：几个 AI 各有专长，但谁先发言？谁来总结？如果让每个 Agent 自由抢话，轻则逻辑混乱，重则陷入死循环。于是，GroupChatManager 这位“圆桌主持人”应运而生。

GroupChatManager 是一个中心化协调组件。它本身不产出业务观点，而是像主持人一样负责三件事：维护一份讨论名单（Agent 列表）、决定下一个发言者、保存会议纪要（对话历史）。在 AutoGen 框架中，开发者在 GroupChat 里登记参与讨论的 Agents，再通过 GroupChatManager 统一调度，就能组织一场井然有序的多角色讨论。

从数学视角看，每个时间步的发言者选择可以被形式化为一个“映射函数”：调度器读取当前历史状态，输出一个发言人索引。

于是，四种调度模式就是四种不同的“点名方式”：轮询是顺着名单轮流叫，随机是抽签，手动是管理员直接点名，LLM 裁决则是主持人根据现场气氛灵活判断。理解了这位主持人的角色，下面就逐一拆解他的四种点名手法。

轮询调度策略

想象班级做自我介绍，老师拿着名单从上往下念：“张三、李四、王五、赵六……”念完一圈再从头开始。这种最朴素的“按名单循环”就叫轮询调度（Round-Robin）。GroupChatManager 的 round_robin 模式正是如此：把参与讨论的 Agent 排成固定顺序，一轮发言结束后，把话筒递给下一个人，所有人都发言一遍后再回到队首。

轮询最大的优点在于公平与零决策成本。它不需要读历史、不需要打分数，只需要记住“上次轮到谁”，下次顺延即可。这在人人平等的头脑风暴中非常合适——不会有人被冷落，也不会有人垄断话题。缺点也显而易见：它完全不看讨论内容，如果工程师 Agent 正需要补充技术细节，轮询却把话筒先交给了运营，流程就略显机械。

在 AutoGen 中，只需在构造 GroupChatManager 时传入 select_speaker_method="round_robin"，调度器便会照单执行。设 Agent 数量为 N，第 t 轮发言者的计算公式如下：

轮询调度像圆桌上的顺时针传话筒，简单可靠。如果你的任务需要全员平等参与、且各 Agent 无明确优先级，轮询永远是可托底的默认选择。

随机调度策略

有些会议主持人喜欢“随机点人”：“下一个——就你吧，设计师！”这种随性而为的方式对应 GroupChatManager 的 random 模式。调度器不再按固定顺序循环，而是掷一次“骰子”，从所有 Agent 中随机选一个出来发言。

随机调度的价值在于多样性。在创意探索类任务中，固定的轮询容易让讨论陷入“每个人都说了一轮”的模板化节奏，随机打破预期，可能让冷门的观点意外冒头。例如一群 Agent 为新产品想 slogan 时，随机切换发言者可能激发不一样的组合思路。但它的代价是不可控：同一个 Agent 可能连续被抽中两次，也可能整场都没发言，不适合对发言顺序有硬性要求的场景。

底层实现并不神秘——调度器调用随机数生成器，在 0 到 N-1 之间产生一个均匀分布的整数：

随机点名适合“发散 > 收敛”的创意讨论，它为会议注入意外与惊喜。但要记住：骰子掷多了，总有运气差的家伙——如果你的任务必须保证每人发言至少一次，请换回轮询。

手动调度策略

有时候主持人不需要自己动脑，台下的“老板”会直接指示：“让工程师先讲技术方案！”这种由外部人工指定发言者的方式，就是 manual（手动）调度。GroupChatManager 允许你配置一个 admin_name（管理员），这位管理员可以在对话中直接点名：“请设计师发言”，调度器便不再自动决策，乖乖把话筒递给指定对象。

手动调度听起来“不智能”，却是工程实践中的救命稻草。当你调试一个多 Agent 系统时，你常常想控制变量：让某个 Agent 先试一句、观察其他 Agent 的反应。手动模式让你像导演一样逐幕排演，精确控制讨论节奏。它还解决了“AI 自主决策失控”的问题——在严格的合规场景（如合同审核）中，人类把关发言顺序远比让 LLM 自由发挥更安全。

手动调度没有复杂的算法，它的决策规则就是“管理员说了算”：

手动调度像导演手中的提词板：AI 团队再聪明，也需要人类在关键时刻“拨一下方向盘”。它常与自动模式配合使用——大部分时间交给系统，关键节点人为干预。

LLM自动裁决

最高级的主持人是这样的：他不死板地按名单念，而是观察现场气氛、总结已有观点，再决定“嗯，这个问题需要工程师来深入讲讲”。GroupChatManager 的 auto 模式（LLM 自动裁决）模拟的正是这种“懂内容的主持人”。

在 auto 模式下，调度器不再使用固定规则，而是调用一个大语言模型作为“评审团主席”。它把候选的发言者列表连同当前对话历史一起交给 LLM，让模型判断谁是最合适的下一位发言者。LLM 会权衡讨论方向：如果现在正在讨论数据库选型，它更倾向点工程师；如果话题转向用户界面，它可能选设计师。这种动态判断远比轮询的机械循环聪明。

代价也很明显：每次选人都是一次 LLM 调用，带来额外延迟与 token 费用。如果对话历史已经很长，评审成本会水涨船高。数学上，LLM 裁决可以做如下抽象：先给每个候选项打分，再取分数最高者：

LLM 裁决让 GroupChatManager 从“拿着名单的传话员”升级为“深谙议题的智库型主持人”。虽然它最聪明，也最昂贵——在追求严谨可控的生产环境中，很多团队选择只在关键决策点启用 auto，日常讨论用轮询兜底。

上下文共享机制

会议纪要为什么重要？因为好的讨论必须“基于前文”。如果工程师 Agent 在第三轮提到“用 Redis 做缓存，延迟降低到 2ms”，设计师 Agent 在第十轮设计页面时看不到这条上下文，就会做出违背性能约束的方案。GroupChatManager 维护的共享历史（chat_history / messages）就是那份完整的会议纪要。

这份纪要是一份全局可见的消息列表，每轮发言结束后，新消息会被追加进去。任何 Agent 需要发言时，调度器会把完整纪要作为上下文传给该 Agent——不是截取片段，而是从开场白到当前轮次的所有消息。这种设计的核心理念是“全员信息对称”：每个 Agent 都站在全局视角发言，避免各说各话、前后矛盾的现象。

随着讨论推进，这份纪要会像滚雪球一样越来越长。形式化地看，每轮结束后历史更新遵循简单的追加规则：

共享上下文是多智能体讨论质量的“压舱石”。它保证了每个 Agent 都拥有全局视野，但也带来了 token 长度增长问题——当纪要膨胀到超过模型上下文窗口，就需要考虑摘要或裁剪策略，这是工程师在构建长对话系统时最常遇到的瓶颈之一。

消息路由原理

主持人的另一项核心工作，是把话语权精确地“递”给下一个发言者，同时确保所有人听到刚才的发言。在 GroupChat 中，这条“递话筒”的机制就是消息路由：Manager 广播每条消息给所有 Agent，同时根据调度策略决定下一位由谁续接。

路由过程可以拆成两个阶段：广播与选择。广播阶段，发言者的话被写入共享历史并分发给全体 Agent，相当于主持人把发言者的观点“传达到每个人耳边”；选择阶段，Manager 调用调度策略（轮询/随机/手动/auto）锁定下一位发言人，再把“话筒”递过去。两个阶段循环往复，就形成了多轮对话的完整链条。

从系统视角看，消息路由可以抽象成一个广播函数：

消息路由决定了“讨论的接力棒”如何流动。一个设计良好的路由机制，能保证讨论不断线、不遗漏、不偏题——这正是 GroupChatManager 作为“圆桌主持人”最核心的工程价值。

主流框架对比

同样一张圆桌，不同会议室的“主持人风格”各不相同。在 AutoGen 中，GroupChatManager 是标准的“主持人”，你需要显式创建一个 GroupChat（会议桌）、一群 AssistantAgent（参会者），再指定调度策略。AutoGen 的强项是灵活的对话流控制：既能快速搭一个轮询讨论组，也能挂上 LLM 裁决做复杂协作。

CrewAI 则更像一个“流程化剧组”：它不强调自由讨论，而是用 Process 定义严格的执行流程——顺序执行（像流水线）或层级执行（像汇报关系），每个 Crew（团队）按剧本依次出场。CrewAI 的调度策略更偏“任务编排”而非“讨论点名”：它关心任务依赖，不关心谁先说。这对应着两种不同的协作哲学：AutoGen 是“会开会”，CrewAI 是“上流水线”。

选型时可以做成本估算。设每轮消息长度为 c(|h_t|)，LLM 裁决会额外产生一次模型调用：

对比框架不是比谁更好，而是看哪种“主持风格”贴合任务：需要多人自由 brainstorming 选 AutoGen 的 GroupChat；需要按职责流水线执行选 CrewAI 的 Process。主持人风格没有优劣，合不合适才见真章。

---

AI 应用场景

Python 演示

"""简化版 GroupChatManager：演示四种调度策略"""import random  class Agent:    def __init__(self, name, role):        self.name = name        self.role = role     def reply(self, msg):        return f"[{self.role}] 针对「{msg}」给出方案"  class GroupChatManager:    def __init__(self, agents, mode="round_robin"):        self.agents = agents        self.mode = mode        self.history = []        self._seq = 0     def select_speaker(self):        n = len(self.agents)        if self.mode == "round_robin":            idx = self._seq % n        elif self.mode == "random":            idx = random.randint(0, n - 1)        elif self.mode == "manual":            print("指定发言者编号: ", end="")            idx = int(input())        elif self.mode == "auto":            scores = [(len(a.role) + i) % 3 for i, a in enumerate(self.agents)]            idx = scores.index(max(scores))        else:            raise ValueError("unknown mode")        self._seq += 1        return idx     def run(self, rounds):        for _ in range(rounds):            idx = self.select_speaker()            speaker = self.agents[idx]            last = self.history[-1] if self.history else "项目启动吧"            reply = speaker.reply(last)            self.history.append(f"{speaker.name}: {reply}")        return self.history  if __name__ == "__main__":    team = [        Agent("Alice", "产品经理"),        Agent("Bob", "工程师"),        Agent("Carol", "设计师"),    ]    gm = GroupChatManager(team, mode="round_robin")    for line in gm.run(6):        print(line)

1. class GroupChatManager:对应 AutoGen 中管理发言顺序与历史的调度器核心类。
2. self.history = []这就是“共享纪要”，每轮发言都追加进来，供全体 Agent 查看。
3. self._seq = 0计数器记录已进行的轮次，用于轮询取模，加下划线后缀避免与同名方法冲突。
4. idx = self._seq % n轮询调度的核心：用“当前轮次除以人数取余”决定轮到谁。
5. idx = random.randint(0, n - 1)随机调度：直接用随机数挑一个 Agent，完全不可预测。
6. scores.index(max(scores))简化版 LLM 裁决：给每个 Agent 打一个启发式分数，取最高分。
7. last = self.history[-1] if self.history else "项目启动吧"从共享历史取最近一条消息作为本轮讨论的输入。

常见误区

面试题