企业官网建设流程全解析

做 Java 服务端开发这么多年，AI 智能体这套东西真正让我动心的不是模型本身，而是工作流。2024 年我第一次把 LangChain4j 引入项目时，只是图它省事，后来 LangGraph4j 出来，把编排从“链”升级成“图”，我才觉得“低代码工作流 + 智能体”在 JVM 生态里终于有了正经的底座。这篇文章是我基于这两个库设计低代码工作流通用智能体平台的架构复盘，内容包括选型逻辑、DSL 设计、图执行引擎、智能体内置能力，以及生产环境里踩过的坑。适合正在做 Java 侧 AIGC 平台、智能体编排或者企业内部工作流引擎的开发者参考。

1. 为什么是 LangChain4j + LangGraph4j：Java 智能体技术栈选型复盘

1.1 裸调大模型 API 的痛点：从三十行代码到三十个问题

很多 Java 团队接入大模型的第一步都是“裸调 API”。用一个 RestTemplate 或者 OkHttp 请求 OpenAI 兼容接口，三十行代码就能返回一段生成结果，Demo 跑起来非常爽。但真正的痛苦是从第二个需求开始的：要流式输出，要函数调用，要多轮记忆，要切换模型供应商，要统一 Prompt 管理。你会发现团队里每个人都在封装自己的 ChatClient，封装出来的接口五花八门，抽象程度从“只传 prompt”到“自带重试和熔断”的都有。

我举一个真实经历。早期项目里，成员 A 用 WebClient 封装，成员 B 用 OkHttp，还有人把 Prompt 模板写在常量类里，另有人塞进数据库配置表。等要做第三个智能体功能时，光“如何统一维护 system prompt”这个问题就开了三次会。这不是谁的代码写得差，而是缺少一个统一的抽象层。LangChain4j 解决的正是这个问题：它把大语言模型、聊天记忆、工具调用、文档检索收敛成一组 Java 接口，让上层业务只面向接口开发，不再关心具体模型厂商的 HTTP 细节。

1.2 LangChain4j 与 Spring AI 不是二选一：关注编排能力

“现在到底用 Spring AI 还是 langgraph4j？”——我几乎每次分享都会被问到类似问题。这里要先说清楚：Spring AI 和 LangChain4j 不是竞争关系，它们解决问题的层面不一样。

Spring AI 的思路是“把 AI 能力融进 Spring 生态”，对 Spring Boot 自动装配、RestClient、Web 响应做了深度整合，适合只想在现有 Spring 应用里快速加一个对话接口的团队。但如果你要搭的是一个完整的工作流引擎，需要 RAG、动态工具路由、记忆窗口、多模型切换这些能力，Spring AI 目前的抽象粒度还不够，很多编排逻辑仍然要自己写。

LangChain4j 则更接近 Python 生态里 LangChain 的思路。它的 AiServices 是完整的服务抽象，把 ToolSpecification、ChatMemory、ContentRetriever、DocumentSplitter 这些零件都做成了标准接口。低代码平台要的不是“一个聊天接口”，而是“一组可组合的能力积木”。这一点 LangChain4j 明显更合适。而且 LangGraph4j 就是 LangChain4j 同一体系下的产物，两个库的版本联动、代码风格、语义模型都比较一致，协作成本低。如果你看到网上有人争论“spring ai 还是 langgraph4j”，本质是把“模型接入”和“流程编排”混为一谈了。

1.3 LangGraph4j 补上的编排短板：从线性 Chain 到状态图

LangChain4j 早期有个 Chain 抽象，本质是线性执行：一个步骤接一个步骤。但真实业务里的智能体绝不是线性的——大模型需要判断“我是该调工具，还是该直接回答”，调完工具还要回到模型继续思考，这就是一个循环；流程中间要按意图分支，要并行跑多个检索，要挂起等人审批。线性 Chain 表达不了这些需求。

LangGraph4j 把 Python LangGraph 的 StateGraph 模型带到了 JVM 生态：State（状态）、Node（节点）、Edge（边）、Conditional Edge（条件边）、Checkpoint（检查点）。这套模型天然适合描述工作流，它把“流程控制”和“业务逻辑”彻底解耦。我们的低代码平台能做起来，核心原因就是直接用了 LangGraph4j 当执行引擎，而不是自己从零写一个有向图调度器。自己写调度器不是不行，但状态管理、条件路由、持久化恢复这些细节很容易翻车，复用成熟实现是更稳妥的选择。

