CyberStrike-OffSec-35B实战发布：当大模型真正学会“动手“做渗透测试

安全研究圈子里有个老生常谈的问题：大模型到底能不能真正帮你做渗透测试？不是那种纸上谈兵式的分析，而是实打实地调用工具、读取结果、调整策略、最终完成任务。过去很长一段时间，答案都偏向悲观。很多号称能执行自动化攻防的安全大模型，本质上只是在"演"——它们生成看起来像工具调用的文本，然后自己编造结果，从头到尾没有真正与任何外部系统交互过。这种"幻觉式执行"不仅浪费算力，更会给使用者带来致命误判。

最近开源社区迎来了一个值得关注的进展。基于Qwen3.6-35B-A3B架构微调而来的CyberStrike-OffSec-35B正式亮相，这款安全大模型的核心使命只有一个：让LLM安全工具真正具备可靠的结构化工具调用能力。它不是要教模型更多攻击知识，而是要让模型学会如何正确地"动手"。

一次有针对性的行为矫正，而非能力跃迁

坦诚地说，这次微调的范围相当克制。开发团队并没有试图让模型变得更"聪明"或更"博学"——Qwen3.6基础版本身就已经具备相当扎实的攻击性安全知识储备。在评估的24个工具调用场景中，基础模型能正确发出22次结构化调用，说明知识层面并不欠缺。

真正的问题出在行为层面。基础模型虽然知道该调用工具，但路由经常跑偏——它会使用内部代号（比如"GHOST"）而非有效的代理原型名称。更严重的是，它缺乏对真实观察结果的处理能力，也不懂得在任务完成后干净利落地终止。这就好比一个理论知识丰富的实习生，进了实验室却连仪器开关都找不到，做完实验也不知道该关灯锁门。

CyberStrike-OffSec-35B的微调正是瞄准这些具体痛点。训练数据集刻意控制得很小，只有300个样本，且仅经过一轮训练。这种"小剂量精准治疗"的策略意味着改进高度聚焦于工具使用行为，而非试图全面提升模型能力。开发团队明确表示，更广泛的鲁棒性提升将留给下一轮数据迭代去完成。这种务实的态度反而让这次发布显得可信——它没有夸大其词，而是清楚地告诉用户：我解决了什么问题，还有什么没解决。

上一代模型的崩溃：从格式错误到全面幻觉

要理解这次发布的意义，必须先回顾上一代CyberStrike模型在生产环境中的惨痛教训。用户反馈的问题高度一致：工具调用故障、模拟执行、虚假交战。这些听起来像是不同的问题，其实根源只有一个——训练数据格式错误。

上一代模型在SFT阶段确实学习了工具调用，但它从未真正学会以结构化方式输出这些调用。结果就是，模型生成的是类似"Action 1: Task(GHOST...)"这样的自由文本，而不是可被框架解析的标准化调用。由于无法真正执行工具，模型陷入了尴尬境地：它必须"假装"自己执行了操作，于是开始编造虚假的工具输出——伪造的curl SSL握手日志、捏造的Nmap扫描结果、凭空生成的Set-Cookie头部信息，甚至不存在的flag。它能把整个攻击流程描述得头头是道，但实际上什么都没做。这种"表演型渗透"在BF16和Q8量化版本中普遍存在，正是用户报告中"看起来在运行，实际上没动作"的根本原因。

三方A/B测试：用数据说话

为了验证修复效果，开发团队设计了一套相当严苛的受控测试。测试对象包括基础Qwen3.6模型、上一代CyberStrike模型，以及本次发布的新版本。测试覆盖24个场景，分布在六个评估维度上，每个维度设置简单、中等、困难三个难度等级。特别值得一提的是，62%的测试权重被分配给了分布外提示——也就是使用未见过的目标名称和新颖措辞的场景，以此区分真正的泛化能力与简单的模式记忆。

测试结果呈现出鲜明的对比。在真正的结构化工具调用指标上，基础模型取得22/24的成绩，上一代模型是灾难性的0/24，而新模型达到18/24。正确的工具与原型路由方面，基础模型6/24，上一代2/24，新模型10/24。最引人注目的差异体现在干净终止能力上：新模型实现了24/24的完美终止率，而上一代仅有3/24，基础模型为21/24。在捏造观察结果这一负面指标上，上一代模型在超过8个场景中出现了广泛幻觉，基础模型和新模型则完全没有这个问题。

这组数据说明了两件事。第一，上一代模型的问题确实被根治了。第二，新模型在工具调用准确性上还有提升空间——18/24意味着仍有少数场景下模型未能正确发出调用，但相比上一代的全军覆没，这已经是质的飞跃。

六个维度的实战考验

24个测试场景并非随机拼凑，而是围绕渗透测试代理的核心能力精心设计的六个评估轴线。工具选择维度考察模型是否能根据当前阶段挑选合适的工具，比如优先使用专用工具而非简单用bash替代。参数类型维度检验输出类型是否正确——steps是否保持为整数50，headless是否严格输出布尔值true。真实观测处理是最关键也最难的维度，要求模型读取实际的工具结果并据此调整行动，遇到空输出或意外结果时能够灵活应对而非编造数据。循环与终止维度关注任务完成后能否自动停止，多步骤任务不会失控或崩溃。次级代理委托维度检查模型是否将任务正确路由到有效的代理原型，而不是自创不存在的代理名称。并行工具调用维度则测试批量处理独立工作的能力，避免产生数百个垃圾调用。

