用 Python 编写 Dify 工作流脚本(小技巧)

       Dify 作为一个支持自定义 Python 工作流的智能体平台,给了我们极大的灵活性。但很多人在写 Dify 脚本时,常常忽略了其中最常用、最实用的一些 Python 技巧。本文从我实际使用的几个脚本中,提炼出一些非常值得掌握的核心知识点。


1. json.loads与嵌套结构提取

Dify1.6 中传入的参数很多都是 JSON 字符串(不是Object,因为输入不支持),需要先用 json.loads() 解析:

import json def main(request: str) -> dict: data = json.loads(request) value = data.get('some_field', 'default') sublist = data.get('nested', {}).get('list', []) return {"value": value, "sublist": sublist}

技巧点:

  • dict.get() 支持默认值,避免 KeyError;
  • 嵌套访问时用 .get(..., {}) 链式访问更安全;
  • 字段缺失时自动降级为默认值,是写健壮代码的基本功。

2. 批量提取列表中的字段

当传入参数是一个包含多个对象的列表时,通常我们只关心每个对象中的一个字段。这时可以用一个简单的 for 循环快速提取:

def main(arg1: str, arg2: list) -> dict: arg1 = json.loads(arg1).get("output") token_list = [item.get("output") for item in json.loads(arg2)] return { "result": { "text": arg1, "tokens": token_list } }

技巧点:

  • 使用列表推导式比传统 for 更简洁;
  • 处理 Dify 中多个节点输出(如 list[{"output":...}])时非常高效。


3. 多个 dict 合并的常见做法

你可能需要把多个字典合并成一个结构统一的输出,比如不同规则的匹配结果。用 {**a, **b, **c} 的形式可以快速实现:

def main(a, b, c) -> dict: a = json.loads(a) b = json.loads(b) c = json.loads(c) result = {**a, **b, **c} return {"merged": result}

或者更实际一点:

rule_a = {"rule_a": [1, 2]} rule_b = {"rule_b": [3, 4]} rule_c = {"rule_c": [5]} merged = {**rule_a, **rule_b, **rule_c}

技巧点:

  • {**dict1, **dict2} 是 3.5+ 的语法,比 update() 更干净;
  • 适合结构扁平的场景,不建议用于深层嵌套的 merge。


4. 从多个输入中整理成统一结构

当你处理多个输入对象,每个都返回结构类似的内容时,可以统一封装成一个最终结果:

def main(text, rule1, rule2, vec_result) -> dict: rule_matches = { "rule1": json.loads(rule1).get("match", []), "rule2": json.loads(rule2).get("match", []) } result = { "text": text, "rules": rule_matches, "vector": json.loads(vec_result).get("similar", []) } return {"result": result}

技巧点:

  • 用 .get(..., []) 处理可能缺失字段;
  • 返回结构清晰、有层次,有助于调试和前端渲染。

总结

在 Dify 或任何支持 Python 的工作流平台中,掌握以下基础技能尤为重要:

技巧

示例

用途

json.loads

json.loads(str)

解析传入字符串参数

.get()

dict.get("key", default)

安全提取字段

列表推导

[x.get("a") for x in list]

从列表中批量提取字段

多 dict 合并

{**a, **b}

聚合结果

结构清晰的 return

return {"result": ...}

提高可读性

这些技巧虽然基础,但在构建实际智能体时非常常用,建议每位使用 Dify 或编写轻量脚本的人都熟练掌握。


      如果你对这类“工作流+Python”类型的技巧感兴趣,欢迎关注我后续的系列文章,也欢迎分享你的实践经验!

Read more

场景深耕:低延迟高并发EasyDSS无人机RTMP高清推流直播技术剖析

场景深耕:低延迟高并发EasyDSS无人机RTMP高清推流直播技术剖析

