1.1 AutoGen 是什么：起源、目标与核心能力
我初次听说AutoGen是在一个技术群里，有人分享微软开源了一个多智能体协作框架。我查了资料，AutoGen来自微软研究院，2023年发布。它的目标很直接，让开发者用对话的方式组织多个LLM智能体。核心能力包括可定制智能体、自动对话、工具调用、代码执行。我试着用了一下，感觉像给AI们开了一个会议室。
从我的角度看，AutoGen不只是一个库，它提供了一种思考AI协作的方式。你可以定义不同角色的智能体，比如助手、用户代理、代码执行器。它们通过消息传递来解决问题。这种设计让复杂任务拆解变得自然。
我作为研究者，觉得AutoGen的核心能力在于灵活性和可扩展性。你可以让智能体调用外部工具，执行代码，甚至让人类参与审批。这为构建自动化工作流打开了大门。
1.2 从单智能体到多智能体：为什么需要协作式 AI
我过去用单个ChatGPT处理任务，遇到复杂项目就卡壳。单个智能体上下文有限，容易遗忘，也缺乏不同视角。我尝试让它写一个数据分析报告，它只能给出通用模板。
后来我让多个智能体协作，一个负责写代码，一个负责检查，一个负责解释结果。效果明显提升。协作式AI模拟了人类团队的分工，每个智能体专注自己的强项。AutoGen让这种协作变得容易配置。
从团队管理者的视角，多智能体系统能减少单点故障，提高输出质量。我见过一些案例，多个智能体辩论后能得到更可靠的答案。这是单智能体难以做到的。
1.3 核心概念速览：Agent、Conversation、GroupChat、Tool
我刚开始学AutoGen，被几个术语绕晕。Agent就是智能体，可以理解为有特定角色的AI。Conversation是智能体之间的对话，一次对话就是一次交互过程。GroupChat让多个智能体在一个群里聊天。Tool是智能体可以调用的外部函数或代码。
我画了一张图帮助记忆。Agent发出消息，Conversation记录消息，GroupChat管理发言顺序，Tool执行具体操作。这四个概念构成了AutoGen的骨架。我建议新手先跑一个两智能体对话的例子。
我作为开发者，发现Tool特别有用。你可以把Python函数注册成工具，智能体就能调用它。比如计算器、搜索引擎、数据库查询。这让智能体不再只会说话，还能动手做事。
1.4 典型应用场景：软件开发、数据分析、研究与自动化
我在几个项目里试过AutoGen。软件开发方面，我让一个智能体写代码，另一个写测试，还有一个做代码审查。它们来回对话，产出可运行的代码。这比我自己写快多了。
数据分析场景也很棒。我上传一个CSV文件，让智能体生成分析代码，执行后得到图表，再让另一个智能体写报告。整个过程自动完成。研究场景里，我用多个智能体做文献综述，一个检索，一个总结，一个批判。
自动化方面，我配置智能体处理日常任务，比如整理邮件、生成周报。这些场景让我看到多智能体协作的潜力。AutoGen适合那些需要多步骤、多角色配合的任务。
1.5 学习路径：如何从 AutoGen 多智能体协作实战教程入门
我入门AutoGen时，先看了官方文档的快速开始。安装包，配置API密钥，运行一个简单的两智能体对话。这一步让我有了直观感受。之后我跟着一个实战教程，搭建了一个群聊，让三个智能体讨论问题。
我建议的学习路径是：先理解核心概念，再动手写代码。可以从AssistantAgent和UserProxyAgent开始。接着学习GroupChat和GroupChatManager。之后尝试工具调用和代码执行。再做一个小的项目，比如自动数据分析。
我作为过来人，提醒新手别急着看高级特性。把基础对话跑通，再逐步增加复杂度。网上有很多AutoGen多智能体协作实战教程，选一个跟着做。遇到报错就查日志，慢慢就熟悉了。
2.1 环境准备与第一个多智能体对话
我搭建AutoGen环境时，头一件事是创建虚拟环境。用conda新建一个Python 3.10的环境，然后执行pip install pyautogen。这里有个小坑，AutoGen更新快，不同版本API有变化。我建议锁定一个稳定版本，比如0.2.x。配置API密钥时，我把它放进环境变量OPENAI_API_KEY，代码里不用硬编码。这样安全，也方便切换模型。
初次多智能体对话，我只写了几行代码。一个AssistantAgent，一个UserProxyAgent。Assistant负责回答，UserProxy负责发消息和執行代码。我让UserProxy问“2的10次方是多少”，Assistant回答“1024”。UserProxy的human_input_mode设为NEVER，它自动回复。整个过程像两个人在聊天，其实是程序在跑。看到消息记录，我有点兴奋。
新手常犯的错是直接复制旧教程代码。我建议从官方Quickstart开始，跑通再改参数。我的初次对话只用了几分钟。那种感觉像打开了新世界的大门。别急着加复杂功能，先让两个智能体说上话。
2.2 核心角色：AssistantAgent、UserProxyAgent 与 GroupChatManager
AssistantAgent是写代码和回答问题的角色。我给它配了系统消息：“你是一个helpful AI assistant，擅长解决任务。”它默认用LLM生成回复。UserProxyAgent是用户代理，可以代表人类发消息，也能执行代码。我经常把它当成万能工具人。GroupChatManager比较特殊，它管理群聊，决定谁发言。
配置UserProxyAgent时，我会设置human_input_mode。ALWAYS表示每次都要我输入，NEVER表示它自动回复，TERMINATE只在终止时询问。我通常用NEVER做自动化测试，用ALWAYS做人工审核。GroupChatManager需要传入一个GroupChat对象，里面包含所有智能体。它的speaker_selection_method决定发言顺序。
从团队管理者的视角，这三个角色像项目经理、执行者和协调员。AssistantAgent出方案，UserProxyAgent做执行，GroupChatManager排日程。我调试时经常打印它们的消息，看谁在什么时候说了什么。理解角色分工，协作就顺了。
2.3 任务分解与群聊编排：发言顺序、终止条件与轮次控制
我设计群聊时，最头疼的是发言顺序。默认的round_robin按顺序轮流，有时不灵活。我改用auto，让LLM决定下一个发言者。效果不错，偶尔会重复。我设置max_round=10，防止无限循环。终止条件可以是一条消息包含“TERMINATE”。我让UserProxyAgent在任务完成时发这个关键词。
我试过让三个智能体讨论一个编程题。一个写代码，一个审查，一个测试。轮次控制很重要，太多轮浪费token，太少轮问题没解决。我的经验是，先设max_round=5，看看效果，再调整。我还用speaker_selection_method="auto"配合自定义的speaker选择函数，实现更复杂的逻辑。
作为研究者，我分析过群聊的消息流。发言顺序影响结果质量。我建议在GroupChat里明确每个角色的职责。终止条件要写在系统消息里，让智能体知道何时结束。轮次控制是门艺术，需要多试几次。别怕调整参数，跑几次就有感觉了。
2.4 工具调用与代码执行：安全沙箱、函数注册与结果回传
工具调用让AutoGen从聊天机器人变成执行者。我注册了一个计算器函数，用register_function绑定到UserProxyAgent。智能体需要计算时，会调用这个函数。代码执行默认在本地，我不建议。我用Docker沙箱，配置code_execution_config里的use_docker。这样代码在容器里跑，安全很多。
函数注册的流程是：定义Python函数，写清楚参数和返回值。调用register_function，指定caller和executor。调用结果会作为消息回传。我试过注册一个获取天气的函数，智能体问天气时，UserProxyAgent会执行函数，把结果返回给Assistant。整个过程自动完成。
从安全角度看，沙箱必不可少。我见过有人执行了删除文件的代码，还好在Docker里。我还会限制执行的超时时间，设置work_dir。结果回传时，要注意消息格式，否则智能体可能看不懂。我的习惯是让函数返回字符串，简单直接。安全第一，别在生产环境裸跑代码。
2.5 实战案例：自动数据分析报告生成
我拿一个销售数据的CSV文件做案例。创建三个智能体：数据工程师、数据分析师、报告撰写者。数据工程师负责加载CSV和清洗。数据分析师生成图表和统计。报告撰写者写Markdown报告。我用GroupChat让它们协作。
我让UserProxyAgent上传文件，之后发消息：“请分析sales.csv，生成报告。”数据工程师先发言，写代码读取文件。UserProxy执行代码，返回前几行数据。数据分析师之后写代码画图，UserProxy执行后保存图片。报告撰写者根据结果写报告。收尾时UserProxy发“TERMINATE”。整个过程大概跑了20秒。
从用户角度，这个案例太方便了。我只需要提供文件，剩下的自动完成。报告里包含销售额趋势、Top产品、区域分布。我还让智能体把报告保存为report.md。这个实战让我理解了多智能体协作的威力。我建议新手从这个案例入手，逐步增加复杂度。
2.6 调试与排错：日志、错误恢复与协作失败诊断
调试AutoGen时，我打开logging。设置logging.basicConfig(level=logging.DEBUG)能看到详细消息。常见错误是API超时，我加retry机制。还有智能体陷入循环，我检查max_round和终止条件。协作失败通常是因为角色定义不清，或者消息格式不对。
我遇到过一次，UserProxy执行代码报错，但Assistant没发现。之后我让UserProxy把错误信息也发出来，Assistant就能根据错误调整代码。错误恢复可以设置max_consecutive_auto_reply，防止一个智能体一直说话。我还用try-except包裹代码执行，捕获异常。
作为排错老手，我建议先看消息历史。GroupChat有messages属性，打印出来一目了然。如果智能体不按预期发言，检查speaker_selection_method。日志是最好朋友。我还会用clear_history()重置对话，避免上下文污染。多试几次，就能找到问题。
3.1 设计哲学：AutoGen 会话驱动与 LangChain 链式编排
我最初接触 AutoGen 时，感觉它像在组织一场会议。每个智能体都有自己的角色，它们通过发送消息来推进任务。AutoGen 的设计哲学就是会话驱动。任务不是被拆成固定步骤，而是交给智能体们你一言我一语地讨论出来。这种模式很接近人类团队解决问题的过程。我让一个智能体写代码，另一个审查，第三个测试，它们会自动交流，直到任务完成。整个过程没有预定义的流程图，更像一场自由讨论。
LangChain 给我的感觉完全不同。它像一条装配线。每个组件是一个工位，数据从一端流入，经过一系列处理，从另一端流出。链式编排意味着我需要明确每一步做什么，前一步的输出如何传给下一步。我写 LangChain 代码时，脑子里要清楚整个流程。这种设计适合确定性强的任务。比如先检索文档，再总结，最后生成回答。每个环节都受控，可预测。
两种哲学没有绝对的好坏之分。我选 AutoGen 时，看重它的灵活和涌现行为。我选 LangChain 时，看重它的可控和可调试性。一个像头脑风暴，一个像流水线。我的项目里，如果任务需要多角色反复协商，我会倾向 AutoGen。如果任务步骤清晰、需要精确控制，我会用 LangChain。
3.2 核心抽象：Agent、GroupChat、Tool 与 Chain、Runnable、Tool
AutoGen 的核心抽象里，Agent 是最基本的单位。每个 Agent 有名字、系统消息和对话历史。我配置 AssistantAgent 时，会写清楚它的专长。GroupChat 是多个 Agent 的容器，它管理消息路由。GroupChatManager 决定下一个发言者是谁。Tool 是 Agent 可以调用的外部函数。我注册一个计算器工具，Agent 需要时就会调用它。这些抽象围绕“对话”展开。Agent 之间通过消息传递协作，GroupChat 像一个聊天室。
LangChain 的核心抽象是 Chain 和 Runnable。Chain 是组件的序列，Runnable 是任何可以调用的单元。我把一个提示模板、一个模型、一个输出解析器串起来，就形成一条链。Tool 在 LangChain 里也是工具，但通常被 Agent 或链调用。LangChain 的抽象更偏向函数式组合。每个 Runnable 有 invoke、batch、stream 等方法。我组合它们时，像在搭乐高积木。
从我的使用体验看，AutoGen 的抽象更接近人类组织。Agent 有记忆、有角色，GroupChat 有发言规则。LangChain 的抽象更接近数据流。Runnable 是纯函数，输入输出明确。我调试 LangChain 时，可以单独测试每个 Runnable。调试 AutoGen 时，我要看完整的消息历史。两种抽象服务于不同场景。我写多智能体对话用 AutoGen 的 Agent 和 GroupChat 很自然。我写数据处理管道用 LangChain 的 Chain 和 Runnable 很顺手。
3.3 多智能体协作：AutoGen GroupChat 与 LangGraph 状态图对比
AutoGen 的 GroupChat 实现多智能体协作很直接。我创建一个 GroupChat 对象，传入所有智能体，再配一个 GroupChatManager。发言顺序可以设为 round_robin 或 auto。auto 模式下，LLM 根据上下文决定谁说话。我试过让三个智能体讨论一个编程问题，它们自动轮流发言，有时还会互相纠正。终止条件是一条包含 TERMINATE 的消息。整个协作过程像一场没有主持人的圆桌讨论。我只需要定义角色和初始消息。
LangGraph 走的是另一条路。它用状态图来定义多智能体系统。节点代表智能体或工具，边代表状态转移。我需要显式画出谁在什么条件下把控制权交给谁。这像设计一个有限状态机。我构建 LangGraph 时，要定义状态的结构，每个节点如何更新状态，以及条件边如何判断。控制粒度很细。我可以精确指定某个智能体只有在收到特定消息时才被激活。这种精确性适合复杂工作流。
我实践下来的感受是，AutoGen GroupChat 上手快，适合探索性协作。LangGraph 学习曲线陡一些，但控制力强。我的一个项目需要多个智能体按严格顺序处理任务，中间还要人工审批。我用 LangGraph 实现了状态流转，把人工审批作为一个节点。另一个项目需要智能体自由讨论创意方案，我用 AutoGen GroupChat，让它们自动碰撞想法。两者都能做多智能体，但风格迥异。
3.4 生态与集成：模型、向量库、RAG、可观测性差异
LangChain 的生态非常庞大。它支持几乎所有主流模型，OpenAI、Anthropic、Hugging Face 等等。向量库集成也很丰富，Pinecone、Chroma、FAISS 都有现成封装。RAG 是 LangChain 的强项。我可以用文档加载器、文本分割器、向量存储、检索器快速搭一个 RAG 管道。可观测性方面，LangSmith 提供了追踪、评估和监控。我调试复杂链时，LangSmith 能显示每一步的输入输出和耗时。这些生态组件让 LangChain 成为构建 LLM 应用的全能工具箱。
AutoGen 的生态更聚焦于多智能体协作本身。它主要支持 OpenAI 的模型，也支持通过配置使用其他模型。向量库和 RAG 不是 AutoGen 的核心功能。我需要在 AutoGen 里做 RAG 时，往往要自己集成 LangChain 或其他库。可观测性方面，AutoGen 有日志和消息历史，但不如 LangSmith 那样系统化。我调试 AutoGen 主要靠打印消息和日志。AutoGen 也在发展，比如支持自定义模型客户端，但整体生态广度不如 LangChain。
我的选择逻辑是，如果项目需要大量外部集成，比如多种模型切换、复杂 RAG、详细追踪，我会以 LangChain 为主。如果项目核心是多智能体对话和协作，AutoGen 更直接。我有时候把两者结合。用 LangChain 处理数据检索和预处理，把结果交给 AutoGen 的智能体群聊做决策。生态差异不是优劣，是定位不同。
3.5 选型建议：单智能体、多智能体、复杂工作流如何选择
单智能体任务，我通常选 LangChain。一个智能体加几个工具，用 LangChain 的 Agent 或简单链就能搞定。比如问答机器人、文档总结、简单代码生成。LangChain 的 Runnable 组合灵活，调试方便。我写一个链，把提示、模型、解析器串起来，几行代码就完成。单智能体不需要复杂协作，LangChain 的轻量抽象更合适。
多智能体协作任务，AutoGen 是首选。任务需要多个角色反复交流、互相检查、动态分工时，AutoGen 的 GroupChat 能自然表达。我做过一个数据分析项目，数据工程师、分析师、报告撰写者三个智能体协作。用 AutoGen 我只需要定义角色和初始消息，它们自己讨论出结果。用 LangChain 实现同样的协作，我要手动编排每个智能体的调用顺序和消息传递，代码量更大。
复杂工作流，比如需要精确状态控制、条件分支、循环、人工介入，LangGraph 更合适。LangGraph 的状态图能清晰表达控制流。我可以用条件边实现“如果代码执行失败，就回到修正节点”。这种精确控制 AutoGen 的 GroupChat 不容易做到。我的经验是，探索性、开放式协作选 AutoGen。确定性、流程化任务选 LangChain 或 LangGraph。不要硬套一个框架，根据任务特征选。
3.6 组合使用：在 LangChain 项目中引入 AutoGen 协作层
我试过在 LangChain 项目里嵌入 AutoGen。思路是把 AutoGen 的 GroupChat 封装成一个工具或一个 Runnable。LangChain 负责前置的数据准备、检索、后置的结果格式化。AutoGen 负责中间的多智能体协作。比如一个报告生成系统，LangChain 先检索相关文档，把文档内容作为输入传给 AutoGen 群聊。群聊里的智能体讨论、分析、撰写报告。报告文本返回给 LangChain，再做最终输出。
具体实现时，我写了一个函数，内部创建 AutoGen 的 AssistantAgent、UserProxyAgent 和 GroupChat，启动对话，收集最终消息。这个函数被包装成 LangChain 的 Runnable。在链中调用它，就像调用任何其他 Runnable 一样。这样 LangChain 的生态优势（向量库、RAG、可观测性）和 AutoGen 的协作优势可以结合。我不用二选一。
组合使用也有挑战。消息格式要统一，错误处理要跨框架。AutoGen 的对话可能产生大量 token，成本要控制。我的做法是给 GroupChat 设置 max_round 和终止条件，避免无限循环。我还用 LangSmith 追踪整个链，包括 AutoGen 调用前后的步骤。这种混合架构适合需要多智能体协作又依赖丰富生态的项目。我的经验是，先从简单集成开始，跑通一个最小示例，再逐步增加复杂度。
4.1 自定义智能体与高级协作模式：嵌套群聊、动态角色、辩论
我玩了一阵子 AutoGen 的基础 GroupChat 之后，开始觉得默认的 AssistantAgent 和 UserProxyAgent 不够用了。默认智能体给我的感觉像标准零件，能跑通很多场景，可一旦任务变得奇怪，它就不太听话。我试过给智能体写很长的系统消息，让它扮演一个挑剔的代码审查员，效果还行。后来我干脆继承 ConversableAgent，重写 generate_reply 方法。这样智能体在每次发言前可以先跑一段我自己的逻辑，比如查数据库、调情感分析模型，再决定怎么回复。改完之后，整个协作的感觉完全不一样了。智能体不再是纯聊天机器人，它有了自己的小算盘。
嵌套群聊是我最近才玩明白的东西。简单说，就是把一个 GroupChat 当成另一个 GroupChat 的成员。我做过一个产品需求评审的系统。外层群聊里有产品经理、技术负责人和项目经理三个智能体。技术负责人自己内部又带了一个子群聊，里面有前端、后端和测试三个智能体。外层讨论到技术方案时，技术负责人会触发内层群聊，让子智能体们先吵一架，得出一个内部共识，再把结论带回外层。这种嵌套结构让复杂组织关系有了对应的代码表达。我不用把所有角色都塞进一个大群聊里，那会乱成一锅粥。
动态角色也很有意思。我有个智能体，平时是数据分析师，一旦检测到对话里出现“安全”或“权限”关键词，它的系统消息会切换成安全审计员。这种切换不是重新创建智能体，而是修改它的 system_message 属性，下一轮发言就会按新角色来。辩论模式我专门试过。我让两个智能体分别持有正反观点，第三个智能体做裁判。我给它们设了一个循环规则，正反双方各发言两轮，裁判总结。AutoGen 的 max_round 参数可以限制总轮次，防止它们吵个没完。辩论出来的结论往往比单个智能体直接回答更有层次，因为反方会逼着正方补漏洞。
4.2 人机协同与审批流：Human-in-the-loop 的落地方式
Human-in-the-loop 这个词听起来很正式，我做起来其实很简单。UserProxyAgent 有一个 human_input_mode 参数，我设成 “ALWAYS” 时，每轮对话都会停下来等我输入。这适合调试阶段，我能看到智能体们在聊什么，随时插话。设成 “TERMINATE” 时，只有满足终止条件才需要我确认。我平时用 “NEVER”，让智能体全自动跑，但在关键节点上单独挂一个审批 Agent。
审批流的实现方式我摸索出两种。一种是用一个自定义 Agent，它的 generate_reply 方法里不调用 LLM，而是发一条消息到一个消息队列，或者写一条数据库记录，然后轮询等待审批结果。审批通过就返回 “APPROVED”，不通过就返回具体修改意见。另一种更轻量，我把审批动作包装成一个工具函数，注册给某个智能体。智能体需要审批时调用这个工具，工具内部会发邮件或发 Slack 消息给人类。人类回复后，工具把结果返回给智能体。这两种方式我都用过，第一种适合正式的企业流程，第二种适合小团队快速验证。
我踩过一个坑。有一次我让一个智能体在调用工具前必须等人类审批，结果人类忘了回复，整个 GroupChat 卡住了。AutoGen 默认没有超时机制。我后来在审批工具里加了超时逻辑，比如五分钟没回复就自动拒绝，并让智能体走备选方案。人机协同的关键不是技术，是流程设计。人类什么时候介入、介入后智能体怎么继续、超时怎么办，这些想清楚了，代码其实就几十行。我现在做审批流，会先画一张状态图，把人类节点和智能体节点都标出来，再写代码。
4.3 评估、成本与安全：多智能体系统的质量、Token 与权限治理
多智能体系统的评估比单智能体麻烦很多。单智能体我只需要看最终答案对不对。多智能体我要看它们协作的过程，有没有互相误导、有没有陷入循环、有没有某个智能体一直不发言。我试过几种评估方法。一种是人工抽检对话记录，看关键决策点是否合理。另一种是让一个独立的评估智能体读完整段对话，给协作质量打分。后一种方法省人力，但评估智能体本身也可能有偏见。我现在把两种方法混着用，关键项目人工看，日常迭代用自动评估。
Token 成本是我最头疼的问题。三个智能体聊二十轮，token 消耗可能是单智能体的十倍。我做过统计，GroupChat 里大部分 token 花在了重复的上下文上。每个智能体发言时，都会把之前的完整对话历史带上。我后来用了两个办法。一个是给 GroupChat 设置 max_round，比如最多十轮，到点就强制终止。另一个是定期压缩对话历史，把早期消息总结成一段摘要，替换掉原始消息。AutoGen 本身没有内置的摘要功能，我自己写了一个函数，在每五轮之后调用一次。成本降了大概四成。
安全治理我分成两块。工具权限方面，我给每个智能体配一个工具白名单。写代码的智能体只能调用代码执行工具，不能调用发邮件或查数据库的工具。代码执行我放在 Docker 沙箱里，限制网络访问和文件系统权限。权限管理方面，我设了一个权限智能体，任何敏感操作都要经过它批准。它内部维护一张规则表，比如“删除文件需要两个智能体同意”，“访问用户数据需要人类审批”。这些规则写死在代码里，不让 LLM 自由发挥。多智能体系统越自动，越需要这些硬约束。
4.4 生产部署与可观测性：日志、追踪、容错与扩展
我把 AutoGen 应用部署到生产环境时，第一个感觉是裸奔。开发阶段打印消息就够了，生产环境需要完整的日志和追踪。我现在的做法是用 Python 的 logging 模块记录每一条消息，包括发送者、接收者、内容、时间戳和 token 数。这些日志统一收集到 ELK 或类似系统里。追踪方面，我把 AutoGen 的调用包裹在 OpenTelemetry 的 span 里。这样一次 GroupChat 会话在追踪系统里就是一棵调用树，我能看到每个智能体发言花了多久、调用了哪些工具、工具执行了多长时间。
容错是我在生产环境里花时间最多的地方。智能体会调用外部 API，API 会超时或返回错误。LLM 本身也可能返回格式不对的内容。我给每个工具调用加了重试机制，最多重试三次，每次间隔递增。如果重试都失败，智能体会收到一个结构化错误消息，它可以决定换一个工具或者向其他智能体求助。我还设了一个全局超时，整个 GroupChat 超过一定时间就强制终止，返回当前最好的结果。这些容错逻辑不是 AutoGen 自带的，需要我自己在工具函数和智能体方法里实现。
扩展性方面，AutoGen 本身是单进程的，一个 GroupChat 跑在一个 Python 进程里。要支撑高并发，我的做法是把每个会话放在独立的 worker 进程里，前面加一个消息队列。请求进来后，队列分配一个 worker，worker 内部创建 GroupChat 并运行。会话状态可以存 Redis，这样 worker 崩溃后可以恢复。我也试过用 Ray 来并行化多个 GroupChat，但调试复杂度上升很多。小规模部署用进程加队列就够了，超过一定量级再考虑分布式方案。我现在的生产系统每天处理几千个会话，用的就是简单的 worker 池加 Redis 状态存储。
4.5 学习资源与实战路线：从官方教程到企业级项目
我学 AutoGen 的路线比较笨，但有效。官方文档我通读了两遍，第一遍看概念，第二遍跟着示例敲代码。官方 GitHub 仓库里的 notebooks 是宝藏，尤其是那些展示 GroupChat 和工具调用的例子。我建议先把 examples 目录下的每个 notebook 跑一遍，跑不通就查 issue。AutoGen 的社区很活跃，很多坑别人已经踩过了。微软还出了 AutoGen Studio，一个低代码的界面，可以用拖拽的方式搭建多智能体系统。我拿它来做原型验证，省了不少写代码的时间。
进阶阶段我推荐自己造几个小项目。我做过的第一个项目是自动代码审查。两个智能体，一个写代码，一个审查，审查意见反馈给写代码的智能体修改，来回三轮。第二个项目是自动数据分析报告，四个智能体分别负责数据加载、清洗、分析和撰写。第三个项目是客服工单分类和回复，这个项目里我加了人工审批节点。每个项目做完，我都会回头读一遍官方文档里对应的章节，理解会深很多。项目不用大，但要完整，从输入到输出跑通。
企业级项目我参与过一个金融领域的合同审查系统。那个系统用了十几个智能体，分三层：文档解析层、条款分析层、风险汇总层。每个层内部有子群聊，层与层之间通过消息传递结果。这个项目的经验是，企业级 AutoGen 应用的关键不在智能体本身，而在外围的工程设施。文档存储、权限控制、审计日志、人工审批流、监控告警，这些东西占了代码量的七成。智能体逻辑反而是最简单的一部分。如果你要从头学，我建议先花时间把工程基础打牢，再研究智能体协作的花样。智能体再聪明，跑在一个不稳定的系统上也是白搭。
