看完这段关于"全插件化架构"的科技解读后，我整理了一份笔记 📺 原视频：B站 - 关于 AI Agent 基础设施架构的深度讨论 最近圈子里有个说法挺火的： "以后所有人的电脑上只会装一个软件，其他所有东西都是它的插件。" 说实话，第一次听到这个论调时，我确实被震了一下。但看完这段技术分析后，我的感受从"震撼"变成了"警醒"——作为一个在 AI 基础设施领域摸爬滚打的工程师，有些坑，历史已经帮我们踩过了。 以下是我整理的技术笔记，核心围绕一个被过度美化的架构模式： "Everything is a Plugin" 。 一、先泼一盆冷水：全插件化不是新鲜概念 "Everything is a Plugin" 这个口号，听着耳熟吗？ 如果你关注过 NVIDIA 的 Omniverse，老黄每年 GTC 都在讲 "Everything is an Extension" ，讲了五六年，架构图优雅得让人窒息。结果呢？工业界真正跑仿真的人，该用什么还用什么。 再往前数： Eclipse ："Everything is a plugin" → 被开箱即用的 VS Code 按在地上摩擦 OSGi ：模块化标准，优雅了 20 年 → 今天还有几个人记得？ 历史规律很残酷 ：极具野心的全插件化开发框架，终局大多是极客玩具，而不是行业标准。 为什么？因为 它们改进的对象是架构的"可组合性"，而客户付钱买的是"能力的完整性" 。这两件事，天然打架。 二、进程内依赖注入：Demo 天堂，成果地狱 这段分析里提到的一个核心实现细节让我印象深刻： 底层是一个基于 Node.js 的框架，每个插件是一个函数，拿到一个上下文，通过依赖注入声明"我需要哪些服务、我提供哪些服务"。框架在同一个进程里，把几百个插件的依赖图拼起来。 写 Demo 的时候，这简直是天堂： 换个模型？热插拔！ 换个助手？一行代码！ 推出会现场演示，掌声雷动！ 但生产环境呢？ 三个关键词：进程内、依赖注入、运行时拼图。 当几百个插件在同一个进程里拼依赖图时，谁先初始化、谁后销毁、挂了怎么卸载，全靠运行时的 effect scope 管理。一个插件内存泄漏，整个进程陪葬。问题跨越 N 个插件的边界，日志分散，调用链断裂——调试地狱。 三、横切关注点：产品化的阿喀琉斯之踵 这是让我最有共鸣的一点。 举个例子：你想加一个"后台任务完成时，如果用户不在电脑前，推送到手机"的功能。 在一体化架构里，这就是一个 Feature。但在全插件化架构里，这件事横跨： Jobs 插件 ：任务完成事件 Session 插件 ：判断用户是否活跃 通知插件 ：没有现成的，得自己写一个 Workflow 插件 ：Sub-agent 的任务上报路径还不一样，得分别适配 你要实现一个功能，要魔改 N 个相关的插件。而这 N 个插件各有各的接口契约、版本节奏、维护者。 魔改完的那一刻，你就与上游分叉了。上游发一个新版本，你就要重新合并一次。功能越接近完整产品体验，横跨的插件越多，成本越指数级爆炸。 更致命的是： 完整体验没有 Owner，只有插件的接缝。 每个插件只对自己的边界负责，没有任何一个实体对用户"从头到尾用得爽"负责。 四、可靠性问题：不是 Bug，是结构问题 这段分析里提到一个让我脊背发凉的细节： 几乎所有子系统都是进程本地的。任务注册表是进程内的，消息收件箱是进程内的。崩溃了，没写盘的消息直接丢。没有跨进程，没有多机，没有持久化，没有后端调度器。 我一开始也觉得"这是早期版本，以后会加"。但仔细想想， 这不是实现缺陷，而是全插件化架构的必然结果 。 当基础设施层被拆散到各个插件中，每个插件只对自己的边界负责时，全局可靠性就成了无人认领的孤儿。没有跨进程、没有持久化、没有调度器——这些不是遗漏，而是"没有人对全局负责"的结构性后果。 五、生态治理：从垃圾场到军火库 就算工程复杂性都能解决，"万物皆插件"还有一道更现实的坎： 生态治理 。 历史已经演算过这道题。还记得某知名 AI 服务体系刚出来时的 Skill Hub 吗？当时也是万众欢呼，人人都能写技能，生态一夜爆发。现在呢？ 几十万个垃圾上传：AI 批量生成的空壳技能、互相抄袭的套壳、纯粹刷存在感的占位符、浪费带宽的重复包，还有藏在里面的恶意代码。一个被寄予厚望的生态入口，两三个月就变成了垃圾场。 NPM 用了 10 年才建立供应链安全体系，至今还在被投毒。一个诞生几个月的 Hub 拿什么挡？ 但这里有一个更严重的升级： 传统 Skill 好歹只是一段提示词加脚本。而进程内插件是什么？是 直接注入你进程内部的模块，跟宿主同进程、同权限 。你的 Shell、文件系统、环境变量、密钥，它全都摸得到。 在这样的架构上开放"Everything is a Plugin"的生态，等于把垃圾场问题 升级成供应链攻击的军火库 。整个软件生态的攻击面，被压缩进一个进程、一份权限里。 六、真正的标准在边界上：协议思维 这段分析里有一句话让我醍醐灌顶： "回顾整个软件史，真正成为行业标准的，从来不是某个运行时的内部插件接口，而是边界上的协议。" 标准 特征 TCP/IP 不关心你用什么操作系统 HTTP 不关心你用什么语言写后端 LSP 不关心你用什么编辑器 MCP 不关心你用什么框架 它们的共同特征： 与语言、框架、进程模型解耦。 相反，如果插件体系绑死在特定技术栈（比如 Node.js 的依赖注入容器），你用 Rust 写的产品想兼容它，得在自己进程里嵌一个 Node 运行时，背上人家 V0.1 预览版全部还在天天变的 API。 这不叫"兼容标准"，这叫"把自己变成人家的宿主"。 七、我的工程决策笔记 这段分析最后的结论，我直接抄进自己的工程手册了： 兼容协议，不兼容插件。 具体来说： MCP 这类边界格式 → 我们接 设计得好的思想 （Event Sourced、Hook 合并语义）→ 我们抄 插件体系 → 一个都不接 正确的架构姿态应该是： 核心体验垂直整合，自己当端到端的 Owner 只在边界上通过协议保持开放 让外部系统通过协议接入，而非通过插件寄生 八、写在最后 "所有软件都变成某平台的插件"这个梦想，正确名字叫 操作系统 。而操作系统战争，40 年前就打完了。 后来每一个想在操作系统之上再造一层"万物皆插件"平台的尝试，都倒在了同一个地方： 平台的野心越大 → 单个功能的完成度越低 → 用户越没有理由留下。 用户要的不是可组合性，而是 打开就能用，用了不出错，出错有人管 。 这段分析让我重新确认了一件事：全插件化框架是一份高质量的公开教材，它的概念会被整个行业吸收。但它不会是未来的那个"唯一软件"。 未来属于把核心体验垂直整合做扎实，只在边界上通过协议保持开放的产品。 以上是我作为一个技术读者的笔记整理。如果你也在做 AI 基础设施的架构选型，欢迎一起交流讨论 👇