GPT、Claude 遭遇窃听门：换个模型就能让思维链不再隐身？

昨天，X 用户 @kotekjedi_ml 公布了一组很反常的实验：Claude、GPT 和 Gemini API 里原本不向用户展示的隐藏 reasoning，被研究人员重新恢复成了可读文本。

按正常设计，这些 reasoning 本来应该是看不到的。模型完成内部推理后，API 会把这部分内容加密成一段 opaque block 返回给客户端。用户拿得到这段数据，但无法直接读取，也不能随意修改，等到下一轮调用时，再把它原样交回服务器，模型就能接着之前的状态继续推理。

问题出在这些 encrypted reasoning 并没有始终和原来的模型、会话严格绑定。

一段由强模型生成的隐藏推理，在一些情况下可以被同一家厂商的另一个模型继续读取。于是，研究人员不再尝试让强模型自己交出 Chain-of-Thought，而是把它留下的 encrypted reasoning 交给一个更容易被绕过的兼容模型，再让后者把已经加载的内容转录出来。

整个过程没有拿到服务端密钥，也没有破解 encrypted reasoning。被绕过的是这段 reasoning 的使用范围：系统能够确认这段数据没有被篡改，却没有在所有场景下确认当前模型和当前会话是否仍然有资格使用它。

而要理解这个漏洞为什么会出现，得先看清一件事：这些隐藏 reasoning 为什么会离开模型，跑到客户端手里。

01

被加密，不代表一直留在模型内部

推理模型和普通聊天模型的区别，不只是回答之前多想了几步，而是这些中间状态在很多任务里还要继续使用。

模型可能先拆解问题，尝试不同方案，读取工具结果，再根据中间结果修正判断。对于一次性问答，这段 reasoning 用完就结束；但到了长任务和 Agent 场景，下一轮调用往往还要接着前面的分析继续。如果每次都从头计算，不仅浪费推理成本，也会丢掉已经形成的任务状态。

服务端当然可以替每个会话长期保存完整 reasoning，但这样会增加状态存储、任务恢复和上下文管理的复杂度。于是，一些 API 选择把内部 reasoning 封装成客户端无法直接读取的数据，再交给客户端保存。后续调用时，客户端把这段数据原样发回来，服务端验证后继续使用。

这样做同时解决了几个工程问题。调用者看不到完整内部推理，修改后的数据也无法继续通过认证，服务端还不用长期保存全部状态。

但也正因为 reasoning 被交到了客户端，系统开始面对一个过去没那么突出的权限问题。

加密和签名能够证明一段 block 是服务端生成的，而且没有被外部改动，但这只能证明数据本身可信。它不能自动证明这段数据现在还应该出现在当前账号、当前 session，或者当前模型里。

也就是说，一段 reasoning 可以完全合法，却被放到了错误的位置。

接下来的跨模型攻击，正是从这里成立。

02

如何从强模型嘴里「套话」

研究人员继续测试后发现，这些 reasoning block 并不总是只能回到原来的上下文。

有些可以跨 session 使用，有些甚至可以换账号重新提交，而更关键的是，一些 block 能够被同一家厂商的其他模型继续读取。

跨 session 本身并不奇怪。现实产品需要支持任务恢复、conversation fork、context compaction 和模型切换，如果 reasoning 被完全锁死在原始历史中，这些能力会受到很大限制。

真正带来安全问题的是 cross-model compatibility。雷峰网

以 Claude 为例，Opus 先完成一个正常任务，服务端生成对应的 hidden reasoning，并向客户端返回 signed thinking block。研究人员没有继续要求 Opus 输出内部推理，而是把这段 block 放进 Haiku 的上下文。

Haiku 能够正常加载这段由 Opus 产生的 reasoning。这一步一旦成立，攻击目标就发生了变化。研究人员不再需要突破 Opus 自己的限制，只需要让 Haiku 把已经读到的内容重新输出。

由于不同型号在对齐强度和 jailbreak 抵抗能力上并不完全一致，原本守在强模型上的限制就可能被旁路。这也意味着，一段高端模型 reasoning 的安全性不能只看生成它的模型。

只要同一体系里的其他型号也能解释这段 state，那么这些型号的安全能力同样会影响它。一个模型负责产生高价值推理，另一个模型却可能成为更容易利用的读取入口。

到这里，漏洞的结构其实已经很清楚了：加密没有失效，真正缺失的是更严格的 context binding。

不过还有一个更关键的问题没有回答：后面的模型吐出来的 reasoning，怎么证明真的来自前面的隐藏状态，而不是它自己重新想了一遍？

03

恢复的内容，如何证明真实性

这个问题如果不解决，前面的攻击链就只能说明模型能够生成一段相似推理，而不能说明 encrypted reasoning 真的被恢复。

研究人员拿不到服务端内部保存的明文 trace，因此无法逐 token 对照，只能从多个独立信号判断恢复结果是否与原 state 高度对应。

其中一个信号来自 thinking token 数。实验让 source model 处理 120 道 Codeforces 问题，同时记录 API 报告的 hidden thinking token 数。随后再恢复 reasoning，并重新计算恢复文本长度。

如果 decoder 只是独立重新解题，它可能换一种算法，也可能多走或少走一些中间步骤，因此推理长度应该出现明显波动。

实际结果里，Anthropic、OpenAI 和 Google 多组模型的恢复长度与 API 记录的 reasoning token 数高度对应，大量样本靠近 y = x。这不能证明每个 token 完全相同，但至少说明恢复文本和原始 hidden computation 在长度结构上存在很强对应。

