业务智能体实战笔记：兜底修复——LLM 错了怎么救

系列导航上一篇业务智能体实战笔记三收窄 LLM 决策空间 | 下一篇预告确定性判定与评测闭环阅读提示本文是智能体准确率优化系列第四篇聚焦四层优化链路的第三层兜底修复。前置拦截、收窄空间、确定性判定相关内容本文不再重复介绍。文章目录概述一、算兜底修复二、工具加强分离注册信息和调用信息自定义属性纠错规则绑定到工具属性上参数校验三、反例后端映射越界四、响应验证双层防线第一类虚假工具调用第二类假阴性第三类图表数据前端静默对齐二次调用设计思路优化收益五、双时间字段加法式补跑六、三种兜底手段横向对比七、兜底修复的能力边界收益汇总下一篇预告概述前置拦截、收窄空间等措施虽然已经大幅压缩LLM的决策范围但模型的输出仍会存在异常例如明明有数据输出却说没有数据。兜底修复的核心思路是后置纠错分为工具加强、响应验证、双时间字段补跑三部分。整体可提升5~9个百分点指标更大价值是把零散线上报错转为自动化流程。文中也会分享「值改写」这个踩坑反面案例。一、算兜底修复兜底修复和前两层优化的发生位置不同前置拦截提前阻断模型决策收窄空间缩小工具选择范围兜底修复在模型输出后执行纠错。兜底修复仅能捕获带有明显异常特征的输出否则无法生效需依靠前置规则拦截。二、工具加强企业MCP第三方工具可能存在缺陷字段规范错误、功能描述模糊、隐藏依赖未标注。第三篇介绍的工具注册负责解决「工具如何筛选」工具加强则解决「选中后如何正确调用」下面四项优化均在原始工具信息基础上补充。分离注册信息和调用信息注册信息简洁轻量化用于工具筛选调用信息完整详尽用于实际请求执行两类配置分开维护。自定义属性纠错保留工具原生字段额外扩展自定义属性用于修正、补充原始配置。即便第三方工具迭代升级预设的修正规则也不会丢失。落地踩坑场景部分MCP工具将全部参数标记为必填LLM会凭空生成无意义参数工具文档缺失前置依赖、使用限制等关键说明目前为止Spring AI未将outputSchema提供给LLMLLM只能猜测返回数据结构。规则绑定到工具属性上工具和配套校验规则天然绑定。如果把规则统一放在全局配置修改工具时需要跨文件同步容易产生遗漏、冲突。这和第三篇向量嵌入的设计思路一致强耦合的逻辑不要人为拆开。参数校验链路拦截三类参数异常漏传参数缺失时间过滤等条件会返回全量数据造成结果膨胀需要前后端双向校验模型自动追加冗余条件有些情况下LLM会莫名其妙的自动添加无关过滤导致查询范围缩小需要后端识别并剔除多余参数文本与系统内部标识不匹配用户说「X」系统里存的却是 YLLM 无法自行对应。后端映射无法完全解决第三节单独讲。三、反例后端映射越界后端映射属于特定场景处理虽然现在仍保留少量后端映射逻辑但不会新增同类规则存量也计划逐步下线。实现逻辑后端转换用户输入文本为第三方业务系统术语降低用户使用门槛。方案存在缺陷后端直接替用户文本映射用户输入「X组」意图可能是精确匹配也可能是模糊分组。模糊分组时后端自动转换后不会告知用户映射关系。一旦映射出错用户无法定位根因只会认为查询结果有误。相比准确率指标小幅波动用户无法追溯自身查询意图是更大的损失。合理处理方式有两种请求预处理阶段提前和用户确认筛选口径返回结果交还用户确认。四、响应验证即便搭配完善提示词LLM 依旧可能失控需要代码层兜底校验分两层处理。双层防线提示词约束禁止输出「我将调用工具」这类过渡话术禁止虚构 taskId、executionId 等标识这一层可拦截大部分异常代码校验提示词不具备强制约束力模型仍可能失控。第一类虚假工具调用模型未发起工具请求仅输出类似(工具名(status0, groupBynone))的伪代码文本三条规则同时命中才判定异常、触发重试。# PATTERN匹配「工具名(参数)」这类工具调用表达式 PATTERN 匹配「工具名(参数)」格式正则 function isPseudocodeResponse(response): if response 为空: return false if response 长度 200 字符: return false matched PATTERN 匹配 response 的首个片段 if matched 不存在: return false if matched 长度 / response 长度 40%: return false 外层判断本次 toolResult 为空逐条拆分单规则的误判场景仅校验短文本高匹配、不判断 toolResult工具正常执行后模型回「已按字段 A/B/C 更新完毕」字符短、复述了大量用户原话但 toolResult 非空说明真调了工具——会被误拦截。仅校验短文本空 tool、不判断匹配占比「好的理解了」「这个字段你指的是 order_id」这类短对话是常态——会被误判。仅校验高匹配空 tool、不限制长度需求梳理、方案输出时大量引用用户诉求占比可能超 40%但这是正常产出——会误触发校验。三条规则组合才能精准识别「未调用工具、无有效思考、内容简短」的无效回复。阈值设计逻辑200 字符正常结果反馈通常 100–300 字长篇分析远超 200异常复读通常几十字200 是中间缓冲40% 匹配占比正常引用原文 10–25%异常整段照搬在 60% 以上40% 是中间安全带toolResult 为空二元硬标准直接判定是否真实调用工具。后续如果出现长篇复读这类新异常形态可基于标注样本分位数重新调整阈值。第二类假阴性工具正常返回数据但模型回复无查询结果复用上述判定逻辑执行重试。第三类图表数据前端静默对齐模型生成图表时标签、数值数组长度时常不一致。该场景无法搭建重试闭环仅在前端做兼容处理数组按最短长度截断、缺失值补0、仅修复尾部残缺JSON。选择静默兼容而非重试的原因重复调用会增加接口开销、结果抖动不可控且前端无真值只能修复结构无法校验数值对错。截断至少确定重跑是赌。JSON修复边界仅补齐括号、引号等尾部残缺中间字段大面积缺失时放弃修复原文交给上层做降级处理。这是一处没做闭环的坑。如实写出来不包装成「多层校验」。二次调用设计思路重试提示会明确告知模型上一轮输出格式错误要求使用标准 tool_call 协议附带原始用户请求。全局仅允许重试一次避免死循环代价是放弃了多次修复的可能性。后续优化方向tool_choice配置为required/any要求模型必须调用工具首次采样温度较高时重试切换为确定性生成temperature0。优化收益响应验证单独提升约2个点核心价值是把随机报错转为可观测、可回归、可迭代的标准化异常。五、双时间字段加法式补跑工单场景存在创建、完成两套统计口径用户模糊提问时模型极易选错过滤条件。后端在满足三项条件时自动补跑一轮查询调用工单统计工具、传入起止时间、返回聚合数据条数≤10。分别按创建、完成时间查询两份结果统一交给模型整理展示系统不提前替用户筛选口径。该机制和前置状态拦截形成镜像对比类型执行时机处理逻辑状态拦截第二篇工具选择前减法剔除无关工具双时间补跑工具调用后加法补充另一口径数据二者均为业务硬约束但执行时机、处理逻辑差异较大无法复用同一套通用逻辑。六、三种兜底手段横向对比工具加强响应验证双时间补跑触发阶段LLM调用工具前LLM输出文本后解决问题工具配置残缺、参数错误伪调用、假阴性、图表结构错乱处理方式补充配置前置参数校验代码识别异常重试/前端兼容能力局限无法识别工具返回错误业务数据无法校验业务数值对错七、兜底修复的能力边界即便前置、收窄两层规则层层约束LLM仍会出现异常兜底必不可少但存在明显短板仅能识别格式异常无法判断业务数字是否真实准确图表只能修复结构不能校验数值正确性无法感知底层工具返回脏数据无明显特征的逻辑错误只能前置拦截。以上场景需要第四层「确定性判定」方案由确定性代码校验不再经过模型。收益汇总优化手段指标提升工具加强3 ~ 5pt响应验证~2pt双时间含前置状态拦截2 ~ 4pt兜底修复整体5 ~ 9pt工具注册加工具加强是整条优化链路收益第二高的模块仅次于第五篇数据过滤方案。下一篇预告第五篇详解确定性判定与评测闭环data_filter五大原子操作、三条业务约束让数据处理不再依赖模型复杂场景优先硬编码而非规则引擎的设计原因评测真值集搭建、数值容差、Python离线打分完整方案。能用固定代码完成判定就不要依赖概率模型输出结果。整套优化体系里评测闭环是我复盘后感受最深的模块如果重新规划迭代会从这里开始。互动提问大家落地兜底相关逻辑时有没有设计过牺牲透明度换取短期指标的方案这类优化短期提分但用户看不到系统转换逻辑长期会降低产品可信度。