AI不需要中心化插件市场，未来的插件是去中心化的 回到过度设计的话题。是不是插件化就是过度设计了呢也不是。我觉得一种理想的形态就是模型用Tag还有关键词自然均匀地分布在互联网的各个仓库或者一些网站里。本地一个小巧的模型利用强大的互联网和本地搜索能力去互联网上执行下载下到本地以后它在本地又有能力去执行。这就像我们的人一样一个人拿到电脑会去网上搜信息搜到信息以后下载到本地无论是自己看还是在本地去用、去学都是从网上获取信息的能力。我们学习知识的时候要不要在身上装一些额外的东西不用它全部内化在了我们的脑子里面。所以对于模型来说它自己拥有一个本地的上下文它就拥有了脑子。那还有必要自己去迭代那么多插件装在自己身上吗这个时候我们再提到我们要去维护插件的更新要去维护插件和插件之间的冲突要去维护插件的持久化上下文要去更新插件是不是很麻烦插件装多了以后很大概率出现的情况就是某几个插件高频使用其他插件吃灰。然后你要去承担这些插件的维护成本、更新成本。最后你会因为系统的复杂性甚至觉得这个系统已经无可救药了没有办法再用了或者一段时间以后你会觉得有割裂感。所以说维护一个精简的插件系统但不代表你就没有插件。插件可以以更加灵活的方式去获取、去组装。DSH这种在本地没有副作用的组装插件的方式正适合这种更加灵活的插件获取方式。未来的插件会越来越多未来的Agent可能不再需要我们去一个插件市场浏览插件Agent会越来越多地自己灵活地组装插件而Agent的核心能力就像DSH的极简模式一样就是执行和获取。但这里必然会引出一个核心问题如果AI从互联网上动态检索并拉取任意代码在本地执行系统的安全性、环境隔离与数据边界该如何保证我认为这部分的安全性必须由底层的Harness来负责这也正是Harness真正应该承担的角色。我曾经在Koishi插件生态里看到过一种很巧妙的插件类型利用中间件来实现检查其他插件的安全性。如今DSH底层的Cordis也是基于Koishi的插件系统发展而来我认为这是一个非常有趣且极具潜力的方向。当AI去中心化地抓取外部脚本时底层的Harness通过中间件机制在入口处构筑起坚固的沙盒与拦截层。它不仅能记录副作用在卸载后干净回滚还能在插件执行前进行安全扫描与权限拦截确保多个插件之间互相不影响也不会污染核心系统。通过将安全与隔离的重任完全交给Harness中间件我们就能以极轻的架构实现真正的动态可插拔设计。在这么好的底层设计下我们还有没有必要像传统插件那样需要下载重启、自己维护更新专门做一个插件市场让用户下载下来还要去更新——我们已经走到AI这个阶段了。我在用ChatGPT的时候有一种感受当我需要什么的时候我直接在提示里说请你访问什么仓库写一个什么工具在你的运行时里面去调用。我们看到豆包的办公空间也是和Codex一样的设计你可以让它在里面写一个脚本持久化在里面然后运行在里面。也就是说AI有了自己去管理自己插件系统的能力。这个时候我再看互联网上关于Codex、关于智能体插件市场的设计我会发现大家还是在走老路还是在用原来的产品思路去做这个插件系统。我看到点进去之后一页一页的Agent一页一页的Skill自己去点、自己去选。DSH发布以后有很多人开始写各种样换皮的、五花八门的插件市场本质都是一样的维护一个源想要让开发者把插件留在他们的插件市场里面用户还是需要一个一个去点点了就下载本地动不动去更新。我觉得这种插件形式在AI时代是天然不需要的。这些插件站不应该再有占山为王的流量思想想把它做成自己有流量的专门仓库、专门站点。其实它可以更加去中心化你的插件可以是一句话发在任何一个会被搜索引擎搜索的文章里可以被发在任何一个开源仓库只要对公开访问对于AI来说就已经在它的插件仓库里面了。所以说AI的未来应该是越来越不追求这种形式。可能我们以后看到的AI产品它没有插件市场没有Skill市场也不会有这么多下载站、更新站。这些都是老的传统观念的东西了。以后应用最好的形态依然是它最开始的那个形态就只有一个对话框。而它背后的核心是对话框里的搜索能力、Harness提供的底层安全防护能力与执行能力。未来的AI开发者、做插件的开发者、做内容的开发者我觉得更重要的能力是被AI所发现的能力。你要想办法让你的插件不出现在传统的什么Skill市场、什么插件市场里这些都是用老的打法去打一个新的东西太传统了。你会发现这里遇到很多宣传的问题同类的Skill站、Skill模板站、提示词模板站有几千个几万个这是一个红海的领域而且我觉得这是一个错误的赛道。其实你应该做到的是把你的Skill写好就让它好好放在GitHub里面让它慢慢去涨star。你不需要把它提到这个商店那个商店这个Agent的市场那个Agent的市场。但是你的插件有人用这是一个很自然、很美好的状态。