Skip to main content
思考模型在给出最终回答前,会先用推理 token 进行“思考”——分解问题、规划步骤、评估多种方案,推理过程通过响应中的 reasoning_content 字段返回。先思考再回答,让模型在复杂推理、代码生成、多步工具调用等任务上表现更好,代价是更高的延迟和更多的 token 消耗。

按场景选择思考模型

本页涉及以下思考模型:
  • kimi-k3:旗舰思考模型,始终进行推理且保留式思考(Preserved Thinking)始终开启,并可能返回 reasoning_content;请求通过顶层 reasoning_effort 配置推理强度,支持 "low" / "high" / "max"(默认 "max")。
  • kimi-k2.7-code:面向代码场景,始终开启思考,且 保留式思考(Preserved Thinking)始终开启。其高速版 kimi-k2.7-code-highspeed 与之为同一模型、思考行为完全一致,本页所有说明同样适用。
  • kimi-k2.6:通用思考模型,默认开启思考,可按需关闭,支持保留式思考
  • kimi-k2.5:通用思考模型,默认开启思考,可按需关闭,但 不支持保留式思考
各模型的请求参数差异如下: 如果您使用 kimi api 进行基准测试,请参考这篇 基准测试最佳实践

基本调用

调用 kimi-k3

kimi-k3 始终进行推理且保留式思考始终开启,无需(也不应)传入 thinking 参数;只需指定 model,并按需通过顶层 reasoning_effort 调节推理强度
多轮对话和工具调用必须把 API 返回的完整 assistant message 原样回传到 messages(包括 reasoning_content),详见保留式思考。更多 K3 用法见 Kimi K3 快速开始

调用 kimi-k2.7-code:无需传 thinking 参数

kimi-k2.7-code 是面向代码场景的思考模型,与 kimi-k2.6 共享同一套思考机制(reasoning_content、多步工具调用、流式输出等),差异仅在 thinking 参数(见上方对照表)。使用时无需(也不应)传入 thinking 参数,只需切换 model 即可,模型始终输出 reasoning_content。由于保留式思考始终开启,多轮对话中请务必把每一轮历史 assistant 消息的 reasoning_content 原样保留在 messages 中。 以下示例发起一次最基本的流式调用,并在输出中区分思考内容与最终回答:

调用 kimi-k2.6:默认即输出思考内容

kimi-k2.6 是通用思考模型,默认即启用思考能力,下面的基本调用无需传入 thinking 参数也会输出思考内容(如需关闭思考或开启保留式思考,见下方 thinking 参数 说明):

控制思考行为

K3:用 reasoning_effort 调节推理强度

kimi-k3 始终进行推理,不支持 thinking 参数。通过请求顶层 reasoning_effort 调节推理强度,支持 "low" / "high" / "max" 三档(默认 "max"),用法与示例见推理强度

用 thinking 参数控制 kimi-k2.6 的思考行为

kimi-k2.6 通过 thinking 参数控制思考行为,包含两个子字段:
  • thinking.type"enabled"(默认)| "disabled",控制是否开启思考。由于默认即为 "enabled",上面的示例无需显式传入即可思考;禁用示例见 k2.6 禁用思考能力示例
  • thinking.keepnull(默认,忽略历史轮次的思考)| "all"(保留历史轮次的 reasoning_content,启用保留式思考,用法详见 保留式思考)。

从响应中读取 reasoning_content

使用 kimi-k2.7-codekimi-k2.6 等思考模型(启用思考能力时)时,API 响应通过 reasoning_content 字段承载模型的思考内容。读取该字段时注意:
  • openai SDK 中的 ChoiceDeltaChatCompletionMessage 类型并不提供 reasoning_content 字段,因此无法直接通过 .reasoning_content 的方式访问该字段,仅支持通过 hasattr(obj, "reasoning_content") 来判断是否存在字段,如果存在,则使用 getattr(obj, "reasoning_content") 获取字段值
  • 如果你使用其他框架或自行通过 HTTP 接口对接,可以直接获取与 content 字段同级的 reasoning_content 字段
  • 在流式输出(stream=True)的场合,reasoning_content 字段一定会先于 content 字段出现,你可以在业务代码中通过判断是否出现 content 字段来识别思考内容(或称推理过程)是否结束
  • reasoning_content 中包含的 Tokens 也受 max_tokens 参数控制,reasoning_content 的 Tokens 数加上 content 的 Tokens 数应小于等于 max_tokens

