结论先说准确率从 65% 提升到 85%,三四周,由我独立完成。核心思路——把不确定性从 LLM 侧转移到工程侧。这不是事后总结,是多次迭代提示词、发现收益递减后,形成的整套调优思路;它覆盖全部 11 个模块,可拆分为四层逻辑:前置拦截 LLM、收窄 LLM 决策空间、兜底修复 LLM 异常、完全脱离 LLM 的确定性判定;后续 4 篇会分层讲解,本篇只讲主线、架构、收益全景,和最后悔的一件事。收益最大:LLM 不擅长结构化数据处理,通过 data_filter 将全部结构化运算迁移至工程侧,单项提升 10pt 以上。最后悔:评测闭环搭建太晚,搭建后迭代节奏清晰,前期无量化调优浪费大量时间。这两点正文会详细展开。背景我们的 AI 基础能力平台接入了各家主流 LLM,产出各类 AI 能力,包括通用业务智能体。业务智能体与运维业务结合落地时,发现准确率低,低到没法交付。我独立承担了提升业务智能体准确率这项任务,三四周,准确率从 65% 提升到 85% 以上。业务实际使用 Qwen,底层框架是 Spring AI Alibaba 的 ReactAgent。下面交代评测集、打分口径、时间跨度三件事,作为全文的可信度地基。评测集:分智能体独立维护的真值集——智能体 A 覆盖工单场景多类统计意图,智能体 B 覆盖巡检场景多类查询意图。打分口径:端到端任务完成率——意图识别 → 工具调用 → 答案组织,三段都对才算对。这个分不是我自己打的——独立测试人员做的全面端到端测试,外挂 Python 评测脚本提供数据支撑,人和工具协作打出的最终验收分。为什么按 85% 报:实际准确率在 85% 以上、部分场景到 95%,但其中一部分是特定场景硬约束贡献的——能过评测集,但换个数据分布不一定稳。按可迁移的下沿报,才对得起读者能否复用。时间跨度:三四周。核心思路:把不确定性从 LLM 侧转移到工程侧所有动作均围绕一条主线:保留 LLM 擅长的语义工作,将它不擅长的处理下沉至工程侧。每遇到一个问题,先问自己——这件事该 LLM 做,还是工程侧做?生成一段自然语言回答 → LLM 侧从上百条工单里数出「已完成」有多少条 → 工程侧把用户口中的「上个月」翻译成 startTime/endTime → LLM 侧判断「上个月」到底指创建时间还是完成时间(业务口径) → 工程侧判断准则还要再加一条:LLM 能做的事,不代表就该让它做。业务智能体这类场景,错答的损失远大于计算成本——能放到工程侧就放到工程侧。四层方法论:全篇的骨架四层是同一条主线在不同环节的具体化,方向不同,意图一致。层次 判断依据 系列篇章一、前置拦截 LLM 在推理前挡住不可靠判断 第 2 篇二、收窄 LLM 决策空间 保留语义决策,收窄候选范围 第 3 篇三、兜底修复 LLM 异常 事后判定异常输出并纠错 第 4 篇四、确定性判定 完全脱离 LLM,交由工程侧执行 第 5 篇第一层:前置拦截 LLM代表动作:消息预处理(业务对象消歧、格式规范化)、两步 RAG 里的前置强制检索、工具选择前的状态歧义拦截。这一层的原则是按事后能否兜底划线:可事后判定和修复的问题,交给后置校验;事后无从识别的问题,必须在推理前拦截。漏检索是典型的后一类——模型基于缺失信息生成看起来完整的回答,响应里没有任何特征让代码判定这次漏了检索。类似地,LLM 虽然支持自主澄清,但慢、贵、不稳三条决定了业务智能体不能把口径确认交给模型自己判断,必须提前统一。第二层:收窄 LLM 决策空间代表动作:提示词工程、采样参数收窄(temperature/top_p 从通用对话挡收到工具调用挡,presence_penalty 归零贴住检索内容)、业务数据预加载、工具信息分层注册。这一层保留 LLM 的决策权,只是压缩它能出错的空间。65% → 75% 的第一阶段红利,主要来自提示词工程 采样收窄 消息预处理三件事的同期动作。但它有天花板——我在提示词上改了 59 版才认清:越写越多、越细、越场景化,智能体反而更不听话。采样这块有一个反直觉的现场,值得在总纲里点一下。一开始我按业界「通用对话」的经验值起步,顾虑是「过锐会失稳、表达机械」。评测闭环搭起来后,把参数收到「工具调用类任务」更收敛的一档——失稳没出现,反而更稳。事后想清楚,是原来的顾虑场景错配了。低温失稳的经验来自创作型任务:答案空间宽、需要多样性。业务智能体恰恰相反:答案空间窄、tool_call 是 JSON 协议、输出是短结论。场景对了,收敛档就是天然更稳的档位。采样层真正做收窄的是三件正交的事:temperature top_p 的双重约束(logits 尖化 词表截断,叠加不是重复),再加 presence_penalty 归零贴住检索内容。至于并行 tool_call 关掉、group 层温度覆盖、响应层规整包装——它们是平台侧的正交能力,和为什么低温稳没有因果关系,不要混进采样的账里。细节和 59 版提示词的坑放在第 3 篇。第三层:兜底修复 LLM 异常代表动作:工具加强(自定义字段纠错、参数校验)、响应验证(伪代码检测、假阴性检测、图表数据静默对齐)、双时间字段的加法式补跑。前两层都是事前——挡在前面或收窄空间。第三层承认一件事:再压再挡,模型仍会出现异常输出,必须有兜底。响应验证里最典型的是「伪代码异常」:模型没真调工具,却直接把工具调用表达式当答案返回给用户,比如输出一行 (某工具名(status0, groupBy‘none’)) 就结束了。我用三个条件同时命中来判定:短( 200 字符) 表达式占比高( 40%) 本次 toolResult 为空——三条同时命中才判异常,少一条都会误伤正常场景。三个阈值来自「异常 短 复读 未执行」的画像,画像变了要重标。这一层的价值不完全体现在分数上——它把非确定性故障从「偶发投诉」降级成「链路自动处理」,可观测、可回归、可迭代,这对交付信心的提升比分数本身重要得多。细节放在第 4 篇。第四层:完全脱离 LLM 的确定性判定代表动作:data_filter(结构化数据处理)、特定场景硬约束(业务口径钉死)、评测闭环(真值集 数值容差)。第四层最纯粹——动作完全脱离 LLM,是主线最深的应用。data_filter 是一个纯 Java 的 ToolCallback,对外只暴露五个原子操作(filter/group_count/sort/count/to_chart);数据不由 LLM 传,而是从 SessionContext 里读——LLM 定「做什么」,工程侧定「怎么算」。这一步同时解决了算错、漏字段、图表乱三类结构化数据错误。评测闭环也在这一层——不走「LLM 当裁判」的主流路线,用真值集加数值容差硬判定。数据库查询的结果是唯一的,能用确定性判定的地方,别请概率过来当裁判。细节放在第 5 篇,也是「最后悔的一件事」所在。全景架构图链路图如下,后 4 篇的模块可在图上定位。图里只保留每个模块动过的关键节点,省略了权限、审计、熔断等与准确率不直接相关的通用组件。工具适配器层ReactAgent 运行时读真值集对齐tool_call结果用户消息消息预处理消歧 · 短路 · 追问第 2 篇数据预加载SessionContext第 3 篇BusinessAgentFactory意图路由 · 旁路开关第 3 篇Hook 链两步 RAG · 硬约束前置第 2 · 5 篇LLM 推理采样收敛 · 串行第 3 篇Interceptor 链响应验证 · 伪代码检测第 4 篇McpAdapter回写 SessionContextSkillAdapterdata_filter5 个原子操作第 5 篇MCP Server · Skill 引擎 · DB前端渲染图表静默对齐第 4 篇外挂 Python 评测真值集打分第 5 篇图里三个高亮:黄色的 data_filter:收益最大的一步,单算 10 分以上蓝色的评测闭环:最后悔搭晚的一件事绿色的 SessionContext:把不确定性从 LLM 侧转移到工程侧的关键载体——工具间流转的数据不进 LLM,只在工程侧流转四层与图上节点的对应:前置拦截 LLM → 消息预处理、Hook 链前置收窄 LLM 决策空间 → 预加载、意图路由、采样参数兜底修复 LLM 异常 → Interceptor 链、前端静默对齐完全脱离 LLM → data_filter、评测闭环收益归因:收益分布在哪些环节按收益段分四段,每段对应四层里的一层或几层。细账留给后 4 篇,首篇只做全景。读表方式先说清楚:下面表里的 Delta 是分开归因的估算值,加总会超过实际 20pt——因为同期动作会被分别计入,不能直接相加。看每一段的相对权重比看加总更有意义。收益段 累计 Delta(估算) 主要对应四层起点红利(65% → 75%) 9 ~ 16pt 第二层:收窄 LLM 决策空间(提示词 采样 消息预处理三件事同期)头部(单模块提升幅度最大) 10pt 以上 第四层:确定性判定(data_filter 单算)腰部(工具处理) 6 ~ 10pt 第二层 第三层(工具注册 工具加强)尾部(每层各压一点) 5 ~ 10pt 第一层 第四层(预加载、两步 RAG、响应验证、硬约束)所有 Delta 均为估算,非精确测量。加总超过 20pt,三个原因:同期动作的 Delta 会重复计入:起点红利里,提示词工程、采样收窄、消息预处理是同期动作,合计对应 65% → 75%。但它们各自那行的 Delta 加起来会超过 10pt,分开归因,加总不能再当独立收益读相互抵消的负 Delta 没进表:比如提示词砍掉场景化那次是负向调整,归入起点红利的净收益里,但表里没单独列一行精确分账靠评测闭环才能做:如果评测闭环早点搭起来,每一行的 Delta 都能压到 ±2pt 以内、加总也能对齐 20pt——这也正是我唯一后悔的一件事每一步的相对权重,比绝对数字更值得关注。按收益排序看:头部:data_filter 单算 10pt——结构化数据处理彻底工程化,是全过程单模块提升幅度最大的一步腰部:工具注册 工具加强合计约 6 ~ 10pt,是收益次高的一段起点红利:提示词工程 采样收窄 消息预处理合计约 9 ~ 16pt,是必要地基,不是重复动作——继续压就撞墙尾部:数据预加载、两步 RAG、响应验证、硬约束各 1 ~ 4pt,单独看都不惊艳,合起来是「每层把不确定性各压一点」的底盘业界看到「提示词 10pt」这种数字要小心:那通常是把预处理、采样、少样本的功劳一起算进去了。单靠提示词能拿到的天花板要保守得多——第 3 篇会展开这段账。最后悔的一件事:评测闭环搭得太晚我用外挂 Python 脚本做真值集回归跑分。这一步我做得太晚——前面几步靠人工观察和感觉调参,浪费了大量时间。有一次教训特别深:砍掉某个提示词后,那类场景准确率反而下降。来来回回反复很多次,我才意识到——没有评测闭环的调优就是猜谜。评测闭环搭起来之后我才想通几件事:正确率提升有了依据:前面每一步的 Delta 不再靠手感,可以直接跑一次量化。这也是为什么起点红利那段的账只能靠事后回忆估算——评测闭环没搭起来,提示词、采样、消息处理三者的功劳只能靠拆解归因,拆不精确迭代周期从数小时缩短到数分钟:改一版跑一遍全量评测集,几分钟出结果,不用人工挨个试防止回退:改一处涨了另一处跌了,人工肉眼看不出来,评测集能立刻发现所以「评测闭环」这一步在系列里是压轴出场,但它不是补丁,是前提条件——前面十步能拿到手的所有 Delta,都建立在评测能量化的基础上。如果重新做一遍,我会先把评测搭起来,再动其他任何东西。这不是感慨,是路径依赖——评测搭起来之后每一步都有据可依,搭之前只能靠感觉。评测闭环本身怎么搭、真值集怎么建、数值容差公式 abs(expect - actual) ≤ max(0.5, expect × 0.5%) 怎么定、为什么不走 LLM 判分,放在第 5 篇——那一篇是本系列的压轴。系列导读后 4 篇按四层方法论分讲,每一篇独立成篇,可以单独看,也可以按顺序追下来。第 2 篇:前置拦截 LLM覆盖:消息预处理(业务对象识别 格式规范化 同步阻塞式消歧)、两步 RAG(前置强制检索替代 Agentic RAG)、工具选择前的状态歧义拦截。关键判断:代码能兜住的决策才优化,兜不住的抢在前面。这一篇会解释「Agentic RAG 为什么听起来聪明实际不可控」——LLM 在「要不要检索」这件事上,行为不可预测,而且响应里看不到「我漏检索了」的信号,没法用代码兜住。第 3 篇:收窄 LLM 决策空间覆盖:提示词工程(59 版的教训、CoT/few-shot/role-play 三件套怎么用)、采样参数收窄(为什么通用对话挡位在业务智能体场景下场景错配、分两轮走的完整故事)、业务数据预加载(为什么不塞 RAG、不塞提示词)、工具信息分层注册(≤20 全量 / 20 两阶段路由 / 50 tag 检索的三档设计)。关键判断:这一层能拿到 65% → 75% 的第一阶段红利,但有天花板。撞墙了别硬撞,别把三个模块的 Delta 一路累加。第 4 篇:兜底修复 LLM 异常