Files

T

eaiadmin 90031b75f3 docs: 重构仓库文档目录并迁移训练素材

按当前架构重组 docs 目录，统一中文命名与目录分层，并将训练原材料迁移到独立目录以保持架构文档边界清晰。

2026-09-22 23:23:16 +08:00

62 KiB

Raw Permalink Blame History

本体论与语义层专题调研

落盘日期：2026-09-19 状态：调研稿 + 一处架构判断（第 8 节，待拍板，尚未形成实施结论）目的：为 pj0235 六层架构「第 2 层本体与语义上下文层」提供外部对照，并回答一个具体问题 —— 现在这套分层切法对不对 关联文档：

docs/09_Research/RS02_外部智能体平台架构对照.md（六层逐层外部对照；本稿是其第 6 节「本体层」的专题展开，不重复其平台部分）

docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY15_术语基准本体语义层与对象层.md（本体层命名口径）

docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY16_本体泛化数据动作与工作流.md（本体三层一般化）

docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY20_角色卡与轻量本体架构.md（轻量本体设计）

docs/01_System_Overall/SY21_统一角色技能动作架构.md、SY22_Role_Skill_App_Unified_Task_Architecture.md（六层定义）

docs/02_Architecture/对象标准化与解耦总则.md（三层职责与关系层判断）

调研方法与可信度（必读）
结论摘要
概念辨析：本体 / 语义层 / 知识图谱
Palantir 深潜（唯一成熟参照）
工业标准侧：哪一层能复用
语义层产品全景：全部只读
中文世界的本体落地
反方意见与失败复盘
对 pj0235 的判断：第 2 层与第 4 层的切口
自研最小可用子集（MVP）
W3C 标准与工具链
GraphRAG 与神经符号
未查证 / 存疑项
来源清单

阅读建议：如果只读一节，读 第 8 节。第 2–6 节是它的证据。

0. 调研方法与可信度（必读）

方法：本次调研由七路并行检索完成 —— ① Palantir 官方文档深潜；② 语义层产品与神经符号；③ 工业本体标准；④ 中文世界厂商落地；⑤ 中文世界学术与标准；⑥ W3C 标准与工具链；⑦ 反方意见与失败复盘。

重要限制：本次环境下 WebFetch 被全域拦截（同 RS02）。因此大部分子调研改用 curl 直取官方页面原文。这在本次反而带来了比 RS02 更高的证据质量 —— Palantir palantir.com/docs、W3C、Microsoft Learn、OpenKG CKAN API、GitHub API 均可直取并逐字核对。

可信度分档（正文按此标注）：

档位	判据	举例
【官方】	官方文档 / 官方仓库 / 标准组织原文可直接引用	Palantir OMCP 机制、Fabric IQ 术语表、OPC UA 配套规范索引、W3C REC 状态
【论文】	同行评议或 arXiv 附编号	OG-RAG (EMNLP 2025)、LLM-Modulo (ICML 2024)、Neuro-Symbolic Survey (IJCAI 2025)
【第三方】	分析机构、媒体、个人、厂商博客	成本数据、失败复盘、竞品分析

引用原则：凡正文写「官方原话」的，均为 curl 直取页面中确实出现过的句子；凡未查证到的一律写「未查到」，不代猜、不补全。厂商自报与竞品内容单独标注。

1. 结论摘要

核心判断分两层：一层是外部的，一层是我们自己的。

1.1 外部世界（第 2–7 节的结论）

#	发现	可信度
一	「本体」与「语义层」的分界线不是表达力，是「读 / 写」。全部主流语义层产品的官方 API 无一提供写回原语	【官方】逐个核实
二	Palantir 官方明确否认自己是语义层："The Ontology is not a 'semantic layer'"	【官方】
三	按动作能力可分三档：只读语义层 → 规则驱动运营本体（Fabric IQ）→ 动作驱动运营本体（Palantir）	【官方】
四	动作层是标准侧的真空。没有任何工业标准描述动作的权限、前置条件、幂等、回滚、审计	【官方】
五	中文世界本体供给远低于观感。 OpenKG 410 个数据集里带本体标签的仅 13 个（3.2%）；真本体工程几乎全部停更在 2019–2022	【官方】API 实测
六	信通院两份旗舰智能体报告均无本体专门章节，而厂商在集体讲本体	【官方】逐页核实
七	最强的反方论据不是「LLM 变强了」，而是载体错配（OWL/SHACL 为推理机设计，非为概率模型设计）；且 13 个生产部署中仅 3 个复用形式本体，这 3 个的本体全部先于 LLM 存在	【论文】/【第三方】
八	工业侧的正确分工是类型层复用标准、实例层自建、动作层自建 —— 决定产品胜负的是后两层	【官方】综合

1.2 我们自己（第 8 节的结论，待拍板）

分层框架是对的，第 5/6 层的优先级判断也是对的 —— 但第 2 层与第 4 层之间的切口切错了。

SY22 §4.2 把第 2 层定义为「业务对象、工作对象和它们之间的关系」，不含动作、不含权限；
而 action 被放在第 4 层能力层（SY22 §4.4）；
按 Palantir 的尺子量，这个第 2 层恰好就是他们定义的「语义层」，也恰好就是他们说的「不是本体」；
这个切法已经留下两个独立症状：
- ① action_definition 表有一个 OntologyBindingJSON 字段指回本体层，全仓零个运行时读取方；
- ② 治理字段（RiskLevel / ApprovalMode / AuditLevel / InputSchemaJSON）齐全但全部无人读取，运行时改从技能中文名里猜风险；「要不要审批」这一个概念全仓有 5 套互不相同的词表，且界面判断的那个值后端根本产不出来（详见 §8.4.1）；
仓库里已经有一套跑通的对象-动作模式，但它写在连接器契约（第 1 层）里，不在第 2 层。

详细论证见第 8 节。

2. 概念辨析：本体 / 语义层 / 知识图谱

2.1 中文文献里最权威的一句定义

【官方·期刊官网摘要页原文】黄恒琪, 于娟, 廖晓, 席运江. 知识图谱研究综述. 计算机系统应用, 2019, 28(6): 1-12. DOI 10.15888/j.cnki.csa.006915

中文摘要：「……本体是知识图谱的模式层和逻辑基础，知识图谱是本体的实例化；本体研究成果可以作为知识图谱研究的基础……」英文摘要同页："the ontology is the schema layer and the logical basis of a knowledge graph while the knowledge graph is the instantiation of an ontology."

用途：本仓库 SY15 引用的是 Gruber 1993 的英文定义。此条可与之并列，作为中文学术界的权威出处。

2.2 分界线：不是表达力，是「读 / 写」

