1. 先说结论AutoGen 到底是什么以及我为什么从 LangChain 转向它AutoGen 是微软开源的 多智能体 应用开发框架它的核心思路不是让你写一串串联大模型的链式调用而是让多个“大模型智能体”通过对话互相协作共同完成任务。说白了它把“一个 Prompt 走到底”变成了“一群 AI 角色开一场会”每个角色有自己的身份、目标、能力和记忆开会开到得出最终交付物为止。我最早接触 AutoGen 是半年前当时手上接到一个内部数据报表自动化的需求——要从十几个来源抓数据、做清洗、跑分析最后生成带图表的周报。一开始我用 LangChain 的 Sequential Chain 搭了一条流水线效果勉强能跑但一旦某个环节的输出格式变了整条链就崩。后来我试着用 AutoGen 把流程改写成 多智能体 协作一个数据抓取智能体、一个清洗智能体、一个分析智能体、一个报告撰写智能体四个角色在一个群里互相喊话居然两三天就稳定跑通了。这篇博文不讲官方案例里那些玩具级别的 demo我把自己从零搭一套 多智能体 协作系统的过程、架构设计、踩坑经验全写下来。适合谁看已经写过几个大模型应用、对 Agent 概念有基本了解但还没真正上手 AutoGen 或没想清楚“多智能体到底该在什么场景用”的开发者。如果你完全没接触过 OpenAI API 和代码执行建议先跑一遍官方 Notebook 再来读。1.1 一个容易复现的“多智能体”最小示例我先给一个能让你最快建立体感的代码。这大概是 AutoGen 里最经典的三行半代码——两个助理对话一个写代码一个审查代码from autogen import AssistantAgent, UserProxyAgent, config_list_from_json config_list config_list_from_json(OAI_CONFIG_LIST) assistant AssistantAgent( namecoder, llm_config{config_list: config_list}, system_message你是一名资深 Python 工程师负责编写数据分析代码。回复必须是可直接运行的 Python 代码。 ) user_proxy UserProxyAgent( nameuser_proxy, human_input_modeNEVER, max_consecutive_auto_reply10, code_execution_config{work_dir: workspace}, ) user_proxy.initiate_chat( assistant, message读取 workspace/data.csv统计每列缺失值占比并画出热力图保存为 missing.png。 )这段代码干了什么user_proxy 收到你的任务后把它抛给 assistantassistant 生成 Python 代码user_proxy 自动在本地执行代码执行结果包括报错信息再回传给 assistantassistant 根据报错调整代码循环往复直到任务完成。我建议你亲手跑一遍这个最小示例。跑通之后你会立刻明白 AutoGen 的“对话即协作”模型所有信息传递都靠自然语言消息代码执行只是其中一种“工具”。理解这一点后面所有架构都不难。1.2 我的选型理由对话驱动 vs 链式编排我知道很多人现在用的是 LangChain我也用过。两者不是一个层面的东西但确实存在重叠。LangChain 的核心抽象是 Chain——你把 Prompt、模型、输出解析器串起来数据沿着固定的管道流动。它的优点是确定性强、调试直观缺点是拓扑结构是写死的AI 在节点内部干活但节点之间怎么连接由你预先定义。AutoGen 正好反过来它的核心抽象是 Agent智能体之间通过消息自由对话执行路径是动态的。这在两类场景里优势特别明显第一类是任务步骤不确定的场景。比如“帮我分析一下这个数据集”这种需求分析哪些维度、用什么算法、需不需要做特征工程、最终结论怎么写连人都没法提前列出完整步骤何况是写死在代码里的链。让几个智能体自由对话它们会自动“长出”合理的流程。第二类是需要多角色来回审查修改的场景。比如代码生成AssistantAgent 写完代码后如果有另一个 CriticAgent 从代码规范、边界条件、性能角度反复挑毛病最终产出的代码质量会明显好于“一次生成”。这在链式架构里很难自然实现。但也不要误会AutoGen 不是银弹。后文我会单独讲它的适用边界实际上有一大类场景用单智能体或传统链式结构反而更好。2. 我实际搭建的多智能体协作系统从架构设计到角色分配2.1 系统整体结构设计我搭建的是叫“weekend_report”的周报自动化系统。目标是从公司内部的数据库、外部公开数据源、团队协作平台三个地方抓取信息经过整合分析生成一份包含业务指标、环比变化、异常点预警和周度总结的 Markdown 周报。整体用了典型的“助理 批判 执行”三层结构第一层是任务编排层单个 OrchestratorAgent 负责理解用户的原始需求拆解成若干子任务分配出去。第二层是执行协作层四个领域智能体各自干活通过群聊同步进展。第三层是质量把关层一个 ReviewerAgent 在最终输出前检查周报的完整性和准确性不合格就打回重写。这个结构不是一次性想出来的。我最初参照了 AutoGen 官方文档里的“嵌套聊天”示例把外层设为产品经理内层设为技术团队跑了一周发现层级太深反而让 token 消耗暴涨。后来简化成上面这个三套层层级浅了成功率反而上来了。为什么选择这个结构核心原因是每个智能体只需要维护自己的局部上下文。Orchestrator 不需要知道数据具体怎么清洗它只负责派活和收结果清洗智能体不需要理解业务指标口径它只要处理数据格式问题。整体上每个智能体的系统提示词保持短小聚焦上下文窗口的压力也小得多。2.2 智能体角色划分与职责边界角色划分是整个多智能体系统里最考验设计能力的一环。划得太粗每个智能体什么都干退化成一个没有方向的大模型划得太细消息满天飞token 消耗翻好几倍。我最终定下五个智能体智能体名称核心角色职责边界不允许做的事orchestrator项目经理拆解需求、分配任务、汇总结果不直接操作数据data_fetcher数据采集专员调 API、查数据库、抓取网页不做任何数据分析data_cleaner数据清洗工程师补缺失值、去重、统一格式不产出业务结论analyst数据分析师跑统计、算环比、生成图表不写最终报告reporter报告撰写员整合分析结果、写周报正文不回改数据结论这个表格里的“不允许做什么”比“要做什么”更重要。很多人的多智能体系统失控本质上是角色边界模糊。比如 reporter 写着写着觉得某项分析不合理顺手改了一下分析结论——这在人类团队里叫越权在智能体团队里同样不该发生。我在每个智能体的 system_message 里都用了一整段话强调边界“你只能基于其他智能体提供的结果进行撰写不得自行修改任何数据结论。如发现异常只须明确指出并请求重新处理。”这个约束让系统行为稳定了不少。2.3 消息流转与群聊机制AutoGen 提供了两种会话模式双人对话initiate_chat和群聊GroupChat。我的系统主流程走群聊因为任务天然涉及多角色协同。实现起来非常简单核心就是把所有智能体丢进一个 GroupChat然后交给 GroupChatManager 调度from autogen import GroupChat, GroupChatManager group_chat GroupChat( agents[orchestrator, data_fetcher, data_cleaner, analyst, reporter], messages[], max_round20, ) manager GroupChatManager(groupchatgroup_chat, llm_configllm_config) result orchestrator.initiate_chat( manager, message请生成本周业务周报重点关注华东区销售变化。 )跑起来之后你观察消息流会发现一个很有意思的现象智能体之间的对话节奏和人开会很像。orchestrator 说“开始干活”data_fetcher 汇报“已抓到数据共 3 个来源 1200 行”data_cleaner 说“清洗完毕处理缺失值 37 处统一日期格式”analyst 说“华东区环比上升 12%异常点是上海仓库缺货”reporter 说“报告已生成”。每轮消息都有明确的前置依赖很少出现两条消息同时“抢话”的情况——这就是 GroupChatManager 的调度在起作用。3. 核心细节解析GroupChat、Manager 和 Human-in-the-loop3.1 GroupChat 与 GroupChatManager 的工作原理很多人第一次接触 GroupChat 时以为它像微信群一样“所有人发言所有人看”。实际上 AutoGen 的群聊机制更像一个有主持人的研讨会。所有智能体的消息先汇聚到 GroupChat 的 messages 列表里然后 GroupChatManager 决定下一轮轮到谁发言。Manager 是怎么决定“轮到谁”的默认策略非常直接把当前所有历史消息拼接成 prompt丢给大模型让模型从当前发言智能体里选一个它认为“应该接着说”的。所以 Manager 本身也要消耗 token而且它消耗的 token 比例不低——我实测过Manager 的输入 token 大约占整体 token 消耗的 15% 到 25%取决于群聊轮数。这里有一个重要的优化空间你不需要过多关注 Manager 的选人策略而应该关注你给每个智能体写的 system_message 里的发言规则。比如我在 data_cleaner 的 system_message 里明确写了“你只会在收到‘数据已采集完成’的通知后发言否则保持沉默。”这比任何调度算法都管用因为 Manager 的选人逻辑本质上是参考历史消息里“谁被了”“谁的工作量还没完成”这些线索你提供清晰的触发条件选人准确率会明显提高。3.2 UserProxyAgent 的两种模式手动审批与自动执行AutoGen 里最容易被忽略却最实用的组件是 UserProxyAgent。它不是一个“用户聊天界面”而是一个代表用户执行动作的代理。它有两个核心能力一是可以把人类的话转达给其他智能体二是在需要执行代码时真正调用 Python 解释器或终端。它的 human_input_mode 参数决定你到底要付出多少人工干预我强烈建议你根据任务风险等级选模式human_input_mode行为表现适用场景我的使用建议NEVER全程自动代理直接执行代码并反馈结果数据抓取、格式转换、低风险分析不差钱的可以全用但建议设好 max_consecutive_auto_replyTERMINATE只在任务可能结束时询问人类需要人拍板交付物的场景适合周报生成后人工审核ALWAYS每轮行动都征求人类确认涉及真实交易、发布操作金融、运维等强监管场景不要嫌烦我在最初的版本里为了省事把 data_fetcher 对应的 UserProxyAgent 设成了 NEVER。结果有一回外部数据源的 API 返回了异常格式代理反复重试了 12 次白白烧了一笔 token还是拿不到正确数据。后来我把外部数据抓取的 human_input_mode 改成 TERMINATE并且加了异常识别 prompt遇到连续两次失败就停下来问人。这个改动让系统的无效消耗降低了大概六成。3.3 代码执行与工具调用让智能体真正“动手”AutoGen 的一大特色是 AssistantAgent 生成代码后UserProxyAgent 可以自动执行代码。我把这个能力形容为“让 AI 长出了手”——它不只是嘴上说“应该这样处理数据”而是真的把代码跑起来再根据运行结果迭代修正。不过这里有一个新手必踩的坑默认的 code_execution_config 用的是本地 interpreter这在本地开发没问题但如果你的智能体系统跑在服务器上或者需要多人共享强烈建议换到 Docker 沙箱执行。否则一个 assistant 生成的os.remove()就可能把你的生产环境文件删了。别笑我见过有人在共享开发机上写了个清理脚本直接把同事的临时数据全清了。code_execution_config { work_dir: workspace, use_docker: True, # 强烈建议 True timeout: 120, }开启 D