M7-02:开源项目深度解读 — Dify 与 LangChain
学习目标:理解当前主流 AI 开发框架的定位与架构,能够为不同产品场景选择合适的技术栈,与工程师进行有效的技术对话。
一、AI 开发生态全景
在正式介绍 Dify 和 LangChain 之前,先建立一张"地图",了解整个 AI 应用开发生态的层次结构。
┌─────────────────────────────────────────────────────────┐
│ 终端用户 / 业务系统 │
├─────────────────────────────────────────────────────────┤
│ AI 应用层(Dify / 自研应用 / SaaS) │
├──────────────────────┬──────────────────────────────────┤
│ 编排框架层 │ 工具与集成层 │
│ LangChain / LangGraph│ 向量数据库 / 搜索引擎 / 外部 API │
├──────────────────────┴──────────────────────────────────┤
│ 大模型 API 层 │
│ OpenAI / Claude / Gemini / 国内模型(通义/文心/混元) │
├─────────────────────────────────────────────────────────┤
│ 基础模型层(训练/托管) │
└─────────────────────────────────────────────────────────┘
产品经理的核心关注点在「AI 应用层」和「编排框架层」——这两层决定了产品的研发速度、扩展能力和维护成本。
二、Dify 深度解读
2.1 Dify 是什么?
Dify 是一个开源的 LLM 应用开发平台,定位是"让非技术人员也能搭建 AI 应用"。它于 2023 年上线,在 GitHub 上迅速积累数万 Star,已成为国内外最流行的 AI 应用平台之一。
核心价值主张:
- 可视化界面 + 低代码,降低 AI 应用的搭建门槛
- 内置 RAG pipeline、Agent builder、模型管理
- 支持私有化部署,数据不出内网
2.2 Dify 架构解析
Dify 平台架构
├── Studio(可视化编排界面)
│ ├── 聊天助手(Chatbot)
│ ├── 文本生成(Completion)
│ ├── 工作流(Workflow)
│ └── Agent
├── 知识库(Knowledge)
│ ├── 文档解析与切片
│ ├── 向量化(Embedding)
│ └── 检索召回
├── 模型管理
│ ├── 支持 100+ 模型接入
│ └── 统一的 Model Provider 接口
├── 插件/工具
│ ├── 内置工具(搜索/代码执行/图像)
│ └── 自定义 API 工具
└── 运维监控
├── 日志与标注
└── A/B 测试
2.3 视觉化工作流(Workflow)
Dify 的 Workflow 是其最强大的功能之一。通过拖拽节点,可以构建复杂的多步骤 AI 流程,无需写代码。
常见节点类型:
| 节点类型 | 用途 | 典型场景 |
|---|---|---|
| LLM | 调用大模型生成文本 | 总结、分类、改写 |
| 知识检索 | 从向量库召回相关内容 | RAG 增强 |
| 代码执行 | 运行 Python/JS 代码 | 数据处理、格式转换 |
| HTTP 请求 | 调用外部 API | 查询天气、数据库 |
| 条件判断 | 分支逻辑 | 根据意图路由 |
| 迭代 | 批量处理 | 处理文档列表 |
| 变量聚合 | 合并多路输出 | 并行任务合并 |
实际案例:某法律公司用 Dify Workflow 构建了一个合同审查流程:
- 用户上传合同 PDF → 解析节点提取文本
- 并行执行:条款识别 + 风险扫描
- LLM 节点生成审查报告
- HTTP 节点推送到内部 OA 系统
2.4 RAG Pipeline
RAG(Retrieval-Augmented Generation,检索增强生成)是 Dify 的核心场景之一。
用户提问
↓
查询改写(Query Rewrite)
↓
向量检索 + 关键词检索
↓
重排序(Rerank)
↓
上下文注入 Prompt
↓
LLM 生成答案
↓
引用来源展示
Dify 知识库的关键配置项(产品经理需要理解):
- 切片策略:按段落/按句子/自定义 — 影响检索精度
- Embedding 模型:text-embedding-ada-002 / BGE / 本地模型
- 检索模式:向量检索 / 全文检索 / 混合检索
- Top-K:召回几条 — 越多上下文越丰富,但 token 消耗越多
2.5 Agent Builder
Dify 的 Agent 支持两种模式:
| 模式 | 原理 | 适用场景 |
|---|---|---|
| Function Calling | 模型决策调用哪个工具 | 工具数量少,任务明确 |
| ReAct | 思考-行动-观察循环 | 复杂推理,多步决策 |
内置工具示例:网页搜索(Google/Bing)、代码解释器、DALL·E 图像生成、Wolfram 数学计算。
2.6 Dify 适用场景
推荐使用 Dify 的情况:
- 企业内部知识库问答(客服、HR、法务)
- 快速验证 AI 产品原型,1-2 天出 Demo
- 非技术团队需要自己维护 AI 流程
- 需要私有化部署,数据安全要求高
- 预算有限,不想写大量工程代码
不推荐使用 Dify 的情况:
- 需要高度定制化的业务逻辑,节点覆盖不了
- 对性能和延迟极度敏感的场景
- 已有成熟 Python 后端,集成成本高
三、LangChain / LangGraph 深度解读
3.1 LangChain 是什么?
LangChain 是一个面向开发者的 LLM 应用开发框架,用 Python 和 JavaScript 编写。它提供标准化的组件和抽象,让开发者用代码构建复杂的 AI 应用。
发展脉络:
- 2022 年底发布,迅速成为 LLM 开发的"标准库"
- 2024 年推出 LangGraph,解决复杂 Agent 编排问题
- LangSmith 提供可观测性(tracing、evaluation)
3.2 LangChain 核心概念
Chains(链)
将多个组件串联成一个处理流程:
# 示例:简单的 RAG Chain
from langchain_core.runnables import RunnableParallel, RunnablePassthrough
chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| llm
| output_parser
)
response = chain.invoke("公司的假期政策是什么?")
Agents(智能体)
让 LLM 自主决策调用哪些工具:
from langchain.agents import create_openai_tools_agent, AgentExecutor
tools = [search_tool, calculator_tool, database_tool]
agent = create_openai_tools_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools)
result = agent_executor.invoke({"input": "帮我查一下今天上海的天气,并计算穿衣指数"})
Memory(记忆)
管理对话历史,让模型"记住"上下文:
| 记忆类型 | 特点 | 适用场景 |
|---|---|---|
| ConversationBufferMemory | 存全部历史 | 短对话 |
| ConversationSummaryMemory | 自动总结压缩 | 长对话 |
| VectorStoreRetrieverMemory | 向量检索相关历史 | 复杂多轮 |
Tools(工具)
LangChain 拥有庞大的工具生态:
数据源:Wikipedia / ArXiv / PubMed / SQL数据库 / CSV文件
搜索:Google / Bing / DuckDuckGo / Tavily
代码:Python REPL / Bash
API:Gmail / Slack / GitHub / Notion
3.3 LangGraph:复杂 Agent 的解决方案
LangGraph 将 Agent 工作流建模为有向图,解决了 LangChain 在复杂流程中的局限:
┌─────────┐
│ START │
└────┬────┘
↓
┌─────────┐
┌──→│ Agent │←──┐
│ └────┬────┘ │
│ ↓ │
│ [需要工具?] │
│ ↓ ↓ │
│ [是] [否] │
│ ↓ │
│ ┌──────┐ │
└─│ Tool │ │
└──────┘ │
↓ │
[完成?] │
↓ ↓ │
[是] [否]──┘
↓
END
LangGraph 的优势:
- 支持循环(Cycle),Agent 可以反复尝试
- 状态持久化,支持人机协作(Human-in-the-Loop)
- 更细粒度的流程控制
3.4 LangChain 适用场景
推荐使用的情况:
- 工程师主导开发,需要高度定制化
- 复杂的多步骤 Agent 流程
- 需要与现有 Python 系统深度集成
- 需要精确控制每一个环节的逻辑
- 团队已有 Python 开发能力
不推荐使用的情况:
- 业务团队需要自己维护,没有工程师
- 追求快速验证,两天出 Demo
- 简单的 RAG 问答,用 Dify 5 分钟搞定的事情
四、三种方案对比:Dify vs LangChain vs 直接调 API
| 维度 | 直接调 API | LangChain | Dify |
|---|---|---|---|
| 开发速度 | 慢(写全套代码) | 中(框架加速) | 快(可视化拖拽) |
| 定制化程度 | 最高 | 高 | 中(受节点限制) |
| 技术门槛 | 高 | 中 | 低 |
| 维护成本 | 高 | 中 | 低 |
| 适合阶段 | 成熟产品 | 产品成长期 | 原型/早期 |
| 团队要求 | 工程师团队 | 工程师团队 | 产品/运营可参与 |
| 可观测性 | 需自建 | LangSmith | 内置日志 |
| 私有化部署 | 自然支持 | 自然支持 | Docker 一键部署 |
五、产品场景选型指南
场景一:企业内部知识库
推荐方案:Dify
理由:业务团队可自助管理知识库内容,上传文档即用,维护成本低。Dify 的 RAG pipeline 对大多数文档问答场景已经足够。
场景二:复杂客服 Agent
推荐方案:LangGraph
理由:需要查订单、查库存、处理退款等多个工具调用,需要复杂的条件判断和状态管理,LangGraph 的图模型更适合。
场景三:AI 功能原型验证(2 周内上线)
推荐方案:Dify
理由:快速搭建可交互 Demo,验证用户价值,获得反馈后再决定是否用 LangChain 重写。
场景四:AI 写作助手(深度定制)
推荐方案:LangChain + 直接 API
理由:写作场景对 Prompt 工程、输出格式、流式输出都有高要求,需要精细控制每一个环节。
场景五:多模态处理流水线(图文混合)
推荐方案:Dify Workflow 或 LangChain
理由:Dify Workflow 支持图片节点和多模态模型,适合快速搭建;LangChain 适合需要复杂逻辑的场景。
六、快速上手指南
Dify 5 分钟体验
# Docker 本地部署
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
# 访问 http://localhost
# 注册账号 → 新建应用 → 选择「聊天助手」→ 配置模型 → 测试
产品经理建议:不需要自己部署,直接访问 cloud.dify.ai 注册免费账号,跑通一个知识库问答 Demo。
LangChain 10 分钟体验
# 安装
pip install langchain langchain-openai
# 最简单的 RAG Demo
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
# 1. 准备文档
texts = ["公司年假政策:入职1年10天,3年15天", "报销需在30天内提交发票"]
# 2. 构建向量库
vectorstore = FAISS.from_texts(texts, OpenAIEmbeddings())
retriever = vectorstore.as_retriever()
# 3. 构建 Chain
prompt = ChatPromptTemplate.from_template(
"根据以下内容回答问题:\n{context}\n\n问题:{question}"
)
chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| ChatOpenAI()
)
# 4. 提问
print(chain.invoke("我入职2年有几天年假?"))
七、产品经理的核心收获
作为 AI 产品经理,掌握这两个框架的关键不在于会写代码,而在于:
- 需求拆解:能把产品需求拆解成"知识库 + LLM + 工具调用"的组合,判断哪些用框架、哪些需要自研
- 技术评估:与工程师讨论方案时,能理解"为什么用 LangGraph 而不是 Dify Workflow"
- 风险识别:知道 Dify 节点的局限在哪里,LangChain 的维护成本在哪里
- 原型能力:能自己用 Dify 搭出 MVP,加速产品验证周期
一句话原则:优先用 Dify 验证,用 LangChain 打磨,用直接 API 极致优化。