本体平台总体架构03-业务需求+技术架构实现方案细化

大家好，我是人月聊IT。

今天继续整理和分析本体驱动平台的整体需求和总体设计方案。即对我前面的两篇文章的核心思路逻辑进一步细化。可以参考这篇文章进一步通过AI辅助来构建完整系统。

一、文档目标

本文档定义一套重新建设的本体驱动平台。平台不以合并既有合同管理、Agent构建、电商分析、数据探索和本体编辑等历史项目为目标，也不直接复制这些项目的页面、代码和数据库。既有项目只用于验证一个事实：不同本体应用虽然最终产物不同，但底层都在重复使用需求探索、本体建模、数据连接、对象映射、应用生成、数据分析、AI推理、报告输出和能力发布等共性能力。

新平台需要把这些共性能力建设为职责清楚、接口稳定、可以独立调用的能力引擎，再通过平台控制面理解用户提出的问题，判断用户希望获得的最终结果，选择本次任务需要的本体模型和能力引擎，生成一条可执行的交付工作流。平台随后按照工作流逐步引导用户补充材料、确认业务判断、配置外部资源、评审模型和验收结果，最终交付应用、Agent、Skills、本体模型、数据分析报告或业务改进建议。

本文档重点回答以下问题：平台解决什么问题；平台面向哪些用户；用户如何从一句话需求进入完整交付过程；V6本体模型在不同场景下如何选择；控制面如何理解、规划和治理任务；执行面各引擎分别承担什么职责；引擎如何动态组合而不形成新的大单体；平台如何管理人工确认、模型版本、数据权限、AI上下文、运行状态和结果追溯；第一阶段应当建设哪些能力，达到什么验收标准。

二、建设背景

企业数字化发展到一定阶段后，主要矛盾通常不再是没有业务系统，而是系统数量多、业务语义分散、数据难以复用、指标口径不统一、应用建设周期长、AI难以获得可靠上下文。业务人员使用客户、合同、订单、库存、回款和风险等语言描述问题，业务系统内部却以数据库表、字段、接口、状态码和程序方法保存这些概念。数据团队又把业务系统转换为事实表、维度表、宽表和指标公式。AI团队为了让大模型回答问题，还要重新组织文档、数据库结构和查询结果。

整个过程中，每一层都在进行语义翻译。需求文档可能无法完整表达业务人员的真实意图；数据库字段可能无法说明业务对象和规则；指标SQL可能脱离原始业务口径；大模型看到数据后也无法判断字段是否可靠、指标如何计算、哪些规则适用。企业最终得到的是多个彼此独立的局部系统，而不是一套可以持续演进的业务语义资产。

本体驱动平台的核心判断是：企业需要一个位于需求、应用、数据和AI之间的统一业务语义层。这个语义层不能只是知识图谱或说明文档，而必须能够被程序读取、校验、引用和执行。需求探索需要围绕它形成结构化输入，应用生成需要依据它生成代码，数据连接需要通过它理解物理数据，AI推理需要从中选择业务上下文，变更治理需要通过它分析影响范围。

在此基础上，平台还需要解决第二个问题：用户的目标不是使用某个引擎，而是获得结果。客户不会以“我要调用本体模型引擎、数据分析引擎和报告引擎”的方式提出要求，客户只会说“帮我分析销售下滑原因”“建设一个合同管理系统”“把现有数据库发布为一个查询Agent”“发现供应商风险后自动通知负责人”。平台必须先理解这些问题属于什么场景，再决定应该使用哪些能力、需要哪些模型、如何组织步骤以及哪些内容必须由客户确认。

因此，新平台并非把若干工具放入统一菜单，而是要建立一套场景驱动的智能交付机制。统一平台负责理解目标、规划过程和治理资产；专业引擎负责完成具体任务；本体模型保证各环节使用同一套业务语义；工作流保证整个交付过程可执行、可暂停、可恢复和可追溯。

三、平台总体定位

平台定位为企业级本体驱动的AI原生应用构建与成果交付平台。它既支持从原始需求正向构建新系统，也支持从现有数据库、接口和文档逆向识别业务语义；既支持生成可运行应用和Agent，也支持基于真实数据完成指标分析、原因归因和报告输出。

平台不是单一领域应用。合同、销售、设备、供应链和财务等领域只是平台上的不同本体项目。平台本身不固化任何领域对象，而是提供领域语义构建、执行能力组装和交付治理机制。

平台不是单纯低代码产品。低代码通常围绕页面、数据表和流程快速生成应用，本平台则以本体模型为中心，同时覆盖需求、领域对象、行为、规则、事件、权限、流程、查询、UI、数据库映射、接口、指标、Agent和AI推理。应用生成只是平台的一种交付方式。

平台不是传统数据分析平台。它不只提供数据库连接、SQL和图表，而是在数据分析之前形成业务对象、字段Mapping和指标语义，使分析结果能够解释数据来自哪里、口径如何定义、结论依据是什么。

平台也不是一个允许大模型自由操作所有资源的通用聊天机器人。AI负责理解问题、补充通用知识、生成候选模型、选择场景配方、形成执行计划和生成分析建议，但AI必须受到本体规范、能力契约、数据权限、场景配方、人工门禁和结果校验的共同约束。

平台最终形成两类核心能力。第一类是设计时能力，将问题、需求、数据库和接口转化为本体及交付资产。第二类是运行时能力，使Agent、应用、分析任务和自动化流程能够基于本体读取数据、执行行为、判断规则和生成结果。

四、总体建设目标

平台首先要建立统一任务入口。用户不需要先理解平台有哪些引擎，而是通过自然语言、文件上传或已有项目表达自己的目标。平台对问题进行分析，并向用户解释自己理解的业务目标、交付类型、推荐场景、所需输入、拟采用模型和预计执行步骤。

