文章首先分析了单Agent在处理复杂任务时存在的上下文窗口限制、角色混淆等问题进而引出多Agent架构的优势。随后详细介绍了四种核心的多Agent模式SubAgents分层架构、HandOff控制权移交、Chat Group平等对话决策和自定义工作流编码业务流程并探讨了不同框架对这些模式的支持情况。最后文章总结了生产环境部署多Agent系统的关键经验如从小规模开始验证、定义清晰的输入输出Schema、设置终止条件以及重视日志和可观测性等。多Agent架构通过合理分配任务和优化协作流程有效提升了大模型的性能和实用性。去年年底一个团队用单 Agent 做研究报告生成。输入一段需求Agent 需要完成资料搜集、文档撰写、事实核查三个步骤。听起来不复杂但跑出来的结果把 leader 气得够呛它把三个角色塞进一个 prompt 里上下文膨胀到 80K tokens写到一半开始引用自己编的论文最后产出一份看起来很专业但事实全错的报告。单 Agent 的毛病在这一点上暴露得很彻底上下文窗口不够、角色混淆、一步错全盘歪、无法并行。让单 Agent 更强这条路走到头了。换个方向把任务拆开让多个 Agent 各自干各自擅长的。这就是 Multi Agent 的起点。1.四种核心模式多 Agent 系统的架构模式可以分为四类SubAgents、HandOff、Chat Group、自定义工作流。区分它们的关键是控制权的分配方式和 Agent 之间的通信路径。工程选型看的就是这个。一、SubAgents —— 一个老板一群员工SubAgents 是目前工业界用得最多的模式。调查数据约 70% 的企业级多 Agent 部署用的是这种架构。思路很直接一个 Supervisor Agent 负责分解任务、分配工作、汇总结果下面挂一组 WorkerSubAgents各干各的互不干扰。Airbnb 的研究系统设计就是个典型例子Lead Agent 用 Claude Opus 4 做规划协调3-5 个 SubAgents 用 Claude Sonnet 4 并行搜索。模型分层——贵的做编排便宜的做执行——token 成本控制住同时并行工人把 wall-clock time 压下来。用 LangGraph 写一个 Supervisor 模式的骨架pythonfrom langgraph.graph import StateGraph, END from langgraph.prebuilt import create_react_agent # 三个专业 SubAgent researcher create_react_agent( model, tools[web_search, arxiv_search], prompt你是一个资深研究员专注于收集和分析技术资料。 ) writer create_react_agent( model, tools[write_document, format_markdown], prompt你是一个技术写作专家擅长将复杂概念转化为清晰文章。 ) reviewer create_react_agent( model, tools[check_facts, grammar_check], prompt你是一个严格的审稿人确保内容的准确性和质量。 ) # Supervisor 的调度逻辑 def supervisor(state): response model.invoke([ SystemMessage(content你是团队 leader。根据当前进度决定 - 需要更多研究 → researcher - 可以开始写作 → writer - 需要审核 → reviewer - 任务完成 → FINISH), *state[messages] ]) return {next: response.content} # 构建图 graph StateGraph(AgentState) graph.add_node(supervisor, supervisor) graph.add_node(researcher, researcher) graph.add_node(writer, writer) graph.add_node(reviewer, reviewer) graph.add_conditional_edges(supervisor, lambda state: state[next], {researcher: researcher, writer: writer, reviewer: reviewer, FINISH: END}) for agent in [researcher, writer, reviewer]: graph.add_edge(agent, supervisor) graph.set_entry_point(supervisor) app graph.compile()这个模式的好处是结构清晰调试时能顺着 Supervisor 的决策链追溯每一步。代价也摆在那协调开销占 token 预算的 15%-45%Supervisor 自己成了单点瓶颈。Salesforce Agentforce 在路由上做了优化——把 Supervisor 的 LLM 路由换成了 HyperClassifier 这种 SLM。分类延迟降了 30 倍同时还能保持路由准确度。思路值得参考路由决策不一定非要用同款大模型。二、HandOff —— 把控制权交出去HandOff 和 SubAgents 的核心差异在控制权的归属。SubAgents 是调度——Supervisor 看着所有人干活。HandOff 是移交——一个时刻只有一个 Agent 活跃控制权整体切换。OpenAI Agents SDK 把 HandOff 作为一等公民设计。下面这段代码三个 Agent 通过 HandOff 互相转接没有中间层pythonfrom openai import agents triage_agent agents.Agent( name分诊Agent, instructions根据用户需求交接给合适的专业Agent。, handoffs[ agents.Handoff(targettech_agent, description技术问题), agents.Handoff(targetsales_agent, description销售咨询), agents.Handoff(targetsupport_agent, description售后支持), ] ) tech_agent agents.Agent( name技术Agent, instructions你是技术专家。解决技术问题必要时交回分诊。, tools[search_docs, run_code], handoffs[ agents.Handoff(targettriage_agent, description非技术问题交回分诊) ] ) sales_agent agents.Agent( name销售Agent, instructions你是销售顾问。处理定价、方案咨询。, tools[get_pricing, create_quote], handoffs[ agents.Handoff(targettriage_agent, description非销售问题交回分诊), agents.Handoff(targettech_agent, description需要技术确认) ] ) result agents.run(triage_agent, 我想了解你们的API性能指标)HandOff 适合客服和对话场景用户从咨询转到技术支持再转到售后控制权跟着话题走。Agent 不需要理解全局只需要知道我能不能处理不能就交给谁。Google ADK 在 HandOff 上做了上下文隔离——include_contents参数控制子 Agent 能看到多少历史。这个设计解决了一个实际问题技术 Agent 不需要看到销售 Agent 之前的报价明细信息过载反而影响判断。HandOff 的坑在调试。控制权在 Agent 之间跳转链路容易形成环路。如果 A 交给 BB 觉得不对交给 CC 又觉得该交给 A——三个 Agent 转圈用户干等。设置最大跳转次数和方向约束是工程上绕不开的。三、Chat Group —— 平等对话投票决策前两种模式都有控制中心Supervisor 或移交规则。Chat Group 把这个中心拿掉了。多个 Agent 地位平等通过对话、辩论、投票来达成决策。学术研究在这个方向上的积累比工业界多。Du et al. 在 ICML 2024 上的实验发现三个 LLM 多轮辩论后事实准确率显著优于单 Agent 的 CoT 和反思机制共识率约 89%。Wei et al. 在 ACL 2025 上做了一个更细的拆解不同决策机制在不同任务上的效果差很多。决策机制最佳场景效果提升投票Majority Voting推理任务13.2%共识Consensus知识任务2.8%分数决策FREE-MADToken 敏感场景消除共识成本投票在推理任务上的提升最大因为每个 Agent 的推理路径不同少数服从多数天然能过滤掉路径依赖导致的错误。知识任务用投票意义不大——三个 Agent 都从相似的训练数据里学到的知识投出来的结果不会更准。Chat Group 还有一种变体叫 Swarm——共享一个黑板Agent 并行工作互相看对方的发现来调整自己的方向。AutoGen 的 GroupChat manager 是 Chat Group 在框架层面的原生实现Agent 之间直接发消息不需要 Supervisor 插在中间。这个模式在工业界用得不广主要瓶颈在成本。三个 Agent 辩论三轮每个 Agent 都调一次大模型token 消耗是三倍。大部分生产场景用 Supervisor 就够了辩论模式更多出现在需要验证推理质量的高风险场景——法律分析、医疗诊断、科学发现。四、自定义工作流 —— 把路径握在手里SubAgents、HandOff、Chat Group 定义了 Agent 之间怎么通信。自定义工作流定义的是 Agent 按什么顺序执行——管的是流程的拓扑。最基础的形态是 Pipeline。MetaGPT 把软件公司的 SOP 编码成了 prompt 序列产品经理 Agent 写 PRD → 架构师 Agent 出设计 → 工程师 Agent 写代码 → 测试 Agent 跑用例。每个阶段的输出是下个阶段的输入SOP 本身成了幻觉的约束——工程师写出来的代码必须匹配架构师的接口定义不一致时报错而不是继续往下走。LangGraph 的 StateGraph 是构建自定义工作流的主力工具。有向图 typed state channels 条件边 循环组合起来能表达任意拓扑python# 一个条件路由的例子根据输入复杂度走不同路径 workflow StateGraph(AgentState) workflow.add_node(classify, classifier_agent) workflow.add_node(simple_handler, simple_agent) workflow.add_node(complex_planner, planner_agent) workflow.add_node(executor, executor_agent) workflow.add_node(reviewer, reviewer_agent) workflow.set_entry_point(classify) # 条件边简单任务走快速通道复杂任务走完整流程 workflow.add_conditional_edges( classify, lambda state: simple if state[complexity] 0.3 else complex, {simple: simple_handler, complex: complex_planner} ) workflow.add_edge(simple_handler, END) workflow.add_edge(complex_planner, executor) workflow.add_edge(executor, reviewer) workflow.add_edge(reviewer, END)自定义工作流的工程实践里Uber 的做法值得提。他们用 LangGraph 给 AI 编码 Agent 套了一层确定性测试验证 pipeline——Agent 写完代码后不是直接提交是先跑“语法检查 → 单测 → 集成测试 → 人工审批”。这套 pipeline 上线后省了 21000 个开发者工时测试覆盖率涨了 10%。CrewAI 提供了更轻量的选择。它把 Pipeline 封装成 Sequential Process20 行代码就能启动一个链式工作流。适合快速原型代价是灵活性不如直接写 StateGraph。动态编排是 2025-2026 的前沿方向。AMAS 系统可以在每次查询时从结构池里选最优拓扑DyLAN 通过 Agent 互评分数动态决定谁留谁走。工业界还没大规模采用思路值得跟不是设计一个完美拓扑是让系统学会什么时候该用哪个拓扑。2.框架对四种模式的支持不同框架对四种模式的支持不全。选框架之前先对一下你需要的模式框架有没有原生支持。框架SubAgentsHandOffChat Group自定义工作流LangGraph✅ StateGraph 构建✅ 条件边⚠️ 需自定义✅ 有向图 循环CrewAI✅ Hierarchical❌❌✅ SequentialOpenAI Agents SDK⚠️ 自行构建✅ Handoff 原语❌⚠️ 自行构建Google ADK✅ 层级 Agent 树✅ Agent Transfer❌⚠️ 自行构建AutoGen/AG2✅ GroupChat mgr✅ 动态切换✅ 原生对话⚠️ 维护模式LangGraph 覆盖面最全代价是学习曲线陡。CrewAI 上手最快但在 HandOff 和 Chat Group 上有缺口。OpenAI Agents SDK 把 HandOff 做到极致SubAgents 和自定义工作流可以自己搭不是原生支持。3.生产环境的几个教训下面的经验来自多个团队踩过的坑不是理论推演。从两个 Agent 开始。 很多人一上来就画十个 Agent 的架构图研究 Agent、写作 Agent、审核 Agent、格式化 Agent、翻译 Agent、配图 Agent、SEO Agent、发布 Agent、通知 Agent、归档 Agent。实际上两个 Agent 就能验证核心流程跑不跑得通。每加一个 Agent状态空间翻倍调试难度涨得更快。Agent 之间的输入输出 Schema 得先定死。 上游 Agent 产出什么结构、下游 Agent 期望什么结构这两个不匹配的时候整个流程静默出错。用 Pydantic 或类似方式把数据结构显式定义出来出错时有 trace不是一团黑。pythonfrom pydantic import BaseModel class ResearchOutput(BaseModel): topic: str key_findings: list[str] sources: list[dict] confidence: float class WriteInput(BaseModel): research: ResearchOutput style: str technical max_words: int 3000设置硬性终止条件。 多 Agent 系统最怕无限循环。Agent A 觉得不够让 Agent B 改B 改完 A 还不满意让 B 再改循环到 token 用光。每轮设最大迭代次数和 token 上限超了就强制终止并告警。日志和可观测性是救命的东西。 多 Agent 系统出问题时没有日志你连哪个 Agent 在哪一步出了什么错都不知道。至少记录每个 Agent 的输入/输出 token 数、每步执行耗时、状态变更前后对比。用 structlog 或 OpenTelemetry 埋点别等到线上挂了再后悔。人工介入节点不是失败标记。 查到的五个生产实践报告里全部保留了 HITL 检查点。高风险操作——删库、发批量邮件、金额超阈值的审批——在 Agent 执行前隔一个人。这不是对 Agent 的不信任是对自动化无法覆盖的边界的承认。4.收尾Multi Agent 解决的不是单 Agent 太弱是一个 Agent 不该干所有事。四种模式的选型逻辑SubAgents。任务能清晰分解成独立子任务有明确的协调者角色。生产环境的首选踩坑经验最多。HandOff。对话场景、客服分流、话题切换。控制权需要在 Agent 之间流转不是集中调度。Chat Group。需要多角度验证的推理任务。成本高建议只在单 Agent 置信度不足的高风险场景用。自定义工作流。业务流程已经明确需要把 SOP 固化成 Agent 的执行路径。LangGraph 的有向图 条件边是最灵活的选择。Gartner 预测到 2027 年 30% 的企业 AI 应用会采用多 Agent 架构。这个数字可能偏保守——2026 年上半年看到的案例数量已经远超这个比例。写多 Agent 系统之前先把两个 Agent 跑通。从两到十之间每一步加 Agent 的时候问自己这个 Agent 是让系统更快还是只是让架构图更好看。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取