Dify工作流实战：零代码调用外部API，构建智能天气查询AI应用

在构建AI应用时，我们常常希望大模型不仅能聊天，还能获取实时、准确的外部信息，比如天气、股价或新闻。传统开发方式需要编写复杂的后端代码来处理HTTP请求、解析JSON，再将结果喂给LLM，流程繁琐且门槛较高。今天，我将分享一个极简方案：使用Dify工作流，通过可视化拖拽，无需编写一行代码，即可让AI智能体轻松调用外部API查询天气。整个过程清晰直观，无论是产品经理、运营同学还是开发者，都能快速上手，将想法落地为可交互的AI应用。

1. 背景与核心概念：为什么需要Dify工作流接入API？

在深入实操之前，我们有必要理解几个核心概念及其价值。

Dify 是一个开源的LLM应用开发平台。它最大的优势在于将大模型应用开发“可视化”和“流程化”。你可以像搭积木一样，通过拖拽不同的节点（如LLM模型、知识库、代码执行器、HTTP请求等）来构建复杂的AI应用逻辑，极大地降低了开发门槛。

工作流（Workflow） 是Dify的核心功能之一。它允许你将多个处理步骤连接成一个自动化流程。例如，一个完整的智能问答流程可能包含：接收用户问题 -> 检索知识库 -> 调用大模型生成答案 -> 对答案进行后处理 -> 返回给用户。工作流让这个过程的每一步都变得可见、可配置、可调试。

接入外部API 则是扩展AI能力边界的关键。大模型的知识受限于其训练数据，无法获取训练截止日期后的新信息（如最新天气）或私有数据（如企业内部系统数据）。通过HTTP请求节点调用外部API，我们可以让AI应用“活”起来，具备查询实时信息、操作外部系统等能力。

UApi 是一个提供免费、公开API服务的平台，其中包含天气查询、IP归属地、手机号归属地等多种实用接口。它无需注册和认证即可调用，非常适合用于演示和原型开发。

将这三者结合，其价值显而易见：开发者无需关注HTTP请求的代码实现、错误重试、结果解析等底层细节，只需在Dify的图形化界面中配置好API地址和参数，即可将外部数据无缝集成到AI推理流程中。接下来，我们就从环境准备开始，一步步实现这个功能。

2. 环境准备与版本说明

本次实战完全基于Dify的云端服务或自托管版本，无需复杂的本地开发环境。我们将使用一个免费的公开天气API作为示例。

核心环境与工具：

1. Dify平台：你可以使用官方提供的 Dify Cloud 服务（有免费额度），也可以自行部署。本文演示以Dify Cloud为例，界面与自部署版本基本一致。
2. 网络：确保你的网络可以正常访问Dify平台及目标天气API。
3. 测试用API：我们将使用 wttr.in 提供的免费天气接口。这是一个命令行风格的天气服务，返回格式简洁的文本，非常适合演示。
   • API地址示例：https://wttr.in/Beijing?format=3
   • 参数说明：Beijing 为城市名，format=3 指定返回极简格式（城市+天气+温度）。

版本说明： Dify的界面和功能会持续迭代，但工作流和HTTP请求节点的核心逻辑稳定。本文基于2024年中期的Dify界面进行讲解，核心步骤适用于后续版本。如果遇到细微的界面差异，请根据节点名称和功能进行对应操作。

3. Dify工作流与HTTP请求节点核心原理拆解

在动手搭建之前，理解Dify工作流中几个关键节点的运作原理，能让你在配置时更加得心应手。

3.1 工作流的基本结构

一个典型的Dify工作流由开始节点、处理节点和结束节点构成。

• 开始节点：通常是“问题”或“对话开始”，用于接收用户的输入。
• 处理节点：包括“LLM”、“知识库检索”、“代码执行”、“HTTP请求”、“条件判断”等，用于对数据进行加工。
• 结束节点：用于输出最终结果给用户。

节点之间通过“变量”传递数据。上一个节点的输出，可以作为变量被下一个节点引用。

3.2 HTTP请求节点的核心配置

这是本次实战的核心节点。它本质上是一个封装好的HTTP客户端，你需要配置以下几个关键部分：

1. URL：目标API的完整地址。你可以在此处直接写死，也可以动态引用其他节点输出的变量，例如 https://wttr.in/{{city}}?format=3，其中 {{city}} 就是一个变量。
2. 方法（Method）：通常是 GET 或 POST。我们的天气查询是 GET。
3. 请求头（Headers）：用于传递认证信息（如API Key）、内容类型等。对于免费的公开API，通常不需要。
4. 请求体（Body）：POST 请求时传递的参数。GET 请求的参数一般直接拼接在URL中。
5. 超时时间：设置请求等待响应的最长时间，防止因API响应慢而卡住整个工作流。

3.3 变量与参数绑定

Dify工作流的强大之处在于动态绑定。例如：

