安全研究员面对一个 APK，要让 AI 帮忙分析。他输入“帮我逆向这个包”，AI 回了一句“请先安装 jadx 或 apktool”。
这场景比你以为的更常见。AI Agent 面对二进制文件时，就像一个只有课本知识的新手，不知道该用 IDA 还是 Ghidra，不知道 Frida 脚本怎么写，甚至不知道这些工具在哪台机器上。不是 AI 不够聪明，是它缺一套“知道什么时候该干什么”的路由系统。
reverse-skill 做的事就这个，而且做得很彻底。它不教你怎么逆向，是教 AI 怎么逆向。146 条路由规则、14 个专业场景、自举工具链加自进化经验库，本质上是给 AI Agent 装了一套逆向工程的操作系统。
说真的，刚看到这个仓库结构的时候我有点意外。不是因为它复杂，是因为它的设计思路跟我预想的完全不一样。我原以为就是一个 Prompt 合集加几个脚本，结果发现它是一个完整的分层路由架构，而且每一层都有明确的职责边界和容错机制。这篇文章就拆开这套架构怎么运转的，以及它暴露出的几个值得讨论的设计选择。
架构解析
reverse-skill 的架构是三层嵌套的漏斗结构，从外到内分别是场景识别、路由分发和工具执行。每一层有自己独立的状态和容错策略，层与层之间通过结构化的规则文件耦合而非硬编码。
最外层负责理解用户意图。系统接到任务后做的第一件事不是直接匹配技能，而是走 RULES.md。这个文件充当整个系统的调度策略层，定义了什么时候该派给 APK 逆向、什么时候该派给 JS 逆向、什么时候应该直接拒绝或要求澄清。它不是简单的关键字映射表，包含了任务上下文和工具链可用性的交叉判断。
核心在中间的路由层。skills/routing.md 里 146 条规则用一个三轴矩阵来组织：
-
任务类型：逆向、渗透、分析 -
目标对象：APK、ELF、JS、PCAP、固件等 -
工具链要求：静态分析、动态 Hook、混合
这个矩阵有一个聪明的取舍：不穷举所有组合，而是在交叉点预留了“模糊匹配”空间。任务落在两个规则边界上时，系统不会卡死，走一条带有置信度标注的降级路径。换句话说，路由是概率性的而非确定性的，这在安全工具链这种高度碎片化的场景里反而是优势。
最内层的工具执行层更有意思。它不预装工具，路由确定后按需自举。skills/tool-index.md 是一个自动生成的本机工具索引，每次启动扫描环境中可用的工具并更新列表：
-
jadx（APK 静态分析） -
Frida（动态 Hook） -
Ghidra（二进制反编译） -
radare2（轻量逆向框架）
这意味着同一套 Skill 在不同机器上的行为会自动适配，不需要手动改路径。安全工具链最头疼的版本碎片化问题，在这里被”先感知、后决策”的流程消解掉了。
工作流分析
一个完整的 APK 逆向任务怎么穿过这三层架构？推演一遍。
用户输入”分析这个 APK 的加密逻辑”。AI 先读 RULES.md，三轴矩阵匹配，结果如下：
任务类型: 逆向
目标对象: APK
工具链要求: 静态分析 + 动态 Hook
→ 路由至 skills/apk-reverse/
路由系统在进入技能前做了一次工具可用性检查，如果缺 jadx 或 Frida，不报错，而是触发引导脚本自动安装。跨平台脚本根据当前系统（Kali、Ubuntu、macOS 或 Windows）执行对应命令，装完后更新 tool-index 重新验证。
进入具体技能后，按标准逆向流程推进：静态拆包看结构，动态 Hook 抓加密参数，最后生成结构化报告。但这中间有一个容易被忽略的设计：每一步的输出都会写入 field-journal/。这不是日志文件，是结构化的经验记录。后续遇到类似任务时系统可以直接调取，避免重复踩坑。
这里涉及的 agent compliance engineering 是这套系统里技术含量最高的部分。AI Agent 在执行逆向任务时有一个天然倾向：跳过验证直接出结论。reverse-skill 用了 8 种技术对抗这种倾向，包括强制验证锚点、置信度阈值门禁、输出格式约束等。从路由规则中“必须确认 X 后才能进入 Y”的结构设计来看，这套机制嵌入在路由层而非工具层，是结构性约束而非事后补救。
整个工作流最大的瓶颈不在工具执行，在路由匹配的边界情况。当一个任务横跨两个场景时，比如“逆向这个 APK 并测试它的网络通信安全性”，系统需要同时激活 apk-reverse 和 pentest-tools 两条技能线。目前通过优先级权重解决冲突，但真正意义上的并行路由还没有实现，这是一个明确的演进方向。
使用场景
14 个入口覆盖了一个安全研究员日常工作的主要任务类型。数量不是重点，重点在场景之间的覆盖关系设计。
APK 逆向和 JS 逆向是最成熟的两条线。前者从 jadx 静态分析到 Frida 动态 Hook 形成完整闭环，后者覆盖了前端加解密参数提取的主流需求。二进制逆向线（ida-reverse / radare2）覆盖了 ELF、DLL、驱动等原生目标，工具链偏手动分析辅助。
几个非传统场景的覆盖深度让人意外。OLLVM 脱密有 501 行文档、9 种混淆变体的识别和对抗策略，包括 MBA 表达式简化和不透明谓词移除。LLM 安全线覆盖了 OWASP LLM Top 10 加 ASI Top 10，不只有检查清单，还包含针对 Agent prompt injection 的服从性测试。EDR 绕过线的文档虽然相对简略，但说明了作者对攻防实战的理解深度。
CTF 沙箱编排器是另一个值得关注的设计。40 多个子技能覆盖了从 Web 到 PWN 到 Reverse 到 Crypto 的常见题型，本质上是把 CTF 解题方法论结构化成了可路由的技能模块。这个设计的价值不在解题能力本身，在为 AI 参与 CTF 建立了一套可扩展的框架。
局限也要说清楚。固件和 IoT 逆向线目前更多是方法论指引，实战深度不如 APK 和二进制线。补丁差分分析和 PWN 漏洞利用链对操作者基础能力要求很高，AI 目前更多是辅助定位而非自主执行。这不是 reverse-skill 的问题，是当前 AI 能力边界的真实反映。
洞察与反思
拆完这套架构，几个判断值得单独拎出来。
第一个判断：reverse-skill 不是 Skill，是 Skill Platform。它跟市面上大多数 Skill 的区别，像操作系统跟应用程序的区别。普通 Skill 是“一个技能干一件事”，reverse-skill 是“一个技能决定该调用哪个技能”。这种元技能的设计思路，我判断会成为 Agent 生态下一阶段的标配。不是因为它技术多先进，是因为复杂专业工具链普遍存在“工具选择困难”这个结构性痛点。
第二个判断：自进化经验库是被严重低估的功能。field-journal/ 看起来只是日志，但如果把它跟路由系统联动来看，它其实是一个持续喂养路由规则的数据管道。每次任务的经验都会影响下一次路由的置信度计算。这个设计让我想到强化学习里的 experience replay，只不过用的是自然语言而非向量。如果能把这个回路真正跑通，路由系统会从“手工精调”逐渐过渡到“数据驱动”，维护成本的结构性问题就有解了。
第三个判断，也是最值得商榷的：146 条路由规则的维护天花板。目前每条规则需要维护触发条件、工具映射、降级路径和验证锚点四个字段。场景数量继续增长，维护成本会非线性上升。一个可能的解法是把路由规则也纳入自进化体系，让 field-journal 的高质量经验自动沉淀为新规则。但目前没有看到这个机制的明确迹象，这可能是整个架构最薄弱的一环。
横向对比来看，GitHub 上能找到的 AI 安全工具绝大多数是单个工具的 Prompt wrapper，而 reverse-skill 做的是基础设施。1.3k forks 说明了一个事实：不是因为逆向更快，是因为它解决的是“让 AI 在安全领域可编程”的结构性问题。BurpSuite MCP 集成（63 个工具）进一步印证了这个方向，它说明作者没有把 reverse-skill 局限在 CLI 工具链里，而是在主动对接专业安全工具生态。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/zhaoxuya520/reverse-skill |
| 社区 | https://t.me/AI_And_Security |
总结
reverse-skill 的核心价值不在支持多少种逆向场景，在它定义了一种”AI × 安全工具链”的架构范式：
-
分层路由：让 AI 知道什么时候该调用什么工具 -
感知式工具调度：先确认工具可用性，再决定执行路径 -
经验回灌式进化：每次任务的教训自动沉淀为下一次的决策依据
这三个设计决策分别解决了 AI Agent 在专业领域最头疼的问题：不知道该用什么工具、不知道工具有没有准备好、同样的坑反复踩。
这套架构适合工具链复杂、操作步骤多、经验依赖度高的领域。安全逆向是最典型场景，但以下领域同样符合这个特征：
-
医学影像分析 -
法律文书处理 -
芯片设计验证
不适合工具链简单、路径唯一、不需要路由判断的场景，加一层路由系统纯属过度设计。
往前看，reverse-skill 最大的挑战是路由规则的规模化维护。146 条手工管得住，500 条呢？如果能把 field-journal 的经验回流机制跟路由生成打通，这套系统的天花板会高得多。这是一个值得持续关注的开源项目，不是因为它现在已经完美，是因为它的架构方向踩在了一个正确的点上。