Skip to main content
与 Kimi 智能助手不同,Kimi API 是 无状态 的,本身没有记忆功能:多次请求之间,模型不知道你前一次请求的内容,也不会记住任何上下文——上一次你告诉它今年 27 岁,下一次请求它并不知情。要实现多轮对话,需要手动维护每次请求的上下文(Context),把历史消息随下一次请求一起发送,让模型能看到此前聊过的内容。
本页示例默认使用最新模型 kimi-k3。K3 使用请求顶层 reasoning_effort 配置推理强度(支持 "low" / "high" / "max",默认 "max")。换用 kimi-k2.6kimi-k2.5 等其他模型时,只需替换 model 字段,但各模型的参数配置存在差异,详见模型参数参考

用 messages 列表为模型补上记忆

以下示例改造自上一章节,演示如何通过维护 messages 列表让模型拥有记忆:每轮对话把用户的新消息(role=user)和模型的回复(role=assistant)都追加到列表中,再整体随请求发送。实现要点已以注释形式标注在代码中:
要点回顾:
  • Kimi API 本身没有上下文记忆功能,需要通过 messages 参数手动把”之前聊了什么”告知模型;
  • messages 中既要存用户提出的问题(role=user),也要存模型的回复(role=assistant)。

截断历史消息,控制上下文长度

随着 chat 调用次数增多,messages 列表不断增长,每次请求消耗的 Tokens 也随之增加,最终列表中的消息会超出模型支持的上下文窗口。建议用某种策略把 messages 控制在可控范围内,例如每次只保留最新的 20 条消息作为本次请求的上下文。 以下示例演示如何用 make_messages 函数控制每次请求的消息数量(默认保留最新 20 条),注意它如何保证截断后 System Messages 仍然留在列表中:

生产环境还需要考虑什么

上述代码示例仅覆盖最简单的调用场景,实际业务中可能还需要处理更多场景和边界:
  • 并发场景下可能需要额外的读写锁;
  • 多用户场景需要为每个用户单独维护 messages 列表;
  • messages 列表进行持久化;
  • 用更精确的方式计算 messages 列表中需要保留多少条消息;
  • 对被遗弃的消息做一次总结,生成一条新消息加入 messages 列表;
  • ……