DeepSeek 接入 n8n 全攻略：从零搭建你的 AI 自动化流程

最近更新：2026 年 5 月 25 日

你是不是也遇到过：DeepSeek API 密钥拿到了，n8n 也搭好了，但一到真正落地，就不是报错就是输出乱七八糟？问题往往不在模型本身，而在你选错了接入方式、URL、模型名，或者没有设计好 JSON 输出结构。下面这篇，就是帮你把 DeepSeek 和 n8n 接起来、跑稳、跑久的实战指南。

提前说一句：如果你只想“先跑起来”，原生 DeepSeek Chat Model 节点就够用；如果你想精细控制思维模式、JSON 输出和调试细节，HTTP Request 才是你的主力工具。

截至 2026 年 5 月，DeepSeek 官方 API 文档列出的主力模型是 deepseek-v4-flash 和 deepseek-v4-pro。旧的 deepseek-chat 和 deepseek-reasoner 只是兼容别名，目前会路由到 V4 Flash 模式，并计划在 2026-07-24 15:59 UTC 后彻底下线。OpenAI 格式的基础 URL 为 https://api.deepseek.com，聊天端点为 /chat/completions，另有 Anthropic 风格的 https://api.deepseek.com/anthropic。

本指南面向自动化工程师、开发者、AI 工作流搭建者和技术负责人，重点放在“怎么在真实工作流里用 DeepSeek”，而不是只讲 API 理论。

你将搭建什么

目标概览

读完这篇，你会清楚地知道如何：

把 DeepSeek 接入 n8n，并正确配置凭据
在多种集成方式中选出适合自己的一种
在 Basic LLM Chain 或 AI Agent 中调用 DeepSeek
用 HTTP Request 节点直接调用 DeepSeek API
通过 Ollama 运行本地 DeepSeek 风格模型
排查常见的认证、模型、JSON、Docker 和限流问题

有用户反馈，用好 JSON 输出和错误处理后，工单分拣类工作流的人工介入率能下降 40% 以上，但前提是你把结构和节点选对了。

快速上手：在 n8n 中跑起 DeepSeek

要在 n8n 中运行 DeepSeek，可以按这个最小闭环来：

注册 DeepSeek 账号并生成 API Key。
打开 n8n，新建一个工作流。
添加一个触发器，比如 Manual Trigger、Chat Trigger、Webhook、Gmail、Slack 等。
根据需求添加 DeepSeek Chat Model、Basic LLM Chain、AI Agent 或 HTTP Request 节点。
配置凭据、选择模型、写好提示词，测试通过后再激活工作流。

n8n 官方文档说明：DeepSeek 凭据使用 API Key 认证，可直接用于 DeepSeek Chat Model 节点。DeepSeek Chat Model 节点会从你的 DeepSeek 账号动态加载可用模型，所以你在 n8n 里看到的模型列表，可能会随账号权限和 DeepSeek 当前 API 状态变化。

如果你只是想搭一个标准 AI 工作流，优先用原生 DeepSeek Chat Model；当你需要完全控制请求体、思维模式、JSON 输出或排错时，再上 HTTP Request。

DeepSeek + n8n 的几种接入方式

集成方式对比：没有绝对“最好”，只有“最合适”

对 n8n 来说，没有一种 DeepSeek 集成方式能覆盖所有场景。你更关心的是：

要不要完全无代码？
要不要精细控制 API 请求？
是否需要自托管或本地模型？

n8n 的 HTTP Request 节点可以发 REST 请求，也可以作为 AI Agent 的工具使用。根据 n8n 的社区节点文档，未验证的社区节点不会出现在 n8n Cloud，需要自托管环境才能安装，所以任何“DeepSeek 社区节点”都应该默认视为自托管方案，除非 n8n 或节点维护者另有说明。

前置条件：开始前你需要准备什么

在把 DeepSeek 接入 n8n 之前，先确认你有：

一个 n8n Cloud 工作区，或自托管的 n8n 实例
一个 DeepSeek 账号
一枚有效的 DeepSeek API Key
如果是预付费账户，要有足够的 API 余额
对 n8n 中触发器、节点、凭据、表达式有基本了解
可选：如果要跑本地模型，提前安装好 Ollama

做 API 工作流时，尽量用 n8n 的 Credentials 管理密钥，而不是把密钥硬编码在 Prompt、Code 节点或 HTTP 请求体里。n8n 会把凭据单独加密存储，节点按需读取。

