Kimi K3 API 返回空 content，不一定是中转坏了：先检查 max_tokens

接 Kimi K3 时，有一种现象很容易被误判成接口不兼容：HTTP 请求成功、响应里也有 assistant message，但content是空的。

我在 AllRouter 的Kimi-K3路线上做了一个最小测试。提示词只要求返回一个固定字符串，temperature=0，第一次把max_tokens设为 32。结果是：

• prompt tokens：136；
• completion tokens：32；
• reasoning tokens：32；
• reasoning_content有值；
• content为空；
• 延迟约 4.0 秒。

32 个 completion token 全部被 reasoning 使用，模型还没来得及输出最终可见文本，预算就结束了。这种情况不是简单的“模型没回答”，也不能直接归因给中转。

把同一个固定回答测试的max_tokens提高到 128 后：

• prompt tokens：134；
• completion tokens：49；
• reasoning tokens：35；
• content正常返回目标字符串；
• 延迟约 3.4 秒。

多轮工具调用也一起测了

第二个场景要求模型调用一次read_file，程序把完整 assistant message 原样放回messages，再追加 tool result。结果：

• 第一轮正确产生 1 个tool_call；
• 第一轮存在reasoning_content；
• 回传完整 assistant message 后，第二轮正常输出最终内容；
• 这个简单场景没有出现重复工具调用；
• 两轮合计延迟约 5.1 秒。

这只能证明这一组最小场景通过，不能外推为所有 Agent、所有 tool schema 或长任务都兼容。复杂 harness 下是否重复调用，仍需要单独做压力和失败场景测试。

排查顺序

遇到空content时，建议按下面顺序看：

1. 请求是否成功返回 2xx；
2. finish_reason和 usage 是否正常；
3. reasoning_tokens是否已经吃满max_tokens；
4. 是否保留并回传完整 assistant message；
5. 工具结果的tool_call_id是否匹配；
6. 是否在旧会话里中途切换到了 K3。

不要把reasoning_content单独拼成一段 user 文本，也不要只保留content后丢掉tool_calls。多轮工具调用需要保留响应的结构。

可复现检查器

检查器没有第三方依赖，默认隐藏 prompt 和 response 正文，只输出响应结构、token、延迟和是否出现重复 tool call。当前一次完整测试按 2026-07-29 AllRouter 页面价格估算约为 USD 0.004644。

测试范围不包括 streaming、图片、百万上下文、provider failover 和长时间 Agent 循环。

Telegram 测试群：https://t.me/+13g2ma9APiU0YjRl

AllRouter 独立测试入口：https://allrouter.ai/register?utm_source=csdn&utm_medium=content&utm_campaign=k3_evidence_20260729&utm_content=k3_reasoning_budget

披露：本文测试由 AllRouter 运营侧完成。测试成功项、失败边界和价格假设均按同一口径记录；实际费用以实时页面和账单为准。