本体及其应用平台
从需求调研到 WorkBuddy Demo 演示

术语对照

这份稿子怎么读

本体平台的难点不在技术组件，而在「一条决策链路要同时穿过五个层」。 所以本稿按真实交付顺序展开，而不是按产品功能目录展开。

用一句话定义本体：不是数据库，是业务世界的可计算模型

本体同时回答四个问题——世界由什么组成（对象与关系）、什么算数（属性与规则）、能改什么（动作）、谁能改（权限）。这四件事必须一次建好，缺一个都长不出应用。

为什么现在必须做：RAG 的天花板与 OAG

RAG 让模型「读到片段」，但业务决策需要的是「知道此刻有哪些对象、处于什么状态、允许做什么动作」。 这正是本体增强生成（Ontology-Augmented Generation）要补的缺口。

本体不是知识库的另一种写法：六类体系横向对照

全文检索、LLM wiki、知识图谱、向量 RAG、GraphRAG、本体平台—— 它们的分歧不在「检索准不准」，而在能不能改世界。下表每格都取自该技术的官方文档或论文原文。

全文检索：只认字面，但最便宜也最稳

像书末尾的索引表：先按词找到页码，再按「这个词在这页出现几次、这词在全部书里常不常见、这本书有多长」打分排序。 它比较的是词，不是含义。

LLM wiki 助手：先让模型写手册，再在手册上问答

大语言模型（LLM，Large Language Model）先把一堆文档或代码读一遍，自动整理成一本人人能查的手册， 再基于这本手册回答问题。入门成本最低，也最容易被误当作事实来源。

知识图谱：把「谁和谁有什么关系」画成一张网

适合回答「这个供应商出问题，会牵到哪些物料、哪些订单、哪些产线」这类关系型问题。 官方对它的定义是「存储、组织、访问相互关联实体的设计模式」。

向量 RAG：按「意思最近」找段落，喂给模型作答

检索增强生成（RAG，Retrieval-Augmented Generation）：把文字变成一串数字（向量）， 提问时找语义最接近的几段塞进上下文。它解决「能不能拿到外部知识」，不解决「世界知识怎么更新」。

GraphRAG：先让模型把文档读成网，再给每个圈子写小结

图检索增强生成（GraphRAG，Graph Retrieval-Augmented Generation）。 它存在的理由就是补向量 RAG 的洞：论文原话——「RAG 在面对针对整个语料库的全局性问题时会失败」。

本体平台：企业世界的镜像，每样东西能看、能改、有主人

前五种都在解决「怎么找到话说」。本体解决的是另一件事：此刻真实状态是什么、允许谁改、改完怎么收场。

决策树

五个常见误解，与「必须上本体」的五个硬信号

代价最高的误区：把本体当成数据库建模

「我们有哪些系统、哪些表」是起点不是答案。本体建模的正确单位是「一次决策」—— 它天然要求数据、逻辑、动作、权限同时到位，缺一件就暴露出来。

Palantir 的建模范式：数据 / 逻辑 / 动作 / 权限 四位一体

这四者不是四个模块，而是同一个对象的四个面。任何一面单独存在都不构成可用的本体。

调研访谈脚本：四类问题

对象是「业务方本来就在说的名词」，不是设计出来的。所以访谈的目标是录下他们的动词和名词。

从一条决策反推本体：决策五问

拿访谈记录里的每一条决策跑一遍五问，答案连起来就是本体草案。

需求盘点表：一张表定范围

八列，一行一条决策。这张表同时是建模输入、验收清单和汇报材料。

范围控制与开工检查单

本体项目最常见的失败方式是「平台先建好，业务再进来」。用四条硬标准砍需求，用 12 项绿灯决定要不要开工。

三层结构：语义 / 动能 / 动态（以及另外两种「三层」）

Palantir 文档里「三层」有三种不同口径，混用会吵架。先消歧，再讲产品叙事的那一层。

对象类型：三种标识 + 两个键，决定后面一切

对象身份的稳定性是本体的地基。RID、ID、API name 各有用途，主键与标题键一旦选定就很难改。

属性进阶：结构体、值类型、派生、只读与强制控制

属性不是字段列表。它承载口径（值类型）、组织方式（结构体）、计算（派生）和治理（必填 / 只读 / 强制控制）。

关系建模：三种实现 + 「过程对象 / 日志对象」范式