平台其次要建立场景化模型选择能力。V6规范提供完整的本体模型体系，但不同项目不应机械生成全部模型。平台要根据场景判断哪些模型是必需、建议、可选或不适用，并说明选择原因。用户需求变化后，模型选择结果也要随之调整。

平台还要建立标准能力引擎体系。每个引擎都应拥有清晰边界、标准输入输出、版本信息、前置条件、权限要求、运行状态和异常语义。控制面调用的是能力，而不是某个历史项目中的页面或内部函数。

平台需要建立动态编排能力。AI在场景配方、能力注册和安全规则范围内形成执行计划，决定任务之间的依赖、并行关系、人工确认点、失败处理和最终交付物。执行计划必须是可以被工作流运行时解释的结构化对象，而不能只是一段自然语言说明。

平台需要建立统一项目和资产空间。一个客户问题从原始输入开始，形成需求文档、本体模型、数据连接、Mapping、指标、数据集、代码、Skills、报告和发布记录。这些资产必须在同一项目上下文中建立版本和引用关系。

平台还必须建立完整治理能力。任何结果都要能够追溯到使用了哪个需求版本、哪个本体版本、哪套Mapping、哪次数据查询、哪个提示词模板和哪个大模型。涉及业务规则、指标口径、数据权限和生产发布的事项必须保留人工确认。

五、平台核心概念

5.1 本体项目

本体项目是平台管理业务语义和交付过程的基本空间。一个项目对应一个相对稳定的业务领域或交付目标，内部保存原始材料、需求、模型、数据源、Mapping、指标、工作流、数据集和交付物。不同项目之间默认隔离，但允许通过受控方式引用公共模型、行业模板和连接器。

5.2 交付任务

交付任务是用户希望平台完成的一次明确目标。例如构建合同应用、发布客户查询Agent、生成季度经营分析报告。一个项目可以包含多次交付任务，同一任务也可以拆分为多个子任务。交付任务必须明确期望结果、业务范围、成功标准和时间边界。

5.3 能力引擎与能力

能力引擎是实现一类专业职责的运行组件，例如本体模型引擎或数据连接引擎。一个引擎可以注册多个具体能力，例如模型生成、模型校验、模型差异比较属于本体模型引擎的不同能力。控制面以能力为最小编排单位，从而避免把一个引擎的所有功能一次性暴露给工作流。

5.4 场景配方

场景配方是经过验证的交付流程模板。配方描述适用于什么问题，需要哪些输入，如何选择模型，调用哪些能力，哪些步骤必须串行或可以并行，哪些节点需要人工确认，失败后如何处理，以及最终产生哪些交付物。配方不包含客户的具体业务数据。

5.5 执行计划

执行计划是场景配方针对当前任务实例化后的结果。计划包含具体能力版本、资产输入、任务依赖、执行条件、人工任务、超时、重试和交付目标。执行计划一经确认，需要保存版本，运行过程中发生调整时应生成新的计划版本并记录原因。

5.6 平台交付工作流与客户业务流程

平台交付工作流用于完成需求探索、本体建模、数据连接、代码生成和报告输出等平台任务。客户业务流程是V6中M6描述的合同审批、订单履约等业务过程。两者可以使用相似的工作流技术，但业务含义、模型来源、参与角色和运行数据完全不同，必须明确分离。

5.7 交付物

交付物是平台最终或阶段性产生的可使用成果，包括本体模型、Mapping、指标定义、API、应用代码、Skills、Agent配置、分析报告、测试结果和部署包。所有交付物必须具有版本、状态、来源工作流和依赖资产。

六、用户角色与职责

业务需求方负责提出问题、解释企业特有规则、确认分析口径并验收结果。业务分析师负责组织需求探索、识别业务范围和协调不同角色意见。本体建模人员负责评审模型边界、跨模型引用和变更影响。数据工程师负责数据源、Mapping、转换、质量和权限。应用架构师负责技术架构规范、生成模板和代码验收。数据分析师负责指标、分析场景和报告解释。Agent管理员负责技能暴露、工具权限、Agent测试和发布。平台管理员负责租户、用户、模型供应商、能力引擎、连接器、配方和安全策略。

平台不能只提供统一管理员权限。不同角色对需求、模型、数据、代码、报告和发布拥有不同权限。尤其是数据访问权和引擎调用权需要分开控制：用户能够查看本体对象，不代表其可以读取对应数据；用户可以执行分析，不代表其可以发布具有写操作能力的Agent。

七、V6本体模型与场景化选择

7.1 V6模型基线

当前平台以ontology_modeling_framework_v6为权威建模规范。V6包含M1对象、M2行为、M3规则、ME事件、M4跨对象事件协同场景、M5主体角色权限、M6流程、M7查询统计与固定报表、MU用户界面、MM对象数据表映射和MI接口模型。

平台要完整支持这些模型的结构定义、引用解析、一致性检查、可视化、版本、导入导出和影响分析。但平台支持全部模型不意味着每个任务都要创建所有模型。模型是否出现必须由真实业务语义和交付目标决定。

7.2 模型选择机制

场景分析完成后，模型选择器输出本次任务的模型适用性清单。每个模型被标记为必需、建议、可选或不适用，并给出基于需求证据的解释。用户可以调整选择，但如果调整违反V6依赖关系，平台必须提示影响并阻止错误计划进入执行。

M1通常是大多数本体项目的基础，因为它定义业务中真实存在的对象、属性和关系。M2在需要定义系统操作、查询入口或外部调用承接行为时使用。M3只用于跨对象、跨行为、事件驱动或需要独立复用的规则，不能把简单字段约束全部堆入M3。ME只在存在真实事实事件及生产订阅关系时使用。M4只描述跨对象的事件协同，不能代替普通顺序流程。M5在存在角色、权限、数据范围或外部主体时使用。M6用于端到端协同和审批，不得因为页面有多个步骤就虚构流程。M7用于正式跨对象查询、统计和固定报表，不是BI指标模型。MU在需要生成或追溯UI时使用。MM在连接已有数据库或明确持久化Mapping时使用。MI在系统对外提供接口或依赖外部接口时使用。

