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

系列导航：上一篇：业务智能体实战笔记（三）：收窄 LLM 决策空间 | 下一篇预告：确定性判定与评测闭环
阅读提示：本文是智能体准确率优化系列第四篇，聚焦四层优化链路的第三层兜底修复。前置拦截、收窄空间、确定性判定相关内容本文不再重复介绍。

概述

前置拦截、收窄空间等措施虽然已经大幅压缩LLM的决策范围，但模型的输出仍会存在异常（例如：明明有数据，输出却说没有数据）。
兜底修复的核心思路是后置纠错，分为工具加强、响应验证、双时间字段补跑三部分。
整体可提升5~9个百分点指标，更大价值是把零散线上报错转为自动化流程。文中也会分享「值改写」这个踩坑反面案例。

一、算兜底修复

兜底修复和前两层优化的发生位置不同：前置拦截提前阻断模型决策，收窄空间缩小工具选择范围，兜底修复在模型输出后执行纠错。
兜底修复仅能捕获带有明显异常特征的输出；否则无法生效，需依靠前置规则拦截。

二、工具加强

企业MCP第三方工具可能存在缺陷：字段规范错误、功能描述模糊、隐藏依赖未标注。
第三篇介绍的工具注册负责解决「工具如何筛选」，工具加强则解决「选中后如何正确调用」，下面四项优化均在原始工具信息基础上补充。

分离注册信息和调用信息

注册信息简洁轻量化，用于工具筛选；调用信息完整详尽，用于实际请求执行，两类配置分开维护。

自定义属性纠错

保留工具原生字段，额外扩展自定义属性用于修正、补充原始配置。即便第三方工具迭代升级，预设的修正规则也不会丢失。
落地踩坑场景：

1. 部分MCP工具将全部参数标记为必填，LLM会凭空生成无意义参数；
2. 工具文档缺失前置依赖、使用限制等关键说明；
3. 目前为止，Spring AI未将outputSchema提供给LLM，LLM只能猜测返回数据结构。

规则绑定到工具属性上

工具和配套校验规则天然绑定。如果把规则统一放在全局配置，修改工具时需要跨文件同步，容易产生遗漏、冲突。
这和第三篇向量嵌入的设计思路一致：强耦合的逻辑不要人为拆开。

参数校验

链路拦截三类参数异常：

1. 漏传参数：缺失时间过滤等条件会返回全量数据，，造成结果膨胀，需要前后端双向校验；
2. 模型自动追加冗余条件：有些情况下，LLM会莫名其妙的自动添加无关过滤，导致查询范围缩小，需要后端识别并剔除多余参数；
3. 文本与系统内部标识不匹配：用户说「X」，系统里存的却是 Y，LLM 无法自行对应。后端映射无法完全解决，第三节单独讲。

三、反例：后端映射越界

后端映射属于特定场景处理，虽然现在仍保留少量后端映射逻辑，但不会新增同类规则，存量也计划逐步下线。
实现逻辑：后端转换用户输入文本为第三方业务系统术语，降低用户使用门槛。
方案存在缺陷：后端直接替用户文本映射，用户输入「X组」，意图可能是精确匹配，也可能是模糊分组。模糊分组时，后端自动转换后，不会告知用户映射关系。一旦映射出错，用户无法定位根因，只会认为查询结果有误。
相比准确率指标小幅波动，用户无法追溯自身查询意图是更大的损失。合理处理方式有两种：

1. 请求预处理阶段提前和用户确认筛选口径；
2. 返回结果交还用户确认。

四、响应验证

即便搭配完善提示词，LLM 依旧可能失控，需要代码层兜底校验，分两层处理。

双层防线

1. 提示词约束：禁止输出「我将调用工具」这类过渡话术，禁止虚构 taskId、executionId 等标识，这一层可拦截大部分异常；
2. 代码校验：提示词不具备强制约束力，模型仍可能失控。

第一类：虚假工具调用

模型未发起工具请求，仅输出类似(工具名(status=0, groupBy='none'))的伪代码文本，三条规则同时命中才判定异常、触发重试。

# 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%，但这是正常产出——会误触发校验。

三条规则组合，才能精准识别「未调用工具、无有效思考、内容简短」的无效回复。
阈值设计逻辑：

1. 200 字符：正常结果反馈通常 100–300 字，长篇分析远超 200，异常复读通常几十字，200 是中间缓冲；
2. 40% 匹配占比：正常引用原文 10–25%，异常整段照搬在 60% 以上，40% 是中间安全带；
3. toolResult 为空：二元硬标准，直接判定是否真实调用工具。
   后续如果出现长篇复读这类新异常形态，可基于标注样本分位数重新调整阈值。

第二类：假阴性

工具正常返回数据，但模型回复无查询结果，复用上述判定逻辑执行重试。

第三类：图表数据前端静默对齐

模型生成图表时，标签、数值数组长度时常不一致。该场景无法搭建重试闭环，仅在前端做兼容处理：数组按最短长度截断、缺失值补0、仅修复尾部残缺JSON。
选择静默兼容而非重试的原因：重复调用会增加接口开销、结果抖动不可控；且前端无真值，只能修复结构，无法校验数值对错。截断至少确定，重跑是赌。
JSON修复边界：仅补齐括号、引号等尾部残缺；中间字段大面积缺失时放弃修复，原文交给上层做降级处理。

这是一处没做闭环的坑。如实写出来，不包装成「多层校验」。

二次调用设计思路

重试提示会明确告知模型上一轮输出格式错误，要求使用标准 tool_call 协议，附带原始用户请求。全局仅允许重试一次，避免死循环，代价是放弃了多次修复的可能性。
后续优化方向：

1. tool_choice配置为required/any，要求模型必须调用工具；
2. 首次采样温度较高时，重试切换为确定性生成（temperature=0）。

优化收益

响应验证单独提升约2个点，核心价值是把随机报错转为可观测、可回归、可迭代的标准化异常。

五、双时间字段：加法式补跑

工单场景存在创建、完成两套统计口径，用户模糊提问时模型极易选错过滤条件。
后端在满足三项条件时自动补跑一轮查询：调用工单统计工具、传入起止时间、返回聚合数据（条数≤10）。分别按创建、完成时间查询，两份结果统一交给模型整理展示，系统不提前替用户筛选口径。
该机制和前置状态拦截形成镜像对比：

六、三种兜底手段横向对比

七、兜底修复的能力边界

即便前置、收窄两层规则层层约束，LLM仍会出现异常，兜底必不可少，但存在明显短板：

1. 仅能识别格式异常，无法判断业务数字是否真实准确；
2. 图表只能修复结构，不能校验数值正确性；
3. 无法感知底层工具返回脏数据；
4. 无明显特征的逻辑错误，只能前置拦截。
   以上场景，需要第四层「确定性判定」方案，由确定性代码校验，不再经过模型。

收益汇总

下一篇预告

第五篇详解确定性判定与评测闭环：

1. data_filter五大原子操作、三条业务约束，让数据处理不再依赖模型；
2. 复杂场景优先硬编码而非规则引擎的设计原因；
3. 评测真值集搭建、数值容差、Python离线打分完整方案。
   能用固定代码完成判定，就不要依赖概率模型输出结果。整套优化体系里，评测闭环是我复盘后感受最深的模块，如果重新规划迭代，会从这里开始。

互动提问：大家落地兜底相关逻辑时，有没有设计过牺牲透明度换取短期指标的方案？这类优化短期提分，但用户看不到系统转换逻辑，长期会降低产品可信度。