如果你用过 ChatGPT 或类似的 AI 工具你的体验大概率是这样的你问一个问题AI 给你一个答案。看起来像是一个 AI 从头做到尾。但在越来越多复杂任务和 Agent 产品中背后可能已经不是“一个人干活”而是一支分工明确的 AI 团队。你只说一句“帮我开发一个登录功能”系统可能让一个 Agent 分析需求一个 Agent 编写前端一个 Agent 处理后端还有一个 Agent 负责测试和审查。它们各自完成一部分工作再由系统把结果组合起来。这就是多 Agent 协作。问题也随之而来这些 Agent 是怎么配合的谁决定下一步做什么任务和上下文怎么传递做完以后结果又怎么汇总这篇文章不堆术语而是用最通俗的方式讲清楚四种常见的多 Agent 协作机制。01先打破一个幻觉在聊具体机制之前需要先纠正一个很容易产生的误解。你可能会脑补这样的画面Agent A 对 Agent B 说“帮我检查一下这段代码。”Agent B 回答“好的马上给你结果。”看起来就像两个 AI 在微信群里聊天。但真实的工程系统通常不是这样运行的。Agent 可能是一次独立的大模型调用、一个工作流节点也可能是一个部署在远端的 Agent 服务。它们通常不会像人一样自由聊天而是在编排系统的控制下传递结构化的任务、消息、状态、上下文和结果。例如主 Agent 判断需要代码审查后系统可能会创建一份明确的审查任务选择代码审查 Agent传入代码、审查范围和输出要求等待子 Agent 完成将结果写回主流程再由主 Agent 决定下一步。把子 Agent 包装成工具由主 Agent 通过 Tool Calling 调用是一种非常常见的实现方式但它不是多 Agent 协作的唯一形式。后面还会看到共享状态、控制权移交、消息发布订阅以及跨系统 Agent 协议等不同方案。核心认知多 Agent 协作通常不是 AI 彼此自由聊天而是由编排系统组织任务分发、上下文传递、状态更新和结果回传。02为什么需要多 Agent一个 Agent 不行吗先说结论不是所有任务都需要多 Agent。如果任务很简单一个 Agent 能够稳定完成就没有必要为了“看起来更先进”而拆成多个 Agent。多 Agent 会增加模型调用次数、响应延迟、运行成本和调试难度。它真正有价值的地方主要体现在下面几个方面。隔离上下文一个 Agent 同时负责调研、写作、编码、测试和审核随着上下文越来越长关键信息容易被大量历史内容稀释处理成本也会不断增加。把任务拆开后每个 Agent 可以拥有相对干净的上下文研究员只关注资料和事实写作者只关注结构和表达审核员只关注错误和风险。每个 Agent 不需要知道所有信息只需要拿到完成自己任务所需的部分。使用不同的能力和模型不同任务需要的能力并不相同。调研 Agent 可能需要联网检索代码 Agent 需要读取仓库和运行命令审核 Agent 需要更强的逻辑判断。系统还可以为不同任务选择不同模型在质量、速度和成本之间做取舍。控制工具和权限多 Agent 还能形成更清晰的权限边界。例如调研 Agent 只能搜索和读取资料代码审查 Agent 只能读代码不能修改发布 Agent 才拥有部署权限。相比把所有高风险工具都交给一个 Agent这种拆分更容易控制风险。并行处理可以拆分的任务如果几个任务之间没有强依赖就可以让多个 Agent 同时处理。例如让三个研究 Agent 分别调查市场、技术和竞品最后再统一汇总。相比一个 Agent 依次完成整体耗时可能更短。因此多 Agent 更适合以下任务可以清晰拆分成多个专业步骤需要隔离上下文或工具权限存在可并行执行的子任务需要不同模型或不同专业能力流程复杂需要反复判断、回退或恢复。03核心四种常见协作机制下面介绍四种容易理解、也经常出现在实际系统中的协作方式Subagent as Tool把子 Agent 当成工具调用Graph-State通过共享状态和图路由推进流程Handoff把当前对话和控制权移交给另一个 AgentPub-Sub通过消息发布和订阅驱动 Agent 工作。需要注意这不是行业唯一的标准分类也不是互斥的四选一。一个实际系统完全可以同时使用多种机制。例如外层用 Graph-State 控制整体流程其中一个节点通过 Tool Calling 调用多个子 Agent某个客服节点又可以通过 Handoff 把用户转交给退款专家。为了让四种方式更容易比较后面每一节都会回答四个问题谁决定下一步Agent 之间传递什么谁直接面向用户状态保存在哪里04机制一Subagent as Tool——把子 Agent 当成工具这是最直观、也最常见的多 Agent 组织方式。核心思想一句话主 Agent 保持控制权把专业子 Agent 注册成可以调用的工具。假设用户说“帮我写一篇关于多 Agent 的文章。”整个过程可能是这样的用户把任务交给主 Agent主 Agent 判断需要先做资料调研主 Agent 调用research\_agent并传入具体调研任务研究 Agent 在独立上下文中完成调研调研结果作为工具结果返回主 Agent主 Agent 再调用writer\_agent完成写作主 Agent 检查并整合结果最后回复用户。这里的关键是子 Agent 完成任务后结果会回到主 Agent用户仍然只和主 Agent 交互。生活类比是主管给不同专家派单。专家完成后把结果交还主管最终仍由主管对客户负责。OpenAI Agents SDK 中的“Agents as tools”就是一个直接的例子from agents import Agent research_agent Agent(nameResearch Agent,instructions负责资料调研并输出结构化事实摘要。,)writer_agent Agent(nameWriter Agent,instructions根据提供的资料写出通俗、准确的文章。,)manager_agent Agent(nameManager Agent,instructions分析用户任务按需调用专业 Agent并整合最终答案。,tools[research_agent.as_tool(tool_nameresearch_topic,tool_description需要检索和整理资料时使用。,),writer_agent.as_tool(tool_namewrite_article,tool_description已有资料需要生成文章时使用。,),],)四个关键问题谁决定下一步 主 Agent 的模型和运行时。传递什么 主 Agent 为子 Agent 生成的任务输入以及子 Agent 返回的结果。谁面向用户 主 Agent。状态在哪里 对话主状态通常由主 Agent 保存子 Agent 往往使用隔离的临时上下文。适用场景主流程清晰专业任务可以独立委派希望统一由一个 Agent 面向用户需要让不同团队维护不同专业 Agent希望通过上下文隔离减少主会话负担。优点概念简单容易实现主 Agent 统一控制结果容易汇总子 Agent 上下文相对独立子任务可以串行也可以按需并行。局限所有结果通常都要回到主 Agent主 Agent 容易成为中心瓶颈复杂流程中的循环、恢复和显式状态管理不够直观如果主 Agent 的任务描述不准确子 Agent 可能从一开始就拿错上下文。Tool Calling 并不是不能处理动态决策。主 Agent 完全可以根据当前结果动态选择下一个子 Agent。只是当流程出现大量分支、循环、持久化状态和失败恢复时显式的图结构通常更容易管理。05机制二Graph-State——所有节点围绕共享状态协作如果一个任务不是简单的“研究完再写作”而是需要来回判断、补充、审核和返工单纯依赖主 Agent 连续调用工具流程会越来越难看清。这时候可以使用 Graph-State 模式。它的核心思想是把工作流表示成一张图由节点执行工作由边决定下一步所有节点围绕一份结构化状态推进任务。可以把 State 理解为当前任务的“工作台快照”。里面可能保存用户原始需求已完成的调研结果当前文章草稿审核意见当前应该进入哪个步骤错误次数和重试次数。每个节点读取自己需要的字段完成工作后返回局部更新。共享状态并不意味着所有 Agent 必须看到全部信息系统可以通过状态结构和上下文组装只向不同节点提供必要内容。一个简化流程可能是用户消息进入 StateSupervisor 判断下一步先调研Researcher 将调研结果写入 StateSupervisor 再次读取 State判断资料是否充分如果不足继续补充调研如果充分路由到 WriterWriter 写入草稿后路由到 ReviewerReviewer 判断通过或退回修改直到流程结束。LangGraph 的核心抽象就是 State、Node 和 Edge。下面是用于解释结构的简化代码from typing import Literal, TypedDict from langgraph.graph import StateGraph, START, END class TeamState(TypedDict): messages: list[str]next: Literal[researcher, writer, FINISH] def supervisor_node(state: TeamState): # 根据当前状态判断下一步并返回局部状态更新... def researcher_node(state: TeamState): # 执行调研把结果写回 messages... def writer_node(state: TeamState): # 根据调研结果生成文章... def route(state: TeamState): return state[next] builder StateGraph(TeamState) builder.add_node(supervisor, supervisor_node) builder.add_node(researcher, researcher_node) builder.add_node(writer, writer_node) builder.add_edge(START, supervisor) builder.add_conditional_edges(supervisor,route,{researcher: researcher,writer: writer,FINISH: END,},) builder.add_edge(researcher, supervisor) builder.add_edge(writer, END) app builder.compile()这里使用next字段只是为了方便理解不是所有 Graph-State 系统都必须这样设计。路由也可以由固定边、条件函数、命令或其他状态字段决定。四个关键问题谁决定下一步 图运行时根据边、条件函数和当前 State 决定某些节点也可以通过更新状态参与决策。传递什么 结构化的 State 更新而不只是某个函数的返回字符串。谁面向用户 由图设计决定可以是固定节点也可以是当前活跃节点。状态在哪里 图状态由运行时管理需要时可以通过 Checkpoint 持久化和恢复。适用场景有复杂条件分支和循环需要审核、返工和重试任务可能被暂停后恢复需要清楚查看当前执行到哪一步需要将确定性工作流和 Agent 判断混合起来。优点流程结构显式复杂路由更容易表达适合循环、失败恢复、人工审批和长任务状态可以持久化便于追踪和调试可以将规则节点与 LLM 节点组合使用。局限状态结构和路由设计需要额外工程投入节点增多后调试状态更新和并发合并并不简单上下文传递不合理时仍然可能出现信息过多或信息缺失。06机制三Handoff——把对话控制权交给专家如果说 Subagent as Tool 像“主管找专家问一个问题”那么 Handoff 更像“客服把电话转接给专业部门”。它的核心思想是当前 Agent 不只是向另一个 Agent 获取一次结果而是把当前对话的处理权转交给它。举个例子。用户对客服总管说“为什么我的退款还没到账”Subagent as Tool 的做法客服总管调用退款专家“请查询这个订单的退款状态。”退款专家返回“退款正在银行处理中预计两个工作日到账。”客服总管拿到结果后继续和用户沟通。Handoff 的做法客服总管判断这是退款问题后直接将用户转交给退款 Agent。接下来由退款 Agent 面向用户继续询问订单号、解释状态并完成处理。从用户体验上看这是控制权移交从具体实现上看Handoff 仍然可能通过一个类似transfertorefund\_agent的工具触发。OpenAI Agents SDK 中可以这样配置from agents import Agent billing_agent Agent(nameBilling Agent,instructions负责处理账单和扣款问题。,) refund_agent Agent(nameRefund Agent,instructions负责处理退款申请和退款状态。,) triage_agent Agent(nameTriage Agent,instructions判断用户问题所属领域并在需要时转交给专业 Agent。, handoffs[billing_agent, refund_agent],)Handoff 时接收方通常能获得对话历史但并不代表必须原样传递所有内容。实际系统可以过滤、裁剪或总结上下文只把专业 Agent 需要的信息交给它。另外专家 Agent 完成任务后是否自动交还给原 Agent也取决于系统设计。它可以继续负责后续对话也可以通过新的 Handoff 转回客服总管。四个关键问题谁决定下一步 当前活跃 Agent 根据用户意图决定是否移交。传递什么 对话历史、当前状态和经过筛选的上下文。谁面向用户 当前接管控制权的 Agent。状态在哪里 通常保存在跨轮次的会话状态中并记录当前活跃 Agent。适用场景客服、咨询和多领域问答专家需要直接向用户追问信息不同阶段需要不同提示词、工具和权限对话会持续多轮不适合每次都回到统一主 Agent。优点更接近真实的专家转接体验专家 Agent 可以直接和用户沟通多轮对话中可以减少反复经过主 Agent 的开销不同 Agent 可以拥有不同的工具和行为规则。局限上下文交接设计更复杂需要明确谁当前拥有控制权如果来回转接过多用户体验和调试都会变差错误的 Handoff 可能让用户进入不合适的处理流程。07机制四Pub-Sub——通过消息发布和订阅协作前三种方式大多能看到一个比较明确的主流程或当前控制者。但在更大规模、更松耦合的系统里Agent 可能由不同团队开发运行在不同服务中并不适合由一个主 Agent 直接管理所有参与者。这时可以采用 Pub-Sub也就是消息发布/订阅模式。核心思想是Agent 不直接指定谁来处理而是向消息总线发布事件订阅了相关事件的 Agent 自动接收并执行。例如研究 Agent 完成资料收集发布ResearchCompleted写作 Agent 订阅这个事件收到后开始写作写作完成后发布DraftCreated审核 Agent 订阅草稿事件自动开始检查审核失败时发布RevisionRequested写作 Agent 再次被唤醒。生活类比是一个团队群但这里的重点不是“大家随意聊天”而是发送有明确类型和结构的事件。消息中可能包括{ event: DraftCreated, task_id: article-1024, artifact_url: ..., version: 3 }这个系统里不一定完全没有协调者但各 Agent 不需要直接知道彼此的地址和内部实现。它们只需要知道自己发布什么事件、订阅什么事件。四个关键问题谁决定下一步 消息类型、订阅关系和各 Agent 的消费逻辑共同决定。传递什么 事件、消息以及结果或文件的引用。谁面向用户 通常由独立的入口服务或响应 Agent 负责不一定是事件生产者。状态在哪里 分散在消息系统、任务存储和各 Agent 自己的状态中。适用场景大规模、松耦合的 Agent 网络多个团队独立开发和部署 Agent事件驱动的异步任务一个事件需要同时唤醒多个处理者长耗时任务和后台流水线。优点发布者和订阅者解耦容易扩展新的 Agent天然支持异步处理和一对多分发适合跨服务、跨团队协作。局限消息顺序、重复消费和失败重试处理复杂很难从单个调用链看清完整过程调试需要统一的事件追踪和任务标识分布式状态一致性和最终结果汇总难度较高。08延伸A2A 不是 Pub-Sub 的另一个名字讲到 Agent 间通信很容易看到另一个热门概念A2A也就是 Agent2Agent Protocol。需要特别强调A2A 不能直接等同于 Pub-Sub。Pub-Sub 是一种消息分发架构A2A 是独立 Agent 系统之间的互操作协议。它解决的问题是不同公司、不同框架、不同技术栈构建的 Agent如何发现彼此、委派任务、传递进度并交付结果。A2A 的核心角色和对象包括A2A Client代表用户发起任务的 Agent 或应用A2A Server提供能力的远程 AgentAgent Card描述 Agent 身份、能力、地址和认证方式的数字名片Message一次通信消息Task具有状态和生命周期的工作单元Artifact远程 Agent 最终交付的文档、图片或结构化数据等成果。A2A 可以采用请求响应、轮询、SSE 流式更新和异步推送通知等交互方式并不要求所有 Agent 连接到同一条消息总线。截至 2026 年 7 月A2A 已发布 1.0 规范提供多种官方 SDK并由 Linux Foundation 项目治理。它已经不只是一个研究概念但相较于普通的 Tool Calling 和单体工作流跨组织的工程落地仍处于生态建设阶段。A2A 和 MCP 有什么区别可以用一句话记住MCP 用来连接 Agent 与工具、数据源和外部系统A2A 用来连接相互独立的 Agent 系统。例如一个旅行 Agent 可以通过 MCP 查询航班和酒店工具再通过 A2A 把签证材料整理任务委派给另一个独立 Agent。09四种方式一张表总结机制谁决定下一步主要传递内容谁面向用户状态位置典型场景相对工程复杂度Subagent as Tool主 Agent任务参数、子 Agent 结果主 Agent主会话 隔离子上下文专业任务委派、统一汇总★★Graph-State图运行时、条件边和状态结构化 State 更新由图设计决定共享状态与 Checkpoint复杂分支、循环、恢复、审批★★★★Handoff当前活跃 Agent对话历史、当前状态、控制权接管后的 Agent跨轮次会话状态客服转接、多领域咨询★★★Pub-Sub事件和订阅关系事件、任务标识、结果引用独立入口或响应 Agent消息系统 分布式存储异步流水线、大规模松耦合网络★★★★★复杂度只是相对判断。一个最简单的消息队列可能比复杂的 LangGraph 容易而一个包含数十个工具和子 Agent 的 Tool-Call 系统也可能非常难维护。更重要的是这些方式可以组合使用而不是必须选择其中一种。10实战拆解CodeBuddy Code 如何用 Markdown 配置子 Agent讲完机制再来看一个真实产品中的实现方式。以CodeBuddy Code 支持通过 Markdown 文件配置专门的子 Agent。用户不需要手动实现一套复杂的 Agent 注册系统只要描述子 Agent 的名称、适用场景、工具权限和系统提示词就可以让主 Agent 按需委派任务。例如在项目的.codebuddy/agents/目录下创建---name: code-reviewerdescription: 代码审查专家。修改代码后主动检查质量、安全性和可维护性。tools: Read, Grep, Glob, Bashmodel: inherit---你是一名资深代码审查专家。请重点检查- 代码是否清晰、可维护- 是否存在安全漏洞- 错误处理是否完整- 是否需要补充测试。这段配置包含两部分YAML Frontmatter它描述这个子 Agent 是谁以及系统应该怎么使用它name子 Agent 的唯一名称description它适合处理什么任务也是自动委派的重要依据tools它能使用哪些工具model指定模型或者用inherit继承主会话模型。系统提示词正文分隔线后面的内容定义子 Agent 的角色、目标、工作步骤和输出要求。CodeBuddy Code 会读取这些配置并在任务与description匹配时将工作委派给相应的子 Agent。子 Agent 使用独立上下文完成任务再把结果返回给主 Agent。从使用者视角看这可以理解为一种声明式的 Subagent as Tool传统方式需要写代码注册 AgentCodeBuddy 把注册过程封装成 Markdown 配置用户只声明“它是谁、什么时候用、能做什么”具体的创建会话、加载工具和结果回传由产品运行时处理。这里需要注意我们能够从官方文档确认其配置形式、独立上下文和任务委派行为但没有必要进一步断言产品内部一定被转换成某一种特定的 Function Calling 实现。对普通读者来说理解它表现出的协作模式已经足够。11如果你是小白从哪里开始如果你看完以后想自己上手可以按照下面的路线逐步学习。第一步先体验工作流拆分可以先用低代码或可视化 Agent 平台搭一个“调研—写作—审核”的简单流程。这一阶段不用追求框架和代码重点是理解一个任务怎么拆成多个角色每个角色需要什么输入输出怎么传给下一步什么情况下需要返工。第二步尝试 Subagent as Tool用 OpenAI Agents SDK、LangChain 或其他支持子 Agent 的框架搭一个主 Agent 调用研究员和写作者的例子。这是最容易理解的多 Agent 起点。CrewAI 也适合用来体验“定义角色、任务和团队”的高层编排方式。它除了 Crew 之外还提供支持状态、路由和持久化的 Flow因此不要把整个 CrewAI 框架简单等同于一种 Tool-Call 实现。第三步学习 Graph-State当流程开始出现下面这些需求时可以学习 LangGraph根据结果动态分支调研不足时循环补充审核失败时退回修改中途暂停之后继续插入人工确认节点。理解 State、Node 和 Edge 后复杂工作流会变得更容易描述。第四步再理解 Handoff 和事件驱动如果你在做客服或多轮咨询重点研究 Handoff。如果你在做异步流水线、多个系统和多个团队之间的协作再研究 Pub-Sub、任务队列和事件追踪。第五步关注 MCP 和 A2A最后再去理解两个跨系统协议MCP 解决 Agent 如何连接工具和数据A2A 解决独立 Agent 如何发现、委派和协作。不一定马上用得上但它们能帮助你建立更完整的 Agent 系统视角。12写在最后多 Agent 不是为了让系统里出现更多“AI 角色”而是为了更合理地拆分任务、隔离上下文、控制权限和组织协作。Agent 之间所谓的“沟通”本质上也不是简单模仿人类聊天而是在回答四个工程问题谁决定下一步做什么任务和上下文怎么传过去状态保存在哪里结果由谁接收并继续处理Subagent as Tool 用中心化方式委派专业任务Graph-State 用共享状态和图控制复杂流程Handoff 把对话控制权交给更合适的专家Pub-Sub 用消息和事件连接松耦合的 Agent。而 A2A、MCP 这样的协议则进一步把协作范围从单个应用内部扩展到了不同工具和独立 Agent 系统之间。你不需要死记每一个框架的 API。只要抓住任务、上下文、状态、控制权和结果这几个核心对象再看任何多 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%免费】