上篇提到的反馈循环的设计，我觉得很不好。

正常来说反馈、修复、迭代和任务的正常运行，应该是几条互不相关平行线，不能相互依赖，以避免相互影响。

上篇提到的方式是强耦合的，很有可能改进反馈的链路时动到正常的任务执行。可一时间我也想不出比较好的方式能解耦，大脑的想象力还不够丰富。

就昨天，睡觉前胡思乱想，突然回忆起四月29号，升级龙虾然后回退版本的过程。

龙虾还真别乱升级。

当时，我为了让自己的飞书多个机器人能对应到不同的workspace（为了隔离 soul 和 memory），翻文档去查资料，配置。

倒腾了1小时之后，我发现自己看的是最新版本龙虾的文档，老版本的文档太多了没心思去找了。最后，我问龙虾的网页版本 Chatbot 要方案，它让我升级，然后我信了，最后我哭了。

三小时过去了，配置是配置完了，但是 Feishu 和龙虾的通道搞坏了，飞书发消息龙虾收不到了。

后来，我打开龙虾的Web UI，它提示我是否上报这个错误 “feishu[default]: failed to dispatch message: TypeError: (0 , _feishu.createScopedPairingAccess) is not a function” ，最终我选择了是，然后回退版本，呆呆的盯着屏幕坐了好一会儿~

Git Hub Issue 迭代与反馈

再后来，我在龙虾的 Issue 下面找到了这个报错。https://github.com/openclaw/openclaw/issues/74138#event-6280888754

（这个 issue 当时就有人修复，但是一直没合并到主干。后来，龙虾认为这个修复已经过时了，打上了 stale 标签...）

不过现在想来，反馈循环这条路似乎可以参考龙虾。

在龙虾的设计里面，反馈链路是独立与任何具体功能模块的，或者说是一个切面。当遇到错误的时候，上报 Issue，具体的 Issue 再通过 Git hub 的 Pipeline 进行自动的修复、审核、打标等工作，人的精力只需要放在 CR 上。

不过，还有一点我没想通。如果大量用户上报同一 Issue，这个怎么优化呢（避免重复）？

不过这是后话了~~