目录

• 1. Agent 的困境：工具很多，却缺一个“调度员”
• 2. reverse-skill 的定位
• 3. 核心架构：意图识别、安全边界、技能路由
• 4. 逆向方向的技能路由设计
• 5. 渗透方向的技能路由设计
• 6. 路由决策的核心信号
• 7. 一个最小可行的路由配置示例
• 8. 聚合与反馈闭环
• 9. 落地建议与合规边界
• 10. 结语

1. Agent 的困境：工具很多，却缺一个“调度员”

安全研究方向的 AI Agent 通常不缺少工具：Ghidra、radare2、Frida、x64dbg、nmap、httpx、nuclei、Burp Suite……真正难的是让 Agent 在正确的时间选择正确的工具，并把多轮结果串成一条可追溯的分析链路。

很多团队在搭建安全 Agent 时，习惯采用最直接的做法：把全部工具的商品说明、参数 schema、示例用法一次性塞进模型上下文，然后让模型“自己看着办”。这种朴素方案在玩具任务上看起来能用，一旦进入真实工作流，Agent 很容易出现三类典型问题：

第一类：乱调用。 任务明明是“分析一个 PE 样本”，模型却可能先去跑 Web 漏洞扫描器；目标明明是“提取某个 ELF 的导入表”，模型却调用了一个需要 GUI 的调试器。造成这种偏差的根源不是模型不够聪明，而是它缺少一个显式的“任务到工具”的映射层——当几十个工具同时出现在上下文里时，模型只能依据工具描述做软匹配，一旦描述简短、名称相近或任务表述模糊，选错工具就几乎不可避免。

第二类：浅尝辄止。 很多 Agent 只执行第一轮工具调用，拿到一个初步输出就急着下结论：看到 UPX 字符串就判断“肯定加壳了”，看到某个端口开放就判断“该服务存在明显风险”。它没有基于上一轮结果继续深入：没有尝试脱壳后再做静态解析，没有对开放端口做指纹识别和漏洞验证。安全分析的价值恰恰在于“顺着线索往下钻”，而不是“拿到第一条结果就停下”。

第三类：上下文爆炸。 一次性注入过多工具说明和原始输出后，真正有用的线索被淹没在大段日志、报错堆栈和格式化文本里。随着任务轮次增加，上下文不断膨胀，模型开始遗忘早期的发现，甚至出现“前面已经确认是 ELF，后面又当成 APK 分析”的离谱失误。

reverse-skill 要解决的就是这个问题：它不是再造一个“更强的模型”，也不是简单增加更多 system prompt，而是给 Agent 增加一层逆向与渗透任务的路由大脑——一个显式、可替换、可审计的技能调度层。它解决的不是“模型会不会”，而是“模型该不该调、下一步调什么、结果如何继续被消费”。

2. reverse-skill 的定位

reverse-skill 可以理解为一个技能编排层，位于“用户/上游任务”与“底层安全工具”之间。如果把底层工具比作安全研究 Agent 的“四肢”，把大模型比作“大脑皮层”，那么 reverse-skill 更像是连接两者的“小脑 + 脊髓”：它不负责产生最终结论，但负责把模糊意图翻译成明确的动作序列，并在动作之间传递结构化的中间状态。

它的核心职责可以归纳为四件事：

1. 任务分类：识别任务属于逆向、渗透、取证还是报告归档；这一步决定后续使用哪一套技能域和评价标准；
2. 意图转译：将自然语言或上游结构体转换为可执行的“技能意图”，例如把“帮我看看这个样本干了什么”转成 artifact_type=PE, intent=analyze 这样的结构化信号；
3. 技能路由：从技能库中挑选最合适的技能链，并根据安全边界、时间预算、可用工具等约束决定是否直接执行、降级执行还是转向人工确认；
4. 结果聚合：汇总各技能输出，归一化成统一的线索卡片，形成下一轮决策或最终结论。

它与几个常见方案有明显区别：

• 比起单纯的 function calling，reverse-skill 强调“先路由、后调用”，在进入工具前增加了一层显式决策，避免模型在高维工具空间中盲目选择；
• 比起把工具说明硬塞进上下文，reverse-skill 采用“按需注入”策略，只把与当前技能相关的工具和 schema 暴露给模型，显著降低上下文噪声；
• 比起写死在代码里的固定流程，reverse-skill 把“何时调用什么”抽成可配置的规则和策略，既能人工审计，也能随样本数据持续优化。

