Dify 1.11.1 在 MacOS-12(Intel) 上用 Docker 部署最容易卡住的不是容器起不来而是 7.1 节的模型供应商那一页TaoToken 走 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key再把 Base URL 换成兼容通道Workflow 是能正常跑的。原文在 7.1 节让读者去 DeepSeek 开放平台申请 apikey回到 Dify 装插件、填配置只要 Key 或者地址差一个字符后面拖出来的 LLM 节点就一口一个调用失败。这件事的难点从来不在 Dify 本身而在于把「浏览器里打开的官网」和「填进 Dify 输入框的接口地址」分成两件事。很多人第一次配的时候把带参数的落地页地址粘进了 Base URL保存的时候看着没报错跑 Workflow 才炸。下面按原文的推进节奏走先在 MacOS-12(Intel) 上把 1.11.1 的 Docker 环境确认好再到模型供应商页把 DeepSeek 插件那一栏的鉴权换成兼容通道最后用一个三节点小工作流验证。1. 7.1 节填 DeepSeek apikey 的位置换成 TaoToken 到底行不行1.1 原文那一步在解决什么问题原文走到 7.1 节的时候Dify 本体已经起来了管理员账号也初始化完了界面上能看到「设置」和「模型供应商」两个入口。这一节做的事情其实是三件去模型供应商市场装一个能识别 DeepSeek 协议的插件拿到一把能调用模型的密钥把密钥和接口地址填进插件配置里。第三步是分水岭前两步只是准备工作真正决定 Workflow 能不能跑到模型的是第三步那两个输入框。原路径选择直连 DeepSeek 开放平台走的是官方域名加官方 Key。这条路的约束在于密钥来源单一模型列表跟着平台走一旦额度或账号状态出问题Dify 里所有引用这个供应商的节点都会跟着挂。而 Dify 的模型供应商页本身是支持自定义 Base URL 的也就是说只要有一路 OpenAI 兼容风格的通道就能把请求指向别处。1.2 判断标准很简单一个 LLM 节点能不能返回文本判断「改走兼容通道行不行」不需要看架构图看结果就够在 Dify 里拖一个 LLM 节点挂上刚配好的模型点运行看它能不能返回一段正常文本。能返回说明鉴权和地址都对返回 401说密钥没被认出来返回 404基本是地址拼错了。兼容通道的好处是把「用哪个模型」和「用哪家的账号」解耦开。今天工作流里用 A 模型明天想换 B 模型只要在模型供应商里再加一条配置Workflow 里的节点不用重画。代价是你要多记两条规则Base URL 填接口地址不带官网那一串参数模型 ID 一律以模型广场当时列表为准别凭印象写。2. MacOS-12(Intel) 上先把 Dify 1.11.1 的 Docker 环境确认好2.1 容器起来之后先确认页面能打开Intel 版 Mac 跑 Docker Desktop 没有那么娇气但 1.11.1 这一版的服务数量比早期版本多第一次启动会拉不少镜像。常规做法还是进 docker 目录复制一份 .env然后拉起来git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d docker compose psdocker compose ps里如果还有容器在 restarting 或者 exited先别急着进模型供应商页浏览器打开http://localhost/install连初始化账号都进不去后面填什么都没意义。Intel 机器上比较常见的情况是内存给得不够Docker Desktop 默认 2G 的话plugin daemon 这类容器容易反复重启调到 4G 以上会稳一些。第一次打开http://localhost/install会要求设置管理员邮箱和密码完成后跳进应用列表页。到这里为止原文和本篇的操作是完全一样的分歧从点开右上角「设置」开始。2.2 进模型供应商页之前先把两样东西准备好第一样是接口地址https://taotoken.net/api。注意末尾不带/v1也不要带任何?后面的参数这个地址是填进 Dify 输入框的不是给人点开的。第二样是一把 API Key占位符可以记作YOUR_API_KEY真实值从 TaoToken 的模型广场页面获取。顺手把第三样也确认了你打算在工作流里用哪个模型 ID。这个值不能猜常见错误是照着别处的教程写了个带日期后缀的名字结果请求发出去被拒。正确做法是打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 看一眼当前模型列表把准确的那串字符复制下来先记在便签上。3. DeepSeek 插件装完之后Base URL 和 Key 分别填什么3.1 先在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key原文这一步是「设置下深度求索的 apikey」动作发生在 DeepSeek 开放平台。改写后的动作同样是一步只是换了个地方打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end登录之后进控制台创建一个 API Key复制出来。Key 通常只在创建时完整显示一次复制完先粘到本地的临时文本里别中途切窗口丢掉了。这里有个容易忽略的细节创建 Key 的页面是给人看的浏览器地址栏里带utm_source之类的参数很正常但待会儿要填进 Dify 的那一栏是接口地址绝对不能把浏览器里那串带参数的地址复制过去。两串地址长得像用途完全不同这一点在本篇里会反复出现。3.2 插件里的 Base URL 字段填什么、不填什么回到 Dify路径是「设置 → 模型供应商 → 探索模型供应商」搜 DeepSeek 装上。装完点进该供应商的「添加模型」会看到若干输入框。按下面这张表对照填不要凭记忆Dify 里的字段应该填的值说明API Base URL / Base URLhttps://taotoken.net/api末尾不要加/v1不要带任何查询参数API KeyYOUR_API_KEY从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建模型名称 / Model Name以模型广场当时列表为准从模型广场复制准确 ID不要自己拼后缀填完先别急着保存三次Dify 的插件在保存或点「添加」时往往会做一次连通性校验如果 Key 或地址有问题页面右上角会飘一条红色提示。看到提示别反复点保存先把 Base URL 那一栏清空重填一遍确认没有多余空格和换行——从网页复制地址时尾部带一个不可见空格是极高频的事故。3.3 模型 ID 不要凭印象写模型 ID 这一栏是所有人的共同陷阱。有些教程会给出一个看起来很像真的字符串你照抄进去请求发出去返回一个「model not found」然后开始怀疑 Key 有问题。实际上大部分这类报错都是名字不对。稳妥做法永远是打开模型广场找到你要用的那一条复制它展示的 ID原样粘进 Dify。列表更新之后以当时看到的为准不要用过期的缓存值。如果工作流里计划用多个模型就在同一个供应商下多添加几条模型配置每条配置里的模型名不同Key 和 Base URL 保持一致。这样在 LLM 节点的下拉框里就能切换不用来回改供应商设置。4. 用一个最小 Workflow 验证模型调用真的通了4.1 搭「开始 → LLM → 结束」三节点验证不要拿复杂流程试。新建一个 Workflow只放三个节点开始节点保留一个文本输入变量LLM 节点选刚配好的模型提示词写一句最简单的比如「把用户输入改写成一句话摘要」结束节点输出 LLM 的文本。连线之后点「运行」在弹窗里填入一段测试文本。如果这一步返回了摘要说明 Dify 的模型供应商配置、Key、Base URL、模型 ID 四项全部对上了。如果报错把报错原文完整读一遍再动手改不要盲改配置——错误码已经把方向指得很清楚了具体见第 5 节。4.2 再跑一次 Chatflow 网页对话Workflow 跑通之后顺手建一个 Chatflow用同一个供应商配置在右侧预览窗口里发一句话。Chatflow 和 Workflow 走的是同一套模型供应商设置两处都通说明配置是全局生效的不是某个节点里单独填的参数在起作用。此时可以打开终端看一眼容器日志确认请求确实发出去了docker compose logs -f --tail100 api日志里会看到模型调用的记录。这一步的用处是区分「Dify 层面没发请求」和「请求发出去了但被拒绝」——前者要检查节点有没有真的连上模型后者才是 Key 或地址的问题。4.3 回控制台对一下这次调用有没有记上配置完最容易被跳过的一步是核对。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end在控制台的用量或调用记录里找刚才那几次请求看时间戳、模型名、消耗量是否对得上。对得上说明 Dify 里每一次模型调用都确实从这条通道走对不上说明工作流里某个节点还挂着一个旧的供应商配置需要逐个节点检查。5. 保存失败和调用报错Dify 里最常见的几类5.1 401Key 没粘全、粘错位置或者被空格污染401 的含义是身份没通过。在 Dify 的模型供应商页看到 401按顺序排查三件事Key 是不是完整复制了有没有漏掉结尾几个字符是不是把某个别的平台的 Key 粘进来了输入框里有没有前后空格。第三种最隐蔽从浏览器复制密钥时经常会带上一个尾部空格界面看不出来但请求头里会带上服务端自然不认。处理办法很简单清空输入框手动选中粘贴的文本删除首尾再保存一次。如果还是 401回控制台重新生成一把 Key 再试排除旧 Key 被吊销的可能。5.2 404Base URL 后面多了一段路径404 在 Dify 里几乎只有一个原因地址拼错了。常见三种写法都是错的——https://taotoken.net/api/v1、https://taotoken.net/api/、以及把浏览器里那串带utm_source的落地页地址粘进来。正确的写法只有一种https://taotoken.net/api末尾不带斜杠不带/v1不带查询参数。有人会问别的工具不是要带/v1吗不同工具对 Base URL 的处理方式不一样有的会自己拼路径有的要求你写全。在 Dify 这套插件里按本文给的写法填就对了保存后如果仍然 404先把地址栏清空重打一遍别复制。5.3 MacOS-12(Intel) 上的容器连通性与资源问题如果错误既不是 401 也不是 404而是超时、连接被拒方向就要从配置转到环境。先在容器里试一下能不能访问到接口域名docker compose exec api curl -s -o /dev/null -w %{http_code}\n https://taotoken.net/api返回一个 HTTP 状态码说明容器到接口这条链路是通的问题回到配置如果命令直接卡住或者报域名解析失败那就是 Docker 自身的网络或 DNS 问题重启 Docker Desktop、确认容器网络模式比反复改 Dify 配置有效得多。Intel 机器还要留意资源。plugin daemon 容器内存吃紧时会杀掉进程表现是模型供应商页偶发保存失败、过一会儿又好了。把 Docker Desktop 的资源上限调高再重试一次保存往往就正常了。6. 切过来之后工作流里每一步模型调用都从同一条通道走6.1 多个节点、多个模型时的注意点一个成熟的工作流里往往不止一个 LLM 节点前面一个负责理解意图中间一个负责生成结构化内容后面可能还有分类或改写。这些节点如果都挂着同一个供应商配置那么每次运行消耗的 Token 都从同一条通道走账目是集中的排查也集中。需要留意的是别在节点里写死过时的模型名。Dify 允许在节点级别指定模型如果某个节点很久没动过里面可能还留着旧名字。切完供应商之后把所有 LLM 节点过一遍确认模型名都在当前列表里比等它运行时报错再回头找要省事。6.2 交接下一步模型供应商配通之后Dify 的调试节奏会明显顺起来。想先用同一把 Key 在网页里直接试一条消息确认模型 ID 没写错可以打开 模型对话如果工作流要长期跑、调用量偏大先在 Coding Plan 里看看套餐是否够用需要再生成一把新 Key 给别的环境用直接去 控制台 API Keys。最后提醒一句Dify 里配的是模型调用通道它不会替你去连生产库、也不会替你执行任何业务脚本。工作流要处理数据库相关的内容仍然是由你本地的客户端执行 SQL、把结果或报错贴回对话模型只负责生成和解释。