Kimi K3.1 Pro 多轮消息与工具历史：完整保留 reasoning_content

一句话结论

Kimi K3.1 Pro 的多轮对话和工具调用必须把 API 返回的完整 assistant 消息原样放回 messages，包括 reasoning_content；客户端不能只保存最终答案。

适用场景

• 适合的任务：需要连续追问、函数调用或多步 Agent 循环的 K3.1 Pro API 工作流。

• 不适合的任务：只做一次请求的调用，或把旧版 K2.x 的 thinking.type、thinking.keep 配置直接迁移到 K3.1 Pro。

• 适用的模型版本：kimi-k3.1-pro。本文的历史保留要求以官方页面对该模型的说明为准。

• 适用的客户端、Agent 或 API：Kimi API Chat Completions，以及能保留并透传 assistant 原始字段的客户端或 Agent。

• 推荐的推理档位和参数：本文不讨论档位；K3.1 Pro 不使用 thinking 参数。请求可按任务另设顶层 reasoning_effort，详见 02 号配置稿。

可直接使用的内容

K3.1 Pro 的首轮请求

{
  "model": "kimi-k3.1-pro",
  "messages": [
    {"role": "user", "content": "请分析这个问题，并在需要时调用工具。"}
  ]
}

多轮和工具调用的消息循环

messages = [
    {"role": "user", "content": "请分析这个问题，并在需要时调用工具。"}
]

while True:
    completion = client.chat.completions.create(
        model="kimi-k3.1-pro",
        messages=messages,
        tools=tools,  # 工具定义由客户端按实际能力提供
    )
    assistant = completion.choices[0].message

    # 原样保存完整 assistant：不要只取 assistant.content
    messages.append(assistant)

    if not assistant.tool_calls:
        break

    for tool_call in assistant.tool_calls:
        result = run_tool(tool_call.function.name, tool_call.function.arguments)
        messages.append({
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": result,
        })

这里的 run_tool 代表客户端自己的工具执行器。工具结果要按对应的 tool_call_id 追加；工具执行权限、参数校验和错误处理仍由客户端负责。

测试或工作流步骤

1. 确认请求使用 model: "kimi-k3.1-pro"，并通过 Kimi API 的 Chat Completions 发送 messages。

2. 收到 assistant 响应后，保存完整消息对象及其字段顺序；至少不能丢弃 reasoning_content、content 或 tool_calls。

3. 如果响应包含 tool_calls，逐个执行客户端已注册且允许调用的工具。

4. 将每个工具结果作为对应 tool_call_id 的 role: "tool" 消息追加到同一历史。

5. 把这段完整历史再次提交给 Kimi K3.1 Pro，直到 assistant 不再返回工具调用。

6. 用户继续追问时，只在既有历史后追加新的 role: "user"，不要清洗掉此前 assistant 的 reasoning_content。

原始证据与数据

• 官方页面将 kimi-k3.1-pro 定义为始终推理且始终启用 Preserved Thinking 的旗舰思考模型。

• 页面明确写出：多轮对话和工具调用要把 API 返回的完整 assistant 消息原样传回 messages，其中包括 reasoning_content。

• FAQ 进一步说明，保留 reasoning_content 能维持多步推理和工具调用的连续性，并会计入 token 消耗。

• 官方页面的 K3.1 Pro 基础请求只展示 model 与 messages；页面没有给出 K3.1 Pro 的完整工具 schema 或一套可直接执行的工具实现。

• 页面中的“Daily News Report Generation”完整工具循环示例使用的是 kimi-k2.6，不能当作 K3.1 Pro 的专属实测或参数示例。

• 本文未使用 API Key 发起请求，未声称工具循环已在 K3.1 Pro 上实测成功。

适用边界

• reasoning_content 是 API 消息中的推理字段，本文只要求保存和回传，没有要求把它展示给终端用户。

• K3.1 Pro 使用顶层 reasoning_effort 调整推理档位，不应照搬 K2.6 的 thinking.type 或 thinking.keep。

• 官方页面对 kimi-k2.7-code 和 kimi-k2.6 的 max_tokens、流式输出、温度及 thinking.keep 说明，适用于各自模型；不能据此推断 K3.1 Pro 的同名参数行为。

• “完整回传 assistant”不等于可以把工具结果、用户隐私或密钥写入日志；历史存储仍应遵守客户端的数据保护规则。

• 本文未给出工具名称、参数 schema、超时、重试或并发策略；这些部分必须按实际工具系统定义。

复现说明

1. 打开官方 Thinking Models，确认页面标题、模型选择表和 K3.1 Pro 基础调用段。

2. 核对页面中关于多轮对话、工具调用和 FAQ 的原文，确认完整 assistant 消息包含 reasoning_content。

3. 用客户端记录每次 API 返回的 assistant 原始对象，检查下一次请求的 messages 中仍保留该对象及工具结果的对应关系。

4. 将 K3.1 Pro 与页面中的 K2.6 工具循环分开验证；除官方明确字段外，不补充未公开的参数或实测结论。