AutoGen多Agent：协作框架使用

可视化演示

动态演示AutoGen多Agent的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

Agent 基础概念

装修队里没有万能工。设计师懂风格，水电工懂管线，监理懂标准，大家各管一摊。如果让水电工去设计北欧风，结果是灾难。同样，在 AI 世界里，一个通用大模型什么都懂一点，但让它同时做策划、写稿、审查、执行，往往顾此失彼。于是 AutoGen 提出一个思路：把大模型包装成一个有明确人设的 Agent——就像给每位工人发一顶帽子，戴上帽子就知道自己该干什么。

在 AutoGen 中，Agent 是一个可对话的智能实体。每个 Agent 内部至少包含三样东西：一个大模型作为“大脑”负责推理，一组工具作为“手脚”负责执行，一份对话历史作为“记忆”记录来龙去脉。AutoGen 的核心类 ConversableAgent 允许你通过 system_message 设定人设，通过 llm_config 配置大模型连接，通过 human_input_mode 决定是否允许人工介入。Agent 的类型也很多样：有带大模型的智能体，也有不带模型、只转达人类指令的“用户代理”。

$$\pi_{\theta}(a_t \mid o_t, h_t)$$

1. 策略函数：策略函数表示 Agent 在给定信息下选择某个动作的概率分布，是 Agent 决策的“大脑”。

$$\pi_{\theta}$$

2. 动作：表示当前时刻 Agent 要执行的动作，比如发送一条消息或调用一次工具。

$$a_t$$

3. 观察与历史：是当前输入观察，是过去所有消息组成的记忆，两者共同决定动作。

$$o_t, \; h_t$$

4. 条件与参数：竖线表示“在……条件下”，是模型的可训练参数。

$$\mid \theta$$

回到装修队：大模型是师傅的“手艺底子”，工具是“工具箱”，对话历史是“施工日志”。AutoGen 就是发帽子的人——它让你轻松创建各种专业的 Agent，并让它们各就各位。使用多 Agent 的第一步，永远是像给装修队分工一样，想清楚每个 Agent 的人设和边界。

对话协作模式

装修队开工后，师傅们怎么沟通？没有人会绕过群聊直接去拆别人刚贴好的瓷砖。每一次沟通都必须有来有回、说得明白：谁说的、对谁说的、内容是什么。如果只是喊一嗓子“帮我一下”，对方根本不知道要干什么。多 Agent 协作的第一课，就是把“话”说规范。

AutoGen 中 Agent 之间通过消息（Message）对话。消息不是简单的字符串，而是一个结构化的数据对象，包含 role（身份）、content（内容）以及可选的 meta（元数据，比如工具调用结果、时间戳）。这种结构化消息让 Agent 能准确知道“这句话是谁说的、想表达什么”，也让对话管理器能看清全局、做出下一步路由决策。这就是“对话驱动”的协作模式：Agent 之间不需要写复杂的函数接口，只要会发消息就能协作。

$$H_t = \{ m_1, m_2, \ldots, m_t \}, \quad m_i = ( \text{role}_i, \text{content}_i, \text{meta}_i )$$

1. 历史集合：从第 1 条到第 t 条消息的集合，相当于装修群的完整聊天记录。

$$H_t = \{ m_1, m_2, \ldots, m_t \}$$

2. 单条消息：每条消息都是一个三元组，携带身份、正文和元数据。

$$m_i = ( \text{role}_i, \text{content}_i, \text{meta}_i )$$

3. 身份：消息发送者的角色名，比如 planner 或 user，让接收者知道是谁在说话。

$$\text{role}_i$$

4. 正文与元数据：一个管“说了什么”，一个管“附带什么信息”（例如工具返回的报错）。

$$\text{content}_i, \; \text{meta}_i$$

这种对话驱动的模式很像群聊：所有消息记录在案，后来的师傅翻翻记录就能明白工程来龙去脉，不需要反复口头复述。但也要注意，历史无限累积意味着 token 消耗持续上涨——群聊记录越长，“会议成本”越高，这也是后文要讲轮次约束的原因。

