【承接上篇】

上篇我们论证了：传统 SaaS 根植于表驱动 CRUD 范式，形成范式级结构性负债。不管局部重构，还是外层封装原子 API，都无法真正支撑 Agent 自主编排，还会持续拖累产品、销售、交付整条业务链。

既然存量系统很难平滑改造，出路不是在旧地基上修修补补，而是新建一套基座。这套基座的核心定位，不是升级版低代码，也不是传统元数据平台，而是元模型驱动的领域运行时。

基座由三驾马车构成：元模型中心、多维鉴权模型、流程规则引擎。三者协同，是上层 Agent、AI 编排的可靠底层。

【本篇核心观点】

传统平台是 “表优先、代码优先”；这套 AI 原生基座是元模型优先。

元模型是一等公民：它不是一份被代码消费的配置，而是整套系统的唯一事实来源。库表、页面、接口、检索、权限、规则，全部由它派生，且只能由它派生。业务分支、动态策略，交给上层规则引擎和 AI 编排层。

（注：这套基座和市面某些 "长得像" 的平台有本质区别，后面第 4 篇专门澄清，本篇聚焦三驾马车本身。）

一、元模型中心：从 "元数据" 到 "元模型" 的跃迁

1. 元数据 ≠ 元模型

绝大多数人（包括很多做中台的团队）理解的元数据，就是一张表结构描述：字段名、数据类型、长度、是否必填。这只是一张 "数据字典"。

元数据回答的是：数据长什么样。

但一个业务实体，只有数据结构是不够的。同一个字段，它同时还在回答另外几个问题：

• 它怎么呈现？（这个字段在界面上是输入框、下拉框，还是日期选择器？）

• 它有什么行为？（选中这个选项，会不会联动显示另一个字段？）

• 它怎么被检索？（用户搜 "张三"，到底是精确匹配还是模糊搜编码 + 名称？）

• 它怎么存储？（这个关系是存在本表，还是中间表？要不要建索引？）

这些，元数据统统回答不了。元数据只描述"是什么"，不描述 "怎么用"。

2. 业务特征 → 技术特征的完整映射

元模型和元数据的本质区别在于：

元模型不是对数据结构的静态描述，而是把每一个业务特征，显式映射为一整套技术特征。它回答的是 "这个业务实体，在存储层、呈现层、交互层、检索层、行为层，各自应该被如何对待"。

用一个例子说明。同样是 "证照类型" 这个字段：

同一个业务特征，会同时映射出存储、呈现、交互、检索、语义五个技术侧的处理方式。这才是 "元模型"—— 它把业务世界的完整性，翻译成了技术世界的完整实现方案。

3. 能力本质：把 "业务定义" 翻译成 "技术实现"

所以元模型中心的职能，远不止 "定义数据结构"。它做的是一次性的、完整的技术翻译：

五层不是五份独立配置，而是同一个业务定义，在五个技术切面上的投影。元模型中心的价值，就是把这五个投影一次性定义、自动落地，并且让它们永远保持一致。

4. 映射必须是 "自动的、不可分的"

传统系统的做法是：业务定义一份（需求文档）、数据库一份（表结构）、页面一份（前端代码）、接口一份（后端代码）、权限一份（权限配置）。五份东西各写各的，靠人来对齐，这就是结构性负债的根源之一。

元模型中心的革命性在于：五层映射由元模型中心一次性生成，彼此之间不存在 "对不上" 的可能。

• 元模型说这个字段是枚举 → 数据库自动存枚举、页面自动出下拉框、检索自动走精确匹配

• 元模型说这个实体关联供应商 → 数据库自动建外键、页面自动出关联选择器、反向自动带出列表

定义一处，全栈生效，永远一致。这才是 "元模型是一等公民" 的真正含义 —— 它不是一份被代码消费的配置，而是整套系统的唯一事实来源（Single Source of Truth），页面、接口、存储、检索、Agent 工具，全部由它派生，且只能由它派生。

