插件商店“活”了!Yakit 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 

新记录 

Yakit  v1.4.7-0424

1. 上线部分功能模块英文翻译

2. 优化WebFuzzer侧边栏展开逻辑

3. 修复手动安装证书未打开脚本文件位置的问题

4. Webfuzzer侧边增加AI

5. 修复流量分析页面排序和展示错误的问题

Memfit AI v1.0.1-0424

1. 增加工具库和技能库页面

2. 历史会话可恢复时间线、文件系统、流量和漏洞风险

3. 修复任务规划定位问题

4. 修复知识库Ai召回白屏问题

IRify v1.2.2-0424

1. 代码扫描增加配置可排除合规规则

2. 修复报告过大导出空白PDF报告的问题

Yaklang 1.4.7-beta1

1. 修复 Java 反编译器在 Windows 下处理嵌套 JAR 路径异常问题

2. 修复 MCP 工具缺少必填参数时 Schema 错误生成 “required”: null 导致解析失败问题

3. 修复调试插件同名参数仅发送首个的问题

4. 修复 ReplaceHTTPPacketQueryParam 仅替换首个重复 query 参数的问题

5. 修复 AI 输出事件中模型名称与服务名称为空或不准确的问题

6. 修复 SSA PHP 解析问题（nowdoc/heredoc 换行符、?> 识别）

7. 新增 HTTP/2 与 HTTP/1 连接池分离，提升并发并修复资源泄漏问题

8. 优化 MITM 流量提取：按「规则+内容」聚合，支持跳转请求溯源

9. 优化 Memfit 模型回调继承逻辑，避免异步任务降级

10. 优化 Memfit 意图识别与知识库动态更新能力

11. 优化 Memfit 任务规划核心 Prompt

12. 优化多认证越权测试插件（多值输入、分组能力增强）

13. 新增 Memfit AI Forge / Tool 元数据字段（作者、标识、时间等）

14. 新增 Memfit AI Forge：scan_risk_analysis_project、sf_project_scan_check

15. 新增 Memfit 会话自动关联扫描结果（绑定 Runtime ID）

16. 重构 Memfit 任务验收机制（由强制改为多信号触发）

17. 新增 Yak MCP 项目管理能力（查看、创建、切换项目）

18. 隐藏冗余插件，仅保留【修改 HTTP 请求】

YAK官方资源 

Yak 语言官方教程：

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