如何设计一个多 Agent 系统：从架构设计、任务编排到生产环境落地

多 Agent 系统（Multi-Agent System）的核心并不是让多个大模型同时工作，而是通过合理的角色分工、任务编排、上下文管理和执行控制，让多个具备不同能力的 Agent 协作完成复杂任务。

一、为什么需要多 Agent 系统？

随着大语言模型能力不断增强，Agent 已经从简单的对话问答发展为能够自主规划任务、调用工具、执行操作的智能系统。

一个典型的 Agent 通常由以下部分组成：

Agent = LLM + Instructions + Tools + Memory + Runtime

其中：

• LLM：负责理解任务、推理和决策。

• Instructions：定义角色、目标和行为约束。

• Tools：提供访问外部系统和执行操作的能力。

• Memory：管理对话历史、任务状态和长期知识。

• Runtime：管理模型调用、工具执行、状态流转、重试和终止条件。

对于简单任务，单 Agent 通常已经足够。例如查询天气、总结文档或根据知识库回答问题。

但是，当任务复杂度逐渐增加时，单 Agent 可能面临以下问题。

1.1 上下文膨胀

假设用户提出一个复杂需求：

分析新能源汽车行业的市场趋势，调研主要竞争对手，对比财务数据，并生成一份投资研究报告。

如果让单个 Agent 完成整个任务，它需要同时处理市场研究、资料检索、数据分析、报告撰写和事实验证。

大量工具调用结果、历史消息和中间分析会不断累积，导致上下文膨胀，增加 Token 成本，并可能降低模型对关键信息的关注程度。

1.2 角色与工具冲突

不同任务需要不同的专业能力和行为约束。

例如，数据分析需要精确计算，信息检索需要关注来源和时效，而报告撰写更关注逻辑组织和表达质量。

如果将所有工具、规则和角色提示词塞进同一个 Agent，其工具选择与任务执行可能变得不稳定。

1.3 缺乏有效的并行能力

复杂任务往往可以拆成多个独立子任务。

例如：

• Agent A：研究行业趋势。

• Agent B：研究竞争对手。

• Agent C：分析财务数据。

如果所有工作都由单 Agent 串行执行，整体耗时可能较长。

通过多 Agent 并发执行，可以缩短任务关键路径上的耗时。

1.4 错误难以隔离

当一个 Agent 同时负责规划、执行、分析和总结时，某个环节出现错误可能影响后续所有步骤。

多 Agent 系统可以将职责拆分，为不同任务建立独立的权限、验证规则和恢复机制。

但需要强调：多 Agent 并不天然比单 Agent 更好。

Anthropic 在多 Agent 研究系统的工程实践中指出，多 Agent 引入了新的协调、评估和可靠性问题。只有当任务适合分解、并行处理或需要独立上下文时，增加 Agent 才更有意义。

二、多 Agent 系统的核心架构

从软件工程的角度看，多 Agent 系统可以拆成五个层次。

2.1 编排层（Orchestration Layer）

编排层是多 Agent 系统的控制中心，主要负责：

1. 理解用户目标。

2. 拆解任务并识别依赖。

3. 选择适合的 Agent。

4. 决定串行或并行执行。

5. 管理任务生命周期。

6. 处理异常、重试和终止。

7. 汇总结果并返回用户。

编排层可以由 LLM 驱动，也可以通过确定性的程序逻辑实现。

生产环境通常更适合采用混合方案：

LLM 负责不确定的语义决策，代码负责确定性的执行控制。

例如，让 LLM 决定需要调研哪些竞争对手，但使用程序来控制最大并发量、任务超时、重试次数和执行预算。

2.2 Agent 执行层

每个 Agent 应有明确的职责边界。

以研究报告系统为例：

设计 Agent 时，应避免通过角色名称进行简单拆分。

例如，创建“高级专家 Agent”“资深专家 Agent”“超级专家 Agent”，但让它们拥有相同的提示词和工具，并不能形成真正有效的专业分工。

合理的 Agent 边界应体现为独立的能力、上下文、权限或执行策略。

