为什么多 Agent 不只是 Function Calling？Multi-Agent 架构深度解析：从任务委派、控制权移交到 Runtime 设计

随着大模型自主规划与工具使用能力的增强，多 Agent（Multi-Agent）逐渐成为构建复杂 AI 系统的一种重要架构选择。它的基本思想并不复杂：将不同的专业能力封装成独立的 Agent，由一个主 Agent（Main Agent）根据用户目标进行任务分解，再协调各个专业子 Agent 共同完成任务。

例如，在企业电信账单分析系统中，当用户提出“分析 A 集团最近三个月的账单变化，找出异常费用，并结合业务规则解释原因”时，主 Agent 可以将任务拆解并交给多个专业 Agent 处理：

                   Main Agent
                       |
          +------------+------------+
          |            |            |
      账单查询Agent  异常分析Agent  业务规则Agent
          |            |            |
          +------------+------------+
                       |
                  综合分析结果

在最简单的实现中，Main Agent 只需调用一个工具，将任务描述传递给对应的 Subagent，等待执行完成后拿回结果，再汇总呈现给用户。很多早期的 Multi-Agent Demo 就是这样实现的。

但随着系统复杂度增加，这种简单的调用模式很快就会暴露出一系列问题：

首先是等待方式与交互控制权的问题。主 Agent 调用子 Agent 后，是否必须原地等待？如果子 Agent 需要较长时间处理，主 Agent 能否同时去处理其他任务？此外，如果专业 Agent 在执行过程中需要向用户确认信息，是否每次都必须通过主 Agent 转述？能否将当前的对话直接交给专业 Agent 来处理？

其次是过程展示与结果传递的问题。子 Agent 执行过程中会产生大量消息、工具调用和中间数据，用户界面应该如何实时展示这些过程？如果子 Agent 返回的是 JSON、图表数据或文件，是否还必须经过主 Agent 的语言模型重新生成一遍？

当系统进一步进入生产环境后，还会遇到更多工程可靠性问题：

生命周期管理：主 Agent 终止时，远程子 Agent 是否应该一起停止？
并发交互协调：多个子 Agent 同时请求用户输入时，前端和后端应该如何协调？
业务副作用处理：子 Agent 已经修改了外部系统数据，但后续任务失败，已发生的操作如何补偿？
断线与安全重试：如果远程 Agent 已经执行成功，只是网络连接中断，系统能否在不引发重复执行的前提下恢复结果？
状态共享与治理边界：不同 Agent 的会话（Session）、上下文和结果如何高效共享？多层 Agent 委派时，如何管理权限、资源预算和调用深度？

这些问题实际上已经超出了普通 Function Calling 的范畴。Multi-Agent 的真正难点，并不是如何启动更多 Agent，而是当多个 Agent 都具有独立的执行循环（Agent Loop）和自主决策能力时，如何让它们在明确的协作契约下共同完成任务。

要理清这套协作机制，首先需要区分几种最常见的多 Agent 协同方式。

二、三种不同的多 Agent 协同方式：委派、移交与异步执行

从实际系统中的调用行为出发，可以先讨论三种最常见的协同方式：Delegation（委派）、Handoff（控制权移交） 和 Asynchronous Collaboration（异步协作）。

这三种方式能够覆盖大量主从式 Multi-Agent 系统，但它们并不是严格互斥的分类。Delegation 和 Handoff 主要关注“任务与控制权归属”，而 Async 主要关注“执行时序”——一次任务委派既可以是同步的，也可以是异步的。

2.1 Delegation：主 Agent 委派子任务

Delegation 是最常见、也最容易理解的多 Agent 协同方式。Main Agent 将一个具有明确边界的任务交给 Subagent；子 Agent 在自己的执行环境中独立完成任务，最后将结果返回给主 Agent，由主 Agent 继续后续处理。

Main Agent
    |
    | Delegate(Task)
    v
Subagent
    |
    | LLM Reasoning
    | Tool Calling
    | Intermediate Results
    |
    v
Task Result
    |
    v
Main Agent Resume

这种模式通常被称为 Agent-as-Tool。虽然被调用的子 Agent 拥有自己的 Agent Loop，能够进行多轮推理和工具调用，但从 Main Agent 的角度来看，它表现为一个内部逻辑更复杂的工具。

在这里需要区分两种不同层面的控制权：

任务级控制权：由 Main Agent 持有，负责决定是否委派任务、选择哪个子 Agent，以及如何使用最终返回的结果。
局部执行控制权：由 Subagent 持有。子 Agent 在获得任务后，可以自主决定调用哪些工具、如何处理信息以及何时完成任务。例如，主 Agent 请求“账单查询 Agent”分析集团账户结构，子 Agent 可以自主决定先检索集团层级关系、再查询关联账户、最后做数据聚合。Main Agent 不需要指定每一步操作，只需要获取最终结果。

因此，Delegation 并不意味着子 Agent 缺乏自主性，而是其自主性受到委派任务范围的约束。这种模式适合专业信息查询、独立分析、代码审查、数据处理等输入输出边界清晰的任务。但它的局限在于：如果所有结果都必须先返回给 Main Agent 再统一处理，在面对复杂的直接交互或大型结构化数据交付时就会受到限制。

2.2 Handoff：将控制权移交给另一个 Agent

Handoff 与 Delegation 的关键区别在于，它不仅涉及任务委派，还涉及后续执行主导权或用户交互责任的转移。

假设用户向通用客服 Agent 提出了一个复杂的账单争议。通用客服 Agent 判断该问题需要专门的“账单争议 Agent”处理。此时，与其由通用 Agent 在中间反复代为提问、转述用户回答，不如直接将当前对话移交给专业 Agent：

