学习文章地址来源学习地址思考“该怎么让服务端在多轮对话中稳定地恢复上下文状态并确认客户端传回的历史思考Thinking没有被篡改或伪造呢”原因大模型 API 并不在乎是不是“同一个用户”它连 Session 都不存它在乎的是“你这次传过来的历史上下文和思考过程是不是我上一轮原原本本生成的那一份”。这样改完就能和你结尾的“Cookie vs JWT”完美呼应答案我们可以借鉴传统后端开发中在HTTP请求头上设置一个cookie来唯一标识一个用户每次同一个用户再带着请求来到服务端的时候服务端通过检查这个http请求有没有我们特定的cookie值来看我们当前的用户的请求是不是第一次请求如果没有这个cookie服务端就默认是第一次请求给他分配一个唯一的cookie值然后客户端方面之后每次请求都要带上这个cookie值来标识。Claude 也是极其类似的无状态校验思路它通过给每次生成的思考块thinking block及其前面的所有上下文前缀system、tools、历史消息做一层数字签名。当下一轮请求来到服务端时服务端会重新计算前缀哈希来校验这个旧签名如果校验通过说明客户端传回来的“历史上下文 之前的思考过程”真实完整、一字未改服务端就会信任并复用这段历史思考让模型顺着之前的推理脉络继续往下想如果校验不通过或者前缀被改动了哪怕一个字符说明上下文和当初生成这段思考时的环境已经对不上了服务端就会直接报错返回 400或者静默丢弃所有失效的 thinking block让模型像“失忆”一样只能根据当前的消息从头开始重新推理。本轮结束时服务端再把本轮新追加的对话和新生成的 thinking block 打包签发一个新的数字签名随响应返回给客户端供下一轮请求继续携带校验。对于第一次请求因为客户端发来的消息列表里还没有任何模型生成的 thinking block即没有携带任何签名服务端就不需要做签名校验直接让模型从头开始推理等模型生成了第一段 thinking block 后服务端会把它和当前的 [system tools 第一条用户消息] 绑定在一起计算出**第一个数字签名Sig_1**返回给客户端从而正式开启后续轮次的“验签-续写-再签发”循环。之后的每次请求都会先校验旧历史信息的签名然后对本次请求的新进服务端的内容进行一个签名且因为采用的大概率是链式哈希来避免每次都对之前已经签名过的内容重新签名。cookie机制和Claude的数字签名也有一个不同点就是普通 CookieSession ID只是发给客户端一个随机号码牌真实数据存服务端内存里。Claude 的签名机制更像 JWT - JSON Web Token服务端自己不存你的历史记录而是把历史记录 思考过程全发给客户端自己保管服务端只在上面盖一个防伪钢印signature。下次客户端把“历史文本 钢印”一起交上来服务端验一下钢印和文本对不对得上——对得上就接着用要是客户端偷偷改了里面的字钢印当场失效