网络安全 Harness 的悲歌

“无限游戏玩家”是James P. Carse写的《有限与无限的游戏》这本书中重要概念，核心概念是：有限游戏玩家的目的是赢得游戏，无限游戏玩家的目的是让游戏继续下去。

“无限游戏玩家”这个概念非常有趣，贴近实际场景来讲：当前行业中我们很多时候在聊的是：渗透测试谁是第一名？重要比赛谁是第一名？或者说产品行业占有率谁是第一名？你是2025年的第一名，还能是2026年的第一名吗？到了2027年，你做的事情和项目还活着吗？

与其说“无限游戏”，倒不如说你的产品和技术理念，是否可以无限运营下去？你的代码是否可以持续不断的更新，在未来的很多年都保持相当的生命力？

所以我们经过最近长期的思考，认为拥抱AI进行“无限期的”安全建设与运营才应该是产品存活的最关键的因素。这与古老智慧说的“流水不争先，争滔滔不绝”是一个基本概念。

受到各种网络安全从业人员视野和“赏金”等因素影响，很多的 AI 从业人员或安全服务人员会认为，网络安全 Harness 就是“渗透测试 Harness”，这是一个非常非常大的误区。相反的，渗透测试 Agent / Harness 只是网络信息安全的一个小领域。

显然，网络安全从业人员的日常工作肯定不仅限于“黑盒渗透测试”：
·对于 SDLC 工程师来说，每天甲方海量代码仓库更新，在有代码且有环境下的“灰盒”安全评估是一项重要工作；
·对于蓝队和需要“值班”的人来说，处理报警与流量分析，编写分析报告和封禁端口这些也是一项重要工作；
·对于审计系统来说，从日常流量中找出没有脱敏的数据，找出有危险请求的数据也属于一项重要工作；
·对于甲方运维安全场景来说，在已有台账的情况下，对资产台账进行日常的安全巡检仍然也是很有价值的场景；
·再扩大一些规模，对监管部门和资质评估来说，几十万家下级单位不可能每一家都高成本的“渗透测试”和“安全分析”，成本低廉+快速+可规模化的安全评估也是重要场景。

我们发现，要解决的问题这么多，专注“渗透测试” Harness 是有点过于一叶障目了。

甚至我们了解了上面场景，都会扪心自问一句：“网络安全 agent 的研发还有意义吗？”。其实我们不太需要正面回答这个问题：

很多渗透测试 Agent 的水平赶不上 WorkBuddy 多跑几轮；也赶不上 Pi Agent 只提供少量的工具（bash与文件读写）的基础型通用 Agent；同样的，如果 Claude Code 放开安全限制（Clawgod）它仍然具有不俗的安全工作能力。

那么换句话来说，这个 Agent 如果只是依赖 bash curl 基础工具的话，随着模型能力的提升，你又如何保证通用 Agent 在执行流程上满足不了安全领域的 Harness 需求呢？靠啥啥啥架构，靠知识图谱，靠所谓的 Ontology 本体论，靠控制论？没用的啦，你无法保证一些通用的 Harness 架构会不会在某个版本上具备这些组织能力。

通用的 Agent 或者一些巨头公司的 Harness 拥有比安全公司更高的研发成本和更专业的 APP 工厂流程，以及更加强悍的内部 AI 模型，有什么理由安全公司能在 Harness 架构这种通用问题上进行创新超过他们呢？别做梦了，超过了也会被瞬间抄走，“想法 idea”作为护城河，几乎一文不值。

安全 Harness 的悲歌就在这里了。价值的衡量已经不是技术本身了，而是有多少人用？烧掉了多少 Token 总量？产生了多少价值？有合同的产值是多少？而不是“我这个东西价值十万美金”。写的代码从来没有用户，并不能称之为创造多少产值。

当我们把一开始的“场景列举”和“安全 Harness 的悲歌”放在一起，基本也就拼凑出了我们作为安全乙方公司在未来的生存方向了：既然知识已经廉价，Harness 架构基础能力也是廉价的，那么我们就需要让网络安全 Harness 到更贴合场景的能力建设中去，去优化所有人的工作流程。

到问题发生的地方去，到真正需要我们的地方去。

我们需要把网络安全与 AI 当成一个无限游戏来玩，加入无限游戏俱乐部，我们需要持续不断的建设安全能力，贴合各种各样的场景，学习不断变化的场景，不断的使用AI来完善自己的能力，缩短安全从业人员与“场景”的距离。

我们经过上面的讨论，读者和一些从业人很容易陷入“科技加速主义”与“虚无主义”的陷阱，特别是我们谈到“能力建设”的时候，很多人觉得这个话题没有任何意义，因为“如果 AI 能写代码，那么 AI 就拥有了无限能力，我想要的工具没有，就让 AI 自己去造就完了！”。这是典型的“左倾冒进”的思想，这只回答了“技术可能性问题”，并没有回答“持续解决问题”的实现生产力问题：

