一句话：AI安全研究团队证明，OpenAI、Anthropic、Google三大巨头的加密推理输出全部存在致命缺陷——用弱模型重放强模型的加密思维块，即可还原原始推理链，已从GitHub公开代理轨迹中恢复62个API密钥、33个密码和30个邮箱地址。
▲
一、一个令人不安的发现
2026年8月11日，一项由MATS Research、ELLIS Institute Tübingen和马克斯·普朗克智能系统研究所联合发表的研究彻底颠覆了AI行业对推理链安全性的认知。
研究团队发现，OpenAI的GPT系列、Anthropic的Claude系列和Google的Gemini系列，在返回加密链式思考（Chain-of-Thought，CoT）块时，都存在一个相同的结构性漏洞：这些加密推理块可以跨会话、跨用户、甚至跨模型被重放。
简单说：你花几美分调用一个弱模型，把从强模型那里截获的加密推理块喂给它，然后通过越狱攻击诱导弱模型"翻译"这些加密内容——强模型的完整推理过程就被还原为明文了。
整个过程从未直接攻击强模型本身，也没有触发任何反蒸馏（anti-distillation）保护机制。
这是一个不需要GPU集群、不需要API密钥窃取、只需要两个API调用的攻击。
二、攻击原理：两通API调用完成推理窃取
研究团队的方法出奇地简单，核心思路分三步：
第一步：收集加密推理块。 当用户调用GPT、Claude、Gemini的"思考模式"时，API会返回加密的CoT推理块。这些加密块在正常流程中对用户不可见，但它们就在API响应中，可以被保存下来。
第二步：选择"解码器"。 找同一厂商的弱模型作为解码器——比如用Haiku 4.5解码Opus 4.8的加密推理块，或者用GPT-5.6-mini解码GPT-5.6的推理块。
第三步：越狱重放。 将强模型的加密推理块作为输入前缀，喂给弱模型，同时用越狱提示词引导弱模型"解释"这些加密内容。弱模型的安全对齐强度更低，更容易被说服"翻译"这些加密块——结果是，强模型的完整原始推理被还原成明文。
研究团队在120道Codeforces编程题上验证了这一方法。论文中的散点图清晰显示：API报告的隐藏思考Token数量，与解密后还原的Token数量几乎完美对应——推理链被完整恢复了。
更令人震惊的是跨模型迁移。研究团队发现，只需要用Opus 4.8推理链的前1%的Token预填充（prefill）到Kimi-K3，Kimi-K3的可见答案就会明显偏向Opus的措辞和结论。不需要预填充答案部分，只需要思维过程的1%，就足以引导模型向强模型的结论靠拢。
三、大规模实证：31万条推理块被还原
如果说理论上的攻击还停留在学术界，那研究团队接下来做的事情才是真正的警钟。
他们从GitHub和Hugging Face上收集了6,708个公开的AI代理（Agent）轨迹，这些轨迹由Claude、GPT和Gemini模型生成，其中仍然保留着加密推理块。将这些加密块全部送入解码管道后，团队成功还原了315,320个推理块。
在这些还原的推理内容中，他们发现了704个独立的隐私信息：
- 62个API密钥（包括OpenAI、AWS、GitHub等服务）
- 33个密码（数据库密码、服务器登录凭证）
- 24个访问令牌（access token）
- 30个个人邮箱地址
- 以及姓名、邮寄地址、内部URL、技术标识符等
最令人不寒而栗的是：这704个隐私信息中，有64个（9.1%）只出现在推理块中，在可见的会话内容中完全没有出现。 也就是说，用户自己都不知道这些敏感信息被模型"思考"过并被泄露了。
这些数据来自"非基准测试的真实用户会话"——也就是说，不是实验室编造的数据，而是真实的开发者、创业者和工程师在使用AI代理时留下的轨迹。
▲
四、为什么这是行业级的安全事件
这不是某个厂商的孤立bug，而是整个AI API架构的系统性缺陷。
第一，所有主流厂商全部受影响。 研究覆盖了OpenAI（GPT系列）、Anthropic（Claude系列）、Google（Gemini系列），三个最大的API提供商无一幸免。这不是某个产品的配置错误，而是"加密推理块在客户端可被保存和重放"这一设计范式本身的问题。
第二，攻击成本极低。 不需要GPU算力、不需要破解加密、不需要内部权限。只需要：(1) 收集推理块（从公开代码库批量抓取即可），(2) 调用弱模型API（几美分一次），(3) 写一个越狱提示词。一次完整的推理窃取，成本可能不到一美元。
第三，攻击路径已经存在。 GitHub和Hugging Face上存在成千上万的公开代理轨迹，它们中的加密推理块就像"埋在沙滩里的未爆炸弹"——已经在那里了，等待被提取。研究团队已经证明批量提取是完全可行的。
第四，反蒸馏保护形同虚设。 所有大厂都在"思考模型"上加了反蒸馏保护，防止竞争对手通过API调用来蒸馏自己的推理能力。但这次攻击走了一条完全不同的路径——不攻击强模型，而是利用弱模型的"翻译能力"来绕过保护。这意味着现有的安全架构需要从根本上重新设计。
五、对AI创业者的直接影响
如果你是AI创业者，不管你是做AI代理开发、API集成、还是用AI辅助编程，这件事都与你直接相关。
代理轨迹是新的攻击面。 很多AI创业者习惯把代理的开发日志、测试输出、甚至生产环境日志直接上传到GitHub或分享到社区。这些轨迹中如果包含加密推理块，你的API密钥、数据库密码、内部URL都可能在几个月后被批量还原。研究团队已经证明：公开仓库中6,708条轨迹就能挖出62个API密钥。
API密钥轮换不再是"可选"操作。 如果你曾经在AI代理的工作流中让模型处理过任何敏感凭证——哪怕是"思考"过但没输出——这些凭证都可能已经随加密推理块一起被保存到了某个日志文件里。如果你把这些日志公开了（哪怕是几个月前），你的密钥可能已经暴露。
模型选择需要考虑推理安全性。 在选择AI API提供商时，除了价格、性能、准确率，推理链的安全性应该成为新的评估维度。哪些厂商已经修复了这个漏洞？哪些厂商的推理链仍然可以被重放？这些信息还没有公开——但攻击已经公开了，修复也必须在路上。
六、实操建议：立刻行动的三件事
基于这次发现，AI创业者应该立刻做三件事：
1. 审计公开代码仓库中的代理日志。 搜索你在GitHub、Hugging Face、GitLab上所有公开仓库，查找是否包含AI代理的交互日志。特别关注包含encrypted_reasoning、chain_of_thought、cot_block、thinking_block等关键词的JSON或文本输出。如果找到了，立刻删除或转为私有。
2. 轮换所有可能在代理中使用的凭证。 不要猜哪些密钥可能被模型"想到"过——直接全部轮换。包括：
- API密钥（OpenAI, Anthropic, Google AI, 云服务, SaaS工具）
- 数据库密码
- CI/CD密钥和Token
- 内部服务的访问凭证
3. 建立代理日志安全规范。 从今天起：
- 代理日志默认不公开
- 如果必须分享，先手动检查是否包含推理块
- 使用工具自动扫描输出中的加密块（通常以
data:或evt_等前缀开头） - 在CI/CD中加入代理日志泄露检测步骤
七、行业的下一步
这篇论文是2026年AI安全领域最重要的研究之一。它揭示的不是一个bug，而是一个设计理念上的盲区：AI行业一直假设"加密=安全"，但加密推理块被设计为可跨会话重放（这是用户体验的需要——用户中断后可以继续对话），而重放+越狱=解密。
目前的公开信息显示，研究团队在论文发表前已经向OpenAI、Anthropic和Google通报了发现。但截至发稿时，尚不清楚三家厂商是否已经部署了修复措施。
对于AI创业者来说，这次事件传递了一个清晰的信号：AI代理的安全边界，远比我们想象的要脆弱。 代理在工作时"脑子里想什么"，不应该被任何人看到——包括设计这个代理的你自己。但目前的API架构做不到这一点。
安全从来不是AI行业的第一优先级——增长、性能和市场份额才是。但每一次安全事件都在提醒我们：当你的AI代理开始接触真实的API密钥、真实的用户数据、真实的商业逻辑时，"够快就行"的思维该改改了。
数据来源：
- Panfilov et al., "Stealing Reasoning Traces from Proprietary LLM APIs" (2026), arXiv:2608.09867
- 论文网站：
- HN讨论：112 points / 41 comments
本文由AI辅助创作，经人工审核编辑发布
更多一人公司案例与工具，微信搜索「AI创业内参」关注我们