做Agent开发时间久了你会发现一个特别有意思的现象单跑一个Agent逻辑再怎么复杂顶多就是慢一点一旦要让Agent去处理真实业务里的多来源信息、多角色协作、多步骤产出最先炸掉的永远不是模型能力而是任务流程的编排方式。我最初看到“智能体21种设计模式”这份清单时对第三项“并行化”其实没太当回事因为并行这个概念在计算机领域太老熟了多线程、多进程、异步IO哪一样不是并行后来自己实现了一个多Agent文档调研系统才意识到这里的“并行化”和操作系统里说的并行完全是两码事它特指把一个复杂任务拆成多个互不依赖的子任务同时交给多个智能体实例去执行最后再汇总结果。这种模式解决的不只是速度问题还直接影响产出质量和大模型的稳定性。这篇文章我就围绕并行化模式把设计动机、适用场景、落地架构、代码实现和实战踩坑一次讲透。内容全部来自我实际跑过的几个项目不是教科书定义可能比概念更粗暴直接一点但保证能直接用到你的Agent工程里。1. 并行化模式是什么为什么能进设计模式清单1.1 从“一个Agent干完”到“多个Agent分头干”如果你之前只做过Demo级别的Agent体验往往是这样的给Agent一个目标它自己规划、调用工具、读文档、总结整个链路是一条线每个环节都要等一次大模型返回。比如让Agent“总结三份PDF并对比差异”它的做法通常是先读PDF A等模型输出摘要再读PDF B等模型输出摘要再读PDF C等模型输出摘要最后汇总对比。每一步的等待时间线性叠加如果每份PDF处理要30秒三份就是90秒中间完全没有任何“复用”或者“缩短”的机会。并行化模式做的事很简单把“总结PDF A、总结PDF B、总结PDF C”这三个子任务拆开同时发起三个独立的Agent调用让它们各自处理一份PDF等三个结果都回来后再做一次汇总。如果原来的串行是90秒并发三个任务后理想情况只需要花费最慢那个任务的耗时加汇总耗时比如35秒。这不是某个框架的优化技巧而是智能体应用里一种可复用的结构方案所以它值得被列为一种设计模式。这个模式为什么需要被单独提炼出来因为在LLM场景里并行不是简单地把代码从“for循环”改成“多线程”就完事。你要额外处理任务拆解、结果合并、上下文隔离、并发限流、失败重试、汇总一致性这些问题。可以说并行化的复杂性主要不在“并行本身”而在“并行之后怎么把结果收拢好”。1.2 并行化到底解决了哪些单靠“聪明”解决不了的问题先说速度。LLM API调用有固定的延迟开销这个延迟主要由模型推理时间决定本地再怎么优化代码也无济于事。串行情况下N个独立子任务的总延迟就是N乘以单任务延迟并行情况下总延迟接近最慢子任务的延迟。对于真实产品来说用户等待从几十秒变成几秒体验是质变。再说质量。当你让同一个Agent按顺序处理多个不同任务时它会受到前面任务的上下文污染。比如你先让Agent读A材料它记住了A里的细节再让它读B材料时它可能会不自觉地把A的细节混进B的总结里。但如果你开启三个独立的Agent实例每个实例只携带自己的那部分上下文互相之间物理隔离产出的纯度就高很多。这一点我后面会重点讲很多人并行化翻车就翻在这里。第三个价值是视角多样性。同一个问题你可以让多个Agent用不同角色、不同prompt、不同temperature去回答再综合评比。这是串行很难做到的——串行情况下你只能得到一次生成的视角并行化可以一下子生成多个候选答案然后择优或融合。这样能明显降低单次大模型生成的随机性和偏差类似集体投票优于单人判断。2. 哪些场景适合并行化哪些场景硬上会翻车2.1 判断任务可并行化的一条黄金法则我自己的判断标准特别简单看看子任务之间有没有“必须等待对方结果”的依赖关系。如果没有数据依赖且每个子任务可以用独立的输入和独立的prompt描述清楚那就可以并行。如果有依赖比如第二步需要第一步的结论才能继续那就老老实实串行或者试试后面的“规划-执行”模式而不是强行并行。举几个我实践过觉得特别适合并行化的场景多源信息收集与摘要。比如给Agent十个网页链接让它提取每个网页的核心观点。这十个网页互不相关天然可以并行。多角色评审与反馈。同样的文档分别让一个“法律专家Agent”、一个“财务Agent”、一个“技术架构Agent”去审查让它们各自输出意见最后汇总成一份综合审查报告。长文本的分块处理。一份100页的合同切成10块每块并行做实体抽取、关键条款标注再合并成一张完整表。多方案生成与评估。让Agent同时生成5种不同的营销文案然后再用一个评估Agent从中选出最优的或者把5份融合成一份更全面的。竞速取优。同一个任务用不同的模型或者不同的temperature配置并行跑拿结果质量更好的那一个。这种情况在评测开源模型时特别好用。不适合并行化的情况也很典型子任务之间有强依赖链。例如“先做市场调研再根据调研结果写策略”调研结果是策略的输入必须串行。需要维护一个全局一致的上下文。比如写一篇长篇小说你不可能让10个Agent各写一章再拼一起除非SoD境界设定写得极其严格否则风格、伏笔、人物关系一定乱。共享可变状态的任务。多个Agent同时往同一个数据库记录写数据不做并发控制轻则覆盖重则锁表。对成本极度敏感的项目。并行会成倍放大token消耗因为每个子任务都有自己的上下文窗口和Prompt开销。如果业务本身利润极薄并行省下来的那几秒钟可能不值得多付几倍API费用。2.2 并行化与“串行”的边界不能只看速度很多人一开始会觉得“既然并行省时间那我是不是所有任务都该并行”我的体验完全相反。并行化有一个隐藏成本合并结果的token消耗和出错率。每个子任务带回来一段长长的产物汇总Agent要把这些产物读一遍、去重、整合、评判这个过程本身可能需要一次很长的LLM调用消耗大量token而且如果子任务产出的格式不统一汇总阶段的模型非常容易犯迷糊甚至漏掉某些子结果。所以我在架构上有个习惯先看任务结构和质量需求再看时间需求。如果是强依赖链即使每一步都很快也不能并行如果任务可拆分但合并成本太高那不如少拆几块或者用更结构化的输出格式来降低合并难度。并行化不是银弹它更像是一门“用资源换时间、用隔离换质量”的权衡艺术。3. 并行化模式的落地实现从架构设计到代码细节3.1 核心架构Fan-out / Fan-in 以及协调者并行化模式在工程上最常见的形态是Fan-out扇出和Fan-in扇入。我把它拆成这样看Fan-out阶段主任务或者一个协调者Orchestrator根据任务的输入把任务分解成多个子任务并给每个子任务分配一套独立的Agent实例、独立prompt、独立输入数据。这个协调者可以是一个“主智能体”也可以是一段固定的逻辑代码看可预见性需求。如果子任务的分解规则很固定例如固定分10段处理我习惯用代码写死不要交给LLM去拆分因为LLM拆分不稳定如果子任务本身是开放式的比如“去调研三个不同方向”那我就让主Agent来拆分。Fan-in阶段所有子任务完成后把它们的输出收集起来交给一个汇总智能体或者一段后处理脚本做去重、排序、合并、校验最后形成整体的产出。Fan-in同样可以选择是LLM还是代码。我的经验是如果子任务的输出是结构化JSON例如都返回“{ “问题”: xx, “风险”: xx }”那么用代码做基础合并只把真正需要语义理解的部分交给LLM比如“综合这些风险给出优先级排名”这样最稳定token也最省。3.2 并发控制不是开得越多越快如果之前没碰过API限流第一次做并行化的人很容易一股脑把并发数量调到20甚至50。结果就是LLM服务商给你返回一大堆429或者连接超时跑得比串行还慢。我强烈建议在代码里引入信号量Semaphore来控制并发数。具体数值没有绝对标准取决于你用的API限流和单请求耗时。一般先从3到5开始观察请求失败率和平均耗时再逐步往上加。我自己在实际项目中稳定跑过并发8到10但这是在限流很宽的前提下。如果API的限流是每分钟600次请求而你一次任务就要发几百个子任务那并发数得配合限流动态调整甚至要用到令牌桶算法。下面是一段我用Python asyncio实现并行化核心逻辑的骨架可以当成一个通用模板来用import asyncio import random async def run_sub_agent(subtask: dict, semaphore: asyncio.Semaphore): 模拟运行一个子Agent任务注意Semaphore限制并发数 async with semaphore: print(f开始处理: {subtask[name]}) # 这里实际调用的是你的Agent执行函数例如 # result await agent.execute(subtask[prompt], subtask[input]) await asyncio.sleep(random.uniform(1, 3)) # 模拟LLM耗时 return { name: subtask[name], result: f{subtask[name]}的提取结果 } async def fan_out_and_fan_in(subtasks: list[dict]): semaphore asyncio.Semaphore(5) # 控制最多5个并发 tasks [run_sub_agent(st, semaphore) for st in subtasks] results await asyncio.gather(*tasks) # 等全部完成 return results async def main(): # 假设你有一个任务拆解函数把主任务拆成多个子任务 subtasks [ {name: 文档A分析, prompt: 提取文档A的预算数据, input: ...}, {name: 文档B分析, prompt: 提取文档B的预算数据, input: ...}, {name: 文档C分析, prompt: 提取文档C的预算数据, input: ...}, ] results await fan_out_and_fan_in(subtasks) # Fan-in把结果统一交给汇总智能体 # combined_prompt build_merge_prompt(results) # final_answer await merge_agent.execute(combined_prompt) if __name__ __main__: asyncio.run(main())注意这段代码只是骨架我没有把真实的Agent调用放进去。实际你需要在run_sub_agent里面调用你自己的Agent执行函数并且考虑超时、重试、错误处理。asyncio.Semaphore(5)的意义是即使你一次创建了50个子任务协程同一时刻最多只有5个在真正执行LLM请求这样可以避免瞬间打满API配额。3.3 超时与重试并行的世界里“卡死”最可怕串行任务遇到一个卡住的API调用最多就是整个流程变慢你还能直观看到它卡在哪。并行化不一样所有子任务同时跑如果某一个子任务由于网络问题长时间不返回gather会一直等下去整个流程就像死锁一样挂在那边。所以在并行化里超时设置比串行更重要。我通常的做法是给每个子任务单独设置超时比如一个子任务最多允许120秒超时就直接返回一个“超时空结果”而不是让整个任务失败。这样汇总阶段能知道这个子任务没完成可以选择重试、忽略或标记为风险点。如果用asyncio.wait可以传timeout参数同时区分完成与未完成的任务。重试方面我建议对429和5xx错误做指数退避重试比如第一次等2秒第二次等4秒第三次等8秒最多3次。重试的时候要确保子任务幂等也就是执行两次不会产生副作用对于Agent任务来说你只需要保证不会重复写入数据或者重复扣费等。3.4 上下文隔离并行化最容易翻车的隐形炸弹这个点值得单独说因为几乎所有第一次做并行化的人都会在这里栽一次。假设你有三个子Agent分别处理不同的文档如果你图省事把它们放在同一个Agent实例里顺序执行三个子任务然后再并行……不对客户端层面可以并行但Agent实例如果共享同一个历史记忆子任务A看到的上下文可能混入子任务B的历史记录。更严重的是如果你用同一个全局context对象去发并行请求多个协程同时对它做append会造成读写竞争轻则产生脏数据重则直接报错。我现在的做法是每个子任务都创建一个完全独立的Agent实例并且只给它注入该子任务需要的系统提示词、工具列表和输入数据。子任务之间不共享任何可变对象所有结果统一用返回值传递。如果确实需要共享一个数据存储比如最后要把结果写入同一个Redis那就用一个队列或专门的存储服务来异步写入绝不让多个Agent直接写同一个内存数据结构。上下文隔离还有一个好处你可以方便地调试单个子任务。哪个子Agent出错了直接看它的独立输出日志就行不用在一大堆互相干扰的上下文里捞数据。4. 实操案例并行化多文档调研与对比报告4.1 案例背景和任务定义我这边曾经帮某客户公司做过一个“竞品分析报告自动生成”的系统。需求大致是提供五家竞品的官网、新闻稿、用户评价语料系统要产出一份包含“产品功能对比、定价策略对比、用户口碑对比、风险提示”的调研报告。如果全塞给一个Agent串行处理五家公司的资料加起来有上百页等它逐篇读完再总结估计得十几分钟用户体验完全不能忍。而且五家公司的语料之间本身没有依赖很适合并行化。于是我们设计成三阶段流水线第一阶段并行拆解每个公司一个子Agent负责读取该公司的所有资料输出一个结构化JSON包含功能列表、价格信息、用户口碑关键词、风险点。第二阶段代码验收对五份JSON做格式校验如果某份为空或格式非法标记为“部分失败”后续汇总时提示。第三阶段汇总生成一个汇总Agent把五份JSON全部输入生成一份对比报告包含竞争格局分析和差异化建议。4.2 具体实施中的参数数字在参数上我们做了几件事每个子Agent的temperature设置为0.2。这是一个很值得参考的经验值提取类任务需要的是稳定和忠实不是创意所以温度要压低。如果温度太高子Agent容易把语料中的细节“自由发挥”成自己的观点后面的汇总也跟着错。每个子Agent的max_tokens设得比较充足防止长文总结到一半被截断。比如我们的资料分析任务子Agent输出通常需要2000到3000个tokenmax_tokens给到4000。并发数先设5也就是五个公司和五个子Agent正好同时跑。因为API限流不是问题所以这个并发数跑得很稳五个任务大约在同一时间结束。超时设置240秒实际上基本在每个子任务60到90秒内就能完成。如果某个子任务因为网络问题超时失败了我们会自动重试一次重试再失败就把这个公司标记为“数据缺失”汇总报告里也会注明不会让整个流程崩掉。4.3 第一次运行的观察记录让我印象最深的是第一次完整跑通时五个子Agent几乎是同时返回的。串行处理五家公司的资料至少要三百多秒而并行化方案里五个子任务合并发出去之后最慢的一个用了92秒然后汇总阶段用了大概20秒整个流程总共一百一十多秒。相比串行压缩了至少60%的时间。但这里有个非常有趣的现象单个子任务如果串行跑往往只需要四十多秒为什么并行时最慢的要92秒主要原因是并发请求到来时LLM服务端或者网关有排队所有请求都在等资源实际算力被摊薄了。这说明并行化不是线性省时间并发数过高时每个请求的延迟反而会上升所以存在一个“最优并发度”的甜点。你最好在自己的环境和限流条件下多做几组测试找到这个点而不是想当然地把并发数拉满。4.4 汇总阶段的特殊处理汇总阶段我原来也试图让LLM直接读五份原始资料但很快发现token消耗太大并且容易漏细节。改成先让子Agent压缩成结构化JSON汇总Agent只读JSON它的prompt里明确要求对比表中每一个功能点都必须标明对应公司名称和数据来源不能凭空捏造遇到某公司JSON里缺失的字段显示“未获取”而不是猜测。这样产出既可靠又可追溯。我还额外做了一个“防幻觉”的小手段在汇总前用一段代码把五份JSON交叉对比如果有同一个字段多个公司都是“未获取”就不让LLM把这一行写得太绝对而是备注为“未获取到可比信息”。这个方法简单但非常管用显著降低了报告里的幻觉率。5. 常见问题与排查技巧实录5.1 高频问题速查表为了让你实际排查方便我把做并行化项目时遇到过的各类问题整理成了表格。这些问题出现的频率极高基本每个项目都会踩一到两个问题现象常见原因排查与解法调用API频繁返回429并发数超过服务商限流降低信号量值增加指数退避重试观察限流头信息多个子Agent结果互相“串味”子任务共享了同一个context或记忆每个子任务独立Agent实例独立上下文快照汇总报告遗漏某个子任务的结果Fan-in阶段prompt太宽松模型跳过了某块用代码把结构化JSON拼接好再给汇总Agent填表并行跑着跑着整个进程卡死某个子任务超时未返回gather无限等待给子任务单独设置超时用asyncio.wait处理未完成任务token成本比预想高很多并行任务各自都有较大的系统提示和上下文精简系统prompt只保留当前子任务必需的工具描述多个Agent同时写同一个数据库出现脏数据共享可变状态改为由协调者统一收集结果后再串行写库或写队列有些子任务结果互相矛盾不同Agent视角或输入范围不同在合并阶段增加矛盾检测步骤LLM判断或代码对比后高亮5.2 我亲历过的三个“反常识”坑第一个坑是并发数增加后整体成功率反而下降。有次我把并发数从5调到了10原本以为效率会翻倍结果十分钟里出现了大量503和网络超时。后来看日志才发现不是所有子任务都打到同一个网关有些请求被路由到了不稳定节点。解决方案就是把并发降回7同时加上“失败自动重试”成功率立刻回到99%以上。第二个坑是子任务输出格式不稳定。一开始我让子Agent“用自然语言总结”结果五个子任务的总结风格各不相同有的用列表有的用段落有的带着个人评价。汇总Agent面对这种五颜六色的输入合并时经常把不同公司的信息张冠李戴。后来我把子Agent的prompt改成了严格JSON输出并且给了它一个非常具体的JSON模板比如字段名、嵌套结构、枚举值。从那以后汇总阶段的出错率大幅下降。这让我意识到并行化的边界不是任务怎么拆而是子任务的产出格式必须先定义清楚。第三个坑是并行化放大了Prompt设计的漏洞。串行跑的时候即使子Agent的指令写得不太清楚前面几步的错误还有机会在后面纠正。并行化一旦跑出去所有子任务都按同一套有问题的prompt执行你会一下子收到五份错误输出而且因为子任务间没有纠错机制错误会被汇总阶段放大。所以每次改prompt后我都会有意识地单独跑一个子任务看输出好不好确认没问题再跑全量并行。5.3 排查时要养成的日志习惯并行化项目调试的复杂度和串行完全不在一个量级。串行你随便print两行就能知道卡在哪并行的时候几十个任务同时刷屏根本分不清谁是谁。我现在的做法是每个子任务启动时都生成一个唯一的trace_id格式类似subtask_agentA_20250101_123456然后在所有日志和返回值里带上这个ID。汇总时如果发现某个ID缺失就能立刻定位是哪个子任务出错。同时我会把每次子任务的输入params模型、温度、max_tokens、输出、耗时、重试次数都记录成结构化日志存到本地文件或日志服务里。这个习惯帮我省了不知道多少排查时间。如果你用的是LangGraph或者类似框架它本身可能自带并行节点但这些框架通常只是帮你解决“并发”部分限流、超时、重试、上下文隔离、结果合并策略仍然需要你自己设计。我反而觉得手工用asyncio实现一遍Fan-out/Fan-in比直接用框架封装更容易理解这个模式的本质也更利于排查问题。6. 并行化模式在完整智能体体系里的位置前面讲的大部分是实现细节最后我想稍微提一下这个模式和其它设计模式的关系免得你做架构选型的时候迷失。并行化不是一个孤立技巧它通常和“规划”模式、“反思”模式、“编排”模式协同工作。比如在规划阶段主Agent把大目标分解成子任务在并行化阶段把无依赖关系的子任务并发执行在执行阶段每个子Agent可能又用到“反思”模式来迭代优化自己的输出。如果子任务之间的结果需要互相校验那可能就要引入“评审”模式。所以21种设计模式不是21个并列选项而是可以组合使用的基本构件。从项目整体来看并行化更是一种架构思想让该独立的独立该隔离的隔离该汇聚的汇聚。它迫使你把问题拆成有边界的小块还为后来的可观测性和稳定性打基础因为你不得不想清楚每一个子任务的输入输出接口。甚至可以说一个团队如果能把并行化落地扎实他们的Agent系统一般不会差到哪里去因为并行化要求你养成“契约先行的思考习惯”。我在设计新项目时会先画任务依赖图只画不输出确认哪些节点可以并行哪些必须串行然后才写代码。这个习惯是从并行化模式里养出来的也是我认为这一模式带给我个人最大的收获。最后讲一个很小的实务心得如果你第一次在项目里引入并行化别着急把所有环节都并起来。先从最稳定、最无依赖的一步开始并行比如多文档读取提取保留串行逻辑作为兜底开关。等观察几轮确认限流、超时、合并都稳定了再逐步拓展到更复杂的协作场景。我一开始就是太乐观同时并行了好几个环节结果出问题根本不知道哪里错后来老老实实一步步来反而更快。并行化这个模式说到底不是为了让你的架构看起来更“高级”而是为了让系统在复杂任务下仍然可控、可扩展、可维护。实践过几次之后你会慢慢找到那种“该并行时酣畅淋漓该串行时绝不僭越”的手感。