2.3 工具与能力层

工具是 Agent 与外部世界交互的接口。

常见的工具包括：

• 信息获取：Web Search、RAG、数据库查询。

• 数据处理：Python、SQL、计算器。

• 外部操作：浏览器自动化、API 调用。

• 业务系统：CRM、ERP、订单系统。

• 系统能力：文件管理、命令执行、沙盒。

一个重要原则是：工具权限应按照 Agent 职责分配，而不是默认全部开放。

例如，Researcher 可以查询数据库，但不应该拥有删除数据库表的权限。

2.4 状态与存储层

多 Agent 的协作不能只依靠消息传递，还需要统一的状态管理机制。

通常包括：

• Task State：任务执行状态。

• Context：任务上下文。

• Artifacts：中间产物。

• Memory：长期记忆。

• Checkpoint：用于中断恢复的持久化状态。

2.5 治理与可观测层

治理层负责系统的可靠性、安全性和运行质量，包括：

• Agent 执行轨迹追踪。

• Token 和成本统计。

• 权限验证和安全审计。

• 超时、重试及失败恢复。

• HITL 人工审批。

• 输出质量评估。

这些能力不是某一个 Agent 的职责，而应由系统级运行环境统一提供。

三、常见的多 Agent 协作模式

多 Agent 系统没有唯一正确的架构。

根据任务特征，可以选择不同的协作模式。

3.1 Supervisor：中心化调度模式

Supervisor 是最常见的多 Agent 架构之一。

Supervisor 负责决策，Worker Agent 负责执行。

例如，用户要求研究一家公司的经营情况：

1. Supervisor 分析任务。

2. 调用 Research Agent 获取公司资料。

3. 调用 Analysis Agent 处理财务数据。

4. 调用 Writing Agent 生成报告。

5. Supervisor 汇总并返回。

这一模式的优势在于控制权集中，便于管理 Agent 权限、异常和执行流程。

但如果 Supervisor 参与每一个细小步骤，也可能成为系统的性能瓶颈。

3.2 Handoff：控制权移交模式

Handoff 的核心是将当前任务的执行控制权交给另一个 Agent。

例如，用户询问退款进度。

Triage Agent 识别意图后，将对话移交给 Refund Agent。后者成为当前任务的主要处理者，可以继续与用户交互和调用退款相关工具。

Handoff 与 Supervisor 最大的区别在于控制权归属。

在 OpenAI Agents SDK 中，Manager 可以通过 Agent.as_tool() 调用其他 Agent 并保留控制权；而 Handoff 会将当前执行控制权交给目标 Agent。

Handoff 适合客服路由、专业领域切换等场景。

不过，移交过程中还需要决定哪些历史消息可以传递给目标 Agent，避免无关上下文或敏感信息泄露。

3.3 Pipeline：流水线模式

当任务存在明确的处理顺序时，可以采用 Pipeline。每个 Agent 处理上一个 Agent 的输出。

这种架构适合文档处理、内容生产、代码生成等场景。

它的优点是流程清晰、易于调试，但缺点是串行任务较多，整体耗时可能较长。

3.4 Parallel：并行执行模式

当任务之间不存在数据依赖时，可以并发执行多个 Agent。

例如，Research Agent A 研究竞争对手甲，Research Agent B 研究竞争对手乙，Research Agent C 研究竞争对手丙。

三个子任务相互独立，因此可以并发执行，完成后再聚合结果。

但是，需要区分逻辑并行和实际并行。

只有底层推理服务具有足够的并发处理能力时，多 Agent 并发才能有效降低实际延迟。

3.5 Hierarchical：分层协作模式

顶层 Agent 负责战略规划，下层 Supervisor 负责子任务协调，Worker Agent 负责具体执行。

这种模式适合长周期、跨专业的复杂任务，但也容易出现层级过多、消息重复传递和成本不可控的问题。

因此，不应该为了实现复杂架构而增加无意义的层次。

四、如何设计 Agent 之间的通信？

多 Agent 系统的难点之一，是让不同 Agent 高效、可靠地交换信息。

