scenario l5 / 中长期 · 科学研究侧
冶金本体与机理知识图谱
把机理模型、文献、试验数据统一到一个可推理的图谱上，让 Agent 能回答「为什么」而不只是「是多少」
数据可得性
中
所需数据是否已在手、能否直接用于建模
工程难度
中高
从可行性验证到稳定上线的工程风险
实时性要求
低
需要秒级响应，还是天级出报告
评级为面向学习者的教学性判断，用于横向比较场景特点，不构成采购或投资建议。
涉及工序 / 6 道 · 高亮项点击可跳章节
业务痛点，讲人话
这个场景跟其他十一个不一样：它不直接产生业务价值，它是让其他场景不变成烟囱的那一层。
想象一下典型的演化路径：
- 第 1 个月：检测团队做了一个标准解析 Agent，自定义了一套牌号编码
- 第 3 个月：质量团队做了溯因 Agent，用的是 MES 里的物料编码
- 第 5 个月：研发团队做了知识库 Agent，实体是从报告里抽的，又一套命名
三个都跑得不错。然后有人问："能不能让溯因 Agent 查一下这个牌号的历史研发记录？"
答案是不能——三套 ID 对不上。要打通就得做映射表，而映射表本身又会随着两边演进而腐烂。
几个月后就是三个烟囱，返工成本远高于前期投入。 这就是为什么本体必须早做。
最小可用本体：四类实体 + 三个维度
一个够用的起点大约是这样：
四类核心实体
| 实体 | 关键属性 | 谁在用 |
|---|---|---|
| 材料 / 牌号 | 成分范围、性能要求、执行标准 | 检测、研发、排程 |
| 工艺步骤 | 参数、设备、时间窗、前后序 | 溯因、排程、仿真 |
| 表征方法 | 测什么、怎么测、不确定度、依据标准 | 检测、研发、SDL |
| 标准条款 | 约束、适用条件、版本、引用关系 | 检测、标准演进 |
三个定位维度（对象-时间-空间）
生产对象（炉次、铸坯、卷）必须同时被这三个维度定位：
- 对象——哪块钢？哪一炉？
- 时间——什么时刻？哪个工序阶段？
- 空间——产线哪个位置？这块钢的哪个部位（头/中/尾、表面/心部）？
为什么本体、权限、多 Agent 是咬合的
这一点常被忽略，但它决定了架构的长期上限：
没有统一实体定义
↓
只能做目录级授权（这个库你能看，那个库你不能看）
↓
不敢开放跨部门的数据调用（粒度太粗，一开就是全开）
↓
多 Agent 跨部门协同做不成
反过来：权限要挂在实体上。有了统一的材料/工艺/表征/标准实体，才能表达"这个 Agent 可以读某牌号的成分但不能读工艺参数"这样的细粒度规则。
在有密级分类要求的场景里，这不是优化项，是准入条件。
ai engineer's view
本体 ≈ 领域的类型系统 + 外键约束
它定义什么是合法实体、实体间有哪些合法关系。没有它，每个团队都会自造一套 ID；有了它，跨系统 join 和细粒度授权才成为可能。
最小可用本体 ≈ MVP schema
先只定义四类实体和三个定位维度，随场景演进。目标不是完备，是让第一批场景的输出落到同一套 ID 上。
对象-时间-空间 ≈ 三维复合主键
缺任何一维，跨工序 join 都会退化成不可靠的模糊匹配。这是主键设计原则，不是哲学。
知识图谱 ≈ 让 Agent 能回答「为什么」
普通数据库回答「是多少」，图谱加上机理关系后能回答「为什么会这样」——这是从检索到推理的分界线。
数据长什么样
data shape / 本场景吃哪几类数据
技术报告、专利、论文、操作规程、设备手册、检修工单、报警日志
瓶颈：非结构化、密级混杂、时效性标注缺失（哪版规程还有效？）
冶金机理专业模型、CALPHAD 热力学与相图库、CFD/FEM 仿真结果、数字孪生生成数据
瓶颈：模型未工具化封装、没有统一调用接口——对 Agent 而言等于不存在
标准文本与条款、检测原始记录、判定结论、方法验证数据
瓶颈：标准版本管理、判定链的可追溯性
熔炼/热处理/轧制/等静压工艺记录、力学性能、蠕变疲劳腐蚀长周期数据、失败案例
瓶颈：无统一实体定义、散落个人手中、失败数据普遍未留存、密级分类复杂
样例结构 / 教学示意，非真实产线数据
# 最小可用本体的实例片段（教学示意）
# —— 注意所有场景都引用同一套 ID
#
Material:
id: "mat:Q355B"
aliases: ["…"] # 跨体系牌号对照
composition_spec: {C: {max: 0.20}, Mn: {max: 1.60}}
property_spec: [ref: "clause:XX-2021#yield-16mm"]
#
ProcessStep:
id: "proc:hot-rolling-F5"
type: "轧制"
equipment_ref: "eq:mill-F5" # ← 先做外键引用，不急着建设备实体
params: [reduction_pct, temp_c, tension_kn]
#
Characterization:
id: "char:tensile-rt"
measures: ["yield_strength", "tensile_strength", "elongation"]
method_standard: "std:XX-tensile-2021"
uncertainty_pct: 2.5 # ★ 表征方法自带不确定度
#
StandardClause:
id: "clause:XX-2021#yield-16mm"
property: "yield_strength"
operator: ">="
threshold: {value: 355, unit: "MPa"}
conditions: {thickness_mm: {max: 16}}
version: "2021"
supersedes: "clause:XX-2015#yield-16mm"
#
# 生产对象通过 OTS 三元组挂上去：
Observation:
object: "heat:H-2024-XXXX" # 对象
time: "2024-XX-XX 14:32:07" # 时间
space: {line: "HSM", station: "F5", position_m: 3000.4} # 空间
characterization: "char:tensile-rt"
value: {yield_strength: 372}关键在于 Observation：它把「对象-时间-空间」三个维度和「表征方法」绑在一起。有了这个结构，质量溯因的跨工序 join 才有确定的主键可用。
实施建议
跟第一批业务场景一起做，不要单独立项做本体。
单独的本体项目没有业务方参与，做出来的模型必然脱离实际。正确做法是：选两三个首批场景，要求它们的输出必须落到同一套实体 ID 上——本体在这个约束下自然长出来。
跟研发知识库场景合并推进。
知识库要从文档里抽取实体（材料、工艺、表征、性能），这跟本体建设的工作量高度重叠。分开做是浪费。
从第一天就按密级打标。
事后补密级标注是补不上的——你没法回溯判断五年前那份报告当时应该是什么密级。这跟审计日志一样，必须从一开始就有。
必懂概念 / 8 张
ai engineer's view / 换成你熟悉的说法
本体 ≈ 领域的类型系统 + 外键约束
它定义什么是合法实体、实体间有哪些合法关系。没有它，每个场景都会自造一套 ID，三个月后就是三个烟囱。
最小可用本体 ≈ MVP schema
完备本体做三年也做不完。业界可行的中间路线是：先只定义材料/牌号、工艺步骤、表征方法、标准条款四类实体，随场景演进。
对象-时间-空间三元组
冶金对象天然要同时被这三个维度定位——哪块钢、什么时刻、在产线哪个位置。这是跨工序 join 的主键设计。
没有本体就没有细粒度权限
权限要挂在实体上。没有统一实体，就只能做到目录级授权，也就不敢开放跨部门的多 Agent 协同。
延伸学习
相关场景