Dify低代码：LLM应用构建

可视化演示

动态演示Dify低代码的核心机制，通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

平台概览：AI应用的中央厨房

想象你是一位想开餐厅的创业者。你不需要自己养猪种菜、发明酱油配方，更不需要从零打造一座燃气灶——你只需要租用一间“中央厨房”，里面的炉灶、冷库、切菜台一应俱全，你只管把菜品设计好、把食材组合起来，就能端出成品菜。这就是“低代码”的核心哲学：不重复造轮子，把成熟的能力当作现成模块来拼接。

在AI应用开发的世界里，Dify就是这样一个“中央厨房”。传统的LLM应用开发，需要你从零搭建Prompt工程、设计知识检索流程、编写Agent推理逻辑、对接模型API、再写一套后端服务来管理用户请求——就像为了开一家面馆，先得建一座面粉加工厂。Dify把这些繁琐的“基建”全部封装为可视化模块，你只需在浏览器里拖拽、配置，就能把原本需要数周开发的AI应用压缩到几小时完成。

Dify的核心能力可以拆解为三个层面：一是模型接入层，内置了OpenAI、Anthropic、通义千问等数十种主流LLM的API接入，你只需填写一个密钥就能切换底层模型；二是应用编排层，提供工作流画布、Agent配置、知识库绑定等可视化工具；三是部署运营层，支持一键发布API、监控调用日志、管理团队成员。这是一套完整的LLM应用生命周期管理方案，覆盖了从Prompt到生产部署的全链路。

回到中央厨房的比喻：LLM是你的主厨，Prompt是指令，知识上下文是菜谱，工具调用是帮厨。Dify把主厨、菜谱、食材、帮厨全部备齐，你只需要巧妙组合它们——这正是低代码的魅力：你不需要会训练模型、构建向量数据库或写Agent搜索引擎，就能构建出专业的LLM应用。

可视化工作流：打通后厨的流水线

走进一家现代化快餐连锁店的后厨，你会看到一条清晰的流水线：配菜台把食材切好码齐，递到烹饪区，出锅后滑入装盘区，最后送到出餐口。每一步都有专门的工位，食材沿着固定的轨道流动，任何一个工位出了问题，整条线的节奏都会一目了然。

Dify的可视化工作流，就是这条AI应用的流水线。在Dify的画布上，你看到的不是一行行代码，而是一个个可以自由拖拽的节点：开始节点、LLM节点、知识检索节点、条件分支节点、工具节点、结束节点。你像铺设流水线一样把它们连起来，就完成了一个应用的主干逻辑。比如一个客服机器人，可以是“开始 → 意图判断 → 知识检索 → LLM生成 → 结束”这样标准的一条线。

每个节点都是一个可配置的“工位”。LLM节点可以切换模型、调节温度参数、限制最大Token数；知识检索节点可以绑定某个知识库、设定返回条数；条件分支节点可以按关键词或结构化数据走不同的线路。节点的输出会成为下一个节点的变量输入，这种“数据流转”机制让复杂的多步推理被拆解成清晰的单元。比起硬编码逻辑，可视化工作流让整个应用的处理过程可读性极强，调试时只需查看每个节点的输入输出即可定位问题。

流水线的好处在于：改一道工序不需要重建整条线。在Dify中，你想在LLM前加一道“敏感词过滤”，只需拖一个节点插入即可，下游节点自动感知输入变化。这种可视化的流式编排，让AI应用的迭代像调整快餐店流水线一样灵活——今天换一盒调料，明天加一道配菜，后厨的节奏完全由你把控。

Agent编排：总厨调度帮厨

餐厅的总厨不会亲自切每一根葱、翻每一勺锅。他手里有一份“调度表”：切配师负责处理蔬菜，炒锅师傅负责烹制热菜，甜点师负责甜品。当一张新订单进来，总厨看一眼订单内容，决定哪些菜让哪位师傅做、什么顺序做、哪些菜需要几位师傅配合。在这个场景里，总厨就是Agent，各位师傅就是Agent可以调用的“工具”。

Dify的Agent编排，正是让LLM扮演这位“总厨”的总控角色。在Agent节点中，你可以挂载一组工具——可以是Dify内置的搜索、计算器，也可以是你自己接入的第三方API。当用户提出复杂需求时，Agent不会像普通聊天一样直接回答，而是先“思考”：这个任务需要调用哪个工具？需要查询什么数据？然后按计划逐个调用工具，把工具返回的结果聚合起来，最终给出一个综合性的答复。

