去年年底一个团队用单 Agent 做研究报告生成。输入一段需求Agent 需要完成资料搜集、文档撰写、事实核查三个步骤。听起来不复杂但跑出来的结果把 leader 气得够呛它把三个角色塞进一个 prompt 里上下文膨胀到 80K tokens写到一半开始引用自己编的论文最后产出一份看起来很专业但事实全错的报告。单 Agent 的毛病在这一点上暴露得很彻底上下文窗口不够、角色混淆、一步错全盘歪、无法并行。让单 Agent 更强这条路走到头了。换个方向把任务拆开让多个 Agent 各自干各自擅长的。这就是 Multi Agent 的起点。四种核心模式多 Agent 系统的架构模式可以分为四类SubAgents、HandOff、Chat Group、自定义工作流。区分它们的关键是控制权的分配方式和 Agent 之间的通信路径。工程选型看的就是这个。1.1 一、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 模式的骨架from langgraph.graph import StateGraph, ENDfrom langgraph.prebuilt import create_react_agent# 三个专业 SubAgentresearcher 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 倍同时还能保持路由准确度。思路值得参考路由决策不一定非要用同款大模型。1.2 二、HandOff —— 把控制权交出去HandOff 和 SubAgents 的核心差异在控制权的归属。SubAgents 是调度——Supervisor 看着所有人干活。HandOff 是移交——一个时刻只有一个 Agent 活跃控制权整体切换。OpenAI Agents SDK 把 HandOff 作为一等公民设计。下面这段代码三个 Agent 通过 HandOff 互相转接没有中间层from openai import agentstriage_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 转圈用户干等。设置最大跳转次数和方向约束是工程上绕不开的。1.3 三、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 就够了辩论模式更多出现在需要验证推理质量的高风险场景——法律分析、医疗诊断、科学发现。1.4 四、自定义工作流 —— 把路径握在手里SubAgents、HandOff、Chat Group 定义了 Agent 之间怎么通信。自定义工作流定义的是 Agent 按什么顺序执行——管的是流程的拓扑。最基础的形态是 Pipeline。MetaGPT 把软件公司的 SOP 编码成了 prompt 序列产品经理 Agent 写 PRD → 架构师 Agent 出设计 → 工程师 Agent 写代码 → 测试 Agent 跑用例。每个阶段的输出是下个阶段的输入SOP 本身成了幻觉的约束——工程师写出来的代码必须匹配架构师的接口定义不一致时报错而不是继续往下走。LangGraph 的 StateGraph 是构建自定义工作流的主力工具。有向图 typed state channels 条件边 循环组合起来能表达任意拓扑# 一个条件路由的例子根据输入复杂度走不同路径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 互评分数动态决定谁留谁走。工业界还没大规模采用思路值得跟不是设计一个完美拓扑是让系统学会什么时候该用哪个拓扑。框架对四种模式的支持不同框架对四种模式的支持不全。选框架之前先对一下你需要的模式框架有没有原生支持。框架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 和自定义工作流可以自己搭不是原生支持。生产环境的几个教训下面的经验来自多个团队踩过的坑不是理论推演。从两个 Agent 开始。很多人一上来就画十个 Agent 的架构图研究 Agent、写作 Agent、审核 Agent、格式化 Agent、翻译 Agent、配图 Agent、SEO Agent、发布 Agent、通知 Agent、归档 Agent。实际上两个 Agent 就能验证核心流程跑不跑得通。每加一个 Agent状态空间翻倍调试难度涨得更快。Agent 之间的输入输出 Schema 得先定死。上游 Agent 产出什么结构、下游 Agent 期望什么结构这两个不匹配的时候整个流程静默出错。用 Pydantic 或类似方式把数据结构显式定义出来出错时有 trace不是一团黑。from pydantic import BaseModelclass ResearchOutput(BaseModel): topic: str key_findings: list[str] sources: list[dict] confidence: floatclass 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 的不信任是对自动化无法覆盖的边界的承认。收尾Multi Agent 解决的不是单 Agent 太弱是一个 Agent 不该干所有事。四种模式的选型逻辑SubAgents。任务能清晰分解成独立子任务有明确的协调者角色。生产环境的首选踩坑经验最多。HandOff。对话场景、客服分流、话题切换。控制权需要在 Agent 之间流转不是集中调度。Chat Group。需要多角度验证的推理任务。成本高建议只在单 Agent 置信度不足的高风险场景用。自定义工作流。业务流程已经明确需要把 SOP 固化成 Agent 的执行路径。LangGraph 的有向图 条件边是最灵活的选择。Gartner 预测到 2027 年 30% 的企业 AI 应用会采用多 Agent 架构。这个数字可能偏保守——2026 年上半年看到的案例数量已经远超这个比例。写多 Agent 系统之前先把两个 Agent 跑通。从两到十之间每一步加 Agent 的时候问自己这个 Agent 是让系统更快还是只是让架构图更好看。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】