做多智能体系统最怕的不是模型能力不够而是“Agent一多系统就乱”。我在用Microsoft开源的AutoGen跑了几个实际项目之后对这种乱象感触很深。微软在AI Agent这块有一套自己的设计哲学与其让一个模型硬扛所有任务不如让多个智能体通过对话协作拆解问题每个Agent只做自己最擅长的事。这篇文章把我在实践里沉淀下来的设计思路、代码套路和排坑经验整理出来如果你正打算基于Microsoft生态搭建一套多智能体系统应该能少走不少弯路。不同背景的读者可以从里面各取所需刚接触Agent的同学可以直接跳到第3节看可运行的代码已经在写Agent项目的朋友重点看第4节和第5节那里是我在真实项目里反复踩过的稳定性和成本问题。我不会去堆概念尽量用实际项目里用得上的话说清楚读完你至少能知道一个包含规划、执行、评审三个角色的多Agent系统是怎么搭出来以及为什么微软会推荐这种对话式协作的设计。1. 多智能体系统到底在解决什么问题1.1 为什么单Agent往往顶不住很多刚接触Agent的人会有一个困惑现在大模型上下文窗口已经做到128K甚至200K了为什么还要拆成多个智能体这不是脱裤子放屁吗我用一个实际场景来回答你。假设你要做一个“行业研究报告自动生成”系统输入是十份PDF和Excel输出是一篇带数据分析、图表建议和风险提示的报告。如果你只用一个Agent把所有文档塞进上下文让它一口气完成效果通常不太理想。原因有三层一是上下文过长后模型会“忘事”前半段的结论到后半段可能就被忽略了二是任务指令混杂在一起一会儿让它分析数据一会儿让它检查合规指令之间容易互相干扰三是排查问题时无从下手报告写错了你根本不知道是哪个环节错了是总结了错误数据还是遗漏了关键信息。多智能体系统做的事情本质上是把一个大而全的问题拆成几个小而专的子任务。比如一个Agent负责读文档并提炼要点一个Agent负责查数据和计算指标一个Agent负责把它组织成报告还有一个Agent专门审校输出质量。每个Agent的系统提示词和职责边界非常清晰模型只需要在一个窄范围里发挥能力效果和可维护性都会明显变好。1.2 Microsoft的Agent编排思路微软在这块的开源主力是AutoGen还有一个和它互补的Semantic Kernel。AutoGen给我的感觉是高度强调“对话驱动”Agent之间的协作不是由一段硬编码流程控制而是通过消息传递和对话轮转来完成。这个设计很有意思它模仿了真实团队的开会场景有主持人有发言人有记录员大家你一言我一语最终收敛到一个结论。微软自己的文档里也明确提出了几种多Agent编排范式双Agent对话、群聊、嵌套聊天、顺序流程。双Agent对话适合一个干活一个验收群聊适合多个角色同时参与的头脑风暴类任务嵌套聊天适合一个Agent内部再发起一次子对话顺序流程则适合数据清洗、分析、出报告这种明确分阶段的管线。这套设计思想几乎可以覆盖我遇到的大部分企业级Agent需求。我不太推荐一上来就用很复杂的编排框架反而建议一开始只用AutoGen自带的基础能力定义Agent定义角色定义工具然后让它们聊起来。跑通之后再逐步增加约束和结构这样对系统的理解会扎实很多。1.3 适合用多Agent系统解决的场景从我实际接触过的项目来看以下四类场景特别适合用Microsoft这套多智能体设计思路第一类是自动化数据分析数据源多、指标口径复杂需要多个Agent分别负责数据获取、口径校验、异常检测和结论生成。第二类是研发辅助一个Agent写代码一个Agent做代码审查一个Agent跑测试并反馈错误形成闭环。第三类是文档密集型业务比如合同审查、研报生成、知识库问答需要先抽取关键信息再对信息做交叉验证最后生成结构化输出。第四类是客服和售前工作台一个Agent负责理解用户意图一个Agent去查订单和库存一个Agent负责组织话术另一个Agent负责安全合规审查。这些场景有几个共同特点任务可以拆分成较独立的子环节每个环节有明确的质量标准且失败之后需要能准确定位。如果你遇到的需求很轻量比如“帮我写一封邮件”那确实没必要上多Agent系统单Agent加大模型指令就够了。多Agent系统是有成本的角色越多token消耗越高调试难度越大这个账要算清楚。2. 整体架构设计与关键决策2.1 我常用的多Agent拓扑结构以我最近做的一个内部知识库问答与分析系统为例它要处理用户自然语言提问例如“上季度华东区销售额前五的产品是什么对比前一个季度变化如何”背后需要串联多张表还要给出结论。我没有继续用一个万能Agent而是设计了三个角色任务规划Agent负责把用户问题拆解成可执行的子问题并判断需要调用哪些数据工具工具执行Agent负责连接数据库、执行查询、处理数据异常把结果转成结构化中间结果报告生成Agent负责把中间结果组织成用户能看懂的报告如果信息不足可以要求前面的Agent补充数据。这三个角色在AutoGen里是通过GroupChat群聊实现的规划Agent发出指令执行Agent干完活把结果丢回群聊报告Agent看到数据后写结果。整个过程不设硬编码的先后顺序而是让它们在群聊里自然流转再由GroupChatManager控制发言轮次。我后来发现这套拓扑的核心优势是扩展性极强如果以后要接入图表生成只需要增加一个图表Agent并告诉它在什么条件下发言即可规划Agent自然会把它纳入任务分配范围。2.2 为什么我更偏向群聊模式很多人设计多Agent系统时会本能地选择流水线模式Agent A的输出作为Agent B的输入像工厂传送带一样。这个模式当然有它的价值但在处理开放式任务时容易出问题。比如用户需求一开始就不明确流水线第一步就让“理解需求Agent”做了错误假设后面所有步骤都跟着错而且很难回溯。群聊模式更像是“先讨论后执行”。Agent之间不是严格的上下游关系而是围绕同一任务贡献各自视角。规划Agent可以先抛出初步方案执行Agent反馈“数据口径不对”审查Agent再补充“缺少时段对比”整个系统具备了一定的纠错能力。AutoGen的GroupChat实现里还有一个关键的speaker_selection_method参数默认轮询或自动选择我一般会让每个Agent在发言内容里明确标注自己是谁、面向谁、在哪个阶段这样可以显著减少选错发言人的概率。当然群聊模式也有代价token消耗更大对话容易出现发散。这时候就需要“主持人”强势一点我通常会在GroupChatManager的系统提示词里明确要求“能直接给出结论的任务不要展开讨论”“如果需要执行代码必须由执行Agent来完成”。这个分寸需要在具体项目里调但总体来说对于需要信息交叉验证的任务群聊模式明显优于死板的流水线。2.3 关键参数是怎么定的AutoGen里最影响系统行为的参数有几个我逐个说下我的设置逻辑。第一个是temperature。规划Agent的temperature我设置为0.2因为它做任务拆解需要稳定和可复用报告生成Agent的temperature可以略微调高到0.4让语言更自然一点但不能太高否则容易出现事实歪曲代码执行Agent的temperature直接用0代码生成必须尽量确定性。第二个是human_input_mode。这是AutoGen里的“人机交互阀门”可选NEVER、TERMINATE、ALWAYS。线上跑批任务必须设为NEVER不然会卡在人机确认上但调试阶段我强烈建议设为TERMINATE或ALWAYS让它在关键节点停下来问你一句这样你能清楚地看到Agent的决策路径。第三个是max_consecutive_auto_reply和max_round。前者是单个Agent连续自动回复次数上限后者是整个GroupChat的总轮次上限。我一般设置max_round为20到30如果30轮还没收敛大概率是任务拆解或提示词出了问题与其让Agent继续烧钱不如主动终止然后根据日志分析问题。另外代码执行开关code_execution_config也要注意。我一般不为所有Agent开启代码执行只给执行Agent开启而且执行环境用Docker沙箱避免Agent生成的Python代码直接跑在宿主机上。这个习惯帮我避免了很多麻烦后来遇到问题排查时也更容易复现。3. 基于AutoGen的实操实现3.1 环境准备和依赖安装实现这套系统我用的是Python 3.10和AutoGen 0.2系列。之所以没直接上最新的0.4是因为0.2的API更简单社区资料多很多公司存量项目也是0.2先把这个搞清楚再迁移会容易很多。安装命令很简单pip install pyautogen如果你只是为了学习和本地调试装这个就够了。如果要走生产环境会需要配合Azure OpenAI或其他模型接口那还要安装Azure相关的SDK比如pip install pyautogen[azure]这里有个常见的坑Windows机器上装pyautogen时如果缺少Microsoft C Build Tools可能会报“Microsoft Visual C 14.0 or greater is required”。解决办法是去微软官网下载并安装Microsoft C Build Tools然后勾选“使用C的桌面开发”工作负载。这个问题和Agent本身无关但确实会卡住很多人先在这里提一个醒。3.2 最小可运行的双Agent实例我们先写一个最简单的双Agent对话一个Assistant负责写Python代码一个UserProxy负责执行代码并把结果回传给Assistant。这段代码来自我最初测试AutoGen时的原型逻辑非常清晰。import autogen config_list [ { model: gpt-4o-mini, api_key: YOUR_API_KEY, } ] llm_config { config_list: config_list, temperature: 0, } assistant autogen.AssistantAgent( nameassistant, system_message你是一名Python程序员。用代码完成任务不要解释太多。, llm_configllm_config, ) user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeTERMINATE, max_consecutive_auto_reply10, is_termination_msglambda x: x.get(content, ).rstrip().endswith(TERMINATE), code_execution_config{ work_dir: workspace, use_docker: True, }, ) user_proxy.initiate_chat( assistant, message写一个Python函数计算1到100之间的所有素数并输出结果。, )这里的关键是UserProxyAgent。它的名字叫“user代理”但它的职责其实是充当“代码执行器”和“人工接口”。当Assistant生成代码后UserProxyAgent会把它提取出来并执行执行结果再作为消息回给Assistant。这个过程形成了一个闭环Assistant写代码、UserProxy跑代码、Assistant根据结果修代码。human_input_mode我设置成TERMINATE意思是Human只在对话可以终止的时候参与其他时候不打扰。这样既不会卡住又能在Agent输出最终结果前让我看一眼。如果你希望完全无人值守可以把human_input_mode改成NEVER。3.3 用GroupChat实现多角色协作双Agent只能覆盖“写代码跑代码”这种二元场景我的知识库问答系统需要三个角色所以用GroupChat更合适。代码结构也很清晰。planner autogen.AssistantAgent( nameplanner, system_message你是任务规划Agent。把用户问题拆解为具体的子任务并分配给合适的Agent。 所有子任务完成后总结并输出最终答案。, llm_config{**llm_config, temperature: 0.2}, ) executor autogen.AssistantAgent( nameexecutor, system_message你是工具执行Agent。接收planner分配的任务调用工具或代码完成数据查询和计算。 只输出结果不编造数据。, llm_config{**llm_config, temperature: 0}, ) writer autogen.AssistantAgent( namewriter, system_message你是报告生成Agent。根据executor提供的数据结果生成简洁、准确的中文报告。 如果数据不足请说明需要补充哪些信息。, llm_config{**llm_config, temperature: 0.4}, ) user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, max_consecutive_auto_reply10, code_execution_configFalse, ) group_chat autogen.GroupChat( agents[user_proxy, planner, executor, writer], messages[], max_round20, ) manager autogen.GroupChatManager( groupchatgroup_chat, llm_config{**llm_config, temperature: 0}, ) user_proxy.initiate_chat( manager, message请分析销售数据表找出华东区上一季度销量前五的商品并生成简短的结论。, )GroupChatManager就是那个“主持人”。它用LLM来决定下一个发言人是谁也可以根据消息内容判断任务是否完成。在我这个例子里planner会先接手任务拆成“查表、过滤、排序、生成结论”几个子任务然后executor去执行writer最后生成报告。由于max_round只有20如果Agent之间频繁扯皮系统会自动停止不会无限烧钱。这里有个容易忽略的地方user_proxy的code_execution_config被我设成了False。为什么因为这三个角色里只有executor应该执行工具调用其他Agent不应该有权限控制代码执行环境。如果每个Agent都带代码执行能力系统非常容易乱套。权限最小化在多智能体系统里尤其重要。3.4 把工具接入Agent上面的例子里说“调用工具完成数据查询”但实际是模型自己在生成代码然后执行有时候我们并不想让它写代码比如查询一个内部HTTP API或者调用一个已经封装好的Python函数。AutoGen支持Function Call我把这个能力集中在executor身上def query_sales_data(region: str, quarter: str) - str: 根据区域和季度查询销售数据。 返回JSON字符串。 # 实际项目里这里会查数据库或调用内部API import json data [ {product: 商品A, sales: 370.5}, {product: 商品B, sales: 275.2}, ] return json.dumps(data, ensure_asciiFalse) executor autogen.AssistantAgent( nameexecutor, system_message你是工具执行Agent。根据用户的请求调用可用函数完成任务。 查询销售数据必须使用query_sales_data函数。, llm_config{ **llm_config, functions: [ { name: query_sales_data, description: 查询销售数据按区域和季度过滤, parameters: { type: object, properties: { region: {type: string, description: 区域例如华东区}, quarter: {type: string, description: 季度例如2024Q1}, }, required: [region, quarter], }, } ], }, )这种写法的好处是模型不会自己乱拼SQL而是被迫走我们封装的接口。query_sales_data函数内部可以加权限校验、日志审计、数据脱敏比让代码执行Agent直接拼SQL安全得多。我后来在项目里把绝大多数数据库操作都改成了这种Function Call形式而不是让Agent生成SQL因为生成SQL的风险很难控制尤其在生产库上。AutoGen在检测到模型返回function_call时会自动把函数结果作为消息回传给LLM让它继续推理。这个循环和双Agent的代码执行循环类似但更可控因为函数参数有固定schema模型只能在这个schema里发挥。4. 运行稳定性与成本优化的关键时刻4.1 上下文控制与记忆管理多Agent系统跑的时间越长上下文里的历史消息就越多。很多人在跑群聊时发现第10轮之后Agent开始忘记前面已经确定的结论甚至反复提出已经解决过的问题。这是因为GroupChat的messages列表一直在增长早先的大量细节被后续的长消息挤出了注意力范围。我的处理方式有三个。第一在系统提示词里明确要求“关键结论必须在消息开头或结尾重复一遍”这样即使上下文被压缩核心信息也有更高概率被保留。第二定期做总结摘要。AutoGen自带Summarizer功能可以用一个小的模型把前面的长对话压缩成摘要替换掉原始messages。第三对于确实需要长期记忆的任务我会把最终产出写到一个本地Markdown文件或向量数据库里而不是让Agent在上下文里“记住”。Token消耗也需要提前估算。我用过一个简单的计算假设每条Agent消息平均800个token一个20轮的群聊单次执行大约消耗3万到4万个token。如果跑50轮那就是10万token级别。这个量在重度使用场景下成本不低所以一定要在设计阶段控制轮次和参与Agent数量。4.2 防止Agent无限循环和不收敛多Agent系统最常见的故障就是“两个Agent互相客套没有实际产出”。有一次我的planner和writer一直在群里讨论应该用什么措辞executor反而插不上话任务跑了18轮都没有执行任何工具让人非常抓狂。我后来总结出一套干预手段给GroupChatManager加一个“任务完成判定器”当检测到“已经给出明确的最终答案”或“用户请求已经满足”时立即返回TERMINATE。把max_round调低到15-20轮哪怕偶尔误杀也要做让系统更注重效率。在关键Agent的system message里加入“不要客套不要复述别人的话直接给结果”这类硬约束。更复杂一点的增加一个单独的评审Agent负责判断“当前对话是否已经可以结束”只有它说可以结束才会触发终止条件。我测试下来最有效的是最后一种。评审Agent不参与核心工作它只读对话记录判断任务目标是否达成。这个角色的成本不高但能显著减少无效轮次。4.3 模型选择与成本预算不是所有Agent都需要用最强的模型。我的一般策略是规划Agent和评审Agent用中等模型比如gpt-4o-mini因为它们主要做语义判断和任务拆解不需要太强的推理执行Agent用较强模型或者至少temperature设低一点因为代码生成和工具调用对正确性要求很高报告生成Agent可以用中强模型保证语言质量的同时控制成本。这里给个成本预算的例子一个20轮群聊如果所有Agent都用gpt-4o假设每轮平均1500 token总共3万token按官方价格重计算一次任务可能就要几块钱人民币。如果改用gpt-4o-mini做规划和评审只有执行Agent用gpt-4o成本能下降一半以上但效果基本一致。另外官方模型的定价经常变动不要死记一个价格。我一般会在项目里做一个简单的token统计中间件记录每个Agent消耗的token数和成本跑完一批任务之后拉个表看看哪个Agent最耗钱。很多时候你会发现是那个一直在闲聊的Agent烧掉了大头这时候就要优化它的提示词或限制它的发言机会。4.4 日志、回放与可观测性多智能体系统调试起来比普通程序难很多因为状态不是由代码控制的而是由LLM的多次决策共同决定的。所以我坚持在项目里做完整日志把所有Agent之间的消息都记录下来包括时间戳、发言Agent、消息内容、token数、用到的工具和返回结果。AutoGen本身有一个很好的特性就是对话记录可以导出成JSON或可读文本。我在系统里写了一个回调函数每轮对话结束后自动把消息写入文件这样即使系统跑挂了我还能回放整个决策过程看到是哪个Agent哪句话把方向带偏了。这个习惯帮我省了很多排查时间强烈建议你照做。如果日志过于冗长可以用一个简单的摘要logger只记录每条消息的前200个字符和关键工具调用。排查时先看摘要定位到可疑轮次再看原文。5. 常见问题与避坑实录5.1 问题速查表我把近期遇到过的高频问题和解决办法整理成了表格方便你直接查阅。现象可能原因解决办法Agent之间互相复述没有实际进展系统提示词缺少约束GroupChatManager选择发言人太随机增加“直接给结果”的约束设置speaker_selection_method为auto或基于内容的判定执行Agent不调用工具自己瞎猜数据没有把工具注册到该Agent的functions或者描述不够清晰在llm_config里注册Function并在system_message里强调必须调用群聊在第5轮就提前终止max_round太小或is_termination_msg误判适当调大max_round到20-30检查终止条件函数上下文太长导致丢失早期结论没有做摘要messages列表无限制增长接入Summarizer定期把历史对话压缩成摘要输出的代码在Docker里跑失败工作目录没有正确挂载或者依赖缺失检查code_execution_config的work_dir和use_docker配置在镜像里安装公共依赖Agent生成的SQL操作了错误的数据表工具权限过宽模型能接触的表太多不要给Agent直接连数据库封装专用查询函数限制表名和字段模型返回JSON格式不稳定没有强制使用Function Call或者提示词不够具体优先用Function Call让模型输出结构化内容而不是让它直接返回JSON字符串多Agent时监控困难缺少日志和回放机制增加消息回调记录所有交互到文件或日志系统5.2 几个我踩过的实操坑第一个坑把数据库连接字符串直接暴露给了代码执行Agent。起初我让executor直接读取一个配置模块结果有一次它“好心”地把表结构打印出来还尝试执行了一个删除操作。虽然被权限拦住了但想想都后怕。现在我的原则是Agent只能通过封装好的函数访问数据底层数据库连接、凭据、权限全部留在受控环境里。第二个坑多个Agent共用一份上下文导致信息串味。有一次我在同一套系统里让两个群聊并发处理不同任务结果因为公共变量没做隔离任务A的中间结果被任务B读到了产出的报告完全错了。后来我改成每个任务独立实例化GroupChat并用任务ID隔离所有状态变量问题立刻消失。第三个坑过度依赖AutoGen的代码执行功能而忽略了模型输出质量。代码执行确实方便但模型写代码偶尔会有莫名其妙的低能错误比如用错变量名、算错边界值。如果任务对准确性要求极高我建议在executor后面再接一个“结果校验Agent”专门检查代码逻辑和数值合理性而不是盲目相信执行结果。第四个坑迷信“最强模型”。在一段时间里我用gpt-4o给所有Agent做底层结果成本很高速度也慢效果并没有比gpt-4o-mini搭配清晰的职责边界好多少。后来我意识到多Agent系统的效果上限更多取决于角色分工、工具设计和上下文管理模型本身的差别在复杂任务里只占一部分权重。5.3 如何让这个系统持续演进多智能体系统不是搭完就结束了它更像是一个内部“团队”需要持续调教。我的习惯是每个版本上线后都收集一批典型失败案例把它们构造成回归测试集。每次调整提示词或系统架构时先跑一遍回归测试集确保旧问题没有复发。遇到新的失败案例再把对应的对话日志加进去。这套回归测试用AutoGen很容易实现单独写一个脚本把测试问题作为输入批量启动GroupChat最后用几个规则或一个评审Agent判断输出是否符合预期。虽然它不能像单元测试那样保证确定性但至少能帮我们在上生产前发现大部分明显的回归。我最后想说的是Microsoft多智能体系统的设计哲学给了我很大的启发它不追求让某个Agent变得全知全能而是通过一套合理的“社会规则”让多个Agent各司其职。如果你正在做类似的项目建议别急着堆数量先把两三个角色之间的对话质量打磨好再慢慢增加新的角色。系统稳定性的第一步是让每个Agent都能在自己的职责边界里把话说明白。