7.3 数据分析扩展模型

数据指标分析场景需要独立指标语义。V6已经明确M7不是BI指标模型，因此平台需要在不改变V6现有语义的前提下，引入可插拔的指标扩展模型。其正式编号需要通过后续建模规范确认，平台第一阶段可以先作为受版本管理的扩展资产实现。

指标模型需要表达指标的业务名称、定义、计算公式、统计粒度、时间口径、过滤条件、维度、单位、适用范围、来源对象、来源属性、数据质量要求、负责人、生效时间和版本。指标定义引用M1和MM，物理SQL只是某个数据源方言下的执行实现，不能成为指标业务定义本身。

数据源配置、账号和网络信息不属于本体模型。MM负责对象属性与物理表字段的对应，指标模型负责业务度量语义，连接配置负责如何访问数据。平台需要清楚区分这三类资产。

7.4 典型场景的模型组合

新建业务应用通常以M1、M2、M3、M5、M6和M7为主体，根据是否存在事件协同增加ME和M4，根据是否生成界面增加MU，根据数据库持久化要求增加MM，根据系统集成要求增加MI。

存量系统逆向建模通常从MM和MI切入，通过数据库与接口元数据推导M1，再根据已有业务文档逐步补充M2、M3、M5和M7。平台不能仅根据表结构自动虚构行为、规则和流程。

经营分析通常需要M1、MM、指标扩展模型和分析场景资产。若需要形成正式查询或固定业务报表，可以增加M2查询行为和M7；若分析涉及数据访问范围，则增加M5。普通分析流程不需要为了模型完整而建立ME、M4或M6。

Agent构建通常需要M1、M2、M5和MI。查询型Agent访问已有数据库时还需要MM和M7；决策型Agent需要M3；触发自动化动作时可能需要ME、M4或M6。Agent技能描述本身属于交付制品，不应替代业务本体。

八、总体产品流程

用户进入平台后，首先创建或选择一个本体项目，然后通过统一任务入口输入问题或上传材料。系统保存原始输入，不在解析后覆盖原文。场景分析器识别业务目标、交付类型、涉及领域、已有材料和缺失信息，并生成场景理解结果。

平台向用户展示自己的理解，包括推荐场景配方、建议模型、拟调用引擎、关键步骤、预计交付物和需要用户参与的确认点。用户可以修改业务范围或交付目标。只有用户确认后，平台才创建正式执行计划。

执行计划创建后，工作流中心按阶段引导用户。某些阶段由引擎自动完成，某些阶段需要用户配置数据源、选择技术架构或确认指标口径。每个阶段完成后形成可检查的中间资产，并执行结构和一致性校验。下游任务只引用已经持久化且状态合格的资产版本。

工作流允许暂停、恢复、回退、重新生成和转人工。用户在中途修改目标时，平台进行影响分析，判断哪些成果仍然有效、哪些节点需要重新执行，而不是简单清空所有结果。

最终结果进入交付中心。交付中心不仅提供下载，还要显示结果依赖的需求、本体、数据、引擎、模板和运行记录，使用户能够判断结果是否可靠，并支持后续迭代。

九、控制面详细设计

9.1 统一任务入口与上下文收集

统一任务入口负责接收自然语言、需求文档、数据库设计、接口文档、样例文件和已有本体模型。入口需要识别文件类型和材料用途，并将材料登记为原始资产。任何自动解析结果都必须保留对原始材料位置的引用。

入口还要收集项目级上下文，包括所属行业、业务域、目标用户、已有系统、数据敏感级别、部署约束和允许使用的大模型。用户不必一次填写全部信息，平台可以根据后续场景按需追问。

9.2 意图与场景分析器

场景分析器负责识别用户是在构建应用、构建Agent、建立本体、分析数据、治理指标还是设计自动化流程。它还要识别最终结果的形态，因为“分析回款风险”和“建设回款风险分析系统”虽然业务主题相同，但交付流程不同。

分析器输出业务目标、交付类型、业务范围、关键对象候选、已有输入、缺失输入、约束、风险和候选配方。每项判断要记录依据和置信度。置信度不足或多个场景相近时，平台应提出少量关键澄清问题，不能悄悄选择一个方向继续执行。

9.3 场景配方管理

场景配方库保存经过验证的标准交付路径。配方包含适用条件、必要输入、模型选择策略、阶段结构、能力节点、人工任务、校验门禁、异常分支和交付物定义。配方支持行业参数，但不能把具体客户对象和字段硬编码在配方中。

配方具有草稿、测试、发布和废弃状态，并独立版本化。已启动工作流继续使用启动时的配方版本，配方升级只影响新任务。管理员可以查看配方成功率、平均耗时、常见失败点和人工修改次数，以此持续改进配方。

9.4 能力注册与发现

能力注册表是控制面认识执行面的唯一入口。每项能力必须声明唯一ID、版本、所属引擎、业务说明、输入输出结构、依赖资产、前置条件、权限、资源消耗、超时、重试、幂等、是否支持流式进度和能够产生的事件。

能力注册表还保存运行地址、健康状态和兼容范围。某个引擎升级后，如果输出结构发生破坏性变化，应注册新能力版本，不能直接改变正在运行的计划。控制面在计划生成时选择明确版本，避免运行时漂移。

9.5 模型选择器

模型选择器根据场景、需求证据和交付物形成模型集合。它必须理解V6各模型的语义边界和依赖，能够解释为什么选择某模型，也能够指出某模型当前缺乏业务依据。