•当你需要流量分析的时候，你需要现场让 AI 手搓一个 Wireshark 吗？

•当你需要访问一些特殊 TLS 网站的时候，你需要让 AI 手动现场去 Patch OpenSSL 吗？

•当你面对 10Gbps 的流量处理的时候，你需要让 AI 现场写一个高可用高负载优化的流量分析引擎吗？

•当你遇到畸形数据包的时候，你需要每次都让 AI 重新去帮你修复这个数据包吗？

AI 可以写代码，这就代表着无限的可能性是廉价的。关键是你烧不起钱，但是这只是你的问题，并不是行业的问题，总有人烧得起钱，这就意味着无限可能性并不代表你能做任何事情，并不代表你具备了无限能力。

AI 写代码具备了无限可能性，但是浪费的 Token 已经超过了你要做的事情的价值就产生了“负价值”，负价值没有太大意义。

但是既然我们提出了“要结合场景解决问题”，那就要讲如何更贴近场景解决安全能力。几乎全部的“安全领域独有的”知识和经验等内容，在动辄万亿的模型面前，几乎是完全不够看的，万亿规模的模型只需要带出你要做的事情，这些知识就可以几乎源源不断的吐出来。但是知识距离工程落地是有一定距离的。

假设 Harness 问题已经解决了， 那么你的安全领域的 AI 工作系统只提供一个 bash 等基础工具，那在具体场景上通常面临着“打不过 WorkBuddy 的问题”。据此我们如果为 AI 配套各种场景的能力扩展和工具系统，那么自然可以期待你的系统在更强的 AI 下发挥比别人更好的效果。

因此，使用 AI 去编写更适合特殊场景下的专业工具，远比些什么渗透测试 Agent 的 Harness 工程更加有价值。这本质上也相当于一种“蒸馏”：把人的经验和积累，配合强大AI的执行力，变成可以重复执行的场景化的专业工具。

很多人错把“无限的可能性”当成“无限的能力”，这是非常非常忌讳的。我们现在基本知道了作为安全从业人员，作为一个安全乙方，我们要做的事情，那么具体我们应该怎么去做呢？

如果我讲不出来，大家就会觉得整篇文章就是只会讲大道理的水文。那我自然是需要具体讲一些我们的工作，来证明我们的观点和对这些事情的看法是自洽的。当然下面的案例也是我最近非常喜欢也觉得非常有趣的技术更新。

熟悉 hyperscan 的应该是相当的“老登”了，这是 Intel 研发的一套多正则同时匹配的库，可以把很多正则编译成一个组，从而降低复杂度。例如你有1000个正则，你要匹配某一个文本，就需要1000个遍历匹配，但是通过 hyperscan 可以把复杂度从N条规则*M文本长度降到一次扫描，获得千倍提升。一些经典的工具 Snort 3 和 Suricata 都拿 Hyperscan 做多规则同时匹配，Zeek 的特征匹配、rspamd 的垃圾邮件规则也使用类似的技术，把规则先编成一份库，每个包或每封邮件只扫一遍。

但是这个技术也有它自己的缺陷：无法支持高级正则，不支持回溯功能，平台绑定在 SIMD 上，和 x86 深度绑定，慢路径和复杂场景无法编译，只能回答命中了啥，但是无法做更深度的拆解。

受到这个技术的启发，我们实现了一个新版本的技术迭代 MiniREHS（Mini-Regexp-HyperScan）现开源在 yaklang 的代码仓库中，这个库可以把几千条指纹正则编成一个规则：匹配内容只过一遍字面量自动机，没有必现字面量的规则直接跳过，命中点附近才跑小自动机，最后才把剩下的几条交给 PCRE2 抽捕获组。库可以落成镜像，下次打开不用重编。它比 Hyperscan 多接了环视、反向引用这类非正则写法，短横幅上的粗筛是几十微秒。我们可以用下面图标直接给大家展示一下 Minirehs 的神奇优势

简单来说，在 Yaklang 中所有规则匹配的场景，CPU利用率和时间上几乎都可以得到至少一个数量级的提升。

为了贴合“蓝队”的工作场景，我们也在持续建设 Yaklang 的流量分析能力。相比渗透测试，处理报警、分析流量、还原一次异常通信，这些工作的行业声量可能没有那么大，但是对于每天需要值班、排查问题和编写分析报告的人来说，这些都是很具体、很重要的工作。Yaklang 作为安全领域的 DSL，也需要在这个领域做积累，所以我们最近做了两个非常有意思的能力：

1.让流量变成可以查询和取证的数据库，可以把流量分析转变为对数据库的查询，避免反复编写流量分析脚本的尴尬浪费

2.通过 AI 长期任务，充分优化和扩充底层协议支持，我们希望是否在一个不远的未来，Yak 能具备 Wireshark 级的协议分析支持。

