GLM 5.2 接入 Dify：零代码构建 AI 应用与工作流

痛点:不写后端代码也能构建 AI 应用

大多数想做客服聊天机器人、文档问答工具或多步 AI 工作流的团队都撞上同一堵墙:他们有可用的模型,却没有时间或人手去搭围绕它的基础设施。你需要对话记忆、检索管线、工具集成、UI、日志和限流——而这些没有一样是你真正想交付的产品。

Dify 恰好解决这个问题。它是一个开源的 LLM 应用平台,让你接上任何 OpenAI 兼容的模型、把文档上传进知识库、连接外部工具、发布一个能用的应用——全部通过可视化界面完成,团队无需写任何后端代码。

本教程带你完成 GLM 5.2(模型 ID:glm-4-plus)接入 Dify 的全程,并构建三种可直接投产的应用类型:聊天机器人、带工具的 ReAct 智能体、用于文档问答的 RAG 管线。

Dify 是什么?

Dify 是一个用于构建和运行 LLM 应用的开源平台。你可以通过 Docker Compose 在本地运行,也可以使用 dify.ai 的托管云服务。源码和自托管说明在 github.com/langgenius/dify。

核心能力包括:

• 聊天机器人构建器 — 带持久记忆、系统提示词和可分享 UI 的多轮对话
• 智能体模式 — ReAct 风格智能体,可调用工具:网页搜索、代码解释器、文件读取器
• 工作流画布 — 可视化节点式自动化(HTTP 请求 → LLM 节点 → 条件分支 → 输出)
• RAG 管线 — 上传 PDF、Word 文档或 Markdown 文件;Dify 自动分块并索引;你的模型基于这些内容回答提问
• 提示词编排 — 带变量注入的版本化提示词模板
• 内置可观测性 — 对话日志、token 用量和延迟指标,无需额外工具

Dify 的「OpenAI 兼容」自定义模型 provider 意味着任何遵循 /v1/chat/completions 规范的 API 都能在几分钟内接入。GLM 5.2 是直接契合的。

竞争差异化

在 Dify 里运行 GLM 5.2,与用 GPT-4o 跑同样的工作流相比,是一个很有说服力的性价比组合。

按每百万输入 token $1.40、每百万输出 token $4.40 计算,GLM 5.2 在同等 Dify 应用上的成本大约是 GPT-4o 的三分之一。对一个月处理数百万 token 的客服聊天机器人团队来说,这个差距会累积成可观的基础设施节省。

GLM 5.2 还带来了 1,048,576 token 的上下文窗口——约 100 万 token。对于想把整本技术手册、大型法律合同或大块代码库装进上下文的 RAG 场景,这种容量减少了短上下文模型必须做的激进分块取舍。

在基准质量上,GLM 5.2 拿下 GPQA Diamond 89% 和 SWE-bench Pro 62.1%,是通过 OpenAI 兼容 API 能拿到的最强模型之一。价格、上下文长度和基准表现的组合,让它成为那些已经越过 GPT-3.5、又想避开 GPT-4o 定价的团队的实际默认选择。

第 1 步:验证你的 GLM 5.2 API 访问

配置 Dify 之前,先确认你的 Zhipu AI API key 能用。前往 open.bigmodel.cn 注册账号,从控制台生成一个 API key。

跑一个快速检查来确认连通性。如果之后 Dify 报连接错误,这段代码也是个有用的参照:

import openai

client = openai.OpenAI(
    api_key="YOUR_ZHIPU_API_KEY",
    base_url="https://open.bigmodel.cn/api/paas/v4/",
)

response = client.chat.completions.create(
    model="glm-4-plus",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is your context window size?"},
    ],
    max_tokens=256,
)

print(response.choices[0].message.content)
print(f"Total tokens used: {response.usage.total_tokens}")

如果它返回了连贯的回答,说明你的 key 有效、API base URL 正确。关于 GLM 5.2 API 的完整拆解——包括函数调用、JSON 模式、流式与批量端点——见我们的 GLM 5.2 API 参考指南。

第 2 步:在 Dify 中把 GLM 5.2 添加为模型 provider

Dify 通过自定义模型 provider 系统支持任何 OpenAI 兼容 API。

1. 打开你的 Dify 工作区,进入 Settings → Model Provider。
2. 点击 Add Model,从 provider 列表中选择 OpenAI-Compatible。
3. 填写配置字段:

4. 点击 Save,然后 Test。Dify 会发送一个简短的补全请求,并以绿色对勾确认连接。

对勾出现后,GLM 5.2 就能在这个工作区里你创建的每个应用中使用。

第 3 步:五分钟内建好一个聊天机器人

1. 从 Dify 首页点击 Create App → Chatbot。
2. 给它起个名字,点击 Create。
3. 在 Prompt 面板里写下你的系统指令:

You are a helpful assistant for a SaaS product company.
Answer user questions clearly and concisely.
When you do not know the answer, acknowledge it and suggest where the user might look.

4. 在 Model 下,从下拉框选择 glm-4-plus。你会看到列出的 1,048,576 token 上下文窗口。
5. 按你的用例调整 Temperature 和 Max Tokens。
6. 点击 Publish,把链接分享给团队。

这就是一个能用的聊天机器人:带对话记忆、可配置的系统提示词、可分享的 UI——零服务器搭建。