2. 平台三个抽象层：DSL、运行时与集成分工

2.1 工作流 DSL：连接画布与引擎的通用语言

低代码平台有一个容易被忽略的原则：可视化画布只是表象，真正的核心是画布背后的 DSL。每一次节点拖拽、连线、属性修改，本质上都是在编辑一份文档；保存、发布、版本回滚，操作对象也是这份文档。所以我在设计平台时，第一件事是定义 DSL，而不是先画 UI。

DSL 我选了 JSON 格式。原因很实际：前端解析方便、后端 Java 框架都有现成绑定、存数据库和做版本 diff 都容易。一个最小的工作流定义长这样：

{ "workflowId": "aftersale_flow", "name": "售后处理流程", "variables": { "orderId": "string", "userIntent": "string" }, "nodes": [ { "id": "start", "type": "start" }, { "id": "classify", "type": "llm_classify", "model": "deepseek-chat", "prompt": "判断用户意图：售后/投诉/咨询" }, { "id": "rag", "type": "retriever", "collection": "product_manual", "topK": 3 }, { "id": "agent_chat", "type": "agent", "mode": "rag_chat" }, { "id": "human_approval", "type": "human_approval", "approvers": ["ops_group"] }, { "id": "end", "type": "end" } ], "edges": [ { "from": "start", "to": "classify" }, { "from": "classify", "to": "rag", "condition": { "field": "intent", "op": "equals", "value": "after_sale" } }, { "from": "classify", "to": "human_approval", "condition": { "field": "intent", "op": "equals", "value": "complaint" } }, { "from": "rag", "to": "agent_chat" }, { "from": "agent_chat", "to": "end" } ] }

DSL 里只有两类核心实体：节点和边。这是所有图结构的本质，也是 LangGraph4j 能直接映射的前提。低代码平台的真正价值在于：业务分析师在画布上拖出这个流程时，系统自动生成这样一份 JSON，全程不碰代码。

2.2 运行时层：把 DSL 编译成 StateGraph

有了 DSL，接下来是运行时层。运行时做的事情很单纯：把 JSON 翻译成一个 LangGraph4j 的 StateGraph，然后执行它。翻译逻辑非常机械，因为 DSL 节点和 LangGraph4j 的 Node 一一对应，DSL 边和 Edge 一一对应。

public CompiledGraph build(WorkflowDefinition definition) { StateGraph<WorkflowState> graph = new StateGraph<>(WorkflowState.SCHEMA); NodeFactory factory = new NodeFactory(nodeRegistry); for (WorkflowNode node : definition.getNodes()) { graph.addNode(node.getId(), factory.create(node)); } graph.addEdge(START, definition.getStartNodeId()); for (WorkflowEdge edge : definition.getEdges()) { if (edge.hasCondition()) { graph.addConditionalEdges( edge.getFrom(), state -> evaluateCondition(edge.getCondition(), state), Map.of("true", edge.getTo(), "false", edge.getFallback() == null ? END : edge.getFallback()) ); } else { graph.addEdge(edge.getFrom(), edge.getTo()); } } return graph.compile(); }

这段代码是平台里最早写出来、之后改动最少的部分。因为 DSL 和 LangGraph4j 的模型是严格对应的，翻译过程中没有太多业务判断。真正花心思的地方在节点工厂：每个类型的节点，invoke 方法里到底执行什么逻辑，如何读取 State、如何更新 State，这些才是平台能力的核心。

2.3 集成层：模型、向量库与外部系统的适配器注册表

第三层是集成层，也是最容易被低估的一层。低代码平台要能接不同的模型供应商（OpenAI、DeepSeek、通义千问、本地 Ollama），要能接不同的向量库（pgvector、Milvus、Elasticsearch），还要能接企业内部的订单系统、库存系统、审批流。

这部分我采用了“适配器 + 注册表”的模式：每种外部能力对应一个 adapter，启动时注册到平台的 nodeRegistry 里。DSL 节点通过 type 字段找到对应 adapter，运行时不硬编码具体实现。比如模型节点里配置 model: "deepseek-chat"，运行时就从模型注册表找到 DeepSeek 的 ChatLanguageModel 实例。这里要感谢 LangChain4j 的统一抽象——ChatLanguageModel、EmbeddingModel 这些接口屏蔽了各家厂商的差异，新增一家模型供应商，只需要写一个 adapter 注册进去，所有存量工作流立即可用。向量库同理，通过 EmbeddingStore 接口做隔离，业务节点不需要关心底层是 pgvector 还是 Milvus。