链接不是外键的同义词。选错实现，遍历性能、可写性和权限继承全都会出问题。

// 过程对象：一次流程实例
Process    { processId PK, caseRef, state, startedAt, closedAt }

// 日志对象：一次状态迁移
ProcessLog { logId PK, processRef FK,
             state, timestamp, actor, reason }

// 本稿 demo 的过程对象：一次发货
Shipment { id PK, sales_order_id FK, from_region_id FK,
           to_customer_id FK, departed_at, eta_at, arrived_at,
           status ∈ {in_transit, delayed, delivered} }

// 「延迟」不是贴上去的标签：eta_at < 演示日 且未到达，状态由时间推出

// 官方强调：其实只需要三列（对象主键 + 当前状态 + 时间戳）

接口与共享属性：让「不同东西」能被同一套逻辑处理

接口是本体里最被低估的抽象。它给多个对象类型一份共同契约，于是检索、遍历、动作参数和 AI 工具都能写一次。

数据接入与索引：对象不是表，中间有一条管道

数据集 → 对象是可查性的关键一跳。理解这条管道，才能解释「为什么改了源数据界面没变」「为什么全量重建会失败」。

数据健康、血缘与「数据即代码」

Titan 系列第一部分讲的就是这件事：本体能不能上线，取决于你敢不敢让别人相信里面的数。

把健康度建成对象，而不是建成告警

告警会淹死人；对象不会。健康检查产出的是一条 DataQualityCheck 对象 （关联数据集 / 对象类型 / owner / 状态 / 最近通过时间）， 于是它能被检索、被列表化、被动作修改、被 AI 当上下文引用——「这条数据可信吗」变成一个可查询问题。

分支工作流四步

• 在分支上改管道 / 本体
• 对比：schema diff + 样本对象 diff + 受影响应用清单
• 评审合并
• 保留回滚点

本体迁移（类型改名、主键变更、属性迁移）是破坏性变更，必须走显式迁移而不是「直接改」。

Action：本体的手

动作 = 一次受控的、可审计的业务变更。它是「规则 + 参数 + 谁能提交 + 提交后干什么 + 出错怎么办」的打包。

Logic 与 Action 都「像预定义函数」，为什么必须分开

区别不在形态，在契约：Logic 回答「是多少 / 该怎么办」，可以很复杂但没有写入权； Action 回答「就这么改了」，简单但有事务、权限与审计。

权限层：三条轴，两个陷阱

本体的安全不是「谁能登录」，而是「谁能看见哪一行哪一列、谁能提交哪个动作」。

检索层：让对象「找得到」，AI 才「用得上」

搜索不是免费得到的。哪些属性可搜、怎么排、向量怎么用、混合结果怎么合，都要显式设计。

能力	用途	设计要点
关键词 / 排序检索	精确名、编号、短语	可搜索属性要显式挑；不要指望全属性默认生效
语义检索（向量）	描述、工单文本、故障现象	向量维度受上限约束，超限直接不可用；只用于相似匹配
混合检索 + RRF	既要准又要全	倒数排名融合，权重需按业务实测调
HyDE / 查询扩展	用户问法与库内表述不一致	生成假想文档再检索，提召回但增噪声
对象集遍历	沿链接跳一跳	扇出规模决定是否走内存 / Spark 路径

OAG 的检索三步

• 把自然语言映射到对象类型 + 属性 + 关系（本体给了词表，LLM 不用猜 schema）
• 检索得到对象集，而不是文本分片
• 对象集成为下一步上下文：可继续遍历、可直接喂给动作参数

把「不可检索」当缺陷管理

每个对象类型列一份检索验收清单：主要查询场景是什么？命中率如何？ 检索不到的业务问题，等于模型不存在。

性能红线

• 预估结果集规模决定执行路径
• 大范围遍历前先加过滤而不是先排序
• 给 AI 的检索工具必须带返回上限

动态层：模型、预测与情景推演

模型不是外挂。要么它的输出落成属性能被动作使用，要么它作为逻辑工具被调用，否则接了也只是个展示。

重点：五件一次做不对、后面全是债的事

判断「是不是重点」的标准只有一条：以后能不能便宜地改。这五条都不能。

难点一：粒度——太粗没人用，太细跑不动

官方给的四条原则能定方向，但落不到「这个字段到底建不建对象」这一层。下面是可操作的判据。