这种“思考—行动—观察”的循环（业内称为ReAct模式）是Agent编排的核心机制。Dify通过“规划器”让LLM按结构化格式输出决策（比如JSON格式的“下一步动作”），系统解析该决策后执行对应的工具调用，将观察结果作为新的上下文反馈给LLM，循环往复直到任务完成。在多轮工具调用之间，Dify还支持“人机交互”节点：当Agent不确定时，可以把问题抛给人工确认，再带着人工的决策继续执行。

回到总厨的比喻：Agent让LLM不再是一个“只会聊天的厨子”，而是一个懂得调度资源的总厨。手下工具越多，能做的菜就越复杂。Dify将这种“总厨调度”的机制可视化、配置化，你不需要手写一套复杂的ReAct提示词，只需在界面上勾选Agent可用的工具，剩下的“排兵布阵”，交给你的总厨自己拿主意。

知识库管理：恒温食材冷库

一家餐厅要保证出品稳定，靠的是后方那座井井有条的冷库。每周采购的新鲜食材入库前要整理、打包、贴上标签；出库时按需取用，今天要做哪道菜，就从冷库里精准拿出对应食材。如果冷库乱成一团，厨师找食材就要花半小时，高峰期根本来不及。对AI应用来说，知识库就是这座冷库——LLM默认只知道自己训练时学过的知识，你的业务专有知识，必须预先“存入冷库”，才能运行时随时取用。

Dify的知识库管理，覆盖了“采购入库 → 整理分装 → 按需取用”的全流程。首先是数据导入：支持上传PDF、Word、Markdown、网页链接等多种格式，也可以通过API批量写入。导入后系统会自动分段，把长文档拆成适合检索的短文本块（业内叫chunk），并做数据清洗，去掉页眉页脚、重复信息等噪音。然后系统把这些文本块做嵌入向量化——也就是把每一段文字转换成一串可以计算语义相似度的数字坐标——存进内置的向量数据库。

当用户提问时，Dify的检索节点会先将问题向量化，在向量数据库中做相似度搜索，返回最相关的Top-K个文本块，把它们拼接到Prompt的上下文里，让LLM基于检索到的资料进行回答——这就是RAG（检索增强生成）。通过RAG，LLM可以回答它训练时从未见过的最新内容，同时也能在答案中附上引用来源，方便验证可靠性。Dify还允许针对每个知识库调整检索策略，比如按语义相关度、按关键词权重，或者混合模式。

冷库管理得越好，出菜越快越稳定。知识库的导入质量和分段策略，直接决定RAG效果的上限——如果食材又脏又乱，再顶尖的主厨也做不出干净的菜。Dify最重要的价值之一，就是把“冷库”管理做得足够傻瓜：上传、分段、向量化、绑定到应用，四个步骤走完，你的LLM应用就拥有了“最新、最准”的业务知识。

API发布：上架外卖平台

后厨忙活再久，菜要做出来给客人吃才算数。一家餐厅要营业，需要在美团、饿了么上架菜品，把菜单和价格公布出去；客人通过平台下单，餐厅接单后把成品菜送出去。与此同时，餐厅还会盯着后台的订单统计，看看今天卖了多少单、哪道菜最受欢迎，借此调整明天的备菜策略。

Dify的应用构建完成后，下一步就是“上架营业”。Dify提供了多种发布方式：一是WebApp模式，Dify直接帮你托管一个可分享的对话页面，无需任何前端开发，填入链接就能用；二是API发布模式，一键将应用封装为RESTful接口，你可以在自己的业务系统中调用；三是嵌入模式，通过一段iframe或脚本将对话组件嵌入到你的官网。三种方式涵盖了从“快速演示”到“生产集成”的各个阶段。

在API发布模式下，Dify做了很多“餐厅运营”的细节：访问控制层面支持API密钥鉴权，只有持有密钥的调用方才能访问你的应用，确保业务数据不外泄；运营监控层面提供调用次数、Token消耗、响应延迟、错误率等维度的统计面板，让你一眼看清应用的健康状况；此外还支持日志回溯，每一次用户与应用的对话都能回放，这对定位Prompt问题和优化产品体验至关重要。

