Skip to main content

Multi-agent

心智模型​

多 Agent 系统的核心是在上下文管理、分布式开发和并行执行三个维度上，将复杂任务拆解给多个专业化组件协作完成。其设计中心是上下文工程——精确控制每个 Agent 能看到什么信息。五种主要模式（子代理、交接、技能、路由、自定义工作流）分别在不同场景下平衡性能与架构复杂度。

二级标题及内容​

  • 【目的】Why multi-agent? 并非所有复杂任务都需要多 Agent。引入多 Agent 通常是为了解决三个问题：上下文管理（避免单 Agent 上下文窗口过载）、分布式开发（允许不同团队独立维护能力）和并行化（同时执行子任务加速响应）。尤其适用于单个 Agent 工具过多导致决策困难、任务需要大量专业背景知识、或需要顺序约束解锁能力的场景。

  • 【模式】Patterns

    • 子代理 (Subagents)：主 Agent 作为协调器，将子代理当作工具调用。所有路由通过主 Agent，提供集中控制。
    • 交接 (Handoffs)：Agent 之间通过工具调用动态转移控制权，行为随状态变化而切换。
    • 技能 (Skills)：单 Agent 按需加载专业提示和知识，保持控制权不变。
    • 路由 (Router)：一个分类步骤将输入导向一个或多个专业代理，结果汇总合成后返回。
    • 自定义工作流 (Custom workflow)：用 LangGraph 构建定制执行流，混合确定性逻辑和代理行为。

  • 【模式选择】Choosing a pattern 通过分布式开发能力、并行化程度、多跳支持、直接用户交互四个维度对比各模式的适用性。可混合使用多种模式。

  • 【性能对比】Performance comparison 通过单次请求、重复请求、多领域请求三种场景，对比各模式在模型调用次数和Token 消耗上的差异：

    • 有状态模式（交接、技能）在重复请求中节省 40-50% 调用。
    • 并行模式（子代理、路由）在多领域请求中 Token 效率最高。
    • 技能模式调用次数最少但上下文持续累积，Token 消耗较高。

最佳实践​

  • 优先用单 Agent：除非确实遇到上下文过载、工具决策混乱、或需要独立开发/并行，否则不必引入多 Agent 复杂度。
  • 按场景选模式：简单聚焦任务优先技能；需并行或大上下文隔离优先子代理/路由；有状态连续交互优先交接。
  • 可混合搭配：子代理可调用自定义工作流，技能可按需加载，各模式可以组合使用。