Dify on CAO ZUOHUA

Dify 深度玩法（五）：Agent、MCP 与一个完整实战

Sat, 26 Sep 2026 20:40:00 +0800

Dify 深度玩法（五）：Agent、MCP 与一个完整实战

上一篇：RAG 深度玩法。本篇是收官：先讲清 Agent 与 Workflow 的分工原则，再讲 MCP 的实际价值，最后把整个系列串成一个跑得通的真实项目——博客勘误官。

Agent 与 Workflow：谁管什么

新版 Dify 的 Agent 带来了 Linux 沙箱与技能（Skills）体系：Agent 可以在隔离环境里执行命令、管理文件、按需安装依赖。能力变强之后，最重要的设计原则反而是克制：

Agent 管判断：任务路径开放的环节——自己决定查什么、跑哪个脚本、怎么补证据；
Workflow 管编排：触发、顺序、分支、审批门、重试、归档——所有需要确定性的环节。

flowchart TD T["定时 / 表单触发"] --> W["Workflow 编排层 触发·顺序·审批门·重试·归档"] W --> A{"需要开放判断？"} A -- "否：路径确定" --> N["普通节点链 LLM·Code·HTTP·知识检索"] A -- "是：现场决定做什么" --> AG["Agent 节点 沙箱内自主执行"] N --> O["出口：API / Web App / MCP / 推送"] AG --> O

反例是"一个 Agent 干全部"：触发它自己定、写操作它自己批、失败它自己咽——这类流程出问题时你连现场都还原不了。自主性是成本，不是默认值。

Dify 深度玩法（四）：RAG 做到什么程度才算到位

Sat, 26 Sep 2026 20:30:00 +0800

Dify 深度玩法（四）：RAG 做到什么程度才算到位

上一篇：节点自定义的五个层级。自托管 Dify 的 RAG 不是"上传文档然后问答"，而是一条每一段都能调参的流水线，且没有云版的容量阉割。

全链路：入库与查询

flowchart LR subgraph IN ["入库侧（一次性）"] A["多源接入 文档·网页·Notion·API"] --> B["分块 通用·父子·问答对"] B --> C["双路索引 向量 + 关键词"] end subgraph Q ["查询侧（每次请求）"] D["查询预处理 改写·分类路由"] --> E["混合检索 向量+全文+元数据过滤"] E --> F["重排 rerank 精排"] F --> G["带引用生成 可拒答·可溯源"] end C -.->|"查询时检索"| E

平台能力是现成的。效果差异来自三个你自己做的决定：分块策略、检索模式、元数据设计。

效果的四层阶梯

层次	做出来的效果	依赖能力
1. 基础问答	回答带引用来源，知识库里没有就明确说不知道	混合检索 + 重排 + 阈值
2. 精准知识库	长文档问答不丢上下文；检索自动限定在某类文档	父子分段 + 元数据过滤
3. 可编程检索流水线	查询改写、分类路由、多库检索、生成前校验全部画进画布	RAG 流水线 / Chatflow
4. 外挂检索引擎	Dify 只当编排层，检索打到你自己写的 API（ES、数据库、自建向量服务）	外部知识库 API

第 2、4 层是自托管的意义所在：云版免费额度装不下，而外部知识库接口意味着可以整体绕开内置向量库。

Dify 深度玩法（三）：节点自定义的五个层级

Sat, 26 Sep 2026 20:20:00 +0800

Dify 深度玩法（三）：节点自定义的五个层级

上一篇：部署选型与模型 Key。进了画布，第一个问题是"这东西到底能改多深"。答案是分层看：参数、逻辑、数据流三层几乎不设限；节点类型可靠插件扩展；硬边界只有两处。

五个层级总览

flowchart TD L1["L1 参数级 每个节点的配置项"] --> L2["L2 逻辑级 Code 与 HTTP 逃生门"] L2 --> L3["L3 数据流级 变量系统 + 容错策略"] L3 --> L4["L4 节点类型级 插件定义新节点"] L4 --> L5["L5 协议级 DSL 手改 + 外部知识库 API"] L1 -.- N1["自由度：低，但覆盖日常"] L2 -.- N2["自由度：高，万能逃生门"] L4 -.- N4["自由度：最高，成本也最高"]

