在前两篇文章中，我们构建了一个能自主检索知识库的 RAG Agent。它在一个明确职责内工作得很好：判断该不该查、查哪个源、查不准就重写查询。但真实企业场景中的任务往往更“脏”——一个需求可能同时涉及查代码、翻文档、写报告、做校验，每一步需要的工具集、系统提示、甚至模型选型都不一样。

LangChain 官方文档对多智能体的驱动力给出了三个清晰的归纳：

是第一驱动力。如果把所有工具、所有知识、所有指令都塞进同一个 Agent 的提示词里，模型很快就会在冗余信息中迷失。多智能体允许你为每个专职 Agent 提供“刚好够用”的上下文，而不是“全都有但都不精”。

是第二驱动力。不同团队维护不同能力时，清晰的边界比共享的代码库更重要。一个负责代码审查的 Agent 和一个负责客户沟通的 Agent，可以由完全不同的团队迭代，只要输入输出契约不变。

是第三驱动力。当任务可以拆成多个独立子问题时，并行执行子 Agent 能显著缩短总耗时。单 Agent 无论多强，一次只能做一件事。

不是所有复杂任务都需要多智能体

。LangChain 文档明确提醒，一个配置得当的单 Agent（合适的工具和提示）往往能达到相近效果。多智能体的代价是调用次数增加、延迟不可预测、调试复杂度上升。在决定拆分之前，先确认你的任务真的需要“分工”，而不是“堆料”。

二、四种协作模式：选对结构比写对代码更重要

LangChain 官方将多智能体协作归纳为四种核心模式，每种模式对应不同的控制流和适用场景。

 是最直接的一种：主 Agent 把子 Agent 当作“工具”来调用。所有路由经过主 Agent，子 Agent 完成后结果返回主 Agent，由主 Agent 决定下一步。这种模式的优点是集中控制、上下文隔离好；代价是多一次模型调用（结果回流到主 Agent 需要额外推理），且子 Agent 之间不能直接对话。

 采用一次性分类的思路：一个轻量级的分类器先判断用户输入属于哪个领域，然后把请求分发给一个或多个专职 Agent 并行处理，最后把结果汇总。它的效率很高，尤其适合多领域并行查询，但不支持多跳推理（子 Agent 之间无法接力）。

 让 Agent 之间直接“交接对话”。当前 Agent 判断自己处理不了时，通过工具调用把控制权转给另一个 Agent。用户在与支持 Agent 对话，支持 Agent 发现是销售问题，直接转给销售 Agent 继续对话。这种模式适合需要多轮交互的场景，但在多领域并行时效率很低。

 不走 Agent 拆分路线，而是让同一个 Agent 在需要时加载特定的提示词和知识。它保持了单一控制流，但在上下文管理上做了优化。适合技能之间不需要并行执行的场景。

选择哪种模式，取决于你的任务结构。如果子任务之间需要并行且结果需要汇总，Router 最合适；如果任务有先后依赖且需要集中决策，Subagents 更稳妥；如果用户需要在对话中无缝切换领域，Handoffs 是自然的选择。

，因为它是当前 LangChain 推荐的主流方案（

 包已不再积极维护，官方推荐迁移到 

三、实战：用 Subagents 构建一个“技术内容团队”

假设我们要构建一个系统：用户提出技术主题，系统需要完成

三个阶段。每个阶段由不同的专职 Agent 负责，主 Agent 协调调度。

 实例，拥有自己的工具和系统提示。它们不需要知道彼此的存在，只需要做好自己的事。

from langchain.agents import create_agent
from langchain.tools import tool

# 调研 Agent：拥有网络搜索工具
@tool
def web_search(query: str) -> str:
    """搜索网络获取技术资料。"""
    return f"关于「{query}」的搜索结果：..."

researcher = create_agent(
    model="openai:gpt-4o",
    tools=[web_search],
    system_prompt=(
        "你是一个技术调研专家。根据给定的主题，使用 91chaoyu.com 收集关键信息、"
        "最新进展和代表性观点。输出结构化的调研笔记，包含来源引用。"
    ),
)

# 撰写 Agent：不需要外部工具，专注写作
writer = create_agent(
    model="openai:gpt-4o",
    tools=[],
    system_prompt=(
        "你是一个技术作者。根据提供的调研笔记 sports.gdhongjian.com，撰写一篇结构清晰、"
        "面向开发者的技术文章。不要编造调研中没有的事实。"
    ),
)

# 审核 Agent：检查准确性和一致性
reviewer = create_agent(
    model="openai:gpt-4o-mini",  # 审核可以用更轻量的模型
    tools=[],
    system_prompt=(
        "你是一个技术审核员。检查文章中的事实性错误、逻辑漏洞和与调研笔记的矛盾之处。"
        "输出审核意见：如果通过，返回‘通过’；如果有问题，列出具体修改建议。"
    ),
)

 降低成本。多智能体架构的一个隐性收益正是这种