在Dify上发布一个AI应用，本质上就是一次“低成本开门营业”：不需要自己买服务器搭网关，不需要自己写节流限流模块，只需要点一下“发布”，Dify的外卖平台就自动开张了。接下来你要做的，就是把API地址放到你的产品里，然后像餐厅老板一样，盯着监控面板看数据。这也解释了为什么Dify特别受AI产品团队欢迎——它把“做菜”和“开餐厅”两大难题一起解决了。

多租户支持：连锁分店各自经营

一家成功的连锁餐饮品牌，通常会有多家分店：北京店、上海店、深圳店……每家分店有自己的店长、员工和菜单，但所有分店共享同一个中央厨房的后勤体系。如果你要新开一家分店，不需要重建一座中央厨房，只需要租好店面、配置好人手、开放中央厨房的接入权限，当天就能开业。

Dify的多租户（多工作空间）机制，就是为这种“连锁经营”设计的。一个Dify实例可以创建多个工作空间（Workspace），每个空间相当于一家独立的分店：有自己的成员列表（通过邮箱邀请加入）、自己的应用集合、自己的知识库和标注数据。作为平台管理员，你可以创建空间并任命空间所有者；作为空间所有者，可以进一步管理本空间的成员角色和权限。

租户隔离是核心安全保障。不同工作空间之间的数据是隔离的——A空间的Prompt、知识库、API密钥、日志，B空间的成员和AI应用完全不可见。这让你可以用一个Dify部署支撑公司内部多个团队（如客服部、运营部、产品部各自一个空间），互不干扰。在权限管理上，Dify区分了“所有者、编辑、只读”等角色，配合资源级权限（谁能改这个应用、谁能看这个知识库），实现“小事不出分店，大事平台审批”的治理格局。

对于AI企业服务来说，多租户能力往往是从“做了个Demo”到“卖给企业客户”的门槛之一。Dify把多租户做成开箱即用的能力，让团队不必为每个客户单独部署一套系统，也不必自己从零写一套权限模型。这就像连锁品牌扩张时，不必为每家店买一个新中央厨房——总部统一运营、分店灵活配置，规模化的路自然就通了。

Prompt管理：秘制调料配方

去一家餐厅，让你印象深刻的不只是食材新鲜，还有那道独特的“秘制酱料”——同样的食材，配比不同、火候不同，出来的味道天差地别。每家大厨都有自己的配方本：盐3克、糖2克、生抽一勺、醋半勺……这个配方就是AI应用里的Prompt。同一个LLM，不同的Prompt设计，效果可能判若云泥。

Dify的Prompt管理，就是一套“配方工程”工具箱。在应用编辑页，你可以分别配置“系统提示词”（设定模型角色的全局指令）和“用户提示词模板”。模板里支持插入变量——比如用户输入的question、知识库检索出的context、Agent工具返回的result，所有这些运行时数据都能像调料一样自动填充进Prompt模板。

Dify还内置了上下文管理能力：在多轮对话场景中，它会自动维护对话历史（把前几轮的问答带进新请求），同时让你设置携带的轮数上限，避免超出模型窗口。模型调试方面，Dify编辑器右侧提供“模型参数”面板，可实时调整temperature（回复的随机性）、topP、max tokens等；左下角有“调试对话”窗口，让你改完Prompt立刻测试效果，不必等到发布后才发现问题。这套“配方—试吃—调整”的闭环，让Prompt优化变得非常高效。

好的调料配方需要反复试错，Dify的目的就是让“试错”的成本降到最低。每一位Prompt工程师本质上都是在为LLM写“菜谱”，而Dify提供了从配比（变量填充）、试吃（实时调试）到量产（发布上线）的完整工具链。正如大厨的秘方不是一次写成的，你的最佳Prompt也需要在同一条可视化流水线里不断迭代——Dify让这件事变得像做实验一样顺滑。

AI 应用场景

Python 演示

