SillyTavern项目中关于Claude提示缓存的兼容性设计与实现

在SillyTavern项目的开发过程中，开发者们遇到了一个关于Claude模型提示缓存功能的兼容性问题。这个问题涉及到不同API源之间的功能差异，以及如何在不破坏现有兼容性的前提下提供更好的用户体验。

问题背景

SillyTavern支持多种API源，包括原生的Claude接口、OpenRouter以及自定义源。其中，Claude和OpenRouter源都支持系统提示缓存功能，包括深度缓存。然而，当用户选择使用自定义源时，这些缓存功能却无法使用。这给那些希望通过自定义源使用OpenRouter Claude接口并应用"严格"模式后处理的用户带来了不便。

技术考量

核心开发团队经过讨论后认为，自定义源的设计初衷是保持与OpenAI API的兼容性。如果在自定义源中添加特定的负载修改功能（如提示缓存），将会使其与OpenAI API标准产生偏离。这种设计决策体现了项目对API兼容性的重视。

解决方案

开发团队采取了多方面的解决策略：

1. 与OpenRouter团队沟通：针对系统消息处理的问题，开发团队与OpenRouter进行了沟通，OpenRouter表示会重新考虑如何处理提示中间的系统消息。

2. 增强OpenRouter源的功能：在项目的staging分支中，开发者为OpenRouter源添加了"半严格"（semi-strict）后处理选项。这种模式可以解决系统角色相关的问题，同时保持API的兼容性。

3. 缓存标记处理优化：开发者确认，添加缓存标记的函数不会进行可能导致其他功能失效的非必要请求重写。这个函数会在最后被调用，确保不会影响其他处理流程。

技术实现细节

在具体实现上，项目团队特别注意了以下几点：

• 缓存标记的添加过程会确保不擦除任何元数据
• 对于消息格式的转换（如将字符串转换为{"type": "text", "text": string}格式）是安全且必要的
• 保持与OpenAI API标准的兼容性始终是首要考虑因素

用户建议

对于需要使用Claude模型并希望获得提示缓存功能的用户，建议：

1. 优先使用原生的Claude接口或OpenRouter源
2. 如果需要使用自定义源，可以考虑等待OpenRouter对系统消息处理的改进
3. 可以尝试staging分支中的新功能，特别是"半严格"后处理模式

这个案例展示了在开源项目开发中如何平衡功能需求与API兼容性，以及如何通过多方面的技术方案来解决复杂的接口兼容问题。