1. 为什么在 Dify 里做数据可视化总卡在最后一步很多人在 Dify 里搭数据问答应用时前半段都很顺接上 MySQL、写好提示词、让大模型把自然语言转成 SQL查询结果也能正常返回。真正让人头疼的是最后一步——把查询结果变成一张能看的图表。传统做法一般是这样数据库节点查出原始数据接一个 Python 代码节点把数据转成 ECharts 能识别的 JSON 结构再调用 ECharts 插件渲染。这条链路我试过问题集中在三个地方。第一Python 转换代码要针对每种图表类型单独写折线图和饼图的 data 结构不一样字段名也不一样改一次需求就要改一次代码。第二大模型生成的 SQL 返回字段顺序不稳定代码节点里写死的索引经常对不上。第三ECharts 插件对入参格式要求严格少一个 series 字段就直接报错排查起来很费时间。这篇要讲的路径换了个思路不自己拼图表配置而是把「画图」这件事交给一个专门的图表服务。Dify 工作流只负责三件事——理解用户要什么、查出数据、把数据交给图表服务。图表服务返回一个图片链接工作流直接展示。整条链路里没有手写图表 JSON 的环节配置量大幅下降。适合谁看已经在用 Dify 搭数据类应用、想让查询结果自动出图的开发者或者刚开始接触 Dify 工作流、想找一个完整可复现案例的新手。下面从环境准备开始一步步把这条链路搭出来。2. 前置准备TaoToken 接入与图表服务启动2.1 为什么这里需要 TaoTokenDify 工作流里有两个节点强依赖大模型一个是需求提炼节点负责判断用户要不要图表、推荐图表类型另一个是自然语言转 SQL 节点。这两个节点对模型的指令遵循能力要求比较高模型选得不对输出的格式就会跑偏后面整条链路都会受影响。TaoToken 在这里的作用是提供一个统一的模型调用入口。你可以在 TaoToken 的控制台里拿到 API Key然后在 Dify 的模型供应商配置里填入这个 Key 和对应的 API 地址就能在工作流节点里直接选用支持的模型。这样不用在每个节点里单独维护不同的模型凭证换模型时也只改一处。具体操作登录 TaoToken 控制台在 API Keys 页面创建一个新的 Key复制保存。然后在 Dify 的「设置 - 模型供应商」里找到兼容 OpenAI 接口的配置项把 API Base 填成https://taotoken.net/api再把刚创建的 Key 填进去。保存后在模型列表里就能看到可用的模型了。如果你还没决定用哪个模型可以先到模型对话页面实际发几条指令测试一下模型对「按固定格式输出」这类要求的遵循程度再决定工作流里用哪个。2.2 启动图表服务图表能力来自一个独立的服务它对外暴露 HTTP 接口Dify 通过 MCP 协议调用它。启动方式用 Docker 最省事docker run -d --name mcp-server-chart -it -p 8000:8000 acuvity/mcp-server-chart:0.4.0启动后确认容器状态docker ps | grep mcp-server-chart看到容器处于 Up 状态就说明服务起来了。这个服务支持三种调用方式STDIO、SSE、streamable HTTP。在 Dify 工作流里我们要用 SSE 模式地址格式是http://你的服务IP:8000/sse。这一点后面配置 MCP 节点时会再强调因为用错协议图表生成会失败。2.3 准备示例数据为了让整条链路能跑通需要一张有数据的表。这里用一张电影票房表做演示CREATE TABLE boxoffice ( id bigint NOT NULL, years varchar(64) DEFAULT NULL, movie_name varchar(255) DEFAULT NULL, score float DEFAULT NULL, director varchar(64) DEFAULT NULL, box_office float DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;插入几条测试数据INSERT INTO boxoffice (id, years, movie_name, score, director, box_office) VALUES (1, 2025, 哪吒之魔童闹海, 8.5, 饺子, 1467030), (2, 2021, 长津湖, 7.6, 陈凯歌, 577524), (3, 2017, 战狼2, 7.1, 吴京, 569456), (4, 2021, 你好李焕英, 8.1, 贾玲, 541372), (5, 2019, 哪吒之魔童降世, 8.5, 饺子, 503557);数据量不用多够验证链路就行。重点是字段类型要清晰后面写提示词时要把字段说明列出来帮助模型生成正确的 SQL。3. Dify 工作流可复制配置骨架3.1 整体节点结构工作流从开始节点接收用户问题经过需求提炼、参数提取、自然语言转 SQL、执行 SQL然后在条件分支处根据「是否需要图表」走两条路需要图表走图文总结节点调用图表服务不需要图表走文字总结节点。最后统一进回复节点。这个结构的好处是职责清晰每个节点只做一件事出问题时能快速定位是哪个环节的输入输出不对。3.2 需求提炼节点配置这个节点用大模型分析用户问题输出三个字段精炼后的查询需求、是否需要图表、推荐的图表类型。模型选择上建议用指令遵循能力强的模型。在 TaoToken 的模型列表里挑一个你测试过、格式输出稳定的即可。提示词这样写你是一名专业的数据需求提炼师。 请仔细阅读用户的自然语言问题{{#context#}}只保留与数据查询直接相关的核心需求。自动忽略与数据查询无关的内容。 请判断用户是否需要用图表展示结果。如果需要请根据问题内容推荐最合适的图表类型如 area、bar、column、line、pie、radar、scatter、treemap、word-cloud 等如果不需要图表请填写无。 请严格按照如下格式输出不要有任何解释或多余内容 sql_requirement: [精炼后的数据查询需求] need_chart: [是/否] chart_type: [推荐的图表类型或无]输出格式固定成三行是为了后面参数提取节点能稳定解析。如果模型输出里带了额外解释文字提取就会失败。3.3 参数提取节点配置把上一个节点的三个输出分别提取成独立变量参数名类型说明sql_requirementstringSQL 查询需求need_chartstring是否需要图表chart_typestring图表类型提取规则按行匹配冒号后面的内容作为值。这一步是纯配置不需要写代码。3.4 自然语言转 SQL 节点这个节点把sql_requirement转成可执行的 SQL。Dify 插件市场里有现成的 text2data 插件安装后添加节点选择对应插件。数据库连接信息填你实际的 MySQL 地址、端口、库名、用户名、密码。提示词里要把表结构说清楚表名boxoffice 字段说明 - ididint - years年份varchar - movie_name电影名string - score评分float - director导演string - box_office票房float 注意事项 - 如有分组统计请使用 SUM、AVG 等聚合函数不要直接用原始字段。 - 所有非聚合字段必须出现在 GROUP BY 中。 - 只输出 SQL 语句不要解释。 示例查询 1. 查询每个导演的总票房SELECT director, SUM(box_office) FROM boxoffice GROUP BY director; 2. 查询每年票房最高的电影SELECT years, movie_name, MAX(box_office) FROM boxoffice GROUP BY years;返回格式选 text这样下一节点拿到的就是纯 SQL 字符串。3.5 执行 SQL 节点输入变量选上一节点返回的 SQL 文本数据库配置和上一步一致返回格式同样选 text。这个节点的输出就是查询结果后面图表节点和文字总结节点都会用到。3.6 条件分支配置判断条件用need_chart字段等于「是」走图文总结分支否则走文字总结分支。两个分支最后都汇入回复节点。3.7 图文总结节点核心这个节点用 Agent 策略选择支持 MCP Tools 的模式。MCP 服务器配置如下{ mcp-server-chart: { url: http://你的服务IP:8000/sse } }这里必须用 SSE 模式。如果用 streamable HTTP图表生成会失败因为当前 Dify 的 Agent 策略对 streamable HTTP 协议的支持还不完整。这是实测踩过的坑配置时注意。指令部分选择执行 SQL 节点的输出作为数据来源。提示词根据给定的数据选择合适的工具生成相应的图表图表类型参考 {{#节点ID.chart_type#}}。 如果有小数的话保留小数点后面2位就行。 输出先用自然语言简要给出数据分析给出图片链接地址并展示图片要求全部用中文回答。注意{{#节点ID.chart_type#}}里的节点 ID 要替换成你实际工作流里参数提取节点的 ID每个人的 ID 不一样直接复制会取不到值。3.8 文字总结节点不需要图表时走这个分支用大模型根据查询结果生成自然语言分析。上下文选执行 SQL 节点的输出提示词请根据用户问题和查询结果用简洁的中文自然语言回答并给出分析意见。 用户问题:{{#节点ID.sql_requirement#}} 查询结果:{{#context#}}同样要替换节点 ID。4. 验证请求与成功结果配置完成后在 Dify 的调试窗口输入测试问题。先测图表分支各导演的票房占比是多少预期结果工作流先提炼出「按导演分组统计票房」的需求判断需要图表推荐饼图类型。然后生成 SQL 并执行拿到导演和票房数据。图文总结节点调用图表服务返回一段分析文字加一个图片链接。如果链路正常你会看到类似这样的输出先是一句「根据查询结果饺子导演的票房占比最高……」然后是一个图片链接。打开链接能看到一张饼图各导演的票房占比一目了然。再测一个折线图场景请用图表展示历年票房变化这次图表类型应该推荐 line生成的图片是折线图横轴是年份纵轴是票房。最后测不需要图表的分支票房最高的电影是哪部这个问题只需要文字回答条件分支会走文字总结节点输出一段自然语言不生成图片。三个场景都通过说明整条链路配置正确。5. 本篇常见错误排查5.1 图表生成失败提示协议不支持现象图文总结节点报错日志里出现协议相关的提示。原因MCP 服务器配置用了 streamable HTTP 而不是 SSE。处理把 MCP 配置里的 URL 从http://IP:8000/mcp改成http://IP:8000/sse保存后重新测试。5.2 参数提取节点取不到值现象参数提取节点输出为空后面 SQL 生成节点拿不到需求。原因需求提炼节点的输出格式和提取规则不匹配。模型可能多输出了解释文字或者冒号用了中文全角。处理检查需求提炼节点的实际输出确认严格是三行、冒号是英文半角。如果模型不稳定可以在提示词里加一句「只输出三行不要任何其他内容」或者换一个指令遵循更好的模型。5.3 SQL 执行报字段不存在现象执行 SQL 节点报错提示 Unknown column。原因模型生成的 SQL 里字段名和实际表结构不一致或者聚合函数用法不对。处理在自然语言转 SQL 节点的提示词里把字段说明写得更详细加上「字段名必须和上面列出的完全一致」这样的约束。另外确认数据库连接配置里的库名正确。5.4 图片链接打不开现象工作流返回了图片链接但浏览器打开是空白或报错。原因图表服务生成的图片链接有时效性或者服务本身没正常返回图片。处理先确认图表服务容器还在运行然后重新执行一次工作流。如果链接是内网地址需要确保你的浏览器能访问到那个地址。5.5 工作流走到错误分支现象明明问了需要图表的问题却走了文字总结分支。原因需求提炼节点把need_chart判断成了「否」。处理检查需求提炼节点的提示词确认对「用图表展示」「画个图」这类表述的识别逻辑清晰。可以在提示词里加几个正例和反例帮助模型判断。6. 把这条链路用起来整条链路搭完之后最直接的用法是把它接到一个对话应用里让用户用自然语言查数据、自动出图。但还有几个可以继续优化的方向。一个是图表类型的控制。目前是让模型自动推荐如果你希望某些问题固定用某种图表可以在需求提炼节点的提示词里加规则比如「涉及占比的问题统一用饼图」。另一个是数据量大的场景。如果查询结果行数很多图表服务渲染会变慢可以在 SQL 节点加 LIMIT 限制或者在提示词里让模型自动加聚合。还有一个是错误兜底。图表服务偶尔会超时可以在图文总结节点后面加一个条件判断如果返回结果里没有图片链接就走一个降级分支只输出文字分析。如果你打算长期在 Dify 里做数据类应用建议把模型调用统一走 TaoToken 的入口这样换模型、调参数都只改一处工作流本身不用动。需要长期跑编码类或 Agent 类任务的话可以了解一下 Coding Plan 的额度方案比按次调用更划算。接入过程中遇到报错先对照第 5 节的排查清单过一遍大部分问题都能定位到具体节点。