摘要核心问题单个 Agent 受限于上下文窗口、能力边界和角色冲突难以独立完成规划—研究—撰写—校验这类需要多专业技能的复杂任务。主要贡献把一个全能 Agent拆成一组各司其职的 Agent通过角色分工 通信协议 协作拓扑把复杂度摊开让每个 Agent 只解决自己擅长的一小块。阅读收获理解多智能体相比单 Agent 解决什么、又引入什么新成本掌握四种经典协作拓扑流水线 / 辩论 / 主管 / 网络的适用边界看清 AutoGen、CrewAI、LangGraph 三套框架的分工与取舍拿到一份可直接运行的多智能体骨架代码避开成本爆炸 / 错误传播 / 永不收敛三个常见坑。一、背景与动机为什么需要多个 Agent在第21–26篇里我们已经把提示词 → 工具 → 检索 → 微调 → 单 Agent 编排这一条链路打通了。一个写好的 LangGraph Agent第26篇已经能带审批的研究工作流、断点续跑、人在回路。但它本质上还是一个单体——所有决策都挤在同一个上下文、同一个角色里。当任务变复杂单体 Agent 会撞上三道墙墙现象根源上下文墙规划、资料、草稿、校验全塞进一个窗口越到后面越忘了前面上下文窗口有限第12篇能力墙既要懂架构、又要懂安全、还要会写文案单模型难以样样精通模型有专长偏向LoRA 也只强化一面第24篇角色冲突让它既当裁判又当运动员自评自写容易自我妥协缺乏独立视角的制衡多智能体Multi-Agent的核心思想用分而治之 相互制衡替代一个 Agent 包打天下。让一个 Agent 当规划者一个当研究员一个当写手一个当批评家彼此通过明确协议通信。这就像把一个人写论文变成一个课题组。呼应第20篇的知识地图多智能体处在应用实战篇的顶端它把前面所有的零件Prompt、Tool、RAG、微调、图编排组合成系统。二、技术原理2.1 三个基本要素任何多智能体系统都可以拆成三件事角色分工Role Specialization每个 Agent 有清晰的人设与职责边界“你是资深审稿人只挑逻辑漏洞”。人设即第21篇讲的 System Prompt但被固化成长期身份而不是每次临时写。通信协议Communication ProtocolAgent 之间怎么说话。可以是私聊点对点消息、群聊广播、共享黑板大家读写同一块记忆。协议越明确系统越可控。协作拓扑Topology谁和谁连、信息怎么流动。这是和单 Agent 编排第25/26篇的图最不同的地方——控制流从一张图变成一张网。2.2 四种经典协作拓扑拓扑结构最适合代表框架思路流水线 PipelineA→B→C 串行每步加工后传给下一步步骤清晰、可线性分解如 抓取→清洗→摘要用第26篇的线性 LangGraph 即可辩论 DebateA⇄B 互审互改直到收敛需要对抗性校验、减少幻觉第17篇自我一致性 / 多模型投票主管 Supervisor一个 Orchestrator 分派任务给若干 Worker回收结果任务类型多、需动态调度AutoGen GroupChat、CrewAI网络 Network去中心化Agent 自由互联、涌现协作开放式、规模大、难以预设流程研究探索阶段工程上最难经验法则能线性分解 →流水线最简单优先用怕出错要制衡 →辩论任务杂、要动态派活 →主管网络慎用——没有全局协调者时极易聊天聊死、谁都不收尾。2.3 通信协议消息即契约多智能体里最常见的 bug 不是模型弱而是消息格式乱、下游读不懂。因此成熟框架都强调结构化消息{ from: supervisor, to: researcher, type: task, payload: { query: LangGraph 的 interrupt 怎么用, constraints: [要带代码示例, 引用官方文档] }, reply_to: task-123 }要点任务规格要可机器解析别只写你去研究一下要写清目标、约束、返回格式。共享黑板Blackboard把临时结论、全局状态放到大家都能读写的记忆里类比第25篇的 Memory避免信息只在私聊里丢失。终止条件显式化用达到最大轮数 / 收到done信号 / Critic 打分通过来收尾防止无限循环呼应第26篇别让模型自由循环。2.4 三大框架定位对比维度AutoGen微软CrewAILangGraph第26篇核心抽象AssistantAgentGroupChat群聊Agent(角色) TaskCrewStateGraph有状态图协作模型对话驱动Agent 在群里轮流发言角色 任务Crew 按流程跑显式图节点/边/条件编程范式事件/会话式偏让 Agent 自己聊声明式配置角色与任务代码即图偏我画流程状态管理会话历史隐式管理Task 上下文传递Checkpointer 显式持久化最擅长快速搭多 Agent 对话原型业务化岗位协作场景可控、可干预、可恢复的生产流选型建议想做多模型辩论/群聊实验想按岗位组织团队做事要审批/回滚/跨会话的生产系统它们不是互斥的实践中常用 CrewAI/AutoGen 定义角色与协作底层用 LangGraph 托住控制流与状态——第26篇的图能力正好补上多智能体的可观测/可恢复短板。2.5 工程陷阱必看成本与延迟爆炸N 个 Agent 各调一次大模型Token 与耗时近似线性放大。务必设max_rounds、缓存中间结果语义缓存第37篇会展开。错误传播上游 Agent 一出错的假结论会被下游当真越传越离谱。要在关键节点加校验 AgentCritic和人在回路第26篇interrupt。永不收敛辩论型没有终止条件会一直聊。必须显式收尾。可观测缺失多 Agent 出问题最难查。给每条消息打trace_id、记录角色与轮次必要时回到第26篇的 Checkpointer 做时间旅行回放。三、实战可运行的多智能体骨架下面给一份不依赖任何 API Key 也能跑的玩具多智能体用假 LLM 演示主管分派 写手 审稿人的协作与收敛判定帮助你建立完整心智模型。把它替换成真实模型调用即可生产化。# multiagent_demo.py —— 一个最小可运行的多智能体骨架主管 写手 审稿人fromdataclassesimportdataclass,fieldfromtypingimportCallable,List# ---------- 1. 假 LLM真实场景换成 OpenAI/本地模型调用 ----------deffake_llm(role:str,prompt:str)-str:ifrolewriter:returnf[草稿] 关于「{prompt}」的要点A. 分角色B. 定协议C. 选拓扑。ifrolecritic:# 审稿人根据轮次逐步放行returnAPPROVEif示例inpromptelseREVISE: 缺少可运行示例returnok# ---------- 2. Agent 定义角色 各自的 LLM 策略 ----------dataclassclassAgent:name:strrole:stract:Callable[[str],str]defmake_agents(llm):writerAgent(写手,writer,lambdap:llm(writer,p))criticAgent(审稿人,critic,lambdap:llm(critic,p))returnwriter,critic# ---------- 3. 主管分派任务、回收结果、判定收敛 ----------dataclassclassSupervisor:writer:Agent critic:Agent max_rounds:int3trace:List[str]field(default_factorylist)defrun(self,topic:str):draftself.writer.act(topic)self.trace.append(f[{self.writer.name}]{draft})forrinrange(self.max_rounds):verdictself.critic.act(draft)self.trace.append(f[{self.critic.name}] 第{r1}轮:{verdict})ifverdictAPPROVE:returndraft,self.trace# 把审稿意见回灌给写手迭代改写draftself.writer.act(topic按意见补充示例)self.trace.append(f[{self.writer.name}] 修订:{draft})returndraft,self.trace# 达上限也收尾防止死循环# ---------- 4. 跑起来 ----------if__name____main__:w,cmake_agents(fake_llm)supSupervisor(w,c,max_rounds3)result,logsup.run(多智能体系统的核心思想)print( 执行轨迹 )forlineinlog:print( ,line)print(\n 最终产物 \n,result)运行输出会显示写手出初稿 → 审稿人要求补示例 → 写手修订 → 审稿人放行。这正好演示了主管调度 角色制衡 显式终止三件套。真实工程里fake_llm换成你的模型客户端第22篇 Function Calling 让写手/审稿人能调工具查资料加一个researcherAgent 用 RAG第23篇检索背景用第26篇的StateGraph把主管→写手→审稿人画成可回放、可干预的图。四、优缺点与选型4.1 什么时候该上 Multi-Agent信号建议单 Agent 上下文总溢出、忘前文✅ 拆角色各管一段任务需要互相挑错保证质量✅ 加 Critic / 辩论任务类型多、要动态调度✅ 主管拓扑AutoGen/CrewAI只是简单线性流水线❌ 用第26篇 LangGraph 线性图就够别过度设计延迟/成本极度敏感⚠️ 多 Agent 是奢侈品先想能不能单 Agent 好 Prompt第21篇4.2 框架怎么选决策树想快速验证多模型辩论/群聊想法→ AutoGen业务上本来就是岗位协作分析师、文案、审核→ CrewAI要上生产、要审批/回滚/跨会话恢复/可观测→ LangGraph 托底外层再用 CrewAI/AutoGen 组织角色极致可控、流程固定→ 直接 LangGraph 状态图第26篇不一定需要多框架。五、总结与展望关键点回顾多智能体用分而治之 相互制衡解决单 Agent 的上下文墙、能力墙、角色冲突。四种拓扑流水线 / 辩论 / 主管 / 网络按能否线性分解、要不要制衡、要不要动态调度选。通信协议要结构化——消息即契约配共享黑板与显式终止条件。AutoGen群聊、CrewAI岗位、LangGraph显式图各有所长常组合使用。三大坑成本延迟爆炸、错误传播、永不收敛——都用上限 校验 可观测对付。未来方向多智能体再往前走一步就是Agent 自己设计 Agent——自动分工、自动演化协作策略这会把我们带向第51篇AI Agent 自主进化。而把多 Agent 真正落地到代码工程下一站是代码大模型让 Agent 不只是写文档而是能读写真实代码仓库、跑测试、修 Bug。下期预告《第28篇代码大模型——原理、训练与实战》。参考资料Microsoft AutoGen 文档microsoft.github.io/autogenCrewAI 文档docs.crewai.comLangGraph 文档langchain-ai.github.io/langgraph本博客《第21篇 Prompt Engineering》《第22篇 Function Calling》《第23篇 RAG》《第24篇 Fine-tuning》《第25篇 LangChain》《第26篇 LangGraph》延伸讨论思考题你手头最复杂的一个 Agent 任务如果用主管 写手 审稿人拆开哪个角色最容易成为瓶颈实践作业把上面的fake_llm换成真实模型调用并给researcher接上第23篇的 RAG让审稿人能引用检索到的资料提意见。读者问答上篇评论区有人问Agent 网络失控怎么加全局协调者——答案就是本文的主管拓扑 显式终止条件 第26篇 Checkpointer 回放欢迎结合你的场景继续聊。