背景

很多人刚接入 Spring AI 时，最先感受到的不是“功能太难做”，而是“结果不稳定”。同样的问题，昨天能答对，今天却开始跑偏；有时会调用工具，有时又直接自己回答。

我后来发现，这类问题通常不是某一个点出错，而是 Prompt、模型参数和工具描述一起影响了最终表现。

先接受一个现实：稳定性不是默认送你的

传统接口开发里，输入相同、输出相同是默认预期；但到大模型场景里，如果你没有做好约束，结果波动是常态。

所以我的思路不是先问“为什么不稳定”，而是先问：

• 模型到底被要求做什么
• 是否给了足够清晰的边界
• 是否提供了稳定的外部工具和数据来源

第一层：Prompt 是否同时承担了太多任务

很多系统 Prompt 一上来就堆很多要求：既要专业、又要友好、还要严格按格式、还要主动调用工具、还要总结结论。问题是，当一个提示承担太多职责时，模型容易顾此失彼。

我更倾向于把 Prompt 的核心目标收敛成三件事：

• 明确角色和任务范围
• 明确什么时候必须调用工具
• 明确输出格式和禁止项

越到工程场景，Prompt 越需要约束性，而不是文学性。

第二层：模型参数会影响波动程度

很多结果不稳定，并不是“模型突然变差”，而是参数配置本身就允许它波动很大。

排查时我重点看：

• temperature 是否过高
• top_p 是否过于开放
• max tokens 是否导致回答被截断
• 是否存在自动重试后结果不一致

如果目标是业务稳定性，参数通常应该更保守一些。

第三层：工具描述和输入结构是否清晰

当系统需要调用工具时，工具定义本身就是 Prompt 的一部分。如果工具描述含糊、参数命名不直观，模型的行为就容易摇摆。

比如“queryData”这种名字看着通用，实际对模型帮助不大；相比之下，明确说明“根据用户编号查询最近三个月订单信息”会稳定得多。

我后来怎么做收敛

为了减少波动，我做过几件比较实际的事情：

1. 把系统 Prompt 缩短，去掉彼此冲突的要求
2. 对需要稳定输出的接口降低随机性参数
3. 给工具补更具体的用途和参数说明
4. 在关键场景增加 few-shot 示例
5. 给异常输出补分类日志，而不是只看最终文本

这些动作不一定都复杂，但叠加起来很有用。

总结

Spring AI 结果不稳定，很多时候不是框架问题，而是约束条件还不够稳定。Prompt、模型参数、工具描述这三层只要有一层比较松，最终表现就容易波动。

工程场景里，想要稳定结果，靠的不是“多试几次”，而是把可控因素一点点收紧。