调研逐个核过全部主流语义层产品的官方 API 文档 —— 没有任何一个提供写回原语，接口全是 query / list / get / describe。唯一沾边的是 Looker Actions（POST 到外部 webhook），但那已发生在语义层之外。

【第三方】一个可直接使用的判定测试（operational-ontology）：

「你能从你的语义层里取消一个订单吗？」 不能 → 只读语义层。能，但源系统没变 → 那只是个平行数据库。能静默删除已发货订单 → 那只是个写 API。

方案	读什么	写什么	规则由谁强制
裸数据库访问	表	无限制 UPDATE	无 / prompt
语义层 / metrics MCP	受治理指标	—	不适用（只读）
API 包装工具	端点	按端点	各后端，不一致
运营本体	对象、链接、聚合	仅具名 Action	模型中的前置条件，且审计

2.3 Palantir 官方否认「本体是语义层」

【官方原文】The Ontology system：

"The Ontology models decisions through the four-fold integration of data, logic, action, and security." "The Ontology is not a "semantic layer"; the fourfold integration and operationalization of data, logic, action, and security cannot be accomplished with a thin semantic layer or a monolithic design. Rather, the Ontology is a multimodal system consisting of dozens of underlying components, which can conceptually be grouped into a Language, an Engine, and Toolchain."

这条是本次调研对我们最直接的一条外部判据。

2.4 三处术语污染（引用时须避开）

(a) 「语义 / 动力 / 动态」三层在官方技术文档里不存在。 中文技术圈普遍把 Palantir 本体整理为「语义层 / 动力层 / 动态层」。核实结果：这个三元组只在产品营销页出现过一次；官方技术文档只承认两层 —— semantic（objects/properties/links）+ kinetic（actions/functions/dynamic security），即 "dynamic" 被官方折叠进 kinetic，没有独立成层。

(b) 「OAG（Ontology-Augmented Generation）」是 Palantir 造的词，不是学术概念。 【官方】Palantir 确有该文档页。但两点须注意：① 该页正文讲的是经典 RAG 技巧（chunking / embedding / HyDE / hybrid+RRF），原话自己写着 "there is no singular 'best approach'"；② 该页还劝你别用检索 —— "With new model generations' increased context lengths, you may not need to use semantic search at all... If your application's full context is within this limit, we recommend you start without search." 学术上可引用的对应物是 OG-RAG（arXiv:2412.15235，EMNLP 2025 Main，微软）。

⚠️ 缩写歧义：Open Academic Graph（OAG） 是学术知识图谱数据集，与此无关。

(c) Microsoft Fabric IQ 引发的两派「semantic layer」冲突。 2025 年 11 月后 "ontology" 一词被微软拿去用。分析派（BI 指标模型，关乎信任）与本体验派（RDF/OWL 知识模型，关乎理解）含义冲突。第三方概括："They're all right, and that's the problem."

3. Palantir 深潜（唯一成熟参照）

3.1 构成（官方定义，逐条核对）

概念	官方定义（原话节选）
Object type	"the schema definition of a real-world entity or event"
Object	"a single instance of an object type"
Property	"the schema definition of a characteristic of a real-world entity or event"
Shared property	"a property that can be used on multiple object types in your ontology"
Link type	"the schema definition of a relationship between two object types"
Action type	"the schema definition of a set of changes or edits to objects, property values, and links that a user can take at once. It also includes the side effect behaviors that occur with action submission."
Function	"a piece of code-based logic... natively integrated with the Ontology: they can take objects and object sets as input, read property values of objects, and be used across action types and applications"
Interface	"describes the shape of an object type and its capabilities"（多态；见 3.5）
Scenario	"a sandbox to apply edits on top of the data in your Ontology" [Beta]

官方还给了与关系型数据的类比表 —— 它暴露了本体的工程本质：

Dataset ↔ Object type ｜ Row ↔ Object ｜ Column ↔ Property ｜ Join ↔ Link type

3.2 Language / Engine / Toolchain（官方原文）

组件	官方定位
Language	"models the semantic objects, links, and properties; along with the kinetic actions and automations; and the literal pieces of logic that define how those actions operate"
Engine	"provides the modular read architecture that enables high-scale SQL queries, real-time subscription to state changes, and every materialization needed by mixed Human + AI teams. In equal measure, it provides a scalable write architecture which enables atomic and durable transactional updates, high-scale batch mutations, high-scale streams, and mechanisms like Change Data Capture"
Toolchain	"enabling developers to use the Ontology as a backend... all build upon the Ontology SDK (OSDK)"

注意 Engine 明确包含 write architecture（原子事务、CDC）。"本体作为后端"的前提是它能写。

3.3 运行时机制：OMCP（最值得借鉴的一节）

【官方原文】Sample architecture：

"Object types: Every object type included in the application is reachable through a SQL tool... Action types: Each action type included in the application becomes its own MCP tool, so agents can invoke a specific, predefined action to write data into the ontology. Query functions: Individual query functions can be exposed as their own MCP tools..."

核心设计：读写工具不对称 —— 读可以宽（合并成一个 SQL 工具），写必须窄（一个动作一个工具）。 agent 因此无法自由构造写操作，只能调用预定义好的动作。

官方还提供 Agent tool description 字段，供建模者写给 agent 看的动作使用说明。

3.4 权限裁决：三方交集

【官方原文】Application restrictions：

"The scope of a given token is determined at runtime and is the intersection of the following:

The permissions of the specific application user or service user in Foundry.

The maximum restrictions configured in Developer Console for the given application.

The operation scope requested in code by the third-party application." "Attempting to request a token with no scope restrictions will generate a token with no permissions."

动作层面的第二处裁决【官方】Action types / Permissions：

"By default, new object types only allow edits via actions... For object types that only allow edits via actions, the user submitting the action will only need Read access on the objects that are being edited."

即：写权限不靠「发写权限」，靠「动作定义 + 提交条件」。

审计【官方】："Because every action the agent performs through Ontology MCP is recorded in the ontology, this pattern provides auditability for unsupervised operations."

3.5 三条官方自己贴出的坑

坑	官方原话
权限只保护读	"Read-time enforcement only — Row and column access controls... These controls do not extend to the model's output or any Ontology edits it composes."
别给 agent 发写权限	新对象类型默认 "only allow edits via actions"，提交者只需 Read 权限
别让模型直接握工具	"LLMs do not have direct access to tools; LLMs can only ask to use tools, and these tool calls are then executed by AIP Logic within the invoking user's permissions"

3.6 Interface 的成熟度（别提前做）

官方自己列出的 Interface 支持矩阵：

完整支持：Ontology Manager、Marketplace、TypeScript v2 Functions
部分支持：Actions（beta）、OSS、OSDK（仅 TypeScript，Java/Python 开发中）
完全不支持：Workshop、TypeScript v1 和 Python functions

