把 minimax-m3 的缓存命中率从 0% 提到 90%：一次接口与插件的折腾记录

模型多了之后，我在 CPA 上把常用模型统一接入，作为所有请求的网关。之后用 opencode 调 minimax-m3 时，最开始走的是 anthropic 兼容接口（和上游官方接口一致），结果发现缓存命中率几乎等于零，每次对话模型都要重新计算，成本直线上升。

换思路试了一下 openai 兼容接口（同样和官方接口一致），缓存命中率立刻上来了，稳定在 90% 左右。但随之而来一个新问题：返回正文里多了 <think>...</think> 包裹的思考内容。用起来其实没毛病，opencode 能正常接收，但思考内容混在正文里终究不太对劲。

查了一下 minimax 官方文档，发现有个 reasoning_split 字段，设为 True 之后，思考内容会单独放进 reason_content，不再占正文，opencode 也能正常解析。问题在于每次请求都得手动加这个字段，太麻烦。opencode 又没有自定义请求格式的入口（至少我没找到），改请求只能自己写插件，不划算。好在 CPA 有插件系统，装一个官方的 JSHandler 插件，写段脚本在请求前自动判断并加字段，一劳永逸。

插件装好后，在配置里指定脚本文件，脚本逻辑如下：先判断协议是不是 OpenAI 格式，再判断模型名是否命中 minimax-m3，命中且请求体里还没加过 reasoning_split 就补上 true，全程只用了几行代码：

function on_before_request(ctx) {

    try {

        // 1. 使用 protocol 判断是否为 OpenAI 格式

        if (ctx.protocol !== "openai" && ctx.source_format !== "openai") {

            return ctx;

        }



        // 2. 检查模型名称是否命中 minimax-m3

        var model = ctx.model || "";

        if (!model.toLowerCase().includes("minimax-m3")) {

            return ctx;

        }



        // 3. 解析请求体并添加 reasoning_split

        var req = JSON.parse(ctx.body);

        if (req.reasoning_split === undefined) {

            req.reasoning_split = true;

            ctx.body = JSON.stringify(req);

            console.log("[" + ctx.id + "] Added reasoning_split=true");

        }

    } catch (e) {

        console.log("[" + ctx.id + "] Error: " + e.message);

    }

    return ctx;

}

配置的时候有一点要注意：脚本路径务必填绝对路径，用相对路径的话插件会找不到文件，直接报错。我的配置长这样：

至此调用链变成：opencode → CPA → JSHandler 自动补 reasoning_split → minimax-m3。缓存命中率保持在 90% 左右，思考内容与正文各归各位，问题彻底解决。如果你也遇到同样的"不缓存"问题，可以按这个思路排查一遍：先对比两种兼容接口的缓存表现，再检查是否被思考内容污染了正文，最后用网关插件统一处理。