混合自动化技术栈：规则与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，而这些原语在规则型系统中几乎是自动具备的。仔细构建接缝，技术栈的两侧都能保持可维护性。