User
  |
  v
General Agent
  |
  | Handoff
  v
Billing Dispute Agent
  |
  | 查询账单
  | 与用户直接交互
  | 收集补充信息
  |
  v
Resolve / Handoff Back

与 Delegation 不同，移交后的专业 Agent 不再只是一个幕后返回结果的工具，而是成为后续交互与执行的主要责任方。

在工程实践中，Handoff 并不是简单地切换一段 System Prompt 或改个 Agent 名称，它需要明确以下几个关键问题：

控制权到底转移了什么？ 控制权可能包括当前任务的执行决策权、用户交互权，以及最终回复的责任。这些权利并不一定同时转移——例如，专业 Agent 可以接管用户对话，但某些关键操作仍然需要上层系统批准。
原 Agent 在 Handoff 后处于什么状态？ 它可以暂停并等待专业 Agent 完成，也可以直接结束当前参与，或者保留一定的监督职责。
控制权如何回收或传递？ 专业 Agent 完成后，可以直接结束用户请求，也可以将控制权交还原 Agent（Handoff Back）。如果专业 Agent 还需要其他能力协助，还可能产生连续移交。

因此，一套完整的 Handoff 机制更接近一种显式的控制权转移协议，至少需要定义：当前控制权的持有者、允许移交的目标与权限范围、原 Agent 的暂停或退出方式、用户交互与最终答复责任，以及移交失败或取消时的恢复机制。

2.3 Asynchronous Collaboration：异步执行与并行协作

前两种方式讨论了任务由谁执行、控制权属于谁。但实际系统还需要处理另一个问题：Main Agent 调用子 Agent 后，是否必须一直等待它完成？

在简单的同步委派中，Main Agent 必须等待子任务返回结果后才能继续。当单个任务耗时较长，或者需要多个专业 Agent 同时工作时，同步等待会显著拉长整体响应时间。异步协作则允许 Main Agent 在启动子任务后继续执行其他工作，而不必原地等待当前子任务结束：

例如，主 Agent 同时启动“账单查询 Agent”和“资费规则 Agent”。当账单查询 Agent 提前返回数据后，主 Agent 可以立即启动异常分析任务，而不必一直等到资费规则 Agent 执行完毕；随后，当规则查询结果到达时，再结合已经完成的异常分析生成最终解释。

这种机制在实际运行中对应着四种不同的等待策略：

等待策略	运行时行为	适用场景
Wait-all	等待所有并发子任务全部完成后继续	多维数据汇总、常规并行分工
Wait-any	任意一个子任务达到条件或返回后即可继续	多渠道检索、备选方案竞速
Incremental	每获得一部分结果就允许主 Agent 继续决策并调整后续计划	深度调研、复杂问题排查
Background	子任务在后台独立运行，主 Agent 不必持续等待	耗时报表生成、后台批处理任务

其中 Incremental（增量决策） 尤其值得关注。传统 Workflow 往往需要预先固定好所有任务的依赖关系；而具备自主决策能力的 Main Agent，可以根据先到达的部分结果动态创建、取消或调整后续任务。这使得异步多 Agent 不仅是一种并发加速手段，也成为增强动态规划能力的重要方式。

相应地，异步协作也带来了新的工程问题：子任务结果如何通知 Main Agent？如果 Main Agent 的当前轮次已经结束，后台任务是否仍允许继续？主任务取消时，是否应该级联取消所有后台子任务？因此，异步协作不能仅理解为把同步调用改成非阻塞调用，它还需要配套的任务状态管理、结果通知机制与生命周期控制。

2.4 三种协同方式的对比

下面是一个三种多agent协作模式的对比：

用表格总结如下：

维度	Delegation（委派）	Handoff（移交）	Async Collaboration（异步协作）
核心关注点	任务委派与结果返回	控制权与交互责任移交	非阻塞执行与并行协同
主 Agent 角色	通常保留总体控制权	可移交当前控制权	启动子任务后可继续执行
子 Agent 角色	独立处理被委派的子任务	接管后续执行或用户交互	后台独立运行、异步交付结果
结果处理方式	通常返回给主 Agent	由当前接管责任的 Agent 处理	通过事件通知或状态查询获取
典型场景	专业查询、局部分析	专家坐席接管、业务流转	长耗时任务、并行研究与增量规划

需要强调的是，上表描述的是三种常见的协同行为，而不是互斥的系统类型。例如，一个长期运行的后台分析任务本质上仍然可以是 Delegation；Handoff 接管后的专业 Agent 也完全可以发起异步委派。系统设计真正需要关注的是这些协同行为背后的控制权契约。

三、任务与会话：为什么必须区分 Session、Run 和 Invocation？

明确协同方式之后，下一个问题是：一个子 Agent 究竟代表一次调用、一个会话，还是一个持续运行的执行实体？

在简单的 Demo 中，这些概念常被混在一起处理：Main Agent 调用 Subagent，框架创建一个临时上下文，执行完成后返回结果，整个过程看起来就是一次普通任务。但在生产系统中，往往需要支持持续会话、任务恢复、多次调用以及异步运行，因此有必要将 Session、Run 和 Invocation 作为三个独立概念加以区分。

3.1 Session、Run 与 Invocation 的各自职责