对自研的含义：Interface（对象类型多态）官方自己都没铺全，提前建接口是纯负债。

3.7 规模与代价

【官方】Object Storage v2 宣称 "indexing throughput on the order of tens of billions of objects for a single object type"；单次 Action 最多编辑 10,000 个对象。【官方】Object Storage v1 "Phonograph" 计划 2026-06-30 后不可用 —— 说明这套存储层已迭代两代。

【第三方·竞品，需打折】实施代价：

"Professional services, forward-deployed engineering time, internal talent investment, and ongoing Ontology maintenance routinely push total cost of ownership well beyond the contract value." "The Bootcamp produces a proof of concept, not a production-ready deployment." "Ontology Drift: Every reorganization, acquisition, and vendor update that changes your data sources requires a corresponding Ontology update."

4. 工业标准侧：哪一层能复用

4.1 三层分工（本节的核心结论）

层	现成程度	代表物	缺口
类型定义层	≈ 齐了	OPC UA 配套规范（430+）的 ObjectType/VariableType、AAS 子模型模板、ISA-95 对象模型	跨标准的 Type 身份互不映射，无权威总目录
属性/字典层	齐了	IEC 61360 / IEC CDD / ECLASS（IRDI 锚点）	收费与授权；中文标准与 IRDI 未打通
形式本体层	齐了但割裂	BFO(ISO 21838-2)、IOF Core、IDO(LIS-14)	三条互不兼容路线
实例数据层	不齐，各家私有	Cognite DMS、AAS Instance、OPC UA 运行时地址空间	无跨平台标准实例交换格式
动作层	几乎空白	OPC UA `Method`、AAS `Operation`、OPC 10000-16 State Machines	没有任何标准描述动作的权限、前置条件、幂等性、回滚、审计

4.2 一个重大动向：OPC Foundation 官方转向 agent

【官方】2026-04-20，OPC Foundation 宣布把全部 430+ 个配套规范转换成面向 RAG / MCP / AI 辅助工程的格式，明确定位 OPC UA 为「agentic AI 与工业自动化之间的语义层」。原型仓库已产出 token 优化的 RAG chunk + 向量嵌入 + MCP/REST 查询接口。

原文："Grounding them in the established semantic interoperability of OPC UA is an important step towards reliability and acceptance" —— Dr. Holger Kenn，OPC Foundation AI 工作组负责人

含义：工业侧的类型层已经有人在替我们做，而且是官方在做。

4.3 值得直接映射的资产

标准	编号	为什么相关
OPC UA Machinery	OPC 40001-1~4	机器标识与发现、状态、过程值、作业、能耗 —— 被大量其他 CS 依赖的公共底座
ISA-95 / IEC 62264	OPC 10030 / 10031-4	ERP↔MES 对象模型（企业资产层级、作业）
AAS	02006 Digital Nameplate	资产身份，最基础的落地入口
AAS	02008 Time Series Data	传感器时序的标准挂载点
AAS	02017 Asset Interfaces Description	描述资产暴露哪些接口 —— 天然的工具面
AAS	02090 OT 资产台账标准数据模型	OT 资产台账
AAS	02091 / 02092 Digital Worker Profile	数字员工画像 —— 与「数字员工平台」直接对位
AAS	02103 AI-Agent (Type & Instance)	在研。IDTA 正在做 AI Agent 的类型/实例子模型

⚠️ 02103 的规范正文未查到（官方页面确认编号与名称存在、状态 In Development，但无公开草案）。这是本次调研的明确空白。

4.4 反面教材：ISO 15926

流程工业最完整的本体，也是最著名的落地教训。【第三方】证据扎实：

NIST 评审：需求规格「宽松」、Part 2 的可执行约束比多数上层本体还少、缺少 conformance testing 计划
Chalmers 案例研究：RDL 至今不完整，工具不支持值/类层级/关系转换
Chemical Processing：RDL 条目被石油公司主导，化工设备信息稀疏；全行业只有「少数人」有能力维护中心 RDL；设备供应商没有动力喂数据
Oil IT Journal：开发 15 年仍未完成，「公司开始各干各的」；RDL 免费，那谁付钱？

结论：不要把 ISO 15926 作为主路线。 后继者 IDO（POSC Caesar LIS-14，约 53 类 / 88 对象属性 / 246 条公理）可作参考而非基座。

⚠️ Siemens 资料称 IDO 为 ISO 23726-3，该编号未从 ISO 官方渠道证实。

4.5 工业知识图谱的失败模式（【第三方】中文行业分析）

约 70% 的项目卡在前两个阶段（数据治理与本体构建），不是卡在算法上
没人拥有本体：设备层级与故障分类各厂不同；没有主数据就抽不出统一的图
单一巨石图风险：一次性建大图前期投入巨大、风险高
图谱类型必须匹配应用：故障诊断图（召回导向）与工艺优化图（因果导向）本质不同，不能互相替代
成功判据原话：「覆盖 3 类核心设备、90% 准确率的小图，远比 10 万实体但满是错误的大图实用。」

5. 语义层产品全景：全部只读

产品	一等对象	读 or 写	服务对象
dbt Semantic Layer	`semantic model` → entity/dimension/measure；`metric`	只读（MCP 工具全是 `list_`/`get_`/`query_metrics`）	BI + agent
Cube	`cube` + `view`	只读（REST/GraphQL/SQL/DAX/MDX + Meta API 自省）	BI / 嵌入式分析
AtScale	`semantic model`（YAML + SML）	只读（`run_query` 官方明确「只执行单条 SQL SELECT」）	BI + agent
Snowflake Semantic Views	`semantic view` → tables/relationships/facts/dimensions/metrics	只读	BI + agent（Cortex Analyst）
Databricks UC Metric Views	`metric view` → fields/measures + agent metadata	只读	BI + agent
Databricks Genie Ontology	`snippet`（带 authority score）+ UC semantics	只读。官方自述为 "unified context layer"，非形式本体	agent 专用
Looker / LookML	model/view/explore/dimension/measure	只读。唯一写路径 Looker Actions（POST 到外部 webhook），属语义层之外	BI + agent
Microsoft Fabric IQ Ontology	entity type / entity instance / entity type key / property（static + time series）/ relationship type / data binding / rule	读 + 图查询 + 条件触发的自动反应。`Action` 不是一等对象，只是 `Rule` 的后果字段	agent 为主
Palantir Ontology（对照）	object type / object / property / link type / link / action type / function / interface / role	读 + 写回。Action 是唯一受控写路径，规则在模型里而非 prompt 里，成功与拒绝均入 action log	运营闭环 + agent

竖着读「读 or 写」这一列：在 Palantir 之前全部是「只读」。

5.1 Fabric IQ Rule vs Palantir Action（一处重要更正）

