前两篇里，我先解释了什么是本体，又拆解了 Palantir 怎样用本体连接数据、逻辑、行动和安全。
第三篇，我想直接把我们自己的系统摆出来。
这套系统在企业里的位置，可以用一张图看懂。
数据库、文档、表格和外部接口经过本体建设与治理，形成一份实时本体，再由业务人员、只读 Agent 和其他业务系统共同使用。
我们要解决的问题很具体。企业已经有数据库、制度文件和业务系统，模型也能做搜索和问答，可它仍然不知道“这条记录代表谁”“两张表里的对象是不是同一个”“一条规则适用于哪些对象”“这次判断用了什么证据”。
这套系统的任务，就是补上这层业务认知。
先看整体：系统分成四层
总体架构可分为业务数据来源、本体建设与治理、实时本体、业务智能体与应用四层。
最左边是企业已经存在的数据。它可以来自 MySQL、PostgreSQL 等业务数据库，也可以来自制度文件、操作手册、Excel 台账、外部 API 和 MCP。已有领域本体时，还可以导入可复用的本体资产。
第二层负责把这些材料变成结构化业务知识。文档会经过类识别、结构识别和实体识别；数据库会经过表语义、字段语义和跨表关系分析；建设人员也可以在管理界面中维护类、属性、关系和自然语言规则。
第三层是整个系统的核心：一份实时本体。这里保存业务对象类型、具体实体、属性、关系和规则，同时维护稳定对象身份与混合检索索引。
最右边是使用这份本体的人和系统。业务 Agent 可以定位对象、沿关系调查并读取规则；建设人员可以通过本体星图和管理界面查看、维护资产；其他平台也可以通过 API 或 MCP 使用同一份业务语义和调查能力。
四层下面还有一条共同的治理底座，包括身份权限、只读数据源、操作审计、索引状态、失败回滚和运行状态检查。模型负责理解语义和规划调查，权限、写入、索引切换和外部查询限制仍由确定性服务控制。
一份文档或一张表，怎样进入本体
系统里的第一条数据流程，是把业务材料变成 Agent 能使用的知识：
注册来源 → 抽取或映射 → 质量检查 → 写入实时本体 → 同步检索索引
文档和表格会先进入本体生成流程。系统从材料中识别业务对象类型，再补齐属性、关系和具体实体。数据库则先识别每张表代表什么，再把源字段绑定到正式属性，用主键或组合字段确认对象身份，用外键或复合字段建立关系。
本体生成支持上传文档、扫描数据库表和连接外部数据库。
这里的大模型有明确分工：它负责理解陌生文档和表结构，系统负责限定输出协议、证据范围和关系类型。模型可以提出语义判断，后端仍要检查对象身份、引用关系和数据质量。
通过检查以后，类、属性、实体、关系和规则会进入当前项目的一份实时本体。系统同时构建精确检索、关键词检索和向量检索索引。写入、质量检查和索引更新属于同一次操作；任何一步失败，数据和活动索引都会恢复到修改前的可用状态。
这带来一个直接结果：Agent 不会在“本体已经改了、索引还没有改完”的中间状态下工作。
类、实体、关系、规则、轻量实体索引和数据映射统一放在本地资产中。
本体星图：先看业务世界的结构，再看具体对象
本体进入系统以后，并不是只留在清单和数据库表里。我们做了一个“本体星图”，用来观察这套业务世界是怎样组成的。
以“高速公路路段”为中心展开的类图谱。左侧可以切换类图谱、实体图谱、邻域范围和展开深度，底部可以直接向当前本体提问。
本体星图有两种视角。
类图谱展示的是业务世界的骨架。例如，“交通事故”可以“发生于”高速公路路段；路段可以“被监控于”摄像头、“关联”出入口、“由”管养单位管理，还可以关联医疗机构、救援站和分流路线。点击一个类，右侧会同时显示它的属性定义、允许建立的类关系、适用规则和相关实体。
实体图谱展示的是这套骨架在当前业务中的具体落点。“交通事故”这个类下面，可以有“青云高速 K50+200 北向事故”这个实体；“道路救援站”下面，可以有“青云重型救援站”和“云溪轻型救援点”。类关系规定哪些连接在语义上成立，实体关系记录这一次具体连接到了谁。
它与常见知识图谱展示页的关键差异，来自图背后连接的内容。常见图谱页面主要回答“谁和谁有关系”；本体星图还要同时回答“它们分别属于哪一类”“这类对象有哪些正式属性”“允许建立什么关系”“哪些规则适用于它”，再让 Agent 以选中对象的稳定标识为起点展开调查。
因此，星图直接投影当前实时本体：类图谱负责看结构，实体图谱负责看对象和事实关系，邻域视图负责控制调查范围，节点详情和 Agent 使用的是同一份对象、关系和规则。图上的内容随着实时本体变化，事实来源始终只有当前本体这一份。
用户问一个问题，系统怎样找到答案
第二条流程从用户问题开始：
用户问题 → 定位稳定对象 → 读取属性与关系 → 调用只读数据 → 对照规则 → 返回有证据的判断
用户往往不会使用本体里的标准名称。他可能说“青云高速北向事故”，也可能少说一个字、使用别名，甚至只给出业务编号。
系统会先做精确匹配。无法唯一命中时，再并行使用关键词和向量检索，经过融合、重排和消歧，找到一个稳定对象标识。
稳定标识相当于业务对象在系统里的身份证。名称可以修改，数据库可以迁移，来源字段也可能变化；身份保持稳定后，关系、规则和历史调查仍然知道自己指向谁。
检索到对象以后，Agent 才开始读取事实。它可以查看对象属性，沿类关系和实体关系扩展有限范围的证据子图，读取自然语言规则，也可以通过受控查询取得外部数据库中的当前值。
检索分数只负责定位对象。最终结论来自对象记录、关系、规则、来源文档或授权数据库结果。这样可以避免把“语义上很相似”直接写成“业务上已经确认”。
这套系统的特点，集中在六个产品取舍上
1. 结构化数据和文档进入同一套业务语义
普通文档问答主要处理文字，企业的关键状态往往留在数据库里。我们的系统让制度文件里的规则、表结构里的属性、数据行代表的实体和跨表关系进入同一份本体。
Agent 因而可以同时回答“制度怎么规定”和“当前对象是什么状态”，也能说明两者怎样关联。
2. 业务数据留在原系统，不要求整库复制
系统会保存表与正式类、字段与正式属性之间的映射，并生成轻量实体索引。Agent 需要最新业务值时，再根据稳定主键从授权的只读数据源查询。
这种方式保留了原有业务系统的数据责任，也减少了重复存储和两边数据不同步的问题。本体保存“怎样理解这些数据”，业务数据库继续保存“当前数据是什么”。
3. 对象身份和关系可以跨来源持续使用
同一台设备可能出现在资产表、维修记录和制度文件中，名称和字段写法也可能不同。稳定对象身份把这些来源连接到同一个业务对象，类关系规定对象类型之间可以怎样关联，实体关系记录具体对象之间已经建立的联系。
这比单纯找到几段相似文字多了一步：系统知道文字和数据共同指向哪个对象，也知道这个对象与谁有关。
4. 本体写入和检索索引保持一致
本体系统每天都可能增加对象、修改属性或调整关系。系统把质量检查、正式写入、关键词索引、向量索引和活动索引切换放在同一次受控操作中。
失败时整体恢复，成功后再对外提供新状态。业务人员和 Agent 因而面对同一份当前知识。
5. 检索负责找对象，事实由权威来源提供
很多 RAG 问题出在最后一步：检索返回一段相似内容，模型顺手把它写成事实。
我们的查询流程会先从相似内容落到稳定对象，再读取对象属性、关系、规则和授权数据。检索通道临时不可用时，系统还能保留精确检索、关键词检索或结构化查询，并明确记录哪些通道发生了降级。
6. Agent 可以推理，但始终保持只读
业务 Agent 可以调查、排序、提示风险和提出建议。它没有本体新增、修改、合并或删除工具，也不能直接提交任意 SQL。
外部 OpenAPI 和 MCP 只有经过测试的只读能力可以进入工具目录。打电话、发消息、创建工单、修改业务系统状态等动作不属于当前产品权限。
这个取舍让 Agent 有能力处理复杂问题，同时让人知道它做到的是调查与建议，外部执行仍由组织的授权和审批机制负责。
一次交通事故调查，怎样用到这些能力
系统里已经有一条用于验证推理能力的完整交通事故调查记录。
问题从“青云高速 K50+200 北向发生事故”开始。用户继续追问：事故属于哪一路段？附近有哪些可用摄像头和出入口？是否应该双向封闭？救护和救援力量怎样选择？车辆往哪里分流？
这里要先说清楚：系统里没有预先写好一条“这起事故应该选择青云重型救援站”的答案，Agent 也不是从某段知识库文字里把结论抄出来。
它能够使用的，是四类彼此关联的本体内容。
第一类是类。系统知道“交通事故”“高速公路路段”“监控摄像头”“高速出入口”“医疗急救机构”“道路救援站”和“分流路线”分别是什么业务对象。
第二类是类关系。系统规定：交通事故可以通过“发生于”关联路段；路段可以通过“被监控于”“有关出入口”“医疗资源覆盖”“救援资源覆盖”“分流路线”等关系关联其他对象。类关系给 Agent 划定了可以沿哪些方向调查，而不是让模型凭语言相似度随意联想。
第三类是实体、属性和实体关系。每个实体先通过“所属类”落到正式类上，所以系统知道事故实体要使用“交通事故”的属性和规则，而救援站实体要使用“道路救援站”的属性。事故实体记录了桩号 50.2 公里、北向、3 条车道受阻、疑似伤员 2 人、无危化品泄漏、影响未蔓延到对向、车辆为重型货车侧翻；它所关联的路段实体记录了单向共 4 条车道。各摄像头、出入口、医疗机构、救援站和分流路线也分别拥有自己的位置、在线状态、到场时间、能力或通行状态。它们再通过实体关系连接到具体路段。
第四类是挂在“交通事故”类上的规则。例如：受阻车道比例达到 75% 时，建议临时封闭事故方向；只有发生危化品泄漏，或事故影响已经蔓延到对向时，才建议双向封闭；重型货车侧翻时，应选择具备重型拖救能力且当前可用的救援站，不能只比较到场时间；作出处置建议前，要核查上下游 3 公里内的在线摄像头，并且只选状态可用的分流路线。
把它们连起来，Agent 实际走的是这样一条推理链：
事故实体 → 发生于 → 路段实体 → 摄像头、出入口、责任单位、医疗、救援和分流候选
事故所属类 → 适用规则 → 把事故属性代入条件 → 筛选候选实体 → 形成结论和排除理由
第一步，Agent 先把用户说的事故定位到稳定实体 INC-QY-20260811-001，再沿实体关系 occurred_on 找到“青云高速北向 K42—K58 路段”。后续调查都从这个锚点向外展开，不在整个知识空间里漫无目的地搜索。
第二步，Agent 从路段实体沿关系取回候选对象。沿 monitored_by 找到 K49+800、K51+000 和 K56+800 三个摄像头；沿 has_access 找到 K46、K55.5 和 K60 的出入口；沿 managed_by 和 jurisdiction_by 找到青云高速路产养护中心与高速交警第三大队；再沿医疗、救援和分流关系取得各自的候选实体。这次调查把扩展深度限制在两层，取得 26 个相关节点、41 条显式关系边和 6 条适用规则；这些内容组成待核验的证据子图，还不是最终答案。
第三步，Agent 把实体属性代入类规则。事故点是 K50.2，现场核查规则要求上下游 3 公里内且在线，因此 K49.8 和 K51.0 分别相距 0.4 公里和 0.8 公里，可以保留；K56.8 虽然同样与该路段有关，但相距 6.6 公里，必须排除。对于出入口，Agent 继续根据事故方向和桩号比较，选出最近的上游入口青云北收费站，以及最近的下游出口青云南互通。
封闭判断来自同样的“属性代入规则”。3 条受阻车道除以单向 4 条车道，正好达到 75%，所以触发“事故方向定向封闭阈值”，建议临时封闭北向。事故实体同时记录“无危化品泄漏”和“未蔓延到对向”，没有满足“双向封闭限制”的任一条件，因此不能仅因为发生了重型货车侧翻就建议双向封闭。
救援选择也不是按名称判断“轻型”或“重型”。事故实体的“车辆类型=重型货车侧翻”触发了“重型车辆救援选择”规则；Agent 随后比较两个 served_by_rescue 候选的类型化属性。云溪轻型救援点预计 6 分钟到场，但“重型拖救能力=false”；青云重型救援站预计 8 分钟到场，“重型拖救能力=true”且当前可用。规则先约束能力和状态，再比较时间，因此最终选择后者。医疗资源同理：7 分钟可到的社区医院不具备创伤急救能力，12 分钟可到的创伤急救中心才满足本次规则。
分流路线则来自 alternative_route 关系。G312 东线的状态为可用，剩余通行能力为每小时 1200 辆；云溪连接线处于施工中，状态不可用，剩余通行能力为 0。规则要求只选可用路线，因此前者保留，后者排除。
Agent 沿路段、设施、责任单位和规则完成调查，并在答案中写明执行边界。
这个案例体现了本体推理的核心：系统并不保存一份现成答案，而是保存业务世界的类型、对象、关系、属性和规则。Agent 每次以具体对象为锚点，取得有限范围的证据子图，在本轮调查中完成多跳关联、规则命中、候选比较和排除说明。对象和规则仍保留来源材料，便于继续核验；来源材料承担的是证据追溯，而不是提供一条预先写好的处置结论。推导出的判断不会反过来自动写入本体。
页面中的答案还明确写着：系统给出的是联络和处置建议，没有实际打电话、发消息、创建工单、封路或调度资源。
这套本体怎样接入其他系统
目前系统提供三类连接方式。
外部数据库通过只读连接和类级数据映射接入。模型提交结构化查询计划，后端检查数据源、表、字段和权限，再生成参数化 SQL，并限制执行时间、返回行数和结果大小。
OpenAPI 和 MCP 工具进入统一目录，继续接受权限、Schema、超时和审计检查。其他知识平台或业务系统也可以通过 API、MCP 调用本体检索和调查能力。
内置工具、OpenAPI 和 MCP 使用同一套只读工具目录。
跨项目复用时，系统可以导出 .ontology.zip。文件携带类、属性、关系、规则、领域提示和推理 Skill；现场实体、物理表绑定、数据库凭据、业务文档、索引和会话继续留在原项目。
换句话说，系统可以迁移“这个领域应该怎样理解”，同时保留每个项目自己的数据和权限边界。
目前我们做到了哪一步
这套本地工程已经能够完成本体建设、质量检查、索引同步、图谱浏览、只读 Agent 调查和外部工具接入。本次检查中，服务监听、存活状态和就绪状态均正常，与文章主线相关的 49 项自动化测试通过。
这些结果证明当前代码、数据和页面已经形成完整流程。客户现场数据、生产部署和正式业务验收仍需要在目标环境中单独完成。
我们希望做出的产品很明确：企业原有数据继续各司其职，本体负责把它们解释成同一个业务世界，Agent 再基于这个世界调查问题。这样，本体才会从一张关系图，变成企业 AI 可以长期使用的业务认知层。