5. 元模型是 Agent 的 "世界说明书"

正因为元模型承载了完整的技术映射，Agent 拿到的才不是一堆散落接口，而是一份它真正能读懂的 "世界说明书"：

• 它知道 "证照类型" 是个枚举 → 知道该给用户哪些选项，不会自己瞎编

• 它知道选了食品证要带出经营项目 → 知道填表时要引导用户补充这个字段

• 它知道证照挂了供应商 → 知道查供应商能带出证照，做跨实体编排

• 它知道状态机的流转规则 → 知道什么操作在什么状态下合法，不越权、不乱来

一句话：如果元模型只是元数据，Agent 看到的就是一张张死表；只有元模型承载了完整的技术映射，Agent 看到的才是一个可以被理解、被编排的业务世界。

二、深度绑定元模型的多维鉴权中心

1. 基本概念：账号、行为、数据

鉴权回答的问题很朴素：哪个账号，能对哪些数据，做什么行为。三者齐备才构成一次完整判断。结合合同场景，立清四个概念：

1. 账号：唯一的权限主体。权限永远落在具体账号上，不是授给 "采购员"" 经理 " 这类身份。角色、岗位、组织都只是账号的属性或容器，鉴权判定的对象始终是当前登录账号。主体唯一，模型才收敛。

2. 行为：系统能执行的动作。查看、编辑、导出、作废合同，都是行为。行为由业务系统实现，权限系统只判 "能不能做"，不管 "怎么做"。且行为在实现时就已确定操作对象 ——"编辑合同" 天生只作用于合同。

3. 数据：被作用的资源，但本身不是权限。资源可以是实体（合同）、一条记录（合同 123）或某个字段（金额）。数据单独摆在那不构成权限，行为落到数据上才产生权限——"能编辑合同 123" 才是一条权限。

4. 角色：批量装权限的容器。账号经角色间接获得权限，一个账号可挂多个角色，结果取并集。角色解决批量授权问题，本身不是主体。

工程落地拆成两个维度，不做行为 × 数据大矩阵。因为行为已内置操作对象，无需再组合一遍数据：

• 功能权限：能干哪些行为（勾行为清单：能否查看、编辑、导出）；

• 数据权限：能触及多大范围，分行范围（本人 / 本组 / 下属 / 全部）和字段范围（可见、脱敏）。

运行时两道叠加：先判有没有行为资格，再判这条记录、这个字段在不在可达范围内。

2. 场景拆解：运行时判定与权限盘点

以一个普遍存在的业务场景来作为案例，大型企业中，对于合同权限的划分：

1. 不同采购组只能看到自己组里的合同；

2. 普通采购人员，只能编辑自己创建的合同；

3. 采购经理，可以编辑自己属下的合同；

4. 采购部长，可以看到、编辑全部的合同。

2.1 权限盘点：正向看角色、反向看数据

正向（角色有什么）—— 功能权限三者相同，差异全在数据权限：

反向（一份合同谁够得着）—— 以组员小李建的合同 123 为例：小李可见可改；同组采购员可见不可改；其经理可见可改；部长可见可改；其他组完全不可见。账号经角色继承规则，系统拿合同属性（所属组、创建人）与账号上下文（我的组、我的下属）比对得出。

两个现实规则：一人多角色范围取并集（取宽松不取交集）；复杂范围用多条规则AND/OR 组合（如 "华东大区且是我下属"）。

2.2 运行时判定：每次操作当场放行或拦截

盘点看的是静态关系，真正最高频的是每一次操作的实时判定，落在四个具体表现上：

1. 列表过滤：张三打开合同列表，后台只查出他有权的行，无权数据压根不返回；

2. 按钮按行置灰：同组别人建的合同，他能看到但编辑按钮置灰；

3. 字段实时脱敏：合同金额、银行账号按字段权限打码或隐藏；

4. 越权请求拦截：即使绕过页面直接调接口，后端对单条记录再判一次，无权即拒。