• 用户输入“北京天气”，我们可以通过一个“文本处理”节点或直接在LLM节点中提取出城市名“北京”。
• 然后将“北京”这个值，赋值给一个叫 city 的变量。
• 在HTTP请求节点的URL配置中，我们就可以使用 {{city}} 来动态替换目标城市。 这样，工作流就能根据用户的不同输入，查询不同城市的天气。

3.4 响应处理与错误处理

HTTP请求节点执行后，会得到一个响应对象，通常包含：

• status_code：HTTP状态码（如200表示成功，404表示未找到）。
• body：API返回的主体内容，可能是文本、JSON或XML。
• headers：响应头。

我们需要从 body 中提取出有用的信息（如天气描述）。如果API返回JSON，Dify可以自动或手动将其解析为结构化数据。对于文本响应，我们可以直接使用或进行简单的文本清洗。

错误处理思路：在实际应用中，API调用可能失败（网络超时、服务不可用、参数错误）。一个健壮的工作流应该包含错误处理逻辑，例如使用“条件判断”节点检查 status_code 是否为200，如果不是，则分支到一个返回友好错误提示的路径。

4. 完整实战：三步构建天气查询AI工作流

现在，我们进入最核心的实操部分。请登录你的Dify平台，进入“工作流”模块，点击“创建新工作流”。

4.1 第一步：创建工作流并设置开始节点

1. 为新工作流命名，例如“智能天气查询助手”。
2. 从左侧节点库中，将 “开始” 节点拖入画布。这个节点代表用户输入的起点。
3. 配置开始节点：在右侧面板的“变量”部分，我们可以定义用户输入变量。这里我们简单处理，假设用户直接输入城市名。你可以添加一个变量，例如 user_query，描述为“用户输入的城市名”。但在本简易流程中，我们也可以稍后在LLM节点中直接提取。

4.2 第二步：构建核心处理链（LLM提取 + HTTP请求）

这是最关键的一步，我们将串联两个核心节点。

步骤A：添加并配置LLM节点

