Dify V1.16.1 如何把工作流封装成可复用技能

Dify 到了 V1.16.1 版本，一个明显的变化是：工作流（Workflow）和智能体（Agent）之间的边界变得更清晰了。以前你可能习惯在智能体里一股脑塞满提示词和工具，或者把复杂逻辑全写在工作流里。现在，Skill（技能）这个模块，恰好成了连接两者的桥梁。

简单来说，工作流负责“把一件事做对”，而 Skill 负责“把做对的事封装起来，随时复用”。这篇文章就聚焦一个实际问题：如何把你在 Dify 里已经调试好的工作流，封装成一个可以被智能体调用的技能。

为什么要把工作流封装成技能？

在动手之前，先想清楚“为什么”很重要。假设你写了一个“客户邮件分类与自动回复”的工作流，里面包含了判断意图、查询知识库、调用大模型生成回复、人工审核分支等多个节点。

如果不封装，你每次想让智能体执行这个任务，都要在智能体的 Prompt 里写一遍完整的步骤描述，或者把工作流作为一个子流程嵌入。这样做有两个麻烦：

1. 维护成本高：只要工作流的逻辑变了，你需要在所有引用它的地方同步修改。




2. 智能体执行不稳定：智能体理解自然语言指令有偏差，它可能不会严格按照你预设的工作流路径执行。

而 Skill 的职责就是解决这两个问题。它本质上是一个“可执行的包”，里面封装了工作流的完整逻辑、输入输出定义，以及一段描述“什么时候该用我”的说明。智能体看到这个 Skill，就像调用一个函数一样，传入参数，拿到结果，中间过程完全黑盒化。

第一步：确认你的工作流已准备好

不是所有工作流都适合封装。在 V1.16.1 中，适合转为 Skill 的工作流通常具备以下特征：

• 边界清晰：完成的是一个独立、完整的任务，比如“总结本周销售数据并生成邮件”、“根据用户问题检索内部知识库并给出答案”。




• 输入输出稳定：工作流的起点和终点是明确的。比如，起点是“用户问题”，终点是“格式化后的回复文本”。输入输出参数最好不超过 3-5 个，太复杂会增加调用方的理解成本。




• 逻辑已经过测试：工作流应该已经在你当前的 Dify 实例中运行过，确认分支、条件判断、节点连接都没有问题。不要用未经验证的工作流去创建 Skill，排查起来会很头疼。

第二步：创建工作流版本并发布

在 Dify 的工作流编辑器里，完成你的工作流后，需要做两件事：

1. 保存为新版本：V1.16.1 强化了版本管理。建议在封装前，为你的工作流创建一个带有明确版本号的版本（比如 v1.0）。这能让你在后续修改工作流时，不影响已经发布的 Skill。




2. 发布为 API 应用：Skill 的底层逻辑是让智能体通过 API 调用工作流。因此，你需要把工作流应用发布为一个 API 端点。在应用设置里，找到“发布”或“API 访问”选项，确保它处于已发布状态，并记下 API 密钥。

第三步：在智能体中创建并配置 Skill

这是最核心的一步，在 V1.16.1 的 New Agent 界面里操作：

1. 创建一个新的 Agent：选择“New Agent”模式。




2. 在配置面板中找到“Skills”：在 Agent 的配置区域，你会看到一个“Skills”的选项卡。点击“添加 Skill”。




3. 选择“从已有应用创建”：这里会列出你当前工作区里所有已发布的应用。找到你刚才发布的工作流应用，选中它。




4. 定义 Skill 的“身份”：这时你需要填写几个关键字段，这是 Skill 能否被智能体正确调用的核心：




5. 名称：给这个 Skill 起一个清晰的名字，比如 customer_email_reply。




6. 描述：这是最重要的。你要用一段自然语言，精确描述这个 Skill 的功能、调用条件和输入输出。智能体就是靠这段描述来决定是否调用它。示例：“当用户需要根据客户邮件内容生成回复时，调用此技能。输入参数为原始邮件文本（email_content）。输出为格式化的回复邮件文本。”




