节点总会出莫名其妙的错，这是我这几年搞自动化最深的体会。你精心设计的流程，在 n8n 里跑得顺风顺水，结果某个第三方 API 今天突然改了返回格式，或者 OpenAI 的某个节点抽风，整个工作流就卡死在那儿了。以前我得半夜爬起来看日志，现在不了，我让它们自己打一架。
这套系统的核心逻辑很简单，就是“不把鸡蛋放在一个篮子里”，但执行起来全是细节。我最早被坑是在一个数据清洗流程里，用 GPT-4 提取结构化信息，结果它偶尔会返回一个完全不合 JSON 格式的字符串，导致下游节点全部崩掉。当时我的做法是加个错误处理，重试三次，不行就发邮件告警。但这解决不了问题，重试三次它可能还是错的，告警来了我还得人工介入，那我要自动化干嘛？后来我想，为什么非得吊死在这一棵树上？我手头有 GPT-4、Claude-3、甚至国内的一些大模型 API，虽然能力有差距，但对付一个简单的信息提取任务，总有一个能干活吧。
于是就有了第一版“多模型投票器”。一个任务进来，我同时发给三个模型，等它们都返回了，我写个简单的脚本比对结果。如果三个结果里有两个高度一致，就采用这个多数派的结果。如果三个都各说各话，那说明这个任务本身可能就有歧义，系统会把它扔进“待人工复核”队列，而不是让流程死掉。这个法子解决了 80% 的随机性错误，但代价是成本和时间都翻了倍，毕竟一个任务要调用三次 API。
成本扛不住，我就得优化。不能无脑并发，得有点策略。现在的系统是这么干的：设置一个主模型（通常是能力最强最贵的那个），一个备胎模型（便宜但够用），还有一个“裁判”模型（用来做结果校验）。工作流正常运行时，只用主模型。一旦主模型的返回被“裁判”模型判定为格式错误、明显胡言乱语、或者触发了某些预设的关键词黑名单（比如“作为 AI 模型，我无法…”），系统不会直接报错，而是自动触发一个分支。
这个分支会做几件事：首先，把原始任务和主模型的错误输出一起，扔给备胎模型，让它再试一次。同时，系统会去检查这个出错节点的历史记录，如果发现类似错误在过去 24 小时内频繁出现，它会自动调低主模型在这个工作流中的优先级，下次直接走备胎。最狠的一招是，我设置了一个“方案库”，里面记录了一些经典错误和对应的解决脚本。比如，如果错误信息是“JSON 解析失败”，系统会先尝试用正则表达式去暴力提取可能的数据字段；如果错误是“API 频率限制”，它会自动把任务挂起，等一个随机时间后再重试，而不是傻乎乎地连续撞墙。
这听起来好像也没什么，不就是一些 if-else 吗？但关键在于，所有这些决策逻辑，本身也是用 AI 来驱动和优化的。我用一个轻量级的模型（比如 GPT-3.5-turbo）作为“调度员”，它来分析错误日志，决定调用哪个修复方案，甚至评估是否值得为了这个任务去启动更昂贵的备胎模型。这就形成了一个闭环：干活的主力会出错，但有一个更冷静、更抠门的“监工”在看着，它手里有备用钥匙和应急手册。
搞这个的初衷，就是不想再当救火队员。去年有段时间，我手头维护着十几个自动化的数据流，每天光处理各种节点的意外中断就能耗掉两小时。身体就是那会儿开始报警的，颈椎腰椎一起抗议。我意识到，所谓的“自由”，不是你能做出多少套自动化，而是你做的自动化能不能在离开你之后自己活下去。你得赋予系统“自愈”的能力，哪怕这种自愈看起来很笨，只是换个模型再试一次，或者按照一条死板的规则去绕路。
现在这套东西跑顺了，我每天只需要扫一眼“人工复核”队列和系统自己生成的“策略调整报告”。看着那些曾经需要我手动干预的错误，现在被系统自己悄无声息地消化掉，有种奇怪的欣慰感。这不是技术的胜利，这是心态的转换。以前总想做出一个完美无缺、永不停机的神级流程，现在接受了“出错是常态”，目标变成了“如何让错误发生时，损失最小，且不需要我起床”。自愈力，对系统来说，是冗余和逻辑判断；对人来说，就是敢放手，以及留出应对意外的冗余时间。我的冗余时间，现在用来健身和琢磨新玩意儿，而不是对着报错日志拧眉头。那眉头早就该松开了。