模型选择不是一次性动作。需求探索、数据探索和接口识别都可能带来新信息。控制面需要持续监控模型适用性变化，并通过影响分析调整后续计划。例如发现外部物流接口后，应增加MI相关建模和接口生成步骤，而不是等到代码生成阶段临时处理。

9.6 计划生成器

计划生成器把配方、能力、模型集合、已有资产和用户约束组合为执行计划。每个计划节点必须指定调用能力、输入资产、输出资产类型、依赖节点、执行条件、失败策略和人工门禁。计划中可以存在并行节点，但任何节点都不能读取尚未完成或未确认的上游结果。

计划生成器需要检查执行图是否存在环路，输入输出是否匹配，所需模型和连接器是否可用，用户是否具备权限，模型调用预算是否允许。计划校验失败时要给出具体缺口，而不是仅提示无法执行。

9.7 工作流运行与状态管理

工作流运行时负责实例化计划、分配任务、传递资产引用、接收进度、处理人工任务、保存检查点和发布状态事件。长时间运行的AI生成、数据扫描和代码构建任务必须异步执行，前端通过事件持续显示进度。

状态管理至少覆盖等待输入、等待资源、准备执行、执行中、等待确认、成功、失败待重试、失败待人工、已跳过、已取消和已补偿。每次状态变化保存时间、操作者、原因和关联日志。

9.8 人工任务与决策中心

人工任务中心集中呈现需要用户处理的事项，包括需求确认、低置信度Mapping、模型错误、指标口径、权限范围、代码差异和生产发布。任务内容要面向业务人员表达，不能只展示内部异常堆栈。

用户可以确认、修改后确认、驳回、退回上一步或要求重新生成。确认结果形成正式决策记录。对于不同意见，平台应允许保留备选方案和评审意见，不把最后一次对话简单视为唯一真相。

9.9 项目、资产与版本中心

资产中心统一登记原始材料、需求、模型、Mapping、指标、数据集、代码、Skills、报告、测试和部署制品。每类资产具有类型、版本、状态、所有者、来源、创建方式和依赖关系。

资产内容可以保存在数据库、对象存储或代码仓库，但元数据和引用关系必须统一。平台需要支持从任意资产向上查看来源，向下查看消费者。模型或Mapping变更时，资产中心为影响分析提供依赖图。

9.10 追溯、审计与成本中心

每次交付任务生成全局追踪标识。控制面记录场景分析、配方版本、计划版本、能力调用、输入输出资产、人工决策、AI模型、Token、耗时和错误。对于数据分析报告，还要记录数据源、查询、数据时间范围和指标版本。

审计中心面向安全和合规，成本中心面向资源治理。平台管理员可以按项目、用户、引擎和模型查看调用量、失败率和成本，并设置预算、并发和模型使用策略。

十、执行面能力引擎详细设计

10.1 需求探索引擎

需求探索引擎负责把一句话目标、会议纪要或已有文档转化为足以支撑建模和交付的结构化需求。它不是普通聊天模块，而是一个按业务范围、对象、行为、规则、事件、流程、角色、查询、界面、数据和接口逐层补齐信息的分析能力。

引擎输入包括原始材料、场景类型、行业背景、已有系统信息和用户回答。处理过程中先识别已明确内容，再利用通用行业知识提出候选项，最后把企业特有内容转化为待确认问题。AI建议和用户确认必须分别标记，不能把模型推测包装成业务事实。

输出包括结构化需求文档、需求条目、来源证据、待确认事项、冲突项和模型候选。每条需求应具有稳定ID，便于后续模型元素反向追溯。需求变更时，引擎输出差异，不重新生成一份与旧版本无关联的文档。

关键约束是控制追问数量和顺序。平台应优先询问会改变模型边界、数据范围或交付路线的问题，而不是一次提出几十个细节。需求完整度应按场景评估，例如纯数据分析不必补齐完整UI需求。

10.2 本体模型引擎

本体模型引擎是平台业务语义资产的核心管理者。它负责根据需求正向生成模型，根据数据库和接口逆向形成候选模型，也负责人工编辑、结构校验、跨模型一致性校验、可视化、版本、差异和影响分析。

引擎必须原生支持V6全部模型，并允许项目只创建选定模型。模型生成顺序根据依赖关系确定，而不是固定要求所有场景走相同顺序。生成过程中应采用分模型、分阶段策略，每个模型生成后立即解析和校验，避免一次大模型调用生成全部文件导致错误难以定位。

一致性检查不仅包括YAML格式，还包括稳定ID、引用目标、M2与M7一对一绑定、事件单一生产者、订阅关系、M4步骤语义、M6流程可达性和无循环、MU调用链顺序、MM对象字段引用以及MI接口字段口径等。

引擎对AI生成模型设置提案机制。AI首先生成候选变更和影响摘要，用户确认后才能覆盖正式版本。删除或重命名被其他模型引用的元素时，引擎必须阻止直接保存，要求用户选择级联修改或保留旧元素。

输出包括模型文件、模型索引、引用图、校验报告、差异报告和影响分析。正式发布的模型版本不可被原地修改，后续变化以新版本存在。

10.3 数据连接引擎

数据连接引擎负责安全访问企业真实数据和外部服务。它提供数据库、数据仓库、REST接口、文件、对象存储和消息系统等连接器，并统一处理认证、网络测试、元数据读取、分页、方言、超时、重试和错误转换。

引擎输入是连接配置、调用者身份、逻辑数据请求和Mapping版本。引擎根据MM以及连接器能力生成物理查询或接口请求，在执行前注入数据范围、字段脱敏、最大行数和超时限制。返回结果包括结构化数据、字段元信息、来源、执行时间、截断状态和质量警告。

数据连接引擎不负责解释经营含义，也不直接生成最终AI结论。它要确保上层不需要了解数据库方言和认证细节，同时不能让上层绕过连接器直接接触生产数据库。

