给设备智能体喂知识，常见的做法是塞一包文档：标签含义、设备耦合、操作规程、历史事故，全都混在一起，最后整体对比“有知识”和“没知识”。但一套设备系统到底该被描述到什么程度、以什么形式交给模型，此前没有被测量。这篇论文提出“本体塔”（ontology tower）：实体很少，知识很深，而且是按依赖关系算出来的层次。
窄：一座塔只描述一套设备系统
研究对象是一套低湿空气处理试验装置，由空气处理机、冷水机组和转轮除湿机作为一个单元运行。实体只有几十个测点和设定值，但每个实体都要写清：绑定到控制器的哪个地址、原始量程与单位、如何校验、由它派生出哪些量、这些派生依赖哪些假设、运行人员对它学到过什么。Brick 这类通用词表负责“命名测点”，塔则立在这些测点之上，装的是这一套系统自己的知识。
塔的层数不是人画的，也不是照物理直觉排的。节点的层级等于“从测量出发、沿已声明的依赖关系走到它的最长路径”，比它最深的父节点高一层。依赖边只在厂区自己的资料库声明了有向关系时才画，来源有三类：派生的输入、控制点与被它驱动的过程变量、机组耦合中记录的因果链。约束与协调关系（比如一个控制器对另一个的上限、分支风量的分配）保留为知识节点，不变成边；没有自然方向的关系（如守恒律）变成双向检查。42 个标签里有 33 个绑定到 PLC，12 个被声明为“被驱动”，最高的是机组温度，层级 3，经冷水设定值、供水温度、送风温度的声明链到达。
深：物理派生与运行日志
第一种加深来自物理关系：由测点算出的派生量连同其假设一起进入塔。第二种加深来自时间：运行日志里的异常、排查和纠正，一旦形成教训，就写成知识节点，挂到相关的测点或设备上。知识节点始终停在第 0 层，不参与层级计算——它增加的是“关于这个点知道什么”，而不是“这个点离测量有多远”。每次抽取塔时，都会把上次抽取之后新写的日志并进来，所以塔是演进的本体。教训只对产生它的系统有效，运行越久，塔越专属。
给智能体的不是节点和边，而是一段从塔投影出来的文本：每个传感器的身份、校验和已知故障，机组耦合与自动逻辑，知识节点，控制点的运行包络，这套装置约 45,000 字符，直接放进提示。16 个派生量及其假设保存在监测软件的计算里，因此只在塔中、不在投影中，评测测的是塔的描述性内容。
9 个任务、4 个模型测出了什么
评测是预注册的：从厂区记录回放 9 个任务，使用 4 个开放权重模型，参数量从 90 亿到约 7500 亿。只给测点名称和单位（K0 到 K1）带来最大的变化，+54.6 个百分点；再把塔的投影文本加进去（K1 到 K2），避开“最像样的误判”的比例从 0.605 升到 0.802，提升 19.8 个百分点（95% 置信区间 +3.0 至 +38.4），要素得分从 0.566 升到 0.777，优势比 5.45。
增益出现在投影文本确实写明任务所需信息的地方：三个答案被文本直接说明的任务，提升 45 至 70 个百分点；两个教训未被纳入的诊断任务，只变化 +13 和 −3 个百分点。这说明模型用的是给它的东西，没给的层次补不上。模型规模假设也未获支持：90 亿参数模型加上投影文本后得分 0.737，高于最大模型不加文本的 0.672；要素得分的增益在四个模型上都存在，但未随参数量上升。
知识的形式同样关键。运行教训写进塔、或以记录形式放进提示时会被使用；留在日志里、只通过搜索工具可达时很少被用，尽管搜索工具本身把规避率提高了 6.9 个百分点。实机运行共 14 次，61 条到达安全层的命令中有 25 条被拒绝并记录：15 条指向本次运行不允许的设定值（其中冷水设定值 11 次，厂区知识建议它与送风设定值联动调整），9 条超过累计变化上限，1 条超过单步限制；另有两类设定值本就不开放写入，在到达安全层前即被拒。14 次运行中 12 次把被控变量带入目标带，每次结束都恢复基线并回读确认。
资料来源：Narrow and Deep: An Ontology Tower as the Knowledge of an LLM Agent for an Industrial Equipment System — arXiv。本文为技术要点整理/编译，非原文全文。