DeepSeek Harness 不会是未来｜everyth #人工智能生态 #软件工程 #deepseek概念

我亮明立场：我是资深DeepSeek吹，前阵子我吹过R1，我吹爆过，他们配得上，但这次我要泼个冷水，DeepSeek Harness不会是未来。 最近圈子里有一种声音说，以后所有人的电脑上只会装一个软件，就是DeepSeek，其他所有东西都是它的插件。操作系统之上，一个Harness统治一切。说这话的人，既不理解历史是什么，也不理解软件工程是什么。先说说我怎么理解DeepSeek：这是一个极具野心的框架。MIT开源三天十几万星，核心宣传就一句话，Everything is a plugin。模型是插件、工具是插件、会话是插件、沙箱是插件，连文件系统都是插件，听着耳熟吗？这么宣传的是英伟达Omniverse，Everything is an extension。对，就是老黄每年GTC都要讲，讲了五六年应者寥寥的那个物理AI仿真框架，架构上无比优雅，PPT上无比性感。然后呢？工业界真正跑仿真的人该用什么还用什么。 再往前数，这个名单还很长。Eclipse说，Everything is a plugin，被开箱即用的VS Code按在地上打。OSGI模块化标准优雅了二十年，今天还有几个人记得？历史规律很残酷，极具野心的全插件化框架，终局大多是极客玩具而不是行业标准。因为他们优化的对象是架构的可组合性，而用户付钱买的是功能的完整性。这两件事天然打架，这不是云评价啊。 我们团队自己在做Agent基础设施。DeepSeek一开源，我们花了三天时间把它的源码一个包一个包啃完了，Subagent、Workflow、Jobs、Go Session Hooks，逐行核对它的契约文档。我们当时认真思考的问题，跟今天这些人一样：它会不会成为行业标准？我们要不要兼容它，接入它？ 先说好话，这是对得起DeepSeek招牌的代码，Event Source的会话日志做唯一事实源驱动状态机，用CAS防并发，Hook合并规则是Deny大于Ask大于Allow，最严格合并每个包的MR，精确到行号都能对上，工程纪律非常高，甚至高到有点学院派，但看的越深，我们越确定它不会成为行业标准。原因不在代码质量，在软件工程的复杂性本身，看看它是怎么动态注册插件的。DeepSeek底层是一个叫Cordes的Node.js开源框架，它的插件模型是这样的：每个插件是一个函数，拿到一个上下文，通过依赖注入声明我需要哪些服务，我提供哪些服务。框架在同一个进程里，把几百个插件的依赖图拼起来，谁先谁后，谁挂了要连坐，卸载谁全靠运行时的Effect Scope管理。注意关键词：进程内依赖注入、运行时拼图。 这套东西写Demo的时候是天堂，换个模型是插件，换个沙箱是插件，发布会上现场热插拔，掌声雷动。但你真拿它做产品，第一天就会撞上那个所有插件化框架都逃不掉的死穴：横切关注点。举个我们调研里的真实例子：你想加一个很朴素的功能，后台任务完成时，如果用户不在电脑前，推送到手机。在一体化架构里，这是一个Feature。在DeepSeek里，这件事横跨Jobs插件的任务完成事件、Session插件判断用户是否活跃，通知还没有插件，要自己写一个，然后Subagent的任务和Workflow的任务上报路径还不一样，你还得分别适配。这就是那个致命问题：你要实现一个功能，要魔改N个相关的插件，而这N个插件各有各的接口契约，各有各的版本节奏，各有各的维护者。你魔改完的那一刻就跟上游分叉了，上游一发新版本，你就要重新合并一次。功能越接近完整，产品体验横跨的插件越多，这个成本越指数级爆炸。 更要命的是，我们逐包核对时发现，DeepSeek现在几乎所有子系统都是进程本地的：任务注册表是进程内的，Subagent的收件箱是进程内的，崩溃了没落盘的消息直接丢，没有跨进程，没有多机，没有持久化后端，没有调度器。这些不是Bug，这是全插件化的必然结果：完整体验没有Owner，只有插件的接缝，每个插件都只对自己的边界负责，没有任何一个插件对用户从头到尾用得爽负责。 还有一个细节特别能说明问题：DeepSeek自己内置了对Cloud Code和Codex的Hook兼容桥。朋友们，定标准的人是不需要兼容别人的，它自己都在向现有生态低头，你跟我说它是下一个标准？ 好，退一万步，就算工程复杂性都能解决，万物皆插件还有一道更现实的坎：生态治理。这道坎不用推演，已经有前车之鉴了。还记得龙虾刚出来那阵的Skill Hub吗？当时也是万众欢呼，人人都能写技能，人人都能上传生态，一夜爆发的增长曲线跟DeepSeek现在一模一样。现在你再去看看，几十万个垃圾上传，AI批量生成的空壳技能，互相抄袭的套壳，纯粹刷存在感的占位符，浪费带宽的重复包，还有藏在里面的恶意代码，一个被寄予厚望的生态入口，两三个月就变成了垃圾场。你想找一个真正能用的技能，得先在垃圾堆里筛选半天，还不敢直接跑，因为你不知道它会不会顺手把你的环境变量和密钥打包发走。这不是龙虾团队不努力，这是开放插件市场的物理规律：上传零成本，审核跟不上，AI让垃圾生产的边际成本降到零，劣币驱逐良币的速度比任何治理手段都快。NPM用了十年才建立起来的供应链安全体系，至今还在被投毒，一个诞生几个月的Hub拿什么扛？ 现在把这个规律套到DeepSeek身上，问题更严重。当年龙虾的技能好歹只是一段提示词加脚本，而DeepSeek的插件是什么？是直接注入你Agent的进程内部的Node模块，跟宿主同进程同权限，你的Share、你的文件系统、你的凭据，它全都摸得到，没有沙箱隔离，没有权限边界。在这样的架构上开放Everything is a plugin的生态，等于把龙虾Skill Hub的垃圾场问题升级成供应链攻击的军火库。所以“所有软件都变成DeepSeek插件”这句话翻译一下，就是把整个软件生态的攻击面压缩进一个进程、一份权限里，然后拿人人可上传去喂它。历史已经用几个月时间演算过这道题，答案不会因为换了个名字就不一样。 回顾整个软件史，真正成为行业标准的，从来不是某个运行时的内部插件接口，而是边界上的协议。TCP/IP是协议，HTTP是协议，LSP是协议，这一轮AI里真正有标准相的是MCP，它们都不关心你用什么语言、什么框架、什么进程模型。而DeepSeek的插件是绑死在Cordes依赖注入容器里的Node进程内模块，你用Rust写的产品想兼容它，你得在自己进程里嵌一个Node运行时，备上人家V0.1预览版全部还在天天变的API，这不叫兼容一个标准，这叫把自己变成人家的宿主。所以我们三天研究完的