动手以前，我以为本体最难的部分，是把企业里的业务内容整理成一张本体图。
本体星图把路段、摄像头、出入口、交警联络点等类节点连接起来。图为本地系统中的合成交通场景。
这张图描述的是业务世界。图上的类，用来定义“事故”“路段”“摄像头”分别是什么；实体代表某一起事故、某一段道路和某一台设备；属性记录它们的特征；关系把不同对象连接起来；规则则说明在什么条件下应该怎样判断。
当这套图能够从文档和数据库里生成，Agent 也能沿着实体关系查数据、找规则、给出判断时，我一度觉得最困难的部分已经完成了。
系统跑起来以后，我才意识到，这套能力只答完了第一张考卷。
本体还要持续找到源系统里的真实数据，连接企业里已经运行的应用和设备，让不同 Agent、不同业务应用都能围绕同一个业务对象协作。
做到这一步，难点已经从描述业务世界转向了进入真实业务。
本体先从企业自己的材料里学习业务
我们现在主要从两类材料中建设本体。
第一类是业务文档，包括制度、方案、操作手册、报告和长期积累的资料。系统从这些内容中识别业务概念、对象、关系和规则。
第二类是结构化数据库。系统读取外部数据库里的表结构和业务记录，判断一张表在业务中代表什么，每个字段表示什么，不同表之间又通过什么方式连接。
这两类材料，其实是在教系统学习这个企业自己的世界。
通用大模型对世界的理解，主要藏在训练形成的权重里。它可以根据概率猜测一张表的用途，也可以从字段名推测业务含义，但企业很难逐条检查这些理解从哪里来，更不可能直接修改权重里的某一条业务定义。
我们让大模型阅读企业自己的文档、表结构和业务记录，再把识别出的概念与定义放到模型外面，形成一套来自企业自身材料的业务认知。
在这里，一个概念可以追溯到哪份制度，一个属性可以对应到哪个数据库字段，一条关系可以说明由什么数据支持。大模型仍然负责理解材料、发现候选，但经过确认的业务定义会被保存成类、实体、属性、关系和规则，并独立于单次对话、模型或 Agent 长期存在。
当前系统可以从业务文档、数据库表和外部数据库开始学习并建设业务本体。
在第一篇《什么是本体？从认出一只猫，到读懂一张表》里，我用过一个简单的解释：一张业务表可以先理解成一个类，表中的每一行对应一个实体，字段对应实体的属性，表之间的连接对应关系。
现在，我们把这个解释做成了真实的数据映射。
轻量实体索引怎样连接真实数据
先用一张摄像头表举例。
系统确认这张表对应“监控摄像头”类，再选择设备编号作为稳定标识，选择设备名称作为展示字段，把位置、在线状态、所属路段等源字段分别映射到本体中的属性和关系。
完成映射以后，表中的每一行都会获得一个稳定的实体身份。本体只保存重新定位源记录所需的信息，经常变化的业务值继续留在原数据库。
轻量实体索引保存的是一组能够重新找到这条记录的信息：
映射实体 ID → 所属类 → 外部数据源 → 来源表 → 稳定主键 → 展示名称
例如，系统可以知道“青云高速 K50 北向摄像头”属于“监控摄像头”类，它在设备库的哪张表里，稳定主键是什么。至于在线状态、当前角度、最后心跳时间等经常变化的字段，仍然保存在摄像头业务数据库中。
系统保存字段映射和轻量实体索引，界面中的“外部数据库实时读取”表示当前业务值仍以源数据库为准。
这就是“索引”和“复制数据”的区别。
索引里的实体像一本地址簿中的联系人。地址簿保存这个人是谁、属于哪个组织、怎样找到他；他此刻正在做什么，则从权威来源读取。
一次查询通常会经历四步。
第一步，用户通过名称、编号或业务关系找到候选实体。第二步，系统从实体索引取得数据源、来源表和稳定主键。第三步，系统使用授权的只读连接回到源数据库，读取这一刻的业务字段。第四步，Agent 再把当前值与本体中的对象关系和规则放在一起判断。
假设某台摄像头刚从在线变成离线，源数据库更新记录以后，下一次查询读到的就是离线状态。普通状态字段变化时，系统直接回源取得新值，实体身份和本体结构保持稳定。
但如果新增或删除了一台设备，主键发生变化，表结构改变，或者映射规则调整，实体身份和读取路径就可能受到影响。这些变化仍然需要同步索引并重新校验。
因此，“轻量”指的是只保存稳定身份和数据地址，把大量、易变的业务值留在原来的系统里。新增记录、主键和表结构等变化，则通过索引同步与映射校验处理。
这就是我所说的“本体读懂了业务数据”：它识别出表里的业务对象，并且始终知道去哪里取得这些对象的当前状态。
同样是本体，建设起点可以不同
目前公开的很多本体方案，更接近 Palantir 式的产品表达：先把多源数据加工成本体对象，再把工作流、Agent、Skill 和外部工具编排成一套应用。用户可以在界面里完成选择、推演、确认和决策。
这类方案通常从应用和决策流程出发，把本体放进一条完整的业务运行链。
这是一条成立的路线。它的重点，是尽快让用户在一个完整应用里看见流程怎样运行、决策怎样产生、动作怎样执行。
我们的建设起点不同。
我们先从企业自己的业务材料和源数据库出发，把已经确认的概念、实体身份、关系、规则和数据地址保存下来。当前数据继续留在源系统，轻量实体索引负责把业务语义与真实记录持续连接，再由不同业务应用和 Agent 使用这套坐标。
我们的当前重点，是先建立可复用的业务坐标，再向上支撑应用和 Agent。
如果一定要用一句话概括两者的区别，我会这样说：
一类方案先把本体做成决策应用的运行底座；我们先把本体做成跨应用复用的业务坐标。
两条路线可以接在一起。工作流、决策界面和外部动作，最后也可以建立在我们的本体之上。我们的工程顺序是先把业务定义放到模型权重之外，让实体持续指向源系统里的真实记录，之后再接应用。
这套做法可以进一步概括为：
语义进入本体，数据留在源系统，实体索引把两边持续连起来。
本体本身就是业务的连接器
我现在更愿意把本体定义成一个连接器。
这里的连接发生在业务语义层。企业上下左右的系统使用同一套业务对象、关系和规则，具体网络请求仍由原有接口或 MCP 连接器完成。
向下，本体连接业务文档、知识库和结构化数据库。
业务文档告诉系统，一个概念怎样定义、制度怎样要求、什么条件对应什么规则。结构化数据库提供具体对象和不断变化的当前状态。轻量实体索引把两者接在一起，让抽象的“摄像头”类能够对应到设备库里某一台真实摄像头。
横向，本体需要连接已经存在的业务系统。
OA 系统里可能有组织和审批，指挥决策系统里有事件与处置任务，摄像头系统里有设备和画面，工单与调度系统负责把决定变成行动。这些系统继续承担原来的业务职责。本体要知道它们分别掌握哪些对象、使用什么标识、彼此是什么关系，以及执行结果应该关联回哪个业务事件。
向上，本体连接用户业务应用、Agent 连接器和各种 Agent。
同一个事故可以被指挥大屏使用，也可以被调查 Agent、报告 Agent 和处置 Agent 使用。它们共同读取已经确认的业务坐标，省去在各自 Prompt 和代码里重复维护“事故、路段、摄像头和责任单位是什么关系”。
本体向下连接业务知识和数据，横向连接业务系统，向上服务应用与各种 Agent。
还是看高速公路事故。事故记录来自事件平台，摄像头属于视频系统，车流与收费站状态来自交通业务系统，处置规范在知识库里，告警、消息、工单和调度又各有自己的接口。
本体需要先把“同一起事故”周围的对象和规则组织起来。打开摄像头画面、发送告警或创建工单，仍然由相应业务系统完成。
说到这里，一个更尖锐的问题就出现了：Agent 已经可以通过 MCP 调用这些系统，本体会不会多加一层？
Agent 已经能调用 MCP，为什么还需要本体？
可以先用一个不那么技术化的比喻。
Agent 像一个会办事的人，Prompt 告诉他这次要做什么，Skill 或 Workflow 是操作手册，MCP 则像一串能够打开不同业务系统的钥匙。
本体扮演的是企业共同使用的地图和地址簿：同一个对象叫什么，位于哪里，与谁有关，应该遵守什么规则，办完以后结果记到谁的名下。
假如任务是“查询设备编号 C-102 是否在线”，设备编号已经明确，数据就在一个摄像头系统里，Agent 直接调用 MCP 最简单。本体参与这次查询能够带来的收益很小。
把问题换成“某起事故附近有哪些可用摄像头，应该通知哪个单位”，任务马上多出一串业务关系。
Agent 需要先知道事件平台里的事故编号对应哪一段道路；道路在摄像头系统里使用什么编号；哪些摄像头与这个路段有关；设备的当前状态去哪里读；哪一版处置规则适用；最后形成的建议和回执应该重新挂回哪一起事故。
Agent 也能处理这些事情。团队可以把对象编号、字段映射、业务关系和判断规则写进 Prompt、Skill、Workflow 或代码里。
写到一定规模以后，每个 Agent 都会带着一份自己的对象表、关系表和规则表。修改一个业务定义，可能要同时修改多个 Prompt 和流程；换一个 Agent 或增加一个应用，又要重新复制一遍。这样做等于把本体藏进各个应用，让它变得分散、重复和难以核对。
这时，独立本体层的价值才出现：
- 同一个业务对象在多个系统里有不同名称和编号时，提供稳定身份；
- 文档规则与多个系统的当前值需要一起参与判断时，提供统一关系；
- 多个 Agent、应用和工作流需要复用业务定义时，提供共同语义；
- 一次行动需要追溯对象、依据、确认人和结果时，提供稳定归属。
对象已知、步骤固定时可以直接调用；跨系统作业时，本体先提供业务坐标，MCP 再完成具体调用。
因此，系统调用可以由 Agent 通过 MCP 直接完成。本体在调用之前提供业务对象、相关对象和规则，在调用之后承接返回结果。
MCP 解决的是“怎样进入一个系统”，本体解决的是“进入系统以后，究竟要找谁，以及这次行动属于谁”。
当前系统的业务 Agent 仍然保持只读。它已经可以查数据、找证据、做推理、给建议，还不能直接发送告警、创建工单或修改外部系统状态。所以，这套边界目前是工程判断，还需要放进真实业务链里验证。
落地应该先跑通一个最小业务单元
检验本体有没有必要，可以先选择一条足够小、能够从头到尾验收的业务链。开局覆盖全公司的对象、数据和流程，只会让第一次业务反馈来得太晚。
这个最小业务单元要写清楚：什么事件触发，需要哪些业务对象和当前数据，使用哪些关系和规则，Agent 应该形成什么判断，哪一步由谁确认，确认以后调用哪个系统，以及系统返回什么结果。
以交通事故为例，第一步可以只跑通：
事故进入 → 定位路段 → 读取摄像头和路况当前值 → 查询处置规则 → 形成建议 → 人工确认
当前系统已经能形成有证据的处置建议，外部系统行动仍是下一阶段的验证内容。
这一步稳定以后，只增加一项外部行动。例如，把确认后的建议发送到告警系统，并记录接收人、发送时间和返回结果。先验证一只“手”能不能接稳，再接工单、调度和状态回写。
同一个场景还应该同时跑两条路线。
第一条路线由 Agent 根据 Prompt 或 Skill 直接调用 MCP。第二条路线先由本体确认事故、路段、摄像头、责任单位和处置规则，再由 Agent 调用 MCP。
两条路线要用几个具体问题比较：对象有没有找错，源数据变化以后结果是否仍然正确，第二个应用能不能复用已有定义，业务人员能否追溯判断依据，执行结果能否稳定回到原事件。
只有本体在准确性、复用或追溯上带来实际改善，建设范围才值得继续扩大。它先在一个最小场景里证明价值，再把已经确认的对象、关系、规则和接口复用到下一条相邻业务链。
业务人员也在这个过程中确认每个判断分支。有效的规则继续保留，错误和例外回到本体建设流程中修正。系统所谓的“越用越好”，来自这些经过确认的真实反馈。
一套本体系统完成的是对业务世界的第一次描述。
到了落地阶段，同一个业务事件要从源数据进入，经过本体、Agent 和人的确认，调用一次真实系统，再把执行结果带回来。
先跑通这一条，再谈覆盖全业务。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。