Multi-Agent 架构

这一节解决什么问题

单 Agent 在复杂场景下会遇到三个核心问题：上下文过长（所有信息塞进一个 Prompt）、职责不清（一个 Agent 做太多不同类型的事）、难以调试（出了问题不知道是哪一步出错）。

Multi-Agent 通过职责分离解决这些问题——把一个复杂的任务拆分给多个专门的 Agent，每个 Agent 只负责自己的领域，通过调度机制协作完成任务。

本节会系统讲解 Multi-Agent 的核心概念、常见协作模式、关键设计问题和工程化要点。

核心概念

Multi-Agent 是什么

Multi-Agent 是由多个独立的 Agent 组成的系统，每个 Agent 有自己的角色定义、工具集和职责边界。它们通过共享状态和调度机制协作完成复杂任务。

关键点：Multi-Agent 不是"多个角色的 Prompt 拼在一起"，而是需要明确的职责划分、状态共享机制、调度策略和结果整合方式。

为什么需要拆分 Agent

拆分 Agent 的核心原因：

• 职责清晰：每个 Agent 只做一类任务，Prompt 更聚焦、工具更精简、输出更可靠
• 上下文管理：不同 Agent 关注不同的上下文，避免单个 Prompt 塞入过多无关信息
• 独立优化：每个 Agent 可以独立调优（Prompt、工具、模型），互不影响
• 可测试性：单个 Agent 的行为更容易测试和验证

常见协作模式

Supervisor 模式

由一个 Supervisor Agent 负责理解用户意图、分解任务、调度其他 Agent 执行、整合结果。

用户请求 → Supervisor → (数据分析) → Data Analyst
                      → (工具调用) → Tool Executor
                      → (风险审查) → Risk Reviewer
                      → 结果整合 → 输出

Supervisor 是整个系统的"大脑"，它知道有哪些 Agent 可用、每个 Agent 擅长什么、当前任务需要哪些步骤。

Planner-Executor 模式

先由 Planner 生成完整计划，再由 Executor 按计划逐步执行。

用户请求 → Planner → 生成计划（步骤列表）→ Executor 逐步执行 → 输出

这种模式适合任务步骤比较明确的场景。计划可以被审查和修改后再执行。

Reviewer 模式

在执行链路中加入 Reviewer 节点，对 Agent 的输出进行质量检查或风险审查。

Agent 执行 → Reviewer → (通过) → 继续
                      → (不通过) → 返回 Agent 重新执行

Reviewer 可以是规则检查、模型判断或人工审核。

多 Agent 的核心问题

协调成本

Agent 之间的通信和协调会引入额外的延迟和 token 消耗。每多一个 Agent，系统的复杂度就增加一层。需要权衡拆分的收益和协调的成本。

状态共享

Agent 之间需要共享上下文（如用户输入、工具结果、中间推理），但不能互相覆盖。需要设计明确的状态读写规则。

重复执行

如果调度不当，多个 Agent 可能重复执行相同的操作。需要有机制避免重复（如标记已完成的步骤、设置执行锁）。

责任边界

当任务失败时，需要能定位是哪个 Agent 的问题。这要求每个 Agent 的输入输出都有明确的记录（Trace）。

为什么重要

Multi-Agent 是处理复杂业务场景的必要架构。

首先，复杂任务需要分工。一个涉及数据分析、工具调用、风险审查的任务，很难用单个 Agent 高效完成。拆分后每个 Agent 的 Prompt 更聚焦，工具更精简，输出质量更高。

其次，不同环节需要不同的模型策略。数据分析可能需要强推理模型，工具调用可能需要快模型，风险审查可能需要保守策略。Multi-Agent 允许为不同环节选择不同的模型和参数。

再次，可维护性。单个 Agent 的 Prompt 膨胀到一定程度就难以维护。拆分后每个 Agent 的 Prompt 相对简短，更容易理解和优化。

最后，可扩展性。新增能力只需要新增一个 Agent 并注册到调度系统中，不需要修改现有 Agent。

工程化理解

从工程角度看，Multi-Agent 系统的核心不是"写多个 Prompt"，而是设计调度机制和共享状态。

调度机制：需要决定谁先执行、谁后执行、失败了怎么办。调度可以是 Supervisor 驱动的（动态决定），也可以是预定义的流程（状态机控制）。Supervisor 模式灵活但成本高，状态机模式可控但不够灵活。

共享状态：所有 Agent 需要读写同一个状态对象。状态设计要考虑：哪些信息全局共享、哪些信息仅特定 Agent 可见、如何避免写冲突。一般的做法是用一个结构化的状态对象，每个 Agent 只写入自己负责的字段。

工具隔离：不同 Agent 应该有不同的工具集。数据分析 Agent 不应该有发送邮件的权限，工具调用 Agent 不应该有数据分析的权限。工具隔离是安全性的重要保障。

结果整合：多个 Agent 的输出需要合并成一个连贯的结果。整合方式可以是简单拼接、优先级选择或由 Supervisor 生成最终回复。

Trace 与调试：每个 Agent 的执行都需要独立记录 Trace，包括输入、关键决策摘要、工具调用、输出。出了问题需要能定位到具体是哪个 Agent 的哪个步骤出错。

常见误区

误区一：多 Agent 就是多个角色的 Prompt

多 Agent 不是把"你是数据分析专家""你是工具调用专家"这样的 System Prompt 拼在一起。每个 Agent 需要有独立的工具集、独立的上下文管理、独立的执行记录。

误区二：Agent 越多越好

每多一个 Agent，协调成本就增加一层。不必要的拆分只会增加延迟和复杂度。只有当单 Agent 确实无法胜任时才需要拆分。

误区三：Supervisor 能解决所有问题

Supervisor 本身也是一个 Agent，它的推理能力有限。如果任务分解逻辑太复杂，Supervisor 可能会做出错误的调度决策。复杂场景下可能需要预定义的流程（状态机）来辅助。

误区四：忽略状态共享设计

多 Agent 之间如果没有明确的状态共享规则，很容易出现信息丢失、状态冲突或上下文膨胀。需要在系统设计阶段就定义好状态结构和读写规则。

误区五：不需要 Trace

多 Agent 系统的调试难度远高于单 Agent。没有 Trace，出了问题根本不知道是哪个 Agent 的哪个步骤出错。Trace 是 Multi-Agent 系统的必备基础设施。

和项目的关系

Multi-Agent 是复杂 Agent 系统的核心架构模式。后续在项目 B 中会用到这一能力，但当前阶段只做知识准备，不展开具体项目实现。

理解 Multi-Agent 的协作模式（Supervisor、Planner-Executor、Reviewer）和核心问题（协调成本、状态共享、责任边界），是设计多 Agent 系统的基础。

面试表达

可以这样表达：

> 多 Agent 不是把多个 Prompt 拼在一起。我的理解是，多 Agent 需要明确的职责拆分、状态共享机制、调度策略和结果整合方式。我采用 Supervisor 模式，让 Supervisor 负责理解意图和调度任务，每个执行 Agent 只负责自己的领域。这样做的好处是职责清晰、每个 Agent 的 Prompt 更聚焦、输出更可靠。但多 Agent 也有代价——协调成本增加、状态管理变复杂、调试难度上升。所以需要 Trace 机制来记录每个 Agent 的执行过程，方便定位问题。

相关链接

• 相关工程化笔记：Agent Trace 执行轨迹
• 相关面试题库：Agent 面试题