碎片洞察与问题记录

学习过程中随时记录的想法、疑问、灵感

2026-05-20

两张图的核心信息

图1：Palantir AIP Ontology

结构：对象（名词）+ 关系（连接）+ 行动（可执行操作）
评论里写"有点像知识图谱里的三元组"——准确，但 Actions 才是真正的差异点
完整链路：多源数据 → Foundry → Ontology → AI 应用层（Chatbot/Agent/Workshop）

图2：FDE（Forward Deployed Engineer）

核心定位：驻场工程师，填补产品与客户之间的鸿沟
四种身份：技术专家 + 客户伙伴 + 问题解决者 + 推动者
五步流程：调研 → 设计 → 实施 → 部署 → 持续优化

初步洞察

Palantir 的护城河不是大模型，而是Ontology + FDE 的组合——这两件事大模型厂商做不了，因为需要深度嵌入客户业务。
OntoFlow（上一篇微信文章）想做的事和 Palantir 非常相似，但走"1人业务+1人开发"的轻量路线，能否真正替代 FDE 模式？这是个值得追问的问题。
"AI 落地失败"很少是技术问题：数据不通、语义不对、没人推、业务不信——这些才是主因。Ontology + FDE 正是在解决这些非技术问题。

2026-05-20（深度研究 Ontology 后）

重要的新发现

Interfaces 于 2024-08-27 以 Beta 形式发布（官方公告），是 Ontology 多态性的关键支撑。

类似 OOP 里的接口/抽象类，提供跨 Object Type 的多态性
实际价值：一个 Action 可以同时作用于多种对象类型，AI Agent 查询时不需要知道具体类型
这对建模复杂业务域（如各类工单、各类审批）非常有价值

Functions 是被低估的组件

图解里没有突出，但实际上 Functions 是 Ontology 的"大脑"
它用代码（TypeScript/Python）封装复杂业务逻辑，既可以做计算，也可以作为 Action 的执行引擎
AIP Logic 中的 AI 推理节点本质上就是在 Functions 里调用 LLM

OAG vs RAG 的核心差异

RAG：检索文本 → LLM 生成文字答案 → 人再去手动执行
OAG：查询业务对象 → 确定性匹配 → 直接触发 Action 执行
简单说：RAG 是"AI 告诉你该怎么做"，OAG 是"AI 替你做了"

权限是从底层设计进去的，不是补丁

数据层权限 → Ontology 权限 → OSDK Token 权限，三层叠加
AI 看不到人看不到的数据——这不是口号，是架构约束
这对企业安全合规至关重要，也是很多国产平台的短板

产生的新问题

[ ] Palantir Ontology 和 W3C OWL/RDF 标准本体的关系？Palantir 是否与标准兼容？
[ ] Functions 的性能上限是什么？大规模 Object Set 计算会不会成为瓶颈？
[ ] Derived Properties 是实时计算还是预计算？对查询性能的影响？
[ ] OSDK 的 Token 权限和企业 SSO/LDAP 怎么集成？

2026-05-20（第二轮独立审视后的修订）

触发动机

第一轮笔记完成后做了一次独立研究者视角的批判性审视，识别出三类问题：

概念框架缺失：Foundry / Ontology / AIP 三者层级关系没讲透，全文出现"Palantir AIP Ontology"这种不严谨的叠加叫法
追捧倾向：几乎全是 Palantir 视角的赞美，缺少商业批评、锁定效应、FDE 模式局限、真正的替代方案对比
若干事实性细节缺乏出处：Interfaces 引入时间、Function-backed Rule 的互斥规则、Functions 多语言体系归属、OSDK Python API 形态

本轮修正动作

README 顶部新增"研究前提"：明确 Palantir 不进中国市场、本研究目的是方法论借鉴
01 新增 §"前置澄清：Foundry / Ontology / AIP 是三层不同的东西"，钉死三者层级
01 新增 §12"局限、批评与替代方案"：商业模式批评、锁定效应、FDE 模式演变、OAG 相对性、Databricks/Fabric/Snowflake/开源/国产方案对比表、地缘政治前提、公开争议案例
01 §3 / §4 / §5 / §6 / §7 / §8 多处增加 [待核实] 标注或精确化表述（OAG 不是官方术语、AI 看不到人看不到的数据软化为工程化表达等）

衍生的新追问（留待后续阶段处理）

