高性能自主智能合约审计工具 Plamen 的构建实践

多年来，我进行的每一次智能合约审计看起来都大同小异：阅读代码、映射状态、追踪执行流、编写 PoC，然后重复撰写报告。

这个过程很慢，且缺乏一致性。最危险的漏洞类型（逻辑漏洞、复合漏洞）往往是由于人类疲劳而漏掉的。你可能抓住了重入问题，却漏掉了在余额变化前未更新的累加器，而这一个小疏忽就可能导致协议损失数百万美元。

因此我开始思考：审计流程是正确的，方法论也是可靠的，瓶颈在于人类的大脑。即使是在团队中，人类的效率也终究有限。

在 AI 工具爆发式增长的背景下，我开发了 “Plamen”。从构思到可用历时两个月。自发布以来，在不到一周的时间里，根据用户反馈已经更新了六个以上的版本。以下是我在构建过程中的心得体会。

初始尝试的失败与架构突破

我最初的直觉很简单：使用两三个 AI Agent，输入完整代码库，让它直接运行。

但事实证明这行不通。

在面对 5,000 行代码时，最初的 3 个 Agent 受限于当时仅有的 128K 上下文窗口，当处理到结尾时，开头的内容已经丢失了。它开始压缩信息，产生幻觉。发现的漏洞质量下降，LLM 在处理中途就开始跳跃，而最细微的漏洞往往就隐藏在这些地方。

突破来自于与 @teryanarmenn 的一次交流：采用具有专门递归功能的多 Agent 架构。不再是一个 Agent 包揽所有工作，而是由一个编排器（Orchestrator）并行启动针对特定任务的 Agent。每个 Agent 都持有其特定代码片段的完整上下文，它们可以相互生成并穷尽搜索，直到用尽所有思路。

这就是 Plamen 目抢跑的架构。

深入解析：8 阶段审计流水线

Plamen 运行一个 8 阶段的流水线。以下是每个阶段的具体工作内容：

阶段 1：侦察 (Recon)

扫描代码库，运行静态工具。了解代码功能、攻击面以及相关的漏洞模式。是闪电贷、预言机、可升级代理还是跨链桥？这一步决定了后续的所有操作。

阶段 2：实例化 (Instantiation)

根据侦察结果，编排器选择加载哪些技能和方法论。一个简单的金库（Vault）合约与一个集成了治理和预言机的借贷协议会分配完全不同的 Agent。

阶段 3：广度搜索 (Breadth)

多个 Agent 并行扫描整个代码库，每个 Agent 同时寻找不同的漏洞类别，以实现全面的覆盖。

阶段 4：清单与语义分析 (Inventory + Semantic Analysis)

去重发现的问题。将每个状态变量映射到所有写入它的位置。寻找协议假设始终为真的不变性（Invariants）——那些没人写下来但整个系统都依赖的规则。

阶段 5：深度挖掘 (Depth)

专门的 Agent 针对每个发现区域进行深入研究，提供具体的边界值。不再是“这可能是一个问题”，而是具体的条件和具体的影响。通过排除已发现问题的列表，递归地重新生成 Agent 进行迭代，以激发更深层次的搜索。

阶段 6：链路分析 (Chain Analysis)

这是我最自豪的阶段。Agent 会思考：“如果漏洞 A 创造了条件 X，而漏洞 B 需要条件 X 才能触发，那么将它们结合起来会发生什么？”两个中等严重程度的问题可能组合成一个致命的漏洞路径。这种复合型漏洞最容易被其他 AI 遗漏，对于任何单次分析来说几乎是不可见的。链路分析阶段之所以能发现复合漏洞，是因为它在推理交互之前掌握了所有先前发现的完整图景。

阶段 7：验证 (Verification)

为每一个发现编写并执行实际的 PoC 测试。如果测试未通过，该发现将被降级。只有经过验证的发现才会进入最终报告。

阶段 8：报告 (Report)

生成一份专业的 AUDIT_REPORT.md，包含执行摘要、严重性表格、带有代码片段的详细章节、执行的 Foundry/Anchor 测试输出以及优先修复建议。严重和高危发现会包含证明漏洞可行的测试输出。

