上一篇介绍了 Routing（路由模式），主要解决不同类型的请求应该进入哪条处理路径。本篇继续讨论另一种常见的任务编排方式——Parallelization（并行化模式）。

在实际 Agent 应用中，一个复杂任务往往包含多个相互独立的子任务。例如，分析一批采购合同，可能需要分别检查付款条款、违约责任和解除条件；生成项目报告时，可能需要同时查询项目进度、预算和历史资料。如果所有子任务都按照顺序执行，即使它们之间没有直接依赖，也必须等待前一个任务完成以后才能开始下一个任务。当每个子任务都需要调用 LLM、RAG 或外部 API 时，这种串行执行会带来不必要的等待。

Parallelization 的基本思路，就是识别任务之间的依赖关系，将可以独立执行的部分并发处理，再将各分支的结果统一汇总。但并行化并不只是将多个模型调用放进线程池。真正进入生产系统后，还需要解决**任务拆分、上下文隔离、并发限制、超时与部分失败、结果一致性以及成本控制**等问题。

## 一、Parallelization 的基本原理

Parallelization 通常采用 **Fan-out / Fan-in** 结构。Fan-out 负责将任务分发到多个并发分支，Fan-in 则负责等待必要结果、合并数据并继续后续处理。

例如，在采购合同分析任务中，系统可以先完成文档解析，再分别检查不同类型的合同条款。三个检查分支不必相互等待，但最终报告必须综合这些结果，并检查不同条款之间是否存在关联或冲突。