[ ] Palantir 价格区间的可信公开数据来源（年报、招股书、媒体披露），用作 §12.1 的引用证据
[ ] FDE 模式在 Palantir 内部正在如何被 AIP/OSDK 替代——是否有官方表态或财报口径变化
[ ] 国内"自建 Foundry+Ontology+FDE"的工程项目，现实成本与人力投入估算
[ ] §12.7 列出的 NHS / JPM 案例的具体争议细节与时间线（用于 03 文档的失败案例展开）

2026-05-20（D1 深化：FDE 演变弧线与中国移植分析）

核心新洞察

FDE 的内嵌矛盾：越优秀的 FDE 越难复制——判断力和信任资本天然无法转移。这不是可以靠流程优化解决的问题，而是人力密集型模式的结构性上限。

知识晶体化路径：FDE 的真正价值不是"完成工作"，而是"把工作变成工具"。每一个被产品化的 FDE 经验，都降低了未来的 FDE 依赖度。这个反馈回路是 Palantir 商业模式的护城河，也是它能规模化增长的底层逻辑。

中国移植的核心障碍：不是技术栈，不是成本，而是采购目标的根本差异——"建能力" vs "买交付物"。这个差异在合同签订那一刻就已经决定了后续会走向哪种变形。

从 02 文档迁入的追问（原"待深入"节）

[ ] Palantir FDE 的选拔标准和培养路径（偏百科，优先级低）
[ ] FDE 与 CSM（客户成功经理）的协作模式（偏百科，优先级低）
[ ] 国内有哪些公司在践行类似的"嵌入式工程师"模式（D1 收尾时值得做一次 tavily-search）

D1 新产生的追问

[ ] Palantir 是否公开过 FDE 人力/客户比？从财报看 FDE 密度的变化趋势（可用于验证"FDE 占比在下降"的推论）
[x] AIP Assist 的当前能力边界：已确认——它是 LLM 驱动的文档/平台导航助手，能回答 Foundry 使用问题，支持上下文感知（知道你在哪个应用），可添加自定义文档源。但它不能操作 Ontology（官方文档明确"does not access your data"），不替代 FDE 的建模和集成工作。来源：官方 AIP Assist 文档
[ ] 变形 1（驻场外包）的退出机制：什么合同结构能从源头防止这种退化？

2026-05-20（D2 深化：非 Palantir 路径 + 规模化坑 + 行业视角）

核心新洞察

"胶水层"是开源替代方案的真实成本：每一层（语义/操作/治理）单独都可以找到 80% 的替代品，但 Palantir 的价值正在于三层的一体化——权限、可见性、Action 在同一系统里保持一致。开源路线省许可费，花的是工程时间和集成复杂度，没有免费午餐。

最难复制的是治理层的"架构保证"：开源方案的权限控制是"人工约定"，Palantir 是"系统保证"。这个差异在 POC 阶段看不出来，规模化后会成为最大的隐患。

行业差异的本质是"谁拥有推动权"：制造的障碍是 OT 系统；金融的障碍是合规要求；政务的障碍是数据权属。三个行业的 AI 落地失败，表面原因不同，深层都是"技术问题之外的组织/权力问题"。

从 03 文档迁入的追问（原"待展开"节）

[ ] Ontology 建模的实操步骤（偏百科，优先级低）
[ ] 如何评估一个 AI 落地项目的 ROI（通用方法论，去掉 Palantir 三字也成立，优先级低）

D2 新产生的追问

[ ] dbt Semantic Layer 和 LlamaIndex Knowledge Graph 的实际集成案例：有没有人真的用这两个搭出了"业务对象"层？
[x] Dify 当前版本的工具调用能力边界：已确认支持 HITL——v1.13.0（2026-03-03）引入 Human Input 节点，工作流可暂停等待人工审批/修改/转发。来源：Dify 官方博客
[ ] 制造业 OT/IT 融合的主流解法：Kepware / OPC-UA 这类协议网关在国内的实际落地情况
[ ] 政务联邦学习的落地案例：国内有没有真实的跨部门联邦学习实施，不只是 POC？（用于 03 的落地建议）

2026-05-20（Q1/Q2/Q3 质量修订）

本次修订内容

02-FDE 前半升级（路线 B）：

"FDE 如何开展工作" → 重写为"四个身份为什么缺一不可"，用逆向拆解表格替代 ASCII 图
"典型工作流程" → 保留骨架，核心改为"FDE 特有的是步骤之间的双轨判断密度"
删除"FDE 为客户创造的价值"节（销售 PPT 语言，无分析价值）
"FDE 适合场景" → 改写为"FDE 不适合的场景"（边界比范围更有意义）
顶部加"阅读前提"承接句（02 = 让 Ontology 语义层在组织里活起来的角色）

