Dify 深度玩法（五）：Agent、MCP 与一个完整实战
Dify 深度玩法（五）：Agent、MCP 与一个完整实战
上一篇：RAG 深度玩法。 本篇是收官：先讲清 Agent 与 Workflow 的分工原则，再讲 MCP 的实际价值，最后把整个系列串成一个跑得通的真实项目——博客勘误官。
Agent 与 Workflow：谁管什么
新版 Dify 的 Agent 带来了 Linux 沙箱与技能（Skills）体系：Agent 可以在隔离环境里执行命令、管理文件、按需安装依赖。能力变强之后，最重要的设计原则反而是克制：
- Agent 管判断：任务路径开放的环节——自己决定查什么、跑哪个脚本、怎么补证据；
- Workflow 管编排：触发、顺序、分支、审批门、重试、归档——所有需要确定性的环节。
反例是"一个 Agent 干全部"：触发它自己定、写操作它自己批、失败它自己咽——这类流程出问题时你连现场都还原不了。自主性是成本，不是默认值。
Dify 深度玩法（四）：RAG 做到什么程度才算到位
Dify 深度玩法（四）：RAG 做到什么程度才算到位
上一篇：节点自定义的五个层级。 自托管 Dify 的 RAG 不是"上传文档然后问答"，而是一条每一段都能调参的流水线，且没有云版的容量阉割。
全链路：入库与查询
平台能力是现成的。效果差异来自三个你自己做的决定：分块策略、检索模式、元数据设计。
效果的四层阶梯
| 层次 | 做出来的效果 | 依赖能力 |
|---|---|---|
| 1. 基础问答 | 回答带引用来源，知识库里没有就明确说不知道 | 混合检索 + 重排 + 阈值 |
| 2. 精准知识库 | 长文档问答不丢上下文；检索自动限定在某类文档 | 父子分段 + 元数据过滤 |
| 3. 可编程检索流水线 | 查询改写、分类路由、多库检索、生成前校验全部画进画布 | RAG 流水线 / Chatflow |
| 4. 外挂检索引擎 | Dify 只当编排层，检索打到你自己写的 API（ES、数据库、自建向量服务） | 外部知识库 API |
第 2、4 层是自托管的意义所在：云版免费额度装不下，而外部知识库接口意味着可以整体绕开内置向量库。
Dify 深度玩法（三）：节点自定义的五个层级
Dify 深度玩法（三）：节点自定义的五个层级
上一篇：部署选型与模型 Key。 进了画布，第一个问题是"这东西到底能改多深"。答案是分层看：参数、逻辑、数据流三层几乎不设限；节点类型可靠插件扩展；硬边界只有两处。
五个层级总览
L1 参数级：每个节点都有一层配置
- LLM 节点：每个节点独立选模型、独立调参数（温度、最大输出等），提示词模板可引用任意上游变量，支持结构化输出、视觉输入、会话记忆。
- 知识检索节点：可挂多个知识库，检索模式、返回条数、相似度阈值、重排模型逐项可配。
- 问题分类器 / 参数提取器：分类类别和抽取字段完全由你定义，抽取方式可选函数调用或提示词驱动。
这一层覆盖了八成日常需求，特点是"改配置不改逻辑"。
L2 逻辑级：两个万能逃生门
Code 节点（Python 3.10+ 或 Node.js 18+）负责任意数据变换。一个真实可用的例子——对抓取结果做归一化去重：
Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单
Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单
上一篇：Dify 适合做什么。 本篇回答第二个实际决策：在哪跑、接什么模型。
先澄清一个常见误解
很多人以为云版免费额度限制的是"调用量"。真实情况是：自带 API Key 的调用不消耗 Dify 的 message credits（credits 只在使用 Dify 内置供应商时消耗）。云版免费版（Sandbox）真正的瓶颈是：
| 维度 | 云版 Sandbox（免费） | 自托管 Community |
|---|---|---|
| 应用数 | 5 个 | 不限 |
| 知识库 | 50 篇文档 / 50 MB | 取决于你的磁盘 |
| 本地模型（llama.cpp / Ollama） | 访问不到你的 localhost | 容器内直连 |
| 费用 | 0（够用要升级到约 59 美元/月） | 0（电费与磁盘） |
| 维护 | 无 | 升级需读 release note、改环境配置后重启 |
结论很直接：多项目 + RAG 的组合，云版免费版装不下。应用数和知识库容量这两个上限，恰好卡在个人开发者的典型需求上。
三阶段部署路径
不建议二选一，建议分三步走：
第 1 步不要投入任何东西——云版只用来确认"画布的工作方式你是否接受"。第 2 步才是正式开发环境。第 3 步等真的要给别人用时再做，因为自托管应用可以导出 DSL 迁移，前期投入不会浪费。
Dify 深度玩法（一）：它适合做什么，不适合做什么
Dify 深度玩法（一）：它适合做什么，不适合做什么
本系列共五篇，基于 2026 年的 Dify（含新版 Agent 与 MCP 能力）整理自实际调研与项目设计。 这一篇先回答最容易被跳过的问题：什么项目该用 Dify，什么项目用了反而更慢。
一句话定位
Dify 是一个 LLMOps 平台：把「可视化编排 + 知识库 RAG + Agent + 一键发布（Web App / API / 嵌入组件）」装进同一个画布。它与 LangChain 这类代码框架的本质区别是——Dify 是产品，LangChain 是框架。框架给你最大自由，产品给你最快速度，代价是边界由平台划定。
三条判断标准
一个项目"适合 Dify"，通常同时满足三条：
- 逻辑主体是 IO + 数据整形 + LLM 判断。抓数据、清洗、让模型打分或判定、输出文本——这条链路是 Dify 节点的母语。
- 需要快速拿到可调用的出口。你需要在几小时内拥有一个能点开的 Web App、一个 REST API、一个可嵌入的聊天组件，而不是先写两周前后端。
- 改提示词的频率远高于改代码的频率。Dify 上改一个 LLM 节点的 prompt 是秒级的，不需要重新发版。如果你的项目半年才改一次提示词，这个优势归零。
反过来，满足不了这三条的，用 Dify 通常更慢。下面这张决策图可以直接对着用：
场景对照表
| 场景 | 用 Dify | 原因 |
|---|---|---|
| 多源抓取 → 清洗 → LLM 打分 → 输出日报 | ✅ | 典型的 IO + LLM 链路，改数据源不动代码 |
| 文档知识库问答（RAG） | ✅ | 分块、检索、重排、引用都是现成节点 |
| 一次性深度调研报告生成 | ✅ | 多 Agent 分工 + 引用校验节点 |
| 需要快速给客户演示的垂直领域助手 | ✅ | Web App 与 API 一键发布 |
| 高频低延迟 API（P95 要求数百毫秒内） | ❌ | 每个节点都有额外开销与队列 |
| 视频渲染、大规模数值计算 | ❌ | 沙箱 30 秒超时 + 内存上限，干不了重活 |
| 复杂有状态业务流程（事务、回滚、幂等） | ❌ | 声明式分支表达不了状态机 |
| 逻辑需要严格 code review 与版本控制 | ⚠️ | 工作流导出为 YAML，diff 可读性差 |
关于"拖拉拽"的真实配比
一个常见误解是"用 Dify = 纯拖拽"。实际项目里有效的配比是约八成拖拽、两成 Code 节点：
标书控标排雷：构建售前经理的 AI Agent 工具库
标书排雷：售前经理的“减负”计划
在售前工作中，标书分析往往是耗时最长且最容易遗漏细节的环节。动辄几百页的招标文件，包含着大量的技术指标、合规要求与潜在的“排雷”点。
为了提升售前效率，我计划构建一套基于 Dify 的售前经理 AI Skill 工具库。本文将分享该项目的设计理念与技术实现。
1. 为什么选择 Agent 工具库？
标书分析的痛点在于“非结构化数据”与“动态标准”。不同行业、不同项目、不同客户的排雷规则完全不同，普通的搜索引擎或通用 LLM 无法处理复杂的规则约束。
我们需要的是一套可定制的 Agent 体系：
- 竞品分析：自动提取招标文件中的关键需求，对比已有产品优势。
- 标书排雷：基于规则库，动态识别招标文件中的敏感排他条款。
- 配置报价：根据需求自动匹配推荐方案。
2. 技术架构设计
整个系统的核心在于**“数据前置处理 + Dify 智能编排”**。
第一阶段：标书脱水 (Data Dehydration)
全量投喂 PDF 给 LLM 是极低效的。我设计了一个基于 Python 的前置处理流程：
- 提取与降维：使用
pymupdf提取文本，移除页眉页脚及冗余法律模板。 - 结构化归一：将分散的表格和条款转化为语义清晰的 Markdown 结构。
- Token 节约：只保留关键技术要求与限制条款，剔除 50% 以上无关字符，显著降低 LLM 压力，提升 RAG 检索准确度。
第二阶段：基于 Dify 的动态排雷
Dify 提供了理想的 Workflow 与知识库分组能力：
- 动态标准配置：行业标准与规则以参数形式输入。
- 动态 Prompt：Agent 根据当前“行业 + 场景 + 客户风格”标签，动态加载对应的排雷标准库。
3. 未来的扩展：社交生态发布
商业计划的最后一步是公域传播。利用 Dify 的 API，我们将排雷后的合规知识点，自动摘要并脱敏，分发至小红书或抖音，构建售前经理的专业个人 IP。