方法一：用原生 DeepSeek Chat Model 节点接入 n8n

为什么说原生节点是大多数人的首选

原生 DeepSeek Chat Model 节点，对大部分用户来说是最干净、最省心的路径。n8n 把它描述为“在对话式代理中使用 DeepSeek 聊天模型”的方式，节点里有模型选择参数，也提供 Base URL 字段，方便你在需要时覆盖默认 API 地址。

我自己在给团队搭内部工单助手时，第一版就是用这个节点配合 Basic LLM Chain，几乎没写一行代码，就把从邮件到 Slack 通知的链路跑通了。

步骤详解：从空白工作流到可用对话

创建或打开工作流
打开 n8n，新建一个工作流，或打开你希望由 DeepSeek 处理文本的现有工作流。
添加触发器
测试阶段用 Manual Trigger 就行；做聊天机器人用 Chat Trigger；对外提供接口用 Webhook；也可以用 Gmail、Slack、Telegram、Notion、Google Sheets 等应用触发器。
添加 Basic LLM Chain 或 AI Agent
- 只做“输入一段文本 → 输出一段文本”的，用 Basic LLM Chain。
- 需要模型自己选工具、查数据、发消息的，用 AI Agent。
挂上 DeepSeek Chat Model
在链路或 Agent 的模型连接处，添加 DeepSeek Chat Model 子节点。
创建 DeepSeek 凭据
在 n8n 的 DeepSeek Credentials 页面填入 API Key。不要把 Key 写进 Prompt。
选择模型
在模型列表中选一个当前可用的模型，比如 deepseek-v4-flash 或 deepseek-v4-pro。
配置 Prompt
写一段简洁的系统指令，并把上游节点的动态内容通过表达式传进来。
测试工作流
手动运行，检查输入、模型响应和下游节点是否符合预期。
保存并激活
确认稳定后再激活，让它在真实流量下运行。

Basic LLM Chain 和 AI Agent 怎么选

Basic LLM Chain 适合模型只需要“改写或生成文本”的场景，例如：

摘要、分类、重写
信息抽取、关键词聚类
工单标签、情绪识别
结构化 JSON 生成

AI Agent 更适合模型需要“决定下一步做什么”的场景，比如：

查 Google Sheets 或数据库
发 Slack 消息或邮件
调用内部 API
决定把工单路由给哪个团队

n8n 的 Basic LLM Chain 主要负责设置 Prompt，并可选用解析器；AI Agent 则负责协调外部工具和 API，真正执行动作。

示例 Prompt：支持工单摘要

System message：

You are an automation assistant. Return concise, structured answers.

User message：

Summarize this incoming support ticket and classify its urgency:

{{$json.message}}

对 Basic LLM Chain 来说，这样就够用了。如果是 Agent，建议再加上边界说明，比如允许用哪些工具、什么情况下要先问清楚、哪些操作必须等人工确认。

方法二：用 HTTP Request 节点直接调用 DeepSeek API

什么时候该用 HTTP Request

HTTP Request 是在 n8n 里调用 DeepSeek 最灵活的方式，适合你需要：

精确控制 API 端点、Header、Body 和模型参数
使用最新文档里的高级参数或思维模式
做 JSON 严格输出和复杂错误处理
调试模型名、认证、限流或响应结构

可以这么理解：原生节点适合“日常用车”，HTTP Request 更像“手动挡 + 改装”，自由度高，也更考验你对 API 的理解。

HTTP Request 节点基础配置

在 n8n 中添加一个 HTTP Request 节点，核心配置通常是：

Method：POST
URL：https://api.deepseek.com/chat/completions
Authentication：Bearer Token（填入 DeepSeek API Key）
Headers：Content-Type: application/json
Body：Raw JSON（见下面几个模板）

DeepSeek 快速上手文档中展示的也是同一个 chat-completions 端点、Bearer 认证头、JSON Content-Type，以及 stream: false 的结构。

可直接复制的 JSON：快速自动化（不启用思维模式）

适合做分类、抽取、改写、聊天回复等对速度要求高的任务：

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "system",
      "content": "You are a concise automation assistant. Return clear, actionable output."
    },
    {
      "role": "user",
      "content": "{{$json.chatInput || $json.prompt || $json.message || ''}}"
    }
  ],
  "thinking": {
    "type": "disabled"
  },
  "stream": false
}

可直接复制的 JSON：需要推理和深度分析时

当工作流需要更强的推理、规划、对比分析时，可以用 deepseek-v4-pro：

