我的适应记忆在生产中依然空虚,它不是一个虫子

2026年9月7日2 次浏览来源:Dev.to阅读原文

我在数据库里有个表应该填满自己的 它的工作就是从失败中吸取教训:每当系统尝试某种事物的变体,却不起作用时,它就保存下来了,以后在另一种可能的情况下循环使用.

一个失败尝试的实验室 积聚起来 在生产中,它有零行。

它已经部署好几天了 而且没有保存任何记录 与此同时,一个相邻的表格——另一个记忆,即指出工作已经耗尽以便不再重复的记忆——正在正常地增长。

诱惑是显而易见的:写作中有虫.

我去寻找它, 它不在那里。

零行与写入错误不同 保存到表格中的路径会发出一个警告, 如果写入失败 。

我搜索了记录 以获取这些警告:0。

没有写失败 。

这是事实,不是没有。

如果这条道被取走而失败,那它就会留下痕迹.

零痕迹和零行只适合一个解释:写道从未跑过.

不跑又失败。

没跑 这是真正的负与负之间的区别, 从来没有被测试过, 它们看起来是一样的,除非你寻找 积极的控制——什么是日志会显示的,如果已经采取了路径。

没有它,"健康而安静"和"死"看起来是一样的.

两个机制互相饿死 为什么它不运行?

因为另一个机制,上游, 做好它的工作。

这个系统有一个负面的记忆:当它耗尽了它知道的一切 如何对抗一个目标时, 它会注意到它,这样它就不会再次花精力去 做它已经知道不会付出的东西。

这是一个明智的优化。

但是,它处于产生新变体的阶段之前,这个阶段一旦失败,本会为图书馆提供食物。

一旦目标被"耗尽",这个阶段就完全跳过了.

如果这个阶段从未运行过,它永远不会产生无法保存的失败.

每一种机制本身都是正确的。

负面记忆避免了无用的工作.

图书馆从失败中吸取教训.

他们共同形成僵局:第一个饿死第二个。

图书馆只能从另一个关机的阶段填补。

这是一个反复出现的模式:当你添加一个机制来控制另一个系统的工作,系统开始奇怪地行为,在代码之前怀疑设计.

症状——一张零的桌子——看起来就像个虫子;这是两个块之间的张力,每个块都很好。

具有两个含义的值是两个字段 还有第二个问题 更能说明问题 库只保存了一种失败:系统处理尝试并返回正常结果的失败,没有成功.

另一种——当尝试被阻挡在前方,从未被处理过的时候,它就被抛弃了,有合理的论点:一个街区比变体更能说出目标的姿态.

但这一论点在回收时会散去。

在一个目标被屏蔽的变体是另一个目标一个未经测试的候选者,其配置不同.

抛弃它恰恰是未能从最常见的失败中吸取教训。

解决的不是将两个意义分解为一个意义. "被处理失败"和"被锁失败"是两个截然不同的信号,所以它们走入两个截然不同的领域:两个计数器.

这样,图书馆既能节省,又能节约,无论什么循环它们都命令它们——经过处理的,资料更多的,首先;被封锁的,在后面,但现在——.

有两种含义的价值不是一字段:是二字段.

留下的症状是2个 也没碰过写作,这始终是正确的。

一个打破了僵局——即使目标被"耗尽",也让阶段给图书馆进食;另一个分裂了失败的两面.

而"零"的桌子,看起来就像"虫子",就是"信使":一条从未跑过的道路,一个条件太窄了,从同一个洞里可以看到.

分享