难点二：同一个东西在三套系统里，怎么变成一条

并购成长的企业几乎必踩。这一步没做扎实，后面所有聚合、所有智能体回答都在算错的东西。

难点三：模式一定会变，难的是分清可逆与不可逆

本体上线三个月后必然要改。真正的问题不是「能不能改」，而是哪些改动没有回头路。

难点四：性能不是调出来的，是建模时定出来的

同一个查询，结果集规模决定它走哪条执行路径。建模时不估规模，上线后只能加机器或砍功能。

痛点：数据质量不是「尽量干净」，是六个可判定的要求

本体对数据质量的要求比报表高一个量级——报表算错只是看错，本体算错会被写成新的业务事实，再回写源系统。 六维是数据管理领域的通用划分，右三列落到本体的具体机制。

解法：把质量做成闸门和对象，而不是做成周报

质量问题一定会发生。区别只在于：它在进入本体之前被拦住，还是在业务出错之后被发现。

闸门上六个反直觉的细节，每一项都容易引发故障

这些不是理念问题，是官方文档里写明的行为。知道的人五分钟避开，不知道的人排查一天。

常见问题速查：六类，每条都有明确规避动作

与难点不同，常见问题是「知道就不会踩」的。这一页适合当代码与模型评审的固定检查项。

最容易被低估的难点：本体是组织问题，不是技术问题

技术上的难点都有解法；组织上的含糊会把所有难点放大十倍，并且表现为「平台不好用」。

九步方法论：每步的完成定义与长期指标

把前面所有判据压成一条流水线。关键在完成定义——没有它，「做完了」永远是主观判断。

运维与演进：避免本体在使用中退化

交付不是终点。缺少归属、服务水平目标与变更纪律，本体三年后必然退化为无人敢信的死系统；随之而来的是无边界的技术支持。

Agent 骨架：会话 / 上下文项 / 事件 / 状态迁移

智能体不是提示词，是一台有状态机。四个概念把它变成可观测、可回放、可审计的工程对象。

面向业务的智能体装配：检索上下文 + 工具 + 应用状态 + 引用

低代码智能体构建器（Chatbot Studio，原名 Agent Studio）的四个配置面，正好对应本体平台的四种能力。

工具设计准则：让模型只会按按钮，不会自己写 SQL

工具是给模型用的 API。它的质量决定智能体的上限——描述不清、参数过宽、无确认，就会出现「模型很自信地做错事」。

{
  "name": "submit_discount_plan",
  "description": "当批次库龄>90天且毛利低于阈值时使用；
                一次只处理一个批次。不要用于询价。",
  "input_schema": { "batchId":{"type":"string"},
                     "discountPct":{"type":"number","max":30} },
  "permission": { "action":"submit_discount_plan", "scope":"inventory" },
  "side_effects": ["ontology_edit", "notification", "wms_writeback"],
  "requires_confirmation": true,
  "idempotency": "required",
  "timeout_ms": 30000
}

六层沙箱：智能体在哪里跑，出了事能圈多大

「沙箱」不是一个容器，而是六层独立边界。任何一层缺失，事故半径就会扩散到全平台。

没有评测与可观测，AI 就是不可发布的功能

智能体的质量是统计量，不是印象。评测套件负责「上线前敢不敢」，可观测负责「上线后知不知道」。

外部 Agent 与 IDE 怎么接进来：四条路

「让 ChatGPT / Claude / 自研 Agent 用我们的本体」在 Palantir 体系里是四条不同的路，能力面、身份模型和适用场景都不一样。

# 构建侧：把 Palantir MCP 挂进编码 Agent（以 Claude Code 为例）
export FOUNDRY_HOST="<your-foundry-hostname>"
export FOUNDRY_TOKEN=<token>   # 在 Foundry 仓库内可省略，用 Git token 引导
claude mcp add palantir-mcp --scope project \
  -e FOUNDRY_TOKEN='${FOUNDRY_TOKEN}' \
  -- npx "-y" "palantir-mcp" \
     "--foundry-api-url" "https://$FOUNDRY_HOST"

{
  "mcpServers": {
    "my-ontology": {
      "type": "http",
      "url": "<ontology-mcp-server-url>",
      "headers": {
        "Authorization": "Bearer ${env:FOUNDRY_TOKEN}",
        "Accept": "application/json, text/event-stream"
      }
    }
  }
}