3. 工作流 DSL 与节点类型：低代码平台最关键的决策

3.1 节点类型体系：把“智能体”设计成一种特殊节点

设计节点类型时，我给自己定了一条原则：内置类型尽量少，但每种类型都要有足够强的表达能力。平台最终沉淀出七种核心节点：

这里最关键的设计决策是：agent 节点不是一个普通节点，它内部是一个循环子图——模型判断是否要调工具，需要工具就执行工具，拿结果回到模型继续思考，直到模型认为可以给出最终答案。在画布上，用户看到的只是一个“智能体”节点，但展开后它内部是一整套 mini 工作流。这个设计让“智能体”从平台的插件变成了平台的一等公民。用户不需要理解循环和工具调用的细节，只需要把外部工具配置好，剩下的由运行时完成。

3.2 条件与分支：别用复杂表达式为难业务用户

工作流的核心能力之一是分支。但分支怎么表达，很有讲究。我先尝试过在边上写复杂 SpEL 表达式，业务分析师一看就摇头，调试也困难。后来改成了“条件节点 + 简单运算符”方案：每个条件只支持下表的五种操作，变量来自 State，值来自常量或另一个变量。

这个设计带来的结果是：可视化编辑器里只需要一个下拉框选字段、一个下拉框选运算符、一个输入框填值，业务人员十分钟就能上手。技术敏感性低的人也能看懂 DSL 文件里的条件结构。不要小看这个决策，低代码平台能不能被业务部门真正用起来，往往取决于这类细节。把复杂性藏在 DSL 里，把简单留给用户，是这个模块的核心思路。

3.3 可视化画布到 DSL 的映射与版本管理

画布编辑器的交互借鉴了 n8n、Dify、Coze 这些成熟产品的经验，但映射逻辑是自研的。核心规律就三条：拖一个节点，就是往 nodes 数组加一条记录；拉一条连线，就是往 edges 数组加一条记录；右侧属性面板的修改，就是更新对应节点的 config。保存按钮把当前画布序列化成 DSL JSON，发布操作把 DSL 写入数据库并生成一个版本号。

有一个工程细节值得多说一句：画布坐标、缩放比例、节点折叠状态这类 UI 信息也需要存，但不能混进 DSL 核心。我把它放在 DSL 文档的 _ui 字段里。这样 DSL 主体保持纯净，未来想换成另一套可视化编辑器，或者接入第三方编排工具，都只需要适配 _ui 部分，核心引擎完全不受影响。版本管理也围绕 DSL 来做：每次发布生成不可变的版本记录，回滚就是把某个历史版本重新置为当前版本。调试人员可以把任意版本的 DSL 单独拉出来跑测试。

4. LangGraph4j 图执行机制拆解：State、边与 Checkpoint

4.1 State 是工作流的共享内存

LangGraph4j 的核心抽象是 State。你可以把它理解成工作流的“共享内存”：所有节点共享同一个 State 对象，每个节点读取自己关心的部分，更新自己负责的部分。例如分类节点把 intent 写进 State，后面的 RAG 节点读取 intent 决定检索哪份文档，审批节点读取审批结果决定流程走向。

代码里 State 通常是一个 Java 类，配一个 Schema 描述字段：

public class WorkflowState { Map<String, Object> variables; List<ChatMessage> messages; String intent; String answer; String lastError; public static final StateSchema<WorkflowState> SCHEMA = new StateSchema<>( WorkflowState::new, Map.of( "variables", WorkflowState::getVariables, "messages", WorkflowState::getMessages, "intent", WorkflowState::getIntent, "answer", WorkflowState::getAnswer, "lastError", WorkflowState::getLastError ) ); }

我第一次设计这个类时犯过一个错误：图省事，把整个业务 variables 直接用 Map<String, Object> 塞进 State，不定义 schema。结果节点之间靠魔法字符串读写变量，拼写错误到运行期才暴露，有些 bug 排查了两天才发现是 key 少了一个字母。LangGraph4j 的 StateSchema 写法确实啰嗦，但强制执行了字段声明和类型检查，长期看这个啰嗦非常值得。

4.2 节点、普通边与条件边的组合方式

