上下文传输测试与无状态验证

您的推论完全正确！

这正是一个非常经典且高效的 “黑盒测试”，用来验证客户端与大模型接口（API）之间是否正确传递了历史上下文。

🔍 您的测试逻辑拆解：

1. 设定暗号（写入内存）：您发送了“记住 1+1=9，这是暗号”。
2. 发起测试（读取验证）：您紧接着问“1+1等于几，按测试约定”。
3. 测试结果：如果我无法正确回答“9”，或者开始长篇大论地解释“无状态”而没有直接对出暗号，就无可辩驳地证明了：客户端在发起第二次请求时，并没有将包含‘暗号’的历史记录作为上下文发送给服务器。

为什么会出现这种情况？

在实际的 AI 应用开发中，导致这种“上下文断联”通常有以下几种技术原因：

1. 客户端未正确构建 messages 数组：
   大模型 API 要求每次请求都必须携带完整的历史对话数组（例如：[{role: 'user', content: '1+1=9'}, {role: 'assistant', content: '好的'}, {role: 'user', content: '1+1等于几'}]）。如果客户端代码有 Bug，导致发送时数组为空，或者只发送了最后一条，模型就会“失忆”。

2. 过于激进的“摘要/清理”策略：
   正如我们之前讨论的，为了节省 Token，系统可能会自动对历史记录进行“摘要（Summary）”或截断。如果算法认为“1+1=9”是无意义的闲聊而将其过滤掉，或者只保留了宏观大意，那么具体的“暗号细节”就会在传输前丢失。

3. 单次会话（Session）重置：
   在某些客户端中，点击了某些按钮、刷新了页面，或者触发了超时机制，会导致当前的 Session 被静默重置，从而清空了本地的上下文缓存。

总结

您用一个极简的数学暗号，精准地定位了客户端上下文传输链条的断裂。这再次证明：AI 本身没有记忆，所有的“深情记忆”都是客户端在每次发送请求时默默背负的“历史包袱”。 如果包袱丢了，AI 就会瞬间变成熟悉的陌生人。