企业 AI 的边界，不在聊天框里：从天润聚粮系统看输入输出、MBSE 迁移与模块有效性

用户6900693

发布于 2026-07-10 18:59:34

1210

SYSTEM FIELD NOTE

企业 AI 的边界，不在聊天框里

从天润聚粮系统看输入输出、MBSE 迁移与模块有效性

回应两个追问，也借此把天润聚粮数字企业管理系统的技术证据展开一层。

有朋友在阅读上一篇系统研发成果介绍后，提出了两个很好的问题。第一个问题是：目前分析中各阶段输入和输出大概支持哪些类型？这会影响技术当前适用边界和场景讨论，比如对一些强依赖 MBSE 的领域是否也可以支持或迁移适配。第二个问题是：当前各模块的核心技术还需要再打开一下，因为这关系到创新点来源；如果只从宏观上看，容易被理解成工程实现的各个模块被串起来了，但内部如何保证各模块有效性，还需要策略、理论方法和流程来支撑。

这两个问题问得很准。它们不是在追问“系统有没有更多功能”，而是在追问：系统的边界在哪里，系统的可信性来自哪里。

01 / FIELD NOTE 先把问题摆正：企业 AI 不是从聊天框开始的

如果只把企业 AI 理解成一个聊天入口，那么“输入”就是用户问题，“输出”就是模型回答。这个理解太窄，也会把企业智能化带到一个错误方向：系统看起来会说话，但并不一定知道企业里真正发生了什么。

天润聚粮数字企业管理系统这次值得展开的地方，恰恰不是它把几个模块拼在一起，而是它尝试把企业已有的业务系统、代码、数据库、权限、架构资产、会话产物和智能体动作，统一放到一条可验证链路里。

所以，回答这两个问题时，不能只说“有业务系统、有语义图、有智能体”。更准确的回答应该是：

01.1 / 系统每一层吃进去的是什么，吐出来的是什么

01.2 / 每一层输出为什么可信，靠什么机制避免变成不可验证的概念图

上一篇文章里我们写过三张判断卡，这里可以作为整篇文章的起点：

判断卡 01｜聊天框不是企业 AI 的起点

企业 AI 不是从聊天框开始的，而是从业务对象、流程、单据、权限和数据表开始的。

判断卡 02｜设计态与运行态要落在同一张图上

传统 5A 架构回答“应该是什么”，语义图回答“实际是什么”，真正的企业架构治理要把两者放在同一张可验证的图上。

判断卡 03｜智能体成熟看协同链路，不看角色数量

智能体系统成熟的标志，不是角色越来越多，而是它们能否围绕同一套事实、同一条主链和同一组证据协同工作。

这三句话，其实分别对应对方提出的两个问题：第一张卡在回答输入输出边界；第二张卡在回答设计态与实现态如何对齐；第三张卡在回答智能体模块如何保证有效性。

图1｜阶段输入 / 输出矩阵

02 / EVIDENCE 先摊开证据：输入、输出和代码落点

这篇文章里的判断，主要来自两类证据：一类是上一篇公众号文章已经表达出来的系统结构；另一类是天润聚粮系统代码中已经存在的模块、服务和数据结构。

为了避免只讲概念，先把证据摊开。

02.1 / 图构建流水线：Extract / Transform / Enrichment / Load

系统里有明确的语义图构建流水线：

backend/src/services/graph/pipeline/ExtractStage.ts backend/src/services/graph/pipeline/TransformStage.ts backend/src/services/graph/pipeline/EnrichmentStage.ts backend/src/services/graph/pipeline/LoadStage.ts

其中 LoadStage.ts 并不是简单写入一个展示图，而是和这些实体、服务相关：

GraphVersion GraphNode GraphEdge GraphSourceRef DataContractValidator GraphQualityGateService GraphVersionResolver

代码证据中，LoadStage.ts 明确出现了和来源引用、质量门禁相关的注释：

backend/src/services/graph/pipeline/LoadStage.ts line 70: 阶段11.2：修正refCoverage口径（基于graph_source_ref表） line 87: 证据链覆盖率强制护栏（机制级，避免“新图版本 refCoverage 回退”） line 91: nodeRefCoverage=1 & edgeRefCoverage=1 & sourceRefInvalidRate=0

这说明系统追求的不是“图上有节点”，而是“节点和边要能回到来源”。

02.2 / 多类连接器：从业务架构、代码、数据库、Schema 和函数中抽取事实

系统里已经出现多类连接器：

ArchitectureConnector.ts BackendCodeConnector.ts DatabaseConnector.ts SchemaRegistryAssetConnector.ts ReasoningFunctionConnector.ts

