企业官网建设流程全解析

做 Agent 最怕的不是模型不给力，而是流程一旦复杂起来，判断和行动纠缠在一起，改一处就牵动全局。我最近在做一个客服工单自动分派项目，第一版就是典型的“一把梭”：把所有指令塞进一个提示词，让大模型一次性回答完。结果上线没几天就露馅了，提问稍微绕一点，分类就乱；分类一乱，后续的答复、转人工、退款判断全跟着错。后来我把流程按判断点拆开，做成条件工作流，每个节点只负责一件事，由上一个节点的结果决定下一个节点该走哪条分支。这篇文章就把我用 langchain4j 实现条件工作流的完整思路写下来，从设计骨架到踩坑优化都会讲到，适合正在用 Java 做 AI 应用、想从“单次调用模型”升级为“多步骤流程编排”的开发者参考。

1. 条件工作流到底在解决什么问题

1.1 “一把梭”式 Agent 为什么撑不住复杂业务

很多团队刚开始做 Agent 应用时都有一个惯性：把所有需求写成一个超级提示词，让模型读一段长文本，然后直接输出最终结果。这在小样本验证、玩具 Demo 里确实跑得通，但一旦放到真实业务里，问题会一层层浮出来，而且往往不是模型不行，是流程结构本身不合适。

第一类是组合爆炸问题。真实业务里有一种典型的“连环判断”：先判断类别，再根据类别判断处理路径，在路径里再根据数据质量判断要不要人工介入。如果这些环节全塞进一个提示词，模型需要在几轮“隐性推理”里同时兼顾多个判断维度，任何一个维度理解偏了，后续全偏。更麻烦的是，你很难定位错误到底发生在哪个判断环节，只好反复调整提示词，越调越乱。

第二类是中间结果无法回填。很多业务场景需要分步获取信息，比如先调用一个查询接口拿到订单状态，再基于订单状态决定下一步动作。单个 prompt 调用里，模型很难“真实地”把外部数据先读进来再继续判断，就算它能用工具调用，你也不好控制调用顺序和结果缓存。条件工作流把“查数据”和“做判断”拆开，每个节点的输入输出都是显式的，中间结果可以落库、可以监控、可以回放。

第三类是容错和人工兜底缺失。一个纯 prompt 实现的 Agent，如果模型输出不符合预期，你除了改提示词别无办法，甚至没有一处清晰的代码可以打日志、设置超时、写降级逻辑。条件工作流天然是一个节点图，每个节点都能单独设防：模型调用失败就走规则分支，判定置信度太低就让用户确认或直接转人工。

用一个生活化的类比理解这件事：一个人处理客服工单，绝不会“读完全部信息再一次性写成最终回复”，他的动作是“看一眼工单标题→判断分类→打开订单系统查数据→根据结果决定是自己解决还是升级给主管”。条件工作流就是把这种真实的“判断—行动—再判断”过程显式建模出来，让 AI 应用的结构和业务认知对齐。

1.2 条件工作流和路由、顺序链这些模式的分工

Agent 设计模式里经常提到的有链式调用、路由、扇出扇入、工作流编排等。很多人会困惑：条件工作流和路由有什么区别？其实它们不是替代关系，而是不同层级的东西。

路由强调的是“分发”：拿到一个请求，根据某个特征把它送到 A、B、C 中的某一条链路，每条链路内部可能是同构的处理逻辑。条件工作流强调的是“流程内的多次分叉”：同一个请求从入口进来后，在一个流程内部可能经历若干次判断，每次判断都基于当时的中间状态，而不是只基于最初的请求。所以路由往往是一次性的入口分发，条件工作流则把“分发”这件事内嵌到流程的多个点位上。

这里有一个特别容易踩的误区：把条件工作流实现成一堆 if-else 胶水代码。比如几个模型调用用 if-else 串起来，表面看有分支，实际上没有把分支当成工作流的一等公民。等流程变长，if-else 的嵌套深度会迅速失控，调试时你根本看不出来某个节点到底是基于什么条件走到下一步的。真正值得做的，是把“分支决策”本身变成一个显式节点，让它有输入、有输出、有日志。

