1. 为什么我会盯上AutoGen多智能体协作才不是概念炒作如果你关注过大模型应用开发肯定见过这类尴尬场景拿一个ChatCompletion接口硬怼业务需求把所有逻辑都堆在一个请求里结果提示词越写越长、成本越飙越高、输出还越来越不可控。等到任务稍微复杂一点——比如既要读文档、又要查数据库、还要生成报告——单Agent的玩法基本就会卡死在“什么都要管”这堵墙上。AutoGen全称Microsoft AutoGen就是冲着这个问题来的。它是一个基于Python的多智能体对话框架核心理念特别朴素别让一个大模型干所有事而是让多个“智能体”像一支小团队一样分工协作各自持有不同的角色、提示词、工具甚至不同的模型后端通过对话机制完成任务编排。我最早接触这个框架是冲着群聊模式GroupChat去的当时刚被LangGraph的有向图折腾得够呛看到AutoGen把多智能体编排做成“群聊 管理员调度”第一反应是这才对嘛真实团队协作本来就是对话驱动的。这个框架适合什么人如果你已经在用LangChain或直接调OpenAI接口想让应用从“单次推理”升级成“多步协作”如果你需要在代码生成、数据分析、文档问答这类场景里让多个模型角色配合甚至你就是个研究生想快速做多智能体实验——AutoGen都能让你少写大量胶水代码。它的抽象层次比LangChain的链Chain更贴近“人类协作”的直觉学习曲线也比自己从零写消息路由平滑得多。我在标题里写“6.2”是因为这套框架无论从依赖、API还是设计模式来看都已经相当成熟当前稳定版API已经稳定到了0.2系列虽然名字带6.2但核心机制没有翻天覆地的变化。这篇文章我就按自己的实操路径来拆先解析核心概念和设计思路再落到环境搭建和具体代码最后聊聊我踩过的坑和排查方法。2. 核心概念与设计思路Agent、对话、工作流2.1 Agent到底是个什么东西很多教程喜欢把AutoGen的Agent描述得很玄实际拆开看就三层角色设定 大脑LLM 工具。角色设定就是system message你告诉这个Agent“你是个Python专家”“你是数据分析师”“你是审核员”。大脑就是它背后调的模型AutoGen支持OpenAI、Azure OpenAI、Gemini、本地Ollama等多种后端甚至可以让不同Agent各自用不同的模型。工具则是一堆Python函数Agent在对话中决定要不要调用、传什么参数然后自己拿到结果继续推理。这个概念看起来跟LangChain的Agent差不多区别在消息机制。AutoGen里Agent与Agent之间是通过对话消息ChatMessage来协作的而不是像LangChain那样走链式管线。什么意思呢你用AutoGen写两个Agent让它们“聊”一个需求A提出问题、B给出回答来回几轮之后你可能才发现原来不需要预先画链路图只需要定义好人设和终止条件协作流程会自己在对话中浮现出来。这带来的直接好处是对付开放式问题特别省心。比如“分析这份数据并给出可视化建议”你根本没法预先编排每一步但两个Agent来回聊思路能螺旋上升。2.2 用户代理与助理代理AutoGen最经典的一对搭档AutoGen官方最早的最佳实践是UserProxyAgent AssistantAgent这个组合。AssistantAgent是“干活的大脑”UserProxyAgent是“执行的手”。默认情况下AssistantAgent只负责思考并输出文本或函数调用建议而UserProxyAgent手里握着execute_code_functions这个工具能实际去跑代码、拿真实结果再把结果反馈给大脑继续分析。这个组合设计得极聪明。为什么不直接让一个Agent既思考又执行因为这两个行为对模型的要求是矛盾的思考推理需要模型专注逻辑如果同时还要它处理执行报错、文件IO注意力很容易被稀释。拆开后UserProxyAgent可以用一个更便宜、更快的模型或者干脆是规则逻辑来执行AssistantAgent则可以用最强模型专注推理成本和质量都能分开调优。我用这个组合写过生成股票分析报告的脚本数据获取、指标计算、图表生成、Markdown报告输出一路下来全在对话中推进完全不需要写一个庞大的调度器。真要说这个模式有什么限制那就是它本质上还是“两个角色轮流说话”复杂程度上去后你会需要群聊模式。2.3 GroupChat与GroupChatManager复杂任务的编排核心等任务发展到要三个甚至更多角色配合——比如有个研究员找资料、有个编码员写代码、有个评论员审查结果——双Agent模式就有点力不从心了。AutoGen给出了答案GroupChat。GroupChat是一个消息池子所有Agent的发言都投进去由GroupChatManager来决定下一个说话的人。怎么决定默认是轮流发言round_robin但也可以配置成选择模式让Manager调用LLM根据当前对话状态“点名”下一个发言者。这个点名逻辑在AutoGen里专门有个角色叫speaker_selection_method不同的选择方法直接决定了对话的走向是高效聚焦还是发散漫游。我对GroupChat最大的体会是它把“调度策略”和“业务逻辑”解耦了。你想改协作风格不用改任何Agent内部逻辑直接换Manager的调度方法就行。这个设计非常先进代价是调试难度上来了——出错时你要去翻对话历史才能定位是哪个Agent跑偏了。2.4 可编程对话模式从AutoGen 0.2开始的新章如果你翻过更早版本的AutoGen可能记得有个“嵌套对话”的概念就是Agent在对话里触发另一个对话结果再作为消息传回来。到了0.2时代AutoGen把API打磨成了更贴近模型原生的风格定义了统一的ChatMessage结构并且支持构建可编程的多Agent工作流——你可以用代码显式控制对话流向而不只是靠LLM自己跑。这意味着AutoGen既能做自由对话式的编排也能做确定性强的流程式编排两条路都走得通。我个人的建议是能显式就显式。自由对话虽然酷但在生产环境里切不可控性太高。用GroupChatManager的自定义对话模式把关键分支固定死让自由对话只发生在边界模糊的子任务里这是我在多个项目里验证过的稳定实践。3. 环境搭建与第一个多智能体应用3.1 环境准备和安装比你想象的简单AutoGen的安装相当省事Python 3.9以上就行我测试用的是3.11。直接pip安装核心包pip install pyautogen注意这个包名老教程里写的是autogen已经被废弃合并到pyautogen里了。如果你用的是更早的版本先把旧包卸干净再装新的不然会出现类名冲突这类很诡异的问题。装完之后最快验证环境的方式是配置好模型信息跑一个最小Demo。我日常开发会先把OpenAI兼容的API参数放到环境变量或配置文件里import autogen config_list [ { model: gpt-4o-mini, api_key: 你的key, base_url: https://api.openai.com/v1 # 如果你用代理网关这里换成网关地址 } ]如果你用的是Azure OpenAI需要把api_key换成azure_endpoint、api_type这些参数AutoGen的config_list_from_json工具函数可以直接从JSON配置里读取格式很简单。还有一点AutoGen也支持本地模型比如通过Ollama起一个Llama 3只要你的服务暴露的是OpenAI兼容接口就可以通过base_url来接入。这意味着你不用为了用AutoGen强制绑定任何云厂商。3.2 快速搭建一个双Agent数据问答系统我这里用一个实际跑过的场景做演示让两个Agent协作完成“查询数据库并生成报告”。我们用一个极简的SQLite数据库当作数据源模拟一个分析师助手。先定义工具函数。注意AutoGen里工具有两种接入方式一种是旧版的function_map挂在UserProxyAgent上由系统自动调用另一种是新版register_function的写法。我推荐用register_function它对类型注解更友好错误信息也更清晰。工具函数定义import sqlite3 def query_sales_data(date: str) - str: 查询指定日期的销售数据返回JSON格式字符串 conn sqlite3.connect(sales.db) cur conn.cursor() cur.execute( SELECT region, amount, orders FROM sales WHERE date ?, (date,) ) rows cur.fetchall() conn.close() import json return json.dumps( [{region: r[0], amount: r[1], orders: r[2]} for r in rows], ensure_asciiFalse )然后创建两个Agent。AssistantAgent的名字就叫analyst人设是“销售数据分析师”SystemPrompt写成这样analyst_system_message 你是销售数据分析师。你能使用query_sales_data工具获取数据。 你的任务是 1. 调用工具获取原始数据 2. 分析趋势并总结关键发现 3. 产出简洁易懂的中文分析报告 注意调用工具后你要用工具返回的精确数据说话不要编造数字。 UserProxyAgent这边user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, # 全自动模式不用人工输入 max_consecutive_auto_reply10, is_termination_msglambda msg: TERMINATE in msg.get(content, ), )human_input_mode三个选项我分别说下ALWAYS表示每次Agent发言前都问你NEVER是全程自动TERMINATE混合模式是Agent发起提问时才询问用户。调试阶段建议用TERMINATE线上自动化再切NEVER。最后让它们开会assistant autogen.AssistantAgent( nameanalyst, system_messageanalyst_system_message, llm_config{config_list: config_list}, ) user_proxy.register_function( function_map{query_sales_data: query_sales_data} ) result user_proxy.initiate_chat( assistant, message请分析2025-06-01的销售数据生成一份包含各区域表现对比的分析报告。, )跑起来之后你会看到对话逐轮推进analyst输出调用查询工具的参数user_proxy本地执行函数并把真实数据喂回去analyst拿到数据后再生成报告。整个链路一目了然比手动维护一个有状态的推理循环简单太多。3.3 扩展到GroupChat三Agent代码审查工作流双Agent能解决不少问题但如果你要做“写代码→审查→修改”这样的迭代任务双Agent的来回轮次会爆炸这时候就该用GroupChat。我写过一个自动代码审查的工作流编码员coder负责写Python脚本审查员reviewer负责挑毛病项目经理pm负责汇总并决定是否收尾。GroupChatManager负责调度发言顺序。coder autogen.AssistantAgent( namecoder, system_message你是资深Python工程师擅长写清晰可维护的代码。, llm_config{config_list: config_list}, ) reviewer autogen.AssistantAgent( namereviewer, system_message你是代码审查员重点检查逻辑错误、边界情况和性能问题。, llm_config{config_list: config_list}, ) pm autogen.AssistantAgent( namepm, system_message你负责汇总审查结果。只有所有问题都解决后才输出TERMINATE。, llm_config{config_list: config_list}, ) group_chat autogen.GroupChat( agents[coder, reviewer, pm], messages[], max_round12, ) manager autogen.GroupChatManager( groupchatgroup_chat, llm_config{config_list: config_list}, ) user_proxy.initiate_chat( manager, message请实现一个计算斐波那契数列的Python函数并确保通过代码审查。, )这段代码跑起来后你会看到GroupChatManager在三个Agent之间做调度。默认round_robin是轮流说话但对于这种审查场景我希望审查员能根据实际情况反复点名编码员修改代码而不是机械地轮转。这种更聪明的调度需要给GroupChatManager传入LLM配置并换一种选择方法后面4.2节我详细展开。回头看这段代码GroupChat真正降低的是“多角色对话协议”的手写成本。如果你自己实现消息路由、发言顺序、终止条件、上下文管理每一项都是坑而AutoGen已经把默认实现做得很扎实。4. 核心机制与参数背后的为什么4.1 终止条件让你的Agent“有始有终”多智能体对话最大的风险就是聊起来停不住。AutoGen里的is_termination_msg参数是防止“死循环”的关键防线。最常见的写法就是检测消息里是否包含TERMINATE字符串。为什么用这个约定因为AssistantAgent在对话中会输出文本、也可能输出工具调用你需要一个不依赖格式的约定信号来表明“这轮任务完成了”。你可以在SystemPrompt里强制执行这个约定比如让项目经理Agent在确认所有问题都已修正后输出TERMINATE。这个字符串其实可以换成任何关键词比如DONE或者完成。但要注意如果你开了多Agent群聊每个Agent的终止判定都共享同一个回调函数所以最好确保只有“最终决策者”会输出这个词否则别的Agent嘴瓢说一句TERMINATE整个流程就提前结束了。我踩过的坑某次把终止词放在了一个工具函数的返回结果里结果工具被调用后返回的JSON里恰好包含“TERMINATE”字样UserProxyAgent误判流程结束。排查半天才发现是数据内容污染了终止信号。现在我的经验是工具返回的数据和Agent的输出分开处理终止判定只面向Agent产出。4.2 发言者选择机制GroupChatManager的灵魂GroupChatManager调度发言者的算法是AutoGen群里讨论最多的话题。源码里提供了几种选择round_robin轮流、random随机、auto让LLM选择下一个发言者。默认是auto。auto模式下Manager会把当前对话历史和所有Agent的简介打包成一份“选择提示词”让LLM自己决定谁最适合说下一句。这个设计的妙处在于它能根据实际对话语境动态调整发言顺序避免无意义的轮转。缺点也很明显如果某个Agent的SystemPrompt写得太像回事Manager可能会一直点名它其他Agent被晾在一边。我建议这么调如果你的任务角色边界明确、流程相对固定用round_robin最稳如果是开放式的头脑风暴或研究任务用auto更灵活。想兼顾的话AutoGen 0.2还支持自定义选择函数你可以自己写逻辑比如优先让工具返回结果的Agent发言这在多工具链场景下能显著提升效率。这里放一个修改选择方法的小例子manager autogen.GroupChatManager( groupchatgroup_chat, llm_config{config_list: config_list}, ) # 注意新版API中可以通过定义自定义选择函数来控制发言者 manager_group_chat autogen.GroupChat( agents[coder, reviewer, pm], messages[], max_round12, speaker_selection_methodauto, # 可换 round_robin / random )如果你用auto出问题优先去改Agent的SystemPrompt而不是盲目调LLM温度。我常用的一句话是“你只在负责XX任务时才发言其他情况请保持沉默。”这比在调度层面强行禁言好用得多。4.3 工具调用与代码执行安全的“手”与“脑”UserProxyAgent能执行代码这个能力让它十分强大但也带来安全风险。AutoGen提供的是本地代码执行默认在一个临时目录运行Python命令。如果你让它“在服务器上跑一段代码”请务必控制好工作目录和权限。我在生产环境里跑AutoGen的经验是所有工具函数和代码执行都尽量封装在容器或受限沙箱里不要直接暴露在宿主机文件系统中。UserProxyAgent有一个code_execution_config参数里面可以设置work_dir、use_docker等选项。如果你的环境支持Docker推荐开启use_dockerTrue把执行环境隔离到容器里user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, code_execution_config{ work_dir: coding_workspace, use_docker: True, # 需要本机装好Docker }, )代码执行这块还涉及一个细节工具函数返回值的格式。AutoGen对工具返回值的处理比较灵活可以是字符串、字典、Pandas DataFrame但建议统一返回字符串或JSON这样在LLM上下文里最容易被理解。我见过有人把整个Excel文件塞进返回值结果模型上下文直接被撑爆。4.4 记忆与上下文管理为什么对话会“断电”AutoGen默认把所有对话历史塞给LLMToken消耗和上下文窗口就是两个绕不开的问题。早期版本有max_consecutive_auto_reply这个参数限制Agent自动回复次数间接控制对话长度但治标不治本。新版AutoGen支持了基于消息的上下文整理和压缩。一个更实际的做法是把长文档拆成多个子任务每个子任务开一次新的GroupChat最终汇总结果。比如你要分析一本300页的电子书不要试图一个对话全部搞定而是先读取目录、分章节处理、再把各章摘要汇总成完整报告。这种“分而治之”的思路在AutoGen里天然适配。我自己常用一个简单的技巧在SystemPrompt里要求Agent“只输出最终结论不要复述中间步骤”这能在很大程度上抑制上下文膨胀。当然如果你任务复杂该买大上下文窗口时就买别抠这个钱。5. 实操过程完整实现一个端到端工作流5.1 场景定义自动化竞品分析报告为了把前面所有机制串起来我写了一个完整的实战项目给定一个产品关键词自动抓取竞品信息并生成分析报告。这个项目用到Web搜索工具我用duckduckgo_search库做了个简单的搜索函数、文本分析和报告生成三部分。工具函数大致长这样from duckduckgo_search import DDGS def search_web(query: str, max_results: int 5) - str: 使用DuckDuckGo搜索返回前若干条结果 results [] with DDGS() as ddgs: for r in ddgs.text(query, max_resultsmax_results): results.append(f标题: {r[title]}\n摘要: {r[body]}\n链接: {r[href]}) return \n\n.join(results)定义四个Agent研究员researcher、分析师analyst、写作员writer、质量审核员qa。研究员负责搜索并整理素材分析师负责提炼关键信息写作员把它们变成结构化报告质量审核员最后检查报告准确性。这段代码的核心逻辑就是让它们在一个GroupChat里接力协作researcher autogen.AssistantAgent( nameresearcher, system_message你是网络研究员。使用search_web搜索与产品相关的信息收集竞品动态、用户评价、价格区间。只输出事实信息不写结论。, llm_config{config_list: config_list}, ) analyst autogen.AssistantAgent( nameanalyst, system_message你是商业分析师。基于研究员提供的资料分析竞品的优劣势和市场趋势。输出结构化分析要点。, llm_config{config_list: config_list}, ) writer autogen.AssistantAgent( namewriter, system_message你是专业报告撰写人。基于分析要点撰写一份800字左右的中文竞品分析报告。报告要分段、有标题、有数据支撑。, llm_config{config_list: config_list}, ) qa autogen.AssistantAgent( nameqa, system_message你是质量审核员。检查报告是否有事实性错误是否遗漏关键信息。若确认无误回复TERMINATE。, llm_config{config_list: config_list}, ) user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, max_consecutive_auto_reply3, is_termination_msglambda msg: TERMINATE in msg.get(content, ), ) user_proxy.register_function( function_map{search_web: search_web} ) group_chat autogen.GroupChat( agents[researcher, analyst, writer, qa, user_proxy], messages[], max_round20, speaker_selection_methodauto, ) manager autogen.GroupChatManager( groupchatgroup_chat, llm_config{config_list: config_list}, ) user_proxy.initiate_chat( manager, message请帮我分析一下近期智能音频眼镜市场的竞品动态输出一份分析报告。, )5.2 运行过程记录AutoGen的对话动线上面这段代码跑起来后我观察到整个流程大概经历了这么几步Manager点名researcherresearcher调用search_web搜索“智能音频眼镜 竞品”返回一堆搜索结果Manager点名analystanalyst提炼出关键技术参数、价格区间和市场趋势writer把分析整理成报告初稿qa读完后发现缺少某品牌的销量数据点名researcher再次搜索补全信息后writer更新报告qa确认无误输出TERMINATE流程结束。整个过程花了我大概3块钱的接口调用费用的gpt-4o-mini十几轮对话产出大概1500字报告。如果让我手动写爬虫、分析、写报告起码半天起步。这就是多智能体协作的杠杆效应。5.3 性能优化与成本控制经验跑这种自动化流程成本是绕不开的话题。我总结出了几条自己的省钱心得模型分级研究员和分析师用gpt-4o-mini写作和质量审核用gpt-4o。作用不同的Agent不要共用同一个模型配置可以分别给llm_config。减少废话指令SystemPrompt里明确要求“输出要精简不要解释你的思考过程”个位数Token的浪费在长对话里会被放大到很夸张。限制搜索条数max_results设为5比设为20成本能降一半还多而且LLM处理太多信息反而会迷失重点。使用上下文压缩AutoGen 0.2提供了ContextHandling相关机制但我更愿意在应用层做任务拆分从源头控制上下文长度。必须承认多Agent的Token消耗通常比单Agent高30%以上。多Agent解决问题靠的是增量式推理和来回校验而这些都需要额外的上下文空间。如果你业务对成本敏感可以用便宜的模型承担大量“跑腿”角色、把昂贵模型留给决策环节这个组合拳下来成本能控制在单Agent方案的120%左右。6. 常见问题与排查技巧实录6.1 对话停止不下来的排查这应该是所有人用AutoGen遇到频率最高的Bug。对话陷入死循环两边Agent互相客套、反复说“你说得对”。排查步骤我从经验里提炼出来检查终止条件is_termination_msg有没有正确配置有没有Agent在SystemPrompt里被告知要输出TERMINATE很多失败都是因为根本没有一个Agent收到“何时结束”的指令。检查max_round和max_consecutive_auto_reply你的群聊最多轮次设了多少如果设了100而你的任务5轮就能完Manager会继续驱动Agent们空转。查看对话历史只让Manager调度的话你可能不知道Agent之间究竟在聊什么但可以通过group_chat.messages查看每条消息的name和content用这个来定位问题源头。这是最典型的教训Agent除了干活必须显式被告知“干完活了怎么提出散会”。6.2 工具调用失败的常见原因工具函数定义了却一直没被调用大概率是以下三种情况第一种SystemPrompt里没有写清楚工具存在以及使用规则——LLM不知道有工具自然就不会调。第二种函数参数顺序或类型不匹配比如工具函数要求参数是date: str但Agent传了一个int或者传了一个函数签名里不存在的参数——AutoGen助手正则提取参数时经常因为格式问题失败。第三种版本兼容问题——旧版本0.1.x的函数映射需要挂在UserProxyAgent的function_map参数里新版更推荐register_function用法有区别对着官方文档核对一下就行。调试工具调用我的做法是在工具函数里加日志每次调用都打印时间和参数def query_sales_data(date: str) - str: print(f[TOOL_CALLED] query_sales_data, date{date}) ...日志配合对话消息一起看很快能定位是Agent没调用还是调用后函数内部报错。6.3 模型后端接入的不兼容情况AutoGen官方支持OpenAI和Azure OpenAI但这不意味着所有模型都能直接接入。特别是用一些开源模型接OpenAI兼容接口时函数调用的格式很可能对不上。AutoGen的llm_config里有functions参数旧版需要显式列出工具函数及其参数格式新版则是在register_function时自动生成。如果某些模型不支持function callingAutoGen会退化成“文本提示式”调用这时你必须在SystemPrompt里把工具的参数格式写成很规范的JSON示例模型才能正确地“输出你想要的调用形式”。另外如果模型上下文窗口太小长对话直接报错411或400。我的建议是优先选择支持函数调用的模型并时刻关注对话长度。如果你在折腾本地部署的模型也就是通过Ollama/vLLM接入的要注意模型的chat_template是否支持tool calling不支持的话用再好的AutoGen API也没用。6.4 输出质量不稳定的应对策略多Agent对话的质量在天然上比单Agent更难控制因为错误会随着对话轮次层层放大。一个Agent理解错了需求后面所有Agent都会被带偏。应对方法是层层设卡每个Agent的SystemPrompt里加上“如果发现输入信息不完整要求补充而不是猜测”。关键节点设置检查Agent就像我前面写的qa那样专门负责挑毛病。设置严格的终止条件避免质量不够时草草收尾。我还有个跟开源社区里学来的技巧给analyst这类角色加上“置信度评估”的指令让它对不确定的数据标注置信度。这样最终报告读到的人知道哪些信息靠谱、哪些只是推测。不做这个处理Agent非常容易在报告里融入幻觉信息看起来逻辑通顺但经不起验证。6.5 问题排查速查表问题现象可能原因检查方向对话永不停缺少TERMINATE指令检查SystemPrompt与终止判定函数工具函数没被调用SystemPrompt未描述工具用法检查提示词中工具说明与示例函数参数解析报错JSON格式不规范检查Agent输出的调用参数与函数签名群聊中某Agent一直沉默speaker_selection_method偏向其他人检查该Agent的SystemPrompt与角色定位上下文过长报错对话轮次太多或历史过长增加max_round上限拆分任务使用小上下文模型模型返回格式怪异模型不支持function calling检查模型兼容性或改用OpenAI系模型输出内容幻觉严重SystemPrompt缺少事实核查要求增加“用数据说话不编造”等指令增加审核环节7. 我的个人体会与建议整套流程走下来AutoGen给我最大的感受不是“功能多”而是“方向对”——多智能体对话是处理复杂任务的自然形态而AutoGen把这件事的开销降到了“写几个类、注册几个函数”就能上手。它比LangChain更贴近协作的本质比LangGraph又少了点和图结构搏斗的复杂度。如果你准备在生产项目里用AutoGen我最后给你三条实操建议都是我拿时间和Token换出来的教训。第一条让每个Agent只做一件事并把这件事写到名字里。我看过太多失败案例Agent的SystemPrompt洋洋洒洒三百字角色混乱结果就是对话中互相推诿、逻辑打架。一个好的SystemPrompt不要超过十行把职责边界写清楚就够了。第二条调试多Agent时不要只盯着最终输出。要开启详细日志或保存完整对话记录逐轮看每个Agent的输出是否合理。90%的问题在中间某轮就种下了只看结论根本找不到根源。我习惯设logging_levellogging.INFO让AutoGen把调度信息都打出来。第三条部署前先考虑清楚安全边界。工具执行权限、代码运行沙箱、Agent访问的外部API这些都要Setting。多Agent越是自动出问题时波及面越大。我始终建议用use_dockerTrue配合受限的网络环境来跑自动化流程可以少掉很多头发。AutoGen直到现在还在快速迭代0.2、0.4每次大版本更新都会带来一些破坏性变更。我的态度是盯紧官方文档的Migration Guide别依赖旧版教程里的代码片段很多旧写法在新的稳定版里已经不再推荐甚至不能用了。如果你正准备在下一个项目里尝试多智能体架构AutoGen是个很好的起点。别急着上最复杂的GroupChat先从一个UserProxyAgent配一个AssistantAgent开始把对话、工具调用、终止条件这套基本功吃透再逐步增加角色。做多了你会发现多智能体真正难的不在框架而在于你怎么定义每个角色的目标——角色想清楚了框架只是顺手的工具。