它的设计目标不是替代人工渗透测试工程师，而是把重复、机械、可结构化的部分自动化，让模型把注意力集中在真正的分析判断上。换句话说：自动化的是“流程”，不是“判断”。

3. 核心架构：意图识别、安全边界、技能路由

整个路由大脑可以抽象为一条流水线，每一个环节都应当是独立、可替换、可审计的模块：

下面对每个环节做展开说明：

• 意图识别器：接收用户原始输入（可能是一句话、一个文件、一段日志），输出结构化的任务描述。它至少需要完成“领域分类”（逆向/渗透/取证/归档）和“意图抽取”（analyze、scan、debug、report 等），必要时还需要从输入中识别出目标类型、目标地址、附件信息等关键字段。

• 安全边界检查：这是整条流水线的“闸门”。在调用任何有副作用或可能触线的技能之前，必须先检查任务的合规性。判断依据包括：目标是否在授权测试范围内、是否包含明文凭据或敏感个人信息、是否要求生成具有明确攻击性的产物（如免杀、一键入侵）。不符合边界的任务应直接拒绝并给出解释，而不是“先跑了再说”。

• 技能路由器：根据意图、目标类型、约束条件给候选技能打分，选择得分最高且高于阈值的技能链。路由器不直接执行工具，它只负责“决定下一步做什么”；真正的执行由技能单元完成。这样设计的好处是：路由策略可以独立调整，而不影响底层工具实现。

• 技能域：将技能按领域分组。逆向技能域通常围绕文件与二进制展开，渗透技能域围绕资产与攻击面展开，报告与归档域负责把前者产生的线索沉淀成可读的产出物。域的作用是缩小路由时的搜索空间，避免在逆向任务中遍历渗透工具。

• 技能单元：最小的可执行能力，比如“文件类型识别”“导入表解析”“端口扫描”“子域枚举”。每个技能单元有明确的输入、输出、调用条件、超时和风险等级，可以单独替换、测试和审计。

• 结果聚合器：把技能单元产生的原始输出洗成统一的“线索卡片”格式，供路由器进行下一轮决策，或供报告模块生成最终结论。聚合器是反馈闭环的关键，没有它，多轮路由就只是多次独立调用，无法形成连续推理。

其中每个节点都不一定是“一个模型调用”，而是一个可独立实现、可替换、可审计的技能单元。生产环境中，意图识别器可能用一次 LLM 调用，安全边界检查可能纯靠规则引擎，技能路由器可能用轻量打分函数——模块边界比实现方式更重要。

4. 逆向方向的技能路由设计

逆向任务通常围绕“样本是什么、它做了什么、它如何实现”三个问题展开。技能路由可以按输入类型和意图进行分流，核心原则是：先定性，再定位，最后验证。

下表是按输入与意图拆分的典型逆向技能域：

技能域	典型触发条件	建议工具/能力	输出物
文件识别	输入为未知二进制	file、magic、哈希计算、熵分析	文件格式、架构、加壳特征、熵值
静态解析	需要导入表、导出表、字符串	objdump、readelf、dumpbin、strings	关键符号、可疑字符串、节区信息
反编译分析	需要理解函数逻辑	Ghidra、IDA、radare2	伪代码、函数调用图、交叉引用
动态调试	需要观察运行时行为	Frida、gdb、x64dbg、strace	Hook 日志、寄存器/内存变化、系统调用序列
加固识别	样本可能被壳或混淆	Exeinfo PE、Detect It Easy、熵扫描、区段分析	壳类型、保护强度、入口点特征
协议逆向	目标是网络协议或通信逻辑	流量抓包、Hook 加解密函数、重放分析	报文结构、加密算法、状态机

除了技能清单，路由设计还应当为每个技能定义基础“前置条件”：例如，只有 文件识别 判定样本为 PE/ELF 后，才进入 静态解析；只有 静态解析 发现可疑函数后，才进入 反编译分析；只有静态分析无法解释行为或需要确凿证据时，才触发 动态调试。这样做可以把昂贵的动作（反编译、调式）留到真正需要的时候执行。

