本体平台总体架构02-底层引擎基于场景驱动的动态组合和编排

大家好，我是人月聊IT。今天继续本体平台架构设计的细化。即如何通过场景分析，动态编排上面谈到的能力引擎。让本体平台能够满足不同的场景需求。

一、为什么要按场景拆分和编排引擎

企业软件建设里常遇到两类麻烦。

第一类是"什么都堆在一起"。一个模块既要查数据、做权限校验、发消息，还要出报告，代码越写越臃肿，改一处牵连七八处，久了没人敢动。

第二类是"什么都想要齐了才开始"。业务提需求，技术先确认数据在哪、格式对不对、权限够不够、性能扛不扛得住，等理清业务方已不耐烦。

两类问题根源相同：能力堆在一起，却没按场景做合理拆分和组装。

本体平台先把平台拆成职责单一的引擎，比如需求引擎只把用户想法变成文档，本体模型引擎只管业务模型文件，数据连接引擎只管连库取数，边界清楚。但光拆开不够，真正的问题是不同场景下引擎要以不同顺序、不同组合协作——零件固定，组装方式取决于要造什么。

例如"做一个供应商管理模块"需要需求、本体、应用生成引擎串起来；"分析供应商付款逾期"需要本体、数据连接、数据分析、报表引擎协同，两者用到的引擎完全不同。若每次请求都启动全部引擎，既浪费资源，流程也跑不通。

平台要做到：按用户实际场景，自动判断需要哪些引擎、按什么顺序、哪些能并行、哪些必须串行。这就是"基于场景驱动的动态组合和编排"要解决的问题。下面先说平台要解决的问题，再依次讲模型规范、引擎清单、依赖关系、场景编排、内部机制和两个横切问题。

二、平台要解决的问题与定位

企业数字化到一定阶段，问题通常不再是缺系统，而是系统太多、语义不一致、数据难复用。业务人员说客户、合同、订单、回款，系统里存的是表、字段、接口、状态码；管理层看经营指标，BI 维护口径，IT 做集成。每一层都在翻译，翻译多了偏差就大。具体三件事长期没解决：

第一，需求和系统之间缺稳定中间层。业务提需求、分析写文档、架构师设计、开发写代码，每次交接都损失语义，几年后没人说得清某条规则来自哪条需求，也没人敢改字段改流程。

第二，业务系统和分析系统长期分离。同一"客户""订单"在不同系统里字段名、粒度、状态、时间口径可能都不一样。一个指标跨多系统取数，报表口径变了源头不知道，分析拿到数据也不懂字段含义。

第三，做分析时缺可控上下文。把宽表、查询结果或文档直接交给大模型，结果看着完整，实际可能混淆概念、误用口径、引用不存在的规则。

平台的核心思路是建一套统一的业务语义层：既能承接需求、指导建应用，又能连数据库和指标体系，为分析提供结构化业务上下文。平台不替代所有系统，而是建一套可复用的语义基础——新应用围绕它生成，老系统通过映射接入，分析基于它获得上下文，指标通过它追溯源头。

三、模型规范：用八类模型描述业务

平台前置基础有两个：需求探索方法和本体建模规范。需求探索把一句话需求变成完整需求，按结构化方式推进——先确认业务范围，再识别对象，接着梳理功能、规则、流程、角色、权限和报表；通用知识平台先补，企业特有规则必须用户确认。

本体建模规范把业务系统拆成八类相互引用但职责清楚的模型：

• M1 对象模型：核心对象、属性和关系。
• M2 行为模型：对象能执行的操作。
• M3 规则模型：校验、计算、推导、风控等可复用规则。
• ME 事件模型：状态变化触发哪些事件、谁订阅。
• M4 场景模型：端到端流程和用例编排。
• M5 主体模型：岗位、角色和权限边界。
• M6 异常补偿模型：失败、回滚、补偿策略。
• M7 质量约束模型：性能、可靠性、并发、安全等非功能要求。

这里要说明：上一版写"M1 到 M7"，漏了 ME 事件模型。事件引擎工作所需的事件定义和订阅关系正来自 ME，所以统一为"M1 到 M7 加 ME 共八类"，事件引擎加载 ME、规则引擎加载 M3。这套模型的价值是把文字需求变成可被程序读取执行的结构化模型，而非画图好看；后续扩展 UI 模型、对象到表映射、接口模型都在此基础上加。