我们对流量分析和告警分析的一个改进，是把 Pcap 变成可以反复查询的数据库。PcapDB 保存原始报文、已解析的协议字段，以及会话和数据流之间的关联，AI 可以按时间、IP、端口和协议字段逐步定位问题，再沿着结果找到原始证据。导入流量包后反复查询，后续分析可以接着已有结果往下做，无需每次重新解析整份抓包、临时编写一套分析脚本。

同时，AI 既然擅长做“流量分析”，我们可以同时启动很多的 Agent 去互联网收集尽可能多的流量样本，让 AI 进行分析，从而来反过来迭代 Yaklang 的流量分析系统。我们希望最终 Yaklang 支持的 Yakit 和 Memfit AI 也可以具备 Wireshark 级的协议广泛支持，并且支持相当灵活的 AI 分析能力？经过一段时间的迭代，Yaklang 已经实现了四百多个协议的支持，具备可用性相当高的协议支持。

熟悉我们的同学对这个项目也大概听过，我们在 AI 出来之前，使用纯 Go 代码为静态代码分析系统专门写过一个 Java 的反编译器。AI 来了之后，这些东西并不应该被抛弃，它反而获得了更新的生命力，我们重新抽离出了 yaklang 仓库，开源在了 ：

https://github.com/yaklang/javajive，并且现在主要由AI来维护。

反编译器内部有不少有意思的算法。例如，支配树、后支配树与循环分析帮助判断分支在哪里汇合、循环从哪里进入，以及一个 break、continue 究竟属于哪一层结构；稀疏到达定义分析追踪变量在不同路径上的赋值，处理局部变量槽复用和循环中的值传递；异常区间索引和图分析缓存则减少复杂方法中的重复扫描。

这些分析最终都要反映在源码上：分支走向、循环出口和表达式求值顺序，需要与原始字节码对应起来。虽然一开始我只想把它作为一些 AI 的能力测试的习题：“AI 可以写反编译器吗？”；后来几个月内随着 AI 越来越强，AI 对 JavaJive 的维护越来越深入，现在已经可以独立修复一些非常棘手的问题：泛型恢复，非规约循环恢复等离谱边界情况。

我们设计了一整套专用的 Harness 来维持他们的“正确性”，我们设计各种复杂的原始 Java 代码来编译 class，然后让 JavaJive 反编译，然后在让 javac 重新编译，然后逐步 PK 执行效果，保证 md5, sha256 等算法都可以经历反编译重建输出一样的内容。

诚实来说，AI 对我们进行这些技术迭代的帮助非常大，几乎是几十倍甚至百倍提升的，但是在这种提升下，一次迭代的速度和从零积累出这些有趣的技术更新的速度是两回事儿。大家一定会有很多问题：上面的技术更新是很容易想到或者很容易意识到的吗？这些技术更新到底花了多久时间？烧掉了大约多少 Token？进行了多少实验和经过了多少测试的检验？同时这些技术服务了多少用户？

强如 Opus5.5 / Fable / Mythos 也无法一句话实现所有细节，有大量的内容需要编写 - 测试 - 修复这种典型的循环；对于 JavaJive 和 Pcap 分析这种需要大量积累，搜索等体力工作的活儿，AI 大人也并不能短时间内完成，这些“趁手兵器”的迭代本身也是领域内的重要工作。

对这些工具的理解，技术的实现仍然和“人”的经验深度绑定，而并不和“知识”绑定，不夸张的来说上面所有的知识，万亿级参数的 AI 都是具备的。人能否提出问题？能否设计出质量验证系统来保证“AI 生产工具”的正确性？当然，如果作为操刀手的“人”都不具备分辨专业和不专业的能力，那么这个人用AI生产出的内容和“一句话需求”也没啥不同。

Yaklang 在 AI 出来之前一直在讲一个“安全能力融合”的故事，其实在 AI 出来之后，这个故事不但没有落伍，反而在我们今天的话题下，变得更诱人了。我们有更强的安全能力融合系统，配合能力在线的 Harness，Yakit 和 Memfit 在安全领域能做的事情，几乎就像滚雪球一样越滚越大。

我们并不制造恐慌，也并不会吹嘘自己的 Harness 和其他的比有什么不同，有多大优势，整个安全的发展是不应该“有了锤子到处找钉子”，所谓的 Harness 应该是为解决具体问题服务的，是为节约大家时间来服务的，而不是为“第一名”和 PR，以及各种“虚荣心”服务的。

到数据生产端去，到场景中去！

话都说到这里啦，那就抽点Token吧！

评论区：💬畅所欲言！所有评论的小伙伴进行随机抽奖：

1、50元额度的 Yakcool.com 平台兑换码；4个；

2、30元额度的 Yakcool.com 平台兑换码；10个；

  3、最新款牛子哥帆布袋：10个；

  4、最新款牛子哥鼠标垫：10个。

  来吧，试试运气

  参与时间：

  2026.10.23 00:00-2026.10.27 18:00