用一个Skill转化所有Skill？Dify工作流与Agent的边界之辩

一个看似荒诞的技术命题

在AI应用开发的实践中，有一类需求听起来颇具哲学意味：如何把一个「Skill」（技能）转化为可视化的工作流？更进一步，能否构造出一个「元Skill」——它的唯一作用，就是把任意其他Skill转化为标准工作流？

这个问题最早由一位B站UP主以半开玩笑的方式抛出，却意外触及了当下Agent与工作流两种范式之争的核心：确定性编排与动态自主决策之间，边界究竟在哪里？

在Dify这类低代码AI应用平台上，工作流（Workflow）是一种由节点连接而成的有向执行图。它允许存在「语言模型节点」（LLM节点），用来完成生成、判断、抽取等任务，但通常不允许直接嵌入「Agent节点」——也就是那种能够自主规划、调用工具、循环反思的智能体单元。

Dify是一个开源的大语言模型应用开发平台，2023年兴起后迅速成为企业级AI应用构建的主流工具之一。它的核心设计哲学是将AI能力「产品化」——通过可视化的Workflow编排、Prompt工程、RAG知识库管理等模块，让非AI专家也能构建可落地的AI应用。Dify的工作流节点体系中，LLM节点、代码节点、HTTP节点、条件分支节点等均有明确的输入输出契约，整体执行图必须是DAG（有向无环图）或带有受控循环的有向图。这种设计使得工作流天然具备可观测性和可回溯性，但同时也意味着它无法原生支持「模型自主决定下一步」的动态编排模式。

这个限制并非平台的技术缺陷，而是一种设计取舍：工作流追求的是可预测、可调试、可复现的执行路径，而Agent追求的是灵活应对未知场景的自主性。二者的张力，正是这场讨论的起点。

能否用Skill转化Skill？

作者提出的核心思路颇具递归美感：如果存在一个Skill，它能够把普通的业务Skill「完美地」转化为工作流，那么只需将这个转化Skill作用于自身，理论上就能得到一个「转化工作流的工作流」。

这实际上是一个自指（self-reference）问题。在计算理论中，类似的构造并不陌生——编译器可以用它所编译的语言来编写自身（自举，bootstrapping），一个通用图灵机可以模拟任意其他图灵机。

自指与自举的思想在计算机科学中有深厚渊源。自指最著名的极端例子是哥德尔不完备定理——一个足够强的形式系统无法证明自身的一致性。在工程实践中，自举（Bootstrapping）则更为具体：GCC编译器最终用C语言编写自身，这意味着编译器的能力边界决定了其自我描述的边界。作者将「元Skill转化自身」类比为这类自指构造，暗含了一个深层问题：若Skill到Workflow的转化本身是有损或不完备的，那么转化器作用于自身时，这种不完备性将被暴露甚至放大。这也呼应了图灵的停机问题——某些计算边界是原理性的，而非工程性的。

作者的设想，本质上是在追问：Skill到Workflow的转化，是否是一个可以被完全自动化、且封闭自洽的过程？

如果答案是肯定的，那意味着所有Skill在本质上都能被「静态展开」为固定的执行图——AI应用的动态性不过是表象，底层依然是确定性流程。这对工程实践的意义相当深远：可视化、可审计、可优化的工作流将能替代大部分黑盒Agent。

转化成立的前提：执行路径可被静态划定

作者特别强调了一个关键前提——「过程都能被划为有向工作流」。换言之，只有当一个Skill的执行路径能够被预先确定为一张有向图时，转化才成立。工作流中允许LLM节点做局部判断和生成，但整个流程的分支结构必须是可枚举、可静态描述的。

这把问题的核心暴露出来：并非所有Skill的执行路径都能被预先划定。

Loop架构：无法被工作流化的反例

这场讨论最有价值的部分，恰恰来自作者自己给出的「破局」案例。他指出，现在已经有了Loop（循环）架构——让模型自我编排流程、在运行时动态生成下一步动作的机制。

Loop架构（循环架构）是现代AI Agent实现中的关键范式，也常被称为ReAct（Reasoning + Acting）或Plan-and-Execute框架。其核心机制是：模型在每一步根据当前上下文输出「下一步动作」，执行该动作后将结果反馈回模型，模型再决定是否继续循环或终止。这种架构中，执行路径的「图结构」并非预先定义，而是在运行时被模型动态构建——每次迭代产生一条新边，直至模型判断任务完成。OpenAI的Function Calling、Anthropic的Tool Use、LangGraph的状态机图以及AutoGen的多智能体对话，都是Loop架构的不同实现变体。Loop架构的强大之处在于能处理「不知道需要几步」的开放性任务，但其代价是执行路径无法预审、Token消耗难以预估、错误传播路径复杂。

借助Loop架构，模型可以在运行时根据中间结果决定下一步做什么、调用哪个工具、是否继续迭代。这种「运行时才确定的执行路径」，从原理上就无法被提前展开为一张固定的有向图——因为图的形状本身，是在执行过程中动态生长出来的。

换句话说，只要允许模型在运行时进行无界的自我编排，就必然能构造出一个「无法被工作流化的Skill」。这正是Agent范式与Workflow范式的根本分野：

• 工作流：执行图在设计阶段确定，运行时只是沿图执行。可预测、可复现，但灵活性受限。
• Agent（Loop架构）：执行路径在运行时动态生成，具备应对开放场景的能力，但难以静态审计与复现。

这场讨论的现实启示

看似轻松的技术调侃，对AI应用架构师其实颇有参考价值。

第一，大多数企业级AI需求可以被工作流化。 很多表面上需要「智能体」的场景，拆解后会发现执行路径是可枚举的——用带LLM节点的工作流实现，往往更稳定、成本更低、也更易于排障。这正是Dify等平台坚持限制Agent节点、优先推广工作流的产品逻辑所在。在企业级落地中，工作流的核心优势在于SLA（服务级别协议）可承诺性——由于执行路径固定，延迟、成本和输出格式均可预测，便于计费、监控和合规审计。微软在Azure AI Foundry、谷歌在Vertex AI中均优先推广确定性Pipeline而非开放式Agent，正是出于企业客户对可预测性的强烈需求。

第二，真正需要Loop/Agent的是路径不可预知的任务。 比如开放式研究、多轮自主探索、需要根据环境反馈动态调整策略的场景。这类需求无法通过静态编排解决，强行工作流化只会得到臃肿且残缺的「分支地狱」。相比之下，Agent/Loop架构更适合内部工具、研究辅助、创意生成等容错空间较大的场景。

第三，「转化一切的元Skill」在Loop架构面前是不可实现的。 这不是能力问题，而是可计算性层面的边界——正如没有任何通用程序能判定所有程序是否停机。一个实用的架构决策框架是：若任务的「执行步骤集合」在设计时可被完整枚举，选工作流；若步骤集合依赖运行时状态且在设计时不可知，选Agent。承认这个边界，反而能让架构选型更清晰：先问「这个任务的路径能否被预先划定」，再决定用工作流还是Agent。

结语

从「用一个Skill转化所有Skill」的递归幻想，到「Loop架构构造出不可工作流化Skill」的自我否定，这段简短的思考完整演绎了当下AI应用开发的核心矛盾。答案或许并不浪漫：不存在万能的转化器，但也正因如此，工作流与Agent才各有其不可替代的位置。理解二者的边界，比追求一个统一的「银弹」更有工程价值。

核心要点