一个典型逆向任务的路由路径可能是：

未知样本 → 文件识别 → 发现 UPX 壳 → 脱壳尝试 → 静态解析 → 字符串定位 → 反编译关键函数 → 动态调试验证。

对应到具体案例：假设 Agent 收到一个名为 invoice_2026.pdf.exe 的文件。意图识别器首先判定 artifact_type=PE, intent=analyze；文件识别确认它是 32 位 PE、熵值偏高、带 UPX 特征；路由器据此先尝试脱壳，成功后进入静态解析，提取出一批可疑字符串；反编译重点查看引用这些字符串的函数；最后如果仍需要确认运行时行为，才启动沙箱动态调试。整个链路中每一步都为下一步提供“干什么”的依据，而不是靠模型随机猜测。

5. 渗透方向的技能路由设计

渗透方向更强调阶段性、授权范围和证据留存。路由大脑需要把宽泛的“帮我测试一下这个目标”拆成可审计的攻击面枚举链路，避免一步跨到高风险动作。

下表按渗透阶段拆分典型意图与建议技能：

阶段	典型意图	建议技能	关键产出
侦察	发现子域、端口、服务	子域枚举、端口扫描、证书透明度查询	资产清单、开放端口列表
指纹识别	判断中间件、框架、版本	响应头分析、路径探测、Wappalyzer 类能力	技术栈指纹、版本线索
攻击面枚举	寻找接口、入口、暴露文件	目录枚举、Swagger/API 发现、JS 分析	候选入口、接口清单
漏洞验证	验证某个漏洞是否存在	指纹匹配、被动 PoC 验证、非破坏性检查	可复现验证结果、风险定级
权限提升评估	已获取低权限后的路径分析	主机枚举、配置审计、横向移动评估	权限路径、风险建议
报告归档	汇总风险与证据	漏洞描述、复现步骤、修复建议	结构化报告、证据链

渗透路由有两个与逆向路由明显不同的约束：

第一是授权范围前置。在侦察动作之前，就必须校验目标是否落在授权清单内；涉及漏洞验证、权限提升评估等高风险动作时，需要增加逐项人工确认，不能由模型自动决定“试一下”。

第二是逐层收敛。相比逆向技能通常围绕一个文件展开，渗透技能链更强调从面到点：先确定目标资产范围，再识别服务指纹，再到具体入口，最后做风险验证。每一层都只在上一步有明确产物的前提下开展，避免在未确认资产归属前就进行扫描。

以授权范围内的一个 Web 目标为例，路由路径可能是：

目标域名 → 子域枚举 + 证书透明度 → 确认资产归属 → 端口与指纹识别 → 识别出 Nginx / Spring Boot → 目录与 API 枚举 → 发现未鉴权的 Swagger 接口 → 非破坏性验证 → 输出风险报告。

这里每一步都附带“是否越界”的判断点。即使模型判断“下一步扫描内网段更高效”，只要该网段不在授权范围内，安全边界检查也会直接拦截。

6. 路由决策的核心信号

要让 Agent 稳定地选择技能链，必须把“模糊的自然语言任务”转换为结构化信号。只靠 system prompt 里写一句“优先选择最相关的工具”是无法保证一致性的；显式字段建模才能让路由逻辑可测试、可调优。

建议至少建模以下几类字段：

• artifact_type：binary、source、network、web、mobile、cloud、log、dump。用来限定技能域，例如 mobile 应优先路由到 APK/IPA 分析域，而不是 PE 工具链；
• intent：analyze、decompile、debug、fuzz、scan、recon、verify、report。这是路由的主信号，直接决定技能类型；
• target：文件路径、URL、IP、域名、样本哈希。用于合法性校验和工具参数组装，同时避免对没有 target 的任务空跑；
• constraints：授权范围、时间预算、是否允许副作用、是否需要交互式操作。例如 VNC 类工具依赖图形界面，无人值守场景就不该调度；
• evidence：已有的崩溃日志、网络包、异常输出等附件信息。它们可能直接改变路由路径，比如提供了 crash dump 时，应优先路由到崩溃分析而非普通静态解析。

当上述字段齐备且互相一致时，路由器可以计算每个候选技能链的得分。一个简易的打分示例：

