Kimi K3 API 已上线：破坏 K2.x 路由脚本的 reasoning_effort 参数变更

每当新的前沿模型发布，头条新闻通常是 benchmark 数字。而真正影响工程团队的操作变化，往往藏在 API changelog 的角落里。Kimi K3 也不例外：月之暗面于 7 月 14 日发布了这款 2.8 万亿参数的开源模型，打算将 K3 接入路由管线的团队，需要在研究 benchmark 之前，先注意一个悄然发生的破坏性变更。

发生了什么

Kimi K3 现已通过 https://api.moonshot.ai/v1 提供服务，模型名称为 kimi-k3。这是月之暗面迄今规模最大的模型：2.8 万亿参数，基于 MoE 架构（896 个专家中激活 16 个），底层采用 Kimi Delta Attention 与 Attention Residuals，以改善长序列的信息流动。

该模型具备 100 万 token 的上下文窗口、原生视觉理解能力，以及始终开启的思维模式——不存在关闭思维的非推理变体。模型权重计划于 2026 年 7 月 27 日公开发布，在此之前仅支持 API 调用。

benchmark 显示，K3 在长程编程任务上的表现与 Claude Fable 5 旗鼓相当，并在多项内部评估中优于 GPT 5.6 Sol。在一次 48 小时的自主运行中，K3 使用开源 EDA 工具完成了一块功能性芯片的版图设计。这些是吸引眼球的数字，但它们不会破坏你的管线——下面这个变更才会。

破坏性变更：reasoning_effort 替代 thinking

所有 Kimi K2.x 集成中，设置思维模式的方式都是通过 extra_body 或 thinking 参数。K3 不接受该参数。正确字段现在是顶层的 reasoning_effort：

completion = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="max",   # 不是 extra_body={"thinking": {"type": "enabled"}}
    messages=[{"role": "user", "content": "..."}],
)

目前 max 是唯一接受的值。低档和高档 effort 模式将在后续版本中推出。这意味着 K3 目前不提供运营商通常用于路由分层的"成本 vs 质量"权衡——每次 K3 调用都以最高思维成本运行。

第二个操作变更影响多轮对话和 tool-call 链：当模型返回响应时，完整的 assistant 消息对象——包括 reasoning_content 字段——必须包含在下一个请求的消息历史中。在传递上下文前裁剪 reasoning_content 会导致后续轮次的连贯性下降。

为什么 AI 工程团队需要关注

在未仔细对比 API diff 的情况下从 K2.x 升级到 K3，会暴露三个实际问题。

参数不匹配可能静默 fallback。 根据你的 SDK 或网关处理未知字段的方式，将旧的 thinking 参数传入 K3 可能会被静默丢弃，而非抛出错误。模型仍然运行——按其默认行为——但你的路由逻辑误以为已设置了思维 effort，实际上并没有。

成本核算逻辑发生变化。 K3 的 token 计费独立于 K2.7 Code。如果你的按模型预算追踪使用 K2.x 模型名前缀，kimi-k3 这个模型字符串将无法命中那些规则。在扩大用量之前，需验证成本归因逻辑已覆盖新模型名。

Coding agent 集成需要复查。 月之暗面官方 quickstart 将 Claude Code、Codex、Cline 和 RooCode 列为 K3 的主要使用场景。这些工具各自发送 model 字符串，并可能根据之前的配置传入 thinking 参数。通过这些工具配置了 K2.x 集成的团队，应在将 K3 流量接入现有 agent 配置之前，重新阅读平台文档发布的 K3 集成指南。

路由与运营商视角

Kimi K3 为长程编程工作负载引入了新的成本-性能层级。对于将编程 agent 任务路由到多个 provider 的运营商来说，K3 的性能档位——大规模 MoE 加上始终开启的 max 思维——最直接可与 Fable 5 和 GPT 5.6 Sol 对比，而非 K2.7 Code。将 K3 作为 K2.7 Code 的直接替代进行路由，会在不需要前沿级推理的任务上增加成本和延迟。

当前缺乏 effort 分档也意味着，从 K3 fallback 到 K2.7 Code 是目前在家族内部降本而不切换 provider 的唯一选择。未来的低档/高档 effort 模式将最终在 K3 内部构建分层路由策略，但这一能力目前尚不可用。

计划于 7 月 27 日开放的开源权重将带来自托管和第三方推理选项。在此之前，api.moonshot.ai 是唯一经过验证的来源。在你倾向使用的推理 provider 添加权重之前，避免将路由指向未经验证的 endpoint。

路由检查清单：

• 在适合 K3 的场景中，将模型字符串从 kimi-k2.6 或 kimi-k2.7-code 更新为 kimi-k3
• 在 K3 路径中，用 reasoning_effort: "max" 替换 thinking 参数
• 多轮请求中携带完整 assistant 消息（包含 reasoning_content）
• 验证成本归因已捕获新的 kimi-k3 模型名
• 等待 7 月 27 日权重确认后，再开启自托管路由

TheRouter 用户可以关注什么

Kimi K3 处理思维模式的方式从 extra-body 扩展改为顶层 reasoning_effort 字段，这是 API 接口碎片化的典型案例，也正是路由网关存在的意义之一。当多个 provider 各自实现了不同的思维模式约定时，统一网关可以在字段到达应用层代码之前完成规范化映射。查阅 TheRouter 文档，了解如何在网关层映射 provider 特定参数，使应用代码保持 provider 无关性。

随着 K3 的 effort 分档逐步落地，它们也将适用于根据任务复杂度或预算阈值动态选择 effort 级别的路由策略——值得在分档上线前提前规划这一配置模式。