Session（会话身份与上下文）：负责保存 Agent 的对话历史及相关上下文状态。一个 Session 可以长期存在，即使当前并没有 Agent Loop 正在运行。例如，专业账单 Agent 完成第一次分析后，几分钟后 Main Agent 希望它基于刚才的分析继续检查某个异常账户，此时可以直接复用原有 Session，而不必重新构建全部上下文。Session 的存在并不意味着持续占用计算资源。
Run（一次实际的 Agent 执行）：表示 Agent 从接收输入到结束当前执行的一次 Loop 激活。一个 Session 可以先后经历多次 Run，每次 Run 内部可能包含多轮 LLM 推理、工具调用、状态更新和结果生成。Run 的终止语义需要由框架明确定义：完成、失败、取消通常属于终态；而等待输入、暂停或等待子任务，则属于可恢复的中间状态。
Invocation（一次委派调用契约）：表示调用方发起的一次任务委派请求，它记录的是跨 Agent 的调用关系与契约，而不是单纯的执行上下文。

这三者的关系可以通过以下结构清晰展现：

Main Session A
     |
     +--- Invocation 1
     |         |
     |         v
     |    Child Session B  --->  Run 1
     |
     +--- Invocation 2
               |
               v
          Child Session B  --->  Run 2

同一个 Child Session B 可以被多次委派使用：Invocation 1 和 Invocation 2 是两次不同的委派请求，但复用了同一个子会话，并分别触发了 Run 1 和 Run 2。此外，在复杂的异步系统中，一次 Invocation 如果遇到瞬时异常，还可能经历任务重试或重新调度，因此不应简单将 Invocation ID 等同于底层的 HTTP Request ID。

简言之：Session 管理上下文，Run 表示一次执行过程，Invocation 表达一次协作委派请求。 它们各自具有不同的身份标识与生命周期。

3.2 One-shot 与 Durable Session 的区别

基于上述模型，可以区分两种常见的子 Agent 使用方式：

One-shot（一次性任务）：每次调用都创建新的执行上下文，任务完成后交付结果，后续不再复用该子会话。适合短耗时任务、独立分析以及无需保留工作上下文的操作。
Durable Session（持续会话型 Agent）：子 Agent 保留自己的 Session，后续的 Invocation 可以继续使用原来的上下文。适合长期调查、多轮分析以及需要保留阶段性进展的复杂任务。

在工程实现上需要注意，Durable Session（持久化会话）不能直接等同于 Durable Execution（持久化执行）。把会话历史保存到数据库中很容易，但这并不代表正在执行的外部工具调用、内存状态和 Agent Loop 可以在另一台机器上无缝恢复。例如，当远程 Agent 所在进程突然崩溃时，系统虽然能找回此前的消息历史，却无法直接恢复某个正在等待外部返回的工具调用。

因此，在设计系统时必须明确区分三种不同层次的能力：恢复会话上下文、重新启动一次 Run，以及恢复尚未完成的执行过程。这三者的实现难度与可靠性保证并不相同。

3.3 连接生命周期不等于任务生命周期

对于远程或跨进程调用的 Agent，这一点尤为关键。假设 Main Agent 通过 HTTP 调用 Remote Agent，当远程任务正在运行时，网络连接因超时或闪断而中断。此时远程任务实际上可能处于三种不同状态：

远程任务已经成功完成，只是最终结果未能送达；
远程任务仍在后台继续执行；
远程任务确实失败或已被取消。

仅凭 HTTP 连接关闭这一现象，调用方无法区分上述情况。因此，分布式 Multi-Agent 系统不能仅依赖网络连接状态来判断任务状态，而必须具备独立的 Invocation / Run 状态查询与持久化记录机制。这是普通远程调用与真正的分布式协作之间一条非常重要的分界线。

四、控制流与数据流解耦：Message、Event 和 Artifact

前面的讨论主要关注 Agent 如何执行任务以及控制权如何流转。但在实际应用中，另一个常被忽略的问题是：子 Agent 产生的信息，究竟应该通过什么路径交给谁？

传统的 Agent-as-Tool 模式通常采用一条固定的传递路径：

Subagent  --->  Task Result  --->  Main Agent LLM  --->  Frontend

对于纯自然语言任务，这种处理方式通常没有问题——专业 Agent 返回调查结论，主 Agent 综合多个结论后形成最终回答。但并不是所有输出都适合走这条路径。

4.1 为什么结构化结果不应该总经过 Main Agent？

假设账单分析子 Agent 生成了以下用于绘制趋势图的 JSON 数据：

{
  "type": "bill_trend",
  "currency": "CNY",
  "months": ["2026-07", "2026-08", "2026-09"],
  "amounts": [12000, 15000, 13500]
}

前端图表组件原本可以根据这份结构化数据直接渲染趋势图。但如果要求所有结果都必须先交给 Main Agent 的语言模型处理一次，它很可能会将其重新总结为一段文字：“7 月费用为 1.2 万元，8 月上涨至 1.5 万元，9 月回落至 1.35 万元。”

这种做法会带来三个明显问题：

数据结构丢失或被改写：原始 JSON 的字段、数据类型和结构不再得到保证；如果下游还有其他 Agent 需要使用这份数据，就不得不重新解析自然语言。
不必要的上下文与 Token 开销：对于包含数百条记录的大型 JSON 或表格，将其放入 Main Agent 的上下文再重新输出，会造成明显的 Token 浪费和延迟。
控制权与数据序列化权混淆：Main Agent 拥有任务编排与决策权，并不意味着所有子 Agent 产出的业务数据都必须经过 Main Agent 的语言模型重新生成一遍。

4.2 区分 Message、Event 和 Artifact

更合理的设计，是在系统协议层面明确区分三类不同的信息对象：