主要有两种方式。

4.1 直接消息传递

Agent 通过显式消息进行通信。

例如：

{
  "task_id": "task_001",
  "source": "planner",
  "target": "researcher",
  "action": "research",
  "payload": {
    "topic": "新能源汽车市场",
    "requirements": [
      "市场规模",
      "主要竞争对手",
      "近三年市场趋势"
    ]
  }
}

Research Agent 执行后返回结构化结果。

{
  "task_id": "task_001",
  "source": "researcher",
  "target": "planner",
  "status": "completed",
  "result": {
    "artifact_id": "research_001",
    "summary": "已完成市场信息整理"
  }
}

相比直接传递自然语言文本，结构化消息更适合工程化系统。

其优势包括：可验证、可追踪、易于恢复，也方便处理不同版本的 Agent。

4.2 共享状态管理

另一种方案是维护统一的任务状态。

例如：

from typing import TypedDict, Literalclass TaskState(TypedDict):    task_id: str    user_query: str    plan: list[dict]    completed_tasks: list[str]    artifacts: dict    status: Literal[        "pending",        "running",        "waiting_approval",        "completed",        "failed"    ]

所有 Agent 围绕统一状态执行任务，但不意味着所有 Agent 都可以任意修改全部字段。

一个更稳妥的方案是：

• 每个 Agent 只读取必要的上下文。

• 每个任务拥有独立输出。

• 由编排层合并状态。

• 对并发写入实施冲突控制。

尤其是在并发系统中，直接让多个 Agent 修改同一对象，很容易出现覆盖和状态竞争问题。

对于大型结果，可以存储在对象存储或数据库中，然后只在消息中传递 artifact_id。

这样可以避免在多个 Agent 之间反复复制大量文本。

五、多 Agent 的任务拆解与编排

任务规划决定了多 Agent 系统的执行效率。

一个常见错误是将任务拆解成简单的线性步骤，却没有考虑任务之间的依赖关系。

更合理的方式是使用有向无环图（DAG）表示任务。

其中，行业调研、竞品分析和财务数据获取可以并行。

财务指标计算依赖数据获取，而报告生成必须等待三项研究工作完成。

5.1 任务的数据模型

可以将任务描述为：

from pydantic import BaseModelfrom typing import Literalclass Task(BaseModel):    id: str    description: str    agent: str    dependencies: list[str] = []    status: Literal[        "pending",        "running",        "completed",        "failed"    ] = "pending"    result_ref: str | None = None

实际运行时，编排器首先识别依赖已经完成的任务，再将它们提交给适当的 Agent。

5.2 并发调度

假设任务已经被转换为 DAG，可以通过以下逻辑进行调度：

import asyncioasync def execute_ready_tasks(tasks, completed, agents):    ready = [        task for task in tasks        if task.status == "pending"        and all(dep in completed for dep in task.dependencies)    ]    async def run_task(task):        agent = agents[task.agent]        return task.id, await agent.run(task.description)    return await asyncio.gather(        *(run_task(task) for task in ready),        return_exceptions=True    )

这段代码展示的是并发调度的核心思想，并不是完整的生产调度器。

生产环境还需要考虑最大并发数、任务租约、超时、取消、状态持久化、执行幂等性以及失败重试。

特别是存在外部写操作时，不能简单地对所有失败任务自动重试，否则可能重复创建订单、重复付款或重复发送消息。

5.3 动态任务规划

固定 DAG 适用于已知任务流程。

但是部分任务需要在执行过程中动态调整计划。

例如，Research Agent 在检索资料时发现某家公司刚发生重大并购，可能需要追加财务分析任务。

系统可以允许 Planner 对尚未执行的任务进行增量规划，但必须设置约束：

• 最大任务数量。

• 最大规划深度。

• 最大模型调用次数。

• 总 Token 或成本预算。

• 最大任务执行时长。

否则，Agent 可能不断拆分任务，形成无法终止的执行循环。

六、上下文与 Memory 应该如何设计？

多 Agent 系统不是上下文越多越好。

