1. Java 开发者为什么需要 Dify 工作流如果你是一名 Java 后端最近大概率会遇到这样的需求产品经理跑过来说“咱们的工单系统能不能加个 AI 自动回复”“客服对话能不能自动分类再流转”“用户传的 Excel 能不能自动分析出结论”。你第一反应可能是自己写 Prompt、调模型 API、拼上下文、处理多轮状态——写完之后发现维护成本极高改一个流程要动一堆 if-else。Dify 的工作流Workflow和对话流Chatflow解决的正是这个问题它把 AI 对话拆成可视化节点条件分支、HTTP 请求、代码节点、变量提取都能在画布上编排Java 侧只需要通过标准 REST 接口触发和接收结果。换句话说Dify 负责“AI 流程编排”Java 负责“业务逻辑与数据落库”两者通过 HTTP 解耦各干各擅长的事。这套组合适合谁适合已经有一套 Spring Boot 业务系统、想把 AI 对话能力嵌进去但不想重写架构的团队也适合个人开发者想快速验证一个“对话 业务动作”的闭环。我试过把工单自动分类和回复生成放进 DifyJava 侧只保留鉴权和持久化代码量比纯手写少了大概三分之二。下面按“环境准备 → 工作流编排 → Java 调用 → 验证 → 排障”的顺序走一遍每一步都给可复制的配置和代码。2. 前置准备Dify 侧与统一 API 通道2.1 Dify 的两种编排形态怎么选在动手之前先分清两个概念选错了后面会返工形态适用场景关键特征Chatflow多轮对话、客服机器人、语义搜索有会话变量、上下文记忆、开场白Workflow自动化任务、数据分析、内容生成无会话状态、一次性输入输出、支持定时Java 业务集成里客服类走 Chatflow批处理类走 Workflow。本文以 Chatflow 为主因为对话交互是最高频的诉求Workflow 的调用方式几乎一致只是接口路径不同。2.2 模型接入用 TaoToken 统一 Key 与 API 通道Dify 本身不提供模型需要配置模型供应商。如果你同时用多个模型比如对话用 Claude、代码节点用别的逐个配 Key 会很乱。我习惯用 TaoToken 做统一入口一个 Key 覆盖多种模型Dify 里只需要填一个 OpenAI 兼容的 Base URL 就行。操作路径登录 TaoToken 控制台在 API Keys 页面创建一个 Key复制备用。然后在 Dify 的「设置 → 模型供应商 → OpenAI-API-compatible」里填写API Base URLhttps://taotoken.net/apiAPI Key你刚创建的那串模型名称按你开通的模型填比如claude-sonnet-4-5之类注意Base URL 结尾不要多加/v1Dify 的兼容层会自己拼接路径多写一层会 404。这一点我在配置时踩过报错信息是model not found其实是路径重复了。配好之后点「测试」能返回模型列表就说明通道通了。这一步是整个链路的地基地基不稳后面全白搭。2.3 Java 侧环境清单JDK 17 及以上Spring Boot 3.x 要求Spring Boot 3.2.x依赖spring-boot-starter-web、spring-boot-starter-webflux用 WebClient 做流式、lombok一个能访问 Dify 服务的网络环境Maven 关键依赖片段dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency3. 可复制配置Dify 工作流骨架与 Java 调用3.1 Dify Chatflow 节点编排在 Dify 里新建一个 Chatflow按下面的骨架拖节点开始节点定义输入变量user_input字符串、user_id字符串LLM 节点系统提示词写“你是工单助手判断用户意图属于[退款/咨询/投诉]之一只输出类别词”条件分支节点根据 LLM 输出走不同分支HTTP 请求节点调用你 Java 侧的/api/ticket/create接口把分类结果和用户输入传过去LLM 节点回复生成根据 Java 返回的工单号生成自然语言回复结束节点输出reply和ticket_id关键配置在 HTTP 请求节点请求体用变量引用{ userId: {{user_id}}, category: {{llm_category}}, content: {{user_input}} }请求头加上你 Java 服务的鉴权 Token。这个节点是 Java 与 Dify 的“握手点”务必保证字段名和 Java DTO 完全一致大小写敏感。3.2 Java 侧接收 Dify 回调的 ControllerDify 的 HTTP 节点会主动调你的服务所以先写接收端RestController RequestMapping(/api/ticket) public class TicketController { PostMapping(/create) public ResponseEntityMapString, Object create(RequestBody TicketRequest req) { // 模拟落库 String ticketId TK System.currentTimeMillis(); // 实际场景这里调用 Service 写数据库 MapString, Object result new HashMap(); result.put(ticketId, ticketId); result.put(status, CREATED); return ResponseEntity.ok(result); } } Data class TicketRequest { private String userId; private String category; private String content; }Dify 拿到ticketId后可以在后续 LLM 节点里引用生成“您的工单号是 TKxxx”这样的回复。3.3 Java 侧调用 Dify 对话接口业务系统主动发起对话时用 WebClient 调 Dify 的 Chatflow 接口Service public class DifyChatService { private final WebClient webClient; public DifyChatService() { this.webClient WebClient.builder() .baseUrl(https://你的dify域名/v1) .defaultHeader(Authorization, Bearer app-你的Dify应用Key) .defaultHeader(Content-Type, application/json) .build(); } public String chat(String userId, String input) { MapString, Object body new HashMap(); body.put(inputs, Map.of()); body.put(query, input); body.put(response_mode, blocking); body.put(user, userId); return webClient.post() .uri(/chat-messages) .bodyValue(body) .retrieve() .bodyToMono(String.class) .block(); } }response_mode选blocking适合同步业务选streaming则返回 SSE 流适合前端打字机效果。Java 侧如果要用流式把返回类型改成FluxString即可。3.4 配置文件关键片段application.yml里把 Dify 地址和 Key 外置别硬编码dify: base-url: https://你的dify域名/v1 app-key: app-xxxxxxxx connect-timeout: 5000 read-timeout: 60000读超时给足因为 LLM 节点串行执行时整体耗时可能到十几秒默认 30 秒有时不够。4. 验证请求与成功结果4.1 先用 curl 验证 Dify 通道在写 Java 之前先用 curl 确认 Dify 应用本身是通的curl -X POST https://你的dify域名/v1/chat-messages \ -H Authorization: Bearer app-你的Key \ -H Content-Type: application/json \ -d { inputs: {}, query: 我要退款订单号 12345, response_mode: blocking, user: test-user-001 }预期返回里能看到answer字段包含工单号和回复文案metadata里有耗时信息。如果这一步就失败先别碰 Java回到 Dify 的「日志与标注」页面看节点执行详情哪个节点红了就查哪个。4.2 再验证 Java 端到端启动 Spring Boot 后用 Postman 或 curl 调你自己的接口curl -X POST http://localhost:8080/api/chat \ -H Content-Type: application/json \ -d {userId:u001,input:我要退款订单号 12345}成功时你会看到Dify 先分类为“退款”触发 HTTP 节点调你的/api/ticket/createJava 返回工单号Dify 再生成带工单号的回复。整条链路跑通后日志里应该能看到两次请求——一次是 Java 调 Dify一次是 Dify 回调 Java。4.3 模型通道验证如果你想单独确认 TaoToken 通道是否正常可以直接在模型对话页面发一条测试消息或者用 API 方式curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer 你的TaoToken Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role:user,content:你好}] }返回正常就说明统一通道没问题Dify 里配的模型也能用。5. 本篇常见错排查报错一Dify 调 Java 接口 401。大概率是 HTTP 节点里的鉴权头没配或者 Java 侧拦截器把 Dify 的请求拦了。检查 Dify HTTP 节点的 Headers 配置以及 Java 的 SecurityConfig 是否放行了该路径。报错二model not found或invalid api key。回到 2.2 节检查 Base URL 是否多写了/v1Key 是否复制完整前后有空格也会失败。TaoToken 的 Key 在控制台可以重新生成别用截图里的旧 Key。报错三Java 侧读超时。把read-timeout调到 60000 以上。如果 Dify 工作流里有多个 LLM 节点串行整体耗时会更长必要时把不依赖前序结果的节点改成并行分支。报错四变量引用为空。Dify 里{{user_input}}这种引用变量名必须和开始节点定义的完全一致。常见坑是开始节点叫queryHTTP 节点里写{{user_input}}结果传过去是空字符串。报错五中文乱码。Java 侧RequestBody默认 UTF-8但如果 Dify HTTP 节点没设Content-Type: application/json; charsetutf-8中文可能变问号。在 Dify 节点 Headers 里显式加上 charset。报错六回调地址填了 localhost。Dify 如果部署在容器或远程服务器localhost指向的是 Dify 自己不是你的 Java 服务。填你 Java 服务在 Dify 所在网络里可达的 IP 或域名。6. 下一步把闭环跑稳链路跑通只是开始真正上线还要考虑几件事。第一把 Dify 的应用 Key 和 TaoToken 的 Key 都放进配置中心或环境变量别提交到 Git。第二给 Java 回调接口加幂等Dify 工作流失败重试时可能重复调用。第三在 Dify 的「日志」页面定期看节点耗时找出瓶颈节点做并行化。如果你还在选模型或想统一管理多个模型的 Key可以从模型对话页面先试几条确认通道稳定后再接进 Dify。长期做编码类 Agent 的话Coding Plan 的额度模型更适合高频调用场景。接入文档里有完整的接口说明和参数列表配置时对着看能少走弯路。把上面这套骨架复制到你的项目里改改字段名和业务逻辑一个 Java × Dify 的对话自动化闭环就能跑起来了。