连接配置与业务模型分开版本管理。密码和密钥加密保存，不进入日志和提示词。生产数据源默认只读，任何写操作必须通过明确接口、M2行为、权限和审批策略执行。

10.4 数据探索与Mapping引擎

该引擎用于理解现有数据库中表、字段、关系和样例数据所代表的业务含义。它综合数据库设计文档、表名字段名、主外键、唯一约束、数据分布、枚举值和样例记录，识别候选业务对象、对象关系和属性Mapping。

每条候选Mapping必须包含目标M1对象或属性、物理表字段、转换规则、置信度、推断依据和确认状态。字段名称清楚但缺少业务说明时不能自动认定为高置信度；同名字段在不同表中口径可能不同，引擎需要结合关系和数据分布判断。

引擎还负责检测源结构变化。当表、字段或类型变化时，它比较数据源指纹和现有MM，输出受影响对象、指标、查询和报告。Mapping不是一次性配置，而是持续治理资产。

逆向探索只能形成候选M1和MM。行为、规则、权限和流程通常无法仅从表结构可靠推导，必须结合需求文档和人工访谈。

10.5 指标模型与指标计算引擎

指标引擎负责从业务目标、对象语义和数据结构中识别候选指标，并将指标从自然语言口径转化为可验证的指标定义和计算计划。它管理基础指标、派生指标、复合指标、维度、粒度、时间窗口、过滤条件、单位和生效版本。

引擎需要区分指标业务语义与物理实现。业务语义引用M1对象和属性，物理实现通过MM解析到具体字段，并根据数据源生成SQL或其他计算任务。一个指标可以针对不同数据源拥有多个实现，但业务定义必须保持一致。

指标计算前需要检查数据完整性、粒度匹配、时间范围和重复关联风险。计算后保存结果、输入数据集、公式版本和质量状态。涉及多个一对多来源时，应使用预聚合等方式避免重复计数。

指标引擎不负责开放式经营归因。它提供可信的度量结果和拆解数据，AI分析推理引擎在这些事实基础上形成原因判断和建议。

10.6 数据分析引擎

数据分析引擎负责将用户分析问题转换为一组可执行的逻辑分析任务。它识别目标指标、对比基准、时间范围、分析维度、过滤条件和需要采用的分析方法，然后组织数据获取、清洗、聚合、对比、贡献度、异常检测和相关性分析。

引擎输入包括结构化分析问题、本体对象、指标定义、规则、Mapping和数据权限。输出包括逻辑分析计划、中间数据集、统计结果、异常点、候选原因和证据索引。逻辑计划不直接绑定某个数据库方言，物理查询交由数据连接引擎处理。

分析引擎应支持场景方法库，例如趋势分析、结构拆解、漏斗分析、客户分层、库存周转和回款风险。方法库定义所需指标、维度和计算步骤，不直接写死客户表名。

分析结果必须保留可重复执行能力。同一数据范围和模型版本下应能够复现相同计算结果。随机性只允许存在于AI解释环节，不能进入基础指标计算。

10.7 AI分析推理引擎

AI分析推理引擎负责在受控上下文内完成归因、风险判断、解释和建议。它不是数据查询入口，也不直接连接数据库。其输入来自本体模型、指标定义、业务规则、分析结果、数据质量信息和用户问题。

引擎首先进行上下文选择，只提取与当前问题相关的对象、关系、规则、指标和数据，避免将全部模型无差别送入大模型。随后构造明确的事实区、口径区、约束区和任务区，要求模型区分数据事实、逻辑推断、假设和建议。

模型返回后，引擎执行结果校验。数字需要在数据集或计算结果中找到来源；字段和对象必须存在；指标需要引用正确版本；建议必须说明依据。校验不通过时可以要求模型修复，仍无法修复的内容标记为低置信度或推测。

引擎输出结构化结论、证据引用、置信度、风险、建议和待进一步验证的问题。平台不保存或展示模型内部思维链，而是保存可审计的分析依据和简明推理说明。

10.8 应用生成引擎

应用生成引擎负责把本体模型和技术架构规范转换为可构建、可运行和可测试的软件工程。生成范围包括数据库结构、领域对象、应用服务、行为接口、规则实现、事件DTO、权限策略、流程定义、查询服务、报表、前端页面、测试和部署配置。

生成前必须确定目标技术栈、工程分层、数据库、认证方式、部署环境、代码风格和模板版本。本体定义业务语义，技术架构规范定义实现约束，二者共同作为生成输入。

引擎应先生成中间表示，再由不同技术模板转换为代码，避免提示词直接生成整个工程而无法稳定复现。每个模型元素与代码文件、类和方法之间保存映射关系，支持从代码追溯模型，也支持模型变更影响分析。

增量生成是关键难点。引擎需要区分平台生成区域和人工维护区域，不得无提示覆盖人工代码。模型变化后先输出代码差异、数据库迁移和兼容风险，经过确认后再应用。

交付前执行编译、单元测试、接口测试和基础安全检查。生成失败时保留中间表示和构建日志，使用户可以定位是模型、模板还是环境问题。

10.9 API与接口生成引擎

接口生成引擎以MI为主要契约来源，同时引用M1字段口径、M2承接行为、M7查询结果和M5外部主体。它负责生成请求响应模型、接口入口、外部客户端、协议文档、Mock、联调测试和错误码骨架。

接口生成必须保持MI的职责边界。MI描述系统边界契约，M2描述业务执行行为，不能把业务流程直接写进接口模型。查询接口不得产生业务状态变化，命令接口需要明确权限、幂等和返回规则。

接口变化时，引擎分析消费者、Agent工具和外部系统影响。破坏性字段删除、类型变化和方向调整需要生成兼容建议及迁移说明。

10.10 Skills技能包生成引擎

Skills生成引擎负责将本体和可调用能力组织为Agent能够理解的技能资产。技能包应包含能力目的、适用范围、对象语义、参数结构、调用方式、返回结构、权限、安全边界、错误处理和典型使用方式。