初稿曾判定「Fabric 本体没有 Action 原语」，该结论下早了（只 grep 了 ontology/overview.md，漏了 how-to-use-rules.md 与 resources-glossary.md）。准确事实：

Fabric IQ 总览页原文："Ontology (preview) defines core business entities, relationships, properties, rules, and actions."
但官方术语表（13 条）中 Rule 有条目，Action 没有 —— 它只在 Rule 定义里作为后果出现："A conditional statement that monitors property values or relationships..., then triggers an action in response (like 'send Teams alert' or 'invoke Fabric Job')."
机制上是条件触发而非具名事务：依赖 Fabric Activator，前置条件是本体至少有一个 time series property 完成 data binding，且产生 Activator 费用

	Palantir Action type	Fabric IQ Rule
是否一等对象	是，与 object/link type 并列，有自己 schema	否，`Action` 是 `Rule` 的后果字段
触发方式	人或 agent 主动提交一次具名动作	条件满足时自动触发（阈值/时序）
写回能力	写回 source of record，唯一受控写路径	通知与作业触发，不是对业务对象的受控事务写
审计	Action log 记录「哪个动作作用于哪个对象」	Activator 侧

一句话：Fabric 把「动作」做成监控规则的反应端（condition → reaction）；Palantir 把「动作」做成可被 agent 显式调用的、带前置条件与审计的业务事务（intent → governed write）。

因此分档是三档而非两档：只读语义层 → 规则驱动的运营本体（Fabric）→ 动作驱动的运营本体（Palantir）。

5.2 标准进展：OSI / Apache Ossie

【官方】Open Semantic Interchange，由 dbt Labs、Snowflake、Databricks、Salesforce、Oracle 等发起，2026-06 进入 Apache 基金会孵化器，更名 Apache Ossie (Incubating)。

时间线：2025-11 开仓库 → 2026-01-27 首版规范 Apache 2.0 发布 → 2026-06 进 Apache
当前草稿 0.2.0.dev0，官方明确标注「生产不建议使用」
覆盖：Semantic Model / Dataset / Field / Metric / Relationship / Dimension / AI Context
关键：ai_context（synonyms / instructions / examples）是规范原生字段，目标就是降 LLM 幻觉
工作组里有一个就叫 "Ontology"

【第三方】重要限制："Portability ≠ Governance" —— OSI 标准化的是指标如何被描述，不是如何在运行时被强制（行级安全、财年日历、币种逻辑、审计轨迹仍属各工具实现细节）。

6. 中文世界的本体落地

6.1 最硬的反证：国家级报告里没有本体

【官方】逐页核实信通院两份旗舰报告：

报告	页数	结论
《2025 政企行业智能体研究报告》（中国电信 + 信通院云大所，2025-04-29）	58 页 5 章 18 节	未查到本体（Ontology）专门章节或论述
《企业级智能体技术与应用研究报告（2026 年）》（信通院人工智能所 + 360，2026-06-24）	55 页 5 章	目录与技术要点中均无「本体/语义层」；技术侧讲的是模型适配、记忆增强（RAG 知识库）、工具增强、自主规划、多智能体协同（A2A）

厂商在集体讲本体，官方技术框架里没有这个词。 这个错位比任何批评文章都有力。

6.2 厂商落地：有术语体系，无具名客户

用友 YonOnto（【官方口径】，术语体系最完整）

产品线：BIP「本体智能体（Ontology-Driven Agent）」（2026-01-07）→ LOM 本体大模型（2026-02-24）→ BIP 6 的 YonOnto + YonWork（2026-08）
分工：「YonOnto 负责让 AI 理解企业业务，YonWork 负责组织 AI 完成企业工作」
六大企业级特性（这是最接近「运行时对象层」的证据）：统一建模、全生命周期（草稿/提交/审核/发布/变更/冻结）、本体空间（空间/领域/场景隔离）、多版本（快照/对比/回滚）、继承扩展（领域本体→租户本体）、跨域协同
⚠️ 关键负面证据：未查到以 YonOnto 命名的客户案例。 用友可公开检索到的具名案例（山东融汇、招金精炼、科沁万佳）用的都是 BIP/YonWork/YonData，不见 YonOnto

中电金信「源启·智能决策操作系统」（【官方口径】）

两个平台：OMP 本体管理平台（结构化沉淀「对象、关系、动作、规则、权限、数据标准和版本体系」）+ OIP 本体智能体管理平台（管智能体、知识库、MCP 服务、CapaMesh）
三层：数据工具层 / 本体模型层 / AI 决策层，打通「数据—知识—决策—操作—反馈」OODA 环路，支持双向回写
「六层约束」：语义、口径、上下文、流程、权限、动作
案例：某国有银行零售营销策略优化，周期数周→数小时，效率提升 80% 以上 —— 不具名

其余厂商：浪潮（海岳本体孪生平台 1.0）未查到细节；华为 iDME 是元模型/模型驱动，未见 ontology 命名；金蝶业务对象模型、阿里 OneData、腾讯 ADP、百度 KG Schema 均未见本体命名 —— 【第三方】有分析指出「这种命名策略反而更诚实」。

6.3 学术与标准

真有本体国标，现行 17 项，其中 GB/T 48000.3-2026 标准数字化第3部分：本体建模要求（2026-08-01 实施）与 GB/T 45256-2025 知识本体构建流程 是正经工程标准。但三个特征明显：地理信息口占大头、「本体建模要求」直到 2026 年才实施、KG 标准数量与成熟度远高于本体标准
OpenKG 实测（CKAN API 直查）：410 个数据集，带本体类标签的仅 13 个（3.2%）；唯一以「本体」命名的分组 schemata 只有 2 个包；一级导航只有「开放图谱 + 开源工具」两栏，没有本体栏目
cnSchema 实测：1765 个类 / 1586 个属性；GitHub 最后推送 2022-12-14（约 4 年未更新）
真本体工程几乎全部停更在 2019–2022：cnSchema 2022-12、CHPO/HPCH 最后上传 2019-11-22、OpenHowNet 2021-12-16、HowNet 原官网已被抢注、CMeKG 官网友尽、chinahpo.org 不可达
《知识图谱：方法、实践与应用》更正：网上流传该书有「2.5 本体技术」一节 —— 该节不存在，2.5 实为「知识图谱的向量表示方法」。该书对本体不独立成章，拆进「表示建模（Protégé 实践）+ 融合（概念层 vs 实例层）+ 推理（本体推理）」三处

该子调研的总结可直接引用：「活跃的只有 KG 与术语表，沉淀下来的才是本体。」

6.4 成本与批评

【第三方】成本数据（Atlan，2026）：

指标	数值
企业知识图谱长期成本	约 1000 万 – 2000 万美元，绝大部分是人头成本
团队规模	5–15 人的专家团队（设计/构建/填充/验证/维护本体）
越过 pilot 阶段的比例	不足 15%
术语	"the ontology tax"（本体税）
放弃项目的头号原因	67% 归因于「缺乏内部图专家」

