用n8n替代本地Cron：情报管线迁移的完整思路

问题背景：同一份数据，两套管线在各自"工作"

事情是在一次代码审查里暴露的。同一个RSS源，我本地有一个Python脚本每小时抓取一次，n8n里也有一个workflow在做几乎完全相同的事——两者的数据源和解析逻辑高度重叠，只有输出路径不同：一个写入本地SQLite，一个推送到Notion。当我把两套任务列到同一张表上，才意识到：我的11个本地cron任务里，有4个和n8n的workflow存在功能重叠。这不是"双重保险"，这是积累了一段时间的技术债，而且我之前根本没意识到它的存在。

这种状态在个人开发者和小团队里极为普遍。演化路径几乎千篇一律：早期靠cron跑几个Python脚本，后来引入n8n做可视化编排，但旧的cron任务没人动，就这么一直并行跑着。时间久了，没人说得清哪个是"权威来源"，出问题了也不知道先看哪里。

为什么这个决策难做：我一开始以为"慢慢合并"就行

我最初的想法是：既然重叠的任务只有4个，直接把本地脚本停掉、让n8n接管不就完了？但实际上，一旦真的去看细节，每个任务的依赖链都比表面上复杂。比如有一个情报抓取脚本，表面上是"拉RSS、写入SQLite"，但本地脚本里其实还夹带了一段去重逻辑，依赖SQLite里的历史记录做判断。如果只是停掉cron、把相同的抓取逻辑搬到n8n，去重这一段就直接断掉了——而n8n那边从来没有实现过这个逻辑，因为两套系统根本没有人做过端到端的对照。

更麻烦的是错误处理。本地Python脚本里的try/except有些写得相当随意——有的只是打印到stderr，有的直接pass了。这些"沉默的失败"在本地完全不可见，而我一直以为脚本在正常工作，因为SQLite里确实有数据。真正让我警觉的是有一次源站改了结构，Python脚本解析失败，但没有任何告警，我是在三天后手动检查数据时才发现有缺口。如果那是一套生产级的情报系统，这个缺口就是一个真实的风险。

根因与核心决策：先盘点，再用三问法分类

真正解决问题的起点，不是迁移，而是把所有定时任务列成一张清单。我用 crontab -l 导出本地所有任务，同时把n8n里所有带Schedule Trigger的workflow逐条列出，对比每个任务的目的、数据流向、外部依赖和失败告警状态。整个过程花了大约两小时。

# 导出本地所有cron任务，先看清楚有什么
crontab -l > cron_audit.txt

# 用grep快速扫一下涉及网络请求的任务
grep -E "curl|wget|python.*fetch|python.*api" cron_audit.txt

清单建好之后，我用三个问题对每个任务做分类判断：

1. 这个任务是否需要与外部服务交互（API调用、HTTP请求、第三方推送）？
2. 这个任务是否需要可观测性（知道上次有没有跑成功、能回溯历史执行记录）？
3. 这个任务是否需要多步骤编排（根据结果分支、依赖上一步输出）？

三个问题只要有一个回答是"是"，就应该迁移到n8n。如果三个答案都是"否"，留在cron里完全合理。比如我有一个每天凌晨清理临时文件的脚本，只操作本地目录，没有网络请求，失败了重跑就行——迁移到n8n只会增加维护成本，没有任何收益。

对于决定迁移的任务，我没有做大爆炸式替换，而是让新旧两个版本并行运行至少三天，对比输出结果：

# 并行验证阶段的简单对比逻辑（伪代码）
# 新版n8n workflow输出写入staging表，旧版cron继续写入production表
# 每日跑一次diff，确认数据一致性

import sqlite3

def compare_outputs(db_path, table_old, table_new, key_col, date_col):
    conn = sqlite3.connect(db_path)
    # 取近三天数据对比
    query = """
    SELECT o.{key} as old_key, n.{key} as new_key
    FROM {old} o FULL OUTER JOIN {new} n ON o.{key} = n.{key}
    WHERE o.{key} IS NULL OR n.{key} IS NULL
    """.format(key=key_col, old=table_old, new=table_new)
    diff = conn.execute(query).fetchall()
    conn.close()
    return diff  # 返回空列表即视为一致

确认输出一致后，把旧的cron任务注释掉，观察一周无问题再彻底删除。整个迁移过程，每个任务平均多花半天，但零生产事故。

可移植的原则：这套逻辑在其他场景也适用

1. 如果你在评估"要不要把cron任务搬到n8n"，用外部交互、可观测性、多步骤编排这三个问题做筛选，三个都否的任务不值得迁移。
2. 如果你在做任何涉及数据管线的切换，先并行运行三天对比输出，确认一致再切换，不要相信"逻辑一样所以结果一样"。
3. 如果你在调度涉及LLM调用的任务，迁移后要重新规划执行时间，避免多个重量级任务同时触发——并发打满API配额是一个很容易忽视的真实风险。
4. 如果你在为团队建立工程规范，用"单一真相源"这条规则消除认知负担：外部交互任务只在n8n维护，本地cron只保留纯本地操作的系统脚本。规范的价值不在于技术先进，而在于出问题时只需要看一个地方。

最后

这次迁移让我意识到，让我困扰的从来不是工具本身，而是系统复杂度在不知不觉中变成了隐性的——没有文档、没有清单、没有人知道全貌。如果你正在构建类似的情报管线，并且也在考虑调度层的可观测性和错误处理怎么做，我们在 Synapse 框架里积累了一些可以直接参考的工程模式，包括迁移决策逻辑对应的参考实现——欢迎来看看是否有可以直接复用的部分。