主题页
可执行的业务本体
可执行的业务本体 的核心不是再做一个演示页面，而是一份可执行的业务本体：对象与字段、关系、动作、权限、流程，以及 Agent 与工具定义。视图、仪表盘、应用和翻译是它的投影，不是产品本身。
可执行的业务本体 把客户、工单、订单、设备、合同和审批等业务记录写进同一份本体：对象、权限、动作和流程声明在一起，运行时从中派生数据库、API、界面和 MCP 工具，并在每一次调用上执行权限与审计。ObjectOS 让 AI 使用明确的工具和权限边界，而不是直接绕过系统访问数据。
为什么现在重要
- 可执行的业务本体 让企业 AI 面向真实业务记录，而不是一次性的导出文件。
- 应用生成之后还需要权限、审计、审批和持续演进能力。
- 企业需要在不替换核心系统的前提下，把 AI 放进实际流程。
平台需要具备什么
- 把客户、订单、案件、设备、合同和审批建模成业务对象。
- 从同一份业务规格生成页面、流程、API 和 Agent 工具。
- 让用户和 AI Agent 在同一套权限、审批和审计边界内执行动作。
- 把已在运行的 CRM、ERP 数据库联邦接入——默认只读、尚在早期——而不是强制迁移。
典型场景
围绕维修、服务、审批或内部运营需求生成可运行应用。
给 CRM、ERP、工单和制造系统增加 AI 查询、总结和异常分析能力。
让 Agent 通过受控工具操作业务对象，而不是拿管理员权限直连数据库。
阅读路径
相关文章
「本体即软件」到底是什么意思？可执行业务本体的完整定义
这句话是 ObjectStack 的定位，这篇是它的定义：可执行业务本体由六类核心构成，有四种投影、三个「不是」，还有一条分辨核心与投影的测试。
从需求到可审查应用：AI 如何生成 ObjectStack 元数据
用设备报修场景拆开 AI Builder 的生成过程：对象、字段、关系、视图、权限、动作、流程、API 和 agent 工具如何由同一份元数据驱动。
低代码 vs AI 原生应用平台：复杂业务卡在哪里
低代码解决的是更快搭页面和流程；复杂业务真正卡住的是对象、权限、集成、变更和可维护性。AI 原生平台要把这些变成可审查的运行时元数据。
给现有系统加 AI：连接数据库，而不是先迁移
在自管部署的 ObjectOS（企业版）里，把已经运行的数据库接入（默认只读），让 agent 把关键数据表建模为对象，再在你的权限边界内叠加 AI 能力；原系统继续运行，AI 走受控对象层。
自托管 AI 应用平台：为什么运行时属于你
当 AI 开始读取业务数据、触发流程、生成应用和调用工具，企业真正要控制的不只是模型，而是承载对象、权限、工具、审批和审计的运行时。
AI Agent 数据安全边界：如何在企业权限内工作
企业不是不想让 AI agent 使用业务数据，而是不允许它绕过身份、权限、审批和审计。真正可上线的 agent，必须像一个受控用户，而不是影子管理员。
继续浏览这个主题
常见问题
可执行的业务本体 解决什么问题？
它解决的是 AI 如何理解并安全操作企业业务系统的问题：对象、权限、流程、API、审批和审计都必须被显式建模。
这和低代码有什么不同？
低代码平台是最近的亲戚：那里同样由元数据生成表、API 和界面。区别在定义放在哪里、写给谁看。低代码把元数据当作配置存在厂商的数据库里、由人在界面上点出来；ObjectStack 把它写成你仓库里类型化、声明式的 TypeScript——进版本库、按 diff 审阅、运行前经 os validate 校验，并且是为 AI 来写而设计的。
是否需要先替换现有系统？
通常不需要。更稳妥的路径是先把现有数据库作为只读数据源接入——联邦默认只读、尚在早期，写权限按对象有意开启——把关键记录建模为业务对象，再逐步叠加 AI、流程和新应用。