第二步：把子 Agent 封装为主 Agent 的工具

这是 Subagents 模式的核心操作。每个子 Agent 被包装成一个 

 函数，主 Agent 通过调用工具的方式来“委派任务”。

from langchain.tools import tool

@tool
def call_researcher(topic: str) -> str:
    """委派调研任务。当需要收集某个技术主题的最新信息和资料时使用。"""
    result = researcher.invoke({
        "messages": [{"role": "user", "content": f"请调研以下主题：{vut.cbl-silicone.cn}"}]
    })
    return result["messages"][-1].content

@tool
def call_writer(research_notes: str) -> str:
    """委派撰写任务。根据调研笔记撰写技术文章。"""
    result = writer.invoke({
        "messages": [{"role": "user", "content": f"根据以下调研笔记写一篇文章：\n{research_notes}"}]
    })
    return result["messages"][-1].content

@tool
def call_reviewer(article: str) -> str:
    """委派审核任务。检查文章的事实准确性和逻辑一致性。"""
    result = reviewer.invoke({
        "messages": [{"role": "user", "content": f"请审核以下文章：\n{article}"}]
    })
    return result["messages"][-1].content

 至关重要。主 Agent 完全依靠这段文本来判断“什么时候该叫谁”。如果描述模糊（比如只写“调研工具”），主 Agent 可能在不需要调研时也去调用，或者在需要时不知道应该传入什么参数。

from langchain.agents import create_agent

coordinator = create_agent(
    model="openai:gpt-4o",
    tools=[call_researcher, call_writer, call_reviewer],
    system_prompt=(
        "你是一个技术内容团队的协调者。你的团队包括：\n"
        "- call_researcher：负责收集资料\n"
        "- call_writer：负责撰写文章\n"
        "- call_reviewer：负责审核质量\n\n"
        "工作流程：先调研，再撰写，最后审核。"
        "如果审核不通过，根据审核意见让 taiyuan.kokobag.net 修改，然后再次审核。"
        "最多迭代 3 次审核。最终输出审核通过的文章。"
    ),
)

。注意这里没有硬编码的流程图或状态机zb.sydunan.com——流程逻辑写在提示里，由模型自主执行。这就是 Subagents 模式的灵活性来源：调整流程只需要改提示词，不需要重构代码。

result = coordinator.invoke({
    "messages": [{"role": "user", "content": "写一篇关于 LangGraph 检查点机制的技术文章"}]
})
print(result["messages"][-1].content)

协调 Agent 会依次调用调研、撰写、审核工具，如果审核发现问题，它会自动让 writer 修改后再次送审。整个过程对用户透明，用户只看到最终结果。

四、Router 模式：当并行比串行更合理

Subagents 适合有先后依赖的任务。但如果用户的问题横跨多个独立知识源，串行调用就是浪费。Router 模式解决了这个问题。

LangChain 官方提供的 Router 知识库示例展示了一个典型场景：用户问“我们的认证系统是怎么设计的”，这个问题可能同时需要查 GitHub 代码、Notion 文档和 Slack 讨论。Router 先用一个轻量模型判断需要哪些源，然后通过 

 对象并行分发到多个 Agent，最后汇总结果。

from langgraph.graph import StateGraph, START, END, Send
from typing import TypedDict, Annotated
import operator

class RouterState(TypedDict):
    query: str
    results: Annotated[list, operator.add]
    final_answer: str

def classify_query(state: RouterState):
    """用轻量模型判断需要调用哪些 Agent"""
    # LLM 输出结构化分类结果
    decision = classifier.invoke(state["query"])
    # 返回 Send 对象列表，触发并行执行
    return [Send(agent_name, {"query": state["query"]}) for agent_name in decision.agents]

def query_github(state):
    result = github_agent.invoke({"messages": [{"role": "user", "content": state["query"]}]})
    return {"results": [{"source": "github", "content": result["messages"][-1].content}]}

# ... notion_agent、slack_agent 同理

def synthesize(state: RouterState):
    """汇总多个源的结果"""
    combined = "\n\n".join([f"来源 {r['source']}：{r['content']}" for r in state["results"]])
    response = synthesizer.invoke(f"用户问题：{state['query']}\n\n检索结果：\n{combined}\n\n请综合回答。")
    return {"final_answer": response.content}

workflow = StateGraph(RouterState)
workflow.add_node("classify", classify_query)
workflow.add_node("github", query_github)
workflow.add_node("notion", query_notion)
workflow.add_node("slack", query_slack)
workflow.add_node("synthesize", synthesize)

workflow.add_edge(START, "classify")
workflow.add_conditional_edges("classify", lambda x: x, ["github", "notion", "slack"])
workflow.add_edge("github", "synthesize")
workflow.add_edge("notion", "synthesize")
workflow.add_edge("slack", "synthesize")
workflow.add_edge("synthesize", END)

