AI 当「反派」，DeFi 保险需要一场压力测试

给 DeFi 金库做碰撞测试：Firelight 拟用 AI 寻找「下一场事故」。

撰文：@jrdothoughts

编译：AididiaoJP，Foresight News

DeFi 保险的盲区：没爆过雷，不等于安全

先听一段黑色幽默式的推销：「我们的新飞机绝对安全，从来没坠毁过。」

「飞了多久？」

「......大概两次。」

把飞机换成 DeFi 金库，故事就很熟悉了：六个月提现顺畅、没被攻击、收益还不错。这当然是证据。但在这六个月里，它有没有遇到网络拥堵时抵押品脱锚、流动性提供者（LP）争相撤出、预言机又不更新？大概率没有。

干净的历史只能说明一个系统承受过什么。承保要问的是：它接下来可能撞上什么。

这是 Firelight 看到的机会：围绕损失的形成方式来定价，而不只是看损失有没有发生过。历史负责锚定，模拟负责探索替代情景，AI 负责找弱点，资本负责背书。

历史是快照，系统却会变

历史损失数据，是一台机器在一种条件下运行时的快照。机器一变，快照就需要重新审视。

一个金库新增了抵押品类型，换了预言机，又提高了杠杆。名字没变，Logo 没变，风险却已经大不一样。里面的借款者、清算人和 LP 也不是表格里摆着不动的数字。他们会对激励做出反应，一旦出事，还都想从同一扇门往外跑。

这就像一张按平常周二通勤情况画出的交通地图。平时看着挺准，主桥一封就不管用了。地图本身没画错，是路况变了。

所以，对 Firelight 来说，真正的问题不只是「这个协议有没有被黑过」，而是：它存在哪些权限？哪些依赖真正重要？所有人同时往外冲时，哪些清算路径还能走？Firelight 公开的框架已经把技术漏洞和经济脆弱性分开，而不是揉成一个安全分数。

承保针对的是系统当前的构造和依赖关系，而不是它沿用至今的那个品牌名。

巨灾保险早就写过剧本

传统保险公司并没有放弃对不确定性的建模。巨灾保险人一直在做一件事：模拟灾害怎么发生、哪些资产会暴露、结构有多脆弱，以及合同最后要赔多少。过去刮过的飓风，代表不了未来所有可能出现的飓风。

DeFi 也需要一套自己的巨灾模型。只不过灾害从飓风换成预言机故障，受灾对象从建筑换成借贷头寸，脆弱性从建筑质量换成抵押缓冲和清算设计，最后再按保障条款计算赔付。

巨灾模型问的是：飓风扫过一座城市会怎样？DeFi 模型问的是：一次故障沿着依赖图扩散，会怎样？

Firelight 公开讨论过，把风险拆解、历史校准、蒙特卡洛模拟、语言模型和强化学习结合起来，接进一个金融碰撞测试实验室。需要说明，这是一个拟议方向，不是宣称每一块都已经上线。

还有一点需要说明：Firelight 把自己的产品定义为协议型保障，而非传统保险合同。文中拿保险作类比，比的是承保纪律，不涉及产品的法律定性。

金融碰撞测试实验室怎么搭

第一步，先把初始状态固定下来，确保可以复现。合约版本、余额、抵押头寸，以及预言机设置、清算规则、市场流动性，都要锁定。否则两次模拟结果对不上，可能只是因为起点不同，测的并不是同一个系统。

第二步，把执行和假设分开。区块链分叉可以跑真实合约逻辑，但它没法凭空变出明天的流动性、链下价格和人的行为。这些必须显式建模。基于分叉、代理驱动的测试，在 DeFi 研究里已有先例。

第三步，给模拟环境安排各类参与者。借款者、清算人、存款人、LP，各有资金限制和激励。但不能给谁开主角光环：清算人不能为了凑一个圆满结局，就去做亏本交易。角色也不必都用大语言模型，简单透明的规则有时更好、更快，也更容易复现。技术层面的失败仍然要靠模糊测试、代码审查和故障注入，这些手段和经济模拟是并行的，不是互相替代。

第四步，搞破坏。价格跳空、预言机延迟更新、流动性变薄、执行中断，都要试。不只改幅度，还要改顺序。LP 在价格冲击前撤流动性，和在冲击后撤，结果可能完全不同。

模拟最后给出的，不该是一个笼统的安全评分，而应该是一条损失链条：哪个头寸先失败、回收了多少、缺口又怎么扩散。有了这条链条，才能决定保障上限和资本要求，或者干脆给出一句「不保」。

让 AI 坐「反派席」，但不能改物理定律

AI 最直观的用法，是读代码和文档。语言模型可以梳理依赖、解释升级、提出失败场景。但一个听起来可信的故事，不等于找到了漏洞，它仍然需要证据。

更有意思的，是让 AI 主动去寻找各种可能情景。蒙特卡洛模拟会从设定好的分布里抽样，这当然有用；但真正糟糕的组合可能太罕见，随机抽样大部分时间只是在重复发现普通情况。