Agent 数量的动态扩展机制

Plamen 会根据复杂度进行缩放。编排器在阶段 2 根据代码行数、外部依赖数量、用户选择的模式以及侦察到的漏洞模式来决定 Agent 数量：

• 轻量模式 (15 个 Agent)：适用于 500 行左右的金库合约。
• 核心模式 (40–60 个 Agent)：适用于标准的 DeFi 协议。
• 彻底模式 (多达 95 个 Agent)：适用于带有预言机、跨链桥和治理的万行级协议。

Agent 数量并非随机，而是对应于需要专门 Agent 覆盖的实际攻击面。

100 万 Token 上下文带来的质变

我选择在 Claude Code 上构建 Agent 运行时，因为它内置了工具调用、文件 I/O、bash 执行和并行 Agent 生成功能。但 100 万 Token 的上下文窗口才是真正的关键。

在 128K 模型中，Agent 必须处理摘要，这会导致信息压缩和丢失。而导致 200 万美元损失的细微状态交互往往就隐藏在被压缩掉的细节中。

有了 1M 上下文，深度分析 Agent 可以在单个上下文中持有整个代码库、所有先前的发现以及完整的方法论。它在分析前会阅读每一行代码，没有任何内容被压缩或丢失。

实际捕获的漏洞类型

静态分析通常捕获模式化问题：缺失重入保护、未检查返回值、旧版 Solidity 的整数溢出等。

Plamen 则能捕获逻辑漏洞：

• “此函数更新了奖励率，但没有先更新累积奖励——因此利率更改后的第一个用户会获得超额支付。”
• “预言机陈旧性检查设置为 1 小时，但预言机每 24 小时更新一次，因此它总是处于陈旧状态。”
• “这两个管理员设置函数的调用顺序可能会使协议进入不变性假设中不可能出现的状态。”

它最擅长的是状态一致性漏洞。语义不变性分析会枚举每个状态变量，映射所有写入点，并在函数更新了一个变量却忘记更新相关变量时发出警报。这是最常被利用且静态分析几乎无法发现的漏洞类别之一。

审计效果验证

我们针对 DODO 审计竞赛运行了 Plamen，这是一场有专业审计师参与、奖金为 47,000 美元的竞赛。

Plamen 实现了 91.2% 的覆盖率。

计算公式：$(14 × 1.0 + 3 × 0.5) / 17 = 15.5 / 17 = 91.2\%$

其中 14 个发现完全匹配（相同的根本原因，相同的修复方案），3 个部分重叠，0 个遗漏。

持续优化与反馈循环

该流水线具有对比模式，可以将 Plamen 的输出与专业审计的基准报告进行对比。每一次遗漏都会按根本原因分类。我们会据此改进 Agent 的观察方式，而不是简单地添加新模式。

每一次迭代都会仔细考虑过拟合和回归问题。目标不是过拟合已知的审计案例，而是构建更好的观察方法。这种反馈循环使 Plamen 从 v1.0.0 进化到了 v1.1.*。

未来发展方向

下一个前沿是单次运行中的多语言审计，例如同时分析包含 EVM 和 Solana 代码的跨链仓库。跨链协议中的大多数实际漏洞都发生在两者之间的边界上。

之后是持续监控。不仅是针对某个时间点的审计，而是一个能够监控状态变化和新部署的 Agent。

目标用户群体

• 独立审计师：希望更快获得更广泛的覆盖。Plamen 进行第一轮扫描，你进行深度分析。
• 协议团队：在支付专业审计费用之前希望获得信号，先清理明显的问题。
• 漏洞赏金猎人：希望对目标进行系统性覆盖。运行 Plamen，审查发现，并为看起来真实的问题编写 PoC。

Plamen 是完全开源的。它运行在你现有的 Claude Code Max 或 Pro 订阅上。如果你审计智能合约、构建协议或寻找漏洞，欢迎尝试。

→ https://github.com/PlamenTSV/plamen

• 原文链接： x.com/p_tsanev/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～