执行路径过长
应用逻辑、服务框架、网络协议和数据库之间频繁往返，导致一次业务操作被拆分成多次跨进程、跨网络调用。
AI 编写 · 机器验证 · 数据库原生执行
MuduDB
让应用进入数据库运行时
让 AI 智能体安全访问数据库
面向数据密集型应用的统一执行与数据管理平台，将事务处理、应用逻辑、状态访问与部署分发整合到同一个数据库运行时中。
AI Agent 生成的业务动作先进入 CQL 形式化语义层，被符号化为可检查的规约，经编译器与模型检查器在执行前机器判定，再由 WASM 受控运行时与数据库内核共同把关，通过才执行——让每一次数据访问可验证、可拒绝、可回放。
MuduDB
让应用进入数据库运行时
让 AI 智能体安全访问数据库
§
提示词
{ }
CQL 规约
Σ
模型检验
λ
编译算子
[#]
数据库
传统痛点
传统数据密集型应用正在被系统边界拖慢
在传统架构中，业务逻辑运行在数据库之外。一次业务操作往往需要穿越应用服务、网络协议、数据库驱动、连接池、SQL 执行器和事务管理器等多个边界。
事务与业务割裂
事务语义留在数据库内部，业务过程留在应用服务内部，开发者需要在两个世界之间手动维护一致性。
部署与运维复杂
应用、数据库、依赖、脚本和配置分别部署，系统越大，集成成本越高。
AI Agent 痛点
AI Agent 的「最后一公里」，卡在没有执行前验证
企业不敢让智能体碰生产数据库，原因不是模型不够强，而是缺少一条可验证、可拒绝、可回放的写库路径。
智能体写库无安全保障
prompt 里写「不许乱来」、每笔操作人工审批、只给只读副本，都是"可能有效"的补丁——要么不安全，要么没价值。
真实价值都在"写"
退款、改价、扣库存、改订单——智能体能力的"最后一公里"是写操作，但没有任何机制能在执行前判定 LLM 生成的 SQL / 代码是否安全。
错了就是事故
AI 不为安全与质量负责，一次错误写入就是一次真实损失；「让智能体动生产库」已成为企业 AI 落地被普遍搁置的头号原因。
MuduDB 方案
MuduDB 将应用过程带入数据库运行时
开发者可以使用熟悉的编程语言编写数据密集型业务过程，并将其编译、打包、部署到数据库内部执行。数据库不再只是被远程调用的数据后端，而是统一承载数据管理、事务处理、应用执行和部署分发的平台。
快速开始
几分钟内将应用部署到数据库内部
将数据模式、过程和资源打包，然后直接部署到 MuduDB 运行时中，无需单独的应用服务器。
1
$ mpm-install your-application.mpk
CQL 语义验证
AI 编写 — 机器验证 — 数据库原生执行
CQL（Churcuring Query Language）是 MuduDB 的语义层，为「机器生成 + 机器验证」重新设计：AI 智能体生成的业务动作先被符号化为可检查的规约，由编译器与模型检查器在执行前机器判定，通过才放行。
AI → SQL → 人工审核 / 直接执行：约束违反只能在事后对账发现
↓
AI → CQL → 验证 → 执行：执行前机器判定，通过才放行
提示词 → CQL 规约 → 模型检验 → 编译算子 → 数据库
Churcuring Query Language
§
提示词
自然语言意图，LLM 生成质量高，人无需学习新语言
{ }
CQL 规约
表、动作、查询、不变式与时态属性的强类型规约
Σ
模型检验
不变式在全部可达状态上验证，反例可重放
λ
编译算子
WASM 受控执行单元，沙箱隔离、靠近数据运行
[#]
数据库
违规代码在链路最左端即被屏蔽，内核只承接通过验证的可信执行
编译即审查
类型错误、效应越权、意外发散在编译期全部拦截，不进入执行环境。
效应三层隔离
纯函数 / 只读查询 / 写事务分层且只能向上组合；无 JOIN，一切关联都是显式 key lookup。
完全确定性
同一快照 + 同一参数 ⇒ 相同结果——这是形式化验证在工程上可跑的前提。
检查的行为 = 运行的行为
checker 与内核共享同一份约束规则与求值语义，验证通过即运行可信。
系统架构
语义层 · 运行时 · 内核：三层一体架构
MuduDB 采用语义层、运行时、内核三层一体架构。最上层的 CQL 形式化语义层承接 AI 智能体生成的业务动作，完成类型检查、效应检查与模型检验；通过验证的逻辑编译为 WASM 应用包，由运行时承载并通过轻量系统调用接口访问内核能力；内核提供存储、事务、查询和调度等基础能力。
CQL 形式化语义层
类型检查效应分层模型检验不变式与时态属性
Mudu 应用包
WASM 字节码数据模式过程资源
MuduDB 运行时
WASM 宿主过程引擎系统调用层
MuduDB 内核
事务查询KV存储调度器
本地 / 云 / 边缘节点
部署分发执行局部性
视频概览
核心能力
面向数据库原生应用的核心能力
CQL 形式化语义层
以表、动作、查询、不变式与时态属性描述业务，把 AI 智能体的输出转为强类型、效应分层、可检查的规约。
执行前模型检验
编译即审查：模型检查器在全部可达状态上验证不变式，违规代码在部署前被拦截，反例可一键重放为回归测试。
应用逻辑入库执行
将数据密集型业务过程部署到数据库运行时，减少跨进程、跨网络、跨服务边界的调用开销。
WASM 可移植运行时
基于 WebAssembly 的运行时模型，支持跨平台、跨语言的应用过程执行。
统一系统调用接口
通过轻量、稳定的系统调用接口访问数据库内核能力，降低传统驱动和连接对象带来的复杂性。
事务与业务过程协同
让事务处理、状态访问和业务逻辑在同一个执行路径中协同完成，减少应用层一致性维护成本。
数据局部性执行
利用分区和数据局部性，将计算移动到数据附近，适合低延迟、高并发的数据服务场景。
应用包分发
将数据模式、过程、依赖和初始化脚本打包，使数据库应用可以像软件包一样安装、部署和升级。
应用场景
MuduDB 适合的工作负载
企业事务处理
订单、库存、账户、审批、结算等业务过程可以靠近事务状态执行。
云平台服务
适合构建多租户、高并发、低延迟的数据服务平台，统一托管数据访问和业务过程。
智能数据应用
为 AI 生成应用和数据密集型应用提供统一的执行、状态和部署底座。
大型多人在线游戏
适合高频状态更新、事务性操作和局部数据访问密集的在线游戏后端。
路线图
从内核原型到应用市场
阶段 1
内核原型
阶段 2
WASM 过程运行时
阶段 3
打包与部署
阶段 4
分布式 / 本地优先执行
阶段 5
应用市场