四、统一引擎清单及职责

前两版引擎数量不一致：一版十个、一版十一个，且一版的"存储引擎""AI 分析推理引擎"在另一版消失，导致"可追溯"和"结果校验"无人负责。下面给出统一清单，共十三类，各写明输入、输出和关键依赖。

1. 需求引擎
   • 输入：用户一句话需求、邮件、会议记录或已有文档。
   • 输出：结构化需求文档（SRS）。
   • 职责：按模板把模糊说法拆成对象、属性、功能、流程、角色，主动提问补齐缺失信息。不依赖其他引擎，是起点但非唯一起点，有些场景可跳过。
2. 本体模型引擎
   • 输入：需求引擎的 SRS（正向），或数据连接引擎读到的库表元数据（逆向）。
   • 输出：M1 到 M7 加 ME 的模型文件，存入版本库。
   • 职责：生成维护模型，做一致性检查（行为引用的对象是否存在、事件订阅的行为是否存在等），建立按对象、行为、规则、事件、场景、角色检索的索引，变更时分析影响范围。
3. 应用生成引擎
   • 输入：本体模型文件。
   • 输出：可运行的应用代码、AI Agent 或 Skills 技能包。
   • 职责：按代码模板库把模型翻译成领域层、应用层、接口层、部署层代码。不生成 UI，前端对接低代码或前端框架，由 M1 属性列表自动生成表单配置。
4. 数据连接引擎
   • 输入：逻辑查询（对象、属性、过滤条件）及调用者身份。
   • 输出：结构化数据集，附来源、拉取时间、字段映射记录。
   • 职责：维护对象到表、字段到字段、枚举到编码的映射，把逻辑查询翻译成物理 SQL 或接口请求执行；负责类型转换、增量同步、缓存、脱敏，并在翻译阶段按 M5 主体模型和调用者身份注入行级过滤条件。
5. 数据分析引擎
   • 输入：本体模型引擎的语义信息，数据连接引擎的数据集。
   • 输出：结构化聚合计算结果。
   • 职责：先形成逻辑查询计划（目标对象、过滤、聚合维度），再交数据连接引擎翻成物理 SQL；只做数据加工，不做推理，不直接拼 SQL 绑定表结构。
6. 报表引擎
   • 输入：数据分析引擎或 AI 分析推理引擎的结果。
   • 输出：PDF、Excel、Word 或网页图表。
   • 职责：负责呈现，包括图表选择、排版、导出格式适配。
7. 规则引擎（运行时）
   • 输入：M3 规则定义，运行时事实数据。
   • 输出：布尔值或计算结果。
   • 职责：把事实与规则做匹配计算。它是被调用角色，不发起流程；数据分析做行过滤、事件引擎判触发时都会调它。
8. 事件引擎
   • 输入：其他引擎发布的事件（类型来自 ME 模型）。
   • 输出：把事件可靠传递给订阅方。
   • 职责：类似消息中间件，负责发布订阅，不处理业务逻辑；支持防抖、去重、最大跳数，避免事件回路无限循环。
9. AI 分析推理引擎
   • 输入：本体模型引擎的上下文、数据连接引擎的数据集、用户问题。
   • 输出：带依据的分析结论、风险判断、原因拆解、行动建议。
   • 职责：选取相关本体上下文，注入数据事实，组织提示词调大模型，返回后做校验——查数字是否来自数据集、字段是否存在、结论是否引用明确依据，无依据标"推测"不写事实。上一版拆掉后此职责无人承接，这里明确归口本引擎。
10. 存储引擎
    • 输入：平台运行产生的各类资产。
    • 输出：可查询、可比对、可追溯的资产库。
    • 职责：保存原始需求、需求文档、模型及版本、对象到表映射、数据快照、生成代码、分析报告和对话记录；支持查某应用版本用了哪个模型版本、某报告用了哪些数据源、某指标口径从何时变更。上一版删掉后"可追溯"无归属，这里恢复。
11. 场景编排引擎
    • 输入：用户场景目标或事件触发信号。
    • 输出：执行计划与执行结果。
    • 职责：做意图解析、任务拆解、计划生成和调度执行，不执行业务逻辑，只让每个引擎在正确时间、正确顺序被调用。