7. 输入参数：定义工作流需要的参数。每个参数需要指定名称、类型（字符串、数字等）和描述。这些描述会帮助智能体在调用时填入正确的值。




8. 输出参数：定义工作流返回的结果。同样需要名称和描述。

配置完成后保存，这个 Skill 就正式注册到了你的智能体里。

第四步：让智能体在对话中调用 Skill

现在，你的智能体就像一个工具箱，里面既有内置的工具（如计算器、网页搜索），也有你刚创建的 Skill。当你向智能体提问时，它会分析你的意图，然后根据每个 Skill 的描述，决定是否调用。

比如，你输入“帮我回复一下昨天李总发来的那封关于项目延期的邮件”。智能体分析后，认为 customer_email_reply 这个 Skill 的职责匹配，于是它会：

1. 从对话历史或知识库中找出“昨天李总关于项目延期的邮件”内容。




2. 把这段内容作为 email_content 参数，调用你的工作流 Skill。




3. 工作流执行完毕后，把结果返回给智能体。




4. 智能体再把结果以自然语言的形式回复给你。

整个过程，你不需要关心工作流内部是调用了哪些模型、走了哪些分支。你只需要关心 Skill 的输入和输出是否正确。

什么时候该用 Skill，什么时候该用工具？

这是很多人会混淆的地方。在 V1.16.1 中，我们可以简单区分：

• 工具（Tool）：通常指单个、原子化的能力。比如“发送邮件”、“查询天气”、“计算两数之和”。它的逻辑单一，不涉及多步推理或状态管理。




• Skill：封装了有流程、有状态、多步骤的逻辑。比如“根据客户邮件生成回复”，它可能包含“判断邮件情绪 -> 查询相关历史记录 -> 调用大模型生成草稿 -> 格式化输出”等多个步骤。

一个简单的判断标准是：如果这个任务的逻辑，用一段不超过 3 行的自然语言就能在智能体 Prompt 里说清楚，那它可能更适合作为一个工具。如果需要画一张流程图才能解释清楚执行步骤，那它就应该被封装成一个 Skill。

复用能力与维护成本的权衡

Skill 的最大优势是复用。你可以在多个不同的智能体里添加同一个 Skill，每个智能体都能获得一致的能力。当工作流逻辑需要更新时，你只需要修改并重新发布那个工作流应用，所有引用它的智能体都会自动获得新版本的能力。

但这也带来了维护成本：你需要管理这些工作流应用的版本，确保 API 密钥安全，以及处理工作流执行失败时的错误反馈。因此，不要为了“封装”而封装。如果一个工作流只在一个智能体里被用到一次，且逻辑简单，直接在智能体里用 Prompt 引导可能更轻量。

哪些执行逻辑适合独立成技能？

结合以上分析，适合独立成 Skill 的执行逻辑通常具备这些特点：

• 业务流程固化：比如“客户投诉处理流程”、“新品上架信息审核流程”。这些流程经过多次验证，变动频率低。




• 需要专业领域知识：比如“医疗报告初步分析”、“法律合同条款审查”。这类任务需要调用特定知识库和模型，封装后能保证执行的专业性。




• 需要人工审核节点：工作流中可能包含“人工审核”节点。封装为 Skill 后，智能体可以自动触发流程，到需要人工介入的环节暂停，等待审核通过后再继续。这在自动化程度和安全性之间取得了很好的平衡。

把工作流封装成技能，本质上是在为你的 AI 应用做“模块化设计”。它让工作流回归到“逻辑执行器”的角色，让智能体专注于“决策与调度”，各司其职。下次当你觉得某个智能体越来越臃肿、Prompt 越来越长时，不妨回头看看，是不是有些“流程性”的任务，可以独立成一个 Skill 了。