信息类型	主要语义	典型内容	主要消费者
Message	Agent 与用户或其他 Agent 的交流	任务指令、澄清提问、结论摘要、原因解释	Main Agent 的推理过程 / 用户
Event	执行过程中发生的状态与进度变化	启动运行、文本流式增量、工具调用、状态更新	前端执行时间线（Timeline） / 监控系统
Artifact	任务产生的结构化、可复用结果	JSON 数据、表格、分析报告、代码或文件	前端渲染器（Renderer） / 下游其他 Agent

这三者不一定由完全独立的存储系统实现，但应当在传递路径与消费语义上加以区分：

                    Subagent
                       |
           +-----------+-----------+
           |           |           |
        Message       Event      Artifact
           |           |           |
           v           v           v
       Main Agent    Frontend   Artifact Store
       / Consumer    Timeline        |
                                     v
                              Frontend Renderer
                              / Other Agent

如图所示，Message 由 Main Agent 消费，用于后续推理与决策；Event 由前端订阅，用于实时展示执行过程；而 Artifact 则经由 Runtime 校验并持久化后，直接通过引用交付给前端渲染器或下游 Agent。

这种思路与 Agent2Agent（A2A）协议 中的 Message、Task、Artifact 模型是一致的：将自然语言交互与结构化任务产物分离，同时支持独立的状态与产物更新。

4.3 为什么 Event 不应该全部经过 Main Agent？

一个子 Agent 在运行过程中可能会密集产生大量过程事件：开始运行、输出流式文本增量、发起工具调用、工具返回结果、进入下一轮推理、更新任务状态等。

如果这些事件全部先传给 Main Agent，再由 Main Agent 转发给前端，会出现两个问题：第一，Main Agent 的上下文会被大量过程数据占据；第二，LLM 推理并不是可靠的事件转发通道，它可能会合并消息、遗漏细节或改变原始内容。

因此，事件通道应当独立于 Agent 的推理通道：

Main Agent ---------+
                    |
Child Agent A ------+----> Event Gateway ----> Frontend
                    |
Child Agent B ------+

各个 Agent 将运行事件直接发送至 Event Gateway，前端根据事件携带的 Session ID、Invocation ID 和 Agent ID，将其关联到对应的任务节点上。这样用户既能看到 Main Agent 的整体进展，也能展开查看某个子 Agent 的工具调用和阶段性输出，而无需等待子 Agent 运行结束。

对于使用 SSE（Server-Sent Events）推送事件的系统，还需要注意两点：

实时订阅与历史回放的配合：普通 SSE 连接负责传递实时增量，但不会自动提供完整的历史回放。当页面刷新或断线重连时，需要配合持久化的事件日志恢复执行状态，并处理好重连期间的重复事件去重与遗漏风险。
事件的可见性策略：并非子 Agent 的所有内部状态都适合公开展示。工具调用的敏感参数、内部数据库查询细节以及未公开的推理过程，都需要在网关层受到可见性策略的过滤与约束。

4.4 Artifact 的独立交付契约

当 Artifact 不经过 Main Agent 的语言模型直接向外交付时，仍然需要经过明确的授权和验证流程。系统可以为 Artifact 定义独立的元数据契约，包括：Artifact ID 与版本号、所属 Invocation 和 Session、数据类型及 Schema、存储位置或引用地址、访问权限、校验状态以及交付策略。

例如，某份账单趋势图的 Artifact 可以根据策略直接交付给前端渲染，而业务规则检索产生的中间数据则可能仅允许内部 Agent 按引用访问。

简言之，控制权流转、执行过程事件和结构化结果交付是三个不同的工程问题，不应全部压缩在一次简单的 Tool Result 返回值中。

五、生产级 Multi-Agent 系统还需要解决哪些工程问题？

当系统从简单的同步委派发展到异步执行、持续会话和跨进程协作后，会面临更多分布式工程挑战。其中不少问题并非大模型所独有，但由于 Agent 具有动态决策能力，这些问题在实际运行中会变得更加动态。

5.1 取消、超时与故障恢复

假设 Main Agent 启动了一个耗时两分钟的远程账单分析任务，执行到第 30 秒时，用户取消了当前请求。此时主 Agent 停止后，远程子 Agent 是否应该立即停止？如果子 Agent 已经启动了外部工具并正在修改业务数据，又该如何处理？

合理的设计应当明确父子任务的取消关系：对于同步委派，默认可以级联取消子任务；对于明确允许在后台独立运行的任务，则可以根据策略保留其继续执行。同时，**“取消”不能只表现为把数据库里的状态字段改成 Cancelled**。Runtime 需要向实际执行者发出取消指令，并确认执行循环是否真正停止；对于无法中途停止的外部操作，应如实记录其真实状态，避免将“已发出取消请求”误当作“所有操作均已撤销”。

超时处理同样如此。远程调用超时并不代表远程任务一定失败。平台应当先通过 Invocation ID 查询原任务的真实状态，而不是立即盲目创建新任务。对于可能产生业务副作用的操作，需要结合稳定的 Invocation ID、业务幂等键和结果去重机制来避免重复执行。在工程上，必须明确区分执行失败、通信超时与结果交付失败这三种不同情况。

5.2 并发任务与动态扩张的约束

当多个子 Agent 并行执行时，Main Agent 往往需要根据部分结果动态调整后续安排。例如，账单查询 Agent 已经完成，而规则分析 Agent 仍在运行，Main Agent 根据已返回的数据决定追加一个异常分析子任务。

这种动态行为很难完全通过预定义的静态 DAG 来描述，但这并不意味着要放弃确定性的资源协调。特别是当子 Agent 也具备继续向下委派任务的能力时，必须限制多层 Agent 的无限扩张：