2. 用 langchain4j 搭出条件工作流的第一版骨架

2.1 为什么在 Java 项目里选 langchain4j

如果你的技术栈已经是 Java/Spring，引入 langchain4j 是我看到的最平滑路线。它不要求你把项目重写成 Python 技术栈，也不要求自己去封装底层模型 API，官方抽象把聊天模型、嵌入模型、记忆、工具调用这些高频能力都统一了。

对比几种方案会更清楚：

我用下来最爽的一点是它的 AiServices 可以把一个普通 Java 接口直接变成带模型能力的服务，接口方法上写 @SystemMessage、@UserMessage 就能完成提示词模板绑定。对条件工作流来说，这意味着每个节点内部需要调用模型时，不必散落一堆字符串拼接，提示词可以集中在接口注解里维护。

2.2 最小骨架：节点、上下文、下一步动作

实现条件工作流时，我给每个业务步骤都建模成 Node，所有节点共享一个 WorkflowContext，节点执行后返回 NextAction 表示下一步怎么走。

先看上下文对象：

public class WorkflowContext { private final String workflowId; private final Map<String, Object> data = new HashMap<>(); private int stepCount = 0; public void put(String key, Object value) { data.put(key, value); } public <T> T get(String key) { return (T) data.get(key); } public void incrementStep() { stepCount++; } public int getStepCount() { return stepCount; } }

然后定义节点接口：

@FunctionalInterface public interface WorkflowNode { NextAction execute(WorkflowContext ctx); }

NextAction 是这个设计里最关键的部分，它不能只是一个字符串，因为后续还要携带要进入的节点、要保存的结果、要传给下一个节点的参数：

public class NextAction { private final String nextNode; private final Map<String, Object> outputs; public NextAction(String nextNode, Map<String, Object> outputs) { this.nextNode = nextNode; this.outputs = outputs; } public static NextAction goTo(String nodeName) { return new NextAction(nodeName, Map.of()); } public String getNextNode() { return nextNode; } public Map<String, Object> getOutputs() { return outputs; } }

工作流引擎本身很简单，无非是“按节点名查节点，执行，提取下一步，再执行”，但要把最大步骤数卡死，防止出现死循环：

public class WorkflowEngine { private final Map<String, WorkflowNode> nodes; public WorkflowEngine(Map<String, WorkflowNode> nodes) { this.nodes = nodes; } public void run(String startNode, WorkflowContext ctx) { String current = startNode; while (current != null && !current.isBlank()) { if (ctx.getStepCount() >= 10) { throw new IllegalStateException("workflow over max steps"); } WorkflowNode node = nodes.get(current); if (node == null) { throw new IllegalArgumentException("node not found: " + current); } ctx.incrementStep(); NextAction action = node.execute(ctx); action.getOutputs().forEach(ctx::put); current = action.getNextNode(); } } }

这个骨架只有几十行，但它已经满足条件工作流最核心的需求：拓扑执行、结果共享、分支跳转、步数保护。后续加日志、加并行、加持久化都很方便。

2.3 一个两分支的演示工作流

为了验证骨架能跑通，我写了一个极简分类工作流：先由模型判断工单类型，然后根据类型走“技术问题分支”或“退款问题分支”。

public class ClassifyNode implements WorkflowNode { private final ChatLanguageModel model; public ClassifyNode(ChatLanguageModel model) { this.model = model; } @Override public NextAction execute(WorkflowContext ctx) { String ticketText = ctx.get("ticketText"); String instruction = """ 你是工单分类器。只输出 TECH 或 REFUND，不要输出其他内容。 工单内容：%s """.formatted(ticketText); String category = model.generate(instruction).trim(); ctx.put("category", category); if ("REFUND".equalsIgnoreCase(category)) { return NextAction.goTo("refundNode"); } return NextAction.goTo("techNode"); } }

主流程里注册节点：