"""Dify风格LLM应用工作流模拟:可视化工作流 -> Agent编排 -> 知识库检索 -> 生成回答不依赖外部API, 纯逻辑模拟"""import refrom dataclasses import dataclassfrom typing import List, Dict, Tuple  @dataclassclass WorkflowNode:    """工作流节点基类"""    name: str     def run(self, data: dict) -> dict:        return data  class PromptNode(WorkflowNode):    """提示词节点: 组装模板"""    def __init__(self, name: str, template: str):        super().__init__(name)        self.template = template     def run(self, data: dict) -> dict:        question = data.get("question", "")        data["prompt"] = self.template.replace("{question}", question)        return data  class KnowledgeBase:    """知识库: 文档向量检索 (模拟)"""     def __init__(self, docs: List[Dict[str, str]]):        self.docs = docs     def search(self, query: str, top_k: int = 2) -> List[Tuple[str, float]]:        """基于关键词重合的简易检索"""        q_tokens = set(re.findall(r"[\w\u4e00-\u9fa5]+", query.lower()))        scored = []        for doc in self.docs:            content = doc["content"]            d_tokens = set(re.findall(r"[\w\u4e00-\u9fa5]+", content.lower()))            inter = len(q_tokens & d_tokens)            union = len(q_tokens | d_tokens) or 1            score = inter / union            scored.append((content, score))        scored.sort(key=lambda x: x[1], reverse=True)        return scored[:top_k]  class RetrievalNode(WorkflowNode):    """知识检索节点: 注入检索结果到上下文"""     def __init__(self, name: str, kb: KnowledgeBase, top_k: int = 2):        super().__init__(name)        self.kb = kb        self.top_k = top_k        self.hit_count = 0     def run(self, data: dict) -> dict:        question = data.get("question", "")        results = self.kb.search(question, self.top_k)        self.hit_count += len(results)        data["references"] = results        return data  class AgentLLMNode(WorkflowNode):    """Agent节点: 选择是否调用工具 (模拟推理)"""     def __init__(self, name: str, tools: List[Dict[str, str]]):        super().__init__(name)        self.tools = tools        self.tool_calls = 0     def run(self, data: dict) -> dict:        prompt = data.get("prompt", "")        refs = data.get("references", [])        context = "\n".join(f"- {doc}" for doc, _ in refs)         # 模拟Agent决策: 检测到计算/数字/总数则调用计算工具        if re.search(r"计算|数字|总数", prompt):            self.tool_calls += 1            nums = [int(n) for n in re.findall(r"\d+", prompt)]            data["answer"] = f"工具计算结果: {sum(nums)}"        else:            data["answer"] = f"基于检索回答: {context[:60]}"        return data  class OutputNode(WorkflowNode):    """输出节点: 格式化最终回答"""     def run(self, data: dict) -> dict:        data["final"] = f"[{self.name}] {data.get('answer', '')}"        return data  class Workflow:    """工作流引擎: 按节点顺序执行"""     def __init__(self, nodes: List[WorkflowNode]):        self.nodes = nodes     def run(self, question: str) -> dict:        data = {"question": question}        for node in self.nodes:            data = node.run(data)        return data  def main():    # 1. 搭建知识库    kb = KnowledgeBase([        {"content": "Dify是开源的低代码LLM应用开发平台"},        {"content": "Dify支持可视化工作流和Agent编排"},        {"content": "知识库通过RAG增强LLM回答"},        {"content": "Dify支持多租户隔离和API发布"},    ])     # 2. 构建可视化工作流    workflow = Workflow([        PromptNode("提示词节点", "请基于上下文回答问题: {question}"),        RetrievalNode("知识检索节点", kb, top_k=2),        AgentLLMNode("Agent推理节点", tools=[{"name": "计算器"}]),        OutputNode("结果输出节点"),    ])     # 3. 运行应用    for q in ["Dify是什么?", "请计算 10+20+30"]:        result = workflow.run(q)        print(f"Q: {q}")        print(f"A: {result['final']}\n")  if __name__ == "__main__":    main()

1. data["prompt"] = self.template.replace("{question}", question)模板变量注入，相当于Dify Prompt模板里{question}的运行时填充
2. q_tokens = set(re.findall(r"[\w\u4e00-\u9fa5]+", query.lower()))把文本切分成词集合，模拟向量化的“语义标记”
3. scored.sort(key=lambda x: x[1], reverse=True)按相似度分数降序排列，模拟向量检索的排序逻辑
4. self.hit_count += len(results)每次检索命中计数，对应Dify监控面板的知识库命中率
5. if re.search(r"计算|数字|总数", prompt):Agent的“决策”：判断当前任务是否需要调用工具
6. data = node.run(data)工作流引擎把上一个节点的输出传给下一个节点，对应Dify画布上的数据流转
7. workflow = Workflow([...])用列表按顺序组装节点，对应在Dify画布上拖拽连线

常见误区

面试题