群聊编排机制

把策划、编辑、校对都拉进一个微信群，七嘴八舌立刻开干——行吗？不行。没人决定“此时该谁发言”，结果就是策划在布置任务，编辑在回复旧话题，校对在刷屏，群彻底乱套。所以装修群一定有一个项目经理在“主持”：谁先讲、谁接话、吵起来了怎么拉回正题。

AutoGen 的 GroupChat 就是这样一个群：它把所有 Agent 拉进来，共享一个消息池。GroupChatManager（简称 GM）是群主，负责两项关键工作：一是维护发言顺序——每轮从所有 Agent 中挑选一个“最有资格发言”的人；二是维护终止条件——达到 max_round（最大轮数）就散会。没有 GM 的群聊只是消息列表，有了 GM 才变成有序的会议。

$$s_{t+1} = \arg\max_{s \in \mathcal{S}} \; \text{Score}(s \mid H_t)$$

1. 下一位发言人：表示下一步被允许发言的 Agent。

$$s_{t+1}$$

2. 候选集合：群里所有可以发言的 Agent 组成的集合。

$$\mathcal{S}$$

3. 打分函数：GM 根据对话历史为每个候选者计算“该谁上场”的分数。

$$\text{Score}(s \mid H_t)$$

4. 最大值：选分数最高的 Agent，也就是“最该说话的人”。

$$\arg\max_{s \in \mathcal{S}}$$

GM 的打分不是硬编码规则，它本身也用一个大模型来“读气氛”：看对话进行到哪一步、哪个 Agent 的话还没被回应、哪个角色最需要出场，然后动态挑人。这种路由方式能应对突发走向——比如校对发现问题后，GM 会把发言权交回编辑，而不是机械地按顺序点名。一个好的群主让会议高效：不冷场、不刷屏、有结论，AutoGen 的 GM 就是这种会“控场”的 AI 群主。

工作流设计

装修不能想干就干。先砸墙后改水电，改完水电才贴砖，瓷砖干透再做木工——这叫工序。但也有能并行的地方：主卧做木工的同时，客厅可以改水电，只要互不干扰就行。施工图就是把每道工序的安排画清楚。AutoGen 的“工作流设计”，就是 AI 协作版的施工图。

工作流设计的本质是对多 Agent 协作过程的整体编排。常见三种模式：线性流程，A 做完给 B、B 做完给 C，适合依赖关系强的任务；并行协作，多个 Agent 各自处理独立子任务再汇总，适合大规模分头行动；动态调度，每一步根据中间结果决定下一步派谁上场，灵活性最高但最难控制。绘制工作流时，可以把每个 Agent 看成图上的一个节点，消息流向看成边。

$$G = (V, E), \quad V = \{ a_1, a_2, \ldots, a_n \}, \quad E \subseteq V \times V$$

1. 有向图：表示整个工作流的结构。

$$G = (V, E)$$

2. 节点集合：每个节点是一个 Agent，比如策划、编辑、校对。

$$V = \{ a_1, a_2, \ldots, a_n \}$$

3. 边集合：每条边表示消息从一个 Agent 流向另一个 Agent。

$$E \subseteq V \times V$$

4. 子集与笛卡尔积：边只是“所有可能组合”的子集，说明不是任意两个 Agent 之间都必须有连线。

$$\subseteq, \; \times$$

在 AutoGen 中，最简单的线性工作流就是两个 Agent 的对话；复杂任务可以拆成多个两两对话，必要时还能用嵌套对话（nested chat）——一个 Agent 在自己内部再开一个小型讨论组。把工作流画成图之后，你能一眼看出哪里可以并行、哪里必须等待、哪里可能出现瓶颈。有了施工图，监理才知道盯哪个节点；设计好工作流，多 Agent 才不会干到一半就卡壳。

代码执行环境