03-落地 Step 3 升级：

用制造业物料追踪具体场景，对比"传统 SQL 表 vs Ontology 关系显式化"的差异
让读者理解 Ontology 为什么能让 AI"理解业务上下文"而不只是查数据
顶部加"阅读前提"承接句（03 = 没有 Palantir 的团队能拼出类似路径吗？坑在哪？）

修订产生的洞察

"拆掉身份法"是理解复合角色的有效框架：不问"这个角色有什么能力"，而问"缺掉任意一个能力后会退化成什么"——退化终态就是"客户已有的替代品"，这才能说清楚为什么需要这个新角色。这个思路可以复用到任何"复合型岗位"的分析上。

Ontology 的核心价值在关系显式化，不在数据建模：SQL 表也是数据建模，差异在于 Ontology 把"业务实体之间的关联"提升为一等公民——AI 沿关系遍历，不需要人工写查询逻辑。这个具体化之后，"为什么 Ontology 让 AI 理解业务"就不再是抽象说法了。

2026-05-20（D3：04 行动指南初版）

核心洞察

"你的场景配不配得上这个复杂度"比"能不能搭"更重要：Palantir 范式的三层一体化确实可以拼出 70-80%，但大多数团队的真实需求其实是 RAG + 工作流就够了。过早追求"Ontology 级"的架构，是在为不需要的复杂度买单。

三档路径的核心判断维度不是技术，是组织和场景：数据复杂度、场景需求、组织成熟度——三个维度任一达到"中"就需要升级路径。其中"组织成熟度"（有没有桥梁角色）是最容易被忽视的。

"谁来建模"是路径 B/C 的生死线：语义建模不是 DBA 建表，是业务翻译。没有桥梁角色就不要走路径 B。

新产生的追问

[ ] 三档路径的"撞墙信号"需要实际案例验证——有没有团队在路径 A 撞墙后成功升级到路径 B 的公开经验？
[ ] 国内 DataHub / dbt Semantic Layer 的实际落地案例——有没有企业真的用它做了"业务对象"层？[待核实]（搜索未找到公开案例，可能需要社区渠道打听）
[ ] 路径 B 的"最小拼法"工具链成本估算需要更精确——3-6 人月是粗略判断，实际取决于数据源数量和治理复杂度

2026-05-20（Q4 事实核实）

核实结论

问题	结果	来源
Interfaces 引入时间	2024-08-27 Beta 发布	官方公告 2024-08
Function-backed Rule 互斥	官方确认："a function rule cannot be combined with other Ontology rules"	官方文档
Functions 多语言体系	概念统一（TS v1/v2 + Python），但特性支持不同	官方文档
OSDK Python API 形态	`client.ontology.objects.Type.where(Type.object_type.prop == value)`	官方文档
AIP Assist 能力边界	文档/平台导航助手，不操作 Ontology，不替代 FDE	官方文档
Dify HITL 支持	v1.13.0（2026-03-03）引入 Human Input 节点	官方博客
FDE 演变阶段时间节点	未核实：无公开资料精确划分	—
国内 DataHub/dbt 落地案例	未核实：搜索无果	—

2026-05-21（05-Ontology 工程落地模式）

核心新洞察

"两端有了，中间缺"是工程落地最隐蔽的陷阱：多数团队的问题不是没有数据底座，也不是没有 Agent 平台，而是两者之间缺一个语义执行层——负责把技术概念翻译成业务语义、暴露受控的 Function/Action、保证每次 AI 执行都有审计。这个"中间层"的缺失，才是幻觉严重、权限乱、业务不敢放权的根本原因。

"LLM 只能申请，平台才执行"是受控执行的最小模型：一旦 LLM 自己调 API 写数据，就失去了前置条件、HITL、审计的保证。两步式（申请 → 执行）不是麻烦，是安全边界。类比 Unix：进程请求权限，内核决定是否允许，LLM 是进程，执行引擎是内核。

GraphRAG 和 Ontology-driven 解决的根本是不同的知识问题：GraphRAG 假设"知识来自非结构化文档"，Ontology-driven 假设"知识来自人工审核的结构化本体"。前者重知识提取，后者重知识执行。两者不是竞争，是不同场景的不同工具。

语义索引层是被严重低估的建模工作量：技术选型（向量数据库、Embedding 模型）的影响远小于"每个本体元素的扩写文本写得好不好"。召回质量 80% 来自语义文本，20% 来自模型和检索算法——这个认知颠覆了"选个好向量库就够了"的惯性思路。

新产生的追问