「本体漂移」的原文（最技术、最锋利的一条）：

"the schema and the real-world entities it describes diverge gradually as source systems change, with no re-validation trigger catching it. A table gets renamed, a customer entity merges with another in the CRM, and none of it produces an error."

另有可引用的量级：【第三方】「十多年前，国内已有大型金融机构投入上百名业务和技术人员，花费半年甚至一年，建设覆盖全行业务的信息架构和本体模型。」

⚠️ 未查到公开的「人月」级成本数据。所有可核验来源只给美元总额、团队人数、占项目工作量百分比。

Gartner 立场（⚠️ 全部由第三方转引，未能核验原文）：建议 "采用轻量级、针对具体应用场景的语义体系，而不是构建庞大、覆盖全企业的统一本体"；另有「到 2028 年 60% 仅依赖 MCP 的 agentic analytics 项目会失败，除非底下有受治理的语义层或知识图谱」等预测。

6.5 一条可直接使用的验收标准

问它要一个具名客户，问它能不能现场跑一个动作回写。

截至本次调研，国内没有一家公开厂商通过这两问。

7. 反方意见与失败复盘

7.1 一条重要的诚实声明

未查到任何厂商、任何高管公开说过「不需要本体」「本体已死」式的断言。 反方论证只能走两条路：① 他们实际选了什么（行为证据）；② 第三方怎么解读（分析证据）。

7.2 行为证据：主流 agent 平台实际选了什么

平台	实际选择
OpenAI	Agents SDK 的工具 `name` 默认取函数名、`description` 默认取 docstring、入参 JSON Schema 由函数签名自动生成。官方《A Practical Guide to Building Agents》把 agent 归约为 model + tools + instructions，全文未出现 ontology/语义层/知识图谱
Google	A2A 的 `AgentSkill` 是自由文本 + tags；发现机制是取 `.well-known/agent-card.json` 后按 tag 关键词过滤。官方文档通篇未使用 ontology
Anthropic / MCP	MCP 规范只定义 Resources / Prompts / Tools 三类原语 + JSON-RPC 2.0。规范中没有本体层。工具语义仅由 JSON Schema + 自然语言 description 承载。《Code execution with MCP》给出量化痛点："This reduces the token usage from 150,000 tokens to 2,000 tokens"；"Tool definitions overload the context window"

⚠️ 严格性提示：Anthropic 没有用「schema 过重」去批评本体，它批评的是「工具定义数量」。把「工具定义过载」等同于「批评本体」是推断，不是原话。

7.3 反方最强的一条：载体错配

OWL 2 / SHACL 是「为推理机和校验器优化」的，不是为被概率模型当作上下文阅读而设计的。

这条不依赖 LLM 能力增长、不随时间失效，且被生产数据支持：

【论文/预印本，⚠️ 发表场所未能确认，应按预印本处理】生产调研统计 13 个 GraphRAG 部署，只有 3 个（AstraZeneca BIKG、Mayo Clinic FHIR-Ontop-OMOP、Airbus Skywise）以既有形式本体为底座，而这 3 个的共同特征是：本体先于 LLM 存在，LLM 至多充当维护/集成辅助 —— 与 GraphRAG 的模式恰好相反。

对工程决策的含义：LLM 在本体工作中的现实定位是 候选生成器 + 维护助手，不是自动化本体工程师。这有硬数据支撑 —— 最好的提示策略 Overall F1 仅 0.49，属性抽取 0.17–0.50，非分类关系抽取 F1 可为 0.0；且同一输入多次运行产出不同本体，一致性差是系统性缺陷。

7.4 经典失败案例

Cyc（1984–）【论文/媒体】：头十年是一个 5000 万美元的项目，需 "two person-centuries" 用于数据录入。初始设想约 100 万条事实达到临界质量，实际发现数据库需求膨胀 10 倍。

语义网泡沫【W3C 自己的 Lessons Learned】：知识工程瓶颈（「根本没有足够的知识工程师去手工更新各个知识图谱」）；本体被认为是 Semantic Web 的最大威胁 —— 「没有唯一正确的建模方式，没有全局真理」；一次爬取在 400 万个 RDF 文档中发现 301,000 处 RDFS/OWL 不一致；OWL 2 DL 是 N2ExpTime-complete。

7.5 对 Palantir 本体的批评

【第三方·个人深度分析】 vonng（冯若航，Pigsty 作者）《The Palantir Ontology Scam》：

核心对照表：Object Type = 表；Property = 列；Link = 外键；Action = 存储过程
并指出 Palantir 自己的专利把 Ontology 定义为 "embodied in a database schema... comprising a data model" —— 其专利自认了这一点
最锋利一问：如果 Palantir 的本体真是革命性的智能平台，为什么这家公司仍需要在客户现场长期驻扎数千名高训练成本工程师？
对模仿者："Ontology was Palantir's way of obscuring its actual moat. The imitators copied the smoke instead of the engine."

【第三方】锁死：Michael Burry 称 Palantir 的护城河 "just obstruction of data transfer"，"一个伪装成 SaaS 公司的咨询公司"。具体案例：使用多年后，NYPD 无法以可迁移格式取回其调查人员自己产生的分析洞察与标签。

⚠️ 一处必须避免的误用：a16z 的《The Palantirization of Everything》没有批评本体本身，它说的是「模仿者缺平台层，会变成 UI 更漂亮的埃森哲」。把 a16z 当反本体论据是误用。

7.6 两边其实在打不同版本的「本体」

反方攻击的是 OWL/RDF 那套形式化本体工程（载体错配、推理不可判定、对齐困难）
正方主张的是 Palantir 式的运行时对象模型 / 语义层（对象、链接、动作）
双方用的都是对方的数据：「13 个部署只有 3 个复用形式本体」能被正方读成「还有 3 个头部企业在生产里跑形式本体，而且恰恰是最成熟的场景」

8. 对 pj0235 的判断：第 2 层与第 4 层的切口

本节是本次调研的主要交付。结论待拍板，尚未形成实施结论。

8.1 结论

分层框架是对的，第 5/6 层的优先级判断也是对的 —— 但第 2 层与第 4 层之间的切口切错了。

8.2 先说对的部分（三件经得起检验的事）

#	判断	外部背书
1	六层作为关注点地图是成立的	与 Palantir 的 `data / logic / action / security` 四重整合大致对得上，只是分得更细
2	SY15 的双层命名是对的	架构目标语用「本体层」、工程语用「语义对象层」—— 恰好避开了最大的坑：Palantir 官方明确说 "The Ontology is not* a 'semantic layer'"*。若当初直接叫「语义层」，现在就得改名
3	SY20 §4.2「当前阶段不适合直接上重本体」是对的	Gartner 原话建议「采用轻量级、针对具体应用场景的语义体系，而不是构建庞大、覆盖全企业的统一本体」；成本数据（1000–2000 万美元 / 5–15 人团队 / 不足 15% 越过 pilot / 67% 失败归因于缺内部图专家）同向