每个 Agent 应当只获得完成当前任务所必需的信息。

可以将上下文划分为三个层次。

第一层：全局任务上下文

包括用户目标、关键约束、整体计划以及共享业务事实。

第二层：Agent 局部上下文

包括当前子任务、专属工具、局部执行历史和相关证据。

第三层：持久化记忆

包括用户偏好、业务知识、历史经验以及允许长期保留的信息。

例如：

Global Context
├── User Goal
├── Task Plan
├── Shared Constraints
└── Artifact References

Research Agent Context
├── Research Task
├── Search Results
└── Evidence

Analysis Agent Context
├── Analysis Task
├── Dataset
└── Python Results

当 Research Agent 完成研究时，不需要把所有网页原文传递给 Analysis Agent，而是提供经过整理的结构化数据、证据引用和必要的原始文件路径。

这实际上是一个 Context Engineering 问题：决定什么信息进入哪个 Agent 的上下文，以及在什么时间进入。

对于需要长期运行的任务，还应该将状态保存到持久化存储中，避免进程重启导致整个任务丢失。

七、HITL：如何支持人工审批与中断恢复？

在实际业务中，并不是所有操作都允许 Agent 自动执行。

例如：

• 发送正式商务邮件。

• 删除重要数据。

• 修改合同关键条款。

• 发起退款或资金支付。

这些操作通常需要人工审批。

需要保存的不仅是对话内容，还包括：

1. 当前任务及执行位置。

2. 完整的待审批工具调用参数。

3. 已完成任务与中间产物引用。

4. 当前 Agent 和后续执行计划。

5. 审批 ID、请求人及审批状态。

6. 已执行外部操作的幂等标识。

假设一个 Agent 同时请求执行两个工具：

{
  "tool_calls": [
    {
      "id": "call_001",
      "name": "query_order",
      "arguments": {
        "order_id": "123"
      }
    },
    {
      "id": "call_002",
      "name": "refund_order",
      "arguments": {
        "order_id": "123",
        "amount": 100
      }
    }
  ]
}

其中 query_order 是只读操作，可以自动执行，而 refund_order 是高风险操作，需要人工审批。

系统应当分别记录两个工具调用的状态，而不是将整批工具调用简单标记为完成或失败。

人工批准后，应恢复到已保存的执行位置，只继续执行尚未完成且已授权的操作，而不是重新运行整个任务。

对于并发 Agent，状态恢复尤其要注意审批期间外部业务状态可能已经变化，因此实际执行前还需要重新校验关键前置条件。

八、生产环境中的可靠性设计

一个多 Agent Demo 可以只包含几个 Agent 和一段调度逻辑。

但生产系统还需要面对任务失败、外部服务波动、状态丢失、成本不可控以及安全风险。

8.1 失败恢复

建议将失败分成三种类型。

不要让 LLM 自行无限次重试。

重试次数和策略应由 Runtime 管理。

8.2 安全与隔离

不同 Agent 应具有不同的权限边界。

例如，Research Agent 不需要写入生产数据库，Analysis Agent 执行 Python 代码时应运行在受限沙盒中。

对于涉及文件操作和命令执行的 Agent，需要考虑：

• 沙盒隔离。

• 文件访问白名单。

• 网络出口限制。

• 凭据隔离。

• CPU、内存和执行时间限制。

• 高风险操作审批。

同时，网页、RAG 文档和工具输出属于不可信内容。

应防止恶意文档通过 Prompt Injection 诱导 Agent 忽略既定规则或执行未授权操作。

8.3 可观测性

建议为整个任务分配一个 trace_id，并对每次 Agent 调用、模型调用和工具调用建立独立的 Span。

例如：

Trace: task_001
│
├── Planner Agent
│   └── LLM Call
│
├── Research Agent
│   ├── LLM Call
│   └── Web Search
│
├── Analysis Agent
│   ├── LLM Call
│   └── Python Tool
│
└── Writer Agent
    └── LLM Call

通过执行轨迹，可以定位任务究竟是卡在模型推理、工具调用、外部 API，还是 Agent 之间的状态交接。

