n8n 升级风险：流程显示启用却不执行

n8n 升级后，工作流仍显示 Published，却再也不执行，这是作者对 3.0 最强烈的提醒。相比节点报错，更麻烦的是没有执行记录，也没有告警，业务可能已经中断，后台看起来却一切正常。

作者围绕这类「静默失效」列出了节点替换方向和升级检查步骤。对维护客户自动化、定时任务或 AI 工作流的程序员，最值得带走的是验收方法。不过，原文没有提供官方公告或复现记录，其中的版本变更需要与作者的经验判断分开看。

为什么 Published 不能证明工作流还活着

作者给出的解释是：在 n8n 2.x 中，工作流的 active 标记与触发器是两件事。升级到 3.0 后，引擎扫描启用的工作流并启动触发器；如果依赖的旧节点包已经不存在，触发器无法启动，但数据库中的 active 状态仍然保留。

也就是，界面记录了「应该运行」，不代表运行所需的组件真的启动成功。

原文把后果分成四类：

• Cron、Interval 触发器失去监听器，定时任务不再触发，日志没有错误。
• 含 Function 或 Function Item 的工作流仍显示一个活动触发器，但 worker 在首次运行前中止，历史记录为零。
• 父工作流正常运行，调用含已移除节点的子工作流时，子流程静默失败。
• 含已移除节点的草稿无法发布，修改滞留在未发布状态。

作者自己运行了一个基于 Error Trigger 的全局错误处理工作流，称为 Watchtower。它能在执行失败时发送通知，并附上失败运行的直达链接。但如果触发器根本没有启动，就没有失败执行可供捕获。

错误告警只能证明有人失败，不能证明该执行的任务都执行了。

原文对前两类描述得较具体；对子工作流如何失败、父流程会留下什么状态，没有进一步解释，不能据此认定所有调用方式都完全没有可见信号。

升级前要替换哪些节点，还要检查什么

按原文说法，n8n 3.0 stable 预计在 2026 年 12 月上旬发布，beta 自 10 月 27 日开放，将移除 37 个弃用节点，并把 Code 节点超时从 300 秒缩短到 60 秒。后者需要单独检查：节点迁移成功，也不代表原先耗时较长的代码还能跑完。

原文列出的主要替换关系如下：

旧节点	替换方式
Function	Code，选择 Run Once for All Items
Function Item	Code，选择 Run Once for Each Item
Cron	Schedule Trigger，迁移 cron 表达式
Interval	Schedule Trigger，改为配置间隔
Item Lists	按用途拆成 Split Out、Aggregate、Sort、Limit、Remove Duplicates 或 Summarize
HTML Extract	HTML，选择 Extract HTML Content
Read PDF	Extract from File，选择 Extract From PDF
Legacy OpenAI node	当前 OpenAI 节点，作者称旧端点已退役
AI Agent v1	Tools Agent

Function 的迁移涉及把 items[i].json 改用 $input.all() 取数，并返回由 json 包装的对象数组；Function Item 则把 item.json 改为 $input.item.json。这里不能当作机械字符串替换：$input.all() 返回全部输入，仍需根据原逻辑处理索引和返回结构。

Schedule Trigger 还要核对 GENERIC_TIMEZONE 或工作流单独设置的时区，避免任务执行时间偏移。

AI Agent 的变化更集中：作者称 Conversational、ReAct、Plan and Execute、SQL Agent 模式退役，版本为 1.5 或更低的 AI Agent 节点会在运行时崩溃。其余 23 个节点被概括为 LangChain 时期的加载器、Pinecone、Supabase、Zep、内存向量存储的写入与加载节点，以及旧记忆提供器和聊天辅助节点。输入原文没有附上完整的 37 节点清单，无法据此完成全量核对。

部署和表达式也有变化。作者称 3.0 停止 npm、npx 安装，自托管只支持 Docker，Kubernetes 和 Helm 部署不受影响；$getPairedItem 被移除，使用会触发致命语法错误，替代写法是 $('Node Name').item.json.property。

原文还强调，3.0 回退到 2.x 必须恢复完整备份；1.x 支持将在 2026 年 12 月 31 日结束，且没有直接从 1.x 升到 3.x 的路径。这些都是影响升级决策的关键断言，但原文未附对应官方依据。

我的判断

作者最有价值的建议，是把升级验收从「服务启动了」推进到「业务任务按预期执行了」。对发票、同步、定时报表这类自动化，仅看 Published 或失败次数，确实不足以确认业务连续性。

但这篇更像一份风险提示和迁移提纲，还不是可以直接照着执行的完整操作手册。作者没有展示测试环境、逐项复现、扫描脚本，也没有给出完整节点矩阵。Watchtower 是作者明确提到的实际使用经历；四类失效是否覆盖所有相关版本和配置，原文没有足够证据。

作者建议记录每个活动工作流两次运行间隔的中位数，并在升级后观察 48 小时。这个方向适合高频定时任务，却不能直接覆盖周任务、月任务或低频 Webhook。48 小时内没运行，可能完全符合预期；固定窗口需要结合业务频率判断。

同样，作者要求用「4-input Merge pattern」检查 If、Filter、Compare Datasets 的 Always Output Data 行为，却没有解释接线方式和预期输出。它只能作为待验证项，不能充当现成测试用例。原文也没有提供与其他验收方法的对照数据，这些步骤应按经验建议看待。

能拿来做什么

• 导出当前工作流，检查旧节点、节点版本和 $getPairedItem 引用，同时覆盖子工作流与草稿，整理成可逐项验收的迁移表。
• 迁移 Function、Function Item 时，用代表性输入核对输出数量和 json 结构，并检查 Code 逻辑能否在原文所称的 60 秒限制内完成。
• 为关键任务记录预期执行频率和最近成功时间，在 Error Trigger 之外补上「到期未执行」检查；观察窗口按任务周期设置，不统一套用 48 小时。
• 升级前准备完整备份及恢复步骤，再验证关键链路的触发、分支、子流程和业务产物；安装方式、回退限制及节点移除范围，应先与目标版本的正式说明核对。