接 Kimi K3 时有一种现象很容易被误判成接口不兼容HTTP 请求成功、响应里也有 assistant message但content是空的。我在 AllRouter 的Kimi-K3路线上做了一个最小测试。提示词只要求返回一个固定字符串temperature0第一次把max_tokens设为 32。结果是prompt tokens136completion tokens32reasoning tokens32reasoning_content有值content为空延迟约 4.0 秒。32 个 completion token 全部被 reasoning 使用模型还没来得及输出最终可见文本预算就结束了。这种情况不是简单的“模型没回答”也不能直接归因给中转。把同一个固定回答测试的max_tokens提高到 128 后prompt tokens134completion tokens49reasoning tokens35content正常返回目标字符串延迟约 3.4 秒。多轮工具调用也一起测了第二个场景要求模型调用一次read_file程序把完整 assistant message 原样放回messages再追加 tool result。结果第一轮正确产生 1 个tool_call第一轮存在reasoning_content回传完整 assistant message 后第二轮正常输出最终内容这个简单场景没有出现重复工具调用两轮合计延迟约 5.1 秒。这只能证明这一组最小场景通过不能外推为所有 Agent、所有 tool schema 或长任务都兼容。复杂 harness 下是否重复调用仍需要单独做压力和失败场景测试。排查顺序遇到空content时建议按下面顺序看请求是否成功返回 2xxfinish_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/13g2ma9APiU0YjRlAllRouter 独立测试入口https://allrouter.ai/register?utm_sourcecsdnutm_mediumcontentutm_campaignk3_evidence_20260729utm_contentk3_reasoning_budget披露本文测试由 AllRouter 运营侧完成。测试成功项、失败边界和价格假设均按同一口径记录实际费用以实时页面和账单为准。