Main Agent
    |
    +-- Agent A
    |     |
    |     +-- Agent C
    |     +-- Agent D
    |
    +-- Agent B
          |
          +-- Agent E

如果每个 Agent 都可以无限制地创建子 Agent，任务树就会迅速膨胀失控。因此，系统需要设置全局最大调用深度、并发数量上限、执行时长限制和 Token 预算约束。这些约束属于 Runtime 的确定性职责，不能仅靠在 Prompt 里提醒大模型“注意节省资源”来实现。

5.3 HITL：多个 Agent 同时请求用户输入

Human-in-the-Loop（HITL，人工介入）是并发场景下另一个容易被忽略的问题。假设 Main Agent 同时委派了两个专业任务：“账单 Agent”执行到一半，需要用户确认要分析哪些账户；与此同时，“资费规则 Agent”也需要用户补充提供合同版本。此时两个子 Agent 同时进入了 Waiting for Input 状态：

                  Main Agent
                 /          \
                /            \
         Billing Agent    Policy Agent
               |               |
         Waiting Input    Waiting Input
               |               |
               +-------+-------+
                       |
                       v
                    Frontend

如果系统只是简单地将两个提问作为普通文本推送到前端，用户可能不清楚自己的回复究竟发给了哪个 Agent。

因此，用户交互本身也需要明确的关联契约。每个交互请求都应分配独立的 Interaction ID，并关联对应的 Invocation、Session、期望的输入类型以及恢复目标。前端可以根据需要将多个交互请求并列展示、合并成表单或按优先级排序；当用户提交回复后，Runtime 能够根据 Interaction ID 将答案准确路由给正在等待的那个子 Agent，而不必默认交回给 Main Agent 重新判断和转述。

这说明：多 Agent 系统不仅需要管理任务执行控制权，还需要管理用户交互权与审批权。

5.4 业务副作用：取消 Agent 不等于撤销业务操作

很多早期 Agent 示例主要执行只读任务（如查询资料、搜索代码、生成文档），但企业级 Agent 往往会直接修改外部业务系统：

Agent
  |
  +-- 1. 查询欠费账户
  +-- 2. 修改催缴策略
  +-- 3. 创建催缴任务
  +-- 4. 发送客户通知

如果 Agent 在创建催缴任务后发生失败，此前已经完成的业务修改不会因为 Agent Loop 的停止而自动回滚。面对这类分布式副作用管理问题，通常有两种工程处理思路：

基于 Saga 模式的业务补偿：对于支持撤销的操作，可以通过业务预定义的补偿动作（Compensating Action）来处理已经提交的局部变更。但需要注意，业务补偿并不等同于数据库事务回滚——某些外部操作（例如已经发送成功的短信或邮件）是无法撤销的。
高风险操作的 Plan-then-Execute：首先让 Agent 生成结构化的变更计划或 Dry-run Artifact，经过权限校验或人工确认后，再交由确定性的执行服务完成实际写入操作。

在概念上，不应简单把 Dry-run + Approval 等同于分布式事务中的两阶段提交（2PC）。真正的 2PC 需要底层参与方提供事务准备（Prepare）和提交（Commit）原语，而普通的外部业务 API 往往不具备这一条件。因此，Runtime 可以负责记录操作日志、传递幂等信息并调度补偿流程，但具体的补偿语义仍需由业务系统自身定义。

5.5 Artifact 的多层次校验

让结构化 Artifact 绕过 Main Agent 的语言模型直接交付，虽然减少了重复生成和格式失真，但并不代表所有 Artifact 都可以不经检验直接使用。例如，账单分析 Agent 返回的 JSON 可能在格式上完全符合 Schema，但却漏掉了集团下属某家分公司的账户，导致汇总金额错误。

因此，针对关键产物需要建立不同层次的校验机制：

校验层次	核心检验内容	主要责任方
技术校验	JSON Schema 合法性、字段类型、版本号、访问权限	Runtime
业务校验	账户覆盖范围、金额勾稽关系、业务规则约束、数据来源	领域业务服务 / 规则引擎
语义验证	解释是否合理、结论是否有证据支撑、是否需要进一步调查	独立验证 Agent（Verifier） / 人工审核

需要注意的是，不能把“让 Main Agent 再总结一遍”视为可靠的验证方式——语言模型同样可能顺着上游 Agent 的错误数据给出看似通顺的解释。真正可靠的验证，通常需要依赖独立的证据来源、确定性的业务规则或必要的人工审核。

5.6 跨 Agent 的上下文与状态共享

多 Agent 协作中的上下文管理常面临一个两难矛盾：如果所有 Agent 共享全部对话历史，容易产生大量冗余信息并导致上下文迅速膨胀；如果各个 Agent 完全隔离，下游 Agent 又可能缺少完成任务所必需的背景信息。

例如，上游 Agent 已经从包含上百个实体、数千个属性和关系的本体 Schema 中检索出了相关的局部子图，接下来需要下游 Agent 依据这个子图生成 Cypher 查询语句。如果每次都把整个子图复制到 Prompt 中传递，Token 成本较高；如果只传递一句自然语言摘要，又可能丢失关键的实体关系和属性名称。

更合理的做法是将“推理上下文”与“业务共享数据”分离：

在 Invocation 中只传递明确的任务目标和必要的背景摘要；
对大型业务数据采用结构化 Artifact 引用传递（Pass-by-Reference），允许子 Agent 在执行过程中按需读取相关数据；
同时在存储层管理好共享状态的版本、访问权限与并发更新。

5.7 权限传播与全链路可观测性

