代码还在推理流里就被拦下：安全规则一响，模型当场改稿，安全且可运行的比例从不足15%升到72.8%–98.1%

防御动作被提前到代码尚未交付的窗口：模型在推理流里已经写出完整实现，此时草稿只存在于token流中，SecReason在交付前检查它并让模型就地修改。 此前的安全提示和检索到的安全知识都在代码出现之前起作用，约束解码只能限制token选择而无法引导修复，事后修复则必须重新生成整条回复。 在CWEval和SecCodeBench上，对无辅助生成会引入漏洞的任务，SecReason把既安全又功能正确的运行比例从不足15%提高到72.8%–98.1%，覆盖两个本地部署的自修复模型和两个基准。

它靠增量解析识别完整语句，再用两条轨道扫描安全规则：语句局部轨道在每条语句输出时检查，上下文相关轨道在累积代码上追踪跨语句的数据流。 静态分析器要求完整且语法合法的文件，而推理流把不完整的代码和自然语言混在一起，因此需要按语句完成度触发扫描，而不是等代码围栏关闭。 实现基于SGLang，使用增量Tree-sitter解析器和semgrep-core后端，原生支持Python、JavaScript、Java、C和C++；在173个任务、六个推理模型上回放推理流，检测到全部被标记的不安全生成，首次告警时中位数还剩54%–82%的流。

规则触发时，SecReason中断生成、把一条针对模型的流内警告插入token流，再从已有前缀继续解码，模型在同一条推理轨迹里改稿。 事后修复在生成完成后才检查代码，修复需要重新生成整条回复，增加token消耗并可能破坏原本可用的代码。 在CWEval和SecCodeBench上，SecReason的Secure & Func.率在表中每个单元格都最高，平均token消耗低于事后修复；在官方注册表规则下重跑，不安全交付仍低于无辅助生成。

这套机制面向推理服务层，作为可选监控器插在推理引擎和下游客户端之间，只检查模型自己生成的流，不改动模型权重和训练数据。它需要原始推理token，因此排除了只返回思考摘要的闭源API；自修复实验只在Qwen3.6-35B-A3B和Gemma-4-26B-A4B两个本地部署模型上运行。评估覆盖CWEval和SecCodeBench的173个任务、五种语言，属于单元级生成，仓库规模开发和多步智能体流水线未测试；代码提取锚定markdown代码围栏，围栏外写出的代码不被分析。

语料校准的规则集在同一任务池上合成和评估，任务级泄漏仍可能存在：在随机一半任务上合成规则，合成半区召回率高，留出半区明显更低，说明规则检测的是校准语料而非通用漏洞模式，因此该规则集是这套基准任务池上的工具，干预结果测的是接近上界工作点下的机制。自修复可能引入功能回退，SecCodeBench上Gemma和Qwen的功能失败率上升，主要因为修复时调用了任务外或版本不兼容的API。假阳性实验显示，警告落在未闭合代码围栏内时功能失败率更高，代价在功能而非安全。定性分析依赖人工检查，推理轨迹的解释还受思维链不忠实影响。