Onyx Incorporated：官方虚构公司，一条完整决策闭环

Palantir 在文档里用一家虚构的医疗设备制造商 Onyx 演示「决策中心本体」。 剧情：主要供应商中断 → 关键原材料短缺 → 外科口罩需求上升 → 生产排期吃紧 → 大量客户订单受影响。

总图：本体是中间那一块，上下都是它的朋友

这张图就是「四位一体」

数据 / 逻辑 / 动作 / 安全四合一的可视化。任何自建平台的架构图，都应该能被这张图的六个区块逐一对应； 对不上，说明有面缺了。

三个消费面 = 三种交付形态

分析工作流、智能体、以及被产品化/SDK 化的对外接口。同一本体，三种用法，不必各建一套数据。

Systems of Action 是关键术语

本体不只是被读，它要能驱动下游执行系统。没有这一组，项目就止步于「看得见」。 Onyx 的下游包括 WMS、三套 ERP、生产计划系统。

数据层：把五个系统变成八个对象类型

Plant Object 示例属性

Status · EnergyConsumption 12000kWh · CycleTime 45.2 · Issues 17 · PlantUptime 99.98% · EfficiencyScore 88

三个可借鉴点

• 对象数量克制：8 个类型撑起一条完整链路，不是 80 个。
• 导航即分析：从「口罩生产风险」一路跳到受影响客户订单，靠的是链接而不是新查询。
• 决策也建模：Decision Data 让「谁在什么上下文做了什么决定」可查询。

安全随范围变化

财务等敏感字段默认隐藏，响应范围扩大时自动控制可见性——权限不是开关，是随上下文变化的函数。

逻辑层：模型不是 prompt 里的文字，是可调用节点

与「文档问答」的分水岭

普通 RAG 助手把规则写在提示词里；Onyx 把预测模型、分配模型、生产优化器接进本体， 成为可组合的计算资产。人用的和 Agent 用的是同一套。

Scenario = 隔离沙箱

模拟结果放进本体情景，不直接改生产数据。分析师可以快速跑多组替代物料方案而不担心污染。

节点命名法

动词 + 业务名词（Estimate / Simulate / Calculate / Score / Assess）。 这套命名直接可当 LLM 工具名，无需二次映射。

可迁移做法：把「算一下」类逻辑做成 5 个以内的小节点，而不是 1 个大引擎。小节点可组合、可评测、可被 Agent 精确调用。

动作层：Disruption Bot 提议，人类审核，写回 WMS / 三套 ERP / 排程

下游系统	写回方式
WMS	API 更新
三套 ERP	原生本体连接器，遵守各系统安全约束
生产计划系统	合并 flat file，异步导入

四条控制机制

• AI 默认只能 staged 动作，人审后才提交。
• 只有充分测试、可信的流程才允许自动闭环。
• 所有动作有精细日志与审计。
• Agent 权限随信任逐步调节，即时反映到所有本体工作流。

剧情细节

Disruption Bot 扫描本体数据、历史行动的事后报告与可用再分配模型， 找到了分析师没考虑到的新方案（用了较新模型）——然后交人审核。这就是 human-AI teaming 的落地形态。

「自动化程度像拨盘而不是开关」是官方叙事里最好的一句产品哲学：同一套动作定义，可以按信任度调节自动提交的门槛。

学习层：决策血缘成为训练数据

与数据目录 / 语义层的根本区别

它把决策本身变成可学习的数据：每个数据元素、每个逻辑资产、每次动作评估都被捕获成端到端血缘。

血缘的三种下游用法

• 作为微调模型的训练语料
• 提炼成 Agent 提示词里的原则
• 作为审计与事故复盘的证据链

自建时怎么起步

最小血缘记录五元组：(who, when, inputs_snapshot, chosen_option, outcome_metric)。 先记下来，后面才有东西可学。

四步闭环回看

识别（数据）→ 模拟（逻辑 + 情景）→ 编排（动作 + Agent）→ 捕获（血缘）。 这是本稿第二部分三层结构在本案例中的投影。

Titan 实操一：从原始数据集到可查对象（Data Tools）

「Building with Palantir AIP」系列的第一集，演示同一条链路的工程实现细节：接入、健康、分支、安全、逻辑与调试。