在权限管理上，“Agent A 可以调用 Agent B”并不意味着“Agent A 自动拥有了 Agent B 的全部权限”。对于跨进程、跨业务系统甚至跨组织的 Agent 协作，必须明确区分调用者身份、任务委派权限以及目标 Agent 的实际工具执行权限。

在可观测性方面，系统需要能够基于统一的关联标识还原完整的跨 Agent 执行链路：

User Request
    └── Main Agent Run
          └── Invocation A
                └── Remote Agent Run
                      ├── LLM / Tool Calls
                      └── Artifact / Result Delivery

只有建立起统一的跨节点追踪标识（Trace / Correlation ID），工程团队才能在发生超时、执行失败、成本异常或结果丢失时快速定位问题根源，而不是仅靠翻查单个 Agent 的孤立日志。

六、Multi-Agent Runtime：应该管理什么，不应该管理什么？

通过前面的分析可以看到，生产级多 Agent 系统需要解决大量跨 Agent 的确定性工程问题。如果把这些问题全部交给大模型通过 Prompt 自行维护，通常很难获得可靠的工程保证；但反过来，如果把所有执行步骤都固定在中央控制器里，又会削弱 Agent 应对复杂任务的自主能力。

因此，架构设计的核心在于明确划分 Agent Loop 与 Multi-Agent Runtime 的职责边界。

6.1 Agent Loop 与 Runtime 的职责划分

在多 Agent 系统中，Agent Loop 负责局部的自主推理与决策（理解当前任务、决定下一步行为、选择和调用工具、判断是否需要委派子任务、根据新结果调整计划）；而 Multi-Agent Runtime 则负责跨 Agent 协作的确定性保障：

协作环节	Agent Loop 决定（智能决策）	Multi-Agent Runtime 负责（工程保障）
任务委派	是否需要拆解并委派子任务	创建与管理 `Invocation` 记录
目标选择	需要哪一类专业 Agent 协助	校验目标实例状态、能力匹配与调用权限
执行方式	同步等待还是异步继续规划	任务队列调度、并发控制与运行状态管理
会话延续	是否基于已有分析继续追问	维护 `Session` 与多次 `Run` 的关联生命周期
任务终止	何时停止或放弃某个子任务	取消信号的级联传播与远端停止状态确认
结果消费	如何理解并采纳子任务结论	`Message`、`Event` 与 `Artifact` 的可靠分流交付
人工介入	何时请求用户补充或确认信息	交互请求的 ID 生成、前端聚合展示与精准恢复路由
探索范围	是否继续深挖或追加新任务	强制执行全局资源预算、并发上限与最大调用深度约束

将这一边界抽象为架构图，可以得到如下分层结构：

                  User / Frontend
                         |
                         v
                     Main Agent
                  (Plan / Decide)
                         |
                         v
                Multi-Agent Runtime
         +---------------+---------------+
         |               |               |
      Dispatcher     Lifecycle       Event Gateway
         |             Manager           |
         |               |               |
         +---------------+---------------+
                         |
              +----------+----------+
              |          |          |
           Agent A    Agent B    Agent C
           Own Loop   Own Loop   Own Loop
              |          |          |
              +----------+----------+
                         |
                  Message / Artifact

需要注意的是，这里的 Runtime 是逻辑上的职责集合，并不要求所有模块都部署在同一个中心化进程中。轻量级系统可以在同一进程内以开发库的形式实现这些能力；复杂的大型系统则可以将状态管理、任务调度、事件网关和产物存储拆分为独立的服务组件。

6.2 Runtime 与 Workflow 并不是非此即彼的关系

在架构设计中，还需要澄清一个常见误解：强调 Agent 的自主性，并不意味着应该完全抛弃 Workflow 或状态图（Graph）编排。

在银行信贷审批、财务结算等业务规则十分明确、合规约束强的场景中，由确定性的 Workflow 或状态机控制关键步骤的执行顺序，往往比完全交给大模型动态规划更加可靠；而在某个具体节点内部，则可以使用具备自主 Loop 的 Agent 来完成复杂的分析任务。
相反，对于开放式研究、复杂问题诊断等步骤难以预先固定的任务，则适合让 Main Agent 动态决定后续的协作行为。

因此，一套实用的生产系统往往是三者的结合：由 Workflow 控制确定的业务流程约束，由 Agent 处理不确定的推理与动态规划，由 Runtime 保障跨节点执行的可靠性。

6.3 并非所有任务都需要完整的 Multi-Agent Runtime

同样需要明确的是，并不是所有 AI 应用都需要引入一整套复杂的 Multi-Agent Runtime。

对于耗时短、低风险、上下文紧密内聚的任务，使用单 Agent 配合普通工具调用，或者使用简单的本地 Subagent 调用通常就已经足够。每增加一个独立的 Agent 执行实体，都会带来额外的上下文传递、通信开销、状态同步和故障排查成本。

只有在确实涉及跨进程调用、耗时后台执行、持续会话复用、多层委派、多路人工介入或高可靠性要求时，完整的跨 Agent 运行时管理机制才真正体现出工程价值。Multi-Agent 应当用于解决单 Agent 难以高效完成的复杂问题，而不必成为所有任务的默认起点。

七、扩展讨论：超越主从委派的其他多 Agent 协作模式

前文主要围绕 Delegation、Handoff 和异步执行展开讨论。这三种方式覆盖了大量以 Main Agent 为中心的主从式协作场景，但多 Agent 协作并不只有主从关系这一种形态。

在经典的分布式人工智能、多智能体系统（MAS）研究，以及现代主流 Agent 框架中（例如 Microsoft Agent Framework 提供的 Sequential、Concurrent、Group Chat、Handoff、Magentic 等编排方式，以及 LangGraph 支持的图状态机与动态编排组合），还存在共享状态驱动、生成评审、并行冗余求解、状态机编排和动态协商等不同思路。