[ ] 语义路由链中，Schema 强校验的粒度如何平衡覆盖率和误拒绝率？过严会拒绝合法查询，过松会执行错误语句
[ ] 子图边界变化时（新增实体类型），向量索引的增量更新机制如何设计，避免全量重建
[ ] 国内私有化 LLM（DeepSeek 本地部署等）在 NL→图查询生成质量上与 GPT-4o 的差距，是否影响语义路由链的可用性
[ ] 一致性分级 STRONG_ON_READ 的穿透读性能代价：如果 Action 的前置条件需要穿透多个业务系统，延时会不会超出可接受范围？

2026-05-25（发现 UModel 开源项目）

核心发现

阿里巴巴开源了 UModel（Unified Model），Apache-2.0，19 天前创建，今日仍在活跃合并 PR。

一句话定位：这是一个厂商中立的企业语义运行时——可以理解为阿里开源版的 Palantir Ontology 语义层，把分散的业务对象、关系、拓扑组织成 workspace-scoped 对象图，通过 MCP 暴露给 AI Agent。

与 Palantir 概念对照：

Palantir	UModel	备注
Object Type	EntitySet / DataSet	概念相同
Link（关系）	entity_set_link + `.topo` 查询	多了拓扑专属查询入口
OSDK	Go/Python/Java SDK（生成式）	契约驱动，不绑定平台
AIP Agent 接入	AgentGateway + MCP	用开放 MCP 标准，不锁定
Ontology Functions	Query Service（`.umodel`、`.entity`、`.topo`）	查询语言不同
Foundry 平台	不含	只做语义运行时，不做数据管道

当前活跃度（截至 2026-05-25）：

仓库年龄：19 天，Stars 62，Forks 10
6 个 PR 全部已 merge，今日刚合并热修复
4 个 feature branch 正在推进
Issue #7 是"多厂商生态参与"RFC，正在建社区治理

PR 工作内容速览

PR	类型	核心内容
#1	Bug fix	开发环境：conda/venv Python 探测 + vite 启动路径修复
#3	Feat	CI 能力门禁：Go 集成测试（capability gate + quickstart health）+ Playwright E2E
#4	Chore	品牌更名 OpenUModel → UModel（命名在 19 天内才定）
#5	Feat	支付网关故障排查示例：三层领域（business/platform/runtime）跨域关系建模 + runbook_set
#6	Feat	写入路径 schema 强校验：20 种 schema 嵌入 Go 二进制，umctl/REST/MCP 写入均校验
#8	Bug fix	CI 热修复：PR #4 改了 schema 文字未同步嵌入副本，一行修复

关键架构洞察（来自 PR #5 / #6）

PR #5 揭示了 UModel 最核心的使用姿势：

business.order_flow ──────────────────────────────────────┐
business.promotion ──triggers──► platform.config_change   │
platform.service ◄──affects── platform.config_change     │
platform.service ──runs_as──► runtime.workload ◄──────────┘

跨域链接类型示例：incident_impacts_service、service_calls_service、team_owns_service

PR #6 揭示了 schema 有两套存储（源头 expanded_schemas/ + 嵌入副本 internal/umodel/schemaspec/data/），自己改 schema 后必须执行 make schemas-embed，否则 CI 会报错。

对现有笔记的意义

04 篇路径 B（自建语义抽象层）：UModel 是目前国产开源里概念对齐度最高的参考实现，可以作为具体工具链填补之前的空白
01 篇替代方案表：国产开源一栏从"无直接对标"升级为 UModel
✅ 之前追问"国内有没有近似 Ontology 的开源实现"——已有答案

跟进实验路线图

Step 1  make quickstart → 跑通 demo，看 Web UI（Explorer / Query / Agent 视图）
Step 2  读 tests/integration/capability_gate_test.go → 理解完整 API 能力边界
Step 3  加载 incident-investigation sample，在 Web UI 走一遍跨域查询
Step 4  仿照 PR #5 结构，建一个自己业务域的 entity_set 模型包
Step 5  接 MCP：umctl agent discover → 连 Claude/Cursor 作为 Agent client

风险提示

API 不稳定：命名 19 天内才定，schema 字段名 PR #5 就写错过（src vs source），不适合生产依赖
社区体量小：62 stars，背后团队规模未知，核心 contributor 少
local.ladybug provider 依赖阿里内部运行时，私有化部署时该 provider 无法使用，只能用 file.memory

2026-05-25（启动 UModel 0~1 学习路线）

学习路线设计

针对 UModel 制定了 6 阶段学习路线，沉淀为 06-umodel-alibaba-semantic-runtime.md：

