智能体聊到第三轮就忘了前面给过的条件，通常不是模型本身变差，而是三件事里断了一件：会话变量没透传下去、每轮请求没带上历史消息、上下文超长被截断。排查顺序建议从成本最低的开始——先用同一段话问三轮确认能不能稳定复现，再去会话记录里看变量值，最后才去比对请求构造和长度限制。这样能把「没存上下文」和「每轮都从头开始」分开，不至于一上来就改模型参数或调温度。

先做可复现的三轮测试：第一轮给条件，第二、三轮只做指代。若第二轮起条件消失，就去会话记录里看变量值是否为空、从第几轮开始为空；变量有值但回答没用上，再去比对相邻两轮请求里的历史消息数组是否还带着第一轮内容；短对话正常、长对话才丢，多半是上下文长度被截断。中途改过条件的情况要单独复验，因为旧变量残留会制造「记住了错的东西」这类假象。

用同一段话问三轮，看第二轮起还认不认

这一步只解决一个问题：丢上文是不是稳定复现。建议固定一组三轮问法，第一轮把条件说全，后面两轮只做指代、不重复条件。下面是可直接照抄的样例，把业务词换成你自己的即可。

第 1 轮：我在排查订单查询接口的问题。环境是预发，订单号规则是 ORD 开头加 12 位数字。请给我一份排查步骤。

第 2 轮：按上面那个环境，我该怎么复现？

第 3 轮：把那个订单号规则写成一条正则给我。

每一轮记录三件事：回答里有没有提到「预发」、有没有提到「ORD + 12 位」、回答是否明显退化成通用套话。判断规则可以先这么用：第一轮正常、第二轮起两个条件都丢，说明上下文没带过去；三轮都能提到但答得笼统，那更像提示词约束不够，不是丢上文；第三轮丢、第二轮不丢，要怀疑是长度或轮次相关的截断。同一组问法建议连做两遍，如果两次表现不一致，说明还有别的变量在影响，比如会话被复用或并发写入。

查看会话记录里的变量值

这里要分清两种情况：「变量没写进去」和「写进去但没读出来」。前者是写入或复制环节丢的，后者是组装提示词时没把变量拼进去。区别方法就是看会话记录或调试信息里的变量快照，并标注它是从第几轮开始变空的。

不同版本入口名称不一样，一般会在会话详情、调试面板或每轮响应的元信息里。能拿到类似下面的结构就够了，字段名不必和你的实现一致，重点是能看出轮次和值。

{
  "session_id": "s-0001",
  "turn": 2,
  "variables": {
    "env": "staging",
    "order_id_pattern": "^ORD\\d{12}$"
  },
  "history_included": true
}

对照方式：第一轮 variables 里有 env，第二轮为空，问题出在变量写入或会话复制；两轮都有 env，但回答里说「不知道你在哪个环境」，问题出在提示词组装时没引用变量，去查模板里的占位符拼写和转义。还有一种边界情况值得留意：变量只在第一轮被写进会话，后续轮次的变量对象是每轮新建的，这种情况快照会显示第二轮就空。

检查每轮请求是否带上了历史消息

变量正常但回答仍然断片，就要确认丢上文发生在请求构造阶段还是模型阶段。通用接入骨架大致是这样，字段名按你实际用的替换：

{
  "session_id": "s-0001",
  "variables": { "env": "staging" },
  "messages": [
    { "role": "user",      "content": "第 1 轮问题" },
    { "role": "assistant", "content": "第 1 轮回答" },
    { "role": "user",      "content": "第 2 轮问题" }
  ]
}

用日志把相邻两轮的原样比对，看四点：messages 长度是否按预期增加（一问一答应加 2 条）；第一轮的 user 内容是否还在数组里；role 顺序有没有错乱；session_id 是否两轮一致。如果第二轮请求里 messages 只有当前问题这一条，说明代码每次都在重建数组而不是追加，属于请求构造问题，和模型无关。如果数组完整、模型还是答不出来，再去看第 4 节。日志比对时建议只打 roles 和内容前若干字符，避免把长文本刷满日志。

判断是不是上下文长度被截断

把「忘了」和「装不下」分开，靠的是长短对话的表现差异：短对话从第一轮到第五轮都认条件，一旦中间插入几段长文本或长日志，从某一轮开始条件突然消失，基本可以按截断处理。

可以做一个便宜的小实验：把第一轮的关键条件原文复制到当前问题的开头再问一次。如果这样能答对，说明信息本身没丢，只是被挤到了窗口之外或者优先级排序把它排到了后面。

截断发生时，优先保留这些内容的顺序建议是：系统提示里不可协商的约束、当前问题、最近一到两轮对话、被变量固化的关键条件；可以牺牲的是早期寒暄、整段原始日志、已经被变量覆盖过的重复描述。这也是把条件写进会话变量的实际价值——一段结构化变量通常比它在对话里出现过多次的原文短，占用的窗口更少，也不依赖模型自己从历史里翻出来。

固定一套回归用例防止再断

改完配置、调整提示词模板或者升级版本之后，靠临场聊天验证不可靠，建议固定下面这 5 条，每条都写清通过标准。

1. 变量透传：第 1 轮设定 env=staging，第 3 轮问「当前是什么环境」。通过标准：回答为 staging，且第 3 轮会话记录里 variables 仍含 env。
2. 指代消解：第 1 轮给出订单号规则，第 2 轮问「按那个规则写一条正则」。通过标准：输出的正则与第 1 轮条件一致，没有反问规则是什么。
3. 中途改条件：第 1 轮 env=staging，第 2 轮改成 env=prod，第 3 轮问当前环境。通过标准：回答为 prod，且变量快照已更新为 prod，不残留 staging。
4. 历史完整性：第 1 轮一次性给出三条约束，第 4 轮问「我前面提过哪几条约束」。通过标准：三条都能列出，或者至少不否认提过；只提最后一条也算不通过。
5. 长前缀压力：第 1 轮给条件，中间插几段长文本，最后再问同一条件。通过标准：回答仍能正确使用该条件；失败时记录是变量丢失还是 messages 被截断，这两条排查路径不同。

这 5 条每次改动后跑一遍，重点看的是「第几轮开始断」，而不是单轮回答好不好。第 1、3 条失败先查变量写入与覆盖，第 2、4 条失败先查请求里的 messages 数组，第 5 条失败先查窗口长度和截断优先级。回归用例也建议带上清理动作：会话复用时如果不重置变量，第 3 条的旧值残留很容易让下一次测试看起来像「记错了」。