L1 参数级：每个节点都有一层配置

LLM 节点：每个节点独立选模型、独立调参数（温度、最大输出等），提示词模板可引用任意上游变量，支持结构化输出、视觉输入、会话记忆。
知识检索节点：可挂多个知识库，检索模式、返回条数、相似度阈值、重排模型逐项可配。
问题分类器 / 参数提取器：分类类别和抽取字段完全由你定义，抽取方式可选函数调用或提示词驱动。

这一层覆盖了八成日常需求，特点是"改配置不改逻辑"。

L2 逻辑级：两个万能逃生门

Code 节点（Python 3.10+ 或 Node.js 18+）负责任意数据变换。一个真实可用的例子——对抓取结果做归一化去重：

Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单

Sat, 26 Sep 2026 20:10:00 +0800

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 的组合，云版免费版装不下。应用数和知识库容量这两个上限，恰好卡在个人开发者的典型需求上。

三阶段部署路径

不建议二选一，建议分三步走：

flowchart TD A["第 1 步：云版免费账号 用 0 到 2 天"] --> B["第 2 步：本机 Docker 自托管 正式开发"] B --> C["第 3 步：迁移到 VPS 需要对外服务时"] A -.- A1["目的：熟悉节点与画布 不绑自己的 Key，不建知识库"] B -.- B1["目的：无配额限制 直连本机 llama.cpp 或 Ollama"] C -.- C1["目的：Web App 与 API 常在线 本地模型改走云端 API"]

第 1 步不要投入任何东西——云版只用来确认"画布的工作方式你是否接受"。第 2 步才是正式开发环境。第 3 步等真的要给别人用时再做，因为自托管应用可以导出 DSL 迁移，前期投入不会浪费。

Dify 深度玩法（一）：它适合做什么，不适合做什么

Sat, 26 Sep 2026 20:00:00 +0800

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 通常更慢。下面这张决策图可以直接对着用：

flowchart TD A["接到一个 LLM 项目需求"] --> B{"逻辑主体是 IO + 数据整形 + LLM 判断？"} B -- "不是：重计算/事务/低延迟" --> C["直接写代码 不要用 Dify"] B -- "是" --> D{"需要 3 天内拿到 可给别人用的界面或 API？"} D -- "不需要，纯后台数据管道" --> E["脚本也可以胜任 Dify 是可选项"] D -- "需要" --> F{"会频繁调提示词 和检索策略吗？"} F -- "不会" --> G["写代码 + 配置文件 更可控"] F -- "会" --> H["用 Dify 原型到生产都在画布上迭代"]

场景对照表

场景	用 Dify	原因
多源抓取 → 清洗 → LLM 打分 → 输出日报	✅	典型的 IO + LLM 链路，改数据源不动代码
文档知识库问答（RAG）	✅	分块、检索、重排、引用都是现成节点
一次性深度调研报告生成	✅	多 Agent 分工 + 引用校验节点
需要快速给客户演示的垂直领域助手	✅	Web App 与 API 一键发布
高频低延迟 API（P95 要求数百毫秒内）	❌	每个节点都有额外开销与队列
视频渲染、大规模数值计算	❌	沙箱 30 秒超时 + 内存上限，干不了重活
复杂有状态业务流程（事务、回滚、幂等）	❌	声明式分支表达不了状态机
逻辑需要严格 code review 与版本控制	⚠️	工作流导出为 YAML，diff 可读性差

关于"拖拉拽"的真实配比

一个常见误解是"用 Dify = 纯拖拽"。实际项目里有效的配比是约八成拖拽、两成 Code 节点：

标书控标排雷：构建售前经理的 AI Agent 工具库

Thu, 27 Aug 2026 00:00:00 +0000

标书排雷：售前经理的“减负”计划

在售前工作中，标书分析往往是耗时最长且最容易遗漏细节的环节。动辄几百页的招标文件，包含着大量的技术指标、合规要求与潜在的“排雷”点。

为了提升售前效率，我计划构建一套基于 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。