• 接入即建血缘，不用手工维护数据字典。
• 健康检查建成对象，责任人可被自动路由。
• 管道与本体改动走分支，diff 后再合并。
• 安全配置在建模界面里可见可改，不藏在后台。
• 逻辑编排提供调试器，块级输入输出可看。
• 应用层直接用对象集，不额外做一套查询 API。

Titan 实操二/三：RAG → OAG 的实证，与过程挖掘

• 同一套工具，人与 Agent 共用——避免出现「人用的逻辑」和「AI 用的逻辑」两套真相。
• Modeling Objective：一次训练 27 个模型变体，固定评估子集比较，配评审关卡，暂存 → 生产。
• 预测即工具：Prophet 需求预测注册为逻辑工具，LLM 在推理中按需调用而非预先算好。
• 供应链 co-pilot：AIP Logic 把检索、计算、动作串成一条可解释流程。

• 范式：过程对象 + 日志对象（见第 26 页代码），零流程引擎依赖。
• 产出：真实流程图、瓶颈耗时、返工率、例外路径，全部是可查询对象。
• 与 MRO 设备场景结合：机器状态迁移历史直接暴露「谁在绕过流程」。
• 信用挂单案例给出「规则 + 例外 + 审批」三件套的完整建模样例。

Onyx 与 Titan 是同一「虚构医疗用品公司」演示谱系的两个命名：Onyx 用于产品文档（why-ontology），Titan 用于 Building with AIP 博客与视频系列。教学上取前者讲架构、取后者讲实操。

Top 10 常见问题与硬限制：把「以后会出问题」写成今天的约束

本体的常见问题高度集中：身份、写路径、索引、权限、限额五类。提前知道数值，比事后重构便宜一个数量级。

自建平台：六面参考架构 + 十个必须早做的决策

路线图

现场视频：官方 AIPCon 6 宣传片

活动混剪，并非 Onyx 专属演示；完整直播需登录官方频道。

完整 Demo：把生产本体接到 WorkBuddy 上

前面所有页面讲「本体是什么、怎么建」；这一章讲「建好之后，一个真实的办公型 Agent 客户端怎么把它用起来」。 场景为虚构，配置形态取自双方官方文档。

端到端架构：连接器只是管道，边界留在本体

本体侧准备：只暴露三个对象、两个动作、两个函数

接入范围越小，Agent 越准。这一步的产物是一张「资源清单」，它同时就是权限清单和测试清单。

WorkBuddy 侧：一个自定义连接器 + 两个办公连接器

// 自定义连接器（示意）：经网关接入生产本体
{
  "mcpServers": {
    "corvina-ontology": {
      "type": "http",
      "url": "https://mcp-gateway.intranet.corvina.com/ontology",
      "headers": {
        "Authorization": "Bearer ${env:CORVINA_MCP_TOKEN}",
        "Accept": "application/json, text/event-stream"
      }
    }
  }
}

能力面按版本分层：个人版只有连接器与对话内 widget；企业版另有侧栏自建菜单（iframe，可承载整套前端）、Buddy 应用与默认落地页。讨论企业版时，不应把「只有聊天接口」当作上限。

认证与权限：三档落法，逐人权限是分水岭

本体侧的 MCP 服务没有独立认证体系，走应用的 OAuth 2.0；两种授权模式对应两类场景。 客户端能不能跑授权码流程，决定了你落在哪一档。

空间呈现：同一份口径，画出来的权限

地图不是装饰。它把「仓、在途、目的地」放在同一张图上，而可见范围由同一条行级策略决定。

口径同一份

地图、队列与对话读的是同一份对象与同一套函数，不另建汇总表。

权限是画出来的

可见性来自行级策略；换一名专员，整片区域随之改变。

点开是对象

弧线打开一张真运单，目的地打开客户；每个图形都能回溯到对象。

第一幕：读——「今天哪些单该放」

这一幕证明一件事：Agent 拿到的是对象集与实时计算结果，不是文档片段。

第二幕：写——Agent 暂存，人确认，动作落地

写操作是整章的分水岭：能不能写、怎么写、写错怎么办，全部在这一幕演示完。

第三幕：从一个人到三个专员——企业版治理

个人验证只是原型；能被管理员复制、被审计、被限流，才叫上线。

官方支持 vs 需要自建

换成知识库会怎样：六类问题的对照

可复用配置卡

一页总结：本体 = 决策的可计算化

© 瀚好智慧科技 · hanhao.co