ChatLanguageModel model = OpenAiChatModel.builder() .apiKey(System.getenv("LLM_API_KEY")) .modelName("gpt-4o-mini") .build(); WorkflowEngine engine = new WorkflowEngine(Map.of( "classifyNode", new ClassifyNode(model), "techNode", ctx -> { System.out.println("走技术分支：" + ctx.get("ticketText")); return NextAction.goTo(null); }, "refundNode", ctx -> { System.out.println("走退款分支：" + ctx.get("ticketText")); return NextAction.goTo(null); } )); WorkflowContext ctx = new WorkflowContext(); ctx.put("ticketText", "我买了课程，但是一直打不开，想退款"); engine.run("classifyNode", ctx);

这个 Demo 展示了条件工作流最基本的闭环：模型产出判定、代码根据判定转移、中间结果放到共享上下文。你在这个阶段已经能直观感受到，想要增加一个分支，只需注册一个新节点，再在判断处多写一个分支条件，不需要动其他节点的代码。

2.4 为什么第一版不直接引入通用流程引擎

其实开发之前我也犹豫过，要不要上现成的流程编排框架，比如类似状态机的库或者工作流引擎。后来决定第一版自己写这个 50 行的骨架，原因是条件工作流的复杂度在“判定逻辑”和“模型输出质量”，不在“引擎的执行能力”。

引入重型框架之后，你会被迫学习它的节点定义、连线方式、事件机制、持久化规则，而这套东西对单个节点内部要调模型这件事没有任何帮助。等流程真的复杂到需要可视化编排、多人协作维护、断点续跑时，再迁移到成熟框架也不迟，因为你的业务逻辑已经清晰地沉淀在 Node 接口上了。

一个实用经验是：先让流程跑通，再谈引擎。你的 Node 接口设计得越稳定，后续替换引擎的成本就越低。很多团队一上来就选重型工作流产品，最后所有精力都耗在“如何把模型调用塞进状态机里”，反而把业务逻辑本身丢掉了。

3. 条件判定怎么写才稳：规则、LLM 路由和兜底策略

3.1 固定输出格式是稳定性的地基

条件工作流的分支拐点高度依赖模型判定。如果模型输出自由文本，哪怕它说得对，你的解析代码也会被各种表述变异折磨到崩溃。所以第一优先级永远是让模型输出固定结构，最好是枚举值或 JSON。

langchain4j 里我常用两种方式实现。一种是直接在提示词里严格约束输出，适合简单的二选一或多选一。另一种是带响应格式的结构化输出，适合需要同时返回“分类结果 + 置信度 + 原因”的场景。

public record TicketClassifyResult(String category, double confidence) {} public interface TicketClassifier { @UserMessage(""" 请将工单内容分类为 TECH（技术支持）或 REFUND（退款）或 OTHER（其他）。 同时输出 confidence，取值范围 0 到 1，表示你对该分类的把握。 工单内容：{{it}} """) TicketClassifyResult classify(String ticketText); }

然后用 AiServices 创建实现并调用：

TicketClassifier classifier = AiServices.builder(TicketClassifier.class) .withChatModel(model) .build(); TicketClassifyResult result = classifier.classify(ticketText);

引入置信度之后，条件判断就不再是“非 A 即 B”，而是变成“A 的概率有多高”。这是一个非常重要的思维转变。在真实业务里，模型判断“这应该走退款分支”和“它有 70% 的可能走退款分支”是两个级别的可靠性，前者你敢直接执行，后者你应该加一步确认或兜底。

3.2 把 LLM 当成路由节点的提示词怎么写

当模型不是去做内容生成，而是纯粹做“路径选择”时，它的提示词和普通问答有本质区别。关键在于给它一个封闭的选项空间，并且禁止它创造新选项。

我整理了一套自己的路由提示词模板：

你是工作流路由器。从下列目标节点中选择一个最适合继续处理的节点。 只输出目标节点名称，不要输出解释。 可选节点： - TECH_DETAIL：处理技术问题排查 - REFUND_REVIEW：进入退款审核 - SAFETY_CHECK：进行安全风控检查 - HUMAN_AGENT：转人工 判断依据： 1. 如果内容涉及资金、退款、发票，优先 REFUND_REVIEW； 2. 如果内容涉及报错、无法使用、如何配置，优先 TECH_DETAIL； 3. 如果内容包含辱骂、威胁或账号安全相关，优先 SAFETY_CHECK； 4. 若无法确定，输出 HUMAN_AGENT。 用户内容： {{it}}