范围差异只用到几种标准原语 —— 本人创建、下属创建、本组、全部，没有为任何人写特殊逻辑。

2.3 权限之外还有两件事

权限不是配完即止：

1. 生命周期运营—— 入职开通、转岗调整、离职回收、请假代办与临时授权；

2. 审计合规—— 操作留痕、权限定期复核、职责分离冲突检查（录入人与审批人不能同一人）。

3. 多维鉴权中心与传统鉴权的区别

同一套权限需求，老系统也能做，但做法和代价完全不同。区别不在 "能不能按元模型勾选授权"，而在权限逻辑到底放在哪、怎么生效。

3.1 传统做法：权限写死在业务代码里

合同列表的底层，大致是这样一段散落的硬编码：

• 权限管到菜单和按钮编码为止，"能不能看到页面" 管了，"能看哪些数据" 管不了；

• 数据范围靠 Service、Mapper 里的角色 if-else：采购员拼创建人=我、经理递归查组织树再拼创建人 IN(下属)、部长不加条件作为特判；

• 同一套规则，前端按钮显隐写一遍、列表查询写一遍、编辑更新接口再写一遍；

• 经理看下属要实时递归组织、拼一长串 ID。

由此带来四个结构性毛病：

1. 规则散落，漏写一处就是越权口子；

2. 组织一变就得改代码发版（加个 "大区副总" 要翻遍所有 SQL）；

3. 规则全埋在代码里，没人能一句话说清张三到底能看哪些合同；

4. 对 Agent 完全是黑盒，它只能试探接口、越权风险高。

3.2 新做法：权限是声明式元数据，由中立引擎强制判定

3.3 新老范式差异

传统鉴权是 "命令式" 的：把 "先查角色、再递归组织、再拼条件过滤" 这套过程写死在业务代码里，权限是代码的一部分；

多维鉴权是 "声明式" 的：业务侧只表达 "采购员只够得到本人创建的合同" 这条规则，至于怎么查、怎么拦，交给一个与业务无关的中立引擎统一强制执行。

即：一个靠静态编码，一个靠动态规则；前者改权限就是改代码，后者改权限只是改配置。

4. 与元模型中心如何协同

4.1 中立定位：自存三类数据，资源和行为靠接入

鉴权中心是一套中立的授权基础设施，不绑定任何一类业务系统。它自己只存三类东西：

• 授权规则：角色上挂的行为 / 资源引用、数据范围谓词、字段范围（配置态）；

• 授权结果：每次判定的放行 / 拒绝结论及约束谓词，供执行点即时消费（运行态）；

• 鉴权日志：每次鉴权的完整事实，只追加、不可篡改，面向审计追溯。

资源和行为则由外部业务系统按统一接入契约提供，提供方可插拔：元模型中心是其中语义最完整的一个，老式与特例系统经适配层同样能接入。鉴权中心对所有来源一视同仁，只负责决策与留痕。

4.2 与元模型协同：实时引用，互不存副本

在新基座内，实体、字段、关联以及实体上的所有行为，都由元模型中心唯一定义和持有。授权规则里只保留资源、行为的引用标识，运行时实时查元模型完成解析，不做同步、不存副本，源头唯一、没有一致性问题。

组织也是这条线上的普通元模型 —— 人员、部门两个实体靠自关联构成汇报线和部门树；账号与人员实体一一绑定，每次判定先由账号定位到具体人员，再进入组织关系。

4.3 数据权限：顺着关系 "摸得到"，就有权限

每份合同挂着两个信息 ——谁建的、属于哪个采购组；每个人也挂着 ——我在哪个组、上级是谁。数据权限就是看从 "我" 出发，顺着这些关系能不能摸到那份合同。

以小李建的合同 123为例：

• 小李本人：是我建的，能看能改；

• 同组小张：同组摸得到，能看；但不是他建的，不能改；

• 经理老王：小李是他下属，能看能改；

• 部长：不限关系，全部能看能改；

• 其他组的人：摸不到，根本看不见。

