重构：使用 n8n+飞书 重写视频下载小工具，直接上链接

这段时间集中使用 n8n，这篇算是给自己一个阶段性的答卷和成果输出。

一开始学习 n8n，不太像“为了学而学”，还是希望找一个真实需求的、有持续价值的事情，做到边学、边用、边完善。正好自己常常下载 YouTube 视频，之前也用 Flutter 实现过一版，对需求和功能都很熟悉，不会在业务本身耗费太多精力，主要就是怎么改成 n8n 节点来实现。

经过前面的 n8n 的学习和实践，自认为对 n8n 有一定的积累了。加上 n8n 各种丰富的组件，实现这个视频小工具是完全够用的。

从想法开始： AI + 视频下载器

最初的设想挺简单的，但必须加上AI。

• 使用飞书、企业微信这一类应用机器人来接入。

• 使用自然语言提需求，AI 理解意图后自动下载视频。过程中还能一步一步递进式的迭代。

• 可以查看历史等等。

把下载视频和 n8n 结合，摇身一变，就成了 AI+ 视频下载小工具😎。

于是乎，第一版就这样诞生咯。

YouTube视频下载器-v1（最终完善版）

第一版实现视频下载，基本功能也算齐全，用 n8n 节点把视频下载流程串起来了。功能验证是可以行的。

但真正用过一段时间后，发现如下的问题：

• 视频会被重复下载。

• 虽然有记录 Memory，但只能获取最近一轮的。

• 没法查询完整的下载记录。

• 下载的文件没有管理起来。视频文件放在临时目录下面，查看不方便。

问题前提是一个技术问题，但它最终是一个管理问题。

于是，学习子流程，升级了第二个版本。

代码工具（Code Tool）全部拆到子流程（Sub-workflow）。在子流程里面，实现下载结果记录，支持后续搜索查询。

同时，下载前先检查是否已下载。已经下载的直接直接返回历史结果。

YouTube视频下载器-v2

YouTube视频下载的子流程-v2

至此，整个工具才真正的可用。

不过，这次“重构”并不轻松，别人写个 n8n 工作流都是分分钟的，而我这个重构，从去年折腾到了今年。

节点超时 和 Memory 节点获取不到前置节点数据，在这两个问题上困扰、消耗了很多的时间，也逼着我不得不去搭建开发环境、调试源码。

飞书的多维表格

下载记录表

会话日志表

效果

实现细节

工作流中用到的插件飞书节点（Lark）和 部署方式，前面的文章断断续续的都有介绍。

本地部署使用n8n，以及开发环境构建

手机上部署 n8n 服务

飞书机器人：在 n8n 中收发飞书消息

飞书多维表格：使用 n8n 存取飞书数据

n8n 2.x internal 模式下 Python Task Runner 配置实践

n8n 部署到 Docker 了，要想少走弯路，就按官方推荐的最佳实践

跟着 n8n 案例来学习子流程 Sub-workflow

n8n 任务 60s 超时，理清 N8N_RUNNERS_TASK_TIMEOUT 的真实用途与位置

一个 If 节点引发的灾难，代码工具节点获取不到前置节点数据

印象时刻

第一个，下载 YouTube 视频代理是必须的。

在 yt_dlp 配置代理使用宿主机器 IP。这样不管在家，还是在公司都能跑。

还有，测试次数多了后，就需要登录了。

添加 cookie 文件，问题基本就解决了。

安装 Get cookies.txt LOCALLY for Chrome，导出 cookies.txt 文件。

https://github.com/yt-dlp/yt-dlp/wiki/FAQ#how\-do-i-pass-cookies-to-yt-dlp

第二个，Memory 记忆。

在普通的应用中，一次操作天然有一个前后上下文的关系。但是，AI 对话接口如果只传当前的消息，它是“失忆”的。它是不知道前面说了什么的，所以需要把前面的对话作为上下文，和最新的消息一起传给 AI。需要把每次的消息都保存到 Memory 记忆里面，使用的时刻时再从记忆里面调出来给 AI。

开始我用的 Simple Memory，后来发现这是不行的。因为，每次飞书的每条消息，在 n8n 都是一次新的 Execution，内存每次都新创建的。

所以，最终换成了 Redis Chat Memory，Key 设置为飞书消息里面的 chat_id，上下文窗口长度设置为 10 条。

测试多次对话、多个 URL 的情况下，记忆太多，AI 整合的时刻就乱了。所以，在 AI 节点前判断消息中是否有 URL，一旦包含就清理缓冲，开启新一个轮对话。

问题也从这里开始复杂起来。运行完 Code Tool 后，Memory 节点取不到前面的 chat_id 数据了（Key parameter is empty）。

经过反复的调试发现，AI Agent Tool 前置节点直接只能一个。这个问题修复后，整个工作流就全盘活了。

第三个，AI Agent Tool 工具。

工具可以理解为领域专业。AI 负责理解用户输入，了解专家的特长（工具的描述），把问题拆分成任务，分配给专家（调用合适的工具去执行）。

但说实在的，在 n8n 里面写代码比在 IDE 编辑器里面难多了。代码节点不好调试。节点之间传递数据约束不够，特别是代码节点，前后节点数据不一致得等到运行时才知道报错。

而且，代码工具 Code Tool Python 节点只能输出字符串，也不能跟其他的节点，比如，保存下载记录这么朴素的需求都做不了。所以，第二版把这些 Code Tool 全部拆到使用子工作流来实现。在单独的流程里面，可以固定输入，单节点运行调试，各个都方便很多。

第四个，节点 pin 数据。

调试的技巧，是测试“神兵利器”。

已经跑过的节点，可以把 pin 钉住输出。在后续节点调试从这类开始，不用每次从头开始跑整一个流程。

甚至乎还能手动修改数据，针对不同情况模拟各种边界数据来测试。

第五个，WSL本地化文件。

这个还得再提出来说，真的差别很大！本地文件系统与跨文件系统访问，速度真的是天上地下。

避免跨文件系统访问导致 WSL 2 速度慢 90%。原来启动服务要等很久的，切换到 WSL 内部部署后，几乎瞬间就启动好了！

大。大。。大。。。巨大！

用 VSCode + WSL 切记一定要在内部文件系统部署！

第六个，节点数据的内存模型。

凑个数，66大顺。

理解内存模型后，知道它为什么这么设计，在节点中，编写代码获取数据就会更加的胸有成竹了。

收获

这一轮折腾下来，对 n8n 的理解不在停留在拖节点的层面，通过搭环境、读源码、调试定位问题，对 n8n 有了多一点的深入理解。搭建了流畅的开发环境后，后面遇到问题就没有畏难情绪的借口了。

更重要的是，现在有了 YouTube 视频下载工作流，已经是一个稳定可用的成品。以后，老大再叫我下载视频，我又从从容容了😁。

写在最后

项目源码地址：https://github.com/winse/n8n-youtube-downloader

如果你也有下载 YouTube 视频的需求，或者对 n8n 工作流感兴趣，欢迎一起 Fork、一起改进、一起打磨完善它。