这套模板的设计要点有三个。第一是“封闭选项”，让模型在给定集合里选，而不是自由生成；第二是“按优先级排列的依据”，相当于把业务专家的排序经验直接喂给模型；第三是“无法确定就走人工”，给所有意外情况一个安全的出口。

实战里我踩过一个坑：一开始没用安全出口，模型遇到语义含糊的工单就会随机选一个，导致分流结果像抽签一样不稳定。加了一行“无法确定就输出 HUMAN_AGENT”之后，分流质量立刻提升了，而且很多误判被自然地引导到人工通道里处理了。

3.3 规则兜底：不是每个判定都需要模型

条件工作流最容易犯的另一个错误是“什么都问模型”。实际上，很多判定用正则或关键词就能稳定解决，而且确定性逻辑不会引入随机性。我的建议是采用“规则在前、模型在后”的混合策略。

举个例子，客服工单里如果包含“退款”“发票”“退款失败”等强词，我会直接走退款分支，根本不需要模型来判断。只有规则匹配不到强特征时，才轮到模型出手。这样既省 token，又避开模型在强规则场景下的误判。

public class RuleFirstClassifier { private static final List<String> STRONG_REFUND_WORDS = List.of("退款", "发票", "退钱"); private static final List<String> STRONG_TECH_WORDS = List.of("报错", "打不开", "配置", "接口"); public String classifyByRule(String ticketText) { if (STRONG_REFUND_WORDS.stream().anyMatch(ticketText::contains)) { return "REFUND"; } if (STRONG_TECH_WORDS.stream().anyMatch(ticketText::contains)) { return "TECH"; } return null; } }

在条件工作流里，我会把规则判定和模型判定封装到一个节点里：先跑规则，命中就直出结论；没命中再问模型；如果模型给出的置信度低于 0.6，也走人工。本质上是一个“层层降级”的判断链。

3.4 把路由能力封装成可复用组件

条件工作流里通常会存在多个判断点，比如先判断工单类别，再判断是否触发安全风控，再判断答方案是否超出知识库置信度。这些判断点都有同一个需求：给定文本或数据，从限定选项里选一个。把这段逻辑抽成可复用组件很有价值。

public class ConditionRouter { private final ChatLanguageModel model; private final Map<String, RouterRule> fallbackRules; public String route(String[] targetNodes, String promptTemplate, String input) { for (RouterRule rule : fallbackRules.values()) { String hit = rule.match(input); if (hit != null) { return hit; } } String prompt = promptTemplate.formatted(input); String raw = model.generate(prompt); return normalize(raw, targetNodes); } }

每个需要判断的节点，只需要准备好自己的目标节点列表和提示词模板，然后调用 ConditionRouter，逻辑就完全复用了。后面的新流程加判断点，不再需要重新解决“模型输出不稳定、格式不统一、要加规则兜底”这些问题。

4. 完整实战：一个客服工单自动分派的条件工作流

4.1 业务拆解与分支设定

我把前面零散的点整合成一个可以落地的案例：客服工单自动分派系统。工作流入口是用户提交的一段工单文本，目标是尽量自动化解决问题，无法处理时转人工。

流程分支设计如下：

我把这三个分支做了优先级处理：安全风控优先于业务分类，只要命中敏感词，立刻进入安全节点，先冻结进一步操作；常规业务里，退款相关走退款支线，技术相关走技术支线。若中途任何节点判定“处理不了”，统一转向 humanNode。

节点之间通过 WorkflowContext 传递数据，包括工单文本、分类结果、风控结果、知识库答案等。

4.2 各节点实现与条件转移

先从入口分类节点看起：

public class ClassifyNode implements WorkflowNode { private final ConditionRouter router; @Override public NextAction execute(WorkflowContext ctx) { String ticketText = ctx.get("ticketText"); String[] targets = {"SAFETY", "TECH", "REFUND"}; String prompt = """ 识别工单请求类型，只输出下面之一： SAFETY：涉及攻击、辱骂、账号安全问题 TECH：涉及功能使用、报错排查 REFUND：涉及退款、发票、交易争议 工单内容：%s """.formatted(ticketText); String category = router.route(targets, prompt, ticketText); ctx.put("category", category); return switch (category) { case "SAFETY" -> NextAction.goTo("safetyNode"); case "REFUND" -> NextAction.goTo("refundNode"); default -> NextAction.goTo("techNode"); }; } }