第 4 步:构建带工具的 ReAct 智能体

Dify 的智能体模式运行一个 ReAct 循环:GLM 5.2 对任务进行推理,选择工具,观察输出,一直继续到得出最终答案。

1. 新建一个应用,选择 Agent。

2. 把 glm-4-plus 设为模型。

3. 从 Tools 面板启用工具。好用的组合:

   • Web Search — 对话过程中实时检索信息
   • Code Interpreter — 智能体编写并执行 Python,做计算、数据转换或文件处理
   • File Reader — 智能体处理用户对话中途上传的文档

4. 写一段简洁的系统提示词,定义智能体的职责范围和角色设定。

5. 在预览面板用多步提示词测试:「查找当前美元兑欧元的汇率,然后计算 3,500 美元等于多少欧元。」

智能体会调用网页搜索获取汇率,再用代码解释器执行计算——GLM 5.2 在单条推理链内编排这两次工具调用。

第 5 步:搭建文档问答的 RAG 管线

这里是 GLM 5.2 的上下文窗口相对短上下文替代品产生实际优势的地方。

创建知识库:

1. 在 Dify 工作区进入 Knowledge,点击 Create Knowledge Base。
2. 上传你的文档——PDF、Word、Markdown、纯文本,或粘贴一个 URL。Dify 自动处理分块和索引。
3. 从你已配置的 provider 里选一个 embedding 模型。Dify 的默认值就很好用;你也可以为了成本一致性配置一个 Zhipu embedding 模型。

把知识库接进聊天机器人:

1. 新建一个 Chatbot 应用。
2. 在 Knowledge 面板里选择你刚创建的知识库。
3. 把 glm-4-plus 设为模型,配置一条检索提示词,例如:

Use the provided context to answer the user's question accurately.
If the context does not contain the answer, say so clearly.
Context: {context}

4. 发布应用。

对于非常大的文档——技术手册、长法律协议、整个代码仓库——GLM 5.2 的 1M token 窗口减少了文档被迫激进分块以塞进更短上下文时发生的信息损失。有足够的上下文可用时,模型可以跨整份文档推理,而不仅仅依赖检索出来的片段。

第 6 步:用可视化画布自动化工作流

Dify 的工作流构建器让你不写代码就能把节点串成自动化管线。一个实用示例:用户提交 URL → Dify 抓取页面内容 → GLM 5.2 提取要点 → 以结构化文本输出。

1. 新建一个应用,选择 Workflow。

2. 从 + 面板添加节点:

   • Start — 定义输入变量(例如:url、focus_topic)
   • HTTP Request — 抓取 URL 内容
   • LLM — 把模型设为 glm-4-plus,写一条引用 HTTP 输出变量的提示词
   • End — 返回 LLM 输出

3. 按顺序连接节点,点击 Run 用真实 URL 测试。

对于开发者集成,Dify 为每个已发布的工作流都暴露了一个 REST API。下面是一个调用已发布 Dify 工作流端点的 Python 示例:

import requests

DIFY_API_KEY = "YOUR_DIFY_APP_API_KEY"
DIFY_ENDPOINT = "https://api.dify.ai/v1/workflows/run"

payload = {
    "inputs": {
        "url": "https://example.com/article",
        "focus_topic": "main conclusions"
    },
    "response_mode": "blocking",
    "user": "user-001"
}

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

response = requests.post(DIFY_ENDPOINT, json=payload, headers=headers)
result = response.json()

print(result["data"]["outputs"])

这个模式让工程团队能通过一次 HTTP 调用,把 Dify 驱动、GLM 5.2 支撑的逻辑嵌进任何现有应用——调用方无需维护任何 LLM 基础设施。

你可以构建什么

部署选项

Dify 支持两种托管路径:

• Dify Cloud — 托管在 dify.ai。有免费档;付费套餐覆盖生产规模。GLM 5.2 通过自定义 OpenAI 兼容 provider 在所有档位都可用。
• 自托管 — 从 github.com/langgenius/dify 做 Docker Compose 部署。数据完全可控,模型流量不经过 Dify 的服务器。推荐企业或合规敏感部署使用。

两种情况下,你的 GLM 5.2 API 调用都直接从 Dify 发往 Zhipu AI 的端点。Dify 从不代理或存储你的模型流量。

如果你正在为生产工作流评估 GLM 5.2,glm5.app 是一个有用的起点——它把模型能力、基准对比和实时演示聚合在一处。

一旦 Dify 配上 GLM 5.2 跑起来,这个组合就能以 GPT-4o 方案的零头成本覆盖大多数无代码 AI 应用需求。1M 上下文窗口和强劲的推理基准意味着,你走到这一步并没有在能力上做出重大妥协。在敲定架构之前,先到 glm5.app 看看 GLM 5.2 能做什么。

Sources

• Zhipu AI GLM-4 API documentation: https://open.bigmodel.cn/dev/api
• GLM-4 model weights on Hugging Face: https://huggingface.co/THUDM/GLM-4
• Dify official site: https://dify.ai
• Dify GitHub repository: https://github.com/langgenius/dify
• Artificial Analysis GLM-4-Plus benchmark data: https://artificialanalysis.ai/models/glm-4-plus