装修师傅手艺再好，没有电钻也只能用锤子慢慢敲。AutoGen 给 Agent 配了“工具箱”——代码执行器，让 Agent 不仅能动嘴，还能动手：写段代码算数据、生成图表、跑一遍测试用例，然后把真实结果反馈回对话。

AutoGen 的代码执行机制是这样的：Agent 在对话中输出代码块，代码执行器负责运行并返回结果。执行方式有几种选择：本地执行最快，但直接碰宿主机，适合完全可信的环境；Docker 沙箱用容器隔离，推荐用于不可信代码；还可以指定 work_dir 工作目录，让执行过程中产生的文件可以持久化。此外，通过工具调用（function calling），Agent 还能调用外部 API——相当于把“工具箱”扩展成整个互联网。

$$R = \begin{cases} O, & \text{if } c = 0 \\ \text{Err}, & \text{otherwise} \end{cases}$$

1. 执行结果：代码运行后返回给对话的最终值。

$$R$$

2. 正常输出：退出码为 0 时返回的标准输出，比如打印的表格、计算结果。

$$O, \; \text{if } c = 0$$

3. 退出码：进程结束时的状态码，0 表示成功，非 0 表示异常。

$$c = 0$$

4. 错误分支：退出码非 0 时返回错误信息，Agent 看到报错就能自己修 bug。

$$\text{Err}, \; \text{otherwise}$$

代码执行的最大价值是闭环验证：Agent 写完代码不只给人看，而是真的跑一遍，把输出或报错贴回群聊，再根据反馈继续修改。这就从“纸上谈兵”变成了“真刀真枪”。给师傅配上趁手的电钻，还要戴上安全帽——Docker 沙箱就是那顶安全帽，让 Agent 放心干活，也不怕拆了承重墙。

结果聚合策略

工地干完，业主问：怎么样？项目经理不能只说“都还行”，得给出明确结论：户型完成度多少、哪些地方返工了、监理怎么评价。如果几位师傅对某个方案有分歧，还要投票或按权威程度加权——不能让门卫大爷和总工程师一票相等。

结果聚合是多 Agent 协作收尾的关键环节。常见策略有三种：一是投票机制，每个 Agent 对候选方案投一票，简单多数胜出，独立角度的投票能互相制衡；二是加权汇总，给不同角色分配不同权重，比如评审 Agent 的权重高于执行 Agent，再求加权平均；三是最优选择，当每个 Agent 都产出完整方案时，用一个评分卡或额外的裁判 Agent 挑出最佳。

$$\text{Final} = \sum_{i=1}^{n} w_i \cdot o_i, \quad \text{s.t.} \quad w_i \geq 0, \; \sum_{i=1}^{n} w_i = 1$$

1. 最终结果：聚合后产出的明确结论，项目经理给业主的交付。

$$\text{Final} = \sum_{i=1}^{n} w_i \cdot o_i$$

2. 意见：第 i 个 Agent 给出的观点、方案或评分。

$$o_i$$

3. 权重：第 i 个 Agent 的发言分量，代表它在这次决策中的权威程度。

$$w_i$$

4. 约束条件：权重非负且总和为 1，这样最终结果就是加权平均，尺度不会跑偏。

$$w_i \geq 0, \; \sum_{i=1}^{n} w_i = 1$$

在 AutoGen 中，聚合不一定是内置函数，更多是你通过工作流设计出来的：你可以让一个专门的“汇总 Agent”去读所有人的输出并提炼结论，也可以在群聊最后让 GM 把意见收敛成答案。关键是聚合策略要匹配任务性质——事实型任务用投票，开放型任务用加权或最优选择。项目经理的水平不在于每个工种都会干，而在于能把大家的成果拧成一句可靠的交付。

实践应用技巧

老项目经理接单多了，总结出几条铁律：小活儿别拉太多人，群聊别开太久，每个人工位要写清楚，手里的预算要盯紧。这些经验照搬到 AutoGen 上，每一条都成立。