docs/02_Architecture/对象标准化与解耦总则.md §9 的「先强对象，再补关系」也在同一方向上。

8.3 问题所在：第 2 层的定义里没有动作

SY22 §4.2 对第 2 层的定义 —— 它回答的是：

平台到底在处理哪些业务对象、工作对象和它们之间的关系。

列出的全是对象类型（device / alarm / work_order / report / task / stage / expert / skill / app / artifact / form / workflow / record）+ 关系。没有动作，没有权限。

而 action 被放在第 4 层能力层（SY22 §4.4：skill / action / policy）。

对照 Palantir 的官方判据（见 §2.3）：

"The Ontology models decisions through the four-fold integration of data, logic, action, and security." "The Ontology is not a 'semantic layer'... cannot be accomplished with a thin semantic layer."

按这个尺子量，我们的第 2 层被设计成的，正好就是他们说的「语义层」，也正好就是他们说的「不是本体」。 它结构上不可能长出动作和权限 —— 因为动作在另外一层，归另外一套代码管。

8.4 症状：`OntologyBindingJSON`

这不是套理论，证据在代码里（均已实际 grep 核实）：

action_definition 表在第 4 层，有一个字段 OntologyBindingJSON，内容形如 {"object_types":["document"],"action_types":["extract"]}
store/seed.go 播了 7 处；api/validation.go 有校验；api/admin_handlers.go 可改
排除 model / validation / seed / admin handler 之后，全仓零个运行时读取方

一个动作定义被放在第 4 层，然后加一个 JSON 字段指回第 2 层。这个字段的存在本身就是分层切错的症状 —— 设计者感觉到了「动作应该属于本体」，但选择了加字段打补丁，而不是移动切口。而因为它是 JSON 字符串而非真关系，它就没有读取方，于是彻底惰性。

按 §5.1 的三档尺子，我们现在卡在第 0 档与第 1 档之间：动作是具名的（像 Palantir），但对象类型绑定只是 JSON 字符串、前置条件与权限裁决没有人读、审计落在别处。升到第 3 档靠往第 2 层塞更多对象类型是做不到的。

8.4.1 第二个独立症状：治理字段齐全，但运行时在旁边另算一套

⚠️ 写给未来的自己：初稿在这里写过「没有权限裁决、没有审计」，这句话是错的。字段都在。真正的问题比「没有」更麻烦 —— 有声明，没人读，运行时有另算一套。

action_definition 表（第 4 层）的治理字段是齐的：

字段	取值	运行时读取方
`RiskLevel`	`low` / `medium`	零
`ApprovalMode`	`not_required` / `approval_guarded`	零
`AuditLevel`	`standard` / `strict`	零
`InputSchemaJSON` / `OutputSchemaJSON`	JSON	零
`ExposedToUser`	bool	零

ActionDefinitionRepo.GetByKey 写好了、key 上有唯一索引 —— 但没有调用方。整个 ActionDefinitionRepo 只被 internal/api/action_definition.go（后台 CRUD）引用。这张表是后台配置表，不参与运行。

那运行时的风险等级从哪来？从技能的中文名里猜（internal/specialists/runtime/records.go:230）：