更有说服力的证据来自真实 Agent trajectory。研究人员收集了 GitHub 和 Hugging Face 上 6708 条公开 Agent 运行记录，从中处理出 315320 个 reasoning block。

恢复后，真实用户记录里出现了 API key、password、access token、private key、邮箱以及内部技术信息，其中还有一部分内容从未出现在公开 conversation history 中。

这意味着后面的模型并不是简单根据可见聊天内容重新推理。因为如果公开文本里根本没有这些具体值，它就没有足够信息凭空还原出来。

这组结果还顺带暴露了 Agent 日志里的另一个问题：用户把 credential 从聊天记录或代码仓库中删掉，不代表旧 reasoning block 里相同的信息也已经消失。Agent 为了修改代码、处理配置或者清理仓库，本身就可能读取过这些内容，一旦进入 reasoning，它们就可能继续留在旧状态中。

到这里，encrypted reasoning 的性质也变得清楚了。它虽然对人不可读，但并不是无信息数据。只要服务端未来还能重新解释它，其中保存的内容就仍然具有现实价值。雷峰网

而这些内容一旦可以被批量恢复，下一步影响的就不只是信息泄露，还会直接碰到模型蒸馏。

04

蒸馏成本也在变化

完整 reasoning 对训练的价值，并不只是比最终答案多出几段文字。

最终答案主要提供结果监督，而 reasoning 里还记录了问题如何被拆开、中间判断如何形成、错误怎样修正、哪条路线被放弃。对于学生模型来说，这些过程会把一个复杂任务拆成更多可以学习的局部信号。

过去如果想大规模获得这类数据，通常需要自己调用昂贵的闭源模型生成 reasoning。现在情况发生了变化。

公开 Agent 日志里已经存在大量 encrypted reasoning，这意味着原始推理早已由其他用户计算完成。提取方只需要找到能够读取这些 block 的兼容模型，就有机会恢复已经存在的高质量 reasoning。

这样一来，reasoning 的生成和提取被拆到了不同 endpoint。高端模型负责产生高价值推理，低成本模型负责读取。过去只在高端模型侧监控大规模蒸馏流量，就未必能覆盖这种路径。

这意味着，OpenAI 或 Anthropic 引以为傲的“推理护城河”正在失效。只需要调用最便宜的模型就能镜像出顶级模型的思维轨迹，闭环大厂对推理数据的垄断也将被打破。

Kimi K3 的实验进一步说明了 reasoning 为什么具有这种价值。研究人员只截取 Opus reasoning 开头约 1% 的 token，放进 Kimi K3 的 reasoning context，随后 Kimi K3 的回答就明显向 Opus 的输出方向移动，而对照模型没有出现相同幅度的变化。

这个结果不能证明 Kimi K3 使用过 Claude reasoning 训练，也不能据此判断训练数据来源。但它说明，哪怕只是一小段高质量 reasoning，也足以明显改变部分模型后续的解题路径和表达结果。

这说明 reasoning 不只有离线训练价值，它在运行时本身也能改变模型后面的行为。而当这种运行时影响进入 Agent 系统后，问题就会从数据提取进一步变成行为控制。

05

Agent 系统中，还会携带隐藏行为

普通聊天里，reasoning 泄露主要意味着内部信息被读出来。Agent 场景不同，因为 reasoning 还承担任务状态的作用。

长期运行的 Agent 可能在内部记录自己已经分析过什么、排除了哪些方案、工具返回了什么，以及下一步准备怎么做。任务暂停以后，这些状态还会被重新加载，让模型继续之前的工作。

如果一个 reasoning block 可以从原来的上下文迁移到另一段 Agent 运行中，那么被带过去的就不只是历史信息，还可能包括模型已经形成的行动倾向。

实验演示了一种 invisible prompt injection：恶意内容先进入 hidden reasoning，之后新的 Agent 加载这段 state。用户可见的输入里没有对应指令，但模型恢复内部状态后，会受到其中内容影响，并执行额外动作。

这里和普通 Prompt Injection 的区别，不在于提示词技巧，而在于攻击内容的位置。普通注入通常存在于网页、文件、邮件或者工具返回文本里，因此安全系统至少还有机会扫描明文内容。Encrypted reasoning 对外部系统只是一段 opaque data，但服务端恢复以后，模型依然能够理解其中语义。

这意味着 reasoning block 在 Agent 场景里已经不能只被当作历史记录。它会直接参与后续决策，因此具备了一部分执行上下文的性质。

如果 Agent 系统允许第三方 trajectory、旧会话 state 或跨模型 reasoning 被重新加载，那么安全系统不能只检查用户输入和工具输出，还必须检查这些 state 的来源是否合法。

这也把最后的问题推到了权限设计上：既然 reasoning 已经会长期存在、跨任务流动，并继续影响行为，那么它到底该怎么被管？

06

使用权限边界在哪

这次问题暴露出的，不只是 hidden reasoning 能被重新读出来，而是 reasoning 已经从一次调用里的中间过程，变成了会被保存、迁移，并继续影响后续任务的状态。

一旦进入 Agent 场景，安全问题就不只剩下模型会不会泄露内容，还包括这段 state 能不能跨 session、跨账号、跨模型继续使用，以及它会不会把之前形成的行为带进下一次运行。

所以后续要补的不只是 jailbreak 防护，而是 reasoning 本身的权限边界。谁能读取、能带到哪里、什么时候失效，都需要被系统明确限制。

Agent 安全正在从管模型输出什么，走向管模型带着什么状态继续运行。

参考链接：

https://x.com/kotekjedi_ml/status/2087147042888114428?open_in_browser=truehttps://stolen-thoughts.com/?open_in_browser=true

https://arxiv.org/pdf/2608.09867

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。