技能包不是把所有模型文件简单拼接成大文档。引擎要根据目标Agent职责选择最小必要上下文，区分查询技能、操作技能、分析技能和组合技能。技能中引用的API和工具必须真实可用，并与能力网关注册信息一致。

生成后需要执行结构校验、工具连通测试、参数边界测试和越权测试。涉及写操作的技能默认不自动发布，需要人工审批。

10.11 Agent构建与发布引擎

Agent引擎负责将一个或多个Skills、模型配置、工具权限、系统指令、记忆策略和发布目标组合成可运行Agent。它根据Agent职责决定允许调用哪些能力，不能让Agent默认访问整个项目。

发布前需要通过对话测试、工具选择测试、错误恢复测试、数据权限测试和敏感操作测试。平台保存测试集和结果，Agent升级后进行回归测试。

Agent可以发布到平台内置运行时、MCP客户端或第三方Agent平台。不同渠道由发布适配器处理，但Agent能力定义保持统一。运行期的每次工具调用仍需经过本体能力网关鉴权和审计。

10.12 规则引擎

规则引擎加载M3规则和经批准的分析规则，接收结构化事实，输出判断、评分或计算结果。规则必须无副作用，业务状态变化由M2行为完成。规则引擎不能自行发起完整业务流程，但可以在工作流节点、数据过滤、事件订阅和AI分析前被调用。

规则需要版本、生效时间、输入结构和测试用例。规则变化后平台能够识别受影响的行为、事件场景、流程和分析任务。高频规则可以编译或缓存，复杂外部决策可以通过适配器调用专业规则服务。

10.13 事件引擎

事件引擎负责运行ME定义的事实事件，包括发布、订阅、顺序、幂等、重试、死信和追踪。事件必须描述已经发生的业务事实，不能把“是否高风险”等未决判断作为事实事件发布。

事件引擎校验生产者和订阅者是否与模型一致，并把事件实例与模型版本关联。对于至少一次投递，订阅者需要幂等键；对于事件回路，平台设置去重、最大跳数和防抖策略。

事件引擎既可以服务生成后的业务应用，也可以服务平台自身的异步任务，但两类事件需要命名空间和权限隔离。

10.14 业务流程执行引擎

业务流程引擎执行M6定义的端到端协同流和审批流。它负责流程实例、人工任务、系统任务、网关、子流程、事件等待、超时和结果分支，并根据M5角色分配人工活动。

引擎执行M2行为、M3规则和M4场景时只使用稳定ID引用，不在流程定义中复制业务逻辑。流程版本发布后，已有实例继续使用原版本，新实例使用新版本，除非管理员执行受控迁移。

业务流程引擎不负责平台自身的交付编排。平台交付工作流由控制面运行时管理，M6流程由客户业务运行时管理，审计数据和用户界面也需要区分。

10.15 报告与可视化引擎

报告引擎负责把查询结果、指标结果、AI结论和证据组织为可阅读的交付物。它支持网页、Markdown、Word、Excel和PDF等格式，并根据内容选择表格、趋势图、结构图和说明文本。

报告模板定义章节、组件、数据绑定和导出格式，但不得改变指标计算和分析事实。报告中的每个重要数字应能够定位到指标结果或数据集，每个AI结论应显示证据和置信度。

报告需要显示分析范围、数据时间、生成时间、本体版本、指标版本和数据质量说明。重新生成报告时保留旧版本，不覆盖已经交付的结果。

10.16 本体能力网关

本体能力网关将平台内部对象、行为、查询、规则、场景和Agent工具以标准方式对外开放。网关提供能力发现、统一鉴权、参数校验、协议适配、限流、审计和调用追踪。

网关对外暴露的是经过授权的能力视图，而不是整个本体项目。不同Agent、系统和用户看到的能力集合可以不同。数据查询还要把调用者身份传递给数据连接引擎，以执行行级和字段级权限。

网关支持REST、MCP、消息和其他协议适配。协议转换不改变业务能力ID，使外部调用仍可以追溯到M2行为、M7查询或已注册执行能力。

10.17 大模型网关

大模型网关统一管理模型供应商、模型列表、密钥、路由、Token预算、超时、重试、缓存、脱敏和成本。各业务引擎只提交任务类型、消息、上下文、安全等级和期望输出结构，不直接管理供应商密钥。

网关可以根据任务选择模型，例如需求探索、本体生成、代码生成和分析推理使用不同配置。模型路由策略需要版本化，并允许项目限定模型供应商和数据出境策略。

网关记录输入摘要、提示词模板版本、输出状态、Token和耗时。敏感原文是否保存由安全策略决定。缓存只能用于不会泄露项目数据且输入完全一致的任务。

10.18 存储与制品引擎

存储引擎管理平台产生的结构化资产和大文件制品。项目、任务、工作流、模型索引和引用关系进入平台数据库；原始文档、模型包、数据快照、报告和构建制品进入对象存储；应用代码进入受管代码仓库。

存储引擎需要提供版本、校验值、锁、归档、恢复和生命周期策略。正式发布的交付物不可被直接替换，删除重要资产前需要检查下游引用。临时数据集按项目策略自动清理，但审计元数据必须保留。

十一、动态编排机制

11.1 配方优先、AI补充

平台优先匹配成熟场景配方，因为固定配方更稳定、更易解释，也便于积累测试和交付经验。AI主要负责理解用户意图、选择配方、填充参数、判断可跳过步骤和补充当前任务特有节点。

当没有完整匹配的配方时，AI可以在能力注册表和依赖规则范围内生成候选计划，但计划必须先通过机器校验，再由用户或平台专家确认。成功运行并经过评审的计划可以沉淀为新配方。

11.2 结构化计划与依赖图