安全节点做双重校验，一边是词库命中，一边是模型对情绪强度的判断。如果命中，直接把人转到人工，不带任何自动生成的解决方案，避免模型回应不当内容。

public class SafetyNode implements WorkflowNode { private static final List<String> RISK_WORDS = List.of("辱骂", "威胁", "投诉升级"); @Override public NextAction execute(WorkflowContext ctx) { String content = ctx.get("ticketText"); boolean risk = RISK_WORDS.stream().anyMatch(content::contains); Integer severity = modelSeverity(content); if (risk || severity >= 8) { ctx.put("safetyRisk", true); return NextAction.goTo("humanNode"); } return NextAction.goTo("techNode"); } }

技术节点会结合知识库结果生成回复，如果知识库覆盖度不够高，就转人工：

public class TechNode implements WorkflowNode { @Override public NextAction execute(WorkflowContext ctx) { String answer = knowledgeBase.search(ctx.get("ticketText")); int coverage = searchCoverage(ctx.get("ticketText"), answer); ctx.put("techAnswer", answer); ctx.put("techCoverage", coverage); if (coverage < 0.6) { return NextAction.goTo("humanNode"); } return NextAction.goTo("finishNode"); } }

退款节点略复杂。如果用户描述涉及金额、商品没到货等，模型输出结论之后，我会再用一组经验规则校验是否存在“高风险模式”，比如同账号频繁退款、金额异常高等。命中就转人工，避免自动操作引发资损。

public class RefundNode implements WorkflowNode { @Override public NextAction execute(WorkflowContext ctx) { String category = ctx.get("category"); int refundTimes = ctx.get("userRefundTimes"); boolean highRisk = refundTimes >= 3 || category.equals("REFUND_ABNORMAL"); if (highRisk) { return NextAction.goTo("humanNode"); } return NextAction.goTo("finishNode"); } }

4.3 循环与终止条件设计

条件工作流最容易出现的故障是节点之间相互跳转形成死循环。虽然引擎有全局最大步数保护，但只靠它兜底太粗鲁了，条件工作流在业务层要有自己的终止策略。

我在每个节点的输出里都会做一个隐式检查：同一个节点最多被访问 N 次。一旦超出，不管接下来的业务逻辑是什么，直接强制跳到 humanNode。因为连续两次经过同一个节点还解决不了问题，说明自动化流程已经无法收敛了，这时候最好的选择就是交给人工。

具体实现可以在 WorkflowContext 里维护一个访问计数 Map：

private final Map<String, Integer> visitCount = new HashMap<>(); public void recordVisit(String nodeName) { visitCount.merge(nodeName, 1, Integer::sum); } public int getVisitTimes(String nodeName) { return visitCount.getOrDefault(nodeName, 0); }

然后在工作流引擎里加一个兜底判断：

ctx.recordVisit(current); if (ctx.getVisitTimes(current) > 2) { current = "humanNode"; continue; }

这个“连续访问两轮就转人工”的策略，帮我在线上挡住过很多奇怪的 edge case。例如模型把“退款”误判成“技术问题”，技术节点处理完后又回到分类节点，再次误判，再次进入技术节点。没有访问次数保护的话，这个循环会一直持续到全局步数耗尽。

4.4 几组测试数据验证流程

为了验证工作流的行为符合预期，我准备了一组覆盖常见分支的用例：

注意第一行和第五行的对比：同样是 TECH 分类，知识库覆盖度不同，出口就不同。这正是条件工作流相对“一把梭”的优势——它能把“解决得了”和“解决不了”这两条路明确拆开，而不是让模型硬着头皮给一个可能错误的答案。

5. 踩坑记录与工程化建议

5.1 模型偶尔不按选项输出，二次校验要有兜底

