混合自动化技术栈：规则与LLM混合使用的决策框架

用LLM智能体替换所有Zapier流程和RPA脚本的团队，往往在六个月后发现了同一件事：他们用"脆弱但可审计"换来了"灵活但难以维护"。Zapier流程以可预测的方式崩溃——第14步因API变更而失败。LLM工作流则悄无声息地出错——模型悄悄地将支持工单路由到错误的队列，直到客户升级投诉才被发现。审计日志只记录着"AI决策"，这用律师的话来说就是"没人知道发生了什么"。

答案不是回避在自动化中使用LLM，而是要有意识地判断哪些任务交给哪个系统，并架构好两者之间的接缝，使故障不会相互传染。

两种截然相反的失败模式——都很糟糕

规则型自动化——Zapier、n8n、传统RPA脚本——以具体且可重现的方式失败。API schema发生变更、字段被重命名、触发了限流。工作流中断，警报触发，工程师修复映射关系。这种失败模式属于运维层面：令人恼火且需要维护，但具备可审计性。你可以重放失败的任务，精确看到发生了什么。

LLM自动化以统计方式失败。相同的输入并不总是产生相同的输出。模型可能正确处理了98%的发票路由，而剩余2%则以难以检测的方式出错，除非进行抽样审查。当规模化出错时，审计追踪读起来像魔术表演："模型做出了决定。"你无法重放这个决策，只能观察结果，希望监控足够完善，能在问题复利式扩大之前浮出水面。

这两者并非处于同一光谱的两端——它们是截然相反的失败特征。规则型系统脆弱但透明；LLM系统灵活但不透明。成熟的自动化技术栈两者兼用，合理分配任务，并在它们之间构建边界，使各自的失败模式不会污染对方。

决策框架：什么任务交给什么系统

对于任何自动化任务，核心问题是：这项任务能用规则完整描述，还是需要判断力？

如果你能写出一棵覆盖所有情况的穷举决策树，就使用确定性自动化。如果边缘情况需要解读——模糊输入、自然语言、"差不多就行"的任务——就考虑LLM。但这只是起点，不是公式。在做决定前，还需叠加两个维度：

审计合规要求。 对于触发财务交易、访问权限变更、合规操作或面向客户通信的工作流，你需要能够精确重建发生了什么以及为什么。LLM决策很难真正做到可审计——日志可以记录输入和输出，但无法记录内部推理过程，而相同输入在不同模型状态下的推理可能有所不同。如果你的工作流受到监管审查，规则型路径要安全得多。智能体AI系统之所以带来日益增长的治理挑战，正是因为其决策过程往往缺乏清晰的可追溯性。

成本敏感度。 LLM API调用按token计费，即使失败也要付费。对于高频率、低复杂度的任务——解析结构化表单、从格式可预测的文档中提取字段、基于关键词列表路由请求——经济效益很少能够证明LLM的开销合理。同样的任务可以用确定性方法以极低成本完成，且可靠性更高。将LLM调用留给判断价值超过token成本的任务。

可接受的容错率。 某些工作流可以承受2%的错误率而不造成危害；另一些则无法容忍哪怕偶发的失败。LLM路由客服工单偶尔分类错误可能没问题——人工审核时能发现。但LLM将财务交易路由到正确账本就不行了。在将任务分配给LLM自动化之前，明确映射容错率。

实用分类如下：

• 使用规则型自动化的场景： 从可预测格式中提取结构化数据、使用完整决策树的条件路由、具有确定性逻辑的定时触发、任何需要精确审计追踪的步骤、算术运算、日期比较和数据库查询
• 使用LLM自动化的场景： 类别不穷举的自由文本分类、自然语言摘要、边缘情况超过规则数量的分诊决策、生成草稿或建议供人工审阅、处理用数百条脆弱正则表达式才能覆盖的变体

接缝：边界处的架构设计

在混合技术栈中，最危险的地方是规则型组件与LLM组件之间的交接点。处理不当，你会得到两者最坏的结合：确定性一侧变得依赖于无法验证的LLM输出，LLM一侧开始处理它从未设计来应对的数据。

以下几种模式有助于保持边界清晰：

时域分离。 确定性组件实时运行；LLM组件异步运行。客服工单到达时，规则型逻辑基于关键词匹配立即将其路由到队列，然后LLM异步为坐席生成建议回复。LLM永远不接触路由决策——只处理回复建议。即使LLM运行缓慢或失败，工单仍能到达坐席。一项工业监控研究架构明确采用了这种方法：确定性智能体保留对LLM生成建议的否决权，LLM分析层被明确与安全关键控制隔离。

