1. 为什么我放弃手搓节点，改用 AI + MCP 生成 n8n 工作流
n8n 是个好东西，拖拽节点就能把定时任务、HTTP 请求、大模型调用串成自动化流水线。但真到落地的时候，你会发现一个尴尬的现实：节点面板里几十个分类、上百个参数，光是搞清楚「飞书机器人怎么发消息」「OpenWeather 返回的 JSON 字段叫什么」就得翻半天文档。更别提多模型切换的场景——今天想用 DeepSeek 分析天气，明天想换 Claude 润色文案，每换一次模型就要重新配一遍凭证、改一遍节点参数，重复劳动拉满。
我自己的痛点是：需要一套能快速生成 n8n 工作流 JSON 的链路，用自然语言描述需求，让 AI 直接吐出可导入的工作流文件，而不是我在画布上一个个拖。这个需求正好撞上了 MCP（Model Context Protocol）——它让 AI 助手能直接调用 n8n 的 API，读取现有工作流、创建新工作流、验证节点配置。再配合 TaoToken 的统一 Key 通道，多模型切换这件事就从「每个模型配一套凭证」变成了「改一个 Model ID」。
这篇文章面向的是需要多模型切换的自动化搭建场景。我会给出 TaoToken 的 Base URL 与 Key 配置示例、n8n-mcp-server 的可复制配置、以及一次从自然语言描述到工作流 JSON 生成并导入验证的完整动作。目标很明确：一次跑通，之后可复用。你不需要是 n8n 老手，只要会改 JSON 配置文件、能跑 npm 命令就行。
先说清楚这套链路的分工：n8n 负责执行工作流，MCP 服务端负责把 n8n 的 API 暴露给 AI 助手，TaoToken 负责给 AI 助手提供统一的模型调用入口。三者各司其职，串起来就是「描述需求 → AI 生成 JSON → 导入 n8n → 跑通验证」。
2. TaoToken 统一 Key 接入：Base URL 与多模型切换配置
TaoToken 在这套链路里的角色是「模型调用的统一入口」。你可以把它理解成一个 API 网关：不管底层是 DeepSeek、Claude 还是别的模型，你只需要记一个 Base URL 和一个 Key，切换模型时改 Model ID 就行。这对 n8n 工作流特别友好——因为 n8n 里的 AI 节点、HTTP Request 节点都只需要填这三个东西：Base URL、API Key、Model ID。
先拿 Key。访问 https://taotoken.net/api-keys ，登录后在控制台创建 API Key。创建完复制出来，格式通常是一串以sk-开头的字符串。这个 Key 要保管好，后面配置 MCP 和 n8n 节点都要用。
Base URL 统一用https://taotoken.net/api。注意这里不要加任何路径后缀，n8n 的 OpenAI 兼容节点会自动拼接/v1/chat/completions这类路径。如果你用的是 Claude Code 或者 Anthropic 风格的调用，Base URL 也是同一个，只是请求体格式不同。
Model ID 是切换模型的关键。在 TaoToken 的模型列表里，每个模型都有一个 ID，比如deepseek-chat、claude-sonnet-4这类。你在 n8n 的 AI 节点里填哪个 ID，就走哪个模型。这意味着同一个工作流，你只需要改一个字段就能从 DeepSeek 切到 Claude，不用动凭证、不用改节点结构。
我实测下来，这套配置在多模型切换场景下省事很多。以前每个模型都要单独申请 Key、单独配环境变量，现在一个 Key 走天下。而且 TaoToken 的通道对 n8n 这种需要频繁调用的场景比较友好，不会因为并发稍微高一点就限流。
如果你打算长期跑编码类或 Agent 类的工作流，可以看看 Coding Plan（https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite），它在调用额度和稳定性上更适合持续运行的场景。只是临时验证模型效果的话，用模型对话（https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite）先试一下返回格式也行。
这里有个细节要注意：n8n 的 OpenAI 兼容节点默认会去请求https://api.openai.com/v1，你要手动把 Base URL 改成 TaoToken 的地址。改完之后，节点里的模型下拉框可能还是显示 OpenAI 的模型列表，这时候直接手动输入 Model ID 就行，不用管下拉框。
3. n8n-mcp-server 可复制配置：让 AI 助手直接操作 n8n
MCP 服务端是这套链路的核心枢纽。它的作用是：AI 助手通过 MCP 协议调用 n8n 的 REST API，实现读取工作流列表、获取单个工作流详情、创建新工作流、激活/停用工作流等操作。这样你就能在 AI 助手里说「帮我新建一个每天查天气的工作流」，AI 直接调 API 把 JSON 写进 n8n。
先装 n8n-mcp-server。我用的是 leonardsellem 的版本，clone 下来编译：
git clone https://github.com/leonardsellem/n8n-mcp-server.git cd n8n-mcp-server npm install npm run build编译完成后，build/index.js就是 MCP 服务端的入口文件。接下来要配置 AI 助手的 MCP 配置文件。不同客户端的配置文件位置不一样，但结构基本一致。以 Trae 为例，配置文件通常放在用户目录下的.trae/mcp.json或者项目根目录的.mcp.json。CodeBuddy 类似，在设置里找到 MCP 配置入口。
可复制的 JSON 配置如下：
{ "mcpServers": { "n8n-local": { "command": "node", "args": [ "/root/n8n/n8n-mcp-server/build/index.js" ], "env": { "N8N_API_URL": "http://localhost:5678/api/v1", "N8N_API_KEY": "你的n8n_api_key" }, "disabled": false, "autoApprove": [] } } }这里有几个关键点。args里填的是build/index.js的绝对路径，Linux 下用正斜杠，Windows 下要用双反斜杠，比如F:\\n8n-mcp-server\\build\\index.js。N8N_API_URL本地部署填http://localhost:5678/api/v1，异地部署填http://你的服务器地址:5678/api/v1。N8N_API_KEY需要在 n8n 界面里创建：登录 n8n → 左下角 Settings → API → Create API Key，复制出来填进去。
如果你用的是 Claude Code，配置方式略有不同。Claude Code 的 MCP 配置在~/.claude/settings.json或者项目级的.claude/settings.json里，结构类似，但字段名可能稍有差异。Claude Code 的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里有详细说明，包括 Base URL 和 Key 的填法。
配置写完后重启 AI 助手，在对话里问一句「列出我的 n8n 工作流」，如果 MCP 服务端正常，AI 会调用 n8n API 返回工作流列表。这一步是验证 MCP 是否接通的关键动作。如果返回空列表或者报错，先检查 n8n 是否在运行、API Key 是否正确、路径是否写对。
还有一个容易踩的坑：n8n 默认开启了 secure cookie，本地测试时如果通过非 HTTPS 访问，可能会被拦截。启动 n8n 容器时加-e N8N_SECURE_COOKIE=false可以跳过这个限制，仅限测试环境用。
4. 从自然语言到工作流 JSON：一次完整的生成与导入验证
配置通了之后，就可以让 AI 生成工作流了。我用的提示词是这样的：
新建一个 n8n 工作流，功能如下：每天上午 7 点定时查询上海当天的天气信息。然后使用 AI（DeepSeek 模型）对天气信息进行分析，生成一份天气预报，内容包括当天天气、穿衣指数推荐、出行注意事项。最后把天气预报信息发送到飞书。
AI 收到这个描述后，会通过 MCP 调用 n8n 的 API，先创建一个空工作流，然后逐步添加节点：Schedule Trigger 节点（定时 7 点）、HTTP Request 节点（调 OpenWeather API）、AI 节点（调 DeepSeek 分析）、飞书 Webhook 节点（发送消息）。每个节点的参数 AI 都会根据 n8n 的节点 schema 自动填充。
这里有个技巧：如果你有参考工作流，可以把 JSON 文件路径告诉 AI，让它参考现有结构。n8n 官网的 workflow 库（https://n8n.io/workflows/）里有大量现成模板，下载一个类似的天气工作流 JSON，让 AI 参考它的节点连接方式，生成准确率会高很多。
生成完成后，AI 会返回工作流 JSON。你可以直接在 n8n 界面里导入：Workflows → Import from File，选择 JSON 文件。导入后检查节点连接是否正确，特别是 Schedule Trigger 的 cron 表达式、HTTP Request 的 URL 和 Header、AI 节点的 Base URL 和 Model ID。
AI 节点的配置要重点检查。Base URL 填https://taotoken.net/api，API Key 填你的 TaoToken Key，Model ID 填deepseek-chat。如果你想让 AI 用 Claude 分析，把 Model ID 改成对应的 Claude 模型 ID 就行，其他不用动。
飞书 Webhook 的配置：在飞书群里添加自定义机器人，拿到 Webhook 地址，填到 n8n 的 HTTP Request 节点里。请求方法选 POST，Body 用 JSON 格式，内容里引用 AI 节点的输出。
导入后点击「Execute Workflow」手动跑一次。如果一切正常，你会在飞书群里收到一条天气预报消息。这一步跑通，说明整条链路——从自然语言描述到工作流执行——已经打通。
实测下来，用 Claude 模型生成工作流 JSON 的准确率比 DeepSeek 高一些，特别是在节点参数填充和连接逻辑上。但 DeepSeek 胜在便宜、快，适合反复调试。你可以先用 DeepSeek 快速生成一版，再用 Claude 润色修正。
5. 常见报错排查：401、EAI_AGAIN、JSON 格式错误
这套链路跑通之前，大概率会撞上几个报错。我把踩过的坑列出来，你对照着排查。
401 Unauthorized：这个最常见，通常是 API Key 填错了或者没填。检查三个地方：n8n 的 API Key 是否复制完整、TaoToken 的 Key 是否有效、MCP 配置里的N8N_API_KEY是否和 n8n 界面里创建的一致。如果 Key 没问题，检查 Base URL 是否多了或少了/v1。TaoToken 的 Base URL 是https://taotoken.net/api，n8n 的 API URL 是http://localhost:5678/api/v1，两者不要搞混。
EAI_AGAIN：这个报错通常出现在 Docker 容器里调外部 API 时，本质是 DNS 解析失败。n8n 容器默认的 DNS 可能解析不了外部域名。解决办法是修改宿主机的 DNS 配置：
vim /etc/resolv.conf把内容改成：
nameserver 8.8.8.8 nameserver 8.8.4.4然后重启 n8n 容器：
docker ps docker restart <容器ID>重启后再跑一次工作流，EAI_AGAIN 应该就消失了。
JSON 格式不对或 params error：这个报错通常出现在 AI 节点返回的内容被直接塞进飞书 Webhook 的 Body 里。AI 返回的可能是 Markdown 格式的文本，而飞书 Webhook 要求 JSON。解决办法是在 AI 节点和飞书节点之间加一个 Code 节点或者 Set 节点，把 AI 的输出包装成 JSON 对象。比如：
{ "msg_type": "text", "content": { "text": "{{ $json.output }}" } }local proxy failed：如果你在 MCP 配置里填了代理相关的环境变量，去掉它们。这套链路不需要代理，TaoToken 的地址直接可达。检查env字段里有没有多余的HTTP_PROXY或HTTPS_PROXY。
OAuth 相关报错：如果你用的是 Claude Code 并且配置了 OAuth，检查settings.json里的认证方式。Claude Code 的接入文档里有说明，用 API Key 方式比 OAuth 更简单，直接填 TaoToken 的 Key 就行。
reading choices 报错：这个通常出现在 AI 节点返回格式不符合 OpenAI 兼容规范时。检查 Model ID 是否填对，Base URL 是否指向 TaoToken。如果用的是非 OpenAI 兼容的模型，需要在 n8n 里换对应的节点类型。
排查顺序建议：先确认 n8n 本身能跑通（手动建一个简单工作流测试），再确认 MCP 能连通（让 AI 列出工作流），最后确认 AI 节点能调通（单独跑一次 AI 节点）。逐层排查，比一上来就查整条链路高效得多。
6. 把生成链路固化下来：可复用的配置与后续动作
一次跑通之后，你要做的是把这条链路固化下来，下次直接复用。我的做法是：把 MCP 配置文件、n8n 的 API Key、TaoToken 的 Key 整理成一个模板，存在项目目录里。下次换机器或者换项目，直接复制配置、改路径和 Key 就行。
n8n 工作流本身也可以导出成 JSON 存起来。在 n8n 界面里选中工作流 → Download，得到一个 JSON 文件。这个文件就是你的「工作流模板」，下次需要类似功能时，让 AI 参考这个模板生成新工作流，准确率会高很多。
如果你需要频繁生成工作流，可以考虑把常用的节点配置写成片段。比如飞书 Webhook 的配置、OpenWeather API 的调用方式、AI 节点的 Base URL 和 Model ID，这些都可以存成 JSON 片段，让 AI 在生成时直接引用。
多模型切换的场景下，建议在 n8n 里用环境变量管理 Model ID。这样你只需要改一个环境变量，所有工作流里的 AI 节点都会切换到新模型。n8n 支持在 Settings → Variables 里定义环境变量，然后在节点里用{{ $env.MODEL_ID }}引用。
后续如果要接入更多模型，只需要在 TaoToken 的模型列表里找到对应的 Model ID，填到环境变量里就行。Base URL 和 Key 都不用动。这就是统一 Key 通道的价值——把多模型切换的成本从「改配置」降到「改一个字段」。
最后一步验证：在 AI 助手里说「列出我的 n8n 工作流」，确认 MCP 仍然连通；然后跑一次天气工作流，确认飞书能收到消息。两个动作都通过，说明整条链路稳定可复用。之后你就可以把精力放在工作流逻辑本身，而不是配置和调试上。
：V1 从跑通到放弃，用 TaoToken 统一 Key 复盘 FastAPI 踩坑)