每次模型调用都要求只输出枚举值，但真实环境里仍然会收到类似“退款”“技术问题”“SAFETY(安全)”这类带噪声的输出。直接把字符串拿去匹配分支，大概率匹配不上，导致流程抛异常。

我的办法是在路由组件里加一个 outputNormalizer，先把模型输出统一处理：转大写、去除括号及括号内容、去掉常见的中文描述后缀，再做精确匹配。如果还匹配不上，就按相似度从已有选项里选一个，比如“退款”就能和“REFUND”通过包含关系建立映射。

public String normalize(String raw, String[] targets) { String cleaned = raw.toUpperCase() .replaceAll("[()（【】\\[\\]：:].*$", "") .replaceAll("[^A-Z_]", "") .trim(); for (String target : targets) { if (cleaned.equals(target)) { return target; } } for (String target : targets) { if (cleaned.contains(target) || target.contains(cleaned)) { return target; } } return "HUMAN_AGENT"; }

从实际日志看，最安全的兜底还是“无法归一化时走人工”，千万不要保留一个“按空分支继续执行”的路径，那会让流程进入未定义状态。

5.2 模型调用的异常与超时怎么兜

条件工作流里每个节点都可能调用外部模型，而在线模型的延迟和失败频率比本地代码高得多。最直接的做法是给每个模型调用包上异常处理，失败时降级到规则分支或人工节点。

@Override public NextAction execute(WorkflowContext ctx) { try { String category = model.generate(prompt); return routeByCategory(category); } catch (Exception e) { log.warn("LLM classify failed, fallback to rule", e); String ruleResult = ruleClassifier.classifyByRule(ctx.get("ticketText")); if (ruleResult != null) { return routeByCategory(ruleResult); } return NextAction.goTo("humanNode"); } }

这个思路非常简单，但救了我很多次。有一次模型接口超时，如果是“一把梭”的 Agent，用户只会看到“服务异常”；而在条件工作流里，请求会静默落到规则分支，规则也没命中时再转人工，用户的体验是“问了个问题，有人工客服来接”，而不是直接报错。

5.3 工作流日志要能还原每一步决策

排查条件工作流问题时，最痛苦的不是代码 bug，而是你不知道某个节点当时为什么选了那条分支。所以日志不能只打“进入 XX 节点”，要把判定用的关键数据打出来。

我给自己定了一个相对固定的日志格式，每个节点执行时都输出同一款模板：

节点[TechNode] step=3 workflowId=abc123 输入: ticketText=系统报错后反复操作三次 输入: techCoverage=0.4 决策: coverage<0.6 -> 跳转 humanNode 输出: techAnswer=null

用这套日志格式，线上问题排查基本都是十分钟之内能定位：先看哪个节点跳的和预期不符，再看这个节点的输入数据是什么，找数据异常还是模型判定异常就很容易了。

5.4 什么时候不应该用条件工作流

条件工作流虽然好用，但不是一个全能容器。如果业务只有一种固定处理路径，只是中间需要调几次模型，那用顺序链就够了，引入条件工作流是过度设计。判断标准很简单：是否真的存在“不同输入走向不同分支”且“分支数量会持续增加”的迹象？如果没有，先保持简单。

另外，条件工作流也不适合极短流程。比如“用户输入一句话→模型输出一句话”这种简单对话，硬拆成节点反而增加维护成本，也会让响应链路变长，多一路模型调用的风险。我建议至少是两步以上、且每个步骤都有独立语义时，再考虑把它做成条件工作流。

我个人的体会是，条件工作流本质上是在“模型的自由发挥”和“代码的确定性控制”之间找一个平衡。模型负责它擅长的语义理解，代码负责它擅长的分支控制和兜底。这个分离带来的最大好处，是每一次由模型做出的决策都有迹可循，而每一个不确定的决策都有一个确定性的出口。

最后再分享一个实战小技巧：给每个分支出口起一个稳定的枚举值，把“finishNode”“humanNode”这种名称当成接口协议来管理，宁可多加一层映射，也不要让节点名散落在字符串比较里。后续你大概率会在这些出口上挂统计指标、告警、甚至追加子流程，稳定的命名能让所有后续工作都轻松很多。