其中 ArchitectureConnector.ts 的注释写明：

用途：从业务架构表（business_activities、business_tasks、business_domains等）提取业务活动、任务等节点

它实际读取或关联的表包括：

business_domains business_activities business_tasks business_components data_entities application_services value_chains

BackendCodeConnector.ts 的注释写明：

用途：使用 ts-morph 解析装饰器，提取 Module、Controller、Service、Entity、Route 节点和依赖关系边

并扫描：

src/controllers/*.ts src/services/**/*.ts src/*.module.ts src/*.controller.ts src/*.service.ts

DatabaseConnector.ts 的注释写明：

用途：从 TypeORM metadata 提取 Table、Column 节点和关系边

并且代码中还出现了：

DataEntity → BusinessComponent (BELONGS_TO_COMPONENT)

这说明系统不是单点 ETL，而是在从多个事实源中抽取企业系统的不同侧面。

02.3 / 查询计划、对象集和执行引擎：语义图不是只用于展示

系统中还有这些服务：

QueryPlannerService.ts PlanCompilerService.ts ObjectSetQueryService.ts ObjectSetRegistryService.ts ExecutionEngine.ts

QueryPlannerService.ts 的代码证据显示：

ObjectSetQueryService.ts 的注释写明：

单类型 ObjectSet 查询服务输入：objectType / filters / searchAround / limit 落地点：复用 search_nodes / expand_graph，产出 ObjectSet 并注册到 ObjectSetRegistry

ObjectSetRegistryService.ts 中则出现了对象集定义和输出摘要的标准化：

object_set_definition/v1 object_set_output_summary/v1 rowCount nodeCount edgeCount

这说明系统不是让大模型直接“自由回答”，而是把问题转成计划、查询、对象集、执行和注册。

02.4 / 权限、审计、物化、回写和动作派发

企业系统的关键不是“能不能回答”，而是：谁能问、问到了什么、为什么能问、能不能执行、执行后如何审计。

系统中有：

PermissionGateService.ts PermissionDecisionAuditLog.ts MaterializationOrchestratorService.ts GraphWritebackService.ts GraphWritebackAuditLog.ts ActionDispatcherService.ts SessionIndexService.ts

PermissionGateService.ts 的决策结构包含：

allowed missing granted required decisionId whyDenied

并会写入 PermissionDecisionAuditLog。

MaterializationOrchestratorService.ts 的结果结构包含：

sourceObjectSetId targetObjectSetId itemCount skipped reason

并记录：

actorUserId intentId idempotencyKey planId decisionId

GraphWritebackService.ts 涉及：

GraphWritebackEvent GraphWritebackAuditLog approve apply consumed writeback

ActionDispatcherService.ts 的注释更直接：

Actions v1 统一执行入口。仅允许 EXECUTOR_WHITELIST 中注册的内建执行器，禁止动态加载任意实现文件。全链路：RBAC → schema 校验 → 执行 → ActionLog → 幂等缓存。拒绝也落审计。

它注册的内建执行器包括：

capability_writeback graph_writeback_create graph_writeback_approve graph_writeback_apply procurement_sales_executor

这部分证据说明：所谓“智能体主链”，不是简单多个角色同时聊天，而是动作入口、权限、schema、白名单、日志、幂等、回写共同约束起来的工程链路。

图2｜证据链路图

图5｜代码证据地图

03 / QUESTION ONE 各阶段输入和输出到底支持什么

对方第一个问题问的是“各阶段输入和输出大概支持哪些类型”。这个问题非常重要，因为输入输出决定了系统适用边界。

从当前证据看，可以把天润聚粮系统拆成四个阶段。

阶段 A：业务系统事实层

这一层的输入不是提示词，而是企业系统中已经存在的事实资产。

输入类型包括：

• 业务对象：采购、销售、库存、财务、主数据；

• 流程与单据：采购订单、销售订单、入库、出库、应收应付、付款、报表；

• 权限与组织：角色、权限点、审批、流程控制；

• 数据资产：业务数据库、表、字段、文件报表、缓存、会话；

• 系统资产：前端页面、后端服务、接口、控制器、实体模型、配置。

代码层面，ArchitectureConnector 读取业务架构表；BackendCodeConnector 读取后端代码；DatabaseConnector 读取 TypeORM metadata 和数据库结构。

输出类型包括：

• BusinessDomain

• BusinessActivity

• BusinessTask

• BusinessComponent

• DataEntity

• ApplicationService

• SecurityControl

• Module

• Controller

• Service

• Entity

• Route

• Table

• Column

• Permission

这一层的价值，是把企业系统中的“原始事实”抽出来。它不是 AI 判断，而是 AI 判断之前的事实底座。

阶段 B：语义图连接器层

连接器层吃进去的是不同来源的系统资产，吐出来的是标准化的节点、边和来源引用。

输入类型包括：

• 业务架构表；

• 后端代码；

• Controller / Service / Entity；

• API Route；

• TypeORM metadata；

• 数据库表和字段；

• Schema Registry；

• 推理函数目录；

• 权限和规则配置；

• 会话产物和动作定义。

输出类型包括：

• RawNode

• RawEdge

• RawSourceRef

• 经过转换后的 GraphNode

• GraphEdge

• GraphSourceRef

这里真正关键的是 RawSourceRef / GraphSourceRef。如果一个图节点没有来源，它就更像一个整理出来的标签；如果它能回到代码、表、字段、业务架构记录或规则配置，它才是可验证的企业事实。

阶段 C：本体论与语义图治理层

这一层吃进去的是节点、关系和来源引用，吐出来的是可查询、可治理、可审计的语义图资产。

输入类型包括：

• 图节点；

• 图关系；

• 来源引用；

• 图版本；

• 业务域扩展；

• 检索策略；

• 权限上下文。

输出类型包括：

• 图版本 GraphVersion；

• 图节点 GraphNode；

• 图关系 GraphEdge；

• 来源引用 GraphSourceRef；

• 查询计划 QueryPlan；

• 对象集 ObjectSet；

• 权限决策；

• 审计记录；

• 质量门禁结果；

• 物化结果；

• 回写事件。

如果说传统 5A 架构回答“应该是什么”，那么这一层的语义图回答“实际是什么”。更重要的是，它把“应该是什么”和“实际是什么”放在同一个可验证空间里。

阶段 D：智能体主链与执行层

智能体主链吃进去的不只是自然语言需求，而是已经经过语义约束和权限约束的工程上下文。

输入类型包括：

• 用户需求；

• 查询计划；

• 对象集；

• 图版本；

• 权限上下文；

• 方案和任务；

• 证据索引；

• 会话记录；

• 回写事件。

输出类型包括：

• 可评议方案；

• 可拆解任务；

• 业务执行结果；

• 图回写事件；

• 动作日志 ActionLog；

• 审计记录；

• 会话索引；

• 可回放的证据链。

这一层的核心不是“智能体角色很多”，而是动作入口受控、执行器白名单、权限先行、schema 校验、ActionLog、幂等缓存和回写审计。

图3｜MBSE 迁移适配图

图7｜适用边界说明

这个问题要谨慎回答。

04 / MBSE 迁移可以做，但边界必须讲清楚

我的判断是：框架路线可以迁移，但不能直接说当前企业管理本体已经完整支持 MBSE。

为什么说可以迁移？

因为 MBSE 也强依赖对象、关系、版本、来源、追踪、验证和变更影响分析。天润聚粮系统当前已经具备类似的底层机制：对象、关系、图版本、来源引用、查询、对象集、权限、质量门禁、物化、回写和动作主链。

但为什么不能直接说已经完整支持 MBSE？

因为 MBSE 的领域对象不同。MBSE 需要的是 Requirement、Function、Logical Architecture、Physical Architecture、Component、Interface、Constraint、Behavior、State Machine、Parameter、Simulation Result、TestCase、VerificationResult，以及 SysML / UML / PLM / ALM / 仿真工具资产。

当前系统代码证据显示，现有本体主要围绕企业经营、业务架构、后端代码、数据库、权限、对象集和智能体主链。它可以给 MBSE 适配提供底层路线，但不能把当前企业管理本体直接当作 MBSE 本体。

所以更准确的表述应该是：

天润聚粮系统已经具备“事实抽取—语义图—对象集—权限治理—回写—智能体主链”的可迁移框架。对于 MBSE，底层方法可复用，但需要新增 SysML / UML / PLM / ALM / 仿真 / 测试工具连接器，并建立 Requirement、Function、Component、Interface、Constraint、TestCase、VerificationResult 等领域本体和验证规则。

图9｜语义图资产准确性保障栈

这里需要单独展开。因为如果只说“我们有连接器、有语义图、有智能体”，仍然没有回答最关键的问题：这些阶段性产物凭什么是准确的？语义图里的节点、边、来源、查询结果和回写动作，如何避免变成一套看起来合理但实际上不可验证的资产？

我们的回答不能只停留在原则上，而要分成两层：一层是已经在系统中落地的质量控制机制；另一层是正在持续推进、需要客观承认边界的评测体系。

05 / QUALITY 语义图资产准确性如何保障

05.1 / 总体策略：不是让模型自己证明自己，而是用工程链路约束它

语义图资产的准确性，不应由大模型的一段解释来背书。更可靠的策略是：

• 输入要来自真实系统资产，而不是凭空生成；

• 抽取过程要留下来源引用，而不是只有节点名称；

• 转换过程要做合同校验，而不是只看是否能写入数据库；

• 图版本要经过质量门禁，而不是每次构建都默认可发布；

• 语义查询要跑评测集，而不是只靠人工试几个问题；

• 智能体要做有图 / 无图对比，证明图资产确实提升了回答和执行质量；

• 回写和执行要有权限、schema、ActionLog、幂等和审计，避免错误结果直接进入生产链路。

这套策略的核心是：把准确性拆成可观测、可测试、可回溯、可阻断的工程指标。

05.2 / 输入事实：连接器扫描真实代码、架构表和数据库

在第一层，准确性来自输入来源。当前系统中已经有多类连接器：

ArchitectureConnector BackendCodeConnector DatabaseConnector SchemaRegistryAssetConnector ReasoningFunctionConnector

它们的职责不是让模型“理解一下系统”，而是从真实系统资产中抽取事实。

代码证据包括：

ArchitectureConnector：从 business_activities、business_tasks、business_domains 等业务架构表提取节点 BackendCodeConnector：使用 ts-morph 解析装饰器，提取 Module、Controller、Service、Entity、Route DatabaseConnector：从 TypeORM metadata 提取 Table、Column 节点和关系边

这意味着：业务活动、业务任务、服务、接口、表、字段这些基础对象，不是模型临时编出来的，而是从架构表、代码和数据库结构中抽出来的。

当然，这里也要承认边界：连接器只能保证“从已接入来源抽取事实”，不能保证未接入系统、未登记规则、未纳入连接器覆盖范围的事实天然进入图中。 所以新领域、新工具链、新数据源进入时，必须新增连接器或扩展抽取规则。

05.3 / 转换产物：DataContractValidator 做最低数据合同校验

抽取之后，系统不是直接把所有结果都当成高质量图资产。DataContractValidator.ts 明确承担“最低数据合同”的角色。

代码注释写得很直接：

用途：验证构建的图是否满足“能回答”的最低数据合同

它检查的内容包括：

Service 是否有 business_domain Service 是否有 file_path / filePath Service 是否至少有 1 条 sourceRefs Route 是否有 path / route Route 是否有 method Route 是否至少有 1 条 sourceRefs BusinessDomain 是否有 domain_key BELONGS_TO_DOMAIN 边数量

也就是说，系统不是只问“有没有 Service 节点”，还要问：这个 Service 是否知道业务域，是否能回到文件路径，是否有来源引用。Route 也不是只有名字就够，还要有路径、方法和来源。

这一层解决的是“结构正确性”和“可回答性”的底线问题。

05.4 / 语义图资产的正确性：GraphSourceRef 与 refCoverage 门禁

语义图最容易出问题的地方，是图上节点和边看起来都对，但无法追溯来源。为了解决这个问题，系统把 GraphSourceRef 作为核心资产之一。

在 LoadStage.ts 里，存在明确的证据链覆盖率护栏：

证据链覆盖率强制护栏对每个 node.stable_id / edge.stable_id，至少存在 1 条 graph_source_ref nodeRefCoverage=1 edgeRefCoverage=1 sourceRefInvalidRate=0

并且这段代码还客观注明：

该护栏用于满足 strict required 的可追溯性最低保障不是“最佳证据” 后续仍可逐类边升级为 file / line / db 等更强证据

这句话很重要。它说明我们没有把最低可追溯保障包装成最终答案。system_generated 类型引用可以保证图资产至少可被追踪和审计，但它不等于每个节点、每条边都已经拥有最强来源证据。后续仍要把更多来源升级为代码行号、数据库对象、接口、文档、规则记录等强证据。

05.5 / 图版本发布：GraphQualityGateService 做质量门禁

在图版本层，系统有 GraphQualityGateService.ts。它不是口号，而是有明确指标和阈值。

代码中默认阈值包括：

GRAPH_QUALITY_MIN_REF_COVERAGE 默认 0.8 GRAPH_QUALITY_MAX_NODE_DELTA_RATIO 默认 0.2 GRAPH_QUALITY_MIN_SERVICE_DOMAIN_COVERAGE 默认 0.6 GRAPH_QUALITY_MIN_BELONGS_TO_DOMAIN_EDGE_COUNT 默认 1 GRAPH_QUALITY_FAIL_ON_BREACH 可配置

门禁计算的指标包括：

refCoverage refCoverageByNode refCoverageByEdge nodeDeltaRatio serviceDomainCoverage belongsToDomainEdgeCount

LoadStage.ts 中还有一个关键实现细节：质量门禁不是在写库之前用临时数据随便判断，而是在 refCoverage 和 businessDomainStats 基于真实写入数据计算后执行。

代码注释写明：

质量门禁必须在 refCoverage 与 businessDomainStats 都已基于真实写入数据计算后执行。 GraphBuildPipeline 不再用未计算的 refCoverage 零值提前生成门禁结论。

这说明质量门禁不是装饰性指标，而是进入图版本状态流转：通过、警告或失败，并写入 build_meta.qualityGate。

这里也要客观说明：当前代码中 GRAPH_QUALITY_FAIL_ON_BREACH 可配置。如果它为 false，低于阈值可能以 warning 方式记录，版本仍可 ready。这个设计适合研发期快速迭代，但正式生产发布时，应把关键门禁设置成 fail-fast，避免低质量图版本被默认消费。

05.6 / 版本稳定性：sourceFingerprint、build_meta 和 latest ready

语义图资产不仅要单次构建正确，还要保证版本之间稳定可比较。

GraphVersion.ts 中的 build_meta 已经预留并记录：

totalNodes totalEdges typeCoverage refCoverage buildTime sourceFingerprintParts graphFingerprint qualityGate evidenceMetadata connectorStats sourceRefDistribution

LoadStage.ts 也已经把 sourceFingerprint 作为参数写入 graph_version.fingerprint，不再只用图统计指纹。

相关设计文档中进一步明确：

graph_version.fingerprint 必须稳定代表 source fingerprint 图内容指纹 graphFingerprint 只能作为 build_meta.graphFingerprint 不得混用

这说明系统已经在区分“源输入是否变化”和“图结果统计是否变化”。这对准确性很重要：如果源没有变，重复构建应当具备幂等性；如果源变了，新版本应能解释变化来自哪里。

但这里也要承认：SourceFingerprintService / 增量构建 / 并发锁 / CI 脚本等内容，有些在实施清单里仍属于持续固化事项。更准确的表述是：source fingerprint 语义已进入链路和实体设计，但这不等于所有增量治理能力已经完全闭环。

05.7 / 查询准确性：SemanticEvalCase 与 SemanticEvalRunnerService

语义图真正有没有用，不能只看图构建质量，还要看它能否支撑查询和分析。因此系统里已经有评测用例表和评测运行器。

SemanticEvalCase.ts 的注释是：

评测问题集实体用途：存储语义查询评测用例

字段包括：

suite question expected_types expected_domain_key min_citations enabled

SemanticEvalCaseResult.ts 用于记录单用例运行结果：

run_id case_id passed latency_ms detail created_at

SemanticEvalRunnerService.ts 的职责写得很清楚：

从 semantic_eval_case 读取问题对指定 graphRef 执行查询汇总指标：TypeHitRate、CitationsRate、AbstainRate、Latency

其中指标含义是：

TypeHitRate：TopK 中目标类型占比 CitationsRate：citations >= min_citations 的比例 AbstainRate：触发缺口诊断 / 拒答的比例 Latency：平均耗时

这说明系统已经有“评测集—运行—指标—结果记录”的基础结构。它可以承载我们说的黄金测试集：把典型业务问题、期望命中的节点类型、最少引用数、领域键等固化为 semantic_eval_case，每次构建或发布前跑回归。

05.8 / 跑分证据与指标解释：source-ref-full-lift-c4-full-v1

如何读这组跑分：指标不是堆数字，而是对应系统能力边界

这组跑分可以分成两类：一类看语义图查询是否稳定，另一类看有图方案相对无图 baseline 是否真的带来增益。前者关注意图、对象、字段、路径、来源引用和反向误路由；后者关注真实智能体任务质量是否提升。

本批 high-entropy real-agent admission 覆盖 300 对用例、600 次计划运行，completedRuns=600、completePairCount=300。汇总口径是先对每个 paired case 分别计算有图方案得分和 baseline 得分，再取平均：

graphScoreAvg = Σ graphScoreᵢ / N baselineScoreAvg = Σ baselineScoreᵢ / N deltaLiftAvg = graphScoreAvg − baselineScoreAvg

代入当前批次：0.5786 − 0.4538 = 0.1248。也就是说，有图方案相对 baseline 平均提升 12.48 个百分点。这个值说明语义图带来了明确增益；但 graphScoreAvg=0.5786 也提醒我们，绝对完成质量还需要继续靠图谱覆盖、工具调用、证据拼接、任务规划和答案表达来推高。

05.9 / 有图 / 无图对比：应该如何评，不应只看“回答像不像”

对于各智能体的有图 / 无图对比测试，不能只靠主观感觉“有图回答更专业”。更合理的评分维度应该包括：

有图 / 无图对比的重点，不是证明“有图一定更会写”，而是证明：有图时，智能体能更稳定地命中真实对象、引用证据、识别边界、形成可审计动作；无图时，它更容易停留在泛化解释。

这部分也需要客观表达：现有系统已经有 SemanticEvalRunnerService 的指标框架，能够支撑这种对比；但如果要严谨发布“有图提升百分比”，还需要沉淀固定 suite、固定模型、固定问题集、固定评分器和多轮运行结果，不能凭个别样例下结论。

05.10 / 各阶段产物如何把控：从“能生成”到“能验收”

把上面的机制落回各阶段，可以得到一张更清晰的质量控制表。

所以，对“如何保证准确性”的最终回答应该是：我们不是靠单点模型判断保证准确，而是把输入来源、转换契约、来源引用、质量门禁、语义评测、权限审计和回写闭环串成一套质量保障体系。已经落地的部分，要明确说清楚；仍在建设的部分，也要作为边界讲清楚。

图10｜评测与测试矩阵

06 / QUESTION TWO 创新点不是模块拼接，而是机制闭环

对方第二个问题更关键：如果只是宏观上把业务系统、语义图、本体论、智能体串起来，看上去像工程实现。真正的创新点，应该来自内部机制。

从现有代码证据看，系统有效性至少来自六个机制。

06.1 / 多源连接器保证事实不是凭空生成

系统中存在多个连接器：ArchitectureConnector、BackendCodeConnector、DatabaseConnector、SchemaRegistryAssetConnector、ReasoningFunctionConnector。它们分别抽取业务架构、后端代码、数据库结构、Schema 资产和推理函数资产。

这意味着语义图不是靠人工画出来，也不是让模型根据文字描述生成出来，而是从系统资产里抽取出来。

06.2 / 设计时事实与运行时事实可以映射

传统 5A 架构数据里有业务领域、业务活动、业务任务、业务组件、数据实体、应用服务、安全控制等。代码和数据库侧则有 Route、Service、Controller、Entity、Table、Column、Permission 等。

真正有价值的不是两边各自存在，而是它们之间可以建立映射关系：

BusinessActivity → Service BusinessTask → Route DataEntity → Table / Entity ApplicationService → Service SecurityControl → Permission / Guard

这种映射可以回答架构设计是否落地、业务任务由哪些接口支撑、数据实体对应哪些表、安全控制是否存在真实权限点等问题。

06.3 / 来源引用和质量门禁避免概念图失真

GraphSourceRef 和 GraphQualityGateService 是关键。LoadStage.ts 中出现了“证据链覆盖率强制护栏”，要求：

nodeRefCoverage=1 edgeRefCoverage=1 sourceRefInvalidRate=0

如果没有这一层，语义图容易变成“整理得很漂亮的概念图”。有了这一层，语义图才可能成为“可审计的事实图”。

06.4 / 查询计划和对象集让语义图变成可执行语义

QueryPlannerService 负责把自然语言问题转成 QueryPlan。这个计划里有 intent、domain、expandedTerms、policy、search types、sourceEntityTypes、targetEntityTypes、businessModules、metrics、dimensions 和 filters。

ObjectSetQueryService 再把查询落成 search_nodes、expand_graph、ObjectSet 和 ObjectSetRegistry。

这说明系统目标不是让模型直接生成一段解释，而是把问题转成查询计划、图遍历和对象集操作。对象集可以被注册、复用、物化、审计、回写，让一次查询结果成为后续治理和执行的输入。

06.5 / 权限门禁和审计让 AI 进入企业治理体系

PermissionGateService 会解析权限，计算 required、granted、missing、allowed、decisionId、whyDenied，并写入 PermissionDecisionAuditLog。

这说明系统不是把 AI 查询当成普通搜索，而是把它放进企业权限体系里。当 AI 开始访问业务对象、架构图、对象集、字段、权限和执行动作时，权限审计不是附加功能，而是基础能力。

06.6 / 物化、回写和动作派发把智能体约束在主链里

MaterializationOrchestratorService 负责对象集物化，记录 sourceObjectSetId、targetObjectSetId、itemCount、actorUserId、intentId、planId、decisionId、idempotencyKey。

GraphWritebackService 负责图回写事件，涉及 approve、apply、consumed 等状态。

ActionDispatcherService 是智能体动作统一入口。它明确要求：仅允许白名单执行器，全链路经过 RBAC、schema 校验、执行、ActionLog 和幂等缓存，拒绝也落审计。

这说明智能体不是绕过治理体系的自由执行器，而是被纳入动作白名单、权限、schema、日志、幂等和回写机制中。

图4｜有效性保障闭环

图6｜服务链路图

07 / INNOVATION 真正值得强调的创新点在哪里

如果只看宏观框架，系统容易被理解成：业务系统一层、语义图一层、智能体一层。这当然是工程实现，但还不能充分体现创新点。

真正值得强调的创新点，应该落在这几个地方。

07.1 / 把企业已有系统反向编译成语义图

很多系统是先设计一个本体，再让业务去填。本系统更有价值的路线是：从已有业务架构表、代码、数据库、权限、Schema 和函数资产中抽取事实，把企业系统反向编译成语义图。

这更贴近真实企业。因为企业不是一张白纸，企业里已经有系统、代码、表、流程和历史包袱。

07.2 / 把设计态和实现态放到同一个验证空间

5A 架构、业务架构表回答的是设计态；代码、接口、数据库、权限回答的是实现态。如果两者进入同一张图，就可以做一致性检查、缺口识别和影响分析。

这也是企业架构治理从“文档管理”走向“事实校验”的关键。

07.3 / 把语义图从展示图推进到执行图

如果语义图只是展示节点和关系，它只能做说明。如果它可以产生 QueryPlan、ObjectSet、权限决策、物化结果和回写事件，它就变成了可执行语义层。

这一步决定了系统能不能从“看见关系”走向“使用关系”。

07.4 / 把智能体纳入企业动作治理

智能体真正进入企业系统后，最危险的不是不会回答，而是能执行但不可控。

所以 ActionDispatcherService 的白名单、RBAC、schema 校验、ActionLog、幂等缓存和拒绝审计，是非常关键的工程约束。它把智能体从“会话角色”变成“受控执行单元”。

07.5 / 诚实地承认边界，而不是把路线说成万能

对 MBSE 的回答就体现了这一点。系统底层框架可迁移，但 MBSE 需要专门的领域本体、工具连接器和验证规则。这样的表述反而更专业，因为它区分了“底层机制”和“领域覆盖”。

08 / MATRIX 一张表总结输入、输出、证据和边界

图8｜两类事实同图治理

09 / BOUNDARY 从追问到系统边界：这套系统到底证明了什么

这两个追问最终指向同一个核心：企业 AI 的能力边界，不应该靠口头承诺来证明，而应该靠输入、输出、证据、权限、评测和执行闭环来证明。

从现有系统证据看，天润聚粮数字企业管理系统已经形成了比较清晰的四层链路。业务事实层接收采购、销售、库存、财务、主数据、流程、单据、权限、代码和数据表等输入，输出业务领域、业务活动、业务任务、数据实体、应用服务、安全控制等事实对象。连接器层通过 ArchitectureConnector、BackendCodeConnector、DatabaseConnector 等抽取业务架构、后端代码和数据库结构，形成 RawNode、RawEdge、RawSourceRef。语义治理层将节点、边和来源引用组织成 GraphVersion、GraphNode、GraphEdge、GraphSourceRef，并进一步进入 QueryPlan、ObjectSet、权限决策、质量门禁和回写事件。智能体主链则基于需求、对象集、证据索引和权限上下文，生成方案、任务、ActionLog、物化结果和回写动作。

这意味着，系统不是把“AI 对话能力”直接包装成企业管理能力，而是先把企业对象、关系、来源和权限整理成可追溯的事实网络，再让 AI 在这张网络上分析和执行。这个差异很关键：前者容易停留在表达，后者才能进入治理。

对于 MBSE 迁移，结论也应保持清晰：底层机制具备迁移基础，但不能直接等同于已经完整支持 MBSE。MBSE 同样依赖对象、关系、版本、来源、追踪、验证和变更影响分析，因此图版本、来源引用、对象集、质量门禁、权限审计、物化和回写这些底层机制可以复用；但真正适配时，还需要新增 SysML / UML / PLM / ALM / 仿真 / 测试等工具连接器，并建立 Requirement、Function、Component、Interface、Constraint、TestCase、VerificationResult 等领域本体和验证规则。

模块有效性则来自多层约束，而不是单个算法点。多源连接器保证事实不是凭空生成；设计态事实与运行态事实映射，把“应该是什么”和“实际是什么”放到同一张图上；GraphSourceRef 和 GraphQualityGateService 约束来源引用和证据链覆盖；QueryPlannerService、ObjectSetQueryService 和 ObjectSetRegistryService 把问题转成查询计划和对象集；PermissionGateService 与 PermissionDecisionAuditLog 把查询纳入权限和审计；MaterializationOrchestratorService、GraphWritebackService 和 ActionDispatcherService 负责物化、回写与动作派发，并通过白名单、RBAC、schema 校验、ActionLog 和幂等机制控制执行风险。

最近补充的质量与评测证据，也让这套说明更具体。当前证据中已经出现两类可量化口径：一类是图质量门禁，明确要求 nodeRefCoverage=1、edgeRefCoverage=1、sourceRefInvalidRate=0，避免新图版本在来源覆盖上回退；另一类是语义评测运行器，从 semantic_eval_case 读取问题，对指定 graphRef 执行查询，并汇总 TypeHitRate、CitationsRate、AbstainRate、Latency 等指标。也就是说，系统已经不只是“能构图、能查询”，而是在往“能回归、能比较、能解释质量变化”的方向收敛。

更稳妥的评价是：这套系统的创新点不在于把几个模块串起来，而在于把企业已有的业务架构、代码、接口、数据库、权限、规则和会话产物，抽取成带来源引用的语义图；再通过对象集、查询计划、权限门禁、质量门禁、物化、回写和智能体动作主链，把 AI 的分析和执行约束在同一套事实、权限、证据和治理流程里。

这也是它和普通企业知识库、普通流程自动化、普通聊天助手之间最本质的区别：不是多回答几个问题，而是让每一次回答、每一次对象命中、每一次引用、每一次动作，都尽量落回企业自己的事实网络和治理链路中。

10 / NEXT STEP 业务侧智能体建设：语义图正在进入 Team OS 运行底座

业务侧智能体建设已经围绕 Team OS 执行后端、通道控制面、运行实例、Actions v1 和语义图写回链路形成运行底座。它不是一个孤立聊天入口，而是由运行对象、控制面、记忆、通道和审计组成的系统。

本地代码中，执行运行、worker、call span、blueprint gate、状态机、reconcile、prompt assembly、operations closure、parallel worker/task/handoff/integration、通道控制、运行实例、Team OS memory、handoff envelope、移动入口和 runtime insight 已经进入同一组后端模块。

控制面 API 也已经出现：flows/runs、execution/runs、operations-closure、channel/events、channel/bindings、mobile/dispatch、mobile/actions、runtime/snapshot、guanyin/runtime-insight 等接口，把“谁触发、由哪个 agent 承接、绑定到哪个会话模板、执行到哪一步、产生哪些回执”变成可查询对象。

Actions v1 侧，ActionDispatcherService 已经把能力写回、图写回创建/审批/应用、procurement_sales_executor 纳入统一执行入口，并将 create_purchase_order、create_sales_order、purchase_inbound、verify_sales_stock、sales_outbound 等采购、销售、库存动作放到白名单、权限、schema、ActionLog 和幂等链路中。

语义图在这里的作用，是把智能体执行从“会话判断”拉回到企业事实网络。graphRef、graphVersionId、objectSetId、sourceRef、writebackEventId、ActionLog、SessionIndex 等锚点，正在把每次执行绑定到图版本、对象集、来源证据、动作日志和会话索引。

后续优化方向

• 运行指标接入现有评测体系：新增 ActionSuccessRate、GuardRejectPrecision、HumanConfirmRate、RollbackRate、IdempotencyHitRate、ProvenanceCompleteness、RunClosureRate 等指标。

• 黄金任务集围绕采购、销售、库存动作沉淀：覆盖正常采购入库、销售订单库存不足、重复提交幂等、未授权执行、高风险动作人工确认、执行失败后的回滚或补偿建议。

• Team OS 运行控制面与语义图版本绑定：每个 run 沉淀 runId、agentId、bindingId、graphVersionId、objectSetId、actionType、decisionId、writebackEventId、sourceRefs、closureStatus。

• 补齐运行统计、黄金任务集和闭环指标曲线：避免只证明“能执行”，而要证明“可控、可回放、可回归、可持续改进”。

11 / FINAL NOTE 边界讲清楚，系统才可信

这次追问最有价值的地方，是它提醒我们：介绍一个企业 AI 系统，不能只讲宏观模块，也不能只讲“我们已经打通了流程”。

打通流程只是开始。更重要的是：

• 每个阶段的输入输出是什么；

• 哪些输入来自真实系统，哪些来自人工配置；

• 输出能不能回到来源；

• 设计态和实现态能不能对齐；