{
  "model": "deepseek-v4-pro",
  "messages": [
    {
      "role": "system",
      "content": "Think carefully and return a structured answer."
    },
    {
      "role": "user",
      "content": "{{$json.task}}"
    }
  ],
  "thinking": {
    "type": "enabled"
  },
  "reasoning_effort": "high",
  "stream": false
}

DeepSeek 的思维模式文档说明：

用 {"thinking": {"type": "enabled/disabled"}} 控制是否启用思维模式
reasoning_effort 可设为 high 或 max
启用思维模式时，不支持 temperature、top_p、presence_penalty、frequency_penalty 等参数，即便兼容层不报错，也不会生效

为下游节点生成 JSON 输出

如果你的下一个节点是 Slack、Telegram、Google Sheets、Notion、邮件或 Respond to Webhook，结构化输出通常比纯文本安全得多。

要让 DeepSeek 输出 JSON，可以：

在请求体中添加 response_format
在 Prompt 里明确要求返回 JSON

示例：

{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "system",
      "content": "Return only valid JSON. Do not include markdown."
    },
    {
      "role": "user",
      "content": "Classify this support ticket as JSON with fields: summary, urgency, category, suggested_reply, next_action. Ticket: {{$json.message}}"
    }
  ],
  "response_format": {
    "type": "json_object"
  },
  "max_tokens": 800,
  "stream": false
}

DeepSeek 的 JSON 输出指南建议：

response_format 设为 {"type": "json_object"}
在系统或用户 Prompt 中明确提到 “json”
给出期望 JSON 结构示例
max_tokens 设得足够大，避免 JSON 被截断

在 n8n 中映射响应数据

DeepSeek 的主要回答通常在：

choices[0].message.content

在 n8n 里，你可以把这个字段传给：

Slack：团队通知
Telegram：即时提醒
Google Sheets：日志或报表
Email：摘要或草稿
Respond to Webhook：对外 API 响应
Set/Edit Fields：重命名或规范字段
Code：做更严格的 JSON 解析和校验

大多数工作流建议保持 stream: false，除非你已经专门设计了流式响应管道。

方法三：在 n8n 中把 DeepSeek 接成 AI Agent 的“大脑”

什么时候用 Agent 而不是简单链路

当你需要的不只是“回答一个问题”，而是：

让模型自己决定要不要查表
选择调用哪个内部 API
更新记录、发通知、创建任务

这时就该用 AI Agent，让 DeepSeek 变成一个会用工具的“执行者”。

一个简单的 Agent 工作流可以长这样：

Chat Trigger → AI Agent → DeepSeek Chat Model
                         → HTTP Request tool
                         → Google Sheets tool
                         → Slack tool
                         → Gmail or Notion tool

n8n 的 AI Agent 节点通过工具和 API 来执行动作，官方说明 Agent 至少要连接一个工具子节点，目前的 Agent 节点属于 Tools Agent 类型。

DeepSeek Agent 的实战建议

给 Agent 的任务范围要窄，不要一句“你负责客户支持”就完事。可以这样写：

You are a support triage agent. Your job is to classify incoming tickets, summarize the issue, decide whether escalation is needed, and draft a reply. You may use the connected tools only when necessary. Never send a customer-facing message without human approval.

然后配合这些规则：

写清楚系统 Prompt，不要含糊
工具权限尽量收紧
涉及风险操作时加人工审批
记录 Agent 输出和工具调用日志
下游写库前先校验 JSON
能用确定性路由的地方，就别全交给模型“拍脑袋”
只有在确实需要对话记忆时再开启 Memory

DeepSeek API 支持 Tool Calls，但模型本身不会执行函数，真正执行工具、把结果回填给模型的，是你的应用或 n8n 工作流。

方法四：用 n8n + Ollama 跑本地 DeepSeek 风格模型

本地运行和云端 API 的关键差异

本地跑 DeepSeek 风格模型，和直接用 DeepSeek 官方 API 是两件事：

用 API：n8n 请求发到 DeepSeek 托管的云端模型
用 Ollama：你在本机或服务器上跑一个本地模型，比如 DeepSeek-R1 的蒸馏版本

这意味着：

行为、延迟、上下文长度、工具支持都可能不同
你对隐私和数据留存有更大掌控
性能高度依赖你的硬件和部署方式

这种方式适合：

本地测试和开发
对隐私敏感的工作流
离线或弱网环境下的实验
自托管 AI 平台
降低对云端模型 API 的依赖

