1.3 工作台解剖：界面分区与系统架构

1.3 工作台解剖：界面分区与系统架构

一次提问的完整路径：浏览器把问题发到网关，网关转给 API 服务，API 服务按应用配置组装提示词、检索知识库、调用模型，再把流式回答推回浏览器，同时把会话写进数据库。理解这条路径，控制台上每个面板就都有了着落。

本章前两节解决了"为什么"和"选什么"，本节解决"在哪"：先逛一遍界面，再钻到底层架构。它同时是第 2 章部署的预告——你在本节看到的每个服务，下一章都会变成一个真实容器。

界面分区：每个面板都有戏份

登录后左侧导航有五个入口，各自的职责与全册的对应关系如下：

工作室是主战场。应用列表占据首页，右上角"创建空白应用"就是我们 1.2 节选型的入口。进入一个应用后，界面切成三块：左侧是编排面板（提示词、变量、上下文、工具、开场白等配置区），中间是调试预览（一个嵌在页面里的对话框，所有改动即时生效，可以边改边试），顶部是发布相关的动作。全册第 3、5、6 章的操作几乎都发生在这三块里。

知识库独立于应用存在。文档在这里上传、分段、索引，应用通过"上下文关联"引用它——一份知识库可以挂到多个应用。第 4 章整章都在这里度过。

工具页管理内置工具（搜索、绘图、时间查询等）与自定义工具（用 OpenAPI 规范描述你的内部接口）。工具是第 6 章 Agent 的"手脚"。

设置页三件事最重要：模型供应商接入（填 API 密钥的地方）、系统模型设置（默认推理模型、Embedding 模型、Rerank 模型）、成员与权限。第 2 章装好环境后第一件事就是来这填密钥。

顶部的工作区切换器容易被新手忽略：工作区是团队级的隔离单位，应用、知识库、成员都隶属于工作区。给"正式环境"和"试验田"建两个工作区，是成本低廉的环境隔离手段，第 7 章会用到。

一条提问的完整路径

现在把镜头切到幕后。用户在发布的网页里输入"七天无理由退货怎么办理"，这条消息要穿过五站：

**第一站，浏览器与网关。**网页（Dify 称 WebApp）本身是一个静态前端，消息通过 HTTPS 发给平台网关（默认由 Nginx 容器承担），网关按路径把请求转给 API 服务。

**第二站，API 服务。**平台的"前台接待"，负责鉴权（应用密钥对不对）、限流、参数校验，然后按应用配置开始编排：找到提示词模板，注入变量，准备调用检索。

**第三站，知识检索。**应用关联了知识库时，先把问题向量化，到向量库里检索相关分段（第 4 章的细节），命中的片段被拼进提示词的上下文占位符。

**第四站，模型供应商。**API 服务带着组装好的完整提示词，调用外部模型接口。这一步走外网，是延迟与费用的大头，也是第 2 章要接通的关键一环。

**第五站，回程。**模型的流式输出被逐段推回浏览器（打字机效果的来源），结束后 API 服务把完整会话、命中的知识片段、token 消耗写入数据库，供日志面板回放。

图 1-2：一次提问在系统内的流转路径

架构速记与两个延伸

五站流水线对应六个核心部件：网关、API 服务、数据库、缓存队列、向量库、模型供应商出口。前五个在自部署时都是本地容器（第 2 章的 docker ps 会逐一亮相），最后一个是外部服务。另有两个不起眼但关键的配角：代码沙箱（工作流里执行代码节点的隔离环境，安全边界）与插件守护进程（1.x 版本后承载插件运行的进程）。记住一句速记：前台问网关，编排找 API，状态进库，向量另存，模型在外。

顺带回应两个常见疑问。其一，"我的数据会不会出境？"——自部署版里，知识库与会话都存在你自己的数据库和向量库容器里；唯一出境的流量是调用外部模型时的提示词（用本地模型可以完全内网闭环，第 2 章接 Ollama）。其二，"并发上不去先查谁？"——按链路顺序排查：网关端口与连接数、API 服务副本数、缓存队列堆积、模型供应商限流。这个顺序不是经验玄学，就是五站流水线的先后。

一次慢响应的推演练习

架构图不是挂墙装饰，用它推演一个真实问题：用户反馈"小艺回答要等十几秒"。假设你还没学任何排障工具，只凭五站流水线做纸面推演——

症状：流式回答第一个字出现得慢，之后打字速度正常。
推理：第一个字出现意味着模型已开始输出，之后正常说明回程链路（网关→浏览器）没问题。
那么延迟必然出在"发出请求到模型开口"之间，按站排查：
第一站 网关：转发是毫秒级，除非全站都慢，基本可排除；
第二站 API 服务：组装提示词是本地操作，除非知识库挂了上千分段，也可缓疑；
第三站 知识检索：检索本身快，但"嵌入计算"要调嵌入模型接口——若嵌入模型走外网且慢，
        这里就是嫌疑点；
第四站 模型供应商：推理模型排队的可能性最大，尤其高峰期。
结论优先级：先看模型供应商的响应耗时（第四站），再看嵌入接口耗时（第三站）。
​

这个练习想传达的不是"答案"，而是链路思维：慢，是哪一段慢？错，是哪一站错？第 2 章的日志工具会把这种纸面推演变成五分钟的真实排查，但推理框架此刻已经建立。顺便说，上面那个案例的真实结局是嵌入接口走了境外供应商，高峰期排队——换国内嵌入模型后首字延迟从十二秒降到两秒。

问题：控制台界面和发布的 WebApp 是同一个东西吗？

不是。控制台是搭建者的工作界面（登录后那个），WebApp 是终端用户看到的对话页面（发布后生成），两者共用同一套后端。这解释了一个新手困惑：为什么改了编排面板，控制台的调试立即变化，而 WebApp 要点"更新发布"才变——发布是一个带版本语义的动作，第 3 章会专门讲。

问题：为什么向量库要单独一个存储，不和数据库放一起？

因为两者的访问模式完全不同。业务数据库回答"这条会话的完整记录是什么"（精确查找），向量库回答"哪些分段和这句话意思最接近"（近似最近邻计算，靠专门的索引结构）。硬塞进同一个存储，两边都跑不快——这也是为什么 1.3 的图里它们是两个独立容器，而第 2 章部署时会看到它们各自的卷。

本节要点回顾

• 界面五区：工作室、知识库、工具、设置、（工作区切换），分别对应第 3/4/6/2 章的操作现场；
• 五站路径：网关→API 服务→知识检索→模型供应商→回程入库，是理解一切性能与排障问题的地图；
• 架构速记：前台问网关，编排找 API，状态进库，向量另存，模型在外；
• 数据边界：自部署下数据留在本机，仅调用外部模型时提示词出网，可换本地模型闭环；
• 排障顺序：照链路顺序查，而不是拍脑袋重启。

带着这张架构图进入第 2 章：把图上每个部件变成你机器上跑着的容器。