1. 从节点库拖入一个 “LLM” 节点，并将其与“开始”节点连接。
2. 选择一个大模型，例如 GPT-3.5-Turbo 或 Claude Haiku。Dify Cloud提供了多种模型选择。
3. 在“提示词”区域，编写一个系统提示词，指导模型从用户输入中提取城市名。
   TEXT 复制

   1

   你是一个天气查询助手。用户会输入一个包含城市名的句子。你的任务是从中提取出纯粹的城市名，不要包含任何其他文字、标点或说明。

   2

    

   3

   示例：

   4

   用户输入：“今天北京天气怎么样？”

   5

   你只输出：“北京”

   6

    

   7

   用户输入：“查询一下上海的天气情况”

   8

   你只输出：“上海”

   9

    

   10

   用户输入：“纽约”

   11

   你只输出：“纽约”

   12

    

   13

   现在，请处理以下输入：

   14

   {{#start.user_input#}}
   注意：{{#start.user_input#}} 是引用开始节点中用户输入内容的变量语法。Dify的变量引用方式可能因版本略有不同，请以界面实际提供的变量选择器为准。
4. 在“上下文”设置中，可以关闭“对话历史”，因为我们不需要多轮对话记忆。
5. 最关键的一步：设置输出变量。在LLM节点的“输出”配置部分，将输出内容赋值给一个变量，例如 extracted_city。这个变量将传递给下一个节点。

步骤B：添加并配置HTTP请求节点

1. 从节点库拖入 “HTTP请求” 节点，并将其与“LLM”节点连接。
2. 配置HTTP请求节点：
   • URL：https://wttr.in/{{extracted_city}}?format=3 这里我们使用了上一步LLM节点输出的 extracted_city 变量。确保变量名一致。
   • 方法：选择 GET。
   • 请求头：对于此API，无需特殊请求头，可以留空或添加 User-Agent 以避免某些服务器限制（非必需）。
     JSON 复制

     1

     {

     2

     "User-Agent": "Mozilla/5.0 (Dify Workflow)"

     3

     }
   • 超时时间：设置为10秒（10000毫秒）。
3. 配置输出变量：HTTP请求节点执行后，其响应内容会存储在默认变量中，通常如 http_request_result 或 response。我们需要从中提取文本。在输出配置中，可以将其 body 字段赋值给一个新变量，例如 weather_raw_text。

4.3 第三步：整合信息并回复用户

现在我们已经拿到了原始的天气文本（例如：“北京: ☀️ +26°C”），需要将其组织成友好的回复。

步骤A：添加第二个LLM节点进行格式化

1. 再拖入一个 “LLM” 节点，连接到“HTTP请求”节点之后。
2. 配置该LLM节点：
   • 提示词：
     TEXT 复制

     1

     你是一个友好的天气助手。根据提供的原始天气数据，生成一段对用户友好的、口语化的天气回复。

     2

      

     3

     原始天气数据：{{weather_raw_text}}

     4

      

     5

     请用一句完整的话描述天气情况。如果数据中包含了天气图标（如☀️）、温度等信息，请在回复中体现。
     这里引用了上一步的 weather_raw_text 变量。
   • 输出变量：将此LLM节点的输出赋值给变量 final_answer。

步骤B：设置回复并结束工作流

1. 从节点库拖入 “回复” 节点（或“结束”节点），将其与最后一个LLM节点连接。
2. 配置回复节点：在“回复内容”中，引用 {{final_answer}} 变量。
3. 保存并发布工作流。你可以点击右上角的“发布”按钮，将其发布为一个可访问的Web应用或API。

至此，一个完整的、可交互的天气查询AI工作流就搭建完成了。你可以点击画布上的“运行”按钮进行测试，在预览区输入“北京天气怎么样？”，工作流将自动执行：提取城市“北京” -> 调用API获取天气 -> 格式化回复 -> 输出“北京现在是晴天，气温大约26摄氏度。”

5. 常见问题与排查思路

在实际操作中，你可能会遇到一些问题。下面是一个快速排查指南。

关于网络热词中提到的API错误：

• api error: 400 'type' must be in ["enabled", "disabled", "auto"]：这通常是调用特定AI模型API时，传递了错误的参数。在Dify中配置LLM节点时，请确保使用平台支持的参数，不要随意添加未定义的参数。
• api error: 400 this model's maximum context length is...：这是提示词过长导致的错误。需要精简你的系统提示词或用户输入，减少token数量。
• api error: connection closed mid-response：网络连接不稳定或API服务端中断。需要检查网络并增加重试机制（高级工作流功能）。

6. 最佳实践与工程建议

掌握了基础操作后，遵循以下最佳实践能让你的工作流更健壮、更专业。

6.1 工作流设计原则

• 模块化：将复杂流程拆分为多个子工作流或清晰的节点组。例如，将“数据清洗”、“API调用”、“结果格式化”分离，便于单独调试和维护。
• 错误处理与降级：重要的HTTP请求节点后，应添加“条件判断”节点。如果状态码非200，则走错误处理分支，可以返回缓存数据、默认值或友好的错误提示，而不是让整个工作流崩溃。
• 使用常量节点：对于固定的API密钥、基础URL等敏感或配置信息，不要硬编码在URL中。可以使用“常量”节点存储，然后在HTTP请求节点中引用 {{constant_node.api_key}}，这样更安全且易于修改。

6.2 API调用优化

• 参数验证与清洗：在调用HTTP请求前，对输入参数（如城市名）进行验证。可以使用“代码执行”节点（Python）编写简单的清洗逻辑，去除空格、检查是否为空等。
• 设置合理的超时与重试：根据API的可靠性设置超时（通常5-30秒）。对于关键业务，可以考虑在工作流逻辑外层实现重试机制，或选择支持重试的第三方节点。
• 处理异步API：如果调用的API是异步的（先返回一个任务ID，再通过另一个接口查询结果），你需要设计包含循环等待和条件判断的复杂工作流。Dify的高级版本可能提供“等待”或“循环”节点来支持。

6.3 提示词工程

• 明确指令：给LLM节点的提示词要尽可能清晰、无歧义。明确指定输入格式、输出格式和任务目标。
• 提供示例：在提示词中加入少量示例（Few-shot Learning），能显著提高LLM输出结果的稳定性和准确性，正如我们在提取城市名的步骤中所做的那样。
• 角色设定：通过系统提示词为LLM设定一个明确的角色（如“专业的天气播报员”），可以让其生成的回复风格更符合预期。

6.4 安全与权限

• 保护API密钥：切勿在提示词、URL或工作流配置中明文暴露你的真实API密钥。对于自部署的Dify，可以利用环境变量或Dify的“密钥”管理功能。在Dify Cloud中，也可以使用平台提供的密钥管理服务。
• 输入过滤：对用户输入进行基本的过滤，防止注入攻击。虽然Dify工作流有一定隔离性，但良好的习惯是避免将未经处理的用户输入直接拼接成系统命令或敏感请求的URL参数。
• 权限控制：在Dify中创建的应用和工作流，要注意其公开范围。内部使用的工具应设置适当的访问权限。

6.5 性能与监控

• 缓存策略：对于天气这类更新频率不高的数据，可以考虑引入缓存。虽然Dify工作流原生不支持，但你可以调用一个带有缓存功能的自建API中间层。
• 日志与调试：充分利用Dify工作流的“运行历史”功能。每次执行都会记录详细的节点输入输出，这是排查问题最宝贵的工具。对于生产环境，需要建立更完善的监控，关注工作流的执行成功率和耗时。

通过以上三步构建和这些最佳实践，你不仅能够创建一个天气查询机器人，更能掌握使用Dify工作流连接外部世界、构建复杂AI应用的核心方法。这种可视化、低代码的集成方式，正成为快速实现AI想法的主流路径。