低代码

当团队里有人说「我想要一个能读表格、按规则出结论的小助手」，直接写代码往往是杀鸡用牛刀。Dify 这类开源编排平台的价值，就是把模型调用、知识库、条件分支、人工节点拖成一张图，产品经理也能看懂。在 Manus 这类通用 Agent 越来越强的同时，垂直小场景反而更适合用「可控的工作流」而非「自由的 Agent」。 最短部署路径 官方仓库自带 docker-compose。在一台有 8GB 内存以上的机器上： git clone https://github.com/langgenius/dify.git，进入 docker 目录； 复制 .env.example 为 .env，按需改对外端口与密钥； docker compose up -d，等所有容器起来后访问 http://localhost/install 初始化管理员账号。 接模型与跑通第一个流 进控制台后，在「模型供应商」里填 OpenAI 兼容接口的 base_url 与 key——DeepSeek、智谱、自建网关都能接。然后建一个「工作流」： 开始节点收一个文本输入（待审批的报销描述）； 接一个 LLM 节点，提示词让它按「金额／事由／是否超标」三栏输出； 再接一个条件分支，金额超阈值走「转人工」，否则走「通过」。 Dify 会自动把这个流暴露成一个 API 端点，内网系统直接 POST 调用。 什么时候该用，什么时候别用 工作流适合路径确定、要求可复现的场景：审批摘要、合同初筛、客服分流。它不适合开放式任务——那种要让模型自己决定下一步做什么的，交给 Agent 框架。把 Dify 当「可控的自动化管道」，而不是「万能机器人」，它才会好用。 补一个团队协作的细节：Dify 的应用可以一键发布成网页或 API，产品同学在网页上自己调提示词和知识库，工程师只负责接后端接口。这种分工比「所有改动都要开发提 PR」快得多。上线前记得打开它的调用日志，看每个节点的耗时，慢的那一步往往是被忽略的外部接口，而不是模型本身。 把 Dify 用成团队的「自动化管道车间」，而不是一个人玩的玩具，它的价值才真正释放出来，产品和工程各就其位。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Dify实战

现状 输入做一个待办清单App，自动生成 拖拽+AI辅助 自然语言改需求 工具 各类AI应用生成器 低代码平台+AI 能力边界 简单应用：几分钟搞定 中等应用：能生成，需调试 复杂应用：还需专业开发 意义 开发从专业变平民。业务人员可以直接做工具，程序员专注复杂系统。

Dify 2026：从LLM应用到Agent平台 Dify在2026年完成了从"LLM应用开发平台"到"全栈AI Agent平台"的蜕变。凭借其低代码可视化界面和强大的后端引擎，Dify已成为开源AI应用开发领域下载量最高的平台之一。 本文将深入分析Dify 2026的核心能力、架构设计和生产适用性。 平台架构演进 2026版架构全景 ┌──────────────────────────────────────────────────┐ │ 可视化编排层 (Studio) │ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐│ │ │ Chatflow│ │ Workflow│ │ Agent │ │ 知识库 ││ │ │ 编排 │ │ 编排 │ │ 编排 │ │ 管理 ││ │ └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘│ ├───────┼────────────┼──────────┼────────────┼────┤ │ 运行时引擎 (Runtime) │ │ ┌─────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ DAG执行器 │ │ Tool调用器 │ │ RAG Pipeline │ │ │ └─────────┘ └──────────┘ └──────────────┘ │ ├──────────────────────────────────────────────────┤ │ 基础设施层 (Infra) │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │ │ │ LLM │ │向量DB │ │ 对象 │ │ 消息队列 │ │ │ │ 网关 │ │ │ │ 存储 │ │ │ │ │ └──────┘ └──────┘ └──────┘ └──────────┘ │ └──────────────────────────────────────────────────┘ 核心组件解析 DAG执行器是Dify工作流的底层引擎，2026版本重写后性能提升3倍： ...

Dify 2026：从工作流到 AI 操作系统 Dify 在 2026 年经历了从"LLM 应用开发平台"到"AI 操作系统"的蜕变。这个由苏州语灵科技打造的开源平台，已经积累了 45.6k GitHub Stars，成为亚洲最大的 AI 应用开源项目之一。本文将从实际使用出发，对 Dify 2026 版本进行全面评测。 核心能力总览 1. 可视化 Workflow 编排 Dify 2026 的 Workflow 编辑器是评测中体验最好的部分。拖拽式画布支持以下节点类型： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Start 节点 │───→│ LLM 节点 │───→│ 条件分支节点 │ │ (输入定义) │ │ (模型选择) │ │ (IF/ELSE) │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ┌──────────────────┤ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ 知识检索节点 │ │ HTTP 请求节点 │ │ (RAG) │ │ (API 调用) │ └──────┬──────┘ └──────┬──────┘ │ │ └────────┬─────────┘ ▼ ┌─────────────┐ │ End 节点 │ │ (输出定义) │ └─────────────┘ 评测中发现，Workflow 的条件分支节点支持嵌套逻辑，代码节点支持 Python 和 JavaScript 双语言： ...

引言 2026 年，AI 应用开发平台已经成为开发者工具链中不可或缺的一环。在国内市场，Dify 和 Coze（扣子）是两个最受关注的选择。两者都定位为低代码/无代码 AI 应用构建平台，但在设计理念、技术架构和适用场景上差异显著。 本文将从实际开发体验出发，从七个维度对两个平台进行深度对比。 一、平台定位与架构 维度 Dify Coze 定位 开源 LLM 应用开发平台 字节跳动 AI Bot 构建平台 部署方式 支持私有化部署 纯 SaaS（国内/国际版） 核心抽象 Workflow + Agent + RAG Bot + Plugin + Workflow 开源状态 Apache 2.0 开源 闭源 技术栈 Python + TypeScript 字节内部技术栈 Dify 的核心优势在于开源可私有化。对于有数据合规要求的企业，Dify 可以部署在自有服务器上，数据完全自控。Coze 则背靠字节生态，开箱即用，适合快速验证想法。 二、工作流引擎对比 Dify 的工作流采用 DAG（有向无环图）模型： # Dify Workflow 示例 nodes: - id: start type: start variables: - name: query type: string - id: llm type: llm model: gpt-4o prompt: "回答以下问题：{{query}}" - id: end type: end output: "{{llm.output}}" Coze 的工作流更偏可视化拖拽，节点类型更丰富，内置了搜索、图片生成、知识库等字节生态能力。但 Coze 的工作流不支持导出和版本管理，这在团队协作中是个痛点。 ...