严格的输出契约。 当LLM为规则型系统提供输出时，输出schema必须严格。不要让规则型组件接受来自LLM的自由文本输出——定义结构化JSON契约，在接收时验证它，当输出不符合规范时快速失败并报错（而非静默地尽力而为）。格式错误的LLM响应悄悄降级规则型逻辑，是混合技术栈中最常见的生产故障模式之一。

确定性兜底路径。 每个LLM处理的任务都应有兜底方案，回退到更简单的规则型路径或人工队列。当LLM超时、返回低置信度信号或输出未通过schema验证时，工作流路由至兜底方案——而非进入同样会失败的重试循环。这不仅仅是弹性工程；这也是让系统可运维的关键。凌晨三点值班的工程师应该能够完全禁用LLM层，让系统继续运行（虽然速度更慢）。

显式置信度阈值。 对于LLM分类任务，要求模型输出置信度分数或带权重的候选标签集。然后将低置信度输出路由到人工或规则型兜底，而非让模型对边界情况自行做出决定。规则型系统应始终能够在定义明确的情况下覆盖LLM。

迁移反模式：全盘替换

团队在运维上犯的最昂贵错误是全量迁移："我们要用AI智能体替换所有n8n工作流。"这种情况往往发生在LLM能力快速提升时、团队面临展示AI应用压力时，或者有人真诚地相信灵活的LLM自动化比脆弱的规则型脚本更易维护时。

仅审计追踪问题就应该让人三思。当规则型工作流路由10,000张发票，其中三张发送到错误的供应商账户时，你可以从工作流执行日志中重建这三个失败的全过程。当LLM智能体路由相同发票，其中三张出错时，你的日志只显示模型接收了输入并产生了输出。将其关联到可恢复的解释需要大量额外的仪表化工作——结构化输出日志、提示词版本控制、模型版本锁定——而团队很少在需要它之前就构建好这些。

不可维护性问题随时间复利累积。规则型工作流脆弱但显式：任何能读懂工作流的人都能理解它做什么。LLM工作流将其逻辑编码在提示词、模型版本、温度设置和上下文窗口的组合中。当模型被更新或提示词被修改以修复某个案例时，它可能悄悄破坏其他数百个案例。没有覆盖完整输入分布的系统性评估套件，LLM工作流的变更就无法有把握地部署。

还有回滚问题。规则型工作流可以通过回退配置来回滚。LLM工作流可以在代码层面回滚，但如果模型权重在上游已发生变化（或第三方模型API改变了其行为），你就无法回滚到之前的行为——只能回滚到之前的提示词。

这一切并不是反对在自动化中使用LLM，而是反对假设LLM自动化和规则型自动化可以自由互换，反对在没有保留原有系统可维护性的情况下，受组织压力驱动"把所有东西都迁移到AI"。

维持边界的运营实践

以下几项实践能让混合技术栈长期可持续：

两侧日志记录方式不同。 规则型步骤应记录输入、输出和所采用的具体规则或分支。LLM步骤应记录输入、输出、置信度分数、模型版本和提示词哈希。将LLM决策视为概率事件，而非确定性结果——日志结构应反映这一点。

在生产环境中锁定模型版本。 如果你使用的是第三方模型API，使用版本锁定的端点，并将模型升级视为需要关联测试的部署。从监控角度看，隐式模型升级导致的输出行为变化与bug无法区分。

切换前运行影子模式。 将规则型任务迁移到LLM自动化时，两套系统并行运行——规则型系统驱动生产，LLM系统静默运行，然后比较输出。只有当分歧率低于可接受的容错阈值，并且你已对一批分歧样本进行了审计后，才上线LLM系统。

监控输出分布，而非只看错误率。 规则型工作流以硬错误失败。LLM工作流会漂移。一项分类任务原本在两个类别之间呈现60/40的分布，现在变成了75/25，这可能意味着模型漂移、输入分布偏移或静默的提示词回归——这些都不会触发传统的错误警报。将输出分布作为与延迟和错误率并列的一等指标进行追踪。

正确的心智模型

将规则型自动化和LLM自动化视为适用于不同问题形态的不同工具，而非同一技术的不同代际。当问题空间可以被完整描述且审计合规很重要时，规则型系统是正确的工具。当问题空间过于庞大或模糊、无法完整描述，且否则人工需要处理每个边缘情况时，LLM系统是正确的工具。

运维危险区不在于选择其中之一——而在于假设它们可以自由替换，认为团队可以在不重建运维原语（审计追踪、回滚路径、错误预算）的情况下将所有东西迁移到LLM，而这些原语在规则型系统中几乎是自动具备的。仔细构建接缝，技术栈的两侧都能保持可维护性。