执行计划由节点和依赖关系组成。节点引用具体能力版本，输入通过资产ID传递，输出声明资产类型。计划支持串行、并行、条件分支、人工任务、重试和子计划，但单次执行计划内部不得形成依赖环。

计划生成后需要进行静态检查，包括输入输出类型、前置资产、模型依赖、权限、资源、预算和危险操作。静态检查通过后才允许启动。

11.3 运行时上下文

工作流上下文保存项目、任务、用户、模型版本、资产引用、权限和预算。引擎之间不传递无限增长的聊天记录，而是读取明确版本的结构化资产，并由上下文构建器生成当前步骤所需的最小输入。

11.4 检查点与恢复

每个重要阶段完成后形成检查点。引擎失败、平台重启或用户暂停后，可以从最近检查点恢复。已经完成且输入未变化的节点不重复执行；上游资产变化时，通过依赖图判断哪些节点失效并需要重新运行。

11.5 异常分类与补偿

平台区分输入缺失、模型校验失败、连接失败、权限拒绝、资源超限、AI输出不合格、构建失败和外部服务不可用等异常。不同异常采用补充输入、自动修复、重试、切换模型、回退版本、跳过或转人工等策略。

补偿不是简单删除结果。已经形成的资产保留为失败运行证据，正式资产是否回退由版本和发布策略决定。

11.6 人工门禁

企业特有规则、指标口径、低置信度Mapping、权限、写操作技能和生产发布默认设置人工门禁。平台允许项目根据风险等级调整门禁，但不能由单次AI规划自行取消安全门禁。

十二、典型场景完整说明

12.1 新业务应用构建

用户提出建设某类业务系统后，控制面识别交付类型为应用，需求探索引擎补齐业务范围、对象、行为、规则、角色、流程、查询、页面和接口。模型选择器根据真实需求确定V6模型集合。本体模型引擎生成并校验模型，业务人员和架构师完成评审。

用户随后选择技术架构规范，应用生成引擎生成工程，接口引擎生成契约和测试，构建环境执行编译和自动测试。平台展示模型到代码的追溯关系和未完成事项。通过验收后，应用作为版本化制品发布或导出。

该场景的核心不是一次提示词生成代码，而是需求、本体、技术规范、中间表示、代码、测试和发布之间形成稳定链路。

12.2 Agent与Skills构建

用户先描述Agent职责和允许执行的业务范围。需求探索引擎重点确认工具能力、数据范围、写操作、人工确认和错误处理。本体模型引擎建立对象、行为、权限、接口及必要的查询和规则模型。

平台生成或连接真实API，再由Skills引擎形成最小技能集合。Agent引擎配置模型、工具和权限，运行测试集检查工具选择、参数正确性、越权和异常恢复。通过门禁后发布到指定渠道。

该场景必须坚持能力最小暴露。Agent需要查询客户，不代表它可以修改客户；能够调用某个API，也不代表它可以使用API的全部参数范围。

12.3 数据探索与经营分析

用户提出经营问题后，需求探索重点确认分析对象、时间、口径、对比基准和期望报告。用户配置只读数据源和数据库说明，数据探索引擎识别对象与字段，Mapping引擎形成M1和MM候选并要求确认低置信度项。

指标引擎建立指标语义和计算计划，数据分析引擎按场景完成多维拆解、趋势和异常分析。AI推理引擎只使用相关本体、指标、规则和分析结果形成归因与建议。报告引擎输出完整报告，并展示数据范围、口径、证据和追溯信息。

该场景体现平台相对传统AI问数的核心差异：真实外部数据通过连接器受控进入；数据通过Mapping获得对象语义；指标定义独立管理；大模型在本体和事实范围内推理。

12.4 存量系统逆向本体化

用户连接已有数据库、导入接口和业务文档。数据探索和接口分析形成候选对象、关系、Mapping和接口目录。本体模型引擎根据结构证据生成M1、MM和MI，再由业务访谈补充行为、规则、权限、查询和流程。

平台对每个推导结果标记来源和置信度。仅能从技术结构推断的内容不能直接发布为正式业务语义。完成评审后，平台输出本体模型、系统边界图、Mapping和影响分析，为后续Agent、分析或系统改造提供基础。

12.5 事件驱动自动化

用户提出风险监控或自动响应目标后，平台识别需要数据来源、判断规则、事实事件、下游动作和权限。需求探索明确哪些是事实、哪些是判断、哪些动作允许自动执行。

模型引擎建立M1、M2、M3、ME、M4和M5，复杂人工处置增加M6，外部通知或工单接口增加MI。运行时由连接器或业务行为提供事实，规则引擎完成判断，事件引擎发布事件，M4或M6组织后续动作，能力网关调用外部系统。所有动作保存审计和幂等信息。

十三、数据、权限和安全设计

平台权限至少分为平台管理、项目资产、能力调用、数据访问和发布五个层次。平台管理员能够配置引擎，不代表可以查看所有项目数据；项目成员能够编辑模型，不代表可以连接生产数据库；Agent能够调用查询工具，不代表可以调用写操作。

数据访问必须在连接执行时生效。控制面把调用者身份、项目和用途传递给数据连接引擎，连接器根据M5、项目策略和数据源策略注入行级过滤、列级限制和脱敏。不能先读取全部数据再由前端隐藏。

所有密钥加密保存，并通过密钥引用提供给连接器和网关。日志、提示词和错误信息不得输出完整密钥。向外部大模型发送数据前执行敏感字段识别和脱敏，项目可以限制只能使用本地模型。

SQL默认只读，限制执行时间、返回行数和危险语句。外部API调用需要超时、重试、熔断和审计。写操作必须对应明确M2行为和权限，危险操作需要人工确认和幂等键。

十四、资产治理与可追溯性

需求条目、本体元素、Mapping、指标、能力、代码和报告都使用稳定ID。平台通过引用图管理它们之间的关系。删除对象属性时，可以定位受影响的行为、规则、查询、UI、Mapping、接口、指标、Agent和报告。

