8月13日，Deepseek Harness发布了。鉴于Deepseek V4 Flash确实很好用，最近也在关注相关的消息，于是第一时间去观摩了一下它的仓库。
首先肯定是看README嘛，这一看不得了，看到了一个似曾相识的名字——Cordis。
我的大脑花了5秒钟思考以前在哪看到过这个名字，点进去一看，还真是它，Koishi框架的元框架。
关于Koishi
两年前，自以为好像学了点什么东西的我兴冲冲地想要做一个聊天机器人。一开始用QQ官方机器人的Python SDK，写了一会儿感觉写着很不得劲，这很多轮子不应该我自己造吧，于是上网找轮子。嗯，这是什么，Koishi，（一看就是个东方厨做的，）看起来好像挺厉害的，插件生态也很完善，好，就用你吧。
彼时的我甚至并不能很好地理解平台、协议与框架之间的联系，只是依葫芦画瓢跟着教程一步步把东西都搭起来。我不由得感叹这Koishi真是把啥都做完了啊：命令格式解析、消息缓冲队列、热插拔、资源管理、GUI管理、数据库……除了觉得插件逻辑得全部放在一个lambda表达式里有点不爽之外，由衷赞叹其强大。（虽然这个不爽点完全不是框架的问题而是当时的我逻辑拆分能力有限的问题）
另一方面我又觉得这个框架有的地方做的有些过头了。比如数据库方面，数据库插件完全定制了一套自己的API，一方面存在一定的学习成本，一方面对插件维护者来说这个维护成本也是挺大的，至少我记得当时这些数据库API有很多都还是实验性或未完成的。于是在数据管理这块还是略为不舒服。又比如Koishi完全按照OneBot协议封装API，想要调用有的QQ专有的API就比较麻烦。
不过这些也不好说了，毕竟两年前的我太菜了，也许现在回去看这些其实完全不是问题呢。
出于对这个框架的敬佩，我几乎阅读了它的全部文档，也就包括介绍Cordis的文档了。Cordis的核心思想简单来说就是实现真正的热插拔，在插件移除时完全消除插件为整个系统带来的“副作用”，在此之上处理好插件之间的依赖关系等跨插件业务。
当时的我虽然看得不是很懂，但大为震撼。震撼之余，却又觉得它实际上还是挺冷门的元框架，基于它的最有名的项目大概也就是Koishi了。也因此，当时的它并没有在我的大脑里占据太多地方。后来因为QQ机器人老是被安全警告下线，也就没再关注Koishi和Cordis了。
关于Deepseek Harness与Cordis
谁料后来我也开始对“造框架”产生了极大的兴趣，架构的执念几乎伴随了后来我的编程成长历程（说的好像我长进了多少似的），一开始是浅薄地在开写业务前绞劲脑汁抽象接口、思考泛用性；后来开始有意地接触现有框架，试图理解它们的设计思想；再到从具体目标出发，评估哪里该好好设计、哪里不用太操心……不管怎么说，能够让别人认可、用上我造的框架，一度成为令我痴迷的事情。
做本科毕设的时候，我一开始煞有其事地把“框架”作为了毕设标题的中心，结果开题时被评审老师猛猛质疑“你是不是想只搞个外壳不做具体功能”，着实让我破防了。那是我头一次如此深刻地认识到即使是在“行内”，也不是所有人都会在乎你的代码有什么或许精妙绝伦的设计、或许惊为天人的架构，更何况我其实也并不能做到。
也正是因此，当我看到Deepseek Harness的介绍里十分C位地把Cordis摆上台面，明晃晃地摆出Cordis的Slogan—— “一切皆插件” 时，当我点开Cordis的作者主页，发现他的Profile上不知何时赫然挂着deepseek-ai时，我有一种恍惚感。这恍惚一方面来自这意外的“重逢”，有一种过去在路边摊瞥见的作品如今成了畅销榜的感觉；另一方面也是在这其中看到了我梦想中的自己：在这样万众瞩目的作品上，骄傲地，毫不遮掩地宣告着， 这是用我的框架做的。
之后的几天我也在积极地了解着网上对Deepseek Harness的看法，倒确实大多数人以前是没见过这Cordis的，也毫不意外地，大多数人的观点分为了泾渭分明的两极：喜欢的人毫不吝啬对它的夸赞，认为它走出了不同的路，且潜力极高；不喜欢的人则觉得它像个玩具，是小团体自嗨的产物，没办法与其他主流Agent竞争。用一种自大且短视的比喻来说的话，前者就像“我”，后者就像“听我开题的评审老师”。
只是因为在Deepseek Harness以前就接触了Cordis，便让我无端地有了一种飘飘然的感觉。或许以后我的身影也会像这样出现在哪个主流项目的身影中呢？或许呢……