8.4 质量评估

多 Agent 系统的评价不能只看最终回答是否正确。

建议从以下维度进行评估：

评估时，应该将单 Agent 方案作为基线，比较多 Agent 是否真正提高任务成功率、降低执行时间或改善结果质量。

如果多 Agent 仅增加了调用次数和系统复杂度，却没有提高实际效果，就应该重新评估架构设计。

九、一个完整案例：设计 AI 行业研究系统

假设现在需要设计一个能够自动完成行业研究的系统。

用户输入：

研究国内新能源汽车行业的发展情况，对比主要厂商，分析市场机会，并生成一份研究报告。

9.2 执行过程

首先，Planner Agent 生成结构化研究计划，确定主要研究主题、所需数据和任务之间的依赖关系。

随后，Orchestrator 将独立任务分发给三个专业 Agent，并发获取行业资料、竞争对手信息和财务数据。

各 Agent 完成后，将结果存储到 Artifact Store，只向编排层返回简要摘要、状态和产物引用。

Writer Agent 根据这些产物生成报告初稿。

Reviewer Agent 检查报告中的事实、数字、证据来源和结构完整性。如果发现可修复的问题，则生成具体修订意见。

系统在预设的最大修订次数内完成修改，最终输出报告。如果无法获得可靠证据，则明确标注信息不足，而不是编造结论。

9.3 技术选型

可采用以下组合：

这里需要根据系统特征选择编排框架。

如果核心需求是明确的状态流转、条件路由、循环以及中断恢复，可以重点考虑 LangGraph。

如果希望通过较轻量的 Agent、Tools 和 Handoff 抽象快速构建多 Agent 应用，可以考虑 OpenAI Agents SDK。

OpenAI 官方将模型驱动编排与代码驱动编排视为两种可以组合使用的方法。前者灵活，后者在流程可预测性、执行成本和控制能力方面具有优势。

十、多 Agent 系统的设计原则

回顾整个架构设计过程，可以总结出几个关键原则。

第一，先设计任务，再设计 Agent。

应该首先分析任务的依赖关系、能力需求和可并行部分，再根据这些边界定义 Agent，而不是先创建多个角色后再寻找工作内容。

第二，保持 Agent 职责单一。

每个 Agent 应具有明确的输入、输出、工具、权限和完成条件。

第三，区分智能决策与执行控制。

LLM 适合规划、推理、语义路由和生成内容，但并发控制、任务重试、权限校验、状态持久化等问题应交给确定性的程序机制处理。

第四，控制上下文，而不是共享所有上下文。

通过共享状态和产物引用进行协作，可以减少重复 Token 消耗，并降低无关信息干扰。

第五，把 Agent 当作不可靠的执行单元。

需要预期模型可能生成错误参数、选择错误工具、产生不准确结果，因此必须设计验证、重试、回滚或补偿、审批及恢复机制。

第六，优先优化端到端效果。

多 Agent 的价值最终应体现为任务成功率、结果质量、成本和延迟的改善，而不是 Agent 数量的增加。

十一、总结

多 Agent 系统本质上是将传统软件工程中的模块化设计、任务调度、并发执行、状态管理和权限控制，与大语言模型的语义理解和自主决策能力结合起来。

从工程角度看，设计多 Agent 系统需要解决四个核心问题：

1. 任务如何拆分？ 通过明确的依赖关系与能力边界建立任务计划。

2. Agent 如何协作？ 根据场景选择 Supervisor、Handoff、Pipeline、Parallel 或 Hierarchical 模式。

3. 状态如何维护？ 通过结构化消息、共享状态、Artifact 和 Checkpoint 支持持续执行与恢复。

4. 系统如何可靠运行？ 通过验证、权限、HITL、可观测性和评估机制确保执行过程可控。

未来的多 Agent 系统未必需要越来越多的 Agent，而是需要更加成熟的运行环境和协作机制。

一个优秀的多 Agent 系统，不是让 Agent 拥有无限的自主权，而是在可控的边界内，让 Agent 充分发挥自主决策能力。