这种强大的组合使我们的框架能够自动化发现深层次的架构性缺陷，真正作为一个自主的安全合作伙伴发挥作用。
3）案例研究：揭示 Bluefin PerpDEX 中的关键逻辑缺陷为了在真实场景中验证我们框架的多层架构，我们将其应用于 Bluefin 的公开安全审计。Bluefin 是一个复杂的永续合约去中心化交易所。这次审计展示了我们如何通过静态分析、专门的 AI 代理以及基于 RAG 的事实校验，发现传统工具无法识别的漏洞。
分析过程：多代理系统的运作这一高危漏洞的发现并非单一事件，而是通过框架中各个集成组件系统性协作完成的：
-
上下文映射与静态分析
流程首先对 Bluefin 的完整代码库进行输入。我们的静态分析引擎确定性地映射了整个协议，并结合基础分析 AI 代理，对项目做了整体性概览，定位到了与核心金融逻辑相关的模块。 -
专门化代理的部署
基于初步分析，系统自动部署了一系列专门的阶段性代理。每个 AI 代理都有自己的审计提示与向量数据库。在本次案例中，其中一个专注于逻辑正确性与边界情况漏洞（如溢出、下溢和比较错误）的代理发现了该问题。 -
基于 RAG 的分析与复核
算术逻辑代理（Arithmetic Logic Agent）开始执行分析。借助检索增强生成（RAG），它查询了我们专家策划的知识库，参考 Move 语言中的最佳实践实现，并将 Bluefin 的代码与其他金融协议中已记录的类似逻辑缺陷进行对比。该检索过程突出显示了正负数比较是一个典型的边界错误案例。
通过我们的框架，我们最终识别出四个不同的问题，其中一个是深植于协议金融计算引擎中的高危逻辑漏洞。
漏洞出现在 signed_number模块中的 lt（小于）函数。该函数对于任何金融比较都至关重要，例如仓位排序或盈亏（PNL）计算。漏洞可能导致严重的财务差异、错误的清算，以及 DEX 核心操作中的公平排序机制失效，直接威胁协议的完整性。
问题的根源在于当负数与正数进行比较时出现了错误的逻辑。signed_number模块使用 value: u64和 sign: bool（true 表示正数，false 表示负数）来表示数值。而 lt函数在其 else 分支（处理不同符号数的比较）中存在缺陷。当比较一个负数（!a.sign）与一个正数（b.sign）时，该函数错误地返回了 a.sign（即 false），实际上断言了“正数小于负数”。
修复措施：
为纠正这一关键问题，lt函数的 else分支需要进行一个简单但至关重要的修改。修复后的实现必须返回 !a.sign，以确保在比较时，负数始终能够被正确地评估为小于正数。
修复