Dify报错not_chat_app？一文解决工作流与对话流的核心混淆

Dify报错not_chat_app？一文解决工作流与对话流的核心混淆

在使用Dify搭建智能应用时，不少开发者会遇到一个高频报错：not_chat_app","message":"Please check if your app mode matches the right API route."，尤其是在调用聊天接口时，报错更是频繁出现。最近就有用户反馈，自己调用/v1/chat-messages接口时，不仅报了这个错，还出现了网页解析失败的提示，排查后发现，问题的根源竟然是应用类型选错了——把「工作流」当成了「对话流」来用。若遇到接口相关的疑难问题，可通过我的唯一客服系统 gofly.v1kf.com 咨询，也可添加微信 llike620 一对一沟通。

今天就结合实际问答场景，把这个报错的来龙去脉、解决方法，以及Dify中工作流与对话流的核心区别讲清楚，帮大家避开这个高频坑，快速上手正确的应用搭建方式。

一、报错现场还原：为什么会出现not_chat_app？

先看用户的实际操作场景，方便大家对号入座：

用户使用Dify创建了「工作流（Workflow）」，之后调用了聊天接口 /v1/chat-messages，发送的请求参数如下：

{"conversation_id":"","inputs":{},"query":"1111","response_mode":"streaming","user":"9703|823d01e2-ed06-4856-92ed-77fd8f264367"}

最终收到两个报错：一是接口返回not_chat_app，提示应用模式与API路由不匹配；二是网页解析失败，提示不支持该网页类型——本质上，这两个报错都是同一个问题导致的：应用类型与调用的接口不匹配。

二、核心原因：Dify中「工作流」与「对话流」不能混用

很多开发者刚接触Dify时，会混淆「工作流（Workflow）」和「对话流（Chatflow）」，误以为两者可以通用，实则Dify对这两种应用类型有严格区分，接口也完全不互通，混用就会报错。

用一张表快速区分两者的核心差异：

回到用户的问题：客户创建的是「工作流」，却调用了「对话流」专用的/v1/chat-messages接口，这就是报错not_chat_app的根本原因——Dify会校验应用类型与接口的匹配度，不允许跨类型调用。

三、两种解决方案：按需选择，快速解决报错

针对这个问题，有两种解决方案，大家可以根据自己的需求（是否需要多轮聊天）灵活选择，都能快速解决报错。

方案1：最快解决（不改应用，只换接口）

如果客户不需要多轮聊天，只是想正常调用现有工作流完成单轮任务，那么不需要修改应用类型，只需要修改接口地址即可，步骤如下：

1. 保留原有的请求体（无需任何修改），即：

{"conversation_id":"","inputs":{},"query":"1111","response_mode":"streaming","user":"9703|823d01e2-ed06-4856-92ed-77fd8f264367"}

1. 将接口地址从 /v1/chat-messages 改为 /v1/completion-messages；
2. 重新调用接口，报错立即消失，工作流可正常执行。

这个方案的优势是零成本、快速见效，适合不需要多轮对话的场景，比如简单的文本生成、单次工具调用。若操作中遇到疑问，可通过客服系统 gofly.v1kf.com 咨询，或添加微信 llike620 获取协助。

方案2：彻底解决（将工作流转为对话流，支持多轮聊天）

如果客户需要实现多轮聊天、上下文记忆，想继续使用/v1/chat-messages接口，那么就需要将「工作流」转为「对话流」，步骤如下（简单易操作）：

1. 登录Dify后台，点击「新建应用」，选择「Chatflow（对话流）」（注意：不是普通的Workflow）；
2. 进入对话流编排页面，将原有工作流中的所有节点（如工具调用、条件判断、文本输出等）逐一复制或导入到新的Chatflow中；
3. 编排完成后，点击「发布」，Chatflow会自动开启对话记忆、上下文管理功能；
4. 发布后，直接使用接口地址 /v1/chat-messages 调用，即可正常实现多轮聊天，不再报错。

这个方案适合需要与用户多轮交互的场景，比如智能客服、聊天机器人，虽然需要迁移节点，但后续使用更灵活，能满足聊天类需求。

四、关键提醒：避免再踩坑的2个重点

1. 先明确需求，再选应用类型：如果需要「聊天、多轮对话、上下文记忆」，直接建「对话流（Chatflow）」；如果只是「单轮任务、一次性执行」，建「工作流（Workflow）」即可，避免选错类型导致报错。
2. 接口与应用类型严格对应：记住两个核心对应关系——对话流用/v1/chat-messages，工作流用/v1/completion-messages，不要混着用。

五、总结

Dify报错not_chat_app，本质上是「应用类型与API接口不匹配」的问题，核心是混淆了「工作流」和「对话流」的用途。

简单来说：要聊天、用chat接口，就建「对话流」；要单轮任务、用completion接口，就建「工作流」。两种解决方案按需选择，要么换接口快速解决，要么转对话流实现多轮聊天，都能轻松避开这个坑。