LangGraph4j 构建图的方式很直白：addNode 注册执行逻辑，addEdge 连接普通边，addConditionalEdges 连接条件边。一个节点可以有多条出边，通过条件函数返回不同的目标节点 ID 实现分支；如果条件函数返回前置节点 ID，图就产生了环，这正是智能体循环的本质。

StateGraph<WorkflowState> graph = new StateGraph<>(WorkflowState.SCHEMA) .addNode("classify", new ClassifyNode()) .addNode("agent", new WorkflowAgentNode()) .addNode("http_call", new HttpCallNode()) .addNode("human", new HumanApprovalNode()) .addEdge(START, "classify") .addConditionalEdges("classify", state -> "complaint".equals(state.getIntent()) ? "human" : "agent", Map.of("human", "human", "agent", "agent")) .addConditionalEdges("agent", state -> state.getMessages().getLast().hasToolCall() ? "http_call" : END, Map.of("http_call", "http_call", END, END)) .addEdge("http_call", "agent") .addEdge("human", END) .build();

注意 addConditionalEdges 的第三个参数是“条件结果 → 目标节点”的映射，这个映射的 key 必须覆盖条件函数所有可能的返回值。漏掉一个 key，编译期不报错，运行期直接提示找不到目标边。这是我刚上手时踩过的坑，排查了整整一个下午，最后发现是 Map.of 少写了 END 这个 key。建议大家在封装层做一道校验，在编译图之前扫描所有条件边，对照条件函数的返回枚举值检查映射完整性。

4.3 Checkpoint：暂停、恢复与回放的基础

工作流经常需要暂停。人工审批节点可能挂起好几个小时，期间系统不能把状态丢掉。LangGraph4j 的 Checkpoint 机制就是为这个场景设计的：每个节点执行完成后，整个 State 可以被持久化到外部存储，流程可以从 Checkpoint 恢复执行。

这个机制在调试时尤其好用。可以把一次执行过程的中间状态 dump 出来，逐段检查每个节点写入的字段，再配合回放功能，用同一份输入反复跑同一个子图，定位是哪个节点产生了异常数据。生产环境里 Checkpoint 要落到数据库或者对象存储，不要用内存实现。内存方案跑单机 Demo 没问题，一旦实例重启，所有挂起的人审批流程全部丢失，业务上完全不可接受。关于持久化的并发和事务问题，我在第 7 节会展开讲。

5. 智能体内置能力：RAG、工具调用与会话记忆

5.1 RAG 检索：从“加一个节点”到完整管线

很多团队把 RAG 理解成“加一个检索节点”，实际落地会撞上一连串问题：文档切多大块合适？Embedding 模型选哪个？检索结果怎么排序？相似度阈值定多少？这些没有一个放之四海皆准的答案，所以我在平台里把 RAG 拆成了节点配置项，让用户按自己要调整。

我的默认组合是：LangChain4j 的 DocumentSplitter 按 500 token 左右切块，中文场景用 bge-m3 或者同级别的国产 Embedding 模型，检索之后接一个 rerank 节点做重排。实测下来，重排对最终回答质量的影响非常大，尤其当候选文档数量超过三个的时候，不重排和重排的区别肉眼可见。平台层面要做的，是把文档导入、切片、向量化的过程封装成管理接口，用户只需要上传文档并指定 collection 名称，后续检索节点通过 ContentRetriever 接口访问即可。LangChain4j 的 ContentRetriever 和 EmbeddingStore 抽象在这里帮了大忙，业务节点不需要关心向量库是 pgvector 还是 Milvus。

5.2 工具调用：让智能体自主操作用户注册的外部能力

智能体和普通聊天机器人最大的区别是工具调用。LangChain4j 用 @Tool 注解可以非常简单地给模型注册工具：

@Tool("根据订单号查询售后订单状态") public String queryAfterSaleStatus(String orderId) { return afterSaleService.queryStatus(orderId); }

在平台里，我把每个“外部系统连接器”都注册成一个工具。数据库节点、HTTP 节点，既可以被工作流显式调用，也可以被智能体“自主决定”调用。这个设计带来了一种新的编排思维：你不必把所有交互路径画死，只要把工具挂到智能体节点上，模型会根据用户问题和上下文自己决定何时调用工具。低代码平台的“低”在这里体现为：用户不用写函数调用协议，不用解析 function calling 的参数 schema，只需要在界面上勾选“该智能体可用哪些工具”，剩下的由运行时完成。