下面补充介绍五种具有代表性的协作模式。需要说明的是，它们与前面的三种基础协同方式并不完全处于同一分类维度——有些侧重状态共享结构，有些侧重质量验证策略，有些则侧重任务分配机制。

7.1 Blackboard（黑板模式）：共享状态驱动的协作

Blackboard 模式可以追溯到经典的 AI 问题求解系统。它的基本思想是：多个具有不同专业能力的 Agent 围绕一个共享工作空间（Blackboard）进行协作。 各个 Agent 不一定需要直接相互调用，而是通过读取共享状态、写入新的分析结果，由共享状态的变化来推动后续步骤的执行：

       Research Agent
             |
             v
       +-------------+
       |             |
       |  Blackboard |
       | Shared State|
       |             |
       +-------------+
          ^       ^
          |       |
     Analyst    Reviewer
      Agent      Agent

例如在复杂软件开发场景中，需求 Agent 首先生成需求规格并写入共享空间，架构 Agent 读取规格后形成系统设计，多个编码 Agent 再围绕共享空间完成各自模块的开发。各个 Agent 可以根据黑板状态的变化主动触发工作，而不一定由同一个 Main Agent 逐个派单。

适用场景：开放式探索、复杂课题研究和长期知识积累等任务路径难以提前固定的场景。
工程考量：Blackboard 并不必然意味着完全去中心化，系统仍然可以保留协调组件来决定下一步激活哪个 Agent。它的主要工程挑战在于共享状态的管理：如何处理多个 Agent 的并发写入冲突？当不同 Agent 对同一问题给出矛盾结论时如何裁决？以及如何判断整个系统的协作已经收敛完成？因此，它更适合以共享工作空间为核心媒介的探索型任务，而不一定是常规企业业务流程的首选。

7.2 Generator-Critic / Debate（生成与评审模式）

这种模式让两个或多个 Agent 围绕同一份任务产物进行“生成 — 评审 — 修正”的迭代循环：

Generator Agent  --->  Artifact v1  --->  Reviewer Agent
       ^                                        |
       +------------ Review Result -------------+
       v
Generator Agent 修正并输出新版本

其中，Generator 负责提出方案或生成初稿，Critic / Reviewer 负责检查问题并给出反馈，再由 Generator 进行针对性修正。当存在多个持不同视角的 Agent 时，还可以演进为 Debate（多方辩论）模式，通过多轮交叉讨论来比较不同的推理路径。

适用场景：代码生成与审查、架构设计论证、复杂方案合规校验等对产出质量要求较高的任务。
工程前提：使用该模式有一个关键前提——评审方必须能够提供真正独立的信息或验证手段（例如挂载独立的检索数据源、代码编译或静态检查工具）。如果两个 Agent 使用完全相同的模型、相同的数据和相同的错误假设，多轮讨论仍然可能达成错误共识。因此，该模式通常需要结合确定性的验证工具与明确的最大迭代轮次限制。

7.3 Ensemble（集成求解与结果聚合模式）

Ensemble 模式的思路不是让多个 Agent 分工完成不同的子任务，而是让多个 Agent 独立求解同一个问题，再对结果进行比对与聚合：

               Same Task
                  |
        +---------+---------+
        |         |         |
      Agent A   Agent B   Agent C
        |         |         |
        +---------+---------+
                  |
              Aggregator
                  |
                  v
                Result

多个 Agent 可以采用不同的底层模型、不同的检索策略或不同的推理路径；随后由聚合器（Aggregator）比较各方输出，选择一致结论、最优方案，或者对存在分歧的部分触发进一步核实。

适用场景：复杂逻辑推理、高风险决策判断以及多方案比选。
工程权衡：Ensemble 需要付出成倍的 Token、计算资源和延迟成本。同时需要注意，简单的“多数投票（Majority Voting）”并不天然等于正确——如果各个 Agent 依赖相同的错误前提，它们的错误往往是高度相关的。因此，Ensemble 更适合作为关键节点提高可靠性的辅助策略，而非通用的默认调用方式。

7.4 FSM / Graph（状态机与确定性图编排模式）

Graph 模式将复杂任务组织成具有明确状态定义和路由关系的执行图：

        Input
          |
          v
     Intent Agent
          |
          v
     State Router
       /       \
      v         v
  Billing     Policy
   Agent       Agent
      \         /
       v       v
       Validation
           |
           v
         Output

在执行图中，每个节点既可以执行一个普通工具或确定性程序，也可以运行一个拥有自主 Loop 的 Agent；而节点之间的流转方向，则由固定规则或基于状态的条件分支来决定。

适用场景：业务规则清晰、需要严格审计，或者对执行路径有明确合规约束的企业级应用（如金融审批、标准客服流程）。
工程价值：引入 Graph 并不意味着所有步骤都被僵化固定。例如 LangGraph 的 Orchestrator-Worker 模式允许协调节点在运行过程中动态生成子任务，同时整体执行过程仍然受状态图管理。它的核心价值在于将可确定的流程控制逻辑显式表达出来，而不必把所有路由判断都交给语言模型。

7.5 Contract Net（契约网：动态协商与任务分配模式）

Contract Net Protocol（契约网协议）源自 Reid G. Smith 于 1980 年提出的分布式问题求解机制。它通过“任务公告 — 候选节点投标 — 择优授标”的流程来实现动态任务分配：