但也有明显代价：模型大小、量化方式、CPU/GPU、内存和并发负载都会直接影响体验。

在 n8n 中接入本地 DeepSeek 模型的步骤

安装 Ollama
在本地机器或服务器上安装 Ollama。
拉取 DeepSeek 模型
示例命令：
```
ollama pull deepseek-r1:7b
```
Ollama 模型库中列出了多个 DeepSeek-R1 变体，包括 1.5b、7b、8b、14b、32b、70b、671b 等，其中 deepseek-r1:7b 是常用的蒸馏版本之一。
在 n8n 中添加 Ollama Chat Model 节点
在工作流里添加 Ollama Chat Model，并连接到 Basic LLM Chain 或 AI Agent。
配置 Ollama 凭据
在 n8n 中配置 Ollama Credentials，填入正确的实例 URL。
选择合适的 Base URL
常见示例：
- 本机非 Docker：
  http://localhost:11434
- n8n 在 Docker、Ollama 在宿主机：
  http://host.docker.internal:11434
- n8n 和 Ollama 分别在 Docker 容器：
  http://YOUR_OLLAMA_CONTAINER_NAME:11434
连接到 Chain 或 Agent
简单 Prompt 用 Basic LLM Chain，涉及工具调用用 AI Agent。
用小 Prompt 先试跑
先用一句话分类或摘要测试，确认延迟和稳定性，再上长文本或复杂任务。

Docker 网络常见坑

在 Docker 里，容器内部的 localhost 指的是容器自己，不是宿主机。n8n 的 Ollama 故障排查文档提到：

如果 n8n 或 Ollama 跑在 Docker 里，需要正确配置网络
Linux 上给 n8n 容器加 --add-host host.docker.internal:host-gateway，才能用 host.docker.internal 访问宿主机
多个容器在同一 Docker 网络上时，可以通过容器名互相访问

很多人以为“URL 写 localhost 就行”，结果调了半天才发现请求根本没出容器，这个坑挺常见。

如何为 n8n 选择合适的 DeepSeek 模型

截至 2026 年 5 月，用 DeepSeek API 做工作流时，实际选择通常在 deepseek-v4-flash 和 deepseek-v4-pro 之间：

deepseek-v4-flash：偏向速度，适合高频、轻量任务
deepseek-v4-pro：偏向推理和复杂任务

DeepSeek 当前的模型详情页显示：

两个模型都支持 JSON 输出和 Tool Calls
上下文长度为 1M tokens
思维模式可按文档切换

部署前，建议再去看一眼最新模型列表和价格：模型名、功能、价格和下线时间表都可能变化。有团队在 2025 年就踩过“用已弃用模型名导致生产故障”的坑，教训挺深。

实战示例：用 DeepSeek + n8n 做工单分拣

目标：自动理解和路由支持工单

当一封支持邮件或工单进来时，希望 DeepSeek 能自动：

总结问题
判断紧急程度
识别类别
生成建议回复
给出下一步动作建议
发 Slack 通知
把结果写入 Google Sheets
可选：生成邮件或工单系统草稿

这种场景在 SaaS 团队里很常见，有团队用类似方案，把一线支持的初筛时间从几分钟压到十几秒。

工作流结构示例

Webhook or Gmail Trigger
→ Set/Edit Fields
→ Basic LLM Chain or HTTP Request to DeepSeek
→ Parse JSON
→ Slack notification
→ Google Sheets row
→ Optional draft reply

示例输入

{
  "customer_email": "alex@example.com",
  "message": "I reset my password twice but still cannot access my account. This is blocking our team from submitting today’s report."
}

示例 Prompt

Return only valid JSON.

Classify the following support ticket. Use this JSON structure:
{
  "summary": "",
  "urgency": "low | medium | high",
  "category": "",
  "suggested_reply": "",
  "next_action": ""
}

Ticket:
{{$json.message}}

示例 JSON 输出

{
  "summary": "Customer cannot access their account after password reset.",
  "urgency": "high",
  "category": "account_access",
  "suggested_reply": "Thanks for reaching out. We’ll help you restore access...",
  "next_action": "Escalate to support tier 2"
}

节点和风控建议

在生产环境里，输出结构一定要“死板”一点：

用 Set/Edit Fields 或 Code 节点校验 JSON 结构
缺字段或类型不对时，走错误分支或人工审核
不要让模型直接发给客户，先落地到 Slack 或工单系统，由人工点一下确认