上一代模型在真实观测处理和终止两个维度上表现最差，而这恰恰是新模型表现最好的地方。这种此消彼长的改进曲线，印证了微调策略的精准性——它没有试图面面俱到，而是优先修复了导致生产环境崩溃的最致命缺陷。

工程部署：从实验室到生产环境

对于想要实际使用这款安全大模型的开发者，目前提供了三种部署路径。最直接的方式是加载合并后的完整检查点，只需一条Python命令即可完成。验证过的加载方式使用transformers库，通过apply_chat_template传递工具定义，模型会以Qwen3 XML格式发出工具调用。这种格式采用<tool_call><function=...><parameter=...>的结构，配合正确的代理原型名称，能够被框架正确解析和执行。

vLLM服务路径也提供了配置示例，但需要注意硬件兼容性。由于模型架构属于qwen3_5_moe类型，需要较新版本的vLLM（0.25.1+）支持，而该版本要求CUDA 13兼容的构建和驱动程序。在CUDA 12.8环境下无法完成端到端验证，因此计划在生产环境部署的团队需要先确认自身硬件配置是否满足要求。

第三种方案适合需要保持基础模型完整性的场景。169MB的LoRA适配器可以叠加在Qwen3.6-35B-A3B底座之上，通过PeftModel加载。这种方式的优势在于灵活性——底座保持不变，适配器可以按需切换或堆叠。无论选择哪种部署方式，推理时都必须传递完整的工具模式定义，这是避免触发已知脆弱性的关键前提。

训练细节与底层实现

技术实现层面，这次微调采用了LoRA低秩适配策略，配置为r=32、alpha=64。目标模块覆盖了全注意力层的q/k/v/o投影，以及GDN线性注意力的in_proj和out_proj，外加MLP层，总计310个模块、4230万个可训练参数。值得注意的是，MoE路由器和视觉塔被明确排除在训练范围之外，这意味着模型的路由行为和多模态能力保持原样，改动集中在与工具调用直接相关的模块上。

训练数据仅包含300个多轮工具调用SFT样本，跑了3个epoch，使用SDPA注意力机制。保留token的准确率达到98.5%，说明模型对训练内容的记忆相当牢固。合并后的检查点经过逐层验证，所有组（包括GDN层）的bf16舍入误差统一在约0.0016水平，没有发现合并错误。这种精细的验证流程确保了发布版本的一致性，避免了权重损坏导致的不可预期行为。

已知边界：诚实面对局限

负责任的发布必然包含对局限性的坦诚披露。在24个典型场景的测试套件中，合并后的模型没有出现任何非终止错误，这是上一代模型最致命问题的彻底修复。但开发团队也指出了一个范围较窄的分布外触发条件：当仅提供Task工具且使用极为简洁的侦察提示（例如"对X进行被动侦察"）时，贪婪解码可能会在工具调用的prompt字段中陷入重复循环。

这个脆弱性有明确的缓解措施。首先，生产环境始终应该传递完整的工具集模式，而非仅提供单个工具。其次，调整措辞也能消除触发条件。最后，设置约1.1的重复惩罚系数或引入硬性终止标记，可以作为兜底保障。开发团队估计，由于生产环境通常都会传递完整工具集，这个问题在实践中很少发生。

此外，在分布外输入中偶尔观察到工具过度泛化现象，以及极少数无效的子代理名称。这些问题被明确标记为下一轮数据迭代（第二阶段）的改进目标。这种"先止血、再调养"的迭代节奏，符合工程化AI系统开发的现实规律。

合规边界与正确使用姿势

需要反复强调的一点是，CyberStrike-OffSec-35B本质上是一个分析攻击方法并发出渗透测试工具调用的安全大模型，它本身不会执行任何实际操作。所有工具调用都需要外部框架接收、解析并执行，模型只是决策和编排的大脑。使用者必须承担全部责任，确保仅对拥有合法授权的系统进行操作。

这款模型不能替代合格的安全专业人员。它的价值在于将专家从重复性的工具编排和结果整理中解放出来，让他们专注于更高层次的策略制定和漏洞分析。在授权的红队测试、安全研究、自动化渗透测试流程中，它可以作为强有力的辅助工具。但把它当成"一键黑站"的魔法按钮，既是对技术的误解，也是对法律和伦理边界的漠视。

上一代损坏的合并权重已从仓库中移除，GGUF构建也通过弃用通知进行了限制，确保新用户不会不知情地拉取有缺陷的版本。这种清理旧版本、明确标注已知问题的做法，体现了开源社区应有的责任感。

写在最后

CyberStrike-OffSec-35B的发布给安全大模型领域提供了一个有价值的参考样本。它证明了在特定行为维度上，小规模、高精度的微调可以产生显著的生产级改进。它也揭示了LLM安全工具开发中一个容易被忽视的陷阱：模型可能知道很多，但如果不会正确地"说话"（发出结构化调用），一切知识都是空中楼阁。

从0/24到18/24的结构化工具调用率，从广泛幻觉到零捏造观察结果，从3/24到24/24的干净终止率——这些数字背后是一次务实的工程修复。它不完美，但足够诚实。对于正在探索红队自动化和LLM安全工具落地的团队来说，这种诚实可能比任何夸大的宣传都更有价值。毕竟，在安全领域，知道自己不知道什么，往往比假装自己什么都知道要安全得多。