使用 Dify 快速构建对话式工作流：从零打造会议室预约智能体

使用 Dify 快速构建对话式工作流：从零打造会议室预约智能体

前言

随着 AI 技术的普及，越来越多的企业开始探索如何将大语言模型（LLM）融入日常业务流程中。Dify是一款开源的 LLM 应用开发平台，提供了可视化的工作流编排能力，让开发者无需编写大量代码，就能快速构建对话式 AI 应用。

本文将手把手带你使用 Dify 搭建一个会议室预约智能体，实现自然语言驱动的会议室查询与预约功能，并重点介绍如何处理用户"知道/不知道目标会议室"这一关键分支逻辑。

一、Dify 简介

Dify（Do It For You）是开源的 LLM 应用开发平台，核心特性如下：

• 可视化工作流编排：通过拖拽节点设计 AI 应用逻辑，无需写代码
• 多模型支持：兼容 OpenAI、Claude、Gemini、本地 Ollama 等主流模型
• 工具调用（Tool Use）：支持自定义 HTTP API 工具，与外部系统集成
• 对话式交互：天然支持多轮对话、上下文记忆
• 一键发布：可直接生成 Web 应用、嵌入式组件或 API 接口

二、场景分析与核心挑战

在设计会议室预约智能体时，有一个关键的用户体验问题需要解决：用户是否已经知道自己要预约哪个会议室？

这两种情况对应完全不同的处理逻辑：

如果不处理这个分支，智能体要么死板地要求用户指定会议室，要么随意选一个不符合需求的房间，用户体验都会很差。

三、工作流整体架构设计

完整的工作流分为以下几个阶段，核心是双层分支判断：

用户输入 └─► 意图识别（查询 / 预约 / 取消） ├─ [查询] → 查询所有会议室 → 展示结果 ├─ [取消] → 提取预约编号 → 取消预约 → 反馈 └─ [预约] → 是否指定了会议室？ ├─ [已指定] → 查询该会议室详细信息 │ └─ 是否可用？ │ ├─ [可用] → 收集信息 → 创建预约 │ └─ [不可用] → 告知冲突，询问是否换房间 └─ [未指定] → 查询所有空闲会议室列表 └─ 展示列表，让用户选择 └─ 用户选择后 → 创建预约

四、环境准备

1. 部署 Dify

推荐使用 Docker Compose 快速部署本地版：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动后访问http://localhost/install完成初始化。

2. 配置模型供应商

进入控制台 →设置→模型供应商，添加模型 API Key，推荐使用gpt-4o或claude-3-5-sonnet以获得更好的意图理解效果。

五、工作流节点详细配置

Step 1：意图识别节点（LLM）

第一层判断：识别用户意图是查询、预约还是取消。System Prompt：

你是会议室预约助手，请分析用户输入的意图，只返回以下三种之一： - QUERY：用户想查询会议室可用情况 - BOOK：用户想预约会议室 - CANCEL：用户想取消已有预约 只返回意图英文标识，不要有任何其他内容。

Step 2：预约意图下的"是否指定会议室"判断节点（LLM）

当意图为 BOOK 时，进入第二层判断：用户是否明确指定了会议室。System Prompt：

分析用户的预约请求，判断用户是否明确指定了具体的会议室（如"101会议室"、"大会议室"等具体名称或编号）。 - 如果用户明确提到了具体会议室名称/编号，返回：SPECIFIED - 如果用户没有指定，或者只说"找一个"、"随便一个"、"合适的"，返回：UNSPECIFIED 只返回 SPECIFIED 或 UNSPECIFIED，不要其他内容。

这一步是整个工作流的关键设计，通过 LLM 的语义理解能力来判断用户意图的细节，而不是依赖关键词匹配，容错性更强。

Step 3A：用户已指定会议室 → 查询具体会议室信息（HTTP Request）

首先用 LLM 从用户输入中提取会议室标识，再调用 API 查询详情。HTTP Request 节点配置：

• 方法：GET
• URL：{{env.API_BASE}}/api/rooms/{{room_identifier}}/availability
• 参数：date={{date}}&start_time={{start_time}}&duration={{duration_hours}}

返回结果包含该会议室的详细信息（容量、设备、当前时段是否可用），再通过 IF/ELSE 节点判断是否可用，分别进入"创建预约"或"告知冲突并引导换房"两条路径。

Step 3B：用户未指定会议室 → 查询所有空闲会议室（HTTP Request）

当用户没有指定会议室时，查询所有符合时间条件的空闲房间供用户选择。HTTP Request 节点配置：

• 方法：GET
• URL：{{env.API_BASE}}/api/rooms/available
• 参数：date={{date}}&start_time={{start_time}}&duration={{duration_hours}}&capacity={{required_capacity}}

Step 4：生成选项列表，等待用户选择（LLM）

拿到空闲会议室列表后，用 LLM 节点生成友好的选择提示，展示各会议室的楼层、容量、设备信息，让用户回复序号或名称选择。

为您找到以下 3 个符合条件的空闲会议室，请选择：
1️⃣101会议室（1楼，可容纳8人，配备：投影仪、白板）
2️⃣201会议室（2楼，可容纳12人，配备：大屏、视频会议）
3️⃣大会议室（3楼，可容纳30人，配备：投影仪、麦克风）
请回复序号或会议室名称进行选择。

Step 5：创建预约（HTTP Request）

两条路径最终汇合到此节点，调用预约接口：

POST {{env.API_BASE}}/api/bookings { "room_id": "{{room_id}}", "date": "{{date}}", "start_time": "{{start_time}}", "duration_hours": {{duration_hours}}, "attendees": {{attendees}}, "title": "{{title}}" }

Step 6：生成最终回复（LLM）

将 API 返回的结构化结果转化为自然语言，礼貌地确认预约信息给用户。

六、完整对话效果演示

场景一：用户明确指定会议室（走快速路径）

场景二：用户未指定会议室（走推荐路径）

场景三：指定会议室但已被占用

七、关键设计要点总结

1. 双层意图分析：第一层识别动作类型（查询/预约/取消），第二层在预约场景下进一步判断"是否指定会议室"，让分支逻辑更精准
2. 语义理解代替关键词匹配：用 LLM 判断用户是否指定了会议室，而不是正则表达式，大幅提升容错性
3. 两条路径最终汇合：已指定和未指定两条路径，在用户最终确认会议室后汇合到同一创建预约节点，避免重复配置
4. 渐进式信息收集：不要求用户一次说完所有信息，通过多轮对话逐步补全，降低用户输入门槛

八、发布与集成

测试通过后，可以通过以下方式发布：

• Web 应用：直接获得可访问链接，分享给团队使用
• API 接口：集成到钉钉/飞书机器人
• 嵌入组件：嵌入现有 OA 系统页面

curl -X POST 'https://your-dify-domain/v1/chat-messages' -H 'Authorization: Bearer YOUR_API_KEY' -H 'Content-Type: application/json' -d '{ "query": "帮我预约明天下午3点一个可以容纳10人的会议室", "response_mode": "blocking", "user": "user_001" }'

总结

本文通过会议室预约场景，重点介绍了如何在 Dify 工作流中设计双层意图判断逻辑：先识别用户动作，再细化判断用户是否知道目标会议室，从而走不同路径——直接查询指定房间详情，或者列出所有空闲房间供用户选择。

这种设计思路同样适合任何需要"已知目标"与"未知目标"两种路径的业务场景，如工单分配、商品推荐、知识库查询等。借助 Dify 的可视化工作流，整个逻辑清晰可见、易于维护，是企业快速落地 AI 助手的理想选择。