有用户反馈，刚开始没做校验，结果模型偶尔输出多一个字段，直接把下游 Google Sheets 节点搞挂了，排查起来非常费时间。

DeepSeek 在 n8n 中的常见问题与排查

常见错误类型

在实际使用中，最常见的几类问题包括：

认证失败：API Key 错误、没加 Bearer、选错 Credentials
模型错误：用到了已弃用的模型名
JSON 解析失败：输出不是合法 JSON 或被截断
限流和配额：高并发或余额不足
Docker 网络：URL 指向错误容器或宿主机不可达

排查时，可以先用一个最简单的 HTTP Request 节点，只发一条固定 Prompt，确认 API 本身没问题，再逐步加复杂逻辑。

安全与生产环境最佳实践

DeepSeek + n8n 很容易接触到敏感数据，所以要把它当“生产系统”，而不是玩具项目。

可以参考这些规则：

不要把 API Key 写在 Prompt、Code 节点、前端代码或可见字段里
把密钥放在 n8n Credentials 或合规的密钥管理服务中，怀疑泄露就立刻轮换
不同环境或工作流用不同的 API Key
对临时错误加重试机制
高并发场景加限流或批处理
未经评估，不要把用户隐私、客户 PII、凭据、内部文档或受监管数据发给第三方
下游系统尽量用结构化 JSON
在写库或发消息前校验模型输出
涉及客户、财务、法律或破坏性操作时加人工审批
监控工作流执行情况和错误率
定期更新 n8n、社区节点和自托管依赖
使用社区节点前，先看维护频率和 Issue 情况

如果你在用 AI Agent，一定要限制它的工具范围：

工单分拣 Agent 不需要访问所有内部 API
线索丰富 Agent 不应该有开票权限
研究类 Agent 不该能删记录

有团队在 2024 年就因为 Agent 工具权限过大，误删了一批测试数据，虽然不是生产环境，但教训挺深。

结尾：把这套方法用在你自己的工作流里

DeepSeek 接入 n8n，看起来只是“多加几个节点”，但真正拉开差距的，是你对模型选择、思维模式、JSON 输出和安全边界的设计。这里的配置和 Prompt 模板，都是在真实工作流里反复打磨过的，遇到问题时也方便你快速对照排查。

如果你正打算把某个业务流程交给 AI 来做判断或分拣，不妨先按文中的示例搭一个小型试点，再逐步扩展。等哪天你需要回头查问题或复制一套配置，这篇文章会比问身边人靠谱得多，值得先收藏一份。

常见问题

Q：怎么在 n8n 里无代码接入 DeepSeek？

A：可以，最简单的无代码方式是用原生的 DeepSeek Chat Model 节点，配合 Basic LLM Chain 或 AI Agent。你只需要在 n8n 里配置好 DeepSeek 的 API Key 凭据，然后在节点里选择模型、写好 Prompt 即可，不需要写任何代码。之所以推荐这种方式，是因为它和 n8n 的 AI 节点深度集成，参数界面清晰，适合快速搭建和后期维护。实操时，建议先用 Manual Trigger 做几次测试，确认响应结构和下游节点映射都正常，再接入真实触发器。

Q：在 n8n 中运行 DeepSeek，哪种方式最省事？

A：对大多数人来说，最省事的链路是：Trigger → Basic LLM Chain or AI Agent → DeepSeek Chat Model。这样你既能用到 n8n 的 AI 能力，又不用自己拼 HTTP 请求。Basic LLM Chain 适合“输入一段文本，输出一段文本”的简单场景，比如摘要、分类、改写；AI Agent 则适合需要调用工具的复杂场景，比如查表、发消息、调内部 API。搭建时，可以先用 Basic LLM Chain 验证 Prompt 和模型效果，再考虑是否升级为 Agent。

Q：DeepSeek 能在 n8n Cloud 上用吗？

A：可以，只要你的 n8n Cloud 工作区里有原生的 DeepSeek Chat Model 节点，或者你用 HTTP Request 节点直接调用 DeepSeek API。两种方式都不依赖自托管环境。需要注意的是，社区节点和官方节点不同，未验证的社区节点通常只能在自托管 n8n 中安装，n8n Cloud 默认不会提供，所以如果你看到某个 DeepSeek 社区节点，部署前要确认它是否支持 Cloud 环境。为了减少不确定性，生产环境优先考虑官方内置节点或 HTTP Request。