从交通工程巡检到文旅宣传,从警务安防到水利监测,无人机直播已成为各行业数字化转型的重要工具。而EasyDSS凭借RTMP低延迟推流、高清直播的核心优势,深度贴合不同行业的场景需求,打造定制化解决方案,让无人机直播真正落地生根,为行业发展提质增效,实现“技术赋能业务”的核心价值。 在交通工程领域,传统人工巡检面临作业面绵长、地形复杂、安全隐患难追溯等痛点,某公路项目就曾面临这样的困境,每天安排6名安全员不间断巡查,仍存在监管死角,夜间施工时人工巡检更是力不从心。 引入EasyDSS无人机RTMP推流直播解决方案后,通过智能机巢部署无人机,结合控飞平台,按预设航线自动开展巡检,搭载8K高清摄像头捕捉施工场景,通过RTMP协议将实时画面低延迟推流至管理平台,延迟控制在2秒内,不仅降低了人工成本,更实现了安全隐患的早发现、早处置。 在文旅宣传领域,传统“图片+短视频”的宣传模式存在体验感缺失、信任度不足等问题,难以展现景区的宏大规模与动态美景。 EasyDSS与无人机构建起7×24小时“空中直播间”,无人机通过RTMP协议将景区实时画面推流至EasyDSS平台,再由平台实现

论文阅读“OmniXtreme: Breaking the Generality Barrier in High-Dynamic Humanoid Control“

目录 * 一、论文核心定位与研究背景 * 1. 核心研究目标 * 2. 行业现状与核心痛点 * 3. 相关工作的局限性 * 二、OmniXtreme核心技术框架 * 第一阶段:基于流匹配的可扩展预训练 * 第二阶段:驱动感知的残差RL后训练精调 * 部署端工程优化 * 三、实验验证与核心结果 * 1. 实验基础设置 * 2. 核心实验结论 * (1)可扩展的高保真跟踪能力(核心性能验证) * (2)打破保真度-可扩展性权衡 * (3)模型容量缩放的优势 * (4)消融实验:各模块的必要性验证 * (5)定性能力验证 * 四、论文核心贡献 * 五、局限性与未来研究方向 * 六、行业价值与影响 摘要 High-fidelity motion tracking serves as the ultimate litmus test

SpringBoot + Low-Code + JSON 表单引擎:5 分钟配置一套审批流,告别重复 CRUD

前言 在企业级应用开发中,审批流是一个高频需求。无论是请假申请、费用报销,还是采购审批,都需要一套完整的表单和流程系统。传统开发模式下,每个审批流都需要单独开发表单页面、验证逻辑、数据存储和流程控制,不仅耗时耗力,还容易出现重复造轮子的情况。今天,我将和大家分享一个基于SpringBoot的低代码表单引擎解决方案,通过JSON配置,实现5分钟配置一套审批流,彻底告别重复的CRUD开发。 原文链接 为什么需要低代码表单引擎? 1. 开发效率问题 传统审批流开发需要经历以下步骤: * 设计表单UI界面 * 实现前端交互逻辑 * 开发后端API接口 * 编写数据验证逻辑 * 集成工作流引擎 * 实现审批节点配置 * 部署和测试 整个过程可能需要几天甚至几周时间,而且每个新流程都要重复这些步骤。 2. 维护成本高昂 随着业务发展,表单字段经常需要调整,流程节点需要变更,每次修改都需要开发人员介入,增加了维护成本和响应时间。 3. 业务人员参与度低 业务人员无法直接参与表单和流程的设计,只能被动接受开发结果,导致最终产品与实际需求存在偏差。 核心技术方案

写给技术管理者的低代码手册系列文章(2)——第一部分:低代码诞生的背景【第一章】

写给技术管理者的低代码手册系列文章(2)——第一部分:低代码诞生的背景【第一章】

第一章 企业软件复杂度的逐步累积 1.1 从硬件导向到数据导向 早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者理解CPU指令、寄存器和内存地址,软件的表达方式高度依赖具体硬件体系结构,如SSE指令集中用于比较字符串的pcmpistr,无法运行在不支持SSE的CPU上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低,应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。随着电子工业的发展,计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键,在于找到一种足够通用的抽象方式。 1970年,来自IBM的E.F.Codd博士在ACM通讯杂志上发表的论文《大规模共享数据银行的关系型模型》,为解决这一问题提供了一种切实可行的技术路线。该路线中,现实世界中的业务单据、业务流程和管理决策,被统一抽象为数据的存储、处理与分析,而执行这些操作的软件被统称为“关系型数据库”。企业的用户只需要一个连接到数据库软件的终端,就能用一套近似于英语的、统一的语言来操作这个软件,以此实现所有的业务操作。如用户想要查询姓名中包含“李”的员工档案,需要输入 SELECT