跳到主要内容

工程实践：Yakit 插件商店接入 AI Agent 能力编排链路

· 阅读需 12 分钟
Yak Project
Yak Project
网络安全垂直语言团队

背景​

过去如果想拓展 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 公众号，阅读原文。