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时，建议按下面顺序看：
- 请求是否成功返回 2xx；
finish_reason和 usage 是否正常；reasoning_tokens是否已经吃满max_tokens；- 是否保留并回传完整 assistant message；
- 工具结果的
tool_call_id是否匹配； - 是否在旧会话里中途切换到了 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 运营侧完成。测试成功项、失败边界和价格假设均按同一口径记录；实际费用以实时页面和账单为准。