func inferRiskLevel(value string) string {
    switch {
    case strings.Contains(value, "发布"), strings.Contains(value, "审批"),
         strings.Contains(value, "同步"), strings.Contains(value, "回写"):
        return "high"
    ...
}

动作不是从 action_definition 读出来的，而是从 specialist.BaseSkills 这个分隔符文本字段切出来的（records.go:132）。名字里带「写回」就是高风险，带「汇总」就是中风险。

于是同一个概念「这个动作要不要审批」，全仓有 5 套词表：

#	位置	产出值	性质
1	`action_definition.approval_mode`（表）	`not_required` / `approval_guarded`	声明式，零读取方
2	`records.go:216` `approvalState()`（动作记录）	`ready` / `pending`	从中文名猜
3	`records.go:82` `buildPermissionRecords`（权限记录）	`approval_required` bool	硬编码
4	`MarketPage.vue:1041`	`approval_required` / `not_required`	前端再猜一遍
5	`StudioPage.vue:1471`	`not_required` / `pending_design`	前端第三套

最硬的一处证据：前端 specialistFlow.js:58,186 读的是后端 item.approval_state，然后判断

if (approvalState === 'approval_required') return 'warning'
approval: item.approval_state === 'approval_required' ? '需要确认' : '可直接执行'

而后端的 approvalState() 只会返回 ready 或 pending —— 全仓 Go 代码里没有任何一处把 approval_required 赋给 approval_state（Go 中该字符串只作为 buildPermissionRecords 里的 bool 键名出现）。

结论：界面上那个「需要确认」的警告，在真实后端数据上永不触发。 actionTone 的 warning 分支同理永不命中。

这和 OntologyBindingJSON 是同一种病：概念在系统里存在，声明在 A 处、计算在 B 处、消费在 C 处，三处词表互不相同，没有任何一处是权威的、有强制力的。这正是第 2 层与第 4 层切口切错之后，治理语义无处安放的具体后果 —— 它没有家，所以每个路过的人各建一个。

8.5 一个反直觉发现：正确模式已在仓库里，只是在最不该在的层

连接器层（第 1 层）有全仓唯一一套真正跑通的对象-动作目录。

internal/connectors/core/contracts/contracts.go：

type ObjectDefinition struct {
    Key, Label, Description, Mode, RecommendedFormID string
    DefaultFields []string
    FilterHint    string
}
type ActionDefinition struct {
    Key, Label, ActionType, Description string
}

金蝶连接器声明了 customer / supplier 等主数据对象，带 RecommendedFormID 与默认字段。且 internal/specialists/runtime/task_runtime.go:269 确实在运行时读它 —— 全仓唯一一处。

它是 stub（definition.Objects[0] 硬取第一个、UseDemo: true、Limit: 3、拿任务标题当过滤条件），但形状是对的：对象类型 + 动作类型 + 运行时读取。

对象-动作这套东西我们早就写出来了，只是写在连接器契约里，而不是写在第 2 层。

8.6 建议的切口（两条路，须二选一）

路线 A：改成真本体（把切口上移）

层	现在	应该是
第 2 层	对象类型 + 关系	对象类型 + 关系 + 动作类型声明 + 提交条件 + 权限裁决点
第 4 层	skill / action / policy	skill / 动作的执行实现 / policy

这正是 Palantir 的切法：Action type（声明、前置条件、schema）属于本体；Action 的 side effect behaviors（函数、webhook）才是执行侧的事。OntologyBindingJSON 应从 JSON 字符串升格为真关系。

路线 B：承认它就是语义层（改名字，不改分层）

如果目标本来就是做一个只读的语义上下文层，那么现在的切法不但没错，还很合适。此时该改的是：

SY22 第 2 层的命名（不再叫「本体与语义上下文层」）
D25 的表述
SY15/SY20 中承诺「本体」的部分

这两条路选哪条是产品判断，不是技术判断。

9. 自研最小可用子集（MVP）

若走路线 A，以下是从 Palantir 官方设计反推的最小集合。

9.1 必需（砍掉任意一个，本体就退化成 ORM 或权限裸奔）

#	概念	为什么必需	最小实现
1	Object Type + Property	没有它，agent 只能看表结构	元数据表：api_name / display / primary_key / title_key / schema
2	Link Type	这是本体区别于「一堆表」的唯一理由 —— 关系是 agent 导航的路径	有向边定义 + 双向遍历 API
3	Action Type	整个运行时安全模型的支点。OMCP 的核心就是「每个 action 一个 MCP tool」	动作 = {参数 schema, 写入规则, 提交条件, 副作用}
4	Function（只读查询函数）	agent 需要「算子」而非只有「取数」	可注册的只读函数
5	权限裁决 = 用户权限 ∩ 工具授信范围	Palantir 的 token scope 三方交集 + action submission criteria 是两处裁决，缺一处就是提权通道	工具/应用级 scope 白名单 + action 级提交判定
6	读写工具分离	官方做法：读走一个 SQL 工具，写走每 action 一个工具。读可以宽，写必须窄	两个 tool 类型：`query`、`action:<name>`
7	写事务（staged writes）	agent 一次任务里会连续写，中途失败必须不留脏数据	单次执行一个事务，提交时统一落库
8	审计日志（decision lineage）	官方卖点原话："every action the agent performs... is recorded in the ontology"	每次 tool call 落一条不可变记录

9.2 可砍（有则更好）

概念	建议
Interface	可砍。官方自己都还没在 Workshop / Python / TS v1 里支持。提前建接口是纯负债
Object Set（持久化）	半砍：语义上必须有，但不必做成可保存可分享的资源
Scenario（沙箱）	可砍，除非要做 Evals —— 若做 agent 评测，它是唯一能安全跑有副作用用例的办法
Shared Property / Value Type / Struct Type	可砍。几十个对象类型以下收益为负
CDC / 流式索引	可砍。Palantir Engine 里最重的一块，MVP 用轮询/增量批次即可
OSDK 代码生成	建议留（TS 优先）。类型化客户端是「本体真的在用」的标志

9.3 MVP 阶段不必做的事

不必上重本体（OWL / 推理机 / SHACL）—— Gartner 与成本数据同向，且 §7.3 的载体错配论据支持这一点
不必自建类型层 —— 工业侧复用 OPC UA CS + AAS 子模型 + ISA-95（§4）
不必做 Interface / Role / 复杂继承

10. W3C 标准与工具链

⚠️ 本节本轮未完成。 负责该路的子调研在落盘前未返回结果，其会话已结束，结论未取到 —— 不是「还在跑」，是「没做成」。补做时本节应覆盖：RDF/RDFS/OWL 2 Profiles/SKOS/SPARQL/SHACL 的定位与选型、RDF 1.2 triple term 现状、图数据库（Neo4j n10s / GraphDB / Stardog / TopBraid / Jena）的 OWL 推理档位与许可、LPG vs RDF 的本质区别、ISO GQL (ISO/IEC 39075:2024)。

对第 8 节的影响：无。 路线 A 只需要「对象 / 链接 / 动作 / 权限」这层概念模型，不依赖 RDF 技术栈选型；即便将来要接 SHACL 做校验，也是实现细节而非切口问题。

已知的临时结论（来自已返回的其他路）：

SHACL 取代 OWL 做校验的原因是世界假设不同：OWL 是开放世界（缺失 ≠ 违规），校验要求封闭世界。OWL 根本不表达约束，只描述推断 —— owl:maxCardinality 1 的语义是「只有当某物最多有一个值时才推断它是该类实例」，多加数据永远不会违反 OWL 约束
RDF-star 已不再作为标准名，工作并入 RDF 1.2 / SPARQL 1.2，机制改名 triple term；WG 章程 2025-05-01 重新制定，延期至 2027-04-30
【第三方】SHACL 在生产工程写作中的出现率低得惊人，尽管它成为 W3C REC 已八年

11. GraphRAG 与神经符号

⚠️ 本节本轮未完成。 同上，负责该路的子调研未返回，结论未取到。

已知的临时结论：

Microsoft GraphRAG（arXiv:2404.16130）四段流水线：LLM 抽实体/关系构图 → Leiden 算法多层社区检测 → 社区摘要预生成 → 检索分 Local（实体邻域）/ Global（社区摘要 map-reduce）。当前 v3.1.2，v3.0.0 的破坏性变更是 monorepo 化（单包拆 8 个）
LazyGraphRAG（2024-11-15）推迟 LLM 使用：索引成本 = 向量 RAG，仅为完整 GraphRAG 的 0.1%；官方称在 GraphRAG 全局搜索 4% 的成本预算下，local 与 global 两类查询均显著优于所有对比方法
神经符号首选综述：arXiv:2508.13678，IJCAI 2025 Survey Track，给出 Symbolic→LLM / LLM→Symbolic / LLM+Symbolic 三分法
最可落地的 agent 机制是 LLM-Modulo（arXiv:2402.01817，ICML 2024 Position）：LLM 是生成器不是验证器；一圈外部 critic（正确性 critic 必须 sound）；meta-controller 汇总批评意见回灌，形成 Generate–Test–Critique 循环
符号护栏的可量化可行性（arXiv:2604.15579）：综述 80 个 agent 安全基准，发现 85% 要么没有具体安全策略、要么只有高层目标；在有明确策略的基准中，74% 可用符号护栏强制实施且不牺牲效用

12. 未查证 / 存疑项

12.1 明确未查到（不得代猜、不得补全）

IDTA 02103「AI-Agent (Type & Instance)」子模型规范正文 —— 官方页面确认编号与名称存在、状态 In Development，但无公开草案
任何厂商公开说过「不需要本体」 —— OpenAI / Anthropic / Google 均无此表述
公开的「人月」级本体建设成本 —— 所有可核验来源只给美元总额、团队人数、占项目工作量百分比
独立、非厂商、量化的本体 ROI 研究 —— 收益侧数字全部来自卖本体的厂商
卡奥斯的工业本体图谱技术规范 —— 只有媒体口径
Honeywell Forge 的 agent/本体技术细节 —— 只有市场宣传语
ISO 23726-3 编号的官方确认 —— 仅见于 Siemens 演示材料
中国本土本体项目的具名失败复盘 —— 未查到，疑似不存在公开记录
徐工汉云本体工作的官方产品文档 —— 仅猎聘 JD 有详细描述
张钹在本体论/知识表示方面的中文论述 —— 多个人主页 404
§10 W3C 标准与工具链、§11 GraphRAG 与神经符号两节的完整调研 —— 本轮未完成（见各节文首说明）。这两节现有的内容只来自其他六路的交叉覆盖，不是该专题的系统检索结果，引用时请按此折价

12.2 存疑（引用须标注）

项	问题
Gartner 全部数字	60% 仅 MCP 项目将失败、>50% agent 系统将用图上下文、44% 已实施语义层等 —— 均未能核验原文，全部第三方转引
生产调研「13 个部署仅 3 个用形式本体」	仅 ResearchGate 落地页，未能确认正式发表场所与评审状态，应按预印本处理
用友 LOM-4B 准确率	89.47% / 93% / 94% 三个口径并存
Atlan 成本数据	厂商自报，引用者需打折
Palantir 实施代价	Datafi / beam.ai 均为竞品，有商业动机
arXiv:2604.00555（Ontology-Constrained Neural Reasoning）	量化结果漂亮到可疑，引用前请自行 curl 确认论文存在
「AI 用量」「本体税」等中文行业数字	多来自个人博文，无出处

12.3 三处常见误用（引用时须避开）

不要把 a16z 当反本体论据 —— 它说的是「模仿者缺平台层」
不要把 Karpathy 当反本体论据 —— 他说的是「context engineering 取代 prompt engineering」
不要引用《知识图谱：方法、实践与应用》的「2.5 本体技术」节 —— 该节不存在

13. 来源清单

13.4 中文世界

厂商：用友 YonOnto 语义中枢｜ BIP 6 产品全景｜中电金信 2026 金融展｜中电金信从"看数据"到"做决策"
标准：GB/T 48000.3-2026 ｜ GB/T 43441.2-2026
资源：OpenKG ｜ cnSchema（⚠️ 须用 http，https 会跳转到无关站点）｜ CHPO/HPCH @ BMICC
学术：黄恒琪等. 知识图谱研究综述. 计算机系统应用, 2019, 28(6): 1-12. DOI 10.15888/j.cnki.csa.006915 ｜刘峤等. 知识图谱构建技术综述. 计算机研究与发展, 2016, 53(3): 582-600 ｜ CMeKG 中文信息学报

13.5 反方与成本

Atlan: Enterprise Knowledge Graph Pitfalls ｜ vonng: The Palantir Ontology Scam ｜工控网：工业知识图谱失败模式｜安全内参转 Gartner ｜虎嗅：本体论是技术幻觉？

13.6 论文

OG-RAG：arXiv:2412.15235（EMNLP 2025 Main）｜ LLM-Modulo：arXiv:2402.01817（ICML 2024）｜ Neuro-Symbolic Survey：arXiv:2508.13678（IJCAI 2025）｜ GraphRAG：arXiv:2404.16130 ｜ LightRAG：arXiv:2410.05779（EMNLP 2025）｜ Logic-LM：arXiv:2305.12295 ｜符号护栏：arXiv:2604.15579

13.7 本仓库内相关文档

docs/09_Research/RS02_外部智能体平台架构对照.md（六层逐层外部对照）
docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY15_术语基准本体语义层与对象层.md
docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY16_本体泛化数据动作与工作流.md
docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY20_角色卡与轻量本体架构.md
docs/01_System_Overall/SY21_统一角色技能动作架构.md
docs/01_System_Overall/SY22_角色技能应用统一任务架构.md
docs/02_Architecture/对象标准化与解耦总则.md
docs/02_Architecture/AR09_对象命名规范.md

13.8 本次核实的代码位置（第 8 节的事实依据）

位置	事实
`eai_agentplatform/backend-go/internal/model/action_definition.go:19`	`OntologyBindingJSON` 字段定义
`eai_agentplatform/backend-go/internal/skills/model/skill_definition.go:28`	同上（skill 侧）
`eai_agentplatform/backend-go/internal/store/seed.go:337,355,373,391,409,427,445`	种子播种 `OntologyBindingJSON` 共 7 处（另有 `:517` 属另一段种子块）
`eai_agentplatform/backend-go/internal/skills/api/validation.go:68`、`internal/api/action_definition.go:82`	仅做 JSON 合法性校验
（运行时）	排除 model / validation / seed / admin handler 后，零个读取方（全仓 22 处引用全部落在上述四类）
`eai_agentplatform/backend-go/internal/connectors/core/contracts/contracts.go:28,36`	`ActionDefinition`(:28) / `ObjectDefinition`(:36) 契约
`eai_agentplatform/backend-go/internal/specialists/runtime/task_runtime.go:269,279`	全仓唯一一处运行时读取对象目录（`definition.Objects[0]`，`UseDemo: true`）
`eai_agentplatform/backend-go/internal/specialists/model/specialist.go:23`	`Version string` —— 展示用自由文本，非版本快照
（四张关系表）	`specialist_skill_binding` / `xapp_specialist_binding` / `xapp_skill_binding` / `specialist_connector_binding` 各 0 处
`eai_agentplatform/backend-go/internal/model/action_definition.go:15-18`	`RiskLevel` / `ApprovalMode` / `AuditLevel` / `ExposedToUser` —— 治理字段齐全
`eai_agentplatform/backend-go/internal/repository/action_definition.go:36`	`GetByKey` 写好且有唯一索引，零调用方；`ActionDefinitionRepo` 仅被 `api/action_definition.go`（后台 CRUD）引用
`eai_agentplatform/backend-go/internal/specialists/runtime/records.go:230`	`inferRiskLevel` —— 从技能中文名子串猜风险等级（运行时实际用的那套）
`eai_agentplatform/backend-go/internal/specialists/runtime/records.go:216-221`	`approvalState()` 只返回 `ready` / `pending`
`eai_agentplatform/backend-go/internal/specialists/runtime/records.go:82,112`	`buildPermissionRecords` 里 `approval_required` 是另一个结构的 bool 键，与 `approval_state` 无关
`eai_agentplatform/frontend/src/specialists/runtime/specialistFlow.js:58,186`	判断 `approval_state === 'approval_required'` —— 后端产不出该值，「需要确认」永不触发
`eai_agentplatform/frontend/src/views/workbench/MarketPage.vue:1041`、`StudioPage.vue:1471`	前端另有 `approval_required` / `not_required` 与 `pending_design` 两套词表

62 KiB Raw Permalink Blame History Unescape Escape