Dify平台对国产大模型的支持情况调研报告

Dify作为开源低代码AI平台，通过可视化编排、RAG集成与Agent框架，高效对接通义千问、百川、GLM等国产大模型，实现企业级应用快速构建与私有化部署，降低AI落地门槛。

又可乐

1035人浏览 · 2025-12-25 14:07:57

又可乐 · 2025-12-25 14:07:57 发布

Dify平台对国产大模型的支持情况调研报告

在AI技术加速落地的今天，越来越多企业开始尝试将大语言模型（LLM）融入实际业务流程。然而，面对通义千问、百川智能、讯飞星火、智谱AI等不断涌现的国产大模型，如何快速构建稳定、可控、可维护的AI应用，依然是横亘在产品与工程团队面前的一道难题。

传统开发方式往往依赖算法工程师手动编写提示词、封装API调用逻辑、搭建检索管道，整个过程不仅耗时耗力，还极易因模型切换或需求变更导致系统重构。更现实的问题是：很多团队根本没有足够的人力去持续维护一个动态演进的AI系统。

正是在这样的背景下，Dify这类开源低代码AI应用平台的价值逐渐凸显。它并非简单地提供一个“聊天界面”，而是试图从底层重构AI应用的构建范式——通过可视化编排、模块化组件和标准化接口，让企业能够以更低的成本、更快的速度实现国产大模型的工程化落地。

可视化AI应用编排引擎：让非技术人员也能参与AI设计

如果把AI应用比作一条流水线，那么Dify的核心能力之一就是提供了这条流水线的“图形化装配工具”。用户不再需要写一行代码，就能拖拽出一个包含条件判断、循环执行、多节点串联的复杂工作流。

它的本质是一个为LLM场景深度优化的低代码调度系统。每个节点代表一个功能单元：可以是大模型推理、文本清洗、数据库查询，也可以是自定义函数或外部服务调用；连接线则定义了数据流向与执行顺序。当你在界面上画出：

[用户输入] → [向量检索] → [拼接上下文] → [调用大模型生成] → [输出结果]

这套流程就会被自动转换成标准的YAML/JSON结构，并由后端引擎按拓扑序执行。支持同步阻塞和异步流式两种模式，兼顾响应速度与用户体验。

这种设计带来的最大变化是什么？开发权责的重新分配。

过去，产品经理提出“我们想要一个能根据客户历史订单推荐商品的客服机器人”，接下来就要等算法团队花几天时间写完提示词、接入知识库、调试效果。而现在，产品经理可以直接在Dify里自己搭出原型：拉一个输入节点，接一个检索节点查订单记录，再连上大模型生成建议话术——整个过程就像搭积木一样直观。

当然，这并不意味着完全取代工程师。相反，专业人员可以把精力集中在更高价值的事情上：比如优化嵌入模型的选择、设计更精细的变量传递规则、开发复用性高的自定义插件。而原本那些重复性的流程组装工作，则交给了更适合的人来做。

值得一提的是，虽然Dify主打可视化操作，但它并没有牺牲程序化能力。你可以通过API完全控制应用配置，实现批量部署、自动化测试甚至CI/CD集成。例如下面这段Python脚本，就创建了一个基于通义千问的客服机器人：

import requests

url = "http://dify.example.com/api/v1/applications"

payload = {
    "name": "Customer Service Bot",
    "mode": "chat",
    "workflow": {
        "nodes": [
            {"id": "input", "type": "user_input", "config": {}},
            {
                "id": "retrieval",
                "type": "retriever",
                "config": {
                    "index_name": "faq_knowledge_base",
                    "top_k": 3
                }
            },
            {
                "id": "llm",
                "type": "llm",
                "config": {
                    "model_name": "qwen-max",
                    "prompt_template": "根据以下信息回答问题：{{context}}\n\n问题：{{user_input}}"
                }
            }
        ],
        "edges": [
            {"source": "input", "target": "retrieval"},
            {"source": "retrieval", "target": "llm", "data": {"variable": "context"}},
            {"source": "input", "target": "llm"}
        ]
    }
}

