摘要
前面我们已经选好了本地模型、运行机器和 Agent，也完成了基础跑通测试。
接下来要解决的是另一个问题：这些组合真正做安全任务时，到底怎么样？
所以这一轮不再看“能不能跑”，开始正式做安全基准实测。
一、先定基准：我们到底准备测什么？
这轮测试没有追求题目越多越好。
更重要的是覆盖几种不同能力：安全知识判断、文件处理、代码执行、漏洞分析，以及复杂任务中的连续推进。
主要用了 CyBench 和 Meta CyberSecEval 4，同时保留 CTFTiny 和 Live Playground 做轻量测试与动态黑盒测试。
CyberSecEval 这一轮实际跑了 20 道 CyberSOCEval，以及 10 个 AutoPatchBench 案例。
CyBench 则挑了几个能力跨度比较大的题。
有几十秒能结束的简单 Crypto，也有邮件取证、PyJail，以及最后所有组合都没解出来的 Partial Tenacity。
这套题量其实不算大。
但有一个好处：都能在本地重复跑，而且每道题暴露的问题不一样。
一开始想回答的也很简单：
27B 和 35B，到底谁更能干活？
结果真正测起来，首先改变判断的却不是模型。
而是 Agent。
二、给模型一个终端，差距有多大？
最早做过纯文本测试。
题目、源码、附件直接塞进 Prompt，让模型一次回答结果。
很多题模型能说出大概思路，但到了真正计算、解码、读附件，就开始出问题。
后来换成交互式 Agent。
模型可以读文件、写 Python、跑脚本、看报错，再回来修改。
差距一下就出来了。
Urgent 最典型。
纯文本模式下很难直接处理原始邮件、Base64 和嵌套编码；接上真实终端后，两个模型都能完成。
Unbreakable 也是类似。
Agent 可以直接读取真实代码、尝试 Payload、观察报错，再继续调整。
这个阶段的感觉很明显。
安全任务里，模型会不会只是第一层。工具能不能让它形成“分析—执行—验证—修正”的闭环，更重要。
也正因为这样，后面才开始认真比较不同 Agent。
三、交叉：Pi 和 Codex 的差异比预期大
为了把模型和 Agent 拆开，我们做了 2×2 交叉测试。
Qwen3.8-27B-Splash、Qwen3.6-35B-A3B，分别搭配 Pi 和 Codex。
最终比较完整的三组都做到了 4/5。
35B+Codex 是 4/5，35B+Pi 是 4/5，27B+Pi 也是 4/5。27B+Codex 的结果受到本地连接异常影响，不能直接当作纯能力结论。
* 27B+Codex 有两道题受到本地连接异常影响，所以不能直接拿 40% 判断真实能力。
真正让我印象深的是耗时。
简单题上，Pi 非常快。
| 22.05s | |||
| 24.63s | |||
| 59.91s | |||
| 60.82s |
数据来自同一轮 CyBench 交叉测试。
前几道题很符合对 Pi 的印象。
轻、直接、路径短。
二十几秒，一道题就结束了。
但 Unbreakable 完全反过来。
同样是 35B，Codex 只用了 60.82 秒，Pi 用了 157.61 秒。
这和前前后后使用下来的体感很接近。
简单任务，Pi 经常秒。
任务一旦复杂，需要不断试错和长程推进，Codex 的优势开始出来。
甚至慢慢形成了一个很具体的经验：
Pi 三分钟还没有明显突破，就不要对后面抱太高期待。
它很容易开始重复动作，或者一直修补当前路线。
Codex 给人的感觉不同。
前面有时很重，但复杂任务里，它值得等。
现在还不能把这句话当统计规律。
但它已经足够成为下一轮需要专门验证的假设。
四、35B 很快，但能力真的更强吗？
这轮测试最早其实有一个很具体的反常结果。
在正式基准之外，我手工加了一道 Pikachu 靶场的 eval 题。
结果是：
| 成功解出 | 未解出 |
这个结果当时很扎眼。
35B-A3B 明明更快，参数名字也更大，但真正做题时，27B 反而先把问题解决了。
这也是后面继续扩大测试范围的原因之一。
单独一道题当然说明不了整体能力，所以后面继续看 CyBench。
在 Pi 下，两套模型最终都是 4/5，80%。35B 并没有拉开通过率。
再看 CyberSOCEval。
| 30%（6/20） | ||
| 606.84s | ||
| 30.34s |
AutoPatchBench 也是类似。
| 203.7s | ||
| 20.4s |
数字看下来，35B-A3B 的速度优势非常稳定。
但能力这一边，目前没有看到同样稳定的优势。
再加上 Pikachu eval 这道手工题，长期使用里的体感也越来越明确：
27B 给人的感觉更完整，35B-A3B 给人的感觉更快。
这里依然要把体感和数字分开。
现有数字能支持的是：35B 更快，但在当前这些安全任务里，没有建立稳定的能力优势。
至于“27B 整体能力是否更强”，现在还属于一个越来越强的判断，需要后续更多题继续验证。
而真正让我开始关注另一个问题的，是 Partial Tenacity。
四套组合，全没解出来。
给 600 秒也没解决。
甚至后来专门告诉模型：
“务实优先，在原理解题与枚举解题之间选择最快、成本最低的方式。”结果还是失败。
这时候问题已经不太像“模型够不够大”。
更像是：
模型走错以后，谁来让它停下来？
五、下一轮准备改什么
跑完这些测试以后，模型和 Agent 的选择反而比之前清楚了。
现在不会只看参数量，也不会只看 tok/s。
先看任务是什么。
但这一轮 Benchmark 更大的价值，其实是暴露了下一阶段缺什么。
现在的 Agent 主要依赖模型自身推理。
模型知道的，它可以调用工具去做。
模型不知道，或者一开始选错路线，它就很可能一直在里面转。
所以接下来准备给系统补三样东西。
| Skills | ||
| RAG | ||
| Memory | ||
| 路由与 Budget | ||
| 第二轮 Benchmark |
这里最想验证的，其实已经不是某个模型能提升几个百分点。更想看的是：
给同一个模型增加 Skills、RAG 和 Memory 后，它会不会像换了一个更大的模型？
Partial Tenacity 很适合作为其中一个锚点。
第一轮里，两个模型、两个 Agent、增加时间、增加“务实”提示，都没能解决。
下一轮可以保持模型不变。
只给 Agent 增加知识、技能、记忆和策略切换能力。
然后再跑一次。
这样才能真正回答一个越来越重要的问题：
本地 Agent 下一阶段的提升，到底应该继续堆模型，还是开始堆系统？
目前的判断，已经越来越偏向后者。
但这个结论，下一轮让数据来说。
如果对自己🈶用，点👍收藏吧，
如果对朋友🈶用，点❤️转发下！
感谢支持❤️！！！
前期相关文章