不是所有任务都需要多Agent。简单任务——一问一答、翻译、摘要——单Agent足够了。拆成多个反而增加复杂度和延迟。多Agent适合这些场景任务有明确的阶段性步骤、每个步骤需要不同的专业能力、步骤之间有依赖关系需要流转。你做了一个Agent让它帮你分析需求、写代码、做测试。单看每一步都不错但串起来就拉垮——它写完代码忘了需求做测试时又把代码逻辑搞混了。一个Agent干所有事注意力不够用。今天讲Agent设计模式实战系列第七篇多Agent协作。让多个Agent各管一摊配合完成复杂任务。一个Agent为什么不够用前面的系列讲了ReAct、Plan-Execute、Tool Use、RAG、Memory、Reflection。每个模式解决一个问题但都建立在单个Agent搞定一切的假设上。实际跑起来你会发现Agent的system prompt越来越长。你要它懂需求分析、会写代码、会做测试、会写文档。prompt塞了四五种角色定义模型在切换角色时表现会打折。工具列表越来越杂。分析需求的工具、写代码的工具、跑测试的工具全挂在一个Agent上。模型经常调错工具或者该用分析工具的时候去写代码了。上下文越来越乱。需求分析的结果、代码草稿、测试报告全堆在同一个对话历史里。信息一多模型就开始丢细节。根本原因一个Agent的注意力是有限的。任务越复杂它需要同时关注的东西越多出错的概率就越高。多Agent的核心思路拆。把一个大任务拆成几个小任务每个Agent只负责一块。比如根据需求生成代码这个任务拆成三步第一步需求分析Agent。读需求文档输出结构化的技术方案。第二步代码生成Agent。拿技术方案写代码。第三步代码审查Agent。检查代码有问题退回给第二步。每个Agent的prompt短、工具少、上下文干净。它只做自己擅长的事效率高很多。Spring AI 怎么实现Spring AI没有内置的多Agent框架但用ChatClient组合起来很自然。核心就是把一个Agent的输出当作下一个Agent的输入。直接看代码import org.springframework.ai.chat.client.ChatClient; import org.springframework.stereotype.Service; Service public class MultiAgentService { private final ChatClient requirementAgent; private final ChatClient codingAgent; private final ChatClient reviewAgent; public MultiAgentService(ChatClient.Builder builder) { this.requirementAgent builder .defaultSystem( 你是需求分析专家。读用户需求输出结构化技术方案。 格式功能描述、涉及模块、接口设计、边界条件。 ) .build(); this.codingAgent builder .defaultSystem( 你是Java开发专家。根据技术方案写代码。 只输出代码不解释。包含完整的类定义和方法实现。 ) .build(); this.reviewAgent builder .defaultSystem( 你是代码审查专家。检查代码的编译错误、空指针、资源泄漏。 有问题逐条列出没问题回复审查通过。 ) .build(); } public String process(String userRequirement) { // Agent 1: 需求分析 String techSpec requirementAgent.prompt() .user(userRequirement) .call() .content(); // Agent 2: 代码生成 String code codingAgent.prompt() .user(techSpec) .call() .content(); // Agent 3: 代码审查 String review reviewAgent.prompt() .user(code) .call() .content(); if (!review.contains(审查通过)) { // 有问题退回修改 code codingAgent.prompt() .user(代码\n code \n\n审查意见\n review \n\n请修正后重新输出完整代码。) .call() .content(); } return code; } }三个Agent三个system prompt各管一摊。process方法就是流水线需求分析→代码生成→代码审查→有问题退回。每个Agent看到的上下文很干净。需求分析Agent只看到用户需求不会被代码干扰。代码生成Agent只看到技术方案不会被需求分析的过程干扰。审查Agent只看到代码不会被技术方案干扰。三种常见的协作模式上面是顺序模式最简单。实际项目还有另外两种。并行模式。多个Agent同时干不同的事最后汇总。比如做竞品分析Agent A分析产品功能Agent B分析定价策略Agent C分析用户评价。三个Agent并行跑最后把结果合并成一份报告。public String parallelAnalysis(String product) { CompletableFutureString features CompletableFuture.supplyAsync(() - featureAgent.prompt().user(product).call().content() ); CompletableFutureString pricing CompletableFuture.supplyAsync(() - pricingAgent.prompt().user(product).call().content() ); CompletableFutureString reviews CompletableFuture.supplyAsync(() - reviewAgent.prompt().user(product).call().content() ); CompletableFuture.allOf(features, pricing, reviews).join(); return ## 功能分析 %s ## 定价分析 %s ## 用户评价 %s .formatted(features.join(), pricing.join(), reviews.join()); }并行的好处是快。三个Agent同时跑总耗时约等于最慢的那个而不是三个加起来。层级模式。一个主Agent负责调度把任务分给子Agent。public String hierarchicalProcess(String task) { // 主Agent判断任务类型分给对应子Agent String route orchestratorAgent.prompt() .system( 你是任务调度器。判断用户任务属于哪类 - code代码相关 - doc文档相关 - test测试相关 只输出类别名不解释。 ) .user(task) .call() .content() .trim(); return switch (route) { case code - codingAgent.prompt().user(task).call().content(); case doc - docAgent.prompt().user(task).call().content(); case test - testAgent.prompt().user(task).call().content(); default - 无法识别任务类型; }; }主Agent不干活只做路由。子Agent各自专业。这种模式适合任务类型多、不好预先判断走哪条线的场景。多Agent的三个坑第一Agent之间信息丢失。Agent A分析出的结论传给Agent B时如果太简略B就丢了上下文。比如A分析出这个接口需要处理高并发但传给B的技术方案里只写了接口签名没提并发要求。B写出来的代码就不会考虑性能。解决办法Agent之间传递的信息要结构化用固定格式确保关键字段不丢。不要指望模型自己判断什么该传什么不该传。第二退回循环停不下来。审查Agent发现问题退给代码Agent改。改完再审查又发现新问题。来回改没完没了。跟Reflection那篇一样的问题。必须设最大重试次数超过就返回最后一次的结果或人工介入。for (int i 0; i 3; i) { String review reviewAgent.prompt().user(code).call().content(); if (review.contains(审查通过)) break; code codingAgent.prompt() .user(代码\n code \n\n审查意见\n review) .call().content(); }第三调试困难。单Agent出问题你看日志就行。多Agent出问题你得排查是哪个环节出了错。是需求分析没分析对还是代码生成理解错了方案还是审查漏了问题建议每个Agent的输入和输出都打日志。出问题时可以按链路追踪快速定位是哪一环出了问题。log.info(需求分析输入: {}, userRequirement); log.info(需求分析输出: {}, techSpec); log.info(代码生成输入: {}, techSpec); log.info(代码生成输出: {}, code);什么时候该用多Agent不是所有任务都需要多Agent。简单任务——一问一答、翻译、摘要——单Agent足够了。拆成多个反而增加复杂度和延迟。多Agent适合这些场景任务有明确的阶段性步骤、每个步骤需要不同的专业能力、步骤之间有依赖关系需要流转。典型场景需求分析→代码生成→测试用例→文档生成。数据分析→报告撰写→可视化。竞品调研→SWOT分析→策略建议。判断标准很简单如果你自己干这个任务也需要切换不同的思维模式那它就适合拆成多Agent。