headers = {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json"
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print("Application created successfully")
else:
    print(f"Error: {response.text}")

这个例子中，model_name设为qwen-max，说明平台已原生支持阿里云的大模型API协议。类似的，你也可以换成glm-4、baichuan2-turbo等国产主流型号，只需改个名字即可完成切换——背后复杂的认证、token处理、流式解析都已被抽象掉。

RAG系统集成：解决“幻觉”的实用主义方案

大模型的知识截止日期和事实准确性一直是落地中的硬伤。即便像通义千问max这样参数量庞大的模型，在面对企业内部政策、产品手册这类私有知识时，依然可能一本正经地胡说八道。

这时候，RAG（Retrieval-Augmented Generation）就成了最务实的选择。Dify没有把它当作一个高级功能藏着掖着，而是直接做成了开箱即用的标准能力。

整个流程非常清晰：上传文档 → 自动分段 → 向量化存储 → 提问时检索相关片段 → 注入提示词 → 生成答案。关键在于，这个链条上的每一个环节都是可配置、可替换的。

比如你在“嵌入模型”选项里，既可以选HuggingFace上的开源中文小模型如bge-small-zh来节省成本，也能对接阿里云、百度文心等厂商提供的高性能API以提升精度。向量数据库方面，支持Weaviate、Milvus、PGVector等多种后端，方便与现有基础设施整合。

更重要的是，知识库支持热更新。这意味着当公司发布了新的年假制度，HR只需要登录Dify上传最新PDF，系统就能立刻生效，无需重启服务或重建索引。对于高频变动的行业（如金融合规、医疗指南），这一点尤为关键。

实际使用中还有一个容易被忽视但极其重要的细节：上下文拼接策略。很多平台只是简单地把检索结果堆在一起扔给模型，结果经常出现信息冲突或冗余。而Dify允许你自定义模板，比如：

请结合以下参考资料作答：
{% for doc in context %}
【来源：{{doc.title}}】{{doc.content}}
{% endfor %}

问题：{{user_input}}

要求：引用原文内容，标注出处编号。

这样一来，不仅能提高回答质量，还能实现结果溯源，满足审计需求。

下面是调用该系统的Python示例：

import requests

def query_knowledge_base(question: str):
    url = "http://dify.example.com/api/v1/completion-messages"

    payload = {
        "inputs": {"query": question},
        "query": question,
        "response_mode": "blocking",
        "user": "user-123"
    }

    headers = {
        "Authorization": "Bearer YOUR_API_KEY",
        "Content-Type": "application/json"
    }

    response = requests.post(url, json=payload, headers=headers)

    if response.status_code == 200:
        data = response.json()
        return data["answer"]
    else:
        raise Exception(f"Request failed: {response.text}")

result = query_knowledge_base("公司年假政策是如何规定的？")
print(result)

如果你希望获得流式输出（比如网页端逐字显示），只需将response_mode改为streaming并配合SSE处理即可。这种灵活性使得同一套系统既能用于后台批处理，也能支撑前端实时交互。

Agent智能体框架：从“能说”到“能做”的跨越

如果说RAG解决了“知道什么”的问题，那Agent要解决的就是“能做什么”。

传统的问答机器人本质上是被动响应：你说一句，它回一句。而真正的智能代理应该具备目标导向的行为能力——比如你说“帮我查下杭州明天的天气”，它不仅要理解意图，还要主动调用天气API、解析返回结果、组织自然语言回复。

Dify的Agent框架正是基于ReAct（Reason + Act）范式构建的。其运行机制可以用一句话概括：每一步都先思考（Thought），再决定是否采取行动（Action）。

具体来说，当用户发出指令后，模型会在内部进行链式推理：“我现在需要获取天气信息 → 需要用到get_weather工具 → 工具需要城市参数 → 用户提到了‘杭州’→ 调用get_weather(city=’杭州’)”。待工具返回结果后，继续推理并生成最终回复。

这一切的前提是工具注册。Dify支持通过OpenAPI规范导入外部服务，自动封装为可调用工具。以下是一个注册天气查询功能的示例：

tool_payload = {
    "name": "get_weather",
    "description": "根据城市名称获取当前天气状况",
    "schema": {
        "type": "function",
        "function": {
            "name": "get_weather",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "城市名称，如北京、上海"
                    }
                },
                "required": ["city"]
            }
        }
    }
}

resp = requests.post(
    "http://dify.example.com/api/v1/tools",
    json=tool_payload,
    headers=headers
)

注册完成后，开发者可在可视化界面中启用该工具，后续模型便会根据上下文自动判断是否调用。所有调用都会经过权限校验，防止越权访问敏感接口。

这一能力打开了全新的应用场景：
- 客服Agent可自动查询订单状态、重置密码、提交工单；
- 办公助手能读取日历、安排会议、发送邮件；
- 数据分析师Agent可连接BI系统，按需生成报表摘要。

更重要的是，这些行为是可以被追踪和审计的。每一次工具调用、每一项参数传递都有完整日志，避免黑箱操作带来的风险。

架构设计与落地实践：为什么Dify适合国产化替代？

回到最初的问题：在一个强调自主可控、数据安全的环境下，Dify凭什么成为连接国产大模型与行业应用的桥梁？

答案藏在其四层架构之中：

前端交互层：Web UI全量汉化，符合国内用户操作习惯；
应用逻辑层：核心引擎完全开源，可私有化部署，保障数据不出内网；
模型接入层：抽象出统一的LLM Provider接口，屏蔽各家API差异；
数据支撑层：兼容主流国产数据库与向量引擎，适配信创生态。

其中最关键的是第三层。Dify并没有绑定任何特定厂商，而是通过插件机制支持多种国产模型，包括但不限于：
- 通义千问系列（qwen-max、qwen-plus）
- 百川智能（baichuan2-turbo、baichuan-agent）
- 智谱AI GLM（glm-4、glm-3-turbo）
- 讯飞星火（spark-v3、spark-protocol）

切换模型仅需在配置页面点选，无需修改任何代码。这让企业可以在不同供应商之间自由对比效果与性价比，避免被单一厂商锁定。

此外，在真实项目落地过程中，我们也总结了一些行之有效的经验：