推荐语

Dify 1.5.0全新升级，变量监视器让AI工作流调试从此告别"盲人摸象"，实现真正的所见即所得开发体验。

核心内容：
1. 传统工作流调试的四大痛点与局限性
2. 状态暂存与逐步执行机制的创新设计
3. 变量监视器带来的全局实时调试能力

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

在构建 AI 应用时，一条生产级工作流往往是一条复杂的逻辑链：它可能始于 RAG 的知识检索，继而调用工具获取实时数据，再通过一或多个 LLM 节点进行推理，最终由代码节点整合输出。

这个过程很强大，但也让调试变得极具挑战。当最终结果未达预期时，问题究竟出在哪一环？是 RAG 检索的文档不相关？是工具返回了异常数据？还是 LLM 的推理出现了偏差？

在以往，我们只能在工作流的入口输入，在出口等待一个最终结果，中间的执行过程对我们而言是不透明的。定位问题严重依赖于事后的日志分析和反复的全局重试，这个过程充满了猜测与等待，既低效又充满不确定性。

我们相信，开发者需要的是一个高度透明、可控的构建环境。因此，dify 1.5.0 带来了一套全新的工作流构建与调试机制，旨在将 AI 应用构建升级为“实时迭代”的体验。

痛点回顾

虽然 Dify 过去就提供了单步执行功能，允许你单独运行和测试某个节点，但这种调试方式存在着明显的局限性：

• 无法保存节点运行结果： 每次单步调试后，节点的运行结果不会被保存，退出节点后所有信息都会丢失；

• 变量重复输入： 每次调试都需要手动输入该节点所需的所有变量，无法复用已经运行好的上游节点结果；

• 缺乏全局视图： 需要在日志中逐个查看各个节点的输出，无法获得整数据状态概览；

• 调试成本高： 一旦发现问题，往往需要重新运行整条工作流，包括那些耗时或昂贵的 API 调用。

当整个工作流的输出效果不理想时，你需要像侦探一样在日志中翻找，逐个检查每个节点的输出，试图找出到底是哪个环节出了问题。这种被动式的问题排查方式，不仅效率低下，更缺乏直观性和确定性。

功能升级

在 Dify v.1.5.0 中，我们力求解决这个问题，因此打造了一个所见即所得的开发环境：

1. 状态暂存与逐步执行机制

上次运行 （Last Run）： 无论你是单步运行，还是完整执行了整个工作流，每个节点都会自动保存其最后一次成功运行的数据。它包含了该节点当时接收的输入、输出以及元数据。它就像是每个节点的“行车记录仪”，准确记录在 draft 版本中的单步调试或全量运行结果，为你提供了不可篡改的、可供随时回溯的“事实依据”。

变量复用： 基于这套状态暂存机制，我们实现了真正的逐步执行能力。只要变量监视器中存在某个节点所需的变量，你就可以直接单步运行该节点，系统会自动获取依赖数据并在执行后更新变量监视器。 这意味着你可以像在 Jupyter Notebook 中执行单个 Cell 一样，随时运行工作流中的任意节点，所有的数据依赖关系都由工作流处理。

2. 变量监视器

我们在画布底部新增了“变量监视器”面板。

https://docs.dify.ai/zh-hans/guides/workflow/debug-and-preview/variable-inspect

这是一个全局的、实时的状态监控中心，它集中展示了当前工作流中所有已生成的变量及其内容。你再也无需在节点的输入输出中来回翻找，所有数据状态一目了然。更重要的是，你可以在此直接编辑大多数变量的值，从而在不重新运行昂贵或耗时的上游节点（如复杂的 LLM 调用或 API 请求）的情况下，模拟不同数据对下游节点的影响。

这两大机制相互配合，将工作流的开发模式转变为更透明化的迭代。每个节点的状态都被完整保存和可视化，每次调试都能精准定位和快速验证，让复杂的 AI 应用开发变得像搭积木一样直观和可控。

实战场景：构建并调试“AI 投研助手”

让我们通过一个真实的例子，感受这种新模式的威力。

假设我们要构建一个 AI 投研助手，其工作流结构如下：

开始 → 知识检索节点获取知识库内的财报 & Exa 网页抓取助手获取互联网上的信息（并行） → 模板转换节点合并内容 → LLM 节点处理信息 → 最终输出

为了演示调试能力，我们模拟一个新手可能遇到的场景：由于对知识检索节点的输出格式不够熟悉，在模板转换节点中未能正确输入知识库的内容。虽然模板转换节点能够正常运行，但由于缺少了知识库的关键信息，导致 LLM 节点接收到的输入不完整，最终输出的内容质量不够理想。

过往调试流程

在过去，如果发现内容质量不够理想，你需要经历一个繁琐的排查过程：

问题定位阶段： 进入历史记录界面找到运行记录，逐个点击节点查看输出内容，最终发现模板转换节点的输出缺少了知识库内容（但节点本身运行正常）。

修复验证阶段： 回到工作流编辑页面，修改模板转换节点代码后，面临两个都不理想的选择：

• 重新运行整个工作流，包括耗时的知识检索节点和网页抓取节点；

• 单步调试 LLM 节点，但需要手动输入修复后的模板转换节点输出内容。

重复循环： 如果效果仍不满意，整个流程需要反复进行。

这个过程不仅浪费时间，还会产生不必要的 API 调用成本，特别是当你需要多轮调试时。

全新调试流程

现在，你可以这样做：

1. 运行完整工作流：一键运行整条工作流，所有节点的执行结果会自动保存到变量监视器中。变量监视器面板清晰展示了每个节点的输出状态；

2. 快速定位问题：在变量监视器中，你可以直观地看到 Exa 网页搜索节点正常工作，但模板转换节点的输出中缺少了知识库的内容；

3. 精准修复配置：发现问题后，直接修复模板转换节点的代码，确保它能正确整合知识库内容。

4. 单步验证：

• 单步运行模板转换节点：模板转换节点将自动从变量监视器获取上游的知识库和网页数据，且此节点的新输出可以自动更新到变量监视器内；

  
  

• 单步运行 LLM 节点：LLM 节点将自动使用更新后的模板转换节点的完整输出作为其新输入。你可以立即看到优化效果，无需重跑上游节点。

  

5. 迭代优化：如果 LLM 节点的输出还需要进一步优化，你还可以继续调整 LLM 节点的 Prompt 设计，让其更加全面。每次修改后，只需单步运行相关节点，几秒钟就能看到效果。

效率对比

传统流程： 发现问题 → 查找历史 → 手动输入变量 → 单步调试 → 重新配置 → 重跑工作流 → 验证效果（可能需要多轮循环）

交互式流程： 发现问题 → 查看变量检查器 → 修复节点或直接编辑变量 → 单步运行 → 立即看到效果

时间从可能的数十分钟缩短到几分钟，成本和效率提升显而易见。

总结

Dify 1.5.0 的这项核心更致力于为日益复杂的 AI 应用开发流程注入更多的确定性与可观测性。我们希望通过提供一个实时交互、状态透明的构建环境，帮助开发者更快地验证想法、更精准地定位问题、更自信地构建和交付强大而可靠的生产级 AI 应用。

🥳

如果你喜欢 Dify，欢迎：

• 体验 Dify 云端版本：https://dify.ai/

• 在 GitHub 上给我们点亮：支持我们的开源项目 https://github.com/langgenius/dify

• 贡献代码，和我们一起打造更强大的 Dify：你的每一行代码都能让但在 Dify 更加完美。
• 通过社交媒体和线下活动：分享 Dify 与你的使用心得，让更多人受益于这个强大的工具。