MiniMax Agent需通过显式context传入历史消息或启用session_id隐式缓存来维持多轮对话状态。显式方式要求按role/content构造JSON数组，system消息置首且唯一，context字段提交并校验X-Context-Status；隐式方式需复用唯一session_id并处理超时失效；精简context应保留状态锚点、合并指令、删除无意义情绪表达。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
想让MiniMax Agent在连续对话中记住用户上一句话、上一轮提问甚至整个会话脉络，避免每次都要重复说明背景或身份，必须正确配置context参数与会话状态机制。
启用显式context传入并构造历史消息数组
这是最基础也最可控的多轮对话维持方式，适用于需要精确控制每条上下文内容的场景，比如客服问答、订单追踪等强状态依赖流程。
第一步：将全部历史消息（含system、user、assistant）按时间顺序整理为JSON数组，每项必须包含role和content两个键，缺一不可。
第二步：确保system消息永远排在数组第一位，且仅出现一次；若多次插入system消息，模型可能忽略后续所有system指令或产生角色混淆。
第三步：在每次新请求的body中，将该数组作为context字段提交，不要放在messages里——【messages字段只用于当前轮次的新输入，context才是承载历史的唯一合法位置】。
第四步：检查返回响应头中的X-Context-Status值，若为valid则表示上下文被完整接收；若为invalid或missing，说明context格式错误或长度超限，需立即排查role字段拼写或content是否为空字符串。
使用session_id启用隐式缓存机制
适合Web端聊天界面、App内嵌对话框等无需手动维护长历史的场景，平台自动压缩并缓存关键语义，大幅降低token开销与构造复杂度。
方法一：在HTTP请求Header中添加X-Session-ID: your_unique_session_id，该ID需全局唯一且稳定复用，不能每次请求都生成新值。
方法二：初始化SDK时设置cache_enabled: true，并在每次调用chat接口时传入同一session_id参数，服务端将据此关联并注入已缓存的历史摘要。
注意：session默认30分钟无操作即自动失效，若用户长时间静默后继续发言，需捕获X-Context-Status: expired响应并主动重建会话。
精简context内容保留状态锚点
过长的context不仅浪费token配额，还会稀释模型对关键状态变更的注意力，尤其当用户说“刚才我说的第三点”时，模型必须能准确定位到对应轮次。
识别并保留显性状态词：如“已确认收货”“第2步操作完成”“地址更改为XX路123号”，这些是模型理解进展的核心锚点。
合并连续用户指令：将“查订单#88921”→“再看下物流”→“发个取件码”压缩为单条：“用户查询订单#88921的物流信息，并索要取件码。”
删除纯情绪表达：如“啊？”“好的谢谢！”“太棒了！”这类语句不携带业务状态信息，可安全剔除。