12. 本体能力网关
    • 输入：外部调用请求，或内部待暴露能力。
    • 输出：对外标准接口，或封装后的外部系统接口。
    • 职责：向南把平台能力以 MCP 或 REST 对外开放供外部 Agent 发现调用；向北把 ERP、物流等外部接口封装成内部标准接口；负责统一权限和调用边界，记录调用日志便于审计。
13. 大模型网关
    • 输入：各引擎的调用请求（含任务类型、提示词、参数）。
    • 输出：大模型返回结果。
    • 职责：按任务类型做模型路由（对话、代码、推理、摘要用不同模型），负责鉴权、成本记录、脱敏、缓存、重试和降级；做转发和路由，不做业务决策。

五、引擎间的依赖关系与调用规则

前面两版这里自相矛盾：一处写"执行引擎彼此无横向依赖，只接受编排引擎调用"，另一处又写"数据分析引擎过滤时调规则引擎、出结果后调事件引擎发布事件"。两者冲突，必须明确规则。我们把依赖和调用分四类：

第一，刚性依赖（必须有上游产出）：需求引擎→本体模型引擎（正向）；本体模型引擎→应用生成引擎；本体模型引擎→数据分析引擎（语义）；本体模型引擎→AI 分析推理引擎（上下文）；本体模型引擎→规则引擎（加载 M3）、本体模型引擎→事件引擎（加载 ME）；数据连接引擎→数据分析引擎（数据）；数据分析引擎→报表引擎。

第二，调度依赖（编排按需触发）：编排→数据分析、编排→报表、编排→事件、编排→规则、编排→应用生成、编排→AI 分析推理。

第三，阶段内直调（紧耦合引擎直接调用）：高频低延迟的内部步骤允许直调，明确登记两种——数据分析引擎→规则引擎（行过滤），数据分析引擎→事件引擎（发布结果事件）。这类直调也须在能力注册表登记并记录调用链，保证可观测。

第四，事件订阅（异步触发）：事件引擎把事件推给订阅方，订阅方可能是编排引擎、应用生成引擎或其他模块。

六条关键约束：

1. 需求引擎是少数无上游依赖的引擎之一（数据连接在逆向场景里作本体输入源）。
2. 本体模型引擎有两个独立输入：需求引擎 SRS 和库表元数据，互不依赖可单独用。
3. 数据分析引擎必须同时依赖本体模型引擎和数据连接引擎，缺语义不懂数据，缺连接拉不出数据。
4. 编排引擎是调度中心，负责阶段级编排；阶段内紧耦合直调单独登记，不属于"所有调用都经编排"，既不牺牲解耦也不牺牲性能。
5. 大模型网关是底层基座，被多引擎调用，不依赖业务引擎输出，也不做业务决策。
6. 单条执行计划内无环（有向无环图）；但事件总线层面允许长期回路（事件触发动作、动作回写再触发事件），故事件引擎须有防抖、去重、最大跳数限制。上一版"整个依赖图无环路"过于绝对，这里限定为"单条计划内无环"。

六、场景化组合：六个典型场景

前四个来自上一版，后两个补缺口。

场景一：从零构建新应用

用户："做一个供应商风险管理模块，管供应商信息、资质、评估记录。"

参与引擎：需求引擎→本体模型引擎→应用生成引擎→本体能力网关。

顺序：需求引擎确认属性、资质格式、评估触发方式、审批级数，产出 SRS；本体模型引擎读 SRS 生成八类模型；应用生成引擎按模板生成各层代码；经网关发布为 Web 包或 MCP Server。

编排方式：严格串行，每步依赖上一步，编排引擎依次触发。

场景二：存量系统逆向建模

用户："一套跑了五年的 ERP，两百张表，想基于这些表生成本体模型。"

参与引擎：数据连接引擎→本体模型引擎→大模型网关（辅助补全）。

顺序：数据连接引擎读表名、字段、类型、主外键；本体模型引擎推导聚合根草稿（订单主表对应"订单"聚合根，明细表对应子实体，外键对应关联）；因表结构常缺业务语义（字段名可能是 col_01），调大模型网关补全；草稿交人工确认后存入模型库。

编排方式：数据连接与本体串行，大模型网关辅助增强，不经需求引擎。

场景三：智能数据分析与归因

用户："分析去年第四季度华东区域销售下滑原因，写份报告。"

