问题背景 昨天晚上睡觉的时候codex设置一个调研任务，利用 /goal 让它自己跑着。第二天起来的时候发现了当时使用的中转站额度没了，想着换一个中转站供应商把剩余的任务跑完。 然后就出现提示了： The encrypted content for item ... could not be verified. Reason: Encrypted content could not be decrypted or parsed. 翻译一下： 项目 ... 的加密内容无法验证。 原因：加密内容无法解密或解析。 问题分析 报错说的是：这次请求在供应商那一侧校验历史时被拒了——原因是历史里有一条 旧供应商留下的推理密文，当前的供应商解不开。 [!note]- codex会话信息层 一次会话不等于一份聊天记录，它由几层不同的信息组成（ 据 OpenAI 官方文档与会话文件结构整理 ）： 层 内容 作用 1 用户消息、助手回复 任务目标、约束、讨论、已公开的决定 2 工具调用与返回结果 执行过程和已拿到的证据 3 加密推理项 reasoning.encrypted_content 后续请求可复用的 内部推理状态 （一段不透明密文） 4 推理摘要、显示事件 客户端拿来展示已有过程 5 会话元数据、分页索引 定位会话、存设置、组织历史 6 工作区里已写入的文件 任务的真实成果 其中第 1、2、6 层是真正「看得见、要保住」的东西；第 3 层是模型私下传给自己的状态，用户看不见。 关键在第 3 层的密文（ reasoning.encrypted_content ），是 生成它的那一方加密出来的 ，跟那一方绑定。原来用的中转站生成了这段密文；换成新的中转站后，新的上游/账号 解不开别人的密文 ， 于是整条请求被拒——哪怕第 1、2 层的可见历史完全正常，它也会因为这一条解不开而 连坐整条请求 。 [!warning] 两点边界 至于究竟是 密钥、账号绑定还是兼容实现 哪一环不匹配，这里无法确证；但结果一致—— 密文跟生成方绑定，换方就解不开 。 并不是任意两家供应商都不通，取决于新供应商能不能解密你原来的密文。 为什么换个站就炸？ 不是会话坏了，是密文的归属方换了。 这也直接指向了解法： 把第 3 层删掉，其余五层全留 解决方案 一般就是两种法子（我经常使用的）： 一：直接删掉会话里的 reasoning.encrypted_content 记录。 原会话 ID和其余五层信息全部保住，任务原地续接；代价是隐藏推理丢失，中间没写出来的判断要重新推，模型可能改变原来的路线。 二：开一个真正的新对话，把旧会话的可见内容接过去 （消息、工具结果、工作区文件，或导出的纯文本）。风险最低，但会话连续性断掉， /goal 之类的自动续跑要重设，隐藏推理同样丢。 [!warning] 二有个坑 「新对话」必须是真正另起一个空白会话。 不要 用 ID 直接打开、继续旧会话，也不要 fork——旧历史会带着密文一起进来，报错原样复现。 具体选哪个，看个人需求： 历史不值钱、只想把任务跑完 → 二，最省事； 会话 ID 和完整历史必须保住（长任务、大量工具证据、 /goal 跑着）→ 一。 由于担心跑到一半的任务接不上、自动续跑断档，前面就白跑了，这个我就选择方法一。 我用的 思路 ： 然后随便找一个 ai修一下（我用的ds4.1）。 也可以固定搞一个脚本。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/12 18:13:27