custom provider 的 openai-responses 请求缺少 prompt_cache_key，导致上游/网关缓存无法稳定命中

我这边在 Alma 里使用 custom provider 接 OpenAI-compatible 网关时，发现 openai-responses 请求没有携带 prompt_cache_key，这会导致某些依赖该字段做缓存路由/缓存命中的网关无法稳定命中缓存。 复现环境：

• Alma 版本：0.0.772

• Provider 类型：custom

• baseURL：自定义 OpenAI-compatible 网关

• 使用模型：gpt-5.4 / gpt-5.5

• 请求风格：openai-responses 现象：

• 同样的长上下文请求，有时能命中大量缓存，有时完全 0 命中

• 进一步抓网关侧请求后发现，Alma 发出的 request body 中没有：

  • prompt_cache_key

  • prompt_cache_retention 对比：

• 另一个几乎总能稳定命中缓存的工具，其 request body 中会显式携带：

  • prompt_cache_key: "<stable-session-key>" 例如：

{ "model": "gpt-5.4", "input": [...], "prompt_cache_key": "e54014bb-41fd-486f-89a5-c39e486f3fd4" }

而 Alma 发出的 body 顶层只有类似：

{ "input": [...], "model": "gpt-5.4", "store": false, "tools": [...], "stream": true, "include": ["reasoning.encrypted_content"], "reasoning": {...}, "tool_choice": "auto" }

没有 prompt_cache_key。

一些 OpenAI-compatible 网关/中转会依赖 prompt_cache_key 来识别同一 session / 同一路由缓存域 如果没有这个字段，即使 prompt 前缀相同，也可能因为落到不同上游账号/通道而导致缓存完全不命中

这在 custom provider 场景下尤其明显

建议： 希望 Alma 在 custom provider + openai-responses 场景下支持自动或可配置地注入 prompt_cache_key。

比较理想的方案：

对 openai-responses 请求自动附带稳定的 prompt_cache_key

例如基于 threadId 或基于 providerId + model + threadId 生成稳定 key

最好允许高级用户自定义该行为： 自动生成、手动指定模板、关闭注入