![](https://developer.qcloudimg.com/http-save/yehe-12085712/91526f2500287e16674dda176349f559.png)

这与前面介绍的 Prompt Chaining、Routing 存在明显区别。

| 模式 | 核心问题 | 典型执行方式 |
| --- | --- | --- |
| Prompt Chaining | 多个步骤如何顺序执行 | A 完成后执行 B |
| Routing | 当前任务应该选择哪条路径 | A 或 B 或 C |
| Parallelization | 独立任务如何同时执行 | A、B、C 并发，随后合并 |
| Planning | 复杂目标如何拆解并协调依赖 | 动态生成和调整任务计划 |

这些模式可以组合。例如，Routing 先识别合同分析任务，Planning 或规则负责确定分析维度，Parallelization 并发执行独立检查，最终通过 Prompt Chaining 完成结果校验与报告生成。因此，并行化并不是一种独立于其他模式的 Agent 类型，而是一种可以嵌入 Workflow 或 Agent Runtime 的执行策略。

## 二、并行任务的拆分方式

在实现并行执行之前，首先需要判断哪些任务真正相互独立。并不是所有步骤都适合并行。例如，必须先解析文档才能分析条款，必须先获得分析结果才能生成最终建议。这些步骤存在明确的数据依赖，不能简单同时执行。更适合并行的是没有直接依赖、可以基于同一份已准备数据独立完成的子任务。

目前常见的并行化方式主要有两种。

**1\. Sectioning：不同子任务并发执行**

Sectioning 将复杂任务拆成多个职责不同、可以独立处理的部分。例如，合同分析可以分别执行付款条款检查、违约责任分析和解除条件检查；项目报告可以同时获取进度、预算和风险数据。

这种方式主要用于减少任务的整体等待时间。

**2\. Voting：同一任务进行多视角分析**

Voting 则让多个模型调用处理同一个问题，或者从不同评价维度给出独立结果，再进行综合判断。例如，对一份需求文档分别检查完整性、可测试性和一致性；或者使用不同的提示策略独立审查同一项风险。

这种方式更偏向提高分析覆盖率和结果可靠性，而不是单纯减少延迟。

但需要注意：**多个模型给出相同结论，并不意味着结论一定正确。** 如果所有分支使用相同的错误来源，或者受到相似的 Prompt 偏差影响，并行执行也可能产生一致的错误。因此，对于企业文档、合同和财务等场景，最终仍然需要验证证据来源，而不是简单采用多数投票。

## 三、实践案例：采购合同的并行分析

假设用户上传一批采购合同，要求检查其中的付款、违约和合同解除条款，并生成风险分析报告。首先由文档解析服务完成文本提取、表格处理和章节识别，形成统一的结构化文档对象。然后将任务拆成三个分析维度。

| 并行分支 | 主要任务 | 输出结果 |
| --- | --- | --- |
| Payment Analysis | 检查付款条件、期限和金额约束 | PaymentFindings |
| Penalty Analysis | 检查违约责任及相关约束 | PenaltyFindings |
| Termination Analysis | 检查解除条件和终止责任 | TerminationFindings |

每个分支只接收当前分析所需的资料和任务说明，并返回结构化结果。例如：

```bash
{
  "dimension": "PAYMENT",
  "status": "SUCCESS",
  "findings": [
    {
      "description": "付款时间未明确约定",
      "evidenceId": "doc-01-section-5"
    }
  ]
}
```

这里的 `evidenceId` 应指向真实文档中的章节或片段，避免在后续汇总过程中丢失证据来源。三个分支执行结束后，由统一的汇总节点检查结果完整性，关联重复问题，识别不同条款之间可能存在的冲突，最终生成完整报告。例如付款条件与违约责任可能存在关联，某项付款期限是否合理，可能需要结合合同中约定的违约责任判断。

因此：**并行分支可以独立执行，但最终结果不能只做简单拼接。**汇总节点仍然需要执行跨分支检查，这是 Parallelization 能否真正落地的重要环节。

## 四、Java 中的并行执行实现

这里继续采用 Java 展示核心逻辑，不绑定具体 Agent Framework，也不展开模型 SDK 的实现。首先定义每个分析分支的统一输出：

```bash
record Finding(
    String description,
    String evidenceId
) {}

record AnalysisResult(
    String dimension,
    List<Finding> findings,
    boolean success
) {
    static AnalysisResult failed(String dimension) {
        return new AnalysisResult(
            dimension, List.of(), false
        );
    }
}
```

各分支通过同一个接口执行：

```bash
interface AnalysisWorker {
    AnalysisResult analyze(
        String documentId,
        String dimension
    );
}
```

接下来使用 `CompletableFuture` 并发运行三个任务：

```bash
List<AnalysisResult> analyzeParallel(
        String documentId,
        AnalysisWorker worker) {

    List<String> dimensions = List.of(
        "PAYMENT", "PENALTY", "TERMINATION"
    );

    ExecutorService pool =
        Executors.newFixedThreadPool(3);

    try {
        var futures = dimensions.stream()
            .map(d -> CompletableFuture
                .supplyAsync(
                    () -> worker.analyze(documentId, d),
                    pool
                )
                .completeOnTimeout(
                    AnalysisResult.failed(d),
                    30, TimeUnit.SECONDS
                )
                .exceptionally(
                    ex -> AnalysisResult.failed(d)
                )
            )
            .toList();

        return futures.stream()
            .map(CompletableFuture::join)
            .toList();

    } finally {
        pool.shutdown();
    }
}
```

这段代码只表达几个核心动作：构建并发任务、执行分析、收集结果，以及将超时或异常转换为明确的失败状态。`completeOnTimeout()` 只是让等待中的 Future 按时返回默认结果，**并不保证底层正在执行的模型请求已经被取消**。正式项目还需要在模型客户端设置请求超时、控制资源占用，并实现必要的取消和清理机制。这里也没有把多个 `AnalysisResult` 直接合并成报告，因为结果汇总仍然需要独立的业务检查。

对于 Java 21 及以上环境，也可以根据项目需要使用虚拟线程处理大量 I/O 型任务；但虚拟线程主要改善线程资源占用，并不会自动提高模型服务的并发配额。这一点很重要：**Java 的并发能力，不等于外部 LLM API 可以无限并发。**无论使用 CompletableFuture、虚拟线程还是 Agent Framework，都必须遵守外部模型服务和业务系统的并发限制。

## 五、并发控制与资源管理

简单 Demo 可以同时启动三个任务，但真实项目可能一次需要分析几十份甚至上百份文档。如果每份文档都拆成多个模型调用，未经限制的 Fan-out 很容易造成：

-   模型 API 限流或并发配额耗尽；
    
-   Token 和推理费用快速增加；
    
-   内存、线程或连接池资源不足；
    
-   下游数据库或文件服务被大量请求压垮；
    
-   某些任务长期排队，整体延迟上升。
    

因此生产系统需要引入有界并发。例如：

```bash
Max Concurrency = 5
Queue Capacity = 100
Request Timeout = 30s
```

这些只是示例配置，实际参数应根据服务配额、平均耗时和业务负载确定。

| 控制机制 | 主要作用 |
| --- | --- |
| Concurrency Limit | 限制同时执行的任务数量 |
| Rate Limit | 控制单位时间内的模型请求 |
| Queue / Backpressure | 避免请求高峰造成资源耗尽 |
| Timeout | 防止异常分支长期占用资源 |
| Retry Budget | 限制失败后的额外调用 |
| Cancellation | 任务终止时释放不再需要的资源 |
| Token / Cost Budget | 限制单次任务的模型消耗 |

这里需要特别区分并发数和请求速率。即使当前只有少量任务在并发执行，如果每个任务内部不断调用模型，也可能超过 API 的单位时间请求限制。因此，并发控制通常需要放在统一的 Model Gateway 或执行调度层，而不能只依赖每个 Agent 自己的线程池。

## 六、部分失败与结果汇总

Parallelization 比串行流程更复杂的地方，在于多个分支可能出现不同的执行结果。例如三个合同分析任务中，付款和违约检查成功，解除条件检查超时。系统应该直接判定整个任务失败，还是允许生成部分报告？这取决于业务要求，而不是并发框架本身。常见策略如下：

| 汇总策略 | 适用场景 | 处理方式 |
| --- | --- | --- |
| All Success | 所有结果都必须完整 | 任一关键分支失败则任务失败 |
| Partial Result | 允许返回不完整信息 | 标记失败分支并返回部分结果 |
| Retry Failed | 部分分支可独立重试 | 只重试失败任务 |
| Fallback | 存在可替代能力 | 使用备用模型或其他数据源 |
| Quorum | 可接受部分有效结果 | 满足预设数量后继续 |

其中 Quorum 更适用于独立重复评估或具有明确容错规则的场景，不适合简单用“多数成功”代替缺失的业务事实。对于合同风险分析，更推荐的方式是：保留成功分支的结果，对失败分支进行有限重试；如果仍然无法完成，应明确标记分析未覆盖的内容，而不是将部分报告伪装成完整结论。

**结果汇总不能只依赖 LLM**

多个分支返回的结果首先应该由程序完成基础整理，包括结果状态检查、按任务标识归集、去重和来源校验。随后才根据需要调用模型进行跨分支分析和报告生成。例如：

| 汇总阶段 | 主要处理 |
| --- | --- |
| Collect | 收集并发任务结果 |
| Validate | 检查结构、任务状态和证据 |
| Deduplicate | 合并重复发现 |
| Conflict Detection | 识别不同分支间的矛盾 |
| Synthesis | 生成综合结论和报告 |

如果把这几个环节全部交给一个 Prompt，模型可能忽略某个失败分支，或者将不同来源的信息混合成无法追溯的结论。因此，结果汇总同样应该遵循前面 Structured Output 和 Prompt Chaining 中的原则：**确定性校验由程序处理，复杂语义整合由模型完成。**

## 七、2026 年并行 Agent 的技术进展

过去 Parallelization 主要表现为多个模型 API 的并发调用。随着 Agent Runtime 和 Harness 的发展，现在已经进一步扩展到动态任务分发、上下文隔离以及长期异步 Worker。

### LangGraph：动态 Fan-out 与 Reducer

LangGraph 支持通过普通 Graph Edge 组织多个并行节点，也可以使用 `Send` 动态创建任务。例如，系统只有在解析文档后才知道存在多少合同、多少章节或多少待检查项目，此时可以根据实际数据动态分发多个分析任务，而不是预先写死 Worker 数量。在结果汇总时，LangGraph 通过 Reducer 合并多个并行节点写入的 State。这意味着 Fan-out / Fan-in 已经不只是线程并发，而是成为 State Graph 中可以明确建模的执行结构。

### OpenAI：并行 Subagent 与执行编排

OpenAI Agents SDK 支持开发者使用 `asyncio.gather` 等语言原生并发机制，同时运行多个独立 Agent。这类实现适合任务边界明确、开发者希望自行控制分发与结果收集的场景。2026 年推出的 Agents API 进一步提供托管式多 Agent 能力，可以让主 Agent 将独立工作分配给多个 Subagent，每个 Subagent 维护自己的执行上下文，再由主 Agent 负责汇总。这一能力目前仍应根据对应 API 和模型的支持范围使用，不应假设所有模型和运行环境都具备完全一致的并行能力。

### LangChain Deep Agents：异步 Subagent

2026 年 11 月 5 日，LangChain 发布了《Agents Are Going Async》，进一步介绍异步 Subagent 的设计。传统并行模式通常是主流程一次发起多个任务，然后等待全部结果返回。异步 Subagent 则允许主 Agent 启动后台任务后立即获得任务标识，继续与用户交互，并根据需要查看进度、调整任务或取消执行。后台任务完成后，再将结果报告给主 Agent。这将并行化从“同一批任务的并发执行”扩展到了“长期运行的异步任务协调”。

### DeepSeek Super-agent：跨任务持续并发

前面刚刚介绍的 DeepSeek Super-agent 同样采用 Router / Worker 双层结构。但它与本篇讨论的普通 Parallelization 存在区别。普通并行化通常围绕**一次用户请求**拆出多个子任务，执行结束后进行汇总；Super-agent 则面向多个持续存在的任务，通过 Router 分派给不同 Worker，并结合事件、Ticket 和 Session 长期跟踪。因此，Super-agent 更接近在并行执行基础上增加持续任务调度，而不是单纯的 Fan-out / Fan-in。

这一趋势说明，Agent 并发已经从普通 API 调用层，逐渐向 Runtime 和任务管理层扩展。

## 八、性能收益与成本评估

Parallelization 最直接的收益是缩短任务的关键路径。如果三个独立任务顺序执行，总耗时主要由三个任务的耗时累加构成；并行执行以后，理想情况下主要受最慢分支和结果汇总耗时影响。但这里存在几个限制。

首先，任务中仍然可能存在不可并行的部分，例如文档解析和最终报告生成。即使中间分析完全并行，这些串行阶段仍然决定整体耗时下限。

其次，并行化可能增加模型调用成本。三个任务同时执行，并不意味着总 Token 消耗减少，只是部分调用发生在相同的时间窗口。

另外，任务拆分过细可能带来额外 Prompt、上下文重复发送、结果协调和模型检查开销，最终抵消并发收益。

因此建议从以下指标评价并行化效果：

| 指标 | 主要观察内容 |
| --- | --- |
| End-to-End Latency | 整个任务的实际完成时间 |
| Critical Path | 最长依赖路径的耗时 |
| Branch Success Rate | 各并发分支的成功率 |
| Partial Failure Rate | 出现部分失败的比例 |
| Token / Cost | 模型调用及总费用 |
| Queue Waiting Time | 任务等待执行的时间 |
| Merge Quality | 汇总结果是否完整、一致、有证据 |
| Resource Utilization | 并发资源是否有效利用 |

例如，将一批合同分析任务从串行改为并发执行以后，需要比较的不是模型调用数量，而是整体报告的完成时间、内容质量、失败率和总成本。如果并行化只减少少量延迟，却显著增加费用、错误和维护难度，就应重新评估任务拆分粒度。

## 九、Parallelization 的适用边界

并不是所有复杂任务都适合并行。如果后一个步骤必须依赖前一个步骤的完整结果，使用 Prompt Chaining 更合适；如果需要根据请求类型选择执行路径，应该优先使用 Routing；如果任务依赖关系会随着执行过程变化，则可以结合 Planning 和 State Machine。可以通过一个简单的原则判断：**能明确划分独立输入、独立执行和独立输出的子任务，通常才适合并发处理。**

| 任务特点 | 更合适的执行方式 |
| --- | --- |
| 明确的顺序依赖 | Prompt Chaining |
| 多种互斥处理路径 | Routing |
| 多个独立分析任务 | Parallelization |
| 动态产生大量子任务 | Dynamic Fan-out / Map-Reduce |
| 长时间后台任务 | Async Worker / Durable Runtime |
| 任务间存在复杂依赖 | Planning + State Machine |
| 需要专业 Agent 分工 | Multi-Agent，按需并行 |

同时，不应将“并行工具调用”直接等同于“多 Agent”。如果任务只是并发查询三个业务 API，使用普通异步函数就足够；只有当不同分支确实需要独立的模型决策、工具循环或上下文时，拆分多个 Agent 才更有意义。

## 十、本篇小结

Parallelization 模式通过 Fan-out / Fan-in 将相互独立的任务并发执行，再统一收集和汇总结果，是 Agent 工作流中常用的一种性能与任务组织优化方式。与前面介绍的 Prompt Chaining 和 Routing 相比，它主要解决的是多个任务的执行依赖和并发关系，而不是任务顺序或路径选择。

在工程实现中，并行化真正需要关注的并不只是线程或模型调用，而是**任务拆分、上下文隔离、并发限制、部分失败处理、结构化结果合并与成本评估**。

随着 LangGraph 的动态任务分发、OpenAI 并行 Subagent、LangChain 异步 Subagent 和 DeepSeek Super-agent 等技术的发展，并行化也正在从单次请求中的并发调用，逐渐扩展到长期运行的任务调度与协调。但基本原则没有改变：**只有相互独立的任务才值得并发；并发结果必须经过统一校验和汇总；模型的执行能力不能替代程序对并发、资源和失败的控制。**

**上一篇回顾：**

[【第四部分：Agentic 智能体设计模式】17. Agent 路由模式详解：从意图识别到动态模型选择-腾讯云开发者社区-腾讯云](https://cloud.tencent.com.cn/developer/article/2773682)

**下一篇：** **Reflection（反思模式）——基于结果检查的迭代修订**。

Parallelization 解决了多个独立任务如何同时执行，而 Reflection 将进一步讨论模型生成结果以后，如何通过独立检查、反馈和有限次数修改来提高结果质量。

上一篇介绍了 Routing（路由模式），主要解决不同类型的请求应该进入哪条处理路径。本篇继续讨论另一种常见的任务编排方式——Parallelization（并行化模式）。

【第四部分：Agentic 智能体设计模式】18.Agent 并行化实战：任务拆分、并发执行与结果汇总

本文介绍 Agent 并行化模式，结合合同分析和 Java 示例，讲解 Fan-out / Fan-in、并发控制、部分失败及结果汇总，并结合 LangGraph、OpenAI 和 DeepSeek 等技术实践，分析并行执行的性能收益、成本与适用场景。

人工智能

架构设计

后端

Parallelization模式通过Fan-out/Fan-in结构并发执行独立子任务，显著缩短任务关键路径。适用于合同分析、项目报告等可拆分场景，需关注任务拆分、上下文隔离、并发限制、部分失败处理和成本控制。实际收益应通过端到端延迟、分支成功率、Token消耗等指标评估，避免因过度拆分增加成本和维护难度。

代码解释

LangGraph

数据库

LangChain

智能体

路由

Agent

Java

腾讯云双十一大促

mmdp

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【第四部分：Agentic 智能体设计模式】18.Agent 并行化实战：任务拆分、并发执行与结果汇总-腾讯云开发者社区-腾讯云

【第四部分：Agentic 智能体设计模式】18.Agent 并行化实战：任务拆分、并发执行与结果汇总

【第四部分：Agentic 智能体设计模式】18.Agent 并行化实战：任务拆分、并发执行与结果汇总

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