Claude 和 GPT 这类闭源大模型的思维链被两步蒸馏已经不只是安全社区的猜测。公开的安全研究与社区实验表明攻击者不需要进入模型内部不需要拿到权重甚至不需要使用复杂的越权手段只要通过 API 发出精心构造的请求就可能把模型在推理过程中暴露出来的思路“教”给另一个开源模型。这个问题的本质是 API 暴露面与模型资产保护之间的矛盾调用接口的人既想获得高质量结果又可能把结果里的推理过程当作训练语料。对开发者而言这不是猎奇新闻而是设计模型 API、评估生成内容、配置日志系统时必须要纳入风险模型的一类问题。思维链Chain of ThoughtCoT是大模型在回答复杂问题时产生的中间推理过程。它让模型像人一样先拆解问题、逐步推理再给出最终答案。相比只输出答案思维链中包含的解题方法、提示模板、搜索策略和业务规则往往比最终结果更有价值。蒸馏则是一种模型压缩和知识迁移技术目的是把小模型的训练目标对齐到大模型行为上。当两者结合成“两步蒸馏”攻击时攻击者先从目标模型的 API 中采集带思维链的输入输出对再用这些数据微调一个开源模型就能在低成本条件下复现目标模型的部分推理能力。这篇文章会沿着“攻击原理 - 暴露点 - 检测方法 - 分层防御 - 排查误区”这条主线展开。如果你维护模型 API、做 Agent 应用开发或者在负责大模型安全评估可以按文中的体检表和防御清单对现有系统做一次针对性检查。先说明边界本文所有检测示例都用于作者自己的账号、自己的模型、授权范围内的安全评估不鼓励也不会详细展开任何绕过服务条款或攻击他人系统的方法。1. 思维链蒸馏攻击到底攻击的是什么1.1 思维链比最终答案更值钱的模型资产思维链不是某个模型的特定参数而是模型在生成最终答案前内部所形成的一串步骤化文本。常见的大模型会把这串文本以“思考过程”的形式写在最终回答前面也可能只在内部生成不对用户展示。从技术资产角度看思维链有价值的点在于以下几点。第一它包含可复用的解题策略。例如对一个数学应用题模型会先列出变量、再列方程、再求解。用户拿到这串过程后不只是知道结果还能知道“怎么想”。第二它隐含提示词模板。模型生成的思维链往往受到系统提示词和 few-shot 示例的影响。攻击者可以通过思维链反推系统提示词中要求模型遵守的步骤、格式和约束相当于把提示词工程的核心资产暴露出来。第三它是微调数据的重要来源。一个被标记为大模型输出的高质量思维链对开源模型的监督微调非常有用。即便缺少原模型内部参数只要输入输出对数量足够开源模型也能学到类似的推理模式。因此思维链泄漏不是“多输出了一段文字”那么简单。它可能把提示词资产、业务规则、评估标准和推理策略一并带走。1.2 蒸馏把小模型“教”成接近大模型的行为传统模型蒸馏是指用大模型教师模型的预测结果或中间特征来指导小模型学生模型的训练。深度学习蒸馏最常用的方式是软标签蒸馏教师模型为每个分类输出一个概率分布小模型去拟合这个分布从而获得更平滑的泛化能力。大语言模型时代的蒸馏有了更简单的形态。研究者不再依赖软标签而是把教师模型生成的文本直接作为训练数据对学生模型进行监督微调。这种方法的门槛很低因为大模型 API 返回的就是可读文本收集数据不需要访问模型内部结构也不需要计算梯度。在这个背景下“模型蒸馏”和“使用 API 输出训练自己的模型”之间的边界越来越模糊。只要用户拥有调用权限输出文本就已经进入用户的可控范围。服务条款可以限制用户不得将其用于训练竞争模型但技术上很难区分“正常调用”和“数据采集”。1.3 “两步蒸馏”的攻击范式拆解标题中的“两步蒸馏”听起来很神秘其实在安全研究语境下它对应的是两个清晰的阶段。第一步是数据收集。攻击者向目标模型发送带有明确推理要求的请求让模型输出完整的思考过程。少量高质样本在早期蒸馏中非常关键因为大模型对某个固定题型只需要几十条到几百条示例就能把解题套路迁移到开源模型上。收集到的数据会被清洗、去重、标注最终整理成指令微调数据集。第二步是能力迁移。攻击者使用这些数据对开源基座模型进行监督微调或者使用知识蒸馏方法让学生模型拟合教师模型的输出分布。训练完成后攻击者再通过测试集对比学生模型与目标模型的回答一致性判断蒸馏是否成功。这种攻击之所以能被反复讨论是因为它的成本主要集中在大模型 API 调用费用和微调算力上。而随着开源模型基础能力的提升学生模型原本就具备较强的推理能力思维链数据只需要帮助它调整格式和策略因此所需样本量比训练一个全新模型要少得多。1.4 为什么说这是 API 暴露面的问题把这个问题称为“API 致命漏洞”并不意味着网络层存在可以被注入的漏洞。更合理的理解是模型 API 的产品设计暴露面过大导致模型资产难以通过技术手段保护。传统 API 漏洞往往涉及权限绕过、注入攻击或数据越权。思维链蒸馏攻击则完全不同攻击者使用的是正常接口、正常参数和正常调用方式最终拿到的也是正常响应。它没有突破请求鉴权也没有读取别人的数据只是利用了“输出文本可以被复制和应用”这一天然属性。所以真正需要修复的不是单个安全漏洞而是一组暴露面模型在响应中暴露了思考过程开发者没有在网关层剥离敏感字段日志系统完整记录了提示词和推理文本服务条款无法落地成技术控制模型输出的同质化让攻击者容易验证蒸馏效果。把思维链蒸馏当作 API 暴露面问题来治理才能在设计层面找到系统化防线。2. 泄漏从哪里来API 设计里的 CoT 暴露点2.1 响应字段直接返回推理文本最容易理解的暴露点是 API 响应体里直接带有思维链字段。不同模型服务商的字段名不同常见的有reasoning、thought、chain_of_thought等。有些模型默认不返回但调用方可以通过参数、提示词或特定模型版本触发。对生产者而言这个字段可能原本是为“可解释性”或“审核需要”而保留的。一旦它进入响应体就会成为数据收集的直接来源。攻击者不需要解析长文本只要把响应 JSON 里对应的字段完整保存就能批量构建数据集。因此模型服务方在对外提供 API 时必须明确一个问题返回内容中哪些字段属于产品功能哪些字段属于内部推理过程。内部推理字段不应出现在面向普通用户的响应契约里也不应通过公网 API 直接下发。2.2 few-shot 示例成为“活体教材”思维链不只会出现在最终输出中还可能隐藏在 few-shot 示例里。少样本提示词中为了让模型理解任务格式开发者往往会提供“问题 - 思考过程 - 最终答案”的完整示例。这些示例如果被完整构造进 API 请求那么攻击者可以通过反复观察模型在不同提示下的输出推测示例中每一步的作用。更危险的是某些评测系统为了获得稳定的推理格式会把思维链模板作为系统提示词的一部分。攻击者使用越权或者普通用户提示注入让模型把系统提示词内容复述出来就能直接获得模板文本。这类模板一旦流到公开数据集里就会变成后续蒸馏训练中的重要监督信号。2.3 日志与可观测性系统二次扩散很多模型 API 的生产系统会记录完整的请求和响应日志用于调试、计费、安全审计和效果分析。如果日志中同时包含用户输入和模型思维链一旦日志存储权限配置不当、接入第三方日志分析平台或者日志保留时间过长思维链就会在模型服务方一侧二次扩散。排查这类问题不能只看在线接口还要看离线链路。需要检查的不只是 API 网关还包括日志采集 agent 是否抓取完整响应体日志平台是否存在长期保存策略数据分析任务是否会读取模型响应表内部员工是否有权限查看原始 prompt 和 response 中的敏感字段。很多蒸馏数据的来源不是黑客攻击而是开发者在排查问题时把一段包含模型推理过程的日志粘贴到了内部文档再被同步到外部协作平台。数据一旦脱离受控环境就难以确认流向。2.4 Agent 场景让上下文被整段导出当大模型用于 Agent 场景时暴露面会进一步扩大。Agent 应用中模型不仅要回答问题还要调用工具、读取文档、执行代码并把整个上下文回传给用户或前端。思维链此时不再只是一段孤立文本而是与业务数据、工具调用记录、文件内容混在一起。例如一个用于客服的 Agent 在处理退款流程时模型可能先输出“用户符合退款条件原因是订单状态为已签收”再调用退款接口。如果 Agent 平台把完整上下文保存到聊天记录并允许用户导出那么模型内部的决策依据和业务规则就同步被导出。这也是为什么很多模型服务商在 Agent 化之后开始把“思考过程”和“可展示结果”分开管理。思考过程可以被系统记录用于调试但不应被当作聊天记录内容展示给最终用户。2.5 参数对蒸馏难易的影响攻击者在收集蒸馏数据时会尝试不同的推理参数。不同参数对蒸馏数据质量的影响如下表所示。参数对数据收集的影响常见设置错误理解temperature采样随机性越高同一问题产生的思维链越多样0.0 到 0.3 用于稳定数据误以为设为 0 就不会被蒸馏max_tokens决定思维链能否被完整输出需要足够空间容纳整个推理过程限得越短越安全但会导致业务回答截断top_p控制候选 token 的采样范围通常与 temperature 配合使用降低后仍无法阻止文本被复用seed部分模型支持固定随机种子便于复现结果用于效果回归测试无法作为防泄漏控制手段参数能影响蒸馏数据的稳定性和多样性但它不是安全措施。只要模型能够在响应中输出关于推理过程的内容攻击者就有办法通过多次采样、不同提示或模型版本组合来收集数据。真正的控制点在响应内容设计和访问策略上。3. 给 API 做一次 CoT 泄漏体检3.1 先梳理接口的输入输出契约要判断自己的 API 是否存在思维链泄漏第一步不是写攻击脚本而是梳理 API 的输入输出契约。把每个开放接口的请求字段、响应字段、必填参数、可选参数列出来重点关注是否存在与“推理”“思考”“解释”相关的字段。可以用一个简单的表格记录接口名称请求字段响应字段是否存在推理字段该字段是否对业务必需/v1/chat/completionsmessages, temperature, max_tokenscontent, reasoning是否/v1/responsestext, reasoning_summary是否/v1/agent/runcontext, tool_outputmessages, metadata是否梳理完接口再对照前端页面和 SDK 实际使用的字段。如果前端只展示content但接口返回了reasoning那么reasoning字段就是高风险暴露点。3.2 用最小请求探测响应字段在自有账号和授权模型上做安全评估时可以构造一个最小请求观察接口完整返回体。示例用 Python requests 库完成。import requests API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key payload { model: your-model-name, messages: [ { role: user, content: 请先写出思考过程再给出最终答案。问题一个两位数加 32 等于 128这个两位数是多少 } ], temperature: 0.0, max_tokens: 1024 } response requests.post( API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload, timeout30 ) data response.json() print(data)这个请求故意要求模型展示思考过程目的是检查响应体里是否存在额外字段。如果返回 JSON 中出现了reasoning、thought、thinking之类的键那么这些字段已经通过 API 到达调用方网络环境。此时需要判断该字段是否是产品设计的一部分。如果接口提供流式输出还需要检查带stream: true的请求。流式响应常常逐 token 下发整个生成内容推理过程可能混在多个 chunk 中。开发者不能只验证普通响应还要对所有传输方式做同样检查。3.3 检查日志、缓存与上报链路只检查 API 响应体还不够还要检查数据经过的日志和上报链路。推荐按以下顺序排查。第一检查应用网关日志。在开发环境打印一条完整请求然后到日志系统里搜索请求 ID确认日志中是否包含整个响应 JSON。如果包含说明推理字段已经进入日志。第二检查数据库字段。模型调用记录表、计费表、调用分析表是否存在raw_response或model_output字段。这些字段如果被宽表存储任何能读取该表的数据任务都可能拿到思维链。第三检查第三方数据分析工具。很多团队会把模型日志接入 ClickHouse、Elasticsearch 或阿里云日志服务再配置采集规则。需要确认采集规则是否只采集了指定字段还是抓取了整个响应体。第四检查前端埋点。有些产品会采集模型输出文本用于用户体验分析。如果埋点包含思维链那么用户端上报系统也会成为泄漏渠道。3.4 评估开源小模型是否已经“学会”你的推理如果怀疑已有外部模型在输出上与自己的模型高度相似可以做一个更进一步的评估收集一批自己模型的代表性答案再让可疑的开源模型回答相同问题比较两者的思维链结构和最终答案一致性。可以用简单的相似度脚本做初筛。这里给出一个基于文本相似度的概念示例用于比较两段回答。from difflib import SequenceMatcher def similarity(text_a: str, text_b: str) - float: return SequenceMatcher(None, text_a, text_b).ratio() sample_a 模型A的回答文本 sample_b 开源模型的回答文本 score similarity(sample_a, sample_b) print(f相似度: {score:.2f})文本相似度高不等于一定发生蒸馏因为同一个推理模板可能来自公开论文或社区提示词。要更准确判断需要进一步分析思维链中的专有术语、步骤顺序、特殊格式标记。如果发现开源模型的输出中出现了与自家系统提示词高度一致的结构就需要回到日志链路上排查数据从哪里流出。3.5 体检报告样例完成上述检查后可以输出一份 CoT 泄漏体检报告。报告模板如下。检查项结论风险等级修复建议普通响应是否包含推理字段是高网关剥离该字段流式响应是否混入思维链是高流式协议增加字段过滤日志是否保存完整响应体是中字段级脱敏关闭原始 body 存储数据仓库是否存储模型输出原文是中建立受控访问权限前端埋点是否采集思维链否低保持现状开源模型是否存在高相似输出待确认中持续监控恢复告警机制体检报告不能只给结论还要给出修复负责人和预期完成时间。只有把“是否泄漏”变成“在哪泄漏、怎么泄漏、谁负责修”风险才能真正被收敛。4. 从网关到模型层的分层防御4.1 响应层把思考过程与最终答案分离最直接的防御不是训练一个“不会思考”的模型而是从产品设计上把思考过程和最终答案分离。对外 API 的响应契约只保留必要字段模型内部的推理过程只进入受控的后端日志不进入公网响应体。在网关层可以增加字段过滤。示意配置如下。api-gateway: response-policy: enabled: true allowed-fields: - content - id - model - usage strip-fields: - reasoning - thought - chain_of_thought - internal_metadata stream-filter: enabled: true mask-tokens: - type: reasoning_token action: drop这段配置表达的是在网关返回给调用方之前把响应体中的推理字段剥离流式输出中匹配到推理 token 时直接丢弃。实际项目里字段名需要根据模型服务商的实际返回体调整。这里有一个取舍如果产品本身需要展示推理摘要例如给用户提供“思考过程摘要”的体验就不能一刀切全部删除。此时建议单独设计reasoning_summary字段由系统对完整推理内容做摘要后再输出避免泄露完整思维链。4.2 接入层调用频率、身份与流量特征识别蒸馏攻击往往带有明显的流量特征例如单个账号在短时间内高频调用同一类问题、请求内容高度模板化、响应结果被完整保存。接入层可以使用以下手段提高攻击成本。限制单位时间内的调用次数尤其是带推理字段的请求。对批量请求做频率控制使用令牌桶算法控制并发。对同一账号的请求内容做去重检测识别大量相似提示词。对可疑账号输出行为进行风控标记并要求完成更高等级的身份验证。频率限制不能完全阻止蒸馏因为攻击者可以使用多个账号、多个 IP 或分布式环境绕过基础限流。它更大的作用是提高数据收集的工程成本让攻击者需要投入更多账号资源和 API 费用。4.3 数据层日志脱敏、访问控制与水印日志系统必须在写入前做字段级脱敏而不是把原始响应整包写入。推荐使用 JSON Schema 校验日志字段只允许记录以下内容请求 ID、模型名称、接口名称业务侧定义的输入摘要最终答案字段模型消费的 token 数、延迟、状态码风险判定结果。推理字段在日志中应直接被丢弃或者加密存储并配置短期自动清理。所有能读取模型响应数据的内部系统都要接入访问控制按“最小必要”原则授权。水印同样是可选项。模型服务方可以在思维链中嵌入难以察觉的特定短语或格式标记一旦发现外部模型输出中出现相同标记就能反向定位到数据来源。不过水印不是完全可靠的攻击者可以清洗文本、改写步骤或者用水印生成器自动重新生成数据。水印应作为辅助手段配合日志和监控一起使用。4.4 训练层蒸馏攻击检测与对抗防御从更长远的角度看模型服务方还需要持续训练蒸馏攻击检测器。检测器可以学习已知 API 请求中正常用户与采集型用户的差异输出风险分数。常用特征包括请求内容的信息熵相邻请求之间的文本相似度请求是否覆盖了固定的题型或模板调用时间分布是否均匀且高频是否批量接收完整模型输出并长时间保持连接。对抗防御则是在模型训练或部署层加入“反蒸馏提示”让模型在遇到可疑请求时拒绝输出完整思维链或者只输出经过压缩的推理摘要。这种方式需要模型本身具备意图识别能力属于更深层的策略但效果上很难做到完全抵御。4.5 防御检查清单发布模型 API 前建议逐项确认以下清单。层级检查项状态响应层普通响应不包含内部推理字段待确认响应层流式响应不包含思维链 token待确认接入层账号级调用频率限制已配置待确认接入层请求内容相似度检测已开启待确认数据层日志不保存原始响应体待确认数据层数据库访问权限已收敛待确认训练层模型可被强制输出推理摘要待确认监控层外部模型相似度告警已建立待确认检查清单不应变成一次性动作。模型版本升级、网关规则变更、日志平台切换都可能重新引入风险建议每个迭代周期重新运行。5. 典型误区和排查路径5.1 误区一认为 temperature0 就能阻止蒸馏温度参数控制的是采样随机性不是访问控制。把 temperature 设为 0只代表模型更倾向选择概率最高的 token并不代表它不会输出思维链。攻击者依然可以通过提示要求模型“先列出解题步骤”也可以在多次请求中改变提示措辞收集稳定结构的数据。防御要落在字段过滤和内容策略上不要依赖随机参数。在排查时如果发现自己的 API 已经把温度调低但仍被大量采集说明问题在响应字段或访问频率控制上。5.2 误区二认为关闭日志就切断了扩散链路关闭应用日志可以减少一部分内部扩散但思维链还可能通过前端埋点、第三方监控 SDK、流式网关缓存、数据库审计表等渠道进入外部环境。只关日志而不检查完整数据链路会漏掉真正的扩散点。正确做法是绘制模型数据的流转图从模型服务生成 token 开始到网关、后端应用、前端页面、日志平台、数据仓库、分析任务每一个环节都要标注字段。只要某个环节存在完整思维链即使应用日志已关闭风险仍存在。5.3 误区三只检查提示词不检查输出 token 分布很多团队在做安全方案时只对用户输入做关键词过滤忽略了对模型输出 token 分布的分析。蒸馏数据和正常使用之间的差异往往体现在输出端。正常用户调用模型通常只需要最终答案输出 token 中不会长期保存推理过程。采集型账号则相反它请求的响应会包含大量步骤化文本并且这些文本会被完整写入调用方的本地数据。对模型服务方而言可以根据推理类 token 的占比、分布和保存特征来判断调用行为是否异常。如果排查工作只停留在“提示词是否命中敏感词”就无法发现这类隐蔽采集行为。5.4 从现象倒推根因的排查表当发现模型推理能力疑似被复制时按这个顺序排查。现象常见原因检查方式处理建议外部开源模型输出和自家回答高度一致少样本提示模板或思维链模板泄漏对比输出文本结构、专有术语、步骤顺序收紧系统提示词可见性增加水印API 响应 JSON 中多出推理字段响应契约未做字段白名单控制查看网关响应日志比对 SDK 字段网关剥离推理字段更新契约文档日志平台存储了完整模型响应采集规则设置为整包抓取进入日志平台搜索请求内容关键字配置字段级解析删除历史原始 body单个账号调用频率异常高缺少账号级风控查看调用 QPS、请求内容相似度增加频率限制和异常告警数据仓库可被读取模型输出的表权限模型过于宽松查看表授权和访问审计日志收紧访问权限开启审计排查时不必一开始就怀疑攻击者使用了高级技术。先确认输入、请求字段、响应字段、日志链路、存储权限这些最基础的环节大多数问题都能在这里找到答案。6. 落地建议与下一步6.1 按风险等级分级治理不同模型资产的敏感程度不同不建议对所有 API 采用完全相同的防御强度。可按风险等级做分级治理。低风险场景例如公开知识问答、闲聊、开放领域文本生成思维链即使泄漏破坏力有限。此时可以只做基础字段过滤和日志脱敏。中风险场景例如代码生成、数学解题、规则推理思维链中包含的方法论可能被其他模型复用。此时应强制分离思考过程增加调用频率限制并对高价值题型设置单独的访问审计。高风险场景例如私有业务规则、安全策略、金融风控、医疗决策思维链一旦泄漏会直接影响业务安全。此时建议把这类模型放到私有化环境或内部网关后不通过公共 API 对外暴露并在模型输出时配置更严格的摘要策略。6.2 学习环境与生产环境差异学习环境里开发者经常为了调试方便直接打印完整响应体并把包含思维链的响应保存到本地笔记本。这没有问题因为学习环境不承载真实业务数据。但同一套代码如果直接进入生产环境风险会立刻升高。需要在不同环境上做配置隔离学习环境允许打印完整响应用于理解模型行为开发环境使用模拟接口不接真实生产模型测试环境开启字段过滤验证过滤规则是否生效生产环境强制剥离推理字段并禁止把模型响应写入可公网访问的存储。建议在 CI 流程中加入契约测试确保 API 响应字段在模型服务商升级后仍然符合内部白名单。否则一次 SDK 升级就可能把新出现的reasoning字段带入生产日志。6.3 后续可以关注的方向思维链蒸馏问题还在快速变化中可以持续关注以下方向。一是模型提供商对推理字段的产品策略调整。不同服务商正在尝试把思考过程重写为摘要或者在流式接口中加入专门的推理 token 标记。跟随官方文档更新及时调整网关过滤规则。二是反蒸馏训练算法的进展。研究者正在尝试让模型在推理过程中对敏感提示产生更强的防御行为这类方法还不成熟但可以作为后续技术选型的储备。三是行业侧的合规要求。随着大模型服务逐渐进入企业核心业务数据资产保护的合规要求会更明确。思维链是否属于商业机密、是否属于用户个人信息、日志保留期限如何设定都会成为生产系统设计的新约束。对想深入学习的开发者建议从一个小实验开始在自有账号和自有模型上构造一份包含思维链的响应然后追踪它在网关、日志、数据库中的去向。把这条链路完整画出来再对照本文的防御清单就能直观理解为什么思维链蒸馏攻击难以用单个技术手段彻底阻断。真正有效的方案一定是响应设计、访问控制、日志治理和监控告警共同作用的结果。