最近我把 AutoGen 从 0.2 一路追到 0.4断断续续用它在本地搭了三套多智能体协作系统跑了不下上百次对话。说实话第一次跑通几个 Agent 互相讨论、追问、修改代码的时候确实有被惊艳到但后面被它各种奇奇怪怪的死循环、上下文爆掉、工具调用失败折腾得也很酸爽。这篇文章不打算给你做 API 文档搬运就聊聊我真实搭多智能体系统的过程、踩过的坑、以及 AutoGen 到底适合做什么、不适合做什么。如果你刚好在纠结要不要用 AutoGen 做多智能体协作或者已经在用但总觉得哪里别扭这篇应该能给你一些参考。1. 先搞清楚AutoGen 到底解决什么问题1.1 从一个真实痛点说起我最早的需求其实很简单让大模型帮我分析一份技术方案同时模拟“甲方”和“乙方”两种立场来回讨论最后给出一个折中结论。用单 Agent 的方式把两个角色塞进一段 system prompt 里结果模型经常说着说着角色就串了一会儿像甲方口吻一会儿又变成了乙方最后结论也是模棱两可。后来我尝试用传统方式硬拆写两套独立的 Prompt分别调用模型再把输出拼在一起。这虽然避免了角色串味但本质是轮询没有真正的“对话状态”。甲方 Agent 不知道乙方 Agent 上一轮说了什么回复全靠我手动拼接上下文一旦多几个角色代码就成了一堆胶水。AutoGen 解决的核心问题恰恰是“让多个 Agent 在同一段会话里自主协作”。它把你需要手动维护的对话历史、角色切换、发言顺序、终止条件全部抽象成框架能力。你在本地定义一个 AssistantAgent再定义一个 UserProxyAgent让它们互相发消息模型会在内部维护多轮上下文Agent 之间可以自然衔接。1.2 多智能体不是“多个 API 轮流调用”网上很多文章把多智能体吹得很玄但按照我的理解它本质上是一套“对话路由系统”。多个 API 轮流调用你还需要自己写状态机来记录谁说过什么、下一步轮到谁而 AutoGen 把这条状态机内部化了你只需要关注每个 Agent 的职责和消息格式。它引入了几类核心抽象ConversableAgent可以参与对话的智能体基类。AssistantAgent默认用 LLM 补全消息的助手可以配置 system prompt。UserProxyAgent默认代表人类执行代码、获取输入也可以自动执行工具函数。GroupChat多 Agent 群聊的会话管理对象。GroupChatManager负责协调群聊顺序、选择下一发言人。真正跑起来以后你才会意识到这些抽象的价值。比如UserProxyAgent不只是“模拟用户”它承担了一个关键职责执行代码。你让大模型写一段 Python 脚本它不会自己运行但UserProxyAgent可以自动在本机跑这段代码再把执行结果反馈给模型。这等于给 Agent 装上了“手”让它能自己验证想法。多智能体的难点从来不是“让多个模型回答”而是“让它们有序地围绕同一个目标推进”。AutoGen 用群聊的机制来约束这种秩序我听过的更形象的说法是——它更像一个“带主持人的圆桌会议”而不是“广播站”。1.3 它擅长什么又真的不适合什么根据自己的实测我总结了几条边界新手可以提前避坑擅长的事需要多角色观点碰撞的任务比如方案评审、产品需求辩论、代码 Review。需要“模型写代码 自动执行 根据结果修改”的闭环任务。需要模拟用户反馈、反复迭代内容的场景比如让模型扮演测试人员挑刺。需要把大任务拆成子任务让不同 Agent 分头负责的探索性流程。不擅长的事高并发、低延迟的线上推理管道。AutoGen 的对话循环是重量级的每次发言都带完整历史不适合做面向用户的实时接口。简单的单轮调用。如果你只需要一次 completion没必要引一个 Agent 框架反而拖慢速度和成本。需要强保证的自动化业务流程。Agent 的自由对话天然有不确定性除非你做好校验和兜底否则不建议直接对接生产系统。另外特别提醒一下多智能体不是越多越好。我做过 2 个 Agent 的协作稳定性和效率都非常高做到 5 个以上 Agent 的时候对话圈数呈指数上涨token 消耗非常吓人而且经常讨论半天没有收敛。后面我会专门讲如何控制这种情况。2. 我为什么选 AutoGen而不是 LangChain 或其他框架2.1 从 LangChain 迁移过来的对比心得在投入 AutoGen 之前我用 LangChain 搭过一个简单的 Agent 工具调用流程。LangChain 的思路是“链式编排”把每一步处理串成一个 pipeline再通过 Agent 决定调用哪个工具。理论上很灵活但实际维护起来有几个痛点状态管理比较隐晦回调、记忆、中间步骤交错在一起出了问题不好追。多个 Agent 协作不是一等公民更多是“链 Agent”的组合写起来很别扭。调试需要层层打印看不到完整的对话流转。AutoGen 给我的第一感觉是“所有控制流都是一场对话”。调试的时候直接把消息历史打出来谁在什么时间说了什么一目了然。这种可视性对开发多智能体系统太重要了。我整理了一个选型对比表都是个人感受维度AutoGenLangChain核心编排方式对话群聊消息驱动链式调用 Agent多 Agent 支持原生支持 GroupChat需要额外组合调试体验消息历史直观适合查看对话流链路较长需自己梳理中间状态工具调用通过 register_function 绑定格式统一有 Tool 抽象但集成较重学习曲线概念少上手快概念多但生态更广当然LangChain 的优势是周边工具丰富、集成面广如果你的需求偏向“重管道、多资源整合”它依然值得考虑。但如果核心诉求就是“让多个 AI 角色互相讨论、协同完成任务”AutoGen 的结构更贴合、也更直接。2.2 AutoGen 的核心抽象Agent 不是“人”是“流程节点”很多人第一次接触 AutoGen 时会下意识把 Agent 当成一个“有名字的模型”。我的理解是一个 Agent 就是一个流程节点它持有自己的上下文、能力和输出规则。你可以让两个 Agent 用同一个模型只要 system prompt 不同、工具列表不同它们就是两个不同的节点。看一个最简单的定义from autogen import ConversableAgent, AssistantAgent, UserProxyAgent assistant AssistantAgent( nameassistant, system_message你是一个严谨的架构师只输出结论和理由。, llm_config{ config_list: [{model: gpt-4o, api_key: your_key}], temperature: 0.3, }, )ConversableAgent是它们的公共基类意味着你既可以用内置的AssistantAgent也可以继承自定义 Agent。灵活度不错实际做复杂任务时我经常在自定义 Agent 里覆写generate_reply来做特殊处理比如注入外部数据、检查关键词、决定是否终止对话。另一个容易混淆的概念是UserProxyAgent。它的名字带 User但它不一定要人工输入也可以配置成自动执行工具。它的默认行为是收到消息后如果需要执行代码就直接在本机运行然后把 stdout/stderr 作为新消息发回去。如果配置了human_input_modeNEVER它就变成一个“自动执行者”适合无人值守的任务。2.3 设计理念上的三个关键选择用久了你会发现 AutoGen 的设计者做了几个很有味道的取舍第一对话即控制流。它不搞复杂的图编排而是用自然语言对话推动流程。一个 Agent 说“我来写代码”另一个 Agent 说“我负责任务验收”流程的推进藏在消息里读起来非常直观。代价是隐私性和确定性稍弱所以必须自己定好终止条件。第二代码优先。UserProxyAgent内部集成了代码执行器模型输出的 Python 代码可以直接跑。这种“让 Agent 自己动手”的模式特别适合数据分析和原型验证。我做过一个需求让 Agent 根据 CSV 文件自动绘制图表它自己写完 matplotlib 代码执行成功再根据运行结果调整图表细节整个过程几乎没有人工介入。第三人类可随时插话。即使多 Agent 跑得热火朝天你也可以通过human_input_mode插入意见或者用人工输入作为某个 Agent 的回复。这种“人在回路”的能力在生产环境很有价值比如让 AI 负责草拟内容人类负责最终拍板。3. 搭建多智能体协作系统的实操过程3.1 环境准备与安装依赖我本地用的是 Python 3.11安装很简单pip install pyautogen如果你想用最新特性可以直接装 nightlypip install pyautogen[teams] # 包含更多实验性功能不一定稳定安装完成后第一件事是配置模型。AutoGen 支持 OpenAI 兼容接口所以即使你本地跑的是开源模型只要暴露成了兼容 API也能接进来。我最初直接用 OpenAI后面换成了本地模型做测试配置方式几乎一样。# config_list 是 AutoGen 管理模型配置的通用格式 config_list [ { model: gpt-4o, api_key: sk-xxxx, base_url: https://api.openai.com/v1 # 也可以是本地服务地址 } ] llm_config { config_list: config_list, temperature: 0.4, timeout: 120, }这里有个容易踩坑的点config_list里可以配多个模型备选AutoGen 会在请求失败或超时时自动切换。我一度以为它是做模型“轮询负载均衡”后来细看发现它主要做高可用容错。如果你的不同模型能力差异大建议不要把能力相差很大的模型放同一个列表里否则同一个任务可能这次是 GPT-4 回复、下次变成小模型回复效果波动很大。3.2 先造一个只会“动嘴”的智能体我先定义一个纯对话的助手不接任何工具当作“唠嗑版”。from autogen import AssistantAgent planner AssistantAgent( namePlanner, system_message 你是一个项目规划专家。用户会给你一个目标你负责 1. 把目标拆解成 3-5 个步骤。 2. 每个步骤标注负责人和验收标准。 3. 不要讨论和计划无关的内容。 , llm_configllm_config, ) user_proxy UserProxyAgent( nameUser, human_input_modeNEVER, max_consecutive_auto_reply2, is_termination_msglambda msg: TERMINATE in msg.get(content, ), )这里我故意没接工具让它先跑通最基本的“你问我答”。UserProxyAgent里有一个参数max_consecutive_auto_reply意思是连续自动回复的次数上限。如果设成 2那表示在用户没有新指令的情况下最多自动往下推两轮就停下。很多人一上来就把这个值设成 10 甚至更大结果对话跑了好几圈都不停。我的实践经验是大多数需要收敛的任务max_consecutive_auto_reply设在 1 到 3 之间就够了超过 5 就很容易放飞。启动一次对话user_proxy.initiate_chat( planner, message我要用 AutoGen 搭一个自动写周报的系统帮我出一份计划。, )看到输出后你能明显感觉到 AutoGen 很自然地把“拆解步骤”的任务完成了。这一步的核心不是“哇好神奇”而是让你理解 Agent 的消息通道User发消息给PlannerPlanner把回复作为新消息发回来一轮一轮往复直到触发终止条件。3.3 让多个智能体真正“聊起来”GroupChat 与 GroupChatManager单个 Agent 太寂寞多智能体才是 AutoGen 的主场。我搭的第一个多智能体场景是一个“模拟评审会”产品、开发、测试三个角色围绕一个需求讨论。from autogen import GroupChat, GroupChatManager product AssistantAgent( nameProduct, system_message你是产品经理负责描述需求和价值注意逻辑清晰。, llm_configllm_config, ) developer AssistantAgent( nameDeveloper, system_message你是技术负责人分析实现方案和复杂度直接指出风险。, llm_configllm_config, ) tester AssistantAgent( nameTester, system_message你是测试负责人关注验收标准和边界场景。, llm_configllm_config, ) group_chat GroupChat( agents[product, developer, tester, user_proxy], messages[], max_round10, # 整个群聊最多 10 轮 speaker_selection_methodauto, # 自动选择下一个发言人 ) manager GroupChatManager( groupchatgroup_chat, llm_configllm_config, ) user_proxy.initiate_chat( manager, message我们要做一个内部工具自动汇总每日错误日志并发到群里请大家评审。, )GroupChat是核心容器它维护消息历史并决定下一个发言者是谁。speaker_selection_method有几种模式auto让GroupChatManager动态决定下一个发言者。round_robin按顺序轮流发言。自定义函数你可以传入一个选择函数完全控制发言顺序。刚开始我推荐用round_robin因为可控性强每个 Agent 都有均等机会发言不会出现某个 Agent 一直抢麦。跑通之后再切auto配合不同角色的 system prompt 让模型自己选择谁该说话对话会更自然。max_round是群聊总轮次上限这个非常重要。我建议按任务复杂度定简单评审 8 轮以内复杂方案评审 15 轮以内。设定得太高token 消耗会急剧上升设定得太低又可能讨论不出结论。我的经验是先设 15 跑一次看大概几轮收敛再下调到合适的值。3.4 给智能体装上“手”接入工具函数多智能体协作最大价值在于它们不仅会聊还能干活。AutoGen 通过register_function把 Python 函数暴露给模型调用。我举个实际例子。我需要一个 Agent 帮我查询服务器当前磁盘使用情况然后另一个 Agent 负责生成告警报告。于是我先写一个工具函数def check_disk_usage(server_ip: str) - str: 检查服务器磁盘使用率返回百分比 # 实际中这里会执行 ssh 或读取监控接口 import random usage random.randint(40, 95) return f{server_ip} 当前磁盘使用率{usage}% from autogen import register_function register_function( check_disk_usage, callerdeveloper, # 哪个 Agent 可以调用这个函数 executoruser_proxy, # 由谁来执行 description检查指定服务器的磁盘使用率, )注意这里的caller和executor分别是“可以调用该函数”的角色和“执行该函数”的角色。通常caller是AssistantAgentexecutor是UserProxyAgent。因为UserProxyAgent有能力真正执行代码和工具。这看起来很简单但实际项目里你可以把任意函数塞进去比如发邮件、写数据库、调用内部 API。我在一个知识库问答系统里把检索函数注册给了RAGAgent再由它把检索结果转述给用户效果比单纯让模型硬记知识库强很多。一个非常关键的提示工具函数必须有清晰且简单的docstringAutoGen 会把函数描述和参数 schema 发给模型。如果描述含糊模型可能不知道怎么调用或调错参数。我见过不少人工具调用失败就是因为 docstring 写得太随意。3.5 终止条件与最大轮次让我调到头秃的参数多智能体系统最常见的失控现象就是“聊个不停”。调试终止条件是我花时间最多的地方。AutoGen 判定对话结束有两种方式消息中出现指定关键词比如TERMINATE。达到最大轮次max_round。我推荐双管齐下。先写一个终止函数def is_termination_msg(msg): content msg.get(content, ) if content.strip().upper().endswith(TERMINATE): return True # 也可以根据内容判断比如包含“最终结论是” return False user_proxy UserProxyAgent( nameUser, human_input_modeNEVER, is_termination_msgis_termination_msg, )不过要注意让模型自己输出TERMINATE并不总是可靠。模型可能忘了输出或者提前输出。所以max_round是最后的兜底一定要设。我调参的经验是给每个 Agent 的 system prompt 里加上明确的收敛要求比如“当你认为讨论已经达成最终结论时回复 TERMINATE 并附上结论摘要”。再加一层human_input_mode控制重要节点让人类确认这样即使模型误判人也能拉回。另外max_consecutive_auto_reply也很关键。比如一个UserProxyAgent连续执行了 3 次工具调用还没得到最终结论如果达到上限就会停下来。这个参数能让对话不无限续杯。4. 真实案例复盘我搭的“技术方案评审小分队”4.1 系统设计三个 Agent 各司其职前几天我正好要评审一个新功能的技术方案就用 AutoGen 搭了一个“评审小分队”。参与 Agent 有四个产品经理 Agent、架构师 Agent、测试 Agent以及我自己通过UserProxyAgent模拟。它们围绕同一份需求文档从三个不同视角提出意见最后输出综合评估。为什么选这四个角色因为一场技术方案评审本来就是这些角色之间的对话。产品经理关心“需求是否被满足”架构师关心“实现方案是否合理、扩展性怎么样”测试关心“边界条件和风险”。让这三个 Agent 在一个群里互相提问比让单个模型同时扮演所有角色更接近真实的评审过程也更容易暴露矛盾点。4.2 每个 Agent 的 prompt 配置与心法我贴一下实际的 system prompt已脱敏方便你感受写法product_sys 你是产品经理 Agent负责从用户价值和需求完整性角度评审技术方案。 要求 - 如果方案没有直接解决用户痛点必须提出质疑。 - 考虑需求的优先级和投入产出比。 - 回答要简洁最多 200 字不废话。 - 在你的疑问被解决后回复 产品侧无异议。 arch_sys 你是架构师 Agent负责从技术角度评估方案可行性和扩展性。 要求 - 指出设计中的风险、复杂度以及备选方案。 - 给出明确的改进建议不要泛泛而谈。 - 如果认为方案可行回复 架构侧无异议。 - 回答控制在 300 字以内。 test_sys 你是测试负责人 Agent负责从质量保障角度评审方案。 要求 - 找出至少 1 个边界场景或异常情况。 - 验证方案是否有明确的可测试性。 - 如果认为风险可控回复 测试侧无异议。 - 回答控制在 200 字以内。我写 prompt 的心法是每个 Agent 都要有“自己的立场输出约束结束条件”。缺少任何一条Agent 就容易变成复读机或者跑题。立场决定了它关注什么输出约束控制了篇幅和风格结束条件让它可以收敛。这里还藏着一个细节角色提示中的“无异议”并不是真正的结束而是给GroupChatManager一个判断信号。当三个 Agent 都说了“无异议”再配合后续一轮让用户总结整个评审就自然收尾了。4.3 运行过程实录与输出摘要我挑一段运行过程给你看真实的流转节奏已简化User: 现在我们评审新功能自动日报生成。该功能每天定时拉取日志汇总为 Markdown 报告并发送到指定群。 Product: 用户价值明确但日报的接收人是否可以自定义如果不能每个团队都要改代码成本高。 Architect: 建议把接收人列表做成配置项用 YAML 管理避免硬编码。整体方案可行但定时任务需要处理并发和失败重试。 Tester: 需要考虑日志为空、进程崩溃、以及多个任务同时运行的场景。建议增加一个 dry-run 模式方便测试。 User: 好的请各位基于以上意见给出最终评估。 Product: 如果支持配置化接收人产品侧无异议。 Architect: 架构侧无异议但需要补充重试策略。 Tester: 测试侧无异议我会增加边界用例。 Product: 最终结论采用配置化接收人 失败重试 dry-run 模式。产品侧确认。 Architect: 确认。 Tester: 确认。你注意到没有模型会自己根据别人的发言调整观点。整个过程大概 10 轮左右耗时 2 分钟token 消耗接近 5 万。如果让我手动写这个评审文档至少需要一两个小时而且往往只想到了正面意见。多 Agent 的交叉提问确实能逼出一些容易被忽略的细节。4.4 资源消耗与成本观察这个案例用四个 Agent包含 UserProxyAgent实际计费按 token 算。我记录了参考数据配置轮数输入 token输出 token预估成本3 个 Agent GPT-4o10约 3.6 万约 1.1 万约 0.5 美元4 个 Agent 本地模型12约 4.2 万约 1.3 万忽略不计6 个 Agent GPT-4o25约 10 万约 3.5 万约 1.6 美元从数据能看出两个趋势Agent 数量越多、对话轮数越多token 消耗呈指数级增长。所以我的建议是能用 3 个 Agent 解决的问题绝不上 5 个。优先使用本地模型做多轮协作测试跑通逻辑后再切付费模型。限制max_round和单个 Agent 的输出max_tokens。成本不光是钱还有时间。网络请求加上多轮往返一个复杂对话可能要几分钟。如果你想做试验最好把timeout设得宽松一些否则还没聊到一半就超时中断了。5. 常见问题速查与排错经验5.1 对话陷入死循环死循环基本是每个用 AutoGen 的人都会遇到的头号问题。表现就是几个 Agent 来回“你说得对”“我同意”“我也同意”永远不进入下一阶段。我排错时按这个顺序来检查max_round是否设置为一个有限值如果没设默认可能非常大。检查每个 Agent 的 system prompt 是否明确了结束条件。检查is_termination_msg是否真的能匹配模型输出的终止词。检查speaker_selection_method如果是auto模型可能频繁选择同一个 Agent然后不断产生相似回复。有一次我排查了半天最后发现是is_termination_msg里用的关键词是TERMINATE但模型输出的是terminate。有句号我的判断函数要求字符串相等自然匹配不上。改成content.upper().endswith(TERMINATE)就解决了。5.2 上下文越聊越长直接爆掉多轮对话会把完整历史传给模型轮数一多上下文长度就爆炸。尤其 Agent 用工具执行完代码之后输出会塞进历史导致下一次请求越来越大。对策有几种设置max_tokens限制每个回复的长度。用summary_method做对话摘要把旧消息压缩后替代原文。AutoGen 支持在群聊里启用摘要这样历史不会无限膨胀。在 Prompt 中明确要求“不要重复之前的内容直接给增量信息”。我用summary_methodlast的时候比较多也就是只保留最近的总结消息避免旧消息塞满上下文。如果你的任务需要保留所有细节那就只能接受成本或者换更长上下文的模型。5.3 工具调用总是“虚假成功”有时模型会“假装”调用了工具然后直接编造结果。比如我定义了一个check_disk_usage模型可能不调用函数而是在回复里写“磁盘使用率 75%”。这不一定是模型坏更可能是不确定函数该什么时候用。我的解决办法有三个在 system prompt 中明确写“当需要获取真实数据时你必须调用工具禁止自己编造数值”。在工具函数内部做校验返回失败信息而不是抛出异常让模型能够感知异常。在UserProxyAgent中配置code_execution_config为{use_docker: False, work_dir: workspace}让执行过程有迹可循方便排查。还有一点工具函数返回的内容会作为普通消息进入对话所以尽量让返回结果包含足够的“说话者信息”比如在返回字符串前加[check_disk_usage]前缀这样排查消息历史时能看清是工具输出而不是模型自述。5.4 多智能体答非所问各说各话如果几个 Agent 话题漂移多半是角色职责和上下文的约束不够。speaker_selection_method设为auto时模型有时会突然让一个不相关的 Agent 发言导致节奏混乱。我的习惯是先round_robin跑通核心逻辑确认每个 Agent 的输出符合预期再切auto并观察一两次如果还是乱就定义自定义发言顺序函数。AutoGen 允许你传一个speaker_selection_method函数返回下一个发言的 Agent 名字完全自由控制。另外给每个 Agent 的 system prompt 里加上“你只负责XX不讨论其他问题”能有效减少跑题。这不是限制而是帮助 Agent 聚焦。5.5 排错速查表我把常见问题整理成了速查表我每次遇到问题都会先对照一遍症状最可能原因推荐解决措施对话停不下来缺少终止条件或轮次限制设置max_round增加终止词判断函数上下文超限历史消息太大开启摘要summary_method限制回复长度工具调用无效工具描述不清或模型不触发强化 docstring在 Prompt 中强制要求调用角色跑题职责不清晰收紧 system prompt使用round_robin或自定义发言顺序模型胡编数据没有真实工具或工具调用失败提供真实函数禁止编造返回错误提示输出太啰嗦未限制 max_tokens为每个 Agent 设置max_tokens200等上限多轮后效果变差上下文被无效信息污染摘要历史清空无用消息限制只有必要信息进入上下文这张表也是我踩了很多坑才总结出来的你可以直接保存。最后再分享一个我自己的体会多智能体系统最容易被忽视的其实是“收敛艺术”。很多人关注怎么让 Agent 有话可说却忽略了怎么让它适时闭嘴。AutoGen 把控制权交给了开发者ESL 上讨论很多的问题都出在终止条件写得太随意。如果你刚开始搭我强烈建议先用两个 Agent 做一个小闭环比如“一个出方案、一个挑刺”跑通之后再往里面加角色否则一上来就建五六人群聊除了烧 token大概率还会收获一群复读机。这套工具的价值在于把对话编排从“胶水代码”里解放出来但真正的效果上限还是取决于你对任务边界和角色的理解。