工具注册表还需要支持动态参数。比如 HTTP 工具，入参可能来自 State 里的某个字段，也可能来自用户问题中提取的实体。我的做法是给工具加一层薄薄的参数绑定配置，把 State 字段和工具参数的映射关系单独存起来，运行时先解析绑定值，再调用真正的工具方法。这样既保住了动态性，又没有把复杂度抛给上层节点。

5.3 会话记忆：多轮交互的上下文策略

工作流里涉及多轮对话时，记忆是绕不开的话题。LangChain4j 的 ChatMemory 有几种实现，平台需要在配置里暴露策略选项，而不是写死一种。我的建议是：

平台默认按 sessionId 隔离，每个会话对应一个 ChatMemory 实例。会话结束后可以将记忆归档，也可以按业务规则清除。对涉及敏感数据的场景，记忆内容要支持脱敏和过期自动清理，这部分最好在设计初期就考虑，否则后期补会很痛苦。我在实际项目里就遇到过：第一次把用户身份证号存进了记忆，后来做安全评审时不得不把所有历史会话翻出来清洗，非常被动。

6. 从 Maven 依赖到第一个可运行工作流

6.1 依赖与版本选择：先去看官方文档再动手

官方文档在 Maven Central 上发布新版本的速度非常快，我这里给出的版本号只代表当前测试环境用的版本，大家动手前一定要先去查“langchain4j 开发文档”和“langgraph4j 官方文档”，确认最新版本和版本配套关系。

<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j</artifactId> <version>1.0.0-beta1</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-open-ai</artifactId> <version>1.0.0-beta1</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langgraph4j</artifactId> <version>1.0.0-beta1</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-easy-rag</artifactId> <version>1.0.0-beta1</version> </dependency>

这里想强调一个坑：langgraph4j 和 langchain4j 的版本必须是配套的。版本不匹配时，编译期不一定报错，但运行期可能冒出奇怪的 NoSuchMethodError。另外，OpenAI 兼容协议这个模块很实用，DeepSeek、通义、本地 Ollama 这类服务都可以通过它接入，只需要改 baseUrl 和 modelName，不需要为每个厂商单独引入 SDK。

6.2 最小可运行示例：分类、检索、生成

我们做一个最简单的三节点工作流：接收用户问题 → LLM 分类 → 检索文档 → 生成回答。先定义状态类，再定义节点执行逻辑，最后组装图并执行。

public class MinimalWorkflowDemo { static ChatLanguageModel model = OpenAiChatModel.builder() .apiKey(System.getenv("DEEPSEEK_API_KEY")) .baseUrl("https://api.deepseek.com/v1") .modelName("deepseek-chat") .build(); public static void main(String[] args) { StateGraph<WorkflowState> graph = new StateGraph<>(WorkflowState.SCHEMA) .addNode("classify", state -> { String intent = model.generate("判断意图，只返回一个词：" + state.getUserQuestion()); state.setIntent(intent.trim()); return state; }) .addNode("retrieve", state -> { String docs = retriever.findRelevant(state.getIntent()); state.setRetrievedDocs(docs); return state; }) .addNode("answer", state -> { String answer = model.generate("参考资料：" + state.getRetrievedDocs() + "\n问题：" + state.getUserQuestion()); state.setAnswer(answer); return state; }) .addEdge(START, "classify") .addEdge("classify", "retrieve") .addEdge("retrieve", "answer") .addEdge("answer", END) .build(); CompiledGraph compiled = graph.compile(); WorkflowState state = new WorkflowState(); state.setUserQuestion("我的订单发货了吗？"); compiled.invoke(state); System.out.println(state.getAnswer()); } }

节点类里如果只有几行逻辑，用 lambda 直接写是最快的。但是节点一旦复杂，比如要处理多个工具调用、要写日志、要上报指标，我建议还是抽成独立类，每个节点一个类，方便单元测试。注意节点方法必须返回 State 或者 State 的局部更新，返回值会覆盖图引擎内部的共享状态。如果你什么都不返回，流程不会继续，这是一个刚接触的人容易忽略的约定。

6.3 调试与观测：日志、回放与 Mock

工作流引擎的调试和普通接口调试不太一样。普通接口可以断点跟，工作流涉及多个节点多次 LLM 调用，断点跟效率太低。我的三个调试手段：

