核心内容摘要
差差差不多30分钟
0 前言Agent是一个使用大语言模型决定应用程序控制流的系统。
随着这些系统的开发它们随时间推移变得复杂使管理和扩展更困难。
如你可能会遇到Agent拥有太多的工具可供使用对接下来应该调用哪个工具做出糟糕决策上下文过于复杂以至于单个Agent无法跟踪系统中需要多个专业领域例如规划者、研究员、数学专家等。
为解决这些问题你可能考虑将应用程序拆分成多个更小、独立的代理并将它们组合成一个多Agent系统。
这些独立的Agent可以简单到一个提示和一个LLM调用或者复杂到像一个ReActAgent甚至更多。
1 多Agent系统的好处模块化独立的Agent使得开发、测试和维护Agent系统更加容易。
专业化你可以创建专注于特定领域的专家Agent这有助于提高整个系统的性能。
控制你可以明确控制Agent之间的通信而不是依赖于函数调用。
2 多Agent架构多Agent系统中有几种方式连接Agent网络每个Agent都可与其他Agent通信。
任何Agent都可以决定接下来调用哪个其他Agent监督者每个Agent与一个监督者Agent通信。
监督者Agent决定接下来应该调用哪个Agent。
监督者工具调用这是监督者架构的一个特殊情况。
个别Agent可以被表示为工具。
在这种情况下监督者Agent使用一个工具调用LLM来决定调用哪个Agent工具以及传递哪些参数给这些Agent。
层次结构你可以定义一个有监督者的多Agent系统。
这是监督者架构的概括并允许更复杂的控制流。
自定义多Agent工作流每个Agent只与Agent子集中的其他Agent通信。
流程的部分是确定性的只有一些Agent可以决定接下来调用哪个其他Agent。
网络这种架构中Agent被定义为图节点。
每个Agent都可以与每个其他Agent通信多对多连接并且可以决定接下来调用哪个Agent。
虽然非常灵活但随着Agent数量的增加这种架构扩展性并不好很难强制执行接下来应该调用哪个Agent很难确定应该在Agent之间传递多少信息建议生产避免使用这架构而是使用以下架构之一。
监督者这种架构中定义Agent为节点并添加一个监督者节点LLM它决定接下来应该调用哪个Agent节点。
使用条件边根据监督者的决策将执行路由到适当的Agent节点。
这种架构也适用于并行运行多个Agent或使用map-reduce模式。
from typing import Literal from langchain_openai import ChatOpenAI from langgraph.graph import StateGraph, MessagesState, START model ChatOpenAI() class AgentState(MessagesState): next: Literal[agent_1, agent_2] def supervisor(state: AgentState): response model.invoke(...) return {next: response[next_agent]} def agent_1(state: AgentState): response model.invoke(...) return {messages: [response]} def agent_2(state: AgentState): response model.invoke(...) return {messages: [response]} builder StateGraph(AgentState) builder.add_node(supervisor) builder.add_node(agent_
builder.add_node(agent_
builder.add_edge(START, supervisor) # 根据监督者的决策路由到Agent之一或退出 builder.add_conditional_edges(supervisor, lambda state: state[next]) builder.add_edge(agent_1, supervisor) builder.add_edge(agent_2, supervisor) supervisor builder.compile()教程以获取有关监督者多Agent架构的示例。
监督者工具调用在这种监督者架构的变体中我们定义个别Agent为工具并在监督者节点中使用一个工具调用LLM。
这可以作为一个ReAct风格的Agent实现有两个节点——一个LLM节点监督者和一个执行工具在这种情况下是Agent的工具调用节点。
from typing import Annotated from langchain_openai import ChatOpenAI from langgraph.prebuilt import InjectedState, create_react_agent model ChatOpenAI() def agent_1(state: Annotated[dict, InjectedState]): tool_message ... return {messages: [tool_message]} def agent_2(state: Annotated[dict, InjectedState]): tool_message ... return {messages: [tool_message]} tools [agent_1, agent_2] supervisor create_react_agent(model, tools)自定义多Agent工作流在这种架构中我们添加个别Agent作为图节点并提前定义Agent被调用的顺序以自定义工作流。
在LangGraph中工作流可以以两种方式定义显式控制流普通边LangGraph允许你通过普通图边显式定义应用程序的控制流即Agent通信的顺序。
这是上述架构中最确定性的变体——我们总是提前知道接下来将调用哪个Agent。
动态控制流条件边在LangGraph中你可以允许LLM决定应用程序控制流的部分。
这可以通过使用条件边实现。
一个特殊情况是监督者工具调用架构。
在这种情况下驱动监督者Agent的工具调用LLM将决定工具Agent被调用的顺序。
from langchain_openai import ChatOpenAI from langgraph.graph import StateGraph, MessagesState, START model ChatOpenAI() def agent_1(state: MessagesState): response model.invoke(...) return {messages: [response]} def agent_2(state: MessagesState): response model.invoke(...) return {messages: [response]} builder StateGraph(MessagesState) builder.add_node(agent_
builder.add_node(agent_
# 明确定义流程 builder.add_edge(START, agent_
builder.add_edge(agent_1, agent_
3 Agent之间通信构建多Agent系统时最重要的事情是弄清楚Agent如何通信。
有几个不同的考虑因素Agent是通过图状态或工具调用进行通信的吗如果两个Agent有不同的状态模式怎么办如何通过共享消息列表进行通信
1 图状态与工具调用Agent之间传递的“有效载荷”是什么在上述讨论的大多数架构中Agent通过图状态进行通信。
在监督者带工具调用的情况下有效载荷是工具调用参数。
图状态要通过图状态进行通信各个Agent需要被定义为图节点。
这些可以作为函数或整个子图添加。
在图执行的每一步中Agent节点接收当前的图状态执行Agent代码然后将更新的状态传递给下一个节点。
通常Agent节点共享一个单一的状态模式。
然而你可能想要设计具有不同状态模式的Agent节点。
2 不同的状态模式一个Agent可能需要与其余Agent有不同的状态模式。
例如搜索Agent可能只需要跟踪查询和检索到的文档。
在LangGraph中有两种方法可以实现这一点定义具有单独状态模式的子图Agent。
如果子图和父图之间没有共享状态键通道则需要添加输入/输出转换以便父图知道如何与子图通信。
定义具有私有输入状态模式的Agent节点函数该模式与整个图的状态模式不同。
这允许传递仅需要用于执行该特定Agent的信息。
3 共享消息列表Agent之间通信的最常见方式是通过共享状态通道通常是消息列表。
这假设状态中至少有一个通道键由Agent共享。
当通过共享消息列表通信时还有一个额外的考虑因素Agent是共享完整的历史记录还是仅共享最终结果共享完整历史记录Agent可以共享他们的思维过程的完整历史记录即“草稿垫”与其他所有Agent。
这种“草稿垫”通常看起来像一个消息列表。
共享完整思维过程的好处是它可能有助于其他Agent做出更好的决策提高整个系统的整体推理能力。
缺点是随着Agent数量和复杂性的增长“草稿垫”将迅速增长可能需要额外的策略进行内存管理。
共享最终结果Agent可以拥有自己的私有“草稿垫”并且只与其余Agent共享最终结果。
这种方法可能更适合拥有许多Agent或更复杂的Agent的系统。
在这种情况下你需要定义具有不同状态模式的Agent。
对于作为工具调用的Agent监督者根据工具模式确定输入。
此外LangGraph允许在运行时传递状态给单个工具以便从属Agent在需要时可以访问父状态。
想入门 AI 大模型却找不到清晰方向备考大厂 AI 岗还在四处搜集零散资料别再浪费时间啦2026 年AI 大模型全套学习资料已整理完毕从学习路线到面试真题从工具教程到行业报告一站式覆盖你的所有需求现在全部免费分享扫码免费领取全部内容
学习必备100本大模型电子书26 份行业报告 600 套技术PPT帮你看透 AI 趋势想了解大模型的行业动态、商业落地案例大模型电子书这份资料帮你站在 “行业高度” 学 AI
100本大模型方向电子书
26 份行业研究报告覆盖多领域实践与趋势报告包含阿里、DeepSeek 等权威机构发布的核心内容涵盖职业趋势《AI 职业趋势报告》《中国 AI 人才粮仓模型解析》商业落地《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》领域细分《AGI 在金融领域的应用报告》《AI GC
实践案例集》行业监测《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。
600套技术大会 PPT听行业大咖讲实战PPT 整理自
年热门技术大会包含百度、腾讯、字节等企业的一线实践安全方向《端侧大模型的安全建设》《大模型驱动安全升级腾讯代码安全实践》产品与创新《大模型产品如何创新与创收》《AI 时代的新范式构建 AI 产品》多模态与 Agent《Step-Video 开源模型视频生成进展》《Agentic RAG 的现在与未来》工程落地《从原型到生产AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。
求职必看大厂 AI 岗面试 “弹药库”300 真题 107 道面经直接抱走想冲字节、腾讯、阿里、蔚来等大厂 AI 岗这份面试资料帮你提前 “押题”拒绝临场慌
107 道大厂面经覆盖 Prompt、RAG、大模型应用工程师等热门岗位面经整理自
年真实面试场景包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题每道题都附带思路解析
102 道 AI 大模型真题直击大模型核心考点针对大模型专属考题从概念到实践全面覆盖帮你理清底层逻辑
97 道 LLMs 真题聚焦大型语言模型高频问题专门拆解 LLMs 的核心痛点与解决方案比如让很多人头疼的 “复读机问题”
路线必明 AI 大模型学习路线图1 张图理清核心内容刚接触 AI 大模型不知道该从哪学起这份「AI大模型 学习路线图」直接帮你划重点不用再盲目摸索路线图涵盖 5 大核心板块从基础到进阶层层递进一步步带你从入门到进阶从理论到实战。
L1阶段:启航篇丨极速破界AI新时代L1阶段了解大模型的基础知识以及大模型在各个行业的应用和分析学习理解大模型的核心原理、
关键技术以及大模型应用场景。
L2阶段攻坚篇丨RAG开发实战工坊L2阶段AI大模型RAG应用开发工程主要学习RAG检索增强生成包括Naive RAG、Advanced-RAG以及RAG性能评估还有GraphRAG在内的多个RAG热门项目的分析。
L3阶段跃迁篇丨Agent智能体架构设计L3阶段大模型Agent应用架构进阶实现主要学习LangChain、 LIamaIndex框架也会学习到AutoGPT、 MetaGPT等多Agent系统打造Agent智能体。
L4阶段精进篇丨模型微调与私有化部署L4阶段大模型的微调和私有化部署更加深入的探讨Transformer架构学习大模型的微调技术利用DeepSpeed、Lamam Factory等工具快速进行模型微调并通过Ollama、vLLM等推理部署框架实现模型的快速部署。
L5阶段专题集丨特训篇 【录播课】