每份分析报告需要记录本体版本、Mapping版本、指标版本、数据源、查询时间、数据范围、分析计划、模型和提示词模板。每个应用制品需要记录需求版本、本体版本、技术规范、模板和构建结果。每个Agent需要记录Skills、工具、权限和测试集版本。

平台对资产采用草稿、评审、发布和废弃等状态。已发布资产不能原地修改。跨模型破坏性变化必须生成影响分析和迁移说明。

十五、总体技术架构建议

平台前端包括统一任务入口、项目工作台、需求工作台、本体工作台、数据连接工作台、工作流中心、人工任务中心、交付中心和管理控制台。

后台分为控制面服务、执行引擎服务、资产与治理服务以及基础设施适配层。控制面负责场景、配方、计划和工作流；执行引擎负责专业任务；资产服务负责模型、文件、版本和血缘；基础设施层连接数据库、对象存储、代码仓库、消息队列、构建环境和大模型。

第一阶段建议采用模块化单体与异步任务队列，先稳定领域边界和能力契约。计算量大、依赖特殊环境或需要独立扩缩容的引擎可以作为独立进程或服务。不要在能力边界尚未稳定前全面微服务化。

模型YAML继续作为可导出、可审查的权威制品，平台数据库保存模型索引、引用图、版本和状态。大文件进入对象存储，生成代码进入Git仓库，工作流状态进入可靠数据库，异步进度通过事件机制传递。

十六、非功能要求

平台需要保证长任务可恢复。任何AI生成、数据扫描和代码构建任务都不能依赖单一HTTP连接完成。平台重启后，运行状态和检查点仍然存在。

平台需要保证可扩展。新增连接器、引擎、模型扩展和场景配方时，不应修改核心编排器。能力契约和资产结构必须版本化。

平台需要保证可观测。管理员能够查看任务拓扑、节点状态、耗时、重试、Token、成本和错误。用户能够看到业务化进度和需要处理的事项。

平台需要保证可测试。本体模型有固定校验样例，引擎有契约测试，配方有端到端回归测试，Agent有工具调用测试，生成应用有构建和接口测试。

平台需要支持私有化部署，并预留多租户能力。项目、数据、模型调用和存储需要租户隔离。对于高敏感行业，应支持本地模型和内网数据源。

十七、实施路线

第一阶段建设平台控制面骨架和数据分析闭环。范围包括项目资产、统一入口、场景识别、能力注册、配方、计划和工作流，本体模型、数据连接、Mapping、指标、数据分析、AI推理、报告和追溯。首个配方选择已有数据库经营分析，因为它能够完整验证本体、外部数据和AI推理三个差异点。

第二阶段建设需求到Agent闭环。增加需求探索、API与Skills生成、能力网关、Agent构建、测试和发布。

第三阶段建设需求到应用闭环。增加技术架构规范、应用生成、MU页面生成、M6流程实现、代码仓库、构建和部署。首批只支持边界明确的单体业务应用，不承诺复杂分布式系统全自动生成。

第四阶段增强事件自动化、企业治理、多租户、模型市场、配方市场、影响分析、成本治理和团队协作。

十八、第一阶段验收标准

用户提出一个经营分析问题后，平台能够识别场景并解释选择理由；能够推荐本次所需模型和引擎，并说明不适用模型；能够生成可审查的执行计划；能够配置只读数据源并识别表字段；能够形成M1和MM候选、展示置信度并接受人工修正；能够建立指标定义和逻辑分析计划；能够在权限范围内执行物理查询；能够基于本体、指标和真实数据生成结论；能够输出包含证据、口径和数据范围的报告；能够从报告追溯到全部输入和执行记录；任务失败后能够从检查点恢复；新增第二个分析配方时不修改核心工作流代码。

平台还需要证明本体确实参与执行，而不是生成后闲置。验收时应能够展示某个对象或字段如何通过MM解析到数据源，某个指标如何引用对象语义，某段分析结论如何获得相关本体和规则上下文，以及模型变化如何触发影响分析。

十九、关键风险与控制原则

最大的产品风险是把平台做成能力菜单集合。控制方式是坚持统一任务入口、场景理解和工作流交付，让用户围绕目标而不是工具操作。

最大的AI风险是自由规划不稳定。控制方式是配方优先、结构化计划、能力白名单、静态校验和人工门禁。

最大的模型风险是为了完整而虚构模型。控制方式是按V6语义边界选择模型，所有模型元素要求需求证据，模型选择结果必须可解释。

最大的数据风险是Mapping和指标口径错误。控制方式是置信度、人工确认、版本、质量检查和源结构变化检测。

最大的工程风险是平台范围过大。控制方式是按数据分析、Agent、应用和自动化四个闭环逐步建设，每个阶段形成可独立验收的业务价值。

二十、总结

本平台要解决的不是如何把历史项目放进一个新界面，而是如何把已经反复验证的需求、本体、数据、应用、Agent和分析能力重新抽象为一套统一交付体系。

平台以本体模型提供稳定业务语义，以数据连接和Mapping连接企业真实世界，以能力引擎完成专业任务，以控制面理解用户目标并生成执行计划，以工作流引导人机协同，以资产和追溯体系保证结果可复查、可迭代和可治理。

用户最终看到的应当是一个能够组织交付过程的AI工作台。用户提出问题，平台解释理解，推荐场景和模型，生成工作流，逐步请求必要输入，调用合适引擎，并交付应用、Agent、报告或改进建议。每个结果都能够回答为什么这样做、使用了什么模型和数据、经过了哪些步骤、哪些内容由AI建议、哪些内容由用户确认。

这也是平台区别于传统AI助手的根本所在：它不只生成答案，而是在本体语义、真实数据、受控能力和可执行工作流基础上完成可持续使用的业务成果交付。