第一条，小任务慎用多 Agent：每个 Agent 每次发言都是一次 LLM 调用，Agent 越多、轮次越长，成本越高。第二条，给每个 Agent 写清 system prompt：职责边界越明确，跑偏概率越低。第三条，设置合理的 max_round：既要给足讨论空间，又要防止无限扯皮。第四条，监控 token 消耗：根据预算反推 Agent 数量和轮次上限，别等账单出来才后悔。

$$N_{\text{calls}} = \sum_{r=1}^{R} k_r$$

1. 总调用次数：整场多 Agent 协作消耗的 LLM 请求总数，直接决定成本。

$$N_{\text{calls}}$$

2. 轮次变量：从第 1 轮跑到第 R 轮，R 通常由 max_round 控制。

$$r = 1, \ldots, R$$

3. 每轮参与数：第 r 轮实际发言的 Agent 数量。

$$k_r$$

4. 求和符号：把每一轮参与发言的人数全部加起来，就得到总调用量。

$$\sum_{r=1}^{R}$$

从公式能看出，控制成本的两条路分别是削减轮次和限制每轮发言人数。这也是为什么“排列组合式”群聊（所有 Agent 每轮都发言）非常烧钱，而精心设计的工作流（每轮只点 1-2 个人）反而又快又省。装修队的老项目经理赢在排兵布阵，不在人海战术——用 AutoGen，同样要学会做减法。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# AutoGen 多 Agent 群聊协作示例from autogen import ConversableAgent, GroupChat, GroupChatManager CONFIG = {"config_list": [{"model": "gpt-4o", "api_key": "YOUR_API_KEY"}]} # 1. 定义装修队成员: 策划、编辑、校对planner = ConversableAgent(    name="planner",    system_message="你是项目经理小王, 负责拆解需求、分配任务、汇总成果。",    llm_config=CONFIG,    human_input_mode="NEVER",) writer = ConversableAgent(    name="writer",    system_message="你是文案编辑小李, 负责写出通俗易懂的正文。",    llm_config=CONFIG,    human_input_mode="NEVER",) critic = ConversableAgent(    name="critic",    system_message="你是质检员小张, 负责挑错并给出修改建议。",    llm_config=CONFIG,    human_input_mode="NEVER",) # 2. 拉一个装修沟通群, 群成员仅限上述三位, 最多聊 8 轮group_chat = GroupChat(    agents=[planner, writer, critic],    messages=[],    max_round=8,) # 3. 任命群主 GroupChatManager, 由它控制发言顺序manager = GroupChatManager(    groupchat=group_chat,    llm_config=CONFIG,) # 4. 用户代理人发起需求, 启动整场群聊user_proxy = ConversableAgent(    name="user_proxy",    llm_config=False,    human_input_mode="NEVER",) user_proxy.initiate_chat(    manager,    message="请写一篇 200 字以内、面向小白的 AutoGen 多 Agent 介绍。",) # 5. 复盘群聊记录for msg in group_chat.messages:    who = msg.get("name", "user_proxy")    print(f"[{who}] {msg.get('content', '')}")

1. CONFIG = {"config_list": [{"model": "gpt-4o", "api_key": "YOUR_API_KEY"}]}大脑接线图，指定用哪个模型、怎么连服务；实际使用时替换成自己的 API Key。
2. system_message="你是项目经理小王..."给 Agent 立人设，相当于给师傅发工牌，告诉它“你是谁、该干什么”。
3. human_input_mode="NEVER"全自动发言人，不需要人工确认，师傅领了任务就自己干活。
4. GroupChat(agents=[planner, writer, critic], messages=[], max_round=8)拉群并设定轮次上限，防止三位 Agent 无限扯皮。
5. GroupChatManager(groupchat=group_chat, llm_config=CONFIG)任命群主（GM），由它负责每轮“该谁发言”的路由调度。
6. user_proxy.initiate_chat(manager, message=...)用户代理人在群里抛出一个话题，启动整场协作。
7. for msg in group_chat.messages翻聊天记录，复盘每个 Agent 都说了什么，方便排查问题和展示成果。

常见误区

面试题