业务智能体实战笔记（三）：收窄 LLM 决策空间

系列导航：上一篇：业务智能体实战笔记（二）｜前置拦截：别让 LLM 做不该做的决策 | 下一篇（预告）：兜底修复 LLM 异常（持续更新）

阅读提示：这是「业务智能体准确率从 65% 到 85%」系列的第三篇。首篇讲主线和全景，本篇是四层方法论的第二层——收窄 LLM 决策空间。四篇预备篇章相互独立可跳读，建议先看首篇了解全貌。

@

目录

概述

这一层做四件事：提示词工程、采样参数收窄、业务数据预加载、工具信息分层注册。

本层是前篇「前置拦截」的进一步延续：不剥夺 LLM 决策权，仅提前压缩工具、参数、上下文的候选范围，缩小模型容易出错的选择面，降低失稳概率。

一、「收窄决策空间」收窄的是什么

保留 LLM 的决策权--LLM 负责工具选择、语义理解、答案组织。在LLM决策前，工程侧压缩候选集、参数、上下文。

这一层的主线是LLM 决策空间越小，行为越稳定。

二、提示词工程：能力有边界

遇到准确性问题，第一反应是改提示词。我们的提示词分几类，大部分是预置固定的，我只改业务系统提示词。
为同类问题添加规则、正反示例和 CoT 模板。提示词打磨用了 Claude Code、Codex、Trae 几个工具轮流试。几轮下来效果明显，65% 涨到 75%。
但规则越多、越细、场景越特殊，效果越差——最后几次升级效果不明显，甚至下降。规则太多，LLM 的注意力被稀释，很多场景下，规则没有按预期的执行。
来来回回很多次，认清了两件事：没有评测闭环的调优就是猜谜（第 5 篇会展开）；修改提示词有收益边界，不能过度依赖。
提示词能做的大概 +5~+8pt（估算，当时还没搭评测闭环，跟同期收采样、做消息预处理的动作混在一起，拆不准）。

三、收窄采样参数

业界提高准确率的一个通用做法是调整温度和 top_p。先按业界经验值起步（0.6/0.7），再基于评测数据继续收（0.3/0.1）。

业界常见 temperature 区间：

  • 查询报表类：0.1–0.3
  • 业务对话：0.4–0.6
  • 创意发散：0.7–0.9

最开始按惯例采用 0.6/0.7。评测闭环搭起来之后，做了两次针对采样的调优：

参数 调整前 调整后 说明
temperature 0.6 0.3 收窄概率分布
top_p 0.7 0.1 只保留最高概率的前 10% token
parallelToolCalls 未显式设置 false 禁止单轮内并行 tool_call
presencePenalty 未显式设置 0 贴着已检索内容回答，不鼓励换话题

调整参数的效果很好：0.3/0.1 比 0.6/0.7 更稳。

采样收窄贡献约 +2~+4pt。

四、数据预加载

用户常见的业务数据，对模型来说是陌生的——存储在数据库中的工单、任务、业务组等。
这些数据随业务变动，不适合放进 RAG。写进提示词也不行，术语越多提示词越大，数据一变整段跟着改。
所以直接在创建智能体时从数据库预加载。只读 id 和 name，不带 description 和扩展属性。每类数据超过 100 条做规则截断，防止上下文膨胀、注意力稀释。
预加载失败则跳过，不阻塞启动——链路必须在没有它的情况下正常工作。用户查某个设备详情时，最新数据顺路刷新预加载里的对应条目，自动纠正陈旧问题。
贡献约 +1~+3pt。间接收益比分数更重要——后面的意图识别、消歧、工具选择都有稳定的业务词表可以参照。

五、工具信息分层注册

开始，业务智能体每次只加载 5 个工具，LLM 的选择受到限制，经常选错。当前做法是按工具总数分两档：

