Kimi 思考模型怎么用：和普通模型的调用差异
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
从普通模型换到 Kimi 思考模型，代码上真正要改的地方只有三处：一是响应里多了一个和 content 同级的 reasoning_content 字段，而且 openai SDK 的类型定义里没有它，只能用 hasattr / getattr 取；二是多轮对话和工具调用要把带 reasoning_content 的完整 assistant message 原样回传；三是不同型号的思考开关完全不一样——kimi-k3 用顶层 reasoning_effort，kimi-k2.7-code 根本不接受关闭思考，kimi-k2.6 和 kimi-k2.5 才用 thinking 参数。 官方文档《思考模型》页把这几条差异排成了一张对照表，如果你按「换个 model 名字就行」的思路迁移，最容易在多轮那一步翻车。
思考模型到底多做了什么
官方对思考模型的描述是：在给出最终回答前，先用推理 token 进行「思考」——分解问题、规划步骤、评估多种方案，推理过程通过响应中的 reasoning_content 字段返回。文档同时把代价写在了同一句里：先思考再回答让模型在复杂推理、代码生成、多步工具调用等任务上表现更好，代价是更高的延迟和更多的 token 消耗。
这句话值得原样记住，因为它划清了选型边界。思考模型不是普通模型的免费升级版，它换来的能力是有对价的，而对价直接体现在 token 上——文档的常见问题里明确写了，reasoning_content 会计入输入/输出 token 消耗，具体计费方式以官方产品定价页为准。所以「要不要开思考」这个决定，本质上是一道成本与任务复杂度的权衡题，不是一个默认打开就完事的开关。关于成本怎么估、账单怎么看，可以配合 API 成本监控的通用做法 一起读。
四个型号，四套思考参数
这是这篇文章里最容易搞错的部分。官方文档按型号分别说明，行为差异很大：
kimi-k3：旗舰思考模型，始终进行推理，保留式思考（Preserved Thinking）始终开启，并可能返回reasoning_content。它不支持thinking参数，推理强度改由请求顶层的reasoning_effort控制，取值为"low"/"high"/"max"三档，默认取"max"（默认值以官方文档当前版本为准）。文档明确说使用 K3 时无需、也不应传入thinking参数。kimi-k2.7-code：面向代码场景，始终开启思考，保留式思考也始终开启。它的高速版kimi-k2.7-code-highspeed与之为同一模型、思考行为完全一致，官方文档里这一页的所有说明同样适用。kimi-k2.6：通用思考模型，默认开启思考，可按需关闭，支持保留式思考。kimi-k2.5：通用思考模型，默认开启思考，可按需关闭，但不支持保留式思考——文档在参数对照表里把它的thinking.keep标为「无此参数，不支持」。
thinking 参数下面有两个子字段，含义不要混：thinking.type 控制本轮要不要思考，thinking.keep 控制历史轮次的思考要不要带上。对 kimi-k2.6，type 可以是 "enabled"（默认）或 "disabled"，keep 可以是 null（默认，不保留）或 "all"（启用保留式思考）。
对 kimi-k2.7-code，这两个字段的容错行为很特别，值得单独记：thinking.type 只接受 "enabled"，传 "disabled" 会报错；thinking.keep 不传或者传合法值 "all" 都按 "all" 处理，传入其他非法值同样报错。也就是说这个模型不给你「关掉思考省点开销」的选项，你能做的只有别传。
reasoning_content 怎么读才不会漏
官方文档专门用一节讲这个字段的读法，因为它有一个反直觉的地方：openai SDK 中的 ChoiceDelta 和 ChatCompletionMessage 类型并不提供 reasoning_content 字段，所以你没法直接写 message.reasoning_content 去访问它。文档给的正确做法是先用 hasattr(obj, "reasoning_content") 判断字段是否存在，存在再用 getattr(obj, "reasoning_content") 取值。官方的 Python 示例通篇都是这个写法，不是随手写的防御性代码，而是类型定义决定的唯一路径。
如果你用的是别的框架，或者自己拿 HTTP 直连接口，那就没有这层障碍——文档说可以直接获取与 content 字段同级的 reasoning_content 字段。
流式场景还有一条顺序保证：在 stream=True 的场合，reasoning_content 字段一定会先于 content 字段出现。这条保证的实用价值是，你不需要额外的信号来判断思考阶段结束，只要在业务代码里判断 content 字段是否出现，就能识别推理过程是否结束——官方示例正是靠一个布尔变量在两个字段之间切换，打印出「开始思考 / 思考结束」的分隔线。
最后一条是预算相关的：reasoning_content 中包含的 tokens 也受 max_tokens 参数控制，reasoning_content 的 tokens 数加上 content 的 tokens 数应小于等于 max_tokens。这意味着 max_tokens 在思考模型上不再等价于「回答有多长」，它是思考加回答的总预算。如果你把普通模型时代的 max_tokens 直接搬过来，很可能出现思考写了一半、正式回答被截断的情况。官方在多步工具调用那一节给出了一个建议下限值，让你避免无法输出完整的 reasoning_content 和 content，具体数值以官方文档当前版本为准。
多步工具调用要按官方那套配置来
文档说 kimi-k2.7-code 和 kimi-k2.6（启用思考能力时）都支持通过深度推理进行多步工具调用，并且用「请务必」的措辞给了一组配置要求，这几条是一起生效的：
- 单轮任务内产生的所有思考内容都要保留并回传。文档的说法是，一次工具调用循环中产生的多步推理，应保留上下文中所有的
reasoning_content字段并随请求回传，模型会按需选择必要的思考内容进行推理。注意这一条和跨轮无关——跨轮对话是否保留历史思考由thinking.keep控制，kimi-k2.6默认不保留，kimi-k2.7-code始终保留。这两层是分开的，别用一个开关去理解两件事。 - 把
max_tokens放大，理由就是上一节说的总预算问题。 - 不要设置
temperature。文档写得很直白：kimi-k2.7-code、kimi-k2.6的temperature不可修改，使用默认值即可，请勿显式传入。很多从别家迁过来的代码里习惯性带着temperature，这里要清掉。 - 使用流式输出。文档给的理由是思考模型的输出内容包含
reasoning_content，相比普通模型其输出内容更多，启用流式输出能获得更好的用户体验，同时一定程度避免网络超时问题。
官方那个「生成今日新闻报告」的完整示例值得看一眼结构：它把 moonshot/date:latest 和 moonshot/web-search:latest 两个官方工具的 Formula URI 列出来，先请求 /formulas/{formula_uri}/tools 拿到工具定义并建立 function.name 到 URI 的映射，再在循环里 POST /formulas/{formula_uri}/fibers 执行工具，判断返回的 status 是否为 succeeded，成功则取 context 里的 output 或 encrypted_output。循环体里每一轮都做同一件事：把返回的 assistant message 整个 append 回 messages（因此 reasoning_content 自然被保留），模型不再返回 tool_calls 就结束循环。
保留式思考：省开销和保连贯性的取舍
保留式思考（Preserved Thinking）的定义是，在多轮对话中把历史轮次的 reasoning_content 一并透传给模型，让模型在本轮推理时能延续之前的思考脉络。
对 kimi-k2.6，thinking.keep 取 null 或不传是默认行为，忽略历史轮次的 reasoning_content，好处是上下文更短、成本更低；取 "all" 则完整保留历史轮次的思考内容。文档特别澄清了一句容易误读的话：thinking.keep 只影响历史轮次的 reasoning_content，并不改变模型在当前轮次是否产生或输出思考内容——后者由 thinking.type 控制。官方推荐把 keep: "all" 与 type: "enabled" 搭配使用。
用 openai SDK 传这组参数时，官方示例是放在 extra_body 里，因为它不是 SDK 的原生参数；用 curl 则直接写在请求体顶层的 thinking 对象里。
对 kimi-k2.7-code，前面说过保留式思考无法关闭，所以文档用了「必须（而非可选）」的措辞：必须把历史轮次 assistant 消息的 reasoning_content 原样保留在 messages 中。kimi-k3 同理，多轮对话和工具调用都必须把 API 返回的完整 assistant message 原样回传。
代价写在文档的提示里：开启保留式思考后，历史思考内容会持续占用上下文长度并计费。这就是为什么 kimi-k2.6 把默认值留在了不保留——多轮聊天类应用如果无脑打开 keep: "all"，上下文会随轮次单调膨胀。思路上这和缓存那类机制正好相反，缓存是让重复内容的计费方式变化，保留式思考则是主动往上下文里加内容，两者的成本模型可以对照 API 缓存计费机制 来理解。
迁移时最容易栽的三个坑
第一个坑是只改了 model 名字。普通模型换成思考模型之后，如果你的多轮代码是自己拼 assistant 消息（只取 content 塞回去），reasoning_content 就丢了。对 kimi-k2.7-code 和 kimi-k3 这类保留式思考不可关闭的模型，这不是「效果差一点」的问题，而是没有按文档要求来。最省事的写法就是官方示例那种：把上一轮 API 返回的 assistant message 直接 append 回 messages。
第二个坑是拿 .reasoning_content 直接访问。SDK 类型里没有这个字段，官方给的可行路径只有 hasattr 加 getattr 这一条，或者干脆走 HTTP 自行解析同级字段。
第三个坑是沿用旧的 max_tokens 和 temperature。前者现在要覆盖思考加回答两段，后者在 kimi-k2.7-code、kimi-k2.6 上不可修改且不应显式传入。
选型上可以这么定：代码类任务直接用 kimi-k2.7-code，别指望在它上面关思考；想要一个可开可关的通用思考模型就用 kimi-k2.6，默认不保留历史思考的行为对多轮聊天更友好；需要调节推理强度就上 kimi-k3，它的档位入口是 reasoning_effort 而不是 thinking。另外，如果你要拿 Kimi API 做基准测试，官方在这一页专门指路了《基准测试最佳实践》，别用随手写的调用参数去跑分。
如果你还没跑通最基础的调用链路，先看 Kimi API 接入的基础步骤，再回来处理思考模型这几个额外字段。以上参数与行为均以 Kimi 官方文档当前版本为准，接入前建议回官方页面再对一遍。