配置多步工具调用

kimi-k2.7-codekimi-k2.6(启用思考能力时)都支持通过深度推理进行多步工具调用,进而完成非常复杂的任务。为确保最佳效果,使用思考模型时请务必按以下方式配置调用:
  • 单轮任务内(一次工具调用循环中产生的多步推理)应保留上下文中所有的思考内容(reasoning_content 字段)并随请求回传,模型会按需选择必要的思考内容进行推理;跨轮对话是否保留历史思考由 thinking.keep 控制(kimi-k2.6 默认 null 不保留,kimi-k2.7-code 始终保留)。
  • 设置 max_tokens>=16000 以避免无法输出完整的 reasoning_contentcontent
  • 无需设置 temperature kimi-k2.7-codekimi-k2.6temperature 不可修改,使用默认值即可,请勿显式传入(详见模型参数参考)。
  • 使用流式输出(stream=True):思考模型的输出内容包含了 reasoning_content,相比普通模型其输出内容更多,启用流式输出能获得更好的用户体验,同时一定程度避免网络超时问题。

完整示例:生成今日新闻报告

下面的示例展示了一个”今日新闻报告生成”的场景,模型会依次调用 date(获取日期)和 web_search(搜索今日新闻)等官方工具,并在这个过程中展现深度思考过程:
整个过程展现了 kimi-k2.7-codekimi-k2.6 等思考模型(启用思考能力时)如何通过深度思考来规划和执行复杂的多步骤任务,每个步骤都有完整的推理过程(reasoning_content),并且思考内容会保留在上下文中以确保工具调用的准确性。

在多轮对话中保留思考(Preserved Thinking)

保留式思考指在多轮对话中,把历史轮次(previous turns)的 reasoning_content 一并透传给模型,让模型在本轮推理时能延续之前的思考脉络。 对于 kimi-k2.6 模型,可通过请求体中的 thinking.keep 参数控制是否保留历史思考:
thinking.keep 只影响历史轮次的 reasoning_content,并 改变模型在当前轮次是否产生/输出思考内容(该行为由 thinking.type 控制)。推荐把 keep: "all"type: "enabled" 搭配使用。kimi-k2.7-code,保留式思考始终开启、无法关闭:thinking.keep 不传或传合法值 "all" 都按 "all" 处理(传入 "all" 以外的非法值会报错)。因此使用该模型时,必须(而非可选)把历史轮次 assistant 消息的 reasoning_content 原样保留在 messages 中,做法与下方示例一致。
使用 keep: "all" 时,需要把每一轮历史 assistant 消息中的 reasoning_content 原样保留在 messages 中。最简单的做法是把上一轮 API 返回的 assistant message 直接 append 回 messages,如以下示例所示:
reasoning_content 会计入 token 消耗。开启保留式思考后,历史思考内容会持续占用上下文长度并计费,请酌情使用。

常见问题

Q1: 为什么需要保留 reasoning_content

A: 保留 reasoning_content 可以确保多步推理的连贯性,特别是在工具调用过程中。请把 API 返回的完整 assistant message 原样回传到 messages。对 K3,多轮对话和工具调用都必须这样处理;对 K2.x,跨轮保留行为由各模型的 thinking.keep 决定:kimi-k2.6 默认不保留,kimi-k2.7-code 始终保留。

Q2: reasoning_content 会消耗额外的 token 吗?

A: 是的,reasoning_content 会计入输入/输出 token 消耗。具体计费方式请参考产品定价