先说结论：不透明字段不是“无害乱码”，发布日志时仍要当作敏感数据

现代推理 API 为了维持多轮对话，可能把模型的隐藏推理包装成客户端看不懂的不透明块，再要求客户端在下一轮原样传回。这样服务端不必保存全部状态，也能让对话继续。论文指出，如果这些块能在不同会话、用户或同一供应商的不同模型之间复用，较弱、限制较少的模型就可能被诱导恢复其中的内容。风险不只关系到模型公司的推理知识产权，也关系到代理在中间步骤里见过的用户数据、工具输出和凭据。

作者报告从公开仓库收集 315,320 个推理块，并在聚合分析中发现 367 项个人信息和 182 份凭据。这个数字足以推翻“正文看不到密钥就可以公开整份日志”的习惯，却不能被扩大成全网泄露率：论文承认没有原始明文作为 ground truth，无法完全验证每个提取 token；扫描是针对性演示，不是随机、完整的互联网普查。内容标题和缩略图都应把数字归因给论文，而不是写成平台已经确认的全球统计。

创作者和开发团队现在可以做的，是清日志与缩小爆炸半径

公开 agent 会话、演示录像、终端输出、bug report、数据集或仓库前，不仅要扫描 `API_KEY`、token、密码、邮箱和连接字符串，也要删除 `thinking`、`signature`、reasoning blob、raw response 与无法解释的不透明字段。历史上公开过原始会话的项目应重新扫描 Git 历史、release 附件、issue、对象存储和训练数据；发现可能暴露的凭据后立即撤销和轮换，而不是等别人证明密文已经被解出。

防御还要靠最小权限和短生命周期：把代理使用的密钥限制到具体服务与动作，设置金额或调用上限，避免把生产管理员凭据直接放进模型上下文，并让日志保留期限与访问权限可审计。平台侧则应把密文与会话、用户、模型和用途绑定，减少可移植范围。最好的中文内容不是复现越权步骤，而是提供一份可执行的发布前清单和事故响应表；读者也可以向搞着玩实验室免费提交自己的日志脱敏流程，公开讨论如何验证而不暴露真实秘密。