score = base_weight(artifact_type, intent)
      + tool_availability_bonus
      + evidence_support_bonus
      - constraint_penalty

实现上不一定要用复杂的机器学习模型，规则打分 + 阈值兜底 对初版已经足够。低于最低置信度时，不要硬执行，而应该向用户追加提问，例如：

• “该样本是否允许在本地沙箱运行？”
• “目标是否在授权测试范围内？”
• “你希望优先关注漏洞验证还是资产测绘？”
• “请补充样本来源或哈希，以便确认它是否已经被分析过。”
• “这个运行环境是否具备图形界面？部分调试工具需要交互式窗口。”

这种“不确定就问”的策略，比强行猜测更接近真实安全测试的工作方式。它把“模型幻觉式地选择工具”变成“结构化缺口识别 + 主动澄清”，对稳定性和合规性都是关键改善。

7. 一个最小可行的路由配置示例

下面是一个概念性的技能路由配置，用于说明技能选择逻辑。它不依赖具体框架，可以映射到 LangGraph、自定义状态机或任何 Agent 编排方案中：

{
  "skills": [
    {
      "name": "pe_static_analysis",
      "description": "对 PE/ELF 样本执行文件识别、字符串与导入表静态解析",
      "when": {
        "artifact_type": ["PE", "ELF"],
        "intent": ["analyze", "triage"]
      },
      "tools": ["file", "strings", "objdump", "ghidra_headless"],
      "output": "import_table_summary",
      "risk_level": "low",
      "timeout_seconds": 180
    },
    {
      "name": "dynamic_hooking",
      "description": "在授权沙箱中通过 Hook 观察样本运行时行为",
      "when": {
        "intent": ["debug", "trace"],
        "runtime_allowed": true,
        "sandbox_available": true
      },
      "tools": ["frida", "gdb"],
      "output": "hook_trace_report",
      "risk_level": "medium",
      "require_approval": true
    },
    {
      "name": "network_recon",
      "description": "对授权资产执行端口、服务与 Web 指纹侦察",
      "when": {
        "target_type": ["host", "domain", "cidr"],
        "intent": ["recon", "enumerate"],
        "authorized": true
      },
      "tools": ["nmap", "httpx", "nuclei"],
      "output": "attack_surface_list",
      "risk_level": "medium",
      "timeout_seconds": 600
    },
    {
      "name": "vuln_verify",
      "description": "对已识别指纹执行非破坏性漏洞验证",
      "when": {
        "intent": ["verify"],
        "evidence_present": true,
        "authorized": true
      },
      "tools": ["nuclei", "custom_poC_runner"],
      "output": "verify_report",
      "risk_level": "high",
      "require_approval": true
    },
    {
      "name": "report_generation",
      "description": "将线索卡片聚合为结构化报告",
      "when": {
        "intent": ["report"]
      },
      "tools": ["report_builder"],
      "output": "final_report",
      "risk_level": "none"
    }
  ],
  "router": {
    "policy": "max_score",
    "min_confidence": 0.75,
    "fallback": "ask_user",
    "scoring": {
      "artifact_type_match": 0.35,
      "intent_match": 0.30,
      "tool_available": 0.20,
      "evidence_support": 0.15,
      "constraint_penalty": -0.15
    }
  }
}

可以看到，路由配置把“什么时候能调什么”显式化。这样做有三个直接好处：

• 便于审计：每一次路由决策都可以回溯到具体规则，而不是“模型觉得应该用这个工具”；
• 风险分级：对危险技能单独设置 require_approval、runtime_allowed、sandbox_available 等前置条件，未满足条件时技能根本不会进入候选集；
• 易于演进：当某个技能链在真实任务中被验证有效后，可以提升它的基础权重，让规则路由逐步带着经验特征。

这套配置只描述“路由政策”，不绑定具体框架。你可以在 LangGraph 里把 skills 映射为带条件的节点，把 router 映射为条件边；也可以在自研状态机里用一份等价的 YAML/数据库表实现，核心思想不变。

8. 聚合与反馈闭环

单次技能调用不是终点。reverse-skill 的价值在于把每次工具输出结构化为可继续消费的“线索卡片”。