参与引擎：需求引擎+本体模型引擎+数据连接引擎→场景编排引擎→规则引擎→数据分析引擎→AI 分析推理引擎→报表引擎。

顺序：意图触发两个准备动作——需求引擎确认口径（"销售"指订单金额还是发货金额，"华东"含哪些省份），本体模型引擎加载"销售订单"语义，数据连接引擎拉取明细。注意：数据连接把逻辑查询翻成物理 SQL 依赖对象到表映射，映射源自本体模型，所以"数据连接并行拉数"仅在映射已注册时成立；首次建模后映射才可用，此时数据连接实际隐含依赖本体模型加载完成。准备完成汇总到编排引擎，拆成清洗、异常标记、多维分析、归因推理、报告生成五个子任务。编排引擎调规则引擎排除退货单、测试单等异常值；调数据分析引擎按区域、产品线、客户类型聚合找出下滑最明显维度；交 AI 分析推理引擎生成归因文本并校验；最后交报表引擎生成含文字图表的 PDF。

编排方式：映射已存在时准备阶段可并行，后续串行，每步依赖上一步，是典型工作方式。

场景四：事件驱动自动化响应

无主动请求，由事件触发。数据连接引擎定时扫描发现"某供应商累计逾期超 50 万"。

参与引擎：数据连接引擎→规则引擎→事件引擎→场景编排引擎→应用生成引擎→本体能力网关。

顺序：数据连接定时查询发现逾期超阈值；规则引擎判"逾期超 50 万且近 30 天无还款"是否成立，成立返触发信号；事件引擎发布"供应商高风险预警事件"；编排引擎订阅后启动风险处置，拉取该供应商全部合同和付款记录；调应用生成引擎动态生成"催收处理"临时 Skills（含发通知、建工单、升级审批）；技能包经网关下发执行并反馈。

编排方式：事件触发链式反应，事件驱动编排再组装其他能力；事件引擎靠防抖与最大跳数防回路扩散。

场景五：OLTP 与 OLAP 语义对齐和指标治理（补齐）

用户："把销售合同、回款、报表的指标口径统一管起来，业务系统改了能知道影响哪些报表。"

参与引擎：本体模型引擎+数据连接引擎→AI 分析推理引擎（影响分析）→存储引擎（血缘）→报表引擎。

顺序：本体模型引擎把业务对象、交易表、分析宽表、指标公式、报表字段统一登记到模型和映射；数据连接引擎提供各源系统实际字段和口径；业务系统变更（如删合同金额字段）或口径调整时，AI 分析推理引擎基于模型索引做影响分析，列出受影响的规则、报表、接口、分析场景；存储引擎记录口径从何时起变更、关联哪些对象和字段；报表引擎按最新口径出数。

编排方式：常驻治理流程，由模型变更事件触发影响分析，补齐上一版"OLTP/OLAP 语义对齐"无对应场景的问题，也让 AI 回答时不仅知字段值，还知字段来自哪个对象、怎么算、适用什么口径。

场景六：外部 Agent 经网关入站调用（补齐）

外部 Agent："查 A 客户本月逾期未回款合同，生成跟进建议。"

参与引擎：本体能力网关（入站）→场景编排引擎→本体模型引擎+数据连接引擎→规则引擎→AI 分析推理引擎→报表引擎。

顺序：外部 Agent 经 MCP 或 REST 调网关；网关做鉴权和边界检查后转编排引擎；编排按场景模板拆解，加载客户语义、拉回款数据、用规则引擎筛逾期、交 AI 分析推理引擎生成建议并校验、经报表引擎返回结构化结果给调用方。

编排方式：网关"向南暴露能力"的入站用法，与场景四"应用生成后经网关下发"互补，说明平台既能推能力出去，也能让外部 Agent 调进来。

此外，模型变更与影响分析可贯穿各场景：需求变更→改模型→AI 分析推理引擎做影响分析→应用生成引擎增量生成代码，不必每次推倒重来，支撑"系统可逐步演进"。

七、编排引擎的内部机制

意图解析器：把用户的话翻成结构化任务列表，背后调大模型网关做语义理解。如"分析销售下滑原因"解析为数据采集、异常过滤、维度聚合、归因推理、报告生成。

