本文是《从泛.AI到ORIVEX：为什么重新设计智能体》的后续。上一篇谈的是智能体为什么要从“回答问题”走向“执行任务”，这一篇只谈一个更具体的方向：当智能体进入逆向分析场景时，它到底应该怎样工作。
上一篇文章里，我写了 ORIVEX 从对话系统向执行型智能体的变化：理解目标、进入项目、调用工具、检查结果，并保存可以恢复的工作状态。
但“能够调用工具”并不等于“能够完成逆向分析”。
逆向工作并不是打开一个软件、反编译一个文件、搜索几个字符串这么简单。一个真实任务往往同时包含目标识别、环境判断、静态分析、运行时观察、网络行为、平台差异、证据记录和反复验证。只要其中一个环节判断错了，后面的结论就可能全部偏离。
因此，我最近做的并不是给 ORIVEX 迭代 AI 场景，抛开逆向场景，它甚至不如你直接去用常见的热门 AI 工具，而是尝试把过去多年形成的逆向经验，形成让智能体落地的工作方式。
这篇文章不会展开具体规则、脚本、工具组合和判断细节，只记录其中可以公开的设计思路。
一、逆向智能体不是“AI 加几个工具”
最容易实现的版本，是让模型知道一些工具名称，再根据用户的问题生成几条命令。
这种方式看起来已经可以工作，但它解决的只是“怎么调用工具”，没有解决“为什么现在应该调用这个工具”。
逆向分析真正困难的地方，通常不是工具本身，而是判断：
– 当前面对的是网页脚本、移动应用，还是进入了原生代码；
– 目标问题属于请求链路、参数生成、业务逻辑，还是运行时行为；
– 现在掌握的是事实、推测，还是尚未验证的线索；
– 静态结果是否足够可信，是否需要运行时证据交叉确认；
– 当前路径已经失效时，是继续深入，还是切换分析层级；
– 什么结果才算完成，什么只能算阶段性发现。
所以，逆向智能体的核心不是“工具越多越强”，而是能够在不同目标、不同平台和不同证据状态之间做出正确路由。
换句话说：
普通自动化执行预先写好的步骤，逆向智能体需要根据新证据决定下一步。
二、为什么很多智能体连问题都无法直接进入
现在的通用智能体已经很强，但通用能力不等于逆向经验。
当一个问题同时出现分析、注入、解密、绕过、设备、网络协议等内容时，普通智能体面对的往往只是一组高风险关键词。
结果通常有三种：
1. 问题还没有进入技术分析阶段，就被笼统中止；
2. 只能给出一些与目标脱节的概念说明，无法继续执行；
3. 即使开始执行，也容易在静态、动态、网络和设备环境之间失去方向。
这并不是因为模型完全没有代码能力，而是因为它缺少逆向任务真正需要的领域上下文。
一个有经验的逆向工程师看到问题时，不会只看到某个敏感词，而会同时判断：目标是什么、研究边界是什么、现在有哪些证据、问题位于哪一层、什么操作可以验证、什么结论还不能下。
ORIVEX 能够继续处理这类问题，并不是因为它创造了模型原本没有的推理能力，也不是简单地取消限制，而是因为我把多年以来积累的逆向经验真正落进了智能体的执行环境。可以这么说，只要有我通过经验落地下来的skill ，哪怕不重新开发智能体，随便一个现有的智能体都能实现并解决问题
这些经验不再只是我脑子里的直觉，而被转化成了智能体能够使用的任务背景、能力路由、分析顺序、证据要求、失败处理和验证标准。系统会先把一个容易被误解的问题还原成边界清楚的专业任务，再决定应该加载什么能力、调用什么工具、怎样保存证据。
因此，它解决的是三个递进的问题：
– **让问题可以被正确理解：** 不只识别关键词，而是识别目标、场景和边界；
– **让任务可以被实际执行：** 不停留在回答层，而是进入项目、环境和工具链；
– **让结果可以被验证：** 不把模型推测直接当成逆向结论。
可以说，模型提供了通用理解能力，而多年逆向经验为它补上了专业坐标系。
别的智能体看到的是一句可能无法回答的问题，ORIVEX 看到的是一个需要先确认边界、再逐层取证的工程任务。
真正形成差异的，并不是一句更大胆的提示词，而是长期经验被结构化以后，能够在正确的时间进入正确的分析层。
三、我把它拆成了四个公开层次
从公开的工程结构看，这套逆向能力可以分成四层。
1. 目标理解层
首先确认要解决的不是“分析这个文件”这样宽泛的问题，而是一个可以验证的目标。
例如，要找的是某个请求参数的来源，理解某段业务判断，定位移动端某个异常行为，还是还原一条跨层调用链。目标不同，进入项目后的第一步也完全不同。
这一层还需要保存任务边界、已有材料、运行环境和成功标准。没有这些信息，智能体很容易做很多操作，却始终没有接近真正的问题。
2. 能力路由层
网页 JavaScript、Android 应用和 iOS 应用虽然都属于逆向，但它们的入口、运行环境和可见证据并不相同。
因此，系统不会把所有规则一次性加载，也不会让所有工具同时参与。它会先判断目标类型和当前所处层级，再加载对应能力；当分析从页面进入移动端、从上层逻辑进入原生模块时，再把已经确认的上下文交给下一层继续处理。
这是一种按需路由，而不是工具堆叠。
3. 证据与状态层
逆向分析中最危险的一句话是：“看起来应该是这样。”
模型很擅长根据片段给出合理解释，但合理不等于真实。因此，每个关键判断都需要知道证据来自哪里：文件结构、代码关系、运行日志、请求行为、运行时输入输出，还是多种结果的交叉印证。
系统会区分：
– 已确认的事实；
– 当前最可能的解释；
– 仍需验证的假设；
– 已经被实验排除的路径。
这样做不是为了增加文档，而是为了防止智能体把一次猜测变成后续所有步骤的前提。
4. 执行与验证层
最后才是工具执行。
智能体读取材料、调用本地能力、生成分析产物，再根据实际结果修正判断。一次执行没有得到预期结果时，不能用一段解释掩盖失败，也不能无限重复同一种尝试，而要回到证据和路径本身重新判断。
公开层面的循环可以概括为：
“`
理解目标
↓
识别平台与分析层级
↓
选择当前最小必要能力
↓
获取证据并形成假设
↓
执行验证
↓
修正结论、保存状态、决定下一步
“`
这个循环比某一次工具调用更重要。
四、面向 JavaScript：从可见行为反向追踪
网页 JavaScript 的特点是代码多、变化快、运行环境复杂。直接阅读全部脚本，往往会很快陷入大量框架代码、打包代码和无关逻辑。
因此，面向 JavaScript 的智能体不会先问“所有代码是什么意思”，而是先问“页面上发生了什么”。
它从可见行为出发：某个操作触发了什么请求，请求由哪段逻辑发起，关键数据在运行时经过了哪些变化，哪些部分必须依赖浏览器环境，哪些部分可以被整理成更小的本地复现单元。
这条路径大致是：
“`
页面行为 → 请求特征 → 调用来源 → 运行时证据 → 最小复现
“`
这里最重要的不是把所有 JavaScript 都还原成“漂亮源码”，而是尽快缩小问题范围，找到与目标直接相关的因果链。
如果任务只是确认一个参数的生成过程，就没有必要把整站脚本全部分析一遍；如果目标需要长期稳定复现，才继续进入更深的逻辑整理。
智能体需要知道什么时候继续，什么时候已经足够。
五、面向 APK：让分析能够跨过不同层级
Android 应用通常不是一个单层目标。
界面与业务逻辑可能位于应用层，关键判断可能下沉到更底层，实际运行时还会受到设备状态、进程生命周期和保护机制影响。只看某一层，很容易得到一个局部正确、整体错误的结论。
因此，面向 APK 的路径更像一棵逐步展开的树：
“`
应用结构
↓
上层业务与资源关系
↓
跨层调用边界
↓
原生模块与运行时行为
↓
多来源证据交叉验证
“`
智能体先建立应用全貌，再决定重点停留在哪一层。能够在上层回答的问题，不必过早进入底层；当证据明确指向原生模块或运行时生成逻辑时，分析路径才继续下沉。
更重要的是，移动端分析经常会遇到“文件里看到的内容”和“程序真正运行的内容”并不完全一致的情况。这时，智能体不能只依靠静态结果下结论，而要把运行时现象、加载关系和实际执行状态结合起来。
这也是逆向智能体与普通反编译助手最明显的区别之一：它不是解释一个文件，而是在恢复一个真实运行过程。
六、面向 iOS：平台不同，证据闭环相同
iOS 的文件结构、运行时体系、签名机制和设备条件都与 Android 不同，很多具体能力不能直接复用。
但从智能体设计角度看，底层平台差异之上仍然可以保持相同的任务模型：先确认应用结构与目标入口，再结合符号关系、运行时行为、网络交互和原生代码逐步缩小范围。
也就是说，平台能力可以不同，证据状态和验证原则应该一致。
这让我在设计时没有把 JavaScript、APK 和 iOS 做成三个互不相干的“问答模板”，而是让它们共享同一套上层任务状态：
– 当前目标是什么；
– 已经确认了什么；
– 证据位于哪一层；
– 哪个假设仍未验证；
– 下一步应该交给哪类能力。
具体平台负责“怎么做”，统一状态负责“为什么做”和“做到哪里”。
七、真正困难的是混合链路
现实任务往往不会老老实实停留在单一平台里。
一个入口可能从网页脚本开始，进入移动端容器，再经过应用层桥接，最后落到原生模块；也可能从一个网络请求出发，反向追到页面逻辑、设备信息和本地状态。
如果每一层都从头开始，前面得到的证据就会丢失。逆向智能体必须能够在能力切换时传递已经确认的上下文，而不是只传递用户最初的一句话。
所以核心：
不是让一个模型什么都会，而是让不同能力围绕同一个目标继续工作。
这和真实团队协作很像。负责不同方向的人可以使用不同方法，但必须共享目标、证据、阶段结论和未解决问题。
八、失败不是异常，而是流程的一部分
逆向分析很少一次成功。
环境可能不满足，工具输出可能不完整，静态结果可能被混淆干扰，运行时现象也可能与最初假设冲突。如果系统只记录成功结果，它就无法真正恢复任务，更无法知道哪些路已经走过。
因此，我在设计中保留失败轮次，并要求每次失败至少回答三个问题：
1. 这次实际验证了什么；
2. 它排除了哪个假设；
3. 下一步为什么要改变路径。
失败被结构化以后，就不再只是一次无效消耗，而会成为缩小问题范围的证据。
九、它仍然不是“全自动逆向”
我不认为现阶段存在一个可以接收任意目标，然后完全自动完成所有逆向工作的系统。
模型会判断错误，工具会受到环境限制，复杂保护会改变可见信息，不同版本也可能让已有经验失效。真正可靠的系统不应该掩盖这些问题，而应该知道自己何时缺少证据、何时需要切换方法、何时应该保留阶段结果并等待新的条件。
所以，如果完全不懂逆向不知道什么时候该用什么工具，可能大部分任务无法顺利高效完成，但是如果本身具有逆向相关经验，那么ORIVEX将是提升效率最佳的帮手，你完全可以明确告诉他用哪个技能去拿分析参数，用哪个技能去取哪个地址。
我们需要定义目标、边界和关键取舍；智能体负责整理材料、推进流程、调用能力、记录证据和完成大量可以被验证的执行工作。
这更接近一名可以持续协作的技术执行者，而不是一个一键生成答案的黑盒。
十、哪些可以公开，哪些不会公开
可以公开的是设计原则：按目标路由、按需加载、证据优先、静态与运行时交叉验证、失败可追溯、结果可恢复。
不会公开的是这些原则如何被真正固化成稳定能力，包括具体的规则组织、判断条件、工具编排、异常恢复、内部脚本、验证细节，以及多年实战中沉淀下来的关键经验。
因为真正形成差异的，从来不是“使用了什么工具”，而是：
在什么情况下选择什么路径，看到什么证据后改变什么判断，以及怎样把一次成功变成可重复的工程能力。
所以我希望每一个逆向工作者都用自己过去的经验去落地一套智能体可实施的能力，因为分析逆向实际上是很累很苦的活，需要的技术栈也特别的多。
十一、为什么现在要做这件事
过去做逆向时形成了从请求、代码和运行行为中寻找证据的习惯；做数据以后，更重视结构、状态、口径和可追溯性；现在做智能体工程，我尝试把这两部分能力重新组合起来。把重心转向智能体，以往占用时间，效率不高的工作，全部用经验固化成智能体可落地的能力。
所以智能体工程要解决的，是如何让这些判断不只存在于人大脑中，而能够被组织、调用、记录和持续执行。
十二、从“会调用”走向“会完成”
一个逆向智能体是否真正有用，主要在于：
1. 它能否根据目标选择正确的分析方向；
2. 它能否用证据修正自己的判断；
3. 它能否留下可恢复、可复现、可继续的项目结果。
不是把 AI 放进逆向工具里，而是让 AI 学会按照逆向工程的方法工作。
这也是 ORIVEX 与通用执行本质的一些区别。
