《WaLiSSH - AI Shell 智能终端》第2-9节：缓存命中与推理使用

作者：小傅哥
博客：https://bugstack.cn (opens new window)
视频：https://t.zsxq.com/OXlKJ (opens new window)

沉淀、分享、成长，让自己和他人都能有所收获！😄

大家好，我是技术UP主小傅哥。

上一节，我们已经给 ReAct 装上了长期记忆和数据召回能力。到这里，WaLiSSH 已经不再只是“收到一句话 → 回一句话”那么简单了，它开始有状态、有历史、有工具、有推理过程。

但你如果真的拿这套系统去跑，会马上遇到一个特别现实的问题——AI 很贵，而且越做多轮对话越贵。

为什么？

因为对话一旦复杂起来，请求里带的内容就会越来越多：

• system prompt
• 工具说明
• 历史消息
• 环境信息
• 长期记忆
• 当前任务
• 当前轮用户输入

这些内容不是一次性的，而是每轮都要带。而如果你的上下文组织得不合理，哪怕内容几乎没变，模型也可能把它当成一份“全新的 prompt”重新计算。那结果就是：token 越打越多，响应越来越慢，费用越来越高。

所以这一节我们要解决两个特别核心的问题：

1. 怎么让 AI 对话更容易命中缓存
2. 怎么在需要的时候，把推理能力正确传给模型

注意，这里的“缓存”虽然不是业务代码时的 Redis 缓存，也不是 JVM 本地缓存，但也有类似之处。LLM 缓存是 Prompt Cache / 输入缓存命中——前缀足够稳定时，模型服务端可能复用前面已经处理过的输入片段。所以这里的设计目标，就是在保证上下文清晰准确的情况下，来让前缀更加稳定。

另外还有一个点，是智能体运行时候的推理级别。它在工程里最终会落到一个很具体的参数：reasoning_effort。你开还是不开、开多大、放在哪一层传递，这些都需要清清楚楚地设计。

这一节我们分2步来走；

• 先了解最基础的 API 调用：缓存命中怎么看、推理参数怎么传、最小请求长什么样。
• 再知道课程代码怎么实现：WaLiSSH 是怎么把这些能力接到 AiApiNode、ChatModelNode、PromptService、DynamicPromptBuilder 这一条链上的。

一、本章诉求

本章的目标，是在 walissh-server 工程里，把 AI 对话链路里最关键的两个能力讲清楚并落到代码上：

• 理解 OpenAI 标准协议：明确 POST /v1/chat/completions 的基本请求结构、消息格式、流式返回方式。
• 理解缓存命中原则：让 system prompt、工具说明、历史上下文尽量稳定，动态内容尽量后置，提升 Prompt Cache 命中率。
• 理解 cached_tokens：知道它在 OpenAI usage 结构里的位置，以及如何通过 API 响应观察命中效果。
• 理解 reasoning_effort：知道推理强度的用途、适用场景，以及如何在代码里传递给模型。
• 理解最基本 API 参数：model、messages、stream、stream_options、tools、reasoning_effort 等。

如果说 2-7 是“让 AI 理解用户想干什么”，2-8 是“让 AI 记住发生过什么”，那么 2-9 就是“让 AI 在多轮对话里既省钱、又稳定，而且在关键时候真的会多想一步”。

二、接口调用（API）

这玩意吧，不能一上来就直接调提示词啥的，咱得先搞懂API是怎么调用的。包括；

• 缓存命中到底体现在哪
• 推理参数到底长什么样
• 一个最基础的 OpenAI 请求应该怎么发

所以这一节，先不急着看代码，我们先把 最基础的 API 调用协议 搞明白。