夜雨聆风从 ObjectStack 的 Microkernel、Plugin 与 Runtime，看企业软件为什么正在从应用走向软件底座
适合阅读：CTO / 架构师 / SaaS 创业者 / 技术负责人 / Agent 工程师 / 后端开发者
几乎每个做过企业软件的人都熟悉，一个 CRM，最开始很单纯，就三样东西：客户、线索、机会。它要解决的问题很清楚——帮销售管好客户。
但几年过去，你再打开这个 CRM 的代码库，会发现它早就不是当初那个样子了。它里面塞满了这些东西：
登录· 权限 · RBAC · 数据权限（行级/字段级） 工作流· 审批 · 审计日志 · Webhook 消息通知· 文件存储 · 实时推送 · 全文搜索 报表· 仪表盘 · 定时任务 · AI · MCP…… |
于是一个尴尬的事实出现了：这个 CRM，早已不只是一个 CRM 了。它在自己内部，悄悄实现了一整套小型操作系统——那些登录、权限、审计、存储、实时，没有一样是客户管理这门业务本身的东西，但它们全都长在了这个 CRM 里。
而更让人无奈的是：隔壁那套 ERP、那套 HR、那套工单系统，各自也都在重复地、从头造着同样的一套东西。每一个企业软件，都在自己的院子里，重新发明同一批轮子。
于是两个问题浮出来了。第一个是老问题：
为什么每一个企业软件，都要重复实现同样的一套基础设施？
第二个，是 AI 时代的新问题：
如果 AI Agent 成了软件的新使用者，这种每个应用自己造轮子的架构，还撑得住吗？
这两个问题合在一起，指向了一个正在发生的转变。这篇文章想借开源项目 ObjectStack 作为案例，来讨论它——先说清楚，ObjectStack 是本文的案例，不是主角。真正的主角是这个判断：
AI-Native 软件真正需要的，可能不是更厚的 Application，而是更强的 Runtime。
一、企业软件，为什么会越做越像操作系统？
先解释一个长期存在、却很少被正面讨论的问题：企业软件之间，存在着大量的基础能力重复。
你去看 CRM、ERP、HR、工单、财务这些看起来八竿子打不着的系统，会发现它们在底层需要的东西惊人地一致——用户、身份、权限、审计、数据存储、工作流、消息、定时任务、Webhook、文件、实时能力。这些东西,没有一样属于某个具体业务,但每个系统都离不开。
而传统的做法是什么呢?是每个系统各造一套:
CRM → 自己做一套（用户/权限/审计/工作流/存储……） ERP → 自己做一套（几乎一模一样的东西，再来一遍） HR → 自己做一套（还是那套东西，第三遍） |
这么做的代价，是复合的：重复开发、能力不一致、权限体系碎片化、数据治理碎片化，到了 AI 时代，还多了一条——Agent 接入方式也碎片化。最终结果就是，每一个 SaaS 都越做越胖，一大半的重量，压在了那些和它核心业务无关的基础设施上。
问题的根子，不是这些应用做得不够好，而是——应用承担了太多本该由 Runtime 承担的责任。它们本该只关心业务，却被迫连地基一起自己造。
二、操作系统为什么是一个好的类比？
讲到这，操作系统这个类比自然就浮现了。但我们不能只是含糊地说它像操作系统，得说清楚这个类比到底成立在哪。
回想一下传统操作系统的结构：内核之上是驱动，再上面是系统服务，最上层才是各种应用。
Kernel（内核） ↓ Drivers（驱动） ↓ System Services（系统服务） ↓ Applications（应用） |
在这个结构里,一个应用(比如一个文本编辑器)不需要自己去管理 CPU 调度、内存分配、文件系统、网络、进程、权限——这些统统由操作系统提供,应用只管调用。正是因为有了操作系统,应用才能只关心自己那点事。
企业软件的 Runtime,可以形成一个高度类似的结构:
Enterprise Kernel（企业内核） ↓ Plugins / Services（插件 / 服务） ↓ Business Runtime（业务运行时） ↓ Applications（业务应用） |
在这个结构里,一个业务应用(比如 CRM)不再需要自己实现登录、权限、审计、存储、工作流、实时、MCP——它调用 Runtime 提供的这些能力就行。
所以 Enterprise Runtime 真正的价值,不是让开发更快这种效率层面的好处,而是一件更结构性的事:把通用软件能力从 Application 里彻底抽离出来,让应用回归到只关心业务。
三、ObjectStack 为什么选择 Microkernel（微内核）？
（以下涉及架构的描述，以 ObjectStack 当前公开文档为准。）
根据 ObjectStack 当前的架构文档，它的内核非常小,核心只负责几件最基础的事:依赖注入、事件总线、生命周期，以及插件的生命周期管理。除此之外的一切业务能力,都通过插件组合上去。
这就是微内核（Microkernel）架构。它的结构大概是这样:
ObjectStack Kernel（微内核） ┌──────────────────────────────┐ │ DI（依赖注入） │ │ EventBus（事件总线） │ │ Lifecycle（生命周期） │ └───────────────┬──────────────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ Security Storage MCP ▼ ▼ ▼ Approval Audit Automation （以上能力均以插件形式组合） |
这里要强调一点:选择微内核,不是为了架构看起来高级。它真正的目的,是建立一个清晰的能力边界——内核只做最不可能变的那几件事,把所有会变、会增减的业务能力,都推到插件层。内核越小、越稳定,插件的组合空间就越大、越灵活。
一个小而稳的内核 + 一堆可自由组合的插件,这个组合的意义,你会在下一节看到——它恰恰是企业软件操作系统这个想法能成立的地基。
四、Plugin 不是模块化代码，而是可组合的能力
很多人一看到插件,第一反应是哦,就是模块化、可插拔嘛。但在 AI-Native 的 Runtime 里,Plugin 的意义要重得多。
传统语境里,Plugin = 可插拔的功能。而在这里,Plugin = 可组合的能力。
差别在哪?看一下 ObjectStack 用插件承载的那些东西——鉴权、安全、共享、审批、审计、存储、实时、Webhook、邮件、MCP、自动化……这些没有一样是某个具体业务,它们是企业软件的通用基础能力。
于是,一个具体的业务系统,就可以被拆解成业务定义 + 业务逻辑 + Runtime 插件的组合:
CRM = 客户等业务对象（Metadata）+ 销售逻辑 + Runtime 插件 ERP = 财务等业务对象（Metadata）+ 财务逻辑 + Runtime 插件 Support = 工单等业务对象（Metadata）+ 支持逻辑 + Runtime 插件 |
看出来了吗?三个完全不同的业务系统,它们各自独有的只是前半截(业务对象 + 业务逻辑);而后半截那套 Runtime 插件(权限、审计、工作流、存储……),是共享的、不需要每个系统重复实现的。
于是可以提出一个判断:未来企业软件的竞争,可能越来越从谁的应用功能更多转向谁的 Runtime 能力更强、组合能力更高。应用层面的功能会越来越容易被拼装出来,而底层 Runtime 的深度,才是真正的壁垒。
五、为什么 AI Agent 的出现，让 Runtime 从幕后走到了台前？
在传统世界里,软件的使用路径是这样的:人,通过 UI,使用应用。Runtime 在很多时候,只是藏在应用背后的基础设施,人根本感知不到它的存在。
传统： Human（人）→ UI → Application （Runtime 在幕后，是后台基础设施） |
但 AI Agent 的出现,改变了这个格局。现在多了一条使用路径:
AI-Native： Human → UI → Application AI Agent → MCP → Runtime → Application |
关键在于:Agent 不应该、也不能像人那样,随便去碰底层的数据库、内部服务、或者某个随机的 endpoint。如果放任每个 Agent 直连底层,企业就彻底失去了对它们的控制。Agent 必须经过一个统一的 Runtime。
而当 Agent 都从 Runtime 走,Runtime 就必须承担起一套全新的职责:
Runtime 面向 Agent，必须负责： · Identity（这个 Agent 代表谁） · Permission（它能做什么） · Policy（什么操作受什么约束） · Action（它能调用哪些业务动作） · Audit（它做过什么，全部留痕） · Tool exposure（哪些能力暴露给它，哪些不） |
于是一个深刻的角色转变发生了:Runtime 正在从应用背后的基础设施,变成AI 与企业业务之间的治理层。它不再是那个人感知不到的后台,而是站到了 Agent 和业务之间,成了那道决定AI 能安全地对企业做什么的关口。
上一篇我们讲的是MCP 怎么让 Agent 进入软件;而这一篇真正想讲的是——Agent 进来之后,为什么必须让它经过 Runtime。前者是入口,后者是治理。而治理,才是企业级的真正难点。
六、如果没有统一的 Runtime，会发生什么？
用一个反例,把上一节的判断坐实。
假设一家公司,给它的每一套系统都配了 Agent:CRM Agent、ERP Agent、HR Agent、工单 Agent。而每一套系统,都各自直接对自己的 Agent 开放 API。听起来很美好,每个 Agent 都能干活。但实际上,Agent 面对的会是这样一张支离破碎的图:
Agent ├── CRM 的一套 API ├── ERP 的一套 API ├── HR 的一套 API ├── 工单的一套 API └── 各种内部服务 |
问题会立刻涌现——而且全是不一致:
· 权限模型不一致（每套系统权限规则都不一样） · Tool schema 不一致（Agent 要适配四套不同的工具格式） · 审计不一致（出了事，日志散在四个地方对不上） · 策略不一致（什么该审批、什么该拦，各说各话） · 身份不一致（同一个人在四套系统里是四个身份） · 数据边界不一致（谁能碰什么，没有统一说法） |
结果就是:Agent 确实可以调用这些系统,但企业无法治理它们。你放出去一群能干活的 Agent,却管不住它们——这在企业环境里,是不可接受的。
所以,当 AI Agent 的数量开始增长,企业真正需要的,可能不是更多 Agent,而是一个更统一的 Agent Runtime——一个让所有 Agent 都走同一套身份、权限、审计、策略的治理层。
七、ObjectStack 的 Runtime，到底提供了什么？
根据仓库当前架构,它的 Runtime 承载了一批能力(ObjectQL、安全、鉴权、共享、审批、审计、存储、实时、自动化、MCP、任务队列、Webhook、国际化、分析等)。但比起罗列,更有价值的是把它们按职责平面归类——这样你能看清 Runtime 到底在管哪几类事:
职责平面 | 承载的能力 | 它负责什么 |
数据平面 Data | ObjectQL、存储、查询、CRUD | 业务数据怎么存、怎么取 |
治理平面 Governance | 鉴权、权限、行级/字段级安全、审计、审批 | 谁能做什么、留不留痕 |
自动化平面 Automation | 工作流、定时任务、队列、Webhook、事件 | 业务怎么自动流转 |
Agent 平面 Agent | MCP、工具暴露、AI 动作 | AI 怎么安全地接入 |
体验平面 Experience | ObjectUI、视图、仪表盘、导航 | 人怎么看、怎么用 |
把这五个平面摆在一起看,一个判断就清楚了:Runtime 正在成为企业应用各种能力的汇流层。数据、治理、自动化、Agent、体验——这些原本散落在每个应用内部、各造各的能力,正在汇集到同一个 Runtime 里,被统一地提供、统一地治理。
八、为什么 ObjectQL 和 ObjectUI，也是Runtime 思维的一部分？
ObjectQL:让业务不必围着具体数据库转
传统开发里,你的业务是紧贴着具体数据库设计的——你脑子里想的是 PostgreSQL 的表、MySQL 的索引、MongoDB 的文档。换个数据库,业务代码就得跟着大改。而 ObjectQL 的思路是插一层进去:
Business Object（业务对象） ↓ ObjectQL（统一的业务查询层） ↓ Storage Driver（具体存储驱动：PG/MySQL/Mongo…） |
业务面对的是业务对象,而不是某个具体数据库。底层换存储,上层业务定义不用动。
ObjectUI:让界面也从业务定义里派生
同样的思路用在界面上:
Business Metadata（业务元数据） ↓ UI Metadata（界面元数据） ↓ Renderer（渲染器） |
你会发现一个统一的模式:数据层和 UI 层,都是围绕业务定义建立的,而不是各自为政。正是这一点,让整个 Runtime 真正成为一个懂业务的 Runtime(Business-aware Runtime)——它不是一个通用的、什么都不懂的插件容器,而是一个理解客户、机会、工单这些业务概念的运行时。这也是它和普通「插件系统」最大的区别之一。
九、数据库、UI、MCP，都成了同一个 Runtime 的出口
既然数据层、UI 层、Agent 层,都围绕同一份业务定义建立,那么同一套业务定义(客户、机会、工单),就可以被 Runtime 派生、暴露到多个出口:
Business Metadata（一份业务定义） │ ObjectStack Runtime ┌──────────┼──────────┐ ▼ ▼ ▼ Data UI API │ │ └──────────┬──────────┘ ▼ MCP |
这里不说所有东西都自动生成这种过头的话。更准确的表述是:同一份业务定义,成为了多个运行时能力的共同来源。数据怎么存、界面怎么显示、API 怎么暴露、Agent 怎么操作——它们不再是四套独立的实现,而是同一个业务定义的四个出口。
十、企业软件真的会变成一个操作系统吗？
明确一点:不要把企业操作系统理解成字面意义上的操作系统。它不是给企业用的 Linux,它不管 CPU 调度、不管内存分页,它仍然运行在 Kubernetes、Linux、云、数据库之上。
更准确的说法,是它是一个类操作系统的 Runtime(Operating-System-like Runtime)——它借用了操作系统的几个结构性特征:
· Kernel（内核） · Plugin / Driver 模型（插件 / 驱动模型） · Shared Services（共享服务） · Capability boundaries（清晰的能力边界） · Resource governance（资源与权限治理） · 支持多个应用、多个用户 / Agent 同时运行 |
OS 在这里是一个架构类比,不是一个产品类别。它说的是企业软件正在长出操作系统那样的分层结构,而不是出现了一个叫企业操作系统的新产品。
十一、这会怎样改变 SaaS 的产品形态？
从技术判断,走到产业判断。
传统的 SaaS 生意是这样的:一家公司,做一个尽可能完整的应用,然后往里塞尽可能多的功能,做成一个大而全的封闭产品卖给你。
而在 Runtime 架构下,SaaS 产品可能会从一套完整产品,变成一套可组合的业务能力。
举个例子,CRM 不一定非得是一个封闭的、边界清晰的产品。它可能会变成一组可以被组合的东西:
CRM 可能不再是「一个产品」，而是一组可组合的能力： 客户对象（Customer Object） 机会对象（Opportunity Object） 销售动作（Sales Actions） 销售流程（Sales Workflow） 销售权限（Sales Permissions） 销售 Agent（Sales Agent） ——然后组合进一个更大的 Enterprise Runtime。 |
这是一个值得关注的趋势判断:当业务能力可以在一个共同的 Runtime 上自由组合,买一整套封闭 SaaS的必要性就会下降,而按需组合业务能力会变得更可行。SaaS 的边界,可能会变得比今天模糊。
十二、程序员的工作是否也会随之改变？
过去,程序员大量的时间,花在了这些事上:写胶水代码、写增删改查、包 API、写一遍又一遍的权限样板代码、做系统集成、写重复的服务代码。这些活,占了日常工作的很大一块。
而在 Runtime 架构下,这些通用的、重复的活,大量被 Runtime 接管了。程序员的价值,会更多地集中到这些地方:
· Business Model（业务模型设计） · Domain Design（领域设计） · Runtime Architecture（运行时架构） · Security Boundary（安全边界设计） · Policy（策略设计） · Agent Capability（Agent 能力设计） · Plugin Architecture（插件架构设计） |
一句话总结:程序员正在从实现每一个功能,逐渐转向设计软件运行的规则。写实现的比重下降,设计结构的比重上升。
十三、这套架构，还面临哪些问题？
1 Runtime 自己会不会变成新的巨石？
如果所有能力都往 Runtime 下沉,那 Runtime 本身可能膨胀成一个新的庞然大物——你只是把应用的臃肿,换成了Runtime 的臃肿。怎么让 Runtime 在承载足够多能力的同时,自己不失控,是个问题。
2 插件的边界，真的那么好设计吗？
插件一多,经典的工程难题就来了:插件之间的依赖爆炸、生命周期的复杂度、版本兼容性。可组合听起来很美,但组合的复杂度本身,是要付出管理成本的。
3 元数据，真的足够表达复杂的企业逻辑吗？
很多企业逻辑极其复杂、极其特殊。用结构化的元数据去表达大部分场景没问题,但总有一些极端场景,元数据表达不了、或者表达起来比写代码还别扭。到那时,仍然需要回落到代码。元数据不是万能的。
4 Agent 真的能可靠地用好这些能力吗？
Runtime 把能力暴露给 Agent 了,不等于 Agent 就能用对。可调用和调用正确之间,还有很长的距离——Agent 依然可能误解语义、调错动作。能力就绪,不代表智能就位。
5 Runtime 的治理本身，会不会成为新瓶颈？
当 Agent 越来越多,它们的策略、审计、身份、审批也会越来越复杂。这套治理体系本身,可能变成一个新的复杂度中心、甚至新的性能瓶颈。治理是必要的,但治理不是免费的。
正是这些还没有被完全解决的问题,让企业软件操作系统目前仍然是一个值得探索的方向,而不是一个已经成立的结论。看见这些难题,才不至于把趋势判断,误当成既成事实。
十四、ObjectStack 真正有趣的地方是什么？
绕了一大圈,回到 ObjectStack。
它值得观察的地方,是它正在把几个过去分开的概念,放进同一个 Runtime 里:元数据（Metadata）、ObjectQL、ObjectUI、插件（Plugins）、安全（Security）、自动化（Automation）、MCP——这些东西过去分属不同的工具、不同的层,而它试图把它们收进同一套架构。
所以它不是一个简单的 Framework,也不是一个低代码工具,而是在探索一种Business Runtime架构。它是一个值得研究的开源案例,而不是一个已经完成的答案。
结论：从 Application 到 Runtime
把全文压缩成一张图,这个转变就清楚了:
过去： Framework → Application → Database / API / UI 正在发生的变化： Kernel → Plugins → Runtime → Business Metadata → Application ↕ AI Agents |
最终的判断是这样一句话:
AI-Native 企业软件最大的变化，不是应用里多了一个 AI 按钮，而是应用本身正在变薄，Runtime 正在变厚。
在传统企业软件里,Application 是主角,Runtime 是后台。而在 AI-Native 企业软件里,Runtime 开始成为业务、数据、人和 Agent 之间共同的基础设施——它从幕后,走到了中央。
如果说上一代 SaaS 解决的是软件如何服务人,那么下一代企业软件要解决的,可能是——一个 Runtime,如何同时服务人、程序和 AI Agent。
过去,我们在构建 Application;下一阶段,我们可能会开始构建 Business Runtime。ObjectStack 不是未来企业软件操作系统已经完成的证明,它更适合被当作一个值得研究的开源案例——它正在尝试,把 Kernel、Plugin、Metadata、Business Runtime、MCP 和企业应用,组合到同一个架构里。而这篇文章想说清楚的,只是:为什么这个方向,值得你关注。
——本文以 ObjectStack 开源项目为案例进行技术分析。涉及仓库能力的部分,以其当前公开源码和文档为准;关于行业趋势与未来软件形态的判断,属于作者观点,非既成事实。
ObjectStack · 开源的 AI-Native 企业软件运行时