多Agent协作实战
不是所有任务都需要多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) { CompletableFuture<String> features = CompletableFuture.supplyAsync(() -> featureAgent.prompt().user(product).call().content() ); CompletableFuture<String> pricing = CompletableFuture.supplyAsync(() -> pricingAgent.prompt().user(product).call().content() ); CompletableFuture<String> 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。