TL;DR：为什么 dsh/cordis 很重要：长时任务和框架元调优

核心思想是，长时任务可能需要一个框架运行数天，Cordis 支持两种场景：框架的一个组件崩溃，我们希望在不重启和丢失状态的情况下恢复；或者，编排器请求一个额外的组件，例如一个未加载的新 MCP。Cordis 强制执行一组准则，说明插件应如何设计以支持这两种场景：它们都通过共享的上下文进行通信，该上下文在组件间传递；它们声明一个模式，指定如何更改上下文；它们应声明对上下文更改的依赖，并为每次对上下文的更改发布一个撤销更改。所有这些加在一起意味着你将拥有一个可逆的、跟踪的依赖关系，存在于所有更改和组件之间，通过版本化的上下文进行管理。因此，对于上述两种场景：如果插件崩溃，你跟踪其每个依赖项并通知它们，它们要么暂停自身，要么优雅降级，即可逆效果的时间可组合性；你添加一个新插件，它更新上下文，触发下游的一系列更新，即响应式更新的空间可组合性。我怀疑这就是他们如何实现接近 100% 的缓存命中：当工具调用失败、MCP 崩溃等情况时，丢弃的状态不超过数学上必要的部分。参见论文 https://github.com/cordiverse/paper 附言：这与 React/redux 使用不可变状态更新管理影子 DOM 的方式没有太大不同，但我说远了。