概念桥接（用 Palantir 词汇对照 UModel，30 分钟）
make quickstart 快速体验 Web UI（1 小时）
SPL 三种查询实践（.umodel / .entity / .topo，1 小时）
自定义 Model Pack 动手练习（电商订单场景，2 小时）
Agent 反射机制理解（MCP + __list_method__()，30 分钟概念）
批判性总结写入 06 篇笔记

核心认知更新

SPL 的 .topo 查询 + Cypher 支持是 Palantir 没有的：Palantir 的 Link 查询走 OSDK，UModel 额外提供图数据库级别的 Cypher 查询，更灵活但也意味着查询语法更复杂，需要额外学 Cypher。

__list_method__() 反射是 Agent 集成的关键设计：传统 Agent 框架需要把工具列表写死在 System Prompt 里，UModel 让 Agent 在运行时自己查"这个对象支持什么操作"，更接近真正的自主决策。但这要求 Agent 有探索-规划-执行的完整能力，对模型能力要求更高。

新追问

[ ] make quickstart 里的 demo 数据覆盖了哪几个领域（domain），与支付网关示例（PR #5）的业务场景有何不同？
[ ] SPL 的 series_decompose_anomalies 是内置算子还是外部插件？异常检测精度如何，和专用时序异常检测比怎么样？
[ ] __list_method__() 返回的方法列表是静态注册的还是运行时反射的？如果是静态注册，和传统 Function Calling 工具列表有什么本质区别？
[ ] file.memory provider（JSON 持久化）在数据量上限和查询性能上的边界在哪里？是否有 benchmark？

碎片洞察与问题记录 ​

2026-05-20 ​

两张图的核心信息 ​

初步洞察 ​

2026-05-20（深度研究 Ontology 后） ​

重要的新发现 ​

产生的新问题 ​

2026-05-20（第二轮独立审视后的修订） ​

触发动机 ​

本轮修正动作 ​

衍生的新追问（留待后续阶段处理） ​

2026-05-20（D1 深化：FDE 演变弧线与中国移植分析） ​

核心新洞察 ​

从 02 文档迁入的追问（原"待深入"节） ​

D1 新产生的追问 ​

2026-05-20（D2 深化：非 Palantir 路径 + 规模化坑 + 行业视角） ​

核心新洞察 ​

从 03 文档迁入的追问（原"待展开"节） ​

D2 新产生的追问 ​

2026-05-20（Q1/Q2/Q3 质量修订） ​

本次修订内容 ​

修订产生的洞察 ​

2026-05-20（D3：04 行动指南初版） ​

核心洞察 ​

新产生的追问 ​

2026-05-20（Q4 事实核实） ​

核实结论 ​

2026-05-21（05-Ontology 工程落地模式） ​

核心新洞察 ​

新产生的追问 ​

2026-05-25（发现 UModel 开源项目） ​

核心发现 ​

PR 工作内容速览 ​

关键架构洞察（来自 PR #5 / #6） ​

对现有笔记的意义 ​

跟进实验路线图 ​

风险提示 ​

2026-05-25（启动 UModel 0~1 学习路线） ​

学习路线设计 ​

核心认知更新 ​

新追问 ​

碎片洞察与问题记录

2026-05-20

两张图的核心信息

初步洞察

2026-05-20（深度研究 Ontology 后）

重要的新发现

产生的新问题

2026-05-20（第二轮独立审视后的修订）

触发动机

本轮修正动作

衍生的新追问（留待后续阶段处理）

2026-05-20（D1 深化：FDE 演变弧线与中国移植分析）

核心新洞察

从 02 文档迁入的追问（原"待深入"节）

D1 新产生的追问

2026-05-20（D2 深化：非 Palantir 路径 + 规模化坑 + 行业视角）

核心新洞察

从 03 文档迁入的追问（原"待展开"节）

D2 新产生的追问

2026-05-20（Q1/Q2/Q3 质量修订）

本次修订内容

修订产生的洞察

2026-05-20（D3：04 行动指南初版）

核心洞察

新产生的追问

2026-05-20（Q4 事实核实）

核实结论

2026-05-21（05-Ontology 工程落地模式）

核心新洞察

新产生的追问

2026-05-25（发现 UModel 开源项目）

核心发现

PR 工作内容速览

关键架构洞察（来自 PR #5 / #6）

对现有笔记的意义

跟进实验路线图

风险提示

2026-05-25（启动 UModel 0~1 学习路线）

学习路线设计

核心认知更新

新追问