Task Announcement (发布任务需求)
        |
        v
   Candidate Agents
      /   |   \
     A    B    C
      \   |   /
     Bids (返回响应与报价)
         |
         v
   Agent Selection
         |
         v
      Execution

在这种模式下，调用方不再直接指定某个固定的子 Agent，而是发布任务需求描述；各个候选 Agent 根据自身能力、当前可用资源或执行成本进行响应，最终由系统选择合适的执行者建立委派契约。

适用场景：大规模开放 Agent 网络、跨组织协作以及需要动态调度异构资源的场景。
工程建议：对于 Agent 数量有限、能力边界明确的企业内部系统，直接基于服务注册表和路由策略进行匹配通常更加简单直接。Contract Net 并不是构建多 Agent 系统的必备前提，而是一种面向动态发现与资源竞争场景的分配机制。

7.6 这些协作模式之间是什么关系？

在实际系统设计中，上述五种扩展模式与前文介绍的三种基础协同方式（Delegation、Handoff、Async）并不是非此即彼的替代关系，而是可以根据业务需求进行灵活组合：

Generator-Critic 的迭代过程可以通过 Graph 状态机进行编排；
Ensemble 可以通过 异步 Delegation 并行启动多个求解 Agent；
Blackboard 可以结合事件驱动机制来组织多角色协同；
Contract Net 可以用于动态选择 Delegation 的目标 Agent。

模式	核心特点	更适合的场景
Blackboard（黑板模式）	围绕共享状态读写协作	开放式探索、复杂知识协同构建
Generator-Critic（生成-评审）	生成、检查与修正闭环	代码审查、复杂方案验证
Ensemble（集成求解）	多路独立求解与结果聚合	多方案比较、高价值决策交叉验证
FSM / Graph（状态机图编排）	显式状态管理与确定性流程控制	企业标准 SOP、强合规约束流程
Contract Net（契约网协议）	动态协商与竞标式任务分配	开放 Agent 网络、动态资源调度

对于大多数企业应用而言，Delegation、Handoff 与异步执行仍然是值得优先掌握和落地的基础协同机制；上述五种扩展模式则可以根据任务的探索性、质量要求、流程确定性和 Agent 规模逐步按需引入。

无论采用哪种模式，系统最终都需要回答相似的底层工程问题：任务与状态如何关联？结构化结果如何保真交付？权限如何控制？发生故障后如何恢复？区别仅在于，不同模式对集中式控制、共享状态和事件协调的依赖程度有所不同。

八、结语：从 Agent Calling 走向 Agent Collaboration

回顾全文的分析，多 Agent 系统的演进可以从三个递进的层次来理解：

第一层是 Agent Calling（智能体调用）：一个 Agent 能够把另一个 Agent 当作工具调用，后者完成任务并返回文本结果。这是最基础的多 Agent 形态，也是许多早期系统采用的实现方式。
第二层是 Agent Collaboration（智能体协作）：多个 Agent 不再只是简单的同步调用关系，而是能够委派任务、转移交互控制权、异步并行执行、按引用共享业务数据、发起人工介入请求，并根据中间结果动态调整协作策略。
第三层是 Multi-Agent Runtime（多智能体运行时工程化）：当协作进入生产环境，系统需要将控制权归属、任务身份（Session / Run / Invocation）、过程事件（Event）、结构化产物（Artifact）以及超时、取消和故障补偿转化为明确的执行契约，从而让多个自主 Agent 在可靠的运行机制下协同工作。

在这一演进过程中，最关键的架构平衡在于：如果把所有任务规划和协作策略都固定在 Runtime 流程里，系统就会退化成传统的工作流，失去 Agent 处理开放性任务的优势；但如果把所有协调、状态同步和故障处理都交给大模型的 Prompt 去维持，又很难获得生产环境所需的确定性保障。

因此，更合理的工程方向是明确各自的边界：

由 Agent Loop 负责局部的自主推理与决策，由协作协议定义控制权流转与信息交换方式，由 Multi-Agent Runtime 提供确定性的执行保障，由业务系统负责领域规则约束与外部副作用管理。

对于简单任务，这可能只是一次普通的子 Agent 调用；对于复杂任务，它则可以自然演进为异步协同、持续会话、跨进程委派乃至多 Agent 共享工作空间。

真正决定一个多 Agent 系统生产可靠性的，从来不是系统中启动了多少个 Agent，也不是堆砌了多少种复杂的编排概念，而是当多个拥有独立 Agent Loop 的执行体协同工作时，系统是否为它们建立了一套清晰的控制权、生命周期、状态管理与结果交付契约，并在保障工程确定性的同时，保留好每个 Agent 必要的自主性。

参考资料

Agent2Agent (A2A) Protocol Specification — 关于 Task、Message、Artifact、生命周期和流式通信模型的协议规范： https://a2a-protocol.org/v1.0.1/specification/
Microsoft Agent Framework — Workflow Orchestrations — Sequential、Concurrent、Handoff、Group Chat、Magentic 等多 Agent 编排方式： https://learn.microsoft.com/agent-framework/workflows/orchestrations/
LangGraph — Workflows and Agents — Workflow 与动态 Agent、Orchestrator-Worker 模式、状态管理与持久化： https://github.com/langchain-ai/docs/blob/main/src/oss/langgraph/workflows-agents.mdx
Reid G. Smith (1980), The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computers, C-29(12), 1104–1113： https://doi.org/10.1109/TC.1980.1675516
OpenCode — Agents — Primary Agent、Subagent 及任务委派的实现参考： https://opencode.ai/docs/agents/

(注：本文中的 Runtime、Invocation 和协作状态模型为通用工程抽象，不代表上述框架全部采用相同命名或提供相同实现保证。)