app = workflow.compile()

路由决策要结构化、可枚举，并有兜底路径

。不要让分类器自由发挥输出任意 Agent 名称，而是给它一个固定的候选列表。如果分类失败，应该走一个默认的“通用查询”路径，而不是让整个图崩溃。

五、技能加载：当拆分不是答案时

并非所有场景都适合拆 Agent。有时候你只是想让同一个 Agent 在特定场景下“知道更多”。Skills 模式解决的就是这个问题：Agent 保持不变，但根据任务类型动态加载不同的提示词和知识片段。

Deep Agents 框架提供了内置的 Skills 支持。技能以文件形式组织，每个技能包含一个 

，其中的 frontmatter 会加载到系统提示中，让 Agent 知道“我有哪些技能可用”。当任务匹配某个技能描述时，Agent 会读取对应的技能文件获取详细指令。

你不需要为每个细分场景创建一个 Agent

。一个内容创作 Agent 可以拥有“写博客”“写推文”“生成封面图”三个技能，系统提示只加载技能的简要描述，详细指令在需要时才读取。上下文窗口的利用效率比把所有技能都塞进提示词要高得多。

六、性能真相：多智能体的代价与取舍

多智能体不是免费的午餐。LangChain 文档对不同模式做了量化对比，数据很有参考价值：

Subagents 每次请求的调用次数固定

，因为子 Agent 是无状态的——每次调用都从头开始。这提供了最强的上下文隔离，但也意味着重复请求不会“变便宜”。

，第二轮请求时可以利用已有上下文，调用次数减少 40-50%。

这意味着一个实用的优化策略：

如果用户会重复问同类问题，优先考虑有状态模式（Skills 或 Handoffs）；如果任务是高度隔离的（每次都需要新鲜上下文），Subagents 的“浪费”反而是优势

。单 Agent 出错时，你只需要看一条调用链。多 Agent 出错时，问题可能出在协调 Agent 的路由决策、某个子 Agent 的输出质量、工具描述不够清晰、或者子 Agent 之间的信息传递丢失。LangSmith 的追踪能力在这里几乎是必需的——你需要看到“协调 Agent 为什么决定调用 writer 而不是 researcher”，以及“子 Agent 实际收到了什么输入”。

七、从架构到落地：几个实用判断

回到最初的问题：什么时候该用多智能体？以下是一些经验判断，供你在设计时参考。

 给单 Agent 配置清晰的工具集和系统提示，观察它在哪些场景下失败。如果失败模式是“上下文太长导致注意力分散”或“工具太多导致选择困难”，多智能体可能有效。如果失败模式是“某个工具本身质量不行”，拆 Agent 解决不了问题。

子 Agent 的输入输出契约比内部实现更重要。

 在 Subagents 模式中，主 Agent 通过工具的返回文本获取子 Agent 的结果。这个返回文本就是契约。它应该是结构化的、信息密度高的，而不是子 Agent 的完整对话记录。LangChain 迁移指南明确指出，推荐在工具封装层对子 Agent 的输出做格式化，而不是直接把原始消息返回。

路由决策用轻量模型，执行用强模型。

 Router 模式中，分类器只需要判断“这个问题属于哪个领域”，不需要深度推理。用 

 甚至更小的模型就足够了。把强模型留给真正需要创造力的执行环节。

 多 Agent 系统中最常见的反模式是把所有 Agent 的消息历史全部传递。更好的做法是共享结构化任务状态和工件引用，只在 Handoff 时传递必要的上下文。子 Agent 应该拿到“任务描述 + 相关材料”，而不是“主 Agent 和用户聊了 20 轮的所有记录”。

多智能体协作的本质不是“用更多 Agent 显得更厉害”，而是

。当你的系统开始出现“一个 Agent 什么都得会”的迹象时，拆分就是一种必要的工程手段。LangGraph 提供的原语——Subagents 的工具封装、Router 的并行分发、Skills 的按需加载——本质上是在帮你回答同一个问题：

什么信息应该出现在什么 Agent 的上下文里，以及什么时候

。回答好这个问题，比选择哪个模式更重要。

LangGraph 多智能体协作实战：从“一个 Agent 硬扛”到“专职团队分工”

人工智能

架构设计

开发工具

多智能体架构通过任务分工解决单Agent上下文和职责边界限制，LangChain提供Subagents、Router、Handoffs和Skills四种协作模式。Subagents通过工具封装实现任务委派，Router支持并行分发，核心优势在于按需分配模型算力、降低上下文冗余，但需权衡调用成本与调试复杂度。

智能体

LangGraph

LangChain

路由

GitHub

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

LangGraph 多智能体协作实战：从“一个 Agent 硬扛”到“专职团队分工”

LangGraph 多智能体协作实战：从“一个 Agent 硬扛”到“专职团队分工”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