Q：能不能只用 HTTP Request，不用 DeepSeek 原生节点？

A：完全可以，而且在一些场景下，HTTP Request 反而更稳。原因是它直接按 DeepSeek 官方文档发请求，你可以精确控制 URL、Header、模型名、思维模式、JSON 输出和请求体结构。遇到认证错误、模型名不兼容或 JSON 解析问题时，用 HTTP Request 调试会更直观。实操建议是：先用 HTTP Request 搭一个最小可用请求，确认 API 行为，再根据需要决定是否切换到原生节点，或者保留 HTTP Request 作为“兜底方案”。

Q：DeepSeek 的 API Base URL 在 n8n 里应该怎么填？

A：如果你走的是 OpenAI 兼容格式，在 n8n 的 HTTP Request 节点中，基础 URL 用 https://api.deepseek.com，聊天补全端点则是 https://api.deepseek.com/chat/completions。也就是说，节点里的 URL 字段可以直接填完整的 https://api.deepseek.com/chat/completions。DeepSeek 文档还列出了一个 Anthropic 风格的基础地址 https://api.deepseek.com/anthropic，但那一套通常需要不同的请求格式。配置时要注意，不要把路径写错成 /v1/chat/completions 之类的其他服务格式，否则会直接返回 404 或参数错误。

Q：在 n8n 里应该选哪个 DeepSeek 模型？

A：一般来说，deepseek-v4-flash 适合大部分高频、轻量的自动化任务，比如分类、抽取、常规对话；deepseek-v4-pro 更适合复杂推理、规划和 Agent 工作流。部署新工作流时，不建议再用 deepseek-chat 或 deepseek-reasoner 这类兼容别名，因为官方已经标注为即将下线。选择模型前，可以先看一眼 DeepSeek 最新的模型和价格页面，结合你的输入长度、输出长度和调用频率做个简单估算，避免因为长 Prompt 和高重试率导致成本意外飙升。

Q：能在 n8n 里本地运行 DeepSeek 吗？

A：可以，你可以通过 Ollama 跑本地的 DeepSeek-R1 等模型，再用 n8n 的 Ollama Chat Model 节点接入。这种方式适合本地测试、隐私敏感或对云端依赖度要求低的场景。不过性能会强烈依赖你的硬件配置（CPU/GPU、内存、磁盘）和 Docker/网络设置。实践中，建议先用小模型（比如 7B）和短 Prompt 做压测，观察延迟和资源占用，再决定是否上更大的模型或更复杂的工作流。

Q：为什么我的 DeepSeek API Key 在 n8n 里总是报错？

A：常见原因包括：Key 填错、Header 里没加 Bearer 前缀、Key 已过期或被删除、节点选错 Credentials、账户余额不足，或者请求发到了错误的 URL。排查时，可以先在 DeepSeek 控制台重新生成一枚新的 API Key，在 n8n 里更新对应 Credentials，然后用一个最简单的 HTTP Request 节点，只发一条固定 Prompt 做测试。如果简单请求都失败，再检查 URL、Header 和网络环境；如果简单请求成功，再回到原工作流逐步排除节点配置问题。

Q：DeepSeek 在 n8n 的 Agent 里支持 Tool Calling 吗？

A：DeepSeek API 本身支持 Tool Calls，n8n 的 AI Agent 也通过工具和 API 来执行动作，但具体组合是否稳定，还要看你用的 n8n 版本、模型版本、工具 Schema 和 Agent 配置。实践中，如果你发现 Tool Calling 行为不稳定，可以先简化工具 Schema（减少字段、避免嵌套过深），并用 HTTP Request 节点直接调试 DeepSeek 的 Tool Calls 接口，确认模型返回的工具调用结构是否符合预期。必要时，可以把复杂工具拆成多个简单工具，让 Agent 更容易做出正确选择。

Q：DeepSeek 用在 n8n 工作流里，会比其他 LLM API 更省钱吗？

A：不能想当然地认为“DeepSeek 一定更便宜”，需要结合你的实际使用模式来算。DeepSeek 的计费是按输入和输出 Token 来算的，如果你的工作流 Prompt 很长、输出很多、还频繁重试或开启高推理强度，即便单价便宜，总成本也可能不低。建议对比当前 DeepSeek 的价格、你预估的调用次数、平均输入输出长度，以及是否启用思维模式和大上下文，然后做一个简单的成本模型。也可以先在测试环境跑一段时间，观察真实消耗，再决定是否大规模迁移。