档位 触发条件 路由方式 工具信息加载
第一档 工具总数 ≤ 20 全量注册给 LLM 路由层全量看，执行层命中后加载
第二档 工具总数 > 20 两阶段意图路由，LLM 从目录挑 4~8 个候选 路由层只看候选，执行层命中后加载
flowchart TD A[用户请求] --> B{工具总数} B -->|≤ 20| C[全量加载路由层] C --> I[加载执行层 schema] B -->|> 20| D[意图路由挑 4~8 个候选] D --> E[加载候选工具路由层] E --> F{正则旁路匹配?} F -->|命中| G[跳过路由筛选，保留全量] F -->|未命中| H[LLM 基于路由层选工具] G --> I H --> I I --> J[LLM 推理 + 工具调用]

工具的选择和调用是两个阶段，信息也分两层：路由层只放名称和一句话概述,在路由时，不会占太长上下文；执行层放完整 schema，命中后才加载，执行层信息全面有利于调用准确。执行层除了schema，也存储对该工具有效的规则，这写规则针对性强，容易被遵守。
两阶段路由不是万能的，某些多维度统计类问题会挑错工具。留了一个正则旁路开关，发现哪类问句容易挑错就补一条规则把它拦到旁路，跳过路由筛选保留全量工具。

当前两档已覆盖到接近 50 个工具的规模。再往上，LLM 在 50 多个工具的目录里挑 4~8 个，漏选和错选都会抬头。下一步规划用 RAG 检索替代 LLM 挑候选，而不是 embedding 检索——embedding
跟工具描述耦合太紧，描述改一个字索引就得重跑，工具集一调整索引永远追着业务跑。RAG 是显式的、可解释的、和描述解耦的。

贡献约 +3~+5pt，收益来自两处：减少选错工具（分层描述 + 旁路开关），减少参数错误（执行层 schema 命中后才注入，不干扰路由决策）。

六、工具调用的串行策略

ReAct 循环让每一步基于上一步返回值再决策，轮与轮之间天然串行。关掉 parallelToolCalls，单轮只走一个工具。
另一种串行：将工具调用拆成查询和筛选两步。先获取查询结果，再识别筛选条件，调用 data_filter 完成筛选。data_filter 的完整设计放第 5 篇。

七、收益与限制

手段 贡献区间 关键动作
提示词工程 +5~+8pt 收敛为规则清单
采样参数收窄 +2~+4pt temp/top_p 0.6/0.7 → 0.3/0.1
数据预加载 +1~+3pt 数据库直读 id+name，100 条截断
工具信息分层注册 +3~+5pt 两档路由 + 分层描述 + 旁路开关
合计 +9~+16pt 65% → 75% 第一阶段涨幅

⚠️ 四个模块同期推进，数字是事后拆开归因的估算，不能简单累加。

这一层的核心逻辑始终是同一件事：压 LLM 的决策空间，提高行为稳定性。但候选集压到最小，LLM 行为失稳的概率也压不到零。剩下的失稳，只能靠第三层「兜底修复」事后判定加纠错。

下一篇预告

第 4 篇讲兜底：工具加强（自定义字段纠错、参数校验的三种典型错法、值改写为什么后悔做了）、响应验证（伪代码检测的三条件为什么必须同时命中、200 字符和 40% 匹配率两个阈值怎么定的、图表数据静默对齐为什么没做成闭环）、双时间字段的加法式补跑。

关键判断：再压再挡 LLM 还是会失稳，你得有兜底。这一篇会讲一个反例——「值改写」是我做过、事后觉得越界的一件事，比精度损失更严重的是透明度损失。

如果你在压决策空间的时候踩过「再压就翻车」的线——那个临界点在哪，是我最想知道的经验。

标签：Spring AI ReactAgent 业务智能体 LLM调优 工具调用 提示词工程 Agent工程化 准确率优化

posted @ 2026-07-20 08:51  荣--  阅读(147)  评论(0)    收藏  举报