这周我把 Spring AI Alibaba 里五个子智能体拼成了一条客服流水线过程中真正看懂了它内置的 flow 编排和 A2A 远程调用是怎么回事。之前文档里那些“Agent 编排”“Agent 协作”的说法对我来说都是黑话直到自己把一个会查订单、能处理售后、能安抚情绪的客服系统拆成五个子智能体再通过编排把它们串起来才意识到多智能体落到工程上到底是什么模样。如果你也在搞 Spring AI Alibaba或者正准备做多 Agent 的应用这篇内容应该能给你省不少弯路。我会从为什么用多智能体、flow 编排怎么理解、A2A 远程调用如何落地到五个子智能体具体怎么拆、怎么协作、踩了哪些坑一条线讲清楚。不说虚的全是实操记录。1. 为什么五个子智能体能撑起客服流水线1.1 单模型对话的天花板很多人一开始都会想客服场景直接用一个大模型不就行了吗我最初也是这么干的把商品知识、订单查询规则、售后政策、优惠计算方式全部塞进一个 System Prompt然后让模型一次性处理所有问题。结果就是Prompt 越来越长模型开始“精神分裂”。它可能在回答订单问题时突然把售后政策的语气带进来也可能因为上下文里塞的规则太多导致最基础的意图判断都出错。而且每轮对话都要把所有规则重新发送一遍Token 消耗也很夸张。更麻烦的是当产品希望“订单查询”“退款处理”“人工转接”分别由不同团队维护、不同策略控制时单个模型的 Prompt 改一处就可能影响所有功能。这就是多智能体拆分的直接动力不是因为它时髦而是因为业务复杂度上来了单模型根本扛不住。1.2 流水线的核心分工逻辑客服场景天然适合流水线式分工。用户进来之后第一件事是判断他想要什么而不是直接给他答案。我把这个判断交给一个“意图识别智能体”它只做分类不回答业务问题。分类结果是订单查询、售后处理、商品咨询、情绪投诉还是人工转接然后走对应分支。订单查询智能体负责调订单接口、物流接口把结构化数据翻译成口语化答案。售后处理智能体掌握退款规则和售后表单逻辑。商品咨询智能体查知识库只讲商品参数和使用建议。情绪安抚智能体比较特殊它不解决问题只负责共情话术为之后的升级处理争取缓冲。人工转接智能体则是在前面几个都搞不定时做会话摘要并生成转接工单。每个智能体的职责边界完全独立Prompt 各写各的工具函数各调各的互不污染。这就是我拆五个子智能体的核心逻辑让每个 Agent 只做一件事但把这件事做明白。1.3 flow 编排 vs 手动 if-else拆完之后面临的第一个问题就是这几个智能体之间怎么协作。最笨的办法是在主流程里写一堆 if-else如果意图是订单就调订单Agent如果是售后就调售后Agent。但这里有个致命问题多智能体协作不是线性的它可能是条件跳转、并行执行、循环追问的组合。比如用户说“我订单还没到想退掉”这需要先查订单状态再判断是否符合退款条件接着才决定要不要走售后流程。用 if-else 写这种链路很快就会变成一团乱麻。flow 编排解决的就是这个问题。它把智能体看作节点把流程看作一个有向图。你定义好节点之间的连接条件、分支策略、并行策略引擎负责执行和状态传递。Spring AI Alibaba 内置的 flow 编排就提供了这套机制我可以把整个客服流程描述成一个图而不是一堆嵌套判断。2. flow 编排的关键实现细解2.1 flow 编排的基本概念我第一次接触 flow 编排时脑海里蹦出来的是工作流引擎比如那些可视化流程工具。Spring AI Alibaba 的 flow 编排没有那么重它更像是一个轻量级的有向图执行器专门为智能体之间协作设计的。核心要素有三个节点、边、上下文。节点就是子智能体或者普通逻辑任务边定义了执行顺序和跳转条件上下文则是所有节点共享的数据容器。每条边带着一个判断逻辑比如“意图识别结果等于 ORDER 时跳转到订单查询节点”或者“意图识别置信度低于 0.6 时直接走人工转接”。这种设计最舒服的地方在于智能体本身不知道其他智能体存在。意图识别智能体只负责输出意图字段和置信度它不关心下游是谁。订单查询智能体只认订单号参数它不关心参数是谁给的。这样一来智能体之间完全解耦我可以随时新增一个智能体只需要改 flow 定义不用动任何子智能体内部代码。这里我想提醒一点flow 编排不是银弹不要什么都往里塞。简单需求比如固定的两步调用直接代码串起来反而更清晰。但一旦分支超过三条或者并行调用超过两个flow 的优势就非常明显了。2.2 条件分支与并行节点怎么设计我在搭建客服流水线时flow 配置里实际用到了三种节点普通节点、条件节点、并行节点。普通节点最简单就是一个子智能体的调用入参从上文里取出参写回上文。条件节点才是整个编排的灵魂。我的第一个节点是意图识别它的输出是一个结构化的意图分类结果。条件节点读取这个结果决定 next 指向谁。这里有几个细节值得注意一是条件判断必须处理“未知意图”和“低置信度”的情况否则 flow 会卡死二是条件判断的逻辑要尽量简单复杂逻辑应该放到智能体内部去消化而不是在 flow 层写一大段判断代码。我有一个经验flow 层的判断只做“看字段、比字符串、跳节点”任何需要语义理解的判断都交给智能体完成否则编排就变成业务逻辑堆积地了。并行节点我用在了处理复杂问题场景。比如用户问“我有个订单想退但赠品怎么处理”这既要查订单信息又要查售后政策还要查赠品规则。三个查询之间互不依赖完全可以并行。配置并行节点时需要指定哪些子节点可以同时执行以及全部完成后怎么汇总结果。Spring AI Alibaba 的 flow 编排里并行节点的汇总会等待所有分支完成然后把结果合并到一个上下文键里。这里有个性能敏感点并行节点里如果挂了一个“第三方接口超时”的重试逻辑整条链路都会跟着遭殃所以并行的子节点要特别注意超时和异常隔离。2.3 我踩过的编排坑第一个坑是上下文混乱。最开始我把上下文设计成一个很大的 Map所有节点都往里写结果一个节点读到的值可能是另一个节点写残的。后来改成使用带命名空间的上下文容器每个智能体只允许读写自己的前缀字段比如 order_ 开头归订单查询智能体用refund_ 开头归售后智能体用。这样就防止了互相覆盖。第二个坑是循环分支。我的流程里有“意图识别看走眼导致必须重走流程”的场景但 flow 不支持无限制循环否则会死循环。我的解法是加计数器超过两次就强制走人工转接。第三个坑是异常中断。一个子智能体调用第三方接口超时后整个 flow 终止了。但实际上订单查询失败并不影响售后咨询完全可以降级处理。所以每个节点都应该声明自己的失败策略是终止流程、跳过节点还是降级到兜底智能体。我在 flow 配置里对每个节点都显式定义了异常处理策略这个对线上稳定性太重要了。3. A2A 远程调用的落地方式3.1 A2A 协议解决什么问题子智能体拆完之后顺其自然就有一个部署问题。前期我把五个智能体放在同一个进程里用一个 Spring 上下文跑起来一切正常。但产品很快说要按团队拆分订单查询智能体由交易组维护售后处理智能体由客服运营组维护两边发版节奏完全不一样。如果还放在同一个进程任何一方的改动都会导致整个客服应用重启这是不能接受的。A2A 就是解决这个问题的。它把智能体暴露成远程服务通过 HTTP 调用其他进程里的智能体。一个智能体不再是一个 Java 对象而是一个可以跨进程、跨语言访问的服务端点。Spring AI Alibaba 内置的 A2A 支持做了一些协议封装我只需要按规范暴露服务然后在客户端定义调用存根就能像调用本地方法一样调用远程智能体。3.2 Spring AI Alibaba 中的 A2A 接入流程A2A 的接入其实没有我一开始想的那么复杂。核心是三步服务端把智能体包装成 A2A 端点暴露出去客户端配置远程智能体的访问地址调用时通过 A2A 客户端发送请求拿到结构化结果。服务端暴露智能体时我在 Spring Boot 配置里加了一段类似下面的内容spring: ai: alibaba: agent: a2a: enabled: true endpoints: - name: orderAgent path: /a2a/order-agent - name: afterSaleAgent path: /a2a/after-sale-agent然后每个子智能体服务里用 Agent 注解标记服务端点AgentRegistry(name orderAgent, displayName 订单查询智能体) public class OrderQueryAgent { Tool(description 根据订单号查询订单状态和物流信息) public OrderQueryResult queryOrder(String orderId) { // 调用交易中台接口返回结构化订单数据 } }客户端要调用远程的订单查询智能体不需要引入对方代码只需要知道服务地址和入参出参格式A2aClient orderAgentClient A2aClient.builder() .agentUrl(http://order-service:8080/a2a/order-agent) .build(); AgentInvocationResponse response orderAgentClient.invoke( 查询订单状态, Map.of(orderId, userId _20250101, userId, userId) ); OrderQueryResult result response.getTypedResult(OrderQueryResult.class);整个过程远程智能体对我而言就是一个带地址的方法。我不用关注对方内部是怎么实现订单查询的也不用关心对方是不是 Java只需要约定好 JSON 格式的交互协议。3.3 本地调用 vs 远程调用的边界A2A 远程调用很灵活但我并不建议全部子智能体都拆成远程服务。远程调用有网络开销、有超时风险、有序列化成本调用失败还需要重试机制。我的拆分原则很简单如果子智能体逻辑稳定、跟主应用强绑定就留在本地如果子智能体需要独立发版、或者被多个应用共用就做成 A2A 服务。实际项目中我把订单查询和售后处理拆了出去因为这两个要对接中台接口跟着业务团队发版。意图识别和情绪安抚留在本地进程内因为它们是客服对话主链路的一部分延迟敏感。这里容易犯一个错误就是把同一进程里的对象调用强行改造成 HTTP 调用美其名曰“以后好拆”。这个做法只会白白增加延迟。A2A 首先是架构手段不是代码风格。4. 五个子智能体的核心设计4.1 意图识别智能体客服流水线的开关意图识别智能体是最先被调用的它的输出直接决定了整个 flow 怎么走。我给它设计的职责只有一个分析用户当前消息输出意图标签和置信度。意图标签就五种ORDER_QUERY、AFTER_SALE、PRODUCT_CONSULT、COMPLAINT_EMOTION、HUMAN_TRANSFER。这个智能体的 Prompt 我写得非常收敛没有要求它去理解业务细节只要求它判断意图。但我加了一个强制约束当用户消息里同时包含多种诉求时以“最先表达的诉求”为准并额外输出一个 secondaryIntent 字段。例如“订单没到想退款”会被识别成 ORDER_QUERY 为主意图但 secondaryIntent 是 AFTER_SALE。这样下游节点可以提前知道后面可能要处理售后做参数准备。置信度低于 0.6 时我不让 flow 强行判断而是设计了一个追问逻辑不让意图识别智能体直接回答而是生成一句澄清话术比如“请问您是想要查询订单还是申请退款呢”把对话推回给用户。这一个设计让后续四个智能体的分流准确率提升了很多。4.2 订单查询智能体一个纯粹的 API 翻译器订单查询智能体的定位很纯粹输入用户身份和查询条件输出结构化的订单和物流信息并把 JSON 翻译成用户能听懂的话。它本身不做意图判断也不做安抚只负责两件事取数据和转译。这个智能体需要在 System Prompt 里明确说明只返回订单状态、物流轨迹、预计送达时间、商品明细如果用户问的是“能不能退”直接返回“该问题不属于订单查询范围”不要解释。因为查询接口返回的原始字段是内部命名比如order_status_code的值为600表示已发货但物流滞缓我需要提供字段枚举映射表让模型把业务码转成用户表达。这步做不做直接影响回答质量。很多智能体项目失败的原因不是模型能力不够而是没有把领域知识喂到正确的位置。4.3 售后处理智能体规则遵循比自由回答重要售后处理是所有客服场景里最容易踩红线的地方因为不同品类、不同时效的退款政策差别很大。我在这块没有让模型自由发挥而是把规则库做成工具函数让智能体通过调用工具获取对应场景的政策而不是凭记忆生成答案。例如当用户说“我要退款”售后处理智能体先调用queryRefundPolicy(productCategory, orderTime)工具拿到结构化的政策文本然后再判断“符合七天无理由退货吗”“运费谁承担”。核心逻辑就是智能体只是政策检索器和话术生成器政策判定交给规则代码。这个设计转变很关键。一开始我试图把全部政策文本塞进 Prompt结果模型经常自己编政策。后来改成工具调用再也没有出现过幻觉政策问题。这提醒我涉及规则严谨性的场景要让智能体变成“嘴替”而是让它做“模拟器”的调度者。4.4 情绪安抚智能体处理异常情绪不让问题升级情绪安抚智能体是我后来加上的。理由很简单用户情绪很激动时直接走订单查询或售后流程体验非常差容易导致投诉升级。它检测到意图识别置信度低但情感偏向负面或者关键词触发投诉意图时就先插一层安抚。安抚智能体不会推进业务它只说三件事表达共情、说明正在处理、告知马上会有专人跟进。就像线下客服说的“我理解您的着急我马上帮您查清楚请您稍等一下”。它的 Prompt 刻意设计得很短并且只输出安抚话术不做业务回答。这样防止它越权给出不靠谱的承诺。实际效果是加了这层之后用户满意度评分上升投诉率下降。原因很有意思用户很多时候要的不是立刻解决问题而是感觉到问题被重视。多智能体流水线的价值不只是完成功能还能支撑这种柔性交互策略。4.5 人工转接总结智能体给人类同事留一手好交接当判断无法解决、或者用户明确表示“我要找人工”时流水线走向最后一个节点人工转接总结智能体。它做的事是把整个对话过程压缩成一段结构化摘要包括用户诉求、已尝试处理方案、未解决的问题、用户当前情绪状态然后生成转接工单。这个智能体不直接面对用户而是面向人工客服。它的 Prompt 要求只输出事实不输出猜测明确标注“系统已确认”和“系统未能确认”两种状态并且摘要不能太长控制在 150 字以内。这块容易被忽略但实际是客服系统的价值洼地。人工客服接到转单后如果能一眼看到上下文摘要平均处理时长能明显缩短。我甚至认为就算流水线其他部分全砍掉只保留这个智能体它本身就有独立的工具价值。5. 实操流水线搭建实录5.1 环境与依赖我在实际搭建时用了 JDK 17 和 Spring Boot 3.x 的组合。Maven 依赖里核心是 Spring AI Alibaba 相关的 BOM 和 Spring AI 核心包。如果你手头版本更新依赖坐标会变但核心思路一致引入 spring-ai-alibaba 的 starter开启 flow 编排和 A2A 支持。具体依赖大致长这样dependency groupIdcom.alibaba.cloud.ai/groupId artifactIdspring-ai-alibaba-starter/artifactId version${spring-ai-alibaba.version}/version /dependency配置里最重要的几个参数模型 API Key、模型名称、flow 开关、A2A 开关。不同版本的配置项前缀可能不同我建议直接看当前版本的 README这是最稳的。5.2 子智能体注册与配置五个智能体在 Spring 容器里就是五个普通的 Bean但需要通过注解声明成 Agent方便 flow 引擎识别。代码结构大致如下Agent(name intentAgent, description 用户意图识别) public class IntentAgent { } Agent(name orderAgent, description 订单查询) public class OrderAgent { } Agent(name afterSaleAgent, description 售后处理) public class AfterSaleAgent { } Agent(name consultAgent, description 商品咨询) public class ConsultAgent { } Agent(name summaryAgent, description 人工转接总结) public class SummaryAgent { }flow 编排侧我用 DSL 把五个 Agent 拼起来。这里的写法强烈依赖 Spring AI Alibaba 的 API 形态不同版本差异很大下面代码只是展示我当时的核心结构你要以自己项目里能跑通的写法为准Flow flow FlowFactory.builder() .start(intentAgent) .branch(intentAgent, context - { IntentResult intent context.get(intentResult); switch (intent.getIntent()) { case ORDER_QUERY: return orderAgent; case AFTER_SALE: return afterSaleAgent; case PRODUCT_CONSULT: return consultAgent; case COMPLAINT_EMOTION: return emotionAgent; default: return finalAgent; } }) .after(orderAgent).next(finalAgent) .after(afterSaleAgent).next(finalAgent) .after(consultAgent).next(finalAgent) .end(summaryAgent) .build();我比较推荐把 flow 的构建放在独立的配置类里而不是业务代码里。因为 flow 本质是配置项将来调整分支时不该动主流程代码。5.3 流水线联调与效果联调时我第一步是模拟用户输入“我 1 月 5 号买的那个东西怎么还没到”。这条消息经过意图识别智能体被分类成 ORDER_QUERY置信度 0.91。flow 条件节点收到结果跳转到订单查询节点。订单查询智能体从上下文里取出订单信息调查询接口拿到了物流轨迹最后生成一段回答“您的包裹已到达本地中转站预计明天下午送达”。这条链路完整跑通大概耗时 2.8 秒。接着我测试“我要退货但东西还没收到”这种复合场景。意图识别输出主意图 ORDER_QUERY、次要意图 AFTER_SALE但 flow 先走了订单查询确认订单处于待收货状态之后并没有直接跳到售后而是由售后处理智能体查询退货政策并结合订单状态生成了符合政策的退货引导话术。这个场景让我确信多智能体流水线比单模型 Prompt 更可控。6. 常见问题与排查技巧实录6.1 多智能体协作的典型故障速查我整理了一份自己踩过的坑速查表分享出来供你参考。问题现象根本原因解决方案智能体 A 调 BB 又调 A调用栈越来越深缺少循环调用防护在 flow 层加跳转深度上限和计数器超过阈值走兜底节点远程 A2A 调用偶发超时导致整条流程卡住没有给 A2A 客户端设置合理超时设置连接超时和读取超时超时后走降级智能体而不是中断用户连续追问时智能体丢失前文信息上下文没有在多智能体之间传递 Session ID用统一的上下文对象存储会话历史每个节点只追加不覆盖意图分类偶尔出错跳到错误分支意图识别智能体 Prompt 过于复杂精简意图种类强制输出置信度并增加低置信度澄清话术工具返回大量 JSONToken 开销飙升智能体把完整 JSON 塞进了上下文工具函数返回前先做字段裁剪只保留模型生成回复所需的字段6.2 远程调用到底该不该重试A2A 调用失败之后要不要重试这个问题我纠结了很久。在客服场景里用户问一次订单状态如果第一次调用超时重试一次是可以接受的。但如果每一次调用都失败重试只会让用户等更久。我的经验是只在“网络抖动导致的瞬时失败”场景重试重试次数不超过两次并且重试之间的间隔指数退避。而对于业务逻辑性失败比如目标智能体返回了“没有查询到订单”这类错误不应该重试而是走正常的兜底流程。判断方法很简单看异常是 HttpException 还是业务错误码。前者重试后者直接进入失败处理流程。还有一个值得注意的点远程调用前一定要做服务发现。不要硬编码智能体的完整 URL而是通过注册中心或者配置文件管理地址。我在本地测试时硬编码没问题但上了多环境之后硬编码地址就是给自己挖坑。Spring 的配置中心方案就够用了把 A2A 目标地址做成配置项是底线要求。6.3 调试多智能体的三个小技巧调试多智能体流水线比调试普通代码麻烦因为每个节点都在跟大模型交互输出不确定。我用了三个技巧来降低调试成本。第一个是“打断点看上下文”在 flow 的每个节点调用前后打印上下文关键字段。特别是意图识别节点之后上下文里的intentResult是整个流程的开关它一旦错了后面全错。我只打印这个字段而不是打印整个巨大的上下文对象这样日志量小、定位快。第二个是“Agent 请求响应落盘”。我把每个子智能体的入参和出参 JSON 都记录到本地文件文件名带会话 ID 和时间戳。出了问题时相当于有了完整的黑匣子可以还原当时到底哪个环节出了岔子。这个习惯在联调阶段尤其有效。第三个是“为每个智能体单独准备一个测试入口”。不要每次调试都从完整流水线跑一遍。我在开发环境暴露了针对每个 Agent 的调试接口可以直接传参调用订单查询智能体或者直接测售后处理智能体。单个智能体稳定之后再集成到 flow 里测链路。这个习惯帮我避开了一个很尴尬的处境流程整体出错时无法区分是编排的问题还是单个智能体的问题。7. 我对这套方案的真实评价与扩展建议做完整套客服流水线之后我的收获比预期大不少。以前理解 flow 编排总觉得它是给那些“流程特别复杂的企业级系统”准备的我这种小客服项目用不上。实际用下来才发现只要分支逻辑超过两条flow 的收益就出现了——它把混沌的 if-else 变成了结构清晰的图把 Agent 之间的耦合降到了最低。A2A 带来的价值则是另一条线组织协作层面。它让“你负责你的 Agent我负责我的 Agent两边通过协议对接”成为可能。对团队来说这比在同一个代码仓库里改同一个类要友好得多。如果你也想尝试这套方案我建议先别急着追求复杂。从一个最简单的三点式流水线开始一个意图识别节点、一个业务处理节点、一个兜底节点跑通了再加 A2A再加上情绪安抚。多智能体系统最忌讳一上来就画一张大图然后照着图把所有节点都实现一遍。真实落地时你一定会发现最初的设计有一半需要调整。先跑通再扩展这是最稳的路径。我对这套方案最大的体会其实是“边界感”。五个子智能体之所以能协作顺畅不是因为模型更聪明了而是因为每个智能体都被严格约束在自己的职责边界里不越界、不抢活、不散发多余的善意。大模型的边界定义比模型能力本身更重要。