第 20 章 Dify 应用和 Agent

Dify 是一个用于构建大模型应用的平台。它把模型调用、提示词、知识库、工作流、工具调用和应用发布整合到一起，适合快速搭建聊天助手、知识库问答、工作流应用和 Agent 应用。

Agent 是大模型应用的一种形态。普通聊天助手主要回答问题，Agent 更强调“闭环执行”：能理解目标、拆解任务、调用工具、观察结果，并根据反馈继续行动。

20.1 相关链接

资源	地址
Dify 官网	https://dify.ai
Dify 文档	https://docs.dify.ai
Dify GitHub	https://github.com/langgenius/dify

如果只是了解 Dify 能做什么，先看官网；如果要搭建应用，主要看官方文档。

20.2 Dify 能做什么

Dify 可以理解为大模型应用的编排平台。

常见能力：

能力	作用
模型接入	统一调用不同大模型
Prompt 编排	管理系统提示词、变量和上下文
知识库	上传文档，构建 RAG 问答
Workflow / Chatflow	用节点方式编排应用流程
Tools	接入搜索、API、数据库等外部能力
Agent	让模型自主选择工具并完成多步任务
API 发布	把应用发布成接口或 Web 应用

Dify 的价值不在于发明新的模型，而在于把大模型应用需要的组件整理成可配置、可部署的工程系统。

20.3 Dify 应用类型

Dify 中常见应用形态包括：

类型	说明
Chatbot	面向对话的助手
Agent	能使用工具的智能体
Workflow	按固定流程执行任务
Chatflow	面向对话场景的流程编排
Text Generator	文本生成类应用

如果任务流程固定，适合用 Workflow；如果任务需要模型自己判断下一步该调用什么工具，适合用 Agent。

20.4 Workflow 和 Agent 的区别

Workflow 更像流程图。开发者明确规定每一步做什么：

输入 -> 知识库检索 -> LLM 总结 -> 输出

Agent 更像带工具的执行者。开发者提供目标、工具和约束，模型在运行时决定怎么做：

用户目标 -> 模型思考 -> 选择工具 -> 观察结果 -> 继续行动 -> 输出

对比：

类型	控制方式	适合场景
Workflow	人预先设计流程	稳定、固定、可控的业务流程
Agent	模型动态决定步骤	多步推理、工具选择、开放任务

Workflow 的优点是稳定、可解释、便于调试；Agent 的优点是灵活，但结果更依赖模型能力和工具描述。

20.5 Agent 的基本组成

一个典型 Agent 系统通常包含：

模块	作用
Planner	拆解目标，决定下一步行动
Tool	执行具体动作，例如搜索、查数据库、调用 API
Memory	保存历史状态、用户偏好和上下文
Observation	接收工具返回结果
Reflection	检查结果是否满足目标，不满足则调整

这些模块不一定都由独立组件实现。它们更像 Agent 系统里的职责划分。

20.6 Dify 中的 Agent

Dify 的 Agent 重点在于工具调用。模型不只是生成文本，还可以根据任务需要选择工具、填写参数、读取工具返回结果，再继续推理。

一个简化流程：

用户输入
-> Agent 理解目标
-> 判断是否需要工具
-> 调用工具
-> 读取工具结果
-> 继续推理或生成最终回答

Agent 能不能稳定工作，主要取决于：

• 工具描述是否清楚。
• 工具参数是否明确。
• Prompt 是否给出任务边界。
• 最大迭代次数是否合理。
• 工具返回结果是否容易被模型理解。

20.7 工具调用

工具让 Agent 从“只会回答”变成“可以做事”。

常见工具：

工具	用途
搜索工具	获取外部信息
HTTP API	调用业务系统
数据库查询	查询结构化数据
代码执行	计算或处理数据
知识库检索	从私有文档中找答案

工具调用需要注意权限。凡是会修改数据、发消息、下单、删除文件的工具，都应该加权限控制、日志和人工确认。

20.8 知识库和 RAG

RAG 是 Retrieval-Augmented Generation，检索增强生成。它的基本流程是：

用户问题 -> 向量检索 -> 召回文档 -> 重排序 -> 拼接上下文 -> 生成回答

Dify 的知识库适合做企业文档问答、产品手册问答、制度查询、客服知识库等场景。

RAG 的目的不是让模型参数记住所有知识，而是回答前先查外部资料。这样可以提高时效性，也能减少幻觉。

20.9 Embedding 和 Reranker

Embedding 模型负责把问题和文档转成向量，用于快速召回相似内容。

Reranker 负责对召回结果重新排序，判断哪些文档和问题最相关。

常见流程：

Embedding 粗召回 -> Reranker 精排 -> LLM 生成回答

Embedding 解决“先找一批可能相关的文档”，Reranker 解决“从候选文档里挑最相关的”。

20.10 OpenClaw 架构

OpenClaw 是一种 Agent 系统架构示例，可以用来理解 Agent 应用怎样拆分职责。

题库中提到的 OpenClaw 核心架构有四个角色：

角色	作用
GateKeeper	多渠道指令接收与身份验证
Planner	负责任务拆解与决策规划
Worker	提供基础操作能力和具体任务方法
Memory	实现用户偏好和对话历史的持久化存储

可以按一句话记忆：

GateKeeper 管入口，Planner 管计划，Worker 管执行，Memory 管长期状态。

Dify 更偏应用编排平台，OpenClaw 更偏 Agent 运行架构。二者关注点不同，但都在解决同一个问题：怎样把大模型、工具、记忆和任务流程组织成可用系统。

20.11 Dify 适合的场景

Dify 更适合搭建应用，而不是训练模型。

适合场景：

• 企业知识库问答。
• 客服助手。
• 内部流程自动化。
• 报表总结。
• 文档处理。
• 低代码 AI 应用原型。
• 带工具调用的 Agent 应用。

不太适合的场景：

• 从零训练大模型。
• 极复杂的后端业务系统。
• 对执行结果要求极高但缺少校验机制的自动化任务。

20.12 Dify 和传统开发的关系

Dify 可以降低大模型应用的搭建成本，但不能完全替代后端开发。

可以把 Dify 理解成：

大模型应用编排层

它适合负责：

• LLM 调用。
• Prompt 管理。
• 知识库检索。
• Agent 工具编排。
• 应用原型搭建。

传统后端仍然适合负责：

• 用户系统。
• 权限控制。
• 复杂业务逻辑。
• 数据一致性。
• 支付、订单等高风险操作。

实际项目中，常见做法是 Dify 负责 AI 能力编排，业务系统负责核心数据和权限。