混合自动化技术栈：规则与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一侧开始处理它从未设计来应对的数据。

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

加载中…