系统不存 "哪份合同给谁" 的死清单，也不在SQL直接写死判定条件，而是只存一条判断规矩，比如 "经理能修改下属建的合同"。运行时：

• 看列表 → 规矩变成查询条件，只查出摸得到的合同；

• 改单条 → 拿这份合同套规矩，是下属建的就放行，否则拦截。

人调岗、换部门，只改人和组织之间的连线，规矩一个字不动，结果自动跟着变。

4.4 每个内置行为都硬性焊上鉴权切口

元模型运行时的所有行为 —— 增删改查、导入导出、关联选择 —— 数据访问全部收口到唯一流水线，强制经过鉴权，没有任何旁路。鉴权中心输出 "允许＋谓词"，运行时分三类落地：

• 读：谓词并入查询条件，源头只返回有权的行；

• 写：对目标实例做成员判定，在范围内才放行；

• 字段：无权字段不查询或返回时脱敏。

多角色规则按并集、AND/OR 确定性合并。物理上即便按领域分库分表，谓词也在逻辑计划层融合、再下推各分片执行，业务侧无感。每次判定的账号、资源、行为、命中规则与结论，异步写入鉴权日志，全程留痕、可追溯、可审计，且不阻塞主判定链路。

老式系统经适配层接入时：功能权限靠网关或 SDK 统一拦截即可生效；行、字段等细粒度数据权限，则由适配器把谓词翻译成它自家的 SQL 落地，能做多深受限于其自身改造程度。

4.5 边界

元模型不管权限；审批流归流程规则引擎，鉴权只判定当前账号是不是该节点的合法操作人。

5. 面客的具体形态

场景一：管理员配一个新角色要新增 "大区副总"，管理员勾选能做的行为（查看、编辑合同），数据范围下拉选 "本部门及下级"，再把金额字段设为可见。保存即生效，全程几分钟、不发版。也可以直接口述要求，AI 翻译成规则、回译成中文给他核对，确认后才生效。

场景二：采购员小张打开合同列表他眼里只有本组合同，别组的压根不出现 —— 这是后台把权限规则变成查询条件、直接过滤的结果；点开列表，别人建的合同 "编辑" 按钮是灰的，自己建的才可点；合同金额一栏对他显示****，部长登录则是明文。他若尝试绕过页面直接调接口，后端再判一次，照样拦下。

场景三：经理老王编辑下属的合同老王点编辑，系统当场拿这份合同套规矩：创建人是不是老王的下属？是，放行保存；不是，直接拒绝。整个判定由确定性引擎瞬间完成并留痕，不经过 AI、也不生成代码。

场景四：AI助手代为操作员工让 Agent"帮我导出本组待到期合同"。Agent 手上只有它被授权的工具 —— 无权工具根本不会下发给它；调用导出时，数据仍按这个账号的范围过滤，Agent 摸不到范围外的数据，没有任何可绕过鉴权的后门。

四个场景概括起来就是一句话：配置以AI提效，运行判定永远由确定性引擎把关。

三、流程规则引擎，负责元模型之间的流通与行为约束

元模型定义 "名词"，鉴权判 "能不能做"，流程规则引擎管的则是"固定动词"—— 实体按什么确定性路径流转、在什么条件下触发什么动作。它和 Agent 的分工很清楚：可固化、要留痕、要求结果每次一致的过程收进引擎；目标模糊、需要临场应变的开放决策留给上层 Agent。

1. 行为是流程唯一的起点，流程从不凭空产生

流程不是悬空画出的一张图，它一定由业务系统（元模型运行时）里的某个具体行为触发，比如 "提交合同"。行为发生后，引擎回答三个问题：要不要走流程（未绑定就直接生效）、怎么走（路由到哪条路径、几级审批）、每一步干什么（谁参与、校验什么、触发什么动作）。

