CangLu Knowledge Base

总览

6分钟阅读

总览

主题索引 | learn 索引

图清单

1. 直接使用 Dify 的核心地图

flowchart TD
    U[使用者]
    W[Web 控制台]
    A[应用配置]
    M[模型供应商]
    D[知识库]
    F[工作流]
    T[插件与工具]
    R[运行结果]
    X[外部模型服务]

    U --> W
    W --> A
    W --> M
    W --> D
    W --> F
    W --> T
    A --> R
    M --> X
    D --> R
    F --> R
    T --> R

一句话理解

  • Web 控制台：你平时操作的入口。
  • 应用配置：决定你的机器人或工作流最终长什么样。
  • 模型供应商：决定它到底调用哪个大模型。
  • 知识库：决定它能否带着你的私有资料回答。
  • 工作流：决定复杂逻辑是否可编排。
  • 插件与工具：决定它能否调用外部能力。
  • 运行结果：最终你看到的回答、调用结果和日志反馈。

2. 帕累托式学习顺序

如果你是直接使用者，不要平均用力。更有效的顺序是：

  1. 先会接模型供应商
  2. 再会建应用
  3. 再会导知识库
  4. 再会调工作流
  5. 最后再看插件和高级能力

原因很简单：

  • 没模型，应用无法真正跑起来。
  • 没应用，知识库和工作流的价值感不强。
  • 没知识库，你做不出真正贴业务的问答。
  • 没工作流，你很难把多步骤逻辑稳定下来。
  • 插件和高级特性价值很高，但不是第一天必须掌握。

3. 80% 场景真正要掌握的知识

3.1 四个页面先搞懂

  1. 模型供应商
    • 用来配置 OpenAI、DeepSeek、SiliconFlow、MiniMax 等上游模型。
    • 这是最容易报错、也最值得优先掌握的页面。
  2. 应用
    • 用来创建聊天应用、Agent、工作流应用。
    • 这是日常交付结果的主入口。
  3. 知识库
    • 用来上传文档、切分、索引、检索。
    • 这是让 Dify 贴近业务资料的关键。
  4. 工作流
    • 用来把 Prompt、知识检索、条件分支、工具调用串起来。
    • 这是从“能聊”走向“能做事”的关键。

3.2 三个最重要的使用边界

模型供应商

  • 解决“我调用哪个模型”的问题。
  • 常见输入：API Key、API Base、验证模型、协议。

插件与工具

  • 解决“模型之外还能调用什么能力”的问题。
  • 例如联网、外部 API、文件处理、第三方能力。

API 扩展

  • 解决“把你自己的接口能力接进来”的问题。
  • 它不是模型供应商，也不是插件市场的同义词。

3.3 一条最短可用路径

  • 先在模型供应商里配置一个可用模型。
  • 创建一个最简单的聊天应用。
  • 直接测试一轮对话。
  • 再补知识库。
  • 最后再补工作流和工具。

如果你一开始就去搭复杂工作流，通常会把错误来源搅在一起。

4. 不必一开始就深挖的内容

这些内容很重要，但不是直接使用者的前 20%：

  • Docker 编排细节
  • 容器健康检查
  • nginx 反向代理
  • plugin-daemon 内部实现
  • sandbox 与 SSRF 代理
  • marketplace 的环境变量拼接逻辑
  • 源码级模型协议适配

直接使用阶段，你只需要知道：

  • 它们存在
  • 它们出了问题会影响页面和模型调用
  • 但你不用一开始就全学会

5. 一份真正实用的判断原则

先问自己五个问题

  1. 我现在卡在页面访问还是业务配置？
  2. 我现在是在配模型、知识库、工作流还是外部 API？
  3. 这个错误是立即失败还是超时后失败？
  4. 错误来自 Dify 本地，还是来自 上游模型服务？
  5. 我是不是把不同层的问题混为一谈了？

这五个问题的价值

它能快速把问题从“感觉 Dify 很复杂”拆成一个具体层次。多数问题并不复杂，只是没有先分层。

关系图谱