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