它与鉴权构成对称的两道闸门：行为先过鉴权，判 "能不能做"，无权直接拦下；再过流程引擎，判 "做完怎么流转"。业务系统因此极薄 —— 不写权限判断、不写流程分支，只声明 "发生了一个行为"。引擎自身不持有业务数据，流程推进的结果是驱动元模型实体的状态机迁移（草稿→审批中→生效→归档）。

2. 根本差异：节点人机双模，能基于行为做编排和定制

传统流程引擎的节点只做三件事：找人、发通知、等人审批，本质是人工任务流转，这套成熟能力直接沿用。真正的增量在于，节点还可以是一个机器自动执行的规则槽：规则不自己实现能力，而是编排业务系统注册好的标准原子服务来完成动作。于是同一类行为节点有两种形态：

• 人工节点：解析参与者、发待办、等人会签或审批 —— 如合同的经理→部长逐级审批；

• 自动节点：不等任何人，机器按规则直接执行 —— 某租户要求合同作废时同步三方系统，主干一行不改，只需在 "作废" 行为节点挂一条租户规则，调用 "发 Webhook 通知" 原子服务即可。

3. 定制从散落的代码补丁，变成中心统管的规则资产

这是对前文 "结构性负债" 最直接的回应。传统私有化项目里，一个定制需求就要改核心代码、塞if(租户)分支、整包发版回归，定制不断吞噬共性。新范式下主干保持标准，所有差异化被外置到规则层、挂在明确的行为上，按租户隔离、带版本、可灰度、可测试、可审计。那 15% 的策略定制场景由此在平台层闭环，而不是一次次堆几百人天。

红线同样清晰：规则只能编排已注册的原子服务，不能直连底层表、不能绕过鉴权和状态机；5% 高吞吐、强实时的硬核场景仍独立定制，不把引擎当成什么都装的垃圾桶。

4. 对 AI：补上最后一份 "说明书"

三驾马车到此恰好构成 Agent 能读懂的三份说明：元模型是 "世界说明书"（有哪些实体和原子能力），鉴权是 "边界说明书"（能做什么、范围多大），流程规则引擎是 "行为与定制说明书"（事情怎么流转、每个客户的差异挂在哪）。

它们都是声明式、集中、带语义的资产，而不是埋在代码里的隐性分支。Agent 据此能读懂客户现状、在边界内安全调用原子能力去自主编排，而不是面对一个被私下改得面目全非、却读不出差异的黑盒。同时它只能调用引擎暴露的动作、不能绕过引擎直接改状态 —— 合规流程的确定性，始终握在引擎而非模型手里。

四、基座与 AI 编排层的边界划分

很多架构容易在这里越界，把所有事情丢给 Agent，造成慢、不可控。 ✅ 基座（三驾马车）承担：

• 标准化实体定义、存储、基础查询；
• 行级 / 字段级鉴权；
• 确定性流转、固定校验规则；
• 稳定、可复用、语义明确的原子能力。

✅ AI/Agent 编排层承担：

• 动态路径选择、多步骤任务规划；
• 模糊需求拆解、多工具组合；
• 客户个性化策略组装；
• 不确定、多变、一次性的业务分支。

❌ 红线：基座内部不埋大量场景化分支；Agent 不直接操作底层数据表、不绕过鉴权与规则引擎。

五、基座的适用边界：不是替代所有系统

这套元模型基座，主攻 80% 同质化管理类场景； 剩下两类场景分开处理：

1. 15% 定制化策略场景：基于基座原子能力做策略扩展；
2. 5% 高吞吐、低延迟、强实时场景：独立深度定制开发，单独演进，不走元模型运行时。

这也是我们前面说的 80/15/5 分层模型。

六、总结与下篇预告

三驾马车组合起来，形成元模型驱动的领域运行时：元模型定义世界，鉴权控制访问，规则驱动流转。它不是一个新的低代码工具，而是 AI 友好的业务基座。 基座产出语义统一、契约稳定、约束显性化的原子能力，给上层 Agent 提供可靠的编排原料；如果没有这套基座，Agent 只能去对接一堆隐性逻辑散落的老 API，本质还是套壳 AI。