工作流里的 LLM 出错后：保留可执行的最小路径

工作流里的 LLM 出错后保留可执行的最小路径1. 模型输出格式异常时工作流如何保持可恢复在生产环境把 LLM 接入工作流自动化系统后工程师遇到的最大难题绝不是提示词工程Prompt Engineering怎么写而是模型的非确定性Nondeterminism。结构化提取任务可能因特殊字符或输出截断得到不完整 JSON。下游直接调用JSON.parse()会失败因此需要把解析、校验、重试和人工/规则降级设计为可恢复路径。还有更棘手的场景模型在 Tool Calling 阶段输出了不存在的函数参数、或者 API 供应商突发网络超时、亦或是模型触发了安全风控返回了拒绝语句。试图通过修改 Prompt“请务必严格返回 JSON不要带有任何额外文字”来解决问题在生产环境完全是自欺欺人。用确定性的软件工程体系来包覆和治理非确定性的 LLM 输出才是落地智能工作流的唯一出路。flowchart TD Req[Start LLM Task Workflow] -- PrimaryModel[Call Primary LLM] PrimaryModel -- ResponseCheck{HTTP / Network OK?} ResponseCheck -- Timeout/Error -- SecondaryModel[Fallback to Light/Backup LLM] ResponseCheck -- OK -- SchemaCheck{Validate Zod Schema} SchemaCheck -- Valid -- Complete[Return Valid Result] SchemaCheck -- Invalid -- AutoRepair[Attempt JSON Auto-Repair] AutoRepair -- RepairCheck{Repaired Schema Valid?} RepairCheck -- Yes -- Complete RepairCheck -- No -- SecondaryModel SecondaryModel -- SecSchemaCheck{Validate Secondary Schema} SecSchemaCheck -- Valid -- Complete SecSchemaCheck -- Invalid -- RuleEngine[Execute Deterministic Rule Engine] RuleEngine -- RuleCheck{Rule Engine Handled?} RuleCheck -- Yes -- FallbackResult[Return Rule Engine Fallback Result] RuleCheck -- No -- HITL[Enqueue Human-in-the-loop Review]2. 确定性软件工程治理非确定性 LLM多级降级阶梯Fallback Ladder为了防范 LLM 随时可能发生的异常必须在工作流内核中设计一套降级阶梯Fallback Ladder。降级阶梯分为五层按顺序逐级兜底第一层结构化 Schema 自动修复Auto-repair当模型返回的 JSON 存在语法瑕疵如缺失引号、末尾多逗号、包裹了 Markdown 代码块标记json时不应该立即放弃而是通过确定性的正则或轻量语法树工具进行自动剥离与闭合修正。第二层重试与提示词自动纠错Feedback Loop Retry如果自动修复失败将校验器抛出的具体错误信息如Field age is required but missing作为上下文自动拼接回 Prompt 中重新发起一次请求给模型自我纠错的机会。第三层模型切流降级Model Switching Fallback当主模型如 高参数模型频繁超时、500 报错或者连续校验失败时快速将请求切流至备用模型如 轻量化开源模型或小参数模型。第四层确定性规则引擎兜底Deterministic Rule Engine当所有 LLM 节点均失效时降级到基于传统正则表达式、关键词提取或硬编码逻辑的规则引擎牺牲一定的智能度换取 100% 的系统可用性。第五层人机协作队列Human-in-the-Loop如果规则引擎依然无法处理将任务打包写入人工审核队列触发钉钉/飞书告警由人工干预后继续推进后续流程。3. Schema 自动修复、模型切流与规则引擎兜底设计在降级阶梯的落地中Zod 或 JSON Schema 校验器充当了最重要的“安全闸门”。绝不能把any或未校验的 LLM 输出直接透传给下一个业务节点。所有的 API Response 必须在出口处经过严格的类型断言。同时必须给每一个 LLM 调用设置硬性 Timeout例如 15 秒和 Token 消费预算限制。防止模型在 Tool Calling 环节陷入死循环白白消耗大量的 API 费用。4. 生产级 TypeScript LLM 多级自动降级与状态机回路下面是基于 TypeScript 实现的生产级 LLM 智能工作流降级框架。集成了 JSON 自动修复、Zod Schema 校验、备用模型切流以及规则引擎兜底。import { z } from zod // 1. 定义期望的结构化数据 Schema export const ExtractResultSchema z.object({ title: z.string().min(1, 标题不能为空), category: z.enum([tech, finance, life, other]), keywords: z.array(z.string()).max(5), confidenceScore: z.number().min(0).max(1) }) export type ExtractResult z.infertypeof ExtractResultSchema export interface LLMProvider { name: string complete(prompt: string): Promisestring } export class RobustLLMWorkflowPipeline { constructor( private primaryLLM: LLMProvider, private secondaryLLM: LLMProvider ) {} // 极简 JSON 语法自动修复器 private attemptJsonRepair(rawText: string): string { let cleaned rawText.trim() // 移除 markdown 代码块标记 cleaned cleaned.replace(/^json\s*/i, ).replace(/^\s*/, ).replace(/$/, ) // 补齐因截断缺少的右花括号 const openBraces (cleaned.match(/\{/g) || []).length const closeBraces (cleaned.match(/\}/g) || []).length if (openBraces closeBraces) { cleaned }.repeat(openBraces - closeBraces) } return cleaned } // 规则引擎兜底方案 private executeRuleEngineFallback(inputText: string): ExtractResult { console.warn([Fallback] 触发最底层的确定性规则引擎兜底) return { title: inputText.slice(0, 20) || 默认无标题, category: other, keywords: [兜底规则], confidenceScore: 0.1 } } // 运行带降级阶梯的完整工作流 public async process(inputText: string): PromiseExtractResult { const prompt 请分析以下文本并按格式输出 JSON: ${inputText} // ----- 尝试 1: 主模型调用 ----- try { console.log([LLM] 调用主模型: ${this.primaryLLM.name}) const rawResponse await this.primaryLLM.complete(prompt) // 1.1 直接校验 try { const json JSON.parse(rawResponse) return ExtractResultSchema.parse(json) } catch (parseErr) { console.warn([LLM] 主模型原始响应校验失败尝试自动修复 JSON...) // 1.2 自动修复后重新校验 const repaired this.attemptJsonRepair(rawResponse) const json JSON.parse(repaired) return ExtractResultSchema.parse(json) } } catch (primaryErr: any) { console.error([Error] 主模型处理失败: ${primaryErr.message}开启备用模型降级...) } // ----- 尝试 2: 备用轻量模型切流 ----- try { console.log([LLM] 调用备用模型: ${this.secondaryLLM.name}) const rawResponse await this.secondaryLLM.complete(prompt) const repaired this.attemptJsonRepair(rawResponse) const json JSON.parse(repaired) return ExtractResultSchema.parse(json) } catch (secondaryErr: any) { console.error([Error] 备用模型处理失败: ${secondaryErr.message}准备降级至规则引擎...) } // ----- 尝试 3: 确定性规则引擎硬编码兜底 ----- return this.executeRuleEngineFallback(inputText) } } // Mock 提供者演示 class MockLLM implements LLMProvider { constructor(public name: string, private shouldFail: boolean, private mockOutput: string) {} async complete(prompt: string): Promisestring { if (this.shouldFail) { throw new Error(Provider ${this.name} connection timeout) } return this.mockOutput } } export async function runWorkflowDemo() { // 模拟主模型返回损坏的 JSON备用模型正常 const primary new MockLLM(GPT-4-Main, true, ) const secondary new MockLLM(Claude-3-Backup, false, json\n{title: 智能降级设计, category: tech, keywords: [LLM, 架构], confidenceScore: 0.95}\n) const pipeline new RobustLLMWorkflowPipeline(primary, secondary) const result await pipeline.process(测试输入文本) console.log( 工作流最终输出:, result) }5. 监控告警与人机协作Human-in-the-loop防线在生产环境引入降级阶梯后绝不能让“悄悄降级”掩盖了上游模型的异常。必须在可观测性平台如 Grafana / Datadog中对每一层的降级频率进行埋点监控Level 1 (Auto-repair Rate)反映模型输出格式问题的严重程度。Level 3 (Model Fallback Rate)反映 API 供应商的网络可用性。Level 4 (Rule Engine Rate)直接触发 P2 级告警提示模型输出质量严重下滑。只有用软件工程的确定性防线将非确定性的 LLM 妥善包裹智能工作流才能真正从“实验室 Demo”走向“7x24 小时高可用的生产系统”。