系列导航 ：上一篇：业务智能体实战笔记（二）｜前置拦截：别让 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 -->|未命中| HLLM 基于路由层选工具 G --> I H --> I I --> JLLM 推理 + 工具调用
工具的选择和调用是两个阶段，信息也分两层：路由层只放名称和一句话概述,在路由时，不会占太长上下文；执行层放完整 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 AIReactAgent业务智能体LLM调优工具调用提示词工程Agent工程化准确率优化