多 Agent 协同：不是 Agent 越多越强，而是上下文分配得更合理

这是当前 LangChain 官方 multi-agent 文档里最值得先记住的一句话的意思：很多人说自己需要“multi-agent”，本质上是在追求下面几种能力之一：

• •更好的上下文管理
• •更清晰的职责边界
• •更高的并行度
• •更强的流程控制

但这并不自动意味着你必须真的拆成多个 agent。很多任务只要：

• •缩减工具数量
• •调整 prompt
• •做好动态上下文加载

一个 agent 就已经够用了。

所以多 Agent 设计的起点，不应该是“我要不要也做一个多 Agent 系统”，而应该是：

单 Agent 现在到底卡在上下文、职责、并行还是流程控制的哪个问题上？

只有先回答清楚这个问题，后面的模式选择才有意义。

官方文档把这个点讲得很直白：multi-agent design 的中心问题是 context engineering，也就是“每个 agent 应该看到什么”。

这比“每个 agent 叫什么角色”重要得多。

因为一旦上下文分配做不好，就会出现两个常见问题：

• •每个 agent 都看到太多信息，拆了和没拆差不多
• •每个 agent 看不到真正需要的信息，只能低质量猜测

所以多 Agent 不是先拆角色，而是先做信息边界设计。

更适合引入多 Agent 的情况通常有这些：

• •一个 agent 的工具太多，选择明显变差
• •任务由多个领域组成，单个上下文已经装不下
• •不同步骤天然可以并行
• •不同团队需要独立维护不同能力模块

如果只是一个普通问答助手或几个工具调用的工作流，先把单 Agent 做稳，几乎总是更划算。

LangChain 当前官方 multi-agent 文档给出的模式非常值得直接吸收，因为它们本质上是在回答不同的工程约束。

1. Subagents

一个主 agent 把其他 agent 当成工具来调用。所有路由都经过主 agent。

适合：

• •主控逻辑必须集中
• •需要强上下文隔离
• •需要并行调用多个子能力

代价是模型调用次数通常会更多，因为每次子任务结果都要回到主 agent 汇总。

2. Handoffs

控制权在不同 agent 之间切换。当前 agent 可以把对话直接交给另一个 agent。

适合：

• •任务在不同阶段由不同角色主导
• •子 agent 需要直接和用户继续交互
• •希望在重复请求时复用当前活跃 agent 的状态

3. Skills

仍然是单 Agent 主控，但会按需加载特定技能、提示词或知识块。

适合：

• •你主要想解决上下文过载，而不是必须拆成多个长期活跃角色
• •希望保留统一对话入口

很多团队以为自己要“多 Agent”，其实最后真正需要的只是 skills。

4. Router

先做一个路由步骤，把请求分配给一个或多个专门 agent，再综合结果。

适合：

• •输入类型差异明显
• •不同分支彼此独立
• •可以并行执行

5. Custom workflow

用 LangGraph 自己编排，把上述模式嵌到更复杂的流程里。

适合：

• •需要 deterministic + agentic 混合流程
• •需要审批、暂停、恢复、回放
• •需要对子流程做更细控制

这类场景已经不是“简单多 Agent”，而是完整工作流系统。

官方文档已经给了一个很好的判断思路，我这里把它翻成更接近工程语言的版本：

优先选 Subagents，当你需要

• •明确的中心调度者
• •强上下文隔离
• •子能力像工具一样被调用

优先选 Handoffs，当你需要

• •对话主导权切换
• •子 agent 直接面向用户
• •连续多轮任务里复用当前激活角色

优先选 Skills，当你需要

• •按需加载领域知识
• •维持单 Agent 体验
• •降低 token 成本和上下文噪音

优先选 Router，当你需要

• •显式分类后分发
• •并行跑多个专门分支
• •最后做统一综合

优先选 Custom workflow，当你需要

• •复杂控制流
• •多阶段状态迁移
• •人工审核和恢复

如果你要做“研究 -> 分析 -> 写作”的流程，第一反应不一定要上 3 个长期对话 agent。一个更稳的起点，是让主 agent 调用三个子 agent 作为工具。

def research_agent(task: str) -> str:
    """负责收集事实与资料。"""
    return "研究结果"


def analysis_agent(research: str) -> str:
    """负责提炼结论。"""
    return "分析结果"


def writing_agent(analysis: str) -> str:
    """负责组织输出。"""
    return "最终文稿"

这当然不是完整实现，但它体现了一个关键设计：

• •研究 agent 不需要看到写作风格约束
• •写作 agent 不需要看到全部搜索细节
• •主 agent 只拿每一步的结果做协调

这就是 context engineering 的直接收益。

如果你的多 Agent 系统开始出现下面这些需求，就说明高层模式可能不够了：

• •某些步骤失败要重试
• •某些阶段要插人工审核
• •某些子任务要并行再合并
• •任务可以暂停，稍后恢复
• •整条执行链需要可回放

这时更适合用 LangGraph 的 subgraphs 或 custom workflow，把 agent 模式嵌进图里，而不是继续依赖隐式控制流。

一个简单的图式思路可能像这样：

router
  -> research_subgraph
  -> analysis_subgraph
  -> review_subgraph
  -> synthesis
  -> END

官方 subgraphs 文档也明确提到，它适合：

• •构建 multi-agent systems
• •复用一组节点
• •让不同团队维护不同子图

1. 角色很多，边界很糊

把系统拆成 5 个 agent 听起来很高级，但如果它们都在读写同一堆上下文、做差不多的事，实际只是在增加协调成本。

2. 没有计算调用和 token 成本

官方 multi-agent 文档还专门比较了不同模式的调用数和 token 成本。这个提醒非常重要：模式不同，延迟和成本结构会差很多。

尤其是：

• •Subagents 通常控制力更强，但调用数可能更多
• •Skills 和 handoffs 在重复请求里更省调用
• •Router 适合并行，但也会引入额外路由开销

所以多 Agent 不是白来的能力，它几乎总是用更多复杂度换更强的边界控制。

3. 只拆角色，不拆上下文

如果每个 agent 仍然拿到几乎相同的信息，多 Agent 基本就失去意义了。

4. 过早框架化

任务还没验证清楚时，就开始设计一整套 supervisor、worker、message bus，最后很可能只是把一个本来简单的问题提前做复杂。

如果你现在正在考虑多 Agent，我会更建议按这个顺序来：

• •先把单 Agent 跑稳
• •找出单 Agent 真正的瓶颈是上下文、工具选择还是并行
• •先尝试 skills 或 router 这种较轻模式
• •只有在需要恢复、审批、并行合并时，再上 LangGraph custom workflow

这个顺序能帮你避免“为了多 Agent 而多 Agent”。

多 Agent 的价值从来不在“Agent 数量”，而在更合理的信息分配和职责边界：

• •用 subagents 做集中调度
• •用 handoffs 做对话主导权切换
• •用 skills 做按需上下文加载
• •用 router 做分类分发
• •用 custom workflow 做复杂编排

只要记住一点，设计通常就不会跑偏：多 Agent 的核心不是角色设定，而是 context engineering。

• •LangChain Multi-agent
• •LangGraph Subgraphs
• •LangGraph Overview