设计“线索卡片”时，应坚持统一 schema。一个字段统一、可以跨技能传递的卡片，才能让路由器在下一轮决策时直接使用。例如一个逆向任务可能产出：

• sample_type: ELF 64-bit
• packer: UPX 4.1
• suspicious_strings: /system/bin/sh
• key_function: 0x4012a0
• source_skill: pe_static_analysis
• evidence_confidence: high

这些字段进入下一次路由决策，Agent 就能自然地从「静态分析」过渡到「动态调试」，而不是重新猜测下一步该做什么。比如发现 suspicious_strings 中含有命令执行特征后，下一轮路由可以优先生成“Hook 该字符串引用的关键函数”这一动态调试计划。

反馈闭环至少应包含三层记忆机制：

• 短时记忆：当前任务运行过程中产生的线索卡片序列，用于指导后续步骤；
• 任务记忆：一次完整分析任务的最终结论、证据链和报告，便于复盘；
• 长期经验：把每次成功或失败的路由决策沉淀为可复用样本。

在长期经验层面，可以把“输入信号 → 技能链 → 结果质量”记录成结构化样本。遇到相似的任务时，优先复用被验证过的技能链；遇到反复失败的链路，则自动降低其权重或加高 require_approval 门槛。这就是从“规则路由”逐步走向“经验路由”。要注意的是，经验路由必须保持可解释性：即使引入统计、检索甚至模型打分，也应保留“为什么选择这个技能链”的显式理由，否则合规审计会变得困难。

9. 落地建议与合规边界

实际落地 reverse-skill 时，建议遵循以下原则：

• 默认沙箱：逆向样本运行、可疑脚本执行必须在隔离环境中完成；没有可用沙箱时，路由层应拒绝调度 runtime_allowed 类技能，并把任务降级为纯静态分析；
• 允许清单优先：工具调用使用 allowlist，而不是简单依赖模型判断。模型可以提出“想调用什么”，但最终执行必须经过白名单和参数校验；
• 危险动作人工确认：涉及漏洞验证、权限提升、横向移动评估时，必须增加 human-in-the-loop，由授权人员对目标、参数、预期影响逐项确认；
• 全程审计：记录意图、路由结果、工具参数和输出摘要。建议采用“事件日志 + 摘要入库”的方式保存证据链，既满足审计要求，又避免原始敏感数据过度留存；
• 最小权限：每个技能单元只申请完成任务所需的最小权限，并使用独立凭据或短期令牌，禁止在技能间共享高权限账号；
• 敏感信息脱敏：对任务中出现的账号、口令、Cookie、Token、内网地址等敏感信息，在入库与日志输出前统一脱敏；
• 只测有权测试的目标：仅用于内部安全、CTF、授权渗透测试或漏洞赏金项目；授权范围和有效期应作为路由的硬约束，而不是可选项；
• 避免武器化输出：不提供一键入侵、免杀、绕过 WAF、明文攻击载荷生成等仅具有攻击性的自动化链路；验证能力应服务于“确认风险存在”，而不是“扩大攻击效果”。

合规不是给研究能力“降级”，而是让 AI Agent 在可解释、可追溯、可复现的框架内工作。安全研究本身高度敏感，只有把授权、审计、人工确认这些机制内建到路由层，而不是事后补文档，reverse-skill 才具备在真实团队中落地的可能性。

10. 结语

reverse-skill 并不是一个神秘的“超级攻击模型”，它更像安全研究 Agent 的操作系统：把逆向与渗透拆成技能单元，把工具选择变成显式路由，把多轮结果组织成可持续推理的线索链。

它的价值可以从三个层次来理解：短期看，它减少乱调用和浅尝辄止，让 Agent 不再“想到哪调到哪”；中期看，它把安全边界、授权范围和风险等级变成系统级硬约束，让自动化安全分析具备可审计性；长期看，它把每次成功与失败沉淀成经验，让规则路由逐步长出“肌肉记忆”。

当 Agent 不再靠运气调用工具，而是有一个清晰的路由大脑时，它才能真正从“会聊天”走向“能完成一条完整安全分析链路”。而这条链路走得越深，越需要记住一件事：自动化让效率提升，合规让能力可持续。 只有在授权、可解释、可追溯的框架里，逆向与渗透方向的 Agent 才能既跑得快，也走得远。