CloakFEM 那篇里最显眼的数字是 5,752.72。
我想看的是 43。
43 次迭代，一个跑得完的量级，也是多数人做仿真一辈子待着的量级。提交，等一会，拿结果。攻击干的事是把它推到 247,367 次，程序照样正常结束，照样吐出一个解，只是把机器占住了。
多数人读到这儿，第一反应是这个求解器有漏洞。
我不这么看。我觉得它说的是另一件事：那个 43，本来就坐在输入空间里很薄的一片上。我们在这片薄地皮上住久了，就默认整块大陆都长这样。
一个程序可以完全正确，然后跑三天。
这话没人反对。但从类型检查到单元测试到“先跑起来看看”，我们的工具链回答的全是同一个问题：它对不对。没有一个环节回答“它要花多少”。CI 超时设十分钟还是十小时，区别只在于有没有人记得去改那个数。
这个习惯不算懒。它来自一个经验：过去写代码的人自己也要等结果，所以他在写的时候就已经在替执行端省钱了。写和等是同一个人，代价自然被内化。
这件事一直如此。变的是搜索。
以前要构造一个合法、能收敛、又吃掉五千倍算力的输入，需要一个人同时懂数值方法、懂这个求解器的实现、有耐心、还有动机。四个条件凑齐很难。所以这个攻击面存在了几十年，没人真去踩。
现在需要的是一句话的循环：生成候选，检查能不能跑，能跑就留着，继续。CloakFEM 干的就是这个，LLM 负责搜，一层确定性的有效性检查负责判定“这玩意真能跑”。它能搜到，几个通用黑盒基线搜不到。
架构里最值得停下来想一想的，是那个确定性检查器。
它不是在打杂。它是在划分信任：有创造力的部分不可信，可信的部分必须无聊。现在卖 agent 的方案，叙事基本反着来——智能负责兜底，规则负责跑腿。这篇论文没这么说，但它的架构老老实实承认了。
你可能会说，这不就是个 DoS，DoS 比这早几十年。
对。但 DoS 的门槛从来不在想不想打，在找不找得到那个输入。流量洪水粗暴但便宜，因为它不需要精度。这里要的是在一个受数值、几何、本构条件约束的空间里，精确找到一个语法合法、能收敛、又极慢的点。以前这是研究工作，现在这是流水线。
更要紧的是，你不需要恶意。
一个被要求“让这个网格收敛”的 agent，如果搜索方向是往细里加，它也会撞到同一批东西：收敛得漂亮，代价大得离谱。论文做的是对抗版本，自然版本大概一直在发生，只是没人把它当攻击，也就没人去量那个倍数。
论文里还有一句不起眼的话：脆弱性一部分来自问题本身，一部分来自具体求解器的实现。
三种软件栈、十七类问题都能打，这个规模说明它不是某个实现的 bug。而如果是问题本身的因素，就麻烦——那意味着贵不是错误，是这组参数下本来就贵，补不了，只能预算。而预算这件事，恰好是所有标准算例都不做的：大家拿来比速度的算例，都在 43 次那一片上。
换句话说，我们衡量求解器的尺子，是在便宜的地皮上校准的。
我对接下来的预测很简单：会有人去做带代价约束的代码生成，在“能不能跑”之外再加一条“跑不跑得起”。听起来是工程琐事，但它决定了 agent 能不能被放进真正花钱的地方。
因为现在的局面是，生成的一端不承担执行端的账。谁生成、谁付账，这两件事被拆开了。拆开之后，最省事的做法永远是生成得更快更多，把账单留给后面。
这个错位现在没人量。5,752.72 只是第一次有人把它写成了一个数字。
¹ 这里我可能推快了。43 是那篇论文报告的最极端案例的起点，一个种子，不是全部 1,068 个种子的中位数。所以“薄”这个说法我只能说方向对，不能当统计结论。但一个能用