能力注册表：记录每个引擎的能力描述、输入输出格式、调用方式；编排查表判断任务由谁执行（"数据采集"对应数据连接引擎），阶段内直调也登记于此。

场景配方库：上一版缺失的一环。仅有能力注册表时，每请求都靠大模型从零推导计划，又慢又不稳定，也难以解释为何选这几个引擎。场景配方库把"销售下滑归因""合同履约分析"等沉淀为可复用模板，固定引擎序列和可变参数，大模型只做"意图匹配模板+填参数"，提升稳定性也利于积累经验。

计划生成器：根据任务、能力注册表、场景配方库生成执行计划，含顺序、并行策略、超时、重试；如"本体加载"与"数据拉取"无依赖可并行，但前提映射已存在。

执行器：按计划逐条执行并监控状态，任务失败触发补偿（重试、跳过或人工介入）。

状态管理器：记录执行状态和链路标识（traceId），便于追溯调试，也是存储引擎做全链路血缘的输入。

核心是方程动态生成不硬编码：新增场景不改引擎代码，只加场景配方；新增引擎只注册到能力表，现有场景即可复用。

八、两个横切问题：数据权限与可追溯

数据权限。M5 主体模型定义角色权限边界，但运行时"谁能看哪些数据行"必须有人执行。明确：数据连接引擎在逻辑查询翻物理 SQL 时，按 M5 主体模型和调用者身份注入行级过滤条件，权限在取数那一刻生效，而非等到分析或展示才补。网关负责"能力调用"层面权限，数据行级权限由数据连接引擎负责，分工清楚。

可追溯。上一版删存储引擎后追溯无归属，这里恢复其为资产与版本中心，保存模型版本、映射、快照、代码、报告，并记录每份报告来源：用了哪个本体版本、哪些数据源、哪次拉取、哪个提示词模板、哪个模型输出。结合编排状态管理器的 traceId，做到一次分析从入口到报表的完整血缘可查，避免平台自身成新黑盒。

九、落地边界与实施建议

平台不宜一开始做满十三类引擎，宜分阶段：

第一阶段做"本体建模到智能分析"最小闭环，核心含本体模型引擎、数据连接引擎、AI 分析推理引擎、存储引擎。选对象清楚、数据源可连、问题明确的场景（如合同履约或销售回款风险分析），验证带本体的分析是否比直接问数更可靠。

第二阶段补"需求到应用生成"闭环，加需求引擎和应用生成引擎，支持一句话需求到 SRS、到模型、到可运行应用；生成范围先控在单体应用、标准增删改查、主从表单、简单状态机、固定报表。

第三阶段建场景编排和开放能力，引入编排引擎、本体能力网关、大模型网关，支持跨系统事件、自动化流程、外部 Agent 调用、模型路由和成本管控。

第四阶段做治理和规模化，重点在模型版本、影响分析、指标血缘、权限体系、审计报表和团队协作。

落地边界：

第一，模型不能只停留在图文档，必须能被程序读取、校验、执行，否则支撑不了生成和分析。

第二，不让平台绕过业务确认。通用字段流程可补，审批规则、权限范围、金额口径、父子对象处理必须由业务确认；平台越自动越要留住关键确认点。

第三，不一上来追求全自动生成复杂系统，先生成稳定模型、表结构、接口、表单、查询，再扩工作流、事件、权限、部署。

第四，数据连接不是一次性项目。系统、字段、口径、权限都会变，映射关系本身是资产，需版本管理、测试和影响分析。

第五，分析结果不当最终事实。输出带依据、来源、口径说明，区分事实、推断、建议，经营决策保留人工复核。

第六，编排引擎意图解析准确率仍是最大挑战，重点应放积累场景配方库和优化意图匹配，而非每次从零让大模型推导计划。

十、小结

本体驱动平台的做法，是把软件建设和数据分析里反复出现的"语义翻译"问题，收敛到一套模型体系：需求经结构化探索进模型，应用经模型生成，数据经模型映射，分析经模型获上下文，OLTP 与 OLAP 经模型统口径。

它不是单点工具，而是一组职责单一的引擎加一套编排机制：先把业务说清，再建成模型，再让模型驱动系统和分析。可从合同履约、销售回款、库存分析等小场景起步，打通"需求—本体—数据—分析"或"需求—本体—应用"流程，逐步验证价值，再按需补编排、网关和治理能力。