自适应压力测试反过来：代理在模拟器里选择扰动因素，主动寻找可信的失败路径。自动驾驶测试里已经有人用强化学习展示过这套思路。代理可以改变天气，但不能改写物理定律。

在 Firelight 的拟议设置里，代理可以在现实边界内调整预言机延迟、流动性撤出和清算人到场率。找到破坏性路径就奖励，作弊就惩罚。一个拥有无限资本和上帝权限的反派，不是有用的承保模型。

然后让 AI 聚类失败轨迹，挑出最能减少不确定性的下一批实验。几百个看起来不同的灾难，可能共享同一个清算瓶颈。这才有行动价值。

速度也重要。低成本近似方法先筛大量情景，昂贵的执行测试再在多个独立测试环境中重放重要情景。但捷径必须验证。给错误模拟器提速，只会让它更快地自信犯错。

AI 扮演的是对抗测试中的司机角色，不是安全裁判。它指出该查什么，执行引擎、领域专家和证据决定这个发现是否站得住。

从损失轨迹到保障条款

设想一个假想中的借贷金库：抵押品价格下跌，LP 纷纷撤出，预言机更新滞后。清算人虽然进场，但滑点吞噬了回收价值，最终借款人的债务超过了抵押品实际能卖出的价钱。

再做几组对照：只让价格跌；价格跌的同时抽走流动性；几个因素一起上。这样才看得出，真正的弱点是在价格上，还是在市场深度上，又或者出在两者的相互影响上。

假设一次示例运行产生 200 万美元合格损失，自留额 50 万美元，保障上限 100 万美元。自留层吸收 50 万，假设保障赔 100 万，剩下 50 万落在限额外。

这些是虚构示例条款，不是 Firelight 的报价，也不是真实模拟结果。合格性、回收、除外责任和重叠保障，都还需要厘清。

关键在于：有经济损失，不代表就能拿到赔付。模拟只有影响到承保决定，才算真正有用------比如调低保障上限、要求更严格的风控、多留资本，或者干脆拒保。灾难动画做得再好看，也还不是一个财务决定。

找到失败路径，不等于算出概率

假设一个对抗性代理在 30% 的测试中攻破了系统。这是否说明系统有 30% 的失败概率？并非如此。这个代理本来就是专门来找漏洞的。

发现失败，回答的是「可能怎么坏、能坏到什么程度」。估计概率，回答的则是「这些条件在保障期内出现的频率有多高」。把两者混为一谈，就是在制造虚假的精确。

从概念上说，预期赔付就是每个情景下的赔付金额，乘以该情景发生的概率，再全部加总。这些概率需要证据支撑，假设也要明确写出来。如果没有可信的估计，就用区间、保守上限和压力约束，而不是编造精确到小数点的数字。

预期赔付并不等于全部保费。资本还要覆盖尾部风险、运营成本和不确定性，而尾部风险往往相当难看。放到组合层面看，共享依赖还可能让多份合约同时触发赔付。

Firelight 公开的资本框架已经考虑了集中度和抵押品回撤。模拟则应该同时压测两头：一头是理赔激增，另一头是支撑资产同步贬值、甚至变得更难卖出。如果一场大灾来袭时资本也跟着缩水，保障池就不能只按平均损失来估算。

谁来压力测试「压力测试器」？

模拟器可以逻辑自洽，结论却完全错误。拿不现实的清算人设定跑一百万次，无非是把同一个错误重复一百万遍。多跑几遍能减小抽样误差，但模型本身的误差不会因此自动变小。

可信的实验室会做四件事：复盘已知事件，用样本外数据检验，对比不同团队独立搭出的模型，调整对参与者行为的假设。快照、随机种子和运行记录都要存档，关键发现才能复现。还要反复问一句：AI 找到的，是协议的弱点，还是模拟器自己的 bug？

没有哪套测试能证明已经找全所有灾难路径。正因为存在未知依赖和从未见过的行为，才需要资本缓冲、除外责任和承保克制。

合同边界也要讲清楚。新证据可以影响未来定价和容量，但不应该让现有保障变成移动靶。Firelight 公开的框架，把持续的风险监控和覆盖期内固定的费率分开处理。持续学习和守住承诺可以并存；但危险出现后再改写承诺，就不行。

结论：在损失出现前学习

更大的价值，是让承保嵌入开发流程。系统出现重大变化，就会触发相应的测试；测试结果影响新的保障决策；真实事件帮助改进下一版模型。工程做得越好，最终越会反映在保障价格和可获得性上。

历史理赔是在事后补课。模拟则让 Firelight 提前弄清：这套系统可能怎么出现故障。

AI 负责扩大搜索范围，证据负责约束它的结论，资本负责兑现承诺。目标不是预测每一场灾难，而是在看清可能面对什么之后，再投入资本，去扛住那些不得不扛的损失.