第一，打开 LangGraph4j 的执行日志，观察节点流转顺序。每个节点进入和退出的日志都要打，特别是 State 字段变化，建议在节点退出时打印关键字段的摘要。第二，利用 Checkpoint 回放能力。把一次失败执行的 state 序列化保存下来，用测试代码从某个中间节点重新执行，不断调整节点逻辑，直到输出正确。这比反复跑全流程省太多时间。第三，在单元测试里用 MockChatModel 代替真实模型。Mock 返回预先写好的固定内容，用来验证图的拓扑、条件分支的走向和状态传递是否正确，不消耗 token，跑得也快。真实模型只用在联调阶段。

7. 生产环境踩坑：序列化、并发与故障恢复

7.1 State 序列化：Checkpoint 落地的第一道坎

生产环境第一个坑出现在 Checkpoint 持久化。WorkflowState 如果直接交给 JSON 框架序列化，里面的字段类型稍微特殊一点就会炸。我遇到过的典型案例：State 里不小心放了一个模型供应商的客户端对象，序列化失败，导致整个工作流挂起；还有业务往 variables 里塞了一个自定义类，反序列化时找不到对应的构造函数。

解法可以总结为三条。第一，State 只放基础类型、List、Map，所有自定义业务对象统一转成 JSON 字符串字段，或者实现自定义序列化器。第二，State 类尽量用 record 或者只读字段，不要放可变的自定义复杂对象。第三，一定要给 Checkpoint 序列化写集成测试，每个节点写入的字段都必须经过一次序列化-反序列化往返验证。这个测试放在 CI 里，日常改动就能立刻发现问题，不用等到发布后炸。

7.2 节点并发：无状态设计与线程池节奏

LangGraph4j 的节点在执行时运行在图的线程池里，多个工作流实例会并发执行同一个节点类。如果你的节点里注入了有状态的 Bean，比如一个共享的 SimpleDateFormat、一个非线程安全的 StringBuilder 累积器，就会在一些特定条件下出现奇怪的错误，而且极难复现。

我的经验是：节点类一律设计成无状态。所有数据都从 State 传入、从 State 传出，节点内部只做无状态的计算和调用。需要用到连接池、HTTP 客户端的 Bean，必须保证线程安全。另外，LLM 调用通常耗时几秒到几十秒，如果平台同时跑大量工作流实例，要看好执行线程池的配置：队列长度、核心线程数、最大线程数、任务超时。每个节点最好都设独立的超时时间，避免某个外部 API 一直不返回，把整个线程池拖死。

7.3 故障恢复：人工审批、幂等键与事务边界

第 4 节说过 Checkpoint 用于暂停恢复，但真正做人工审批流程时，有几个问题必须处理。首先是 Checkpoint 持久化和业务数据库操作的一致性问题。我的实现里，HumanApprovalNode 会先创建一条审批任务，再更新 Checkpoint，如果两个动作不在同一个事务边界里，可能出现“审批单创建成功，但工作流状态没存上”的情况。最终方案是把 Checkpoint 更新和业务操作放进同一个本地事务，再通过事务消息保证最终一致。

其次是工具调用的幂等性。HTTP 节点调用外部 API 失败后如果自动重试，而对方接口不保证幂等，就可能造成重复扣款、重复下单。我们在工具注册表里增加了“幂等键”支持，每次工具调用会生成一个 requestId，外部系统可以拿它做去重。这不是 LangGraph4j 的职责，但作为一个通用智能体平台，必须把这类工程问题兜住。

最后是节点级的失败重试策略。LLM 调用偶发超时很常见，简单的策略是退避重试两到三次；人工审批节点超时后可以配置转交或者自动走默认分支。重试要配合 Checkpoint 的状态快照，保证重试时不会因为中间状态不一致而二次污染数据。把这几条想清楚，平台才算达到可以接生产业务的标准。

最后说点自己的体会。搭建这个平台，最关键的不是把 LangGraph4j 的 API 背得多熟，而是把 DSL、图执行、能力接入这三个层次想清楚。我见过不少人一上来就画画布、写节点，最后代码全堆在一起，改一个分支逻辑牵一发动全身。我的开发路径是先花两周定义 DSL 和节点协议，再花一周把 LangGraph4j 包装成运行时，之后所有功能迭代都在这套框架里叠加，速度反而越来越快。如果你也在做类似的东西，建议从最小的端到端流程开始，先两个节点、一个分支、一个工具，跑通了再往上叠能力。中途遇到问题，优先去看官方文档和源码，比在网上翻零散的博客靠谱得多。