fix(agent): skip prompt_cache_key for NVIDIA inference endpoints (fixes #353)

[leo-cheung-itlger]

问题

英伟达免费推理接口（integrate.api.nvidia.com）在 CipherTalk 的 Agent 子系统里调用时报：
400 Unsupported parameter(s): prompt_cache_key

无论用户在设置里选「自定义 OpenAI 兼容端点」填英伟达地址，还是选内置的「英伟达」接口，
只要 baseURL 指向 nvidia.com，都会触发该错误（prompt_cache_key 是 OpenAI prompt-caching 扩展字段，
英伟达接口不认）。

根因

Agent 子系统在 openai-compatible 协议下从两条路径把 prompt_cache_key 塞进请求体：

1. electron/services/agent/provider.ts 的 transformRequestBody（直接改请求体）
2. electron/services/agent/cache.ts 的 buildProviderOptions（经 providerOptions 透传——
   agent 实际请求走这里，所以这是关键修复点）

英伟达接口对这两个字段都不接受，直接 400。

修复

• 新增零依赖模块 electron/services/agent/promptCacheCompat.ts，集中维护「哪些端点不支持
  prompt_cache_key」的判定（isNvidiaInferenceBaseURL 仅匹配 nvidia.com 域名）。
• provider.ts 的 transformRequestBody 与 cache.ts 的 buildProviderOptions 都改为：
  命中英伟达域名时跳过注入，其余 OpenAI 兼容端点完全不变（已用单测验证 OpenAI / DeepSeek /
  火山方舟仍保留 prompt_cache_key）。

范围

• 仅影响 baseURL 指向 nvidia.com 的请求；自定义 OpenAI / DeepSeek / 方舟等端点行为零改动。
• 主聊天路径（非 Agent）原本就不注入 prompt_cache_key，不受影响。

测试

npx tsx scripts/test-nvidia-prompt-cache.ts 通过：

• 英伟达域名下请求体不含 prompt_cache_key；
• OpenAI / DeepSeek / 火山方舟下保留 prompt_cache_key；
• 无 baseURL 时按非英伟达处理（保留）。

真机验证（Verification）

修复已用英伟达真实接口验证（脚本 scripts/e2e-nvidia-proof.ts：直接 import 本 PR 的
promptCacheCompat.ts 生成请求体，再真实 POST 到 integrate.api.nvidia.com/v1/chat/completions）：

测试	模型	请求体是否含 prompt_cache_key	英伟达返回
A 修复后	minimaxai/minimax-m3	否（修复生效）	200 ✅ 成功
B 对照（模拟旧代码手动加回参数）	minimaxai/minimax-m3	是	429（免费额度速率限制，非参数被接受；参数存在性已确认）
C 范围正确	api.openai.com	是（自定义端点保留）	—（纯逻辑断言，无需网络）

结论：

• A=200 证明修复后英伟达可正常对话；
• C 证明自定义 OpenAI 兼容端点行为未被误伤（仍保留 prompt_cache_key）；
• B 本次因免费层速率限制返回 429 而非 400，但已确认参数确实被加回；结合 issue [Bug] 使用英伟达免费 API（integrate.api.nvidia.com）调用时返回 400：Unsupported parameter(s): prompt_cache_key #353 原始报错即为
  400 Unsupported parameter(s): prompt_cache_key，可确认该字段就是根因。验证用模型
  qwen/qwen3.5-122b-a10b 已于 2026-07-20 EOL（返回 410），故改用 minimaxai/minimax-m3。

如需对 B 复现干净的 400，可等限流过后单独跑对照：ONLY_B=1 DELAY_B=10 npx tsx scripts/e2e-nvidia-proof.ts。

关联

Fixes #353

---

注：补丁合入源码 ≠ 已安装的 App 立即修复；若需立即可用，仍可用 LiteLLM 反向代理
（drop_params=True）临时兜掉该字段。

[ILoveBingLu]

感谢 PR，根因定位准确：main 上 prompt_cache_key 只在 agent/provider.ts（transformRequestBody）和 agent/cache.ts（buildProviderOptions）两处注入，主聊天路径确实不注入；非 NVIDIA 端点行为零改动（已用 mock fetch 验证 openai / deepseek / notnvidia 仍带该字段）。整体方向同意，合并前请处理两点：

1. isNvidiaInferenceBaseURL 改为解析 hostname（必改）

electron/services/agent/promptCacheCompat.ts:18 用正则 /(^|\.)nvidia\.com(\/|$)/i 扫整串 URL，nvidia.com 后只允许 / 或行尾，带端口时漏判：https://integrate.api.nvidia.com:443/v1 会判为 false，仍然注入 prompt_cache_key（实测）。建议与同目录 arkContextFetch.ts 的 isArkBaseURL、cache.ts 的 hostFromUrl 同风格：

export function isNvidiaInferenceBaseURL(baseURL?: string): boolean {
  if (!baseURL) return false
  try {
    const host = new URL(baseURL).hostname.toLowerCase()
    return host === 'nvidia.com' || host.endsWith('.nvidia.com')
  } catch {
    return false
  }
}

2. PR 描述与提交内容不一致 / 测试未接入

• 描述中大篇幅引用的 scripts/e2e-nvidia-proof.ts 不在本 PR 中（diff 只有 4 个文件）。不把外网调用脚本放进仓库是对的，但请把描述改成与实际提交一致。
• scripts/test-nvidia-prompt-cache.ts 请按仓库惯例接到 package.json："test:nvidia-prompt-cache": "node --experimental-strip-types scripts/test-nvidia-prompt-cache.ts"，并补一条断言 buildProviderOptions 在 nvidia baseURL 下不含 prompt_cache_key（PR 自己说这是关键修复点，目前只测了纯函数）。

可选：cache.ts 的 buildProviderCacheStatus 对 nvidia 仍会返回"已通过 transformRequestBody 注入 prompt_cache_key"，UI 上会显示误导信息，顺手加个分支更好。

改完 @ 我，合并没问题。

[ILoveBingLu]

已合并，感谢！评审里提到的几点我在 4853a1a 直接补上了：isNvidiaInferenceBaseURL 改为 hostname 判断（修带端口漏判）、buildProviderCacheStatus 增加 NVIDIA 分支、test:nvidia-prompt-cache 接入 package.json 并补端口/大写/同形域名用例。下个版本发布生效。