今年做的最折腾的一件事是把一个 AI 工单助手从“一个大 Agent 硬刚所有问题”改造成“Graph 编排的混合流程”。改完后同一批测试用例的通过率从 67% 提到了 91%单条工单的平均处理耗时从 40 秒降到了 6 秒模型调用费用直接腰斩。这个数据对比让我彻底想明白一件事企业里真正能落地的 AI 复杂流程缺的往往不是更强的大模型而是一套能把“模型决策”和“规则执行”捏在同一个流程里的编排引擎。聊的框架是 Spring AI Alibaba Graph。它提供了一种在 Java 生态里实现 LangGraph 式编排的路径让 ReAct Agent 和 Workflow 不再是二选一而是可以放在一张图里混合使用。这篇文章我会从实战角度拆透三件事ReAct Agent 与 Workflow 的本质边界在哪、Spring AI Alibaba Graph 里的状态/节点/条件边怎么建模、以及我用它把一个工单流转系统从 Agent 改造成 Graph 后踩过的所有坑。如果你正处在“Agent 演示很惊艳一上生产就失灵”的阶段或者团队在纠结要不要把流程固定成 Workflow这篇文章应该能帮你省不少试错时间。1. 先别急着堆大模型企业AI流程编排到底卡在哪1.1 单 Agent 的失控现场我第一次把 Agent 接进一个企业内部模拟工单系统时理想的画面是所有工单进来模型自动判断意图、调用工具、给出解决方案全程“自动驾驶”。但真实表现完全不是这样。举个当时复现过很多次的例子。用户提交了一条报修工单“会议室投影仪突然没画面了后天要开重要会议尽快处理。”大模型拿到这个问题后先调用了一次“设备查询”工具发现这台投影仪有两条维保记录又回头调用“工单查询”工具去翻历史处理方案中间还生成了两段解释性文字最后才调用“创建维修工单”工具。整个过程跑了 9 轮工具调用耗时 47 秒模型输入输出加起来消耗了大量 token其中大半是根本不需要的上下文。更难受的是不可复现。同一个问题隔十分钟再跑一次路径可能完全不同有时它会先检索知识库有时它会先询问用户更多信息。排查问题的时候你根本说不清它这一单为什么走这条路下个月想审计某一单的处理依据也无从下手。这不是模型能力问题而是编排方式问题。单 Agent 把“流程控制权”完全交给了模型而模型天生不适合做需要严格排序、记忆状态、精确回退的事情。它擅长的是理解、生成、归纳这一类非确定性任务。1.2 企业流程要的是哪四样东西做企业内系统跟在个人项目里玩 Agent 完全是两种心态核心诉求可以收敛成四点可审计每一步处理路径、每一次模型调用、每个状态变更都能回放。可 SLA响应时间要可控。不能出现“运气好 3 秒运气差 3 分钟”。可兜底模型判断出错时有规则或者人工环节能接住而不是一起失控。可变更产品说要调整流程顺序时不用把整段逻辑全部推翻。这四点单 Agent 几乎给不了。模型有天然的随机性路径不可控审计无从谈起自由调用工具导致响应时间方差极大模型兜底也只是“再让它想想”而不是确定性兜底。所以企业里真正缺的是流程引擎。把大模型当作流程里的一个能力节点而不是让流程围着模型转。这就是我第一次意识到需要 Graph 编排的起点。1.3 只让模型做它擅长的事想清楚问题之后我开始重新划分职责。模型擅长的意图分类、实体抽取、话术生成、非结构化信息的归纳。模型不擅长的状态管理、路径控制、精确计算、长期规划、对每一步给出确定性证明。于是我把方案改成了 Spring AI Alibaba Graph把每个工单的处理过程拆成一条可描述的路径先让模型做意图分类分类结果交给代码决定走向走到维修分支后再调用设备查询接口查询结果里有一个字段专门给代码做金额判断超过阈值才转人工审批。模型只在“分类”“信息抽取”这两个真正需要它的节点出现。这一步改完系统才第一次像个正式软件了有状态、有分支、有退出条件而不是一段“看模型心情”的黑盒循环。2. ReAct Agent和Workflow本质区别不是“有没有工具调用”2.1 ReAct 不是一种框架而是一种推理模式ReAct 这个词经常被误解为代表某种 Agent 框架其实它描述的是一种循环模式Reason思考→ Act行动→ 观察结果 → 再思考如此往复。模型在每一轮推理时决定要不要调用工具、调用哪个工具、怎么解读工具返回的结果。用一句话类比把一个实习生丢到一个任务面前他自己查资料、自己问人、自己试错直到把任务完成。这就是 ReAct 的核心价值——在开放域里探索。在 Spring AI Alibaba 里实现一个简单的 ReAct 形态并不复杂。定义几个工具让 ChatClient 自行决定调用public class DeviceService { Tool(根据设备名称查询设备维修记录) public String queryMaintenanceHistory(String deviceName) { // 实际调用设备管理系统的 REST 接口 return 该设备近一年维修 2 次最近一次为投影灯泡故障; } Tool(根据设备名称查询设备状态) public String queryDeviceStatus(String deviceName) { // 返回设备在线状态、故障码、剩余寿命等 return 状态异常故障码 E-302剩余寿命 12%; } }ChatClient chatClient ChatClient.builder(chatModel).build(); String answer chatClient.prompt() .user(会议室投影仪没画面了帮我查一下可能的原因) .tools(new DeviceService()) .call() .content();这段代码跑起来后模型会自己决定先查状态、再查维修记录而不是按代码写死的顺序去查。它就是最典型的 ReAct Agent。但 ReAct 的代价也很明显每一步“思考”都要计费循环次数没有天然上限执行路径高度随机模型可能连续调用同一个工具两次而不自知。适合它的场景是信息综合、开放诊断、边界模糊的任务而不适合固定交易类流程。2.2 Workflow 是“把流程钉死”的执行模型Workflow 的思路刚好像是另一个极端每个节点做什么、执行顺序是什么、什么条件下走哪个分支全部由代码预先定义。模型只在某个特定节点被调用比如“生成一段回复话术”它永远没有控制流程走向的机会。还是用实习生类比这次他不是自己探索而是站在流水线上工序单规定了它第 1 步贴标签、第 2 步装箱、第 3 步过安检每一步做完必须盖章确认。Workflow 的价值在于确定性和可审计性。同样一个输入进来永远走同一条路径响应时间稳定任何一步出错都能直接定位到具体节点。合规场景、支付场景、售后流程这类强流程业务几乎只能采用它。它的问题则是如果流程本身边界不清提前画不出来Workflow 也白搭。比如客户说“我有个问题但我也说不清是什么问题”这种开放场景很难写进预设代码。2.3 关键洞察Graph 是光谱而不是二选一这是全文我最想强调的一点。很多人把 ReAct 和 Workflow 当成一个非黑即白的选择题但 Graph 的基本思想是它们是一条光谱的两端你可以在一张图里同时容纳这两端。Spring AI Alibaba Graph 的实现思路深受 LangGraph 启发用 State状态、Node节点、Edge边三个概念来构建执行图。有些节点是普通代码节点、有些节点是 LLM 节点、有些节点内部甚至可以再嵌一个 ReAct Agent边上再挂条件决定走向。三种模式的差异我做了张表方便对照维度ReAct Agent纯 WorkflowGraph 混合编排流程确定性低模型自己决定路径高代码决定全部路径中高关键路径固定局部开放Token 消耗高思考和反复调用都计费低只在模型节点使用中可精确控制模型节点的位置出错排查难路径不可复现容易每步可回放容易特定节点可单独调试变更成本改 Prompt 就能试改代码、重新发版局部改某个节点或边的条件适合场景开放问题、复杂诊断强审计、高 SLA、合规敏感企业级主流选择我的实际判断非常偏实用企业 90% 的场景应该以 Workflow 为主干把 Agent 作为局部节点的增强能力而不是让整个系统从头到尾都是 Agent。判断依据只有一个问题——这一步需要模型“现场决策”吗如果下一步路径事前能枚举出来就不需要 Agent如果实在枚举不出再把这一步处理逻辑包成一个 Agent 节点放进去。3. Spring AI Alibaba Graph的建模前提把流程拆成状态、节点和边3.1 三个核心概念怎么理解Graph 的建模语言只有三个核心概念理解了它们整个编排思路就通了。State状态所有节点共享的数据对象一个节点消费它、返回新的它下一个节点再拿到更新后的它。类比像一张工单在各个处理部门之间流转工单本身的内容就是 State流转过程就是图。Node节点一段业务逻辑的函数输入是 State输出也是 State。节点内可以是普通 Java 代码、REST 调用、也可以是大模型推理。Edge边节点间的连接关系决定执行顺序。普通边是“无条件走下一步”条件边则是根据 State 里的某个字段决定走 A 分支还是 B 分支。Spring AI Alibaba Graph 默认是内存态执行。也就是说State 在进程内传递整个图的运行是一次函数调用链。这个设计的好处是简单直接坏处是进程重启后执行状态会丢后面的踩坑部分我会专门讲怎么处理。3.2 状态设计的第一原则字段所有权我在最早写 Graph 时犯过一个低级错误把整个 State 设计成一个大而全的 DTO所有节点拿到就随手往里塞字段。前几个节点串行跑没问题一上并行节点立刻炸了两个并行分支同时往state.setResult()写东西后写的把先写的覆盖了。这里给出一个第一原则每个字段必须有唯一的所有者节点。并行分支可以各自维护自己的私有字段最后通过一个合并节点把它们汇总到公共字段上。以我工单系统为例State 大致长这样public class WorkOrderState { // 基础信息由入口节点写入 private String orderId; private String userText; // 分类结果由 classify 节点写入 private String intent; // repair / refund / complaint / unknown // 设备信息由 inspectDevice 节点写入 private String deviceName; private String faultCode; private BigDecimal repairCost; // 审批信息由 approval 节点写入 private Boolean needApproval; private String approvalUrl; // 最终结果由 merge 节点统一汇总 private String finalResult; // 审计追踪所有节点都可追加 private ListString auditLog; }字段分区后并行分支之间的冲突就自然消失了。任何节点想写repairCost都要经过“拥有该字段的节点”来写其他节点只能读。3.3 节点怎么写才像“企业级”企业级节点和 Demo 里节点的最大区别是每个节点都要留下痕迹。我在每个节点外面套了一层统一的包装逻辑记录四样东西节点名、开始时间、结束时间、传入传出状态的摘要。public StatefulNodeWorkOrderState auditedNode(String nodeName, StatefulNodeWorkOrderState inner) { return state - { long start System.currentTimeMillis(); try { WorkOrderState out inner.apply(state); state.getAuditLog().add(String.format( [%s] %s 完成耗时 %d ms, LocalDateTime.now(), nodeName, System.currentTimeMillis() - start)); return out; } catch (Exception e) { state.getAuditLog().add(String.format( [%s] %s 失败: %s, LocalDateTime.now(), nodeName, e.getMessage())); state.setFinalResult(系统处理失败已转人工兜底); return state; } }; }节点内抛出的异常不要直接往外炸而是写进 State 的错误标记里把流程引导到兜底节点。这是后文“回退机制”的基础也是让 Graph 面向生产可用的关键一步。4. 跑一个真实案例智能工单流转从Agent退回Graph的全过程4.1 案例需求企业内部服务台的工单自动流转我拿模拟项目 X 举例。它的业务规则是这样的用户提交一段问题文本系统先判断意图如果是报修去查对应设备的当前状态根据预估维修费用决定自动派单还是走人工审批如果是退款走退款审核如果是投诉直接转人工分类不出来也要有一个兜底节点接住。这个系统一开始用的是整体 ReAct Agent效果我在开头就说了路径不可控、token 消耗高、经常绕路。后来我用 Spring AI Alibaba Graph 重写把意图分类保留给模型其余全部交给确定性的节点和条件边。4.2 基础依赖与配置Graph 模块的依赖很简单dependency groupIdcom.alibaba.cloud.ai/groupId artifactIdspring-ai-alibaba-graph-starter/artifactId version1.0.0-M6.1/version /dependency这里提醒一下Spring AI Alibaba 的版本迭代比较快1.0.0-M 系列的 API 在不同小版本之间可能有命名微调我下面写的代码基于我当时的版本思路不变如果个别方法名对不上翻一下当前版本官方示例即可。模型配置我用的是 DashScope 的 endpoint只要你项目里配了任何 OpenAI 兼容的模型服务改成自己的 base-url 和 api-key 也一样跑spring: ai: dashscope: api-key: ${DASHSCOPE_API_KEY} chat: options: model: qwen-plus4.3 四个核心节点实现第一步分类节点。它是唯一一个不确定的模型节点用 ChatClient 让模型输出一个 JSON内容只有意图和提取出的关键实体。为了避免模型乱说话我在 Prompt 里给了一个严格的输出约束public class ClassifyNode implements StatefulNodeWorkOrderState { private final ChatClient chatClient; Override public WorkOrderState apply(WorkOrderState state) { String prompt 你是工单分类器根据用户输入返回 JSON不要输出其他内容。 格式{intent:repair|refund|complaint|unknown,device:设备名或null,amount:金额数字或0} 用户输入%s .formatted(state.getUserText()); String raw chatClient.prompt().user(prompt).call().content(); // raw 可能是带 json 围栏的需要清洗 String json cleanJson(raw); // 用 Jackson 解析成 Map 后写回 State // intent、deviceName、repairCost 等字段在此节点被写入 return state; } }第二步设备状态查询节点。它调用设备管理系统提供的 REST 接口把故障码、剩余寿命、预估费用拉回来。这个节点没有任何模型参与执行时间是稳定的毫秒级public class InspectDeviceNode implements StatefulNodeWorkOrderState { Override public WorkOrderState apply(WorkOrderState state) { String deviceName state.getDeviceName(); // GET /device/{name}/status DeviceStatus status deviceClient.fetchStatus(deviceName); state.setFaultCode(status.getFaultCode()); state.setRepairCost(status.getEstimatedCost()); return state; } }第三步费用判断节点。这里我必须强调一个点分支条件不要用模型判断用代码判断。费用到底超没超阈值这种确定性判断交给模型纯属浪费 token 还引入不稳定。我这里直接在条件边里写boolean needApproval state.getRepairCost().compareTo(new BigDecimal(5000)) 0; state.setNeedApproval(needApproval);第四步通知节点。无论哪个分支最终走完都要往审计里写一条结果并生成给用户的回复文本。4.4 用 StateGraph 把节点串起来核心的编排代码长这样StateGraphWorkOrderState graph new StateGraph(WorkOrderState.class) .addNode(classify, new ClassifyNode(chatClient)) .addNode(inspect, new InspectDeviceNode()) .addNode(autoDispatch, new AutoDispatchNode()) .addNode(humanApproval, new HumanApprovalNode()) .addNode(notify, new NotifyNode()) .addNode(fallback, new FallbackNode()) // 入口 .addEdge(__start__, classify) // 条件路由根据 classify 节点写入的 intent 决定走向 .addConditionEdge(classify, List.of(inspect, refundHandle, complaintHandle, fallback), state - switch (state.getIntent()) { case repair - inspect; case refund - refundHandle; case complaint - complaintHandle; default - fallback; }) // 维修分支查询设备状态后根据费用决定自动派单还是人工审批 .addConditionEdge(inspect, List.of(autoDispatch, humanApproval), state - Boolean.TRUE.equals(state.getNeedApproval()) ? humanApproval : autoDispatch) // 所有处理分支最后都汇到 notify .addEdge(autoDispatch, notify) .addEdge(humanApproval, notify) .addEdge(refundHandle, notify) .addEdge(complaintHandle, notify) .addEdge(fallback, notify) .addEdge(notify, __end__) .compile();执行时只需构造初始状态调用invokeWorkOrderState initialState new WorkOrderState(); initialState.setOrderId(WO-2024-001); initialState.setUserText(会议室投影仪突然没画面了后天要开重要会议尽快处理); WorkOrderState finalState graph.invoke(initialState); System.out.println(finalState.getAuditLog()); System.out.println(最终处理结果 finalState.getFinalResult());整条链路非常清晰分类是唯一的模型节点之后是“规则 代码 少量模型”的混合执行。业务负责人来问“这单为什么走审批”直接把审计日志翻出来每一跳都有节点名和时间戳根本不用猜。4.5 改造前后对比同样是那批之前 Agent 跑得很吃力的测试用例改造后的数据变化是路径确定性从“每单路径都可能不同”变成“相同条件相同路径”。单均耗时从平均 40 秒降到 6 秒因为中间不再有多余的模型思考轮次。Token 消耗只有分类节点和通知节点各调一次模型费用直接降了一半以上。排查效率以前看一条日志要看几十行工具调用记录现在看审计日志里的节点链路就够了。这套实践让我坚定了一个原则模型只做它不可被替代的那一步其他全交给代码和规则。5. 上线之后才踩到的坑并发覆盖、模型JSON、状态快照与人工兜底5.1 并行节点把 State 写串了系统接入真实流量后我很快加了并行节点人工审批的同时并行跑一个风险扫描节点。表面看两个分支互不影响但它们最终都往 State 里写“结果相关字段”时晚写的那一个覆盖了先写的。解决办法是前面已经提到的字段所有权设计。并行分支各自写私有字段比如approvalResult和riskResult最后用一个 merge 节点读取两边结果汇总到finalResult。Graph 本身不帮你做并发状态控制它只是一个函数执行引擎“谁写什么”必须由建模的人自己设计清楚。5.2 模型返回的 JSON 根本不是干净的 JSON第一个版本里我在分类节点直接拿chatClient.call().content()的返回值去用 Jackson 解析结果生产环境很快出现一批解析异常。模型有时会输出带 json 围栏的代码块有时在 JSON 前后夹带一句“好的这是你要的结果”更离谱的是偶尔会在 JSON 末尾多一个逗号。处理办法是两层先清洗字符串再走容错解析。清洗函数去掉围栏和前后缀解析失败时返回一个unknown意图走兜底节点而不是让整个 Graph 抛异常卡死。private String cleanJson(String raw) { String s raw.trim(); if (s.startsWith()) { s s.replaceAll(^[a-zA-Z]*\\n, ).replaceAll(\\n$, ); } int start s.indexOf({); int end s.lastIndexOf(}); if (start 0 end start) { return s.substring(start, end 1); } return s; }这个过程看起来土但非常实用。模型输出的稳定性永远不能假设 100%Graph 的容错设计必须从第一个模型节点就做好。5.3 图里嵌 Agent 节点循环次数不设上限会出事我在某个分支里嵌入了一个小范围的 ReAct Agent让它去综合多个信息源给出处理建议。开发环境下跑得好好的一并发量上来就出了各种“慢请求”。原因很简单Agent 节点的循环次数没有设上限遇到复杂问题它可能连续调用十几个工具单次请求耗时几分钟。这直接破坏了 Workflow 主干辛苦建立起来的 SLA。后面我在 Agent 节点外层加了三道闸最大迭代次数限制、单次调用超时、总耗时超时。超时后不走“继续思考”而是把这条分支标记为“处理失败”并转入人工兜底节点。宁可让人来做也不能让它无限空转下去。5.4 进程一重启挂在“人工审批”的单子全丢了Graph 是内存态执行这意味着只要服务没重启一切正常一旦重启所有停留在中间状态的任务全部丢失。我曾在灰度环境里重启过一次服务结果当时所有等待人工审批的工单直接消失业务方还以为是系统吞单了。应对办法是按“快照 事件”的思路补了一层持久化。Graph 每一步节点完成后把当前 State 序列化到数据库里记录节点名、执行版本号和变更时间。进程重启后扫描状态为“执行中”的单子从最近完成的那个节点重新恢复后续分支。// 伪代码示意 for (WorkOrderSnapshot snap : snapshotDao.findPending()) { WorkOrderState state snap.deserializeState(); // 从 snap.lastNode() 的下一个节点开始继续执行 graph.invokeFrom(state, snap.lastNode()); }这层不是框架自带的能力是要自己造的轮子。在企业场景里它比某个花哨的 Agent 特性重要得多。5.5 别让模型去决定流程走向最后这个坑有点反直觉条件路由是流程里最容易出问题的地方但我见过不少人把路由判断也交给模型。比如在条件边里再让模型判断“这笔费用算不算高”。这不是聪明是自找麻烦。费用阈值是确定性规则模型判断不仅多花 token还会因为 prompt 措辞不同而出现摇摆不定的结果。Graph 里条件边的职责应当全部由确定性代码承担模型只需要负责上游的意图分类和信息抽取输出结构化的中间结果路由交给switch就够了。6. 我的选型判断哪些环节该用Agent哪些环节该钉死成Workflow6.1 三个问题快速判断边界现在我设计任何一条 AI 流程时都会先对着每个环节问三个问题这个环节的结果必须是确定的吗如果是直接写代码或规则不碰模型。下一步路径事前能枚举出来吗如果能用条件边只有枚举不出来才考虑 Agent。失败成本高吗如果高必须有回退节点和人工兜底绝不放给 Agent 自由重试。这三问能过滤掉大部分“为了 AI 而 AI”的设计。分类、抽取、总结、话术生成这些都是模型的活比较大小、判断状态、按条件跳转、执行某个外部动作这些都是代码的活。6.2 什么场景真的需要 ReAct Agent在我的工单系统里真正还需要 Agent 的只剩一个环节用户问题异常模糊且跨多个业务域时先让 Agent 做一轮“诊断式探索”再把它探索的结果落成结构化意图交给后面的 Workflow 执行。所以我的建议不是消灭 Agent而是限制它的使用边界。把 Agent 当作一个局部的、有超时和重试上限的复杂节点放进以 Workflow 为主干的 Graph 里这样才能既享受它的探索能力又不被它的失控路径绑架。6.3 渐进式改造路线如果你现在手里正好是一个已经开始发散的 Agent 项目别急着推翻重来按这个顺序渐进改造第一步把业务方描述的全部处理路径画成图确定有哪些节点、哪些分支、哪几个退出条件。这一步只画流程不写代码。第二步把图中能用规则和代码实现的节点全部实现掉模型节点暂时用“返回固定值”的方式占位先把整条链路跑通。第三步再把真正需要模型的位置换成 LLM 节点比如意图分类、摘要总结、话术生成。此时整个系统已经有稳定的主干和清晰的审计结构。第四步如果某个位置确实需要自由探索再在该节点内嵌一个 ReAct Agent并加上本章讲过的迭代上限和超时控制。这套路线我实践下来非常稳每次只动一个节点出问题可以精准回滚不会出现“改个流程全家翻车”的场面。最后再分享一个很实用的小技巧从 Graph 入口生成一个traceId放进 State 里每个节点写审计日志时都带上它排查跨节点问题时你会在日志系统里省下大把时间。这个习惯我在改造成 Graph 之后才开始做后悔没早点加。流程可解释AI 才可信。它能让模型在生产环境里变成一个标准化的、可监督的组件而不是躲在黑盒里的不确定性来源。