Palantir低代码企业应用OntologyWorkshop数据智能
Palantir Workshop 深度解析：Ontology 驱动的低代码应用构建平台
深入分析 Palantir Workshop 如何通过 Ontology 绑定实现低代码应用构建，以及为什么它与传统低代码平台本质不同。
Coomia 团队发布于 2025年4月15日17 分钟阅读
分享本文Twitter / X
#TL;DR
- Palantir Workshop 是一个低代码应用构建平台，但与 OutSystems/Mendix/PowerApps 本质不同——Workshop 的每个组件都直接绑定 Ontology 对象，数据、权限、Action 天然贯通，不需要"连接器"或"数据源配置"。
- Workshop 能构建运营仪表盘、审批流程、控制面板、数据录入表单等企业应用，且所有操作自动走 Action 审计链路，天然满足合规要求。
- 这种 Ontology 驱动的低代码模式正在成为行业趋势，Coomia DIP 等开源平台也在以更开放的方式实现类似能力。
#引言：企业应用开发的困境
每个大型组织都有这个痛点：业务部门有大量的定制化应用需求，但 IT 部门的开发排期永远排不过来。
Code
业务部门的需求清单：
├── 供应商绩效看板（优先级：高） → IT 排期：Q3
├── 库存预警控制台（优先级：高） → IT 排期：Q4
├── 审批流程跟踪界面（优先级：中） → IT 排期：明年 Q1
├── 客户投诉处理系统（优先级：中） → IT 排期：明年 Q2
├── 设备维护工单系统（优先级：低） → IT 排期：排不上
└── ...还有 47 个需求 → IT：人手不够
低代码平台的出现就是为了解决这个问题——让业务用户自己构建应用。但传统的低代码平台有一个根本性问题：
Code
传统低代码的架构：
┌──────────────┐
│ 低代码 IDE │
│ （拖拽组件） │
└──────┬───────┘
│ 需要配置
▼
┌──────────────┐ ┌──────────────┐
│ 数据源连接器 │────→│ 数据库/API │
│ （手动配置） │ │ （各种系统） │
└──────────────┘ └──────────────┘
│ 需要配置
▼
┌──────────────┐
│ 权限系统 │
│ （又一套配置） │
└──────────────┘
│ 需要集成
▼
┌──────────────┐
│ 工作流引擎 │
│ （再配一套） │
└──────────────┘
每一层都需要单独配置和集成。结果是"低代码"变成了"低了一半的代码"——还是需要大量的配置工作。
Palantir Workshop 的革命性在于：所有这些层都被 Ontology 统一了。
#一、Workshop 能构建什么？
#1.1 运营仪表盘
实时展示业务关键指标，支持钻取和 Action 触发：
Code
┌──────────────────────────────────────────────────────────┐
│ 供应链运营中心 [全屏] [分享] │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 在途订单 │ │ 库存预警 │ │ 交付准时率│ │ 供应商风险│ │
│ │ 1,247 │ │ 23 !! │ │ 94.2% │ │ 3 !! │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────────┐ │
│ │ 各区域订单分布 │ │ 本月 vs 上月趋势 │ │
│ │ │ │ │ │
│ │ ## 华东 420 │ │ --- 本月 │ │
│ │ ## 华南 310 │ │ ... 上月 │ │
│ │ # 华北 267 │ │ /--\ /-- │ │
│ │ # 西南 250 │ │ / \--/ │ │
│ │ │ │ / │ │
│ └─────────────────────┘ └─────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 需要关注的订单 [批量处理] │ │
│ │ ┌────┬──────────┬────────┬──────┬──────────────┐ │ │
│ │ │ [] │ 订单号 │ 供应商 │ 状态 │ 操作 │ │ │
│ │ ├────┼──────────┼────────┼──────┼──────────────┤ │ │
│ │ │ [] │ PO-12847 │ 华为 │ 延迟 │ [催单][换供] │ │ │
│ │ │ [] │ PO-12851 │ 中兴 │ 预警 │ [催单] │ │ │
│ │ │ [] │ PO-12853 │ 比亚迪 │ 延迟 │ [催单][换供] │ │ │
│ │ └────┴──────────┴────────┴──────┴──────────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
#1.2 审批工作流
可视化展示审批状态，一键审批/拒绝：
Code
┌──────────────────────────────────────────────────────┐
│ 采购审批工作台 │
├──────────────────────────────────────────────────────┤
│ │
│ 待我审批 (7) │ 我发起的 (12) │ 已完成 (156) │
│ ═══════════ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ PR-2024-0847: 采购 CNC 刀具 │ │
│ │ │ │
│ │ 申请人： 张三 （生产部） 金额： ¥ 128,000 │ │
│ │ 日期： 2024-01-15 供应商： 山高刀具 │ │
│ │ │ │
│ │ 审批链： │ │
│ │ 张三（申请） --> 李四（组长） --> [你]（部长） --> 王五 │ │
│ │ Done Done Pending │ │
│ │ │ │
│ │ 关联对象： │ │
│ │ * 供应商： 山高刀具 （风险评分： 低） │ │
│ │ * 历史采购： 过去 12 个月 32 次， 总额 ¥2.1M │ │
│ │ * 当前库存： CNC 刀具剩余 15 把 （预计用完： 3 天） │ │
│ │ │ │
│ │ [批准] [拒绝] [退回修改] [评论] │ │
│ └────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
#1.3 数据录入表单
结构化数据录入，自动校验和关联：
Code
┌──────────────────────────────────────────────────────┐
│ 新建质量检验记录 │
├──────────────────────────────────────────────────────┤
│ │
│ 产品批次号： [BT-2024-01-0847 ] <- 自动关联产品 │
│ 产品名称： CNC 精密轴承 （自动填充） │
│ 产品线： A 线 （自动填充） │
│ │
│ 检验类型： o 首检 * 过程检 o 终检 │
│ 检验数量： [100] 件 │
│ 不良数量： [3 ] 件 │
│ 不良率： 3.0% <- 自动计算 │
│ │
│ 不良类型 （多选）: │
│ [x] 尺寸超差 [ ] 表面缺陷 [x] 材料异常 [ ] 其他 │
│ │
│ 关联设备： [CNC-007 v] <- 从 Ontology 选择 │
│ 操作员： [王师傅 v] <- 从 Ontology 选择 │
│ │
│ 附件： [+ 上传照片/报告] │
│ 备注： [ ] │
│ │
│ !! 不良率超过 2%，将自动创建质量调查工单 │
│ │
│ [保存草稿] [提交] [取消] │
└──────────────────────────────────────────────────────┘
#1.4 控制面板
设备监控和远程操作：
Code
┌──────────────────────────────────────────────────────┐
│ 车间设备控制中心 │
├──────────────────────────────────────────────────────┤
│ │
│ CNC-007 状态面板 │
│ ┌─────────────────────────────────────────────┐ │
│ │ 状态： [OK] 运行中 运行时间： 127h 23m │ │
│ │ 主轴转速： 3,200 rpm 进给速率： 120 mm/min │ │
│ │ 刀具磨损： 73% !! 冷却液温度： 42 C │ │
│ │ │ │
│ │ 振动趋势 (24h): │ │
│ │ ------/\-----/\/\----------- │ │
│ │ ^ 异常振动 │ │
│ │ │ │
│ │ [暂停运行] [调整参数] [维护申请] [查看历史] │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ 所有设备概览： │
│ CNC-001 OK CNC-002 OK CNC-003 !! CNC-004 OK │
│ CNC-005 OK CNC-006 OK CNC-007 !! CNC-008 XX │
│ CNC-009 OK CNC-010 OK CNC-011 OK CNC-012 OK │
└──────────────────────────────────────────────────────┘
#二、Workshop 的核心机制：组件与 Ontology 绑定
#2.1 组件绑定模型
Workshop 的每个组件都通过 Ontology 绑定来获取数据和触发操作：
Code
┌──────────────────────────────────────────────────┐
│ Workshop 组件绑定模型 │
│ │
│ ┌─────────────┐ │
│ │ Widget │ │
│ │ （表格/图表/ │ │
│ │ 表单/按钮） │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ 绑定配置 │ │
│ └────┬────┘ │
│ │ │
│ ┌────┼──────────┬──────────────┐ │
│ ▼ ▼ ▼ ▼ │
│ ┌────┐ ┌────────┐ ┌───────────┐ ┌────────────┐ │
│ │数据│ │过滤条件 │ │排序规则 │ │Action 绑定 │ │
│ │源 │ │ │ │ │ │ │ │
│ │ │ │Object │ │property │ │ActionType │ │
│ │Obj │ │Set的 │ │+ 方向 │ │+ 参数映射 │ │
│ │Type│ │Filter │ │ │ │ │ │
│ └────┘ └────────┘ └───────────┘ └────────────┘ │
│ │ │ │
│ │ Ontology Layer │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ Object Type + Properties + LinkTypes │ │
│ │ + ActionTypes + Permissions │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
#2.2 实际绑定示例
JSON
{
"widget": "DataTable",
"binding": {
"objectType": "PurchaseOrder",
"objectSet": {
"filter": {
"and": [
{ "property": "status", "eq": "DELAYED" },
{ "property": "amount", "gte": 100000 }
]
},
"orderBy": [
{ "property": "dueDate", "direction": "ASC" }
],
"limit": 50
},
"columns": [
{ "property": "orderId", "label": "订单号" },
{ "property": "supplierName", "label": "供应商", "link": "Supplier" },
{ "property": "amount", "label": "金额", "format": "currency" },
{ "property": "dueDate", "label": "交期", "format": "date" },
{ "property": "daysOverdue", "label": "超期天数", "derived": true }
],
"rowActions": [
{
"actionType": "RushOrder",
"label": "催单",
"icon": "bolt",
"parameterMapping": {
"orderId": "$row.orderId",
"priority": "HIGH"
}
},
{
"actionType": "ChangeSupplier",
"label": "更换供应商",
"icon": "swap",
"parameterMapping": {
"orderId": "$row.orderId",
"currentSupplierId": "$row.supplierId"
}
}
]
}
}
#2.3 为什么 Ontology 绑定优于数据源绑定
Code
传统低代码（数据源绑定）：
组件 → 连接器 → API/DB → 拿到原始数据 → 自己处理权限 → 自己处理关联
Workshop（Ontology 绑定）：
组件 → Ontology → 自动带权限 → 自动带关联 → 自动带 Action → 完事
具体差异：
| 维度 | 数据源绑定 | Ontology 绑定 |
|---|---|---|
| 获取数据 | 配置 API/SQL 查询 | 选择 ObjectType |
| 权限控制 | 手动实现行级/列级过滤 | Ontology 自动过滤 |
| 关联导航 | 手动写 JOIN/子查询 | 沿 LinkType 自动导航 |
| 触发操作 | 手动调 API | 选择 ActionType |
| Schema 变更 | 组件可能崩溃 | Ontology 层吸收变化 |
| 审计追踪 | 手动记录 | Action 自动审计 |
#三、Workshop vs 传统低代码平台
#3.1 核心对比
| 对比维度 | Palantir Workshop | OutSystems | Mendix | PowerApps |
|---|---|---|---|---|
| 数据模型 | Ontology 对象 | 实体模型 | 域模型 | Dataverse/连接器 |
| 数据来源 | Ontology 统一入口 | 多连接器 | 多连接器 | 多连接器 |
| 权限模型 | Ontology 继承 | 自建 | 自建 | Azure AD |
| 操作触发 | Action （含审计） | Logic 流 | Microflow | Power Automate |
| 适用场景 | 数据密集型操作应用 | 全栈应用 | 全栈应用 | 轻量级应用 |
| 离线支持 | 有限 | 完整 | 完整 | 有限 |
| 移动端 | 响应式 | 原生 App | 原生 App | 原生 App |
| 自定义代码 | TypeScript 扩展 | C#/.NET | Java | Power Fx |
| 部署方式 | SaaS / 私有化 | SaaS / 私有化 | SaaS / 私有化 | SaaS |
| 价格 | 企业定制 | $$$$ | $$$ | $ |
#3.2 根本性差异：Ontology-Backed 低代码
传统低代码平台本质上是应用开发框架的简化版——简化了 UI 构建和 API 调用，但数据模型、权限、工作流仍然需要在低代码平台内部重新定义。
Workshop 的本质不同在于：它不是一个独立的应用平台，而是Ontology 的表现层。
Code
传统低代码：
┌─────────────┐
│ 低代码平台 │ <- 一切在这里面定义
│ ┌─────────┐ │
│ │ UI │ │
│ │ 数据模型 │ │ <- 重复定义（和源系统不同步）
│ │ 权限 │ │ <- 重复定义（和企业 IAM 不同步）
│ │ 工作流 │ │ <- 重复定义（和业务流程不同步）
│ └─────────┘ │
└─────────────┘
Workshop：
┌─────────────┐
│ Workshop │ <- 只负责 UI 和交互
│ ┌─────────┐ │
│ │ UI 组件 │──┼──→ Ontology（数据 + 权限 + Action）
│ └─────────┘ │ ^ 唯一数据源（Single Source of Truth）
└─────────────┘
这意味着：
- 在 Workshop 中创建的任何应用，数据自动与其他所有工具（Contour、Pipeline、API）保持一致
- 权限改变在 Ontology 层生效，所有 Workshop 应用自动生效
- 新增 Action 在 Ontology 层定义，所有 Workshop 应用自动可用
然而，Workshop 作为 Palantir 封闭生态的一部分，其高昂的许可费用和平台锁定效应让许多企业望而却步。Coomia DIP 基于相同的 Ontology 驱动理念，提供了开源替代方案，让企业以更低的成本获得同等的低代码应用构建能力。
#四、Workshop 应用的真实案例
#4.1 案例：供应链控制中心
一个中型制造企业用 Workshop 构建了完整的供应链控制中心，替代了原来 3 个独立系统：
之前：
Code
供应商管理 → SAP 模块（操作复杂，非供应链人员不会用）
库存监控 → Excel + 人工巡检（延迟大，经常遗漏）
物流跟踪 → 第三方系统（数据不互通）
之后（Workshop 应用）：
Code
一个统一界面：
├── Tab 1: 供应商绩效看板
│ └── 从 Ontology 读取 Supplier 对象 + 关联的 PurchaseOrder
├── Tab 2: 库存预警
│ └── 从 Ontology 读取 Inventory 对象，自动计算预警阈值
├── Tab 3: 物流跟踪
│ └── 从 Ontology 读取 Shipment 对象 + 实时位置
└── Tab 4: 操作中心
└── Action: 催单、调拨、换供应商、紧急采购
构建时间：2 周（1 名业务分析师 + 1 名 IT 支持），替代了原来预估需要 6 个月开发的项目。
#4.2 案例：合规审批平台
一家金融机构用 Workshop 构建了交易合规审批平台：
Code
交易提交
│
▼
Workshop 审批界面
├── 自动展示：交易详情、客户画像、历史交易模式
├── 自动标注：风险等级（来自 Reasoning Engine）
├── 自动关联：相关的合规规则和监管要求
├── Action 选项：
│ ├── 批准（自动记录审批人、时间、理由）
│ ├── 拒绝（必须填写拒绝原因）
│ ├── 上报（自动转给上级）
│ └── 请求补充材料
└── 审计追踪：每一步操作自动记录，不可篡改
#五、从 Workshop 看企业应用的未来
#5.1 传统开发 vs 低代码 vs Ontology 低代码
Code
应用复杂度
^
│ ┌───────────────────────────────┐
│ │ │
高 │ │ 传统开发 │ <- 什么都能做，但贵且慢
│ │ (React + Spring Boot) │
│ │ │
│ └───────────────────────────────┘
│ ┌───────────────────────────────┐
│ │ │
中 │ │ Ontology 低代码 │ <- Workshop 的甜蜜区
│ │ (Workshop) │ 数据密集型操作应用
│ │ │
│ └───────────────────────────────┘
│ ┌───────────────────────────────┐
│ │ │
低 │ │ 传统低代码 │ <- 简单表单/流程
│ │ (PowerApps, 宜搭） │
│ │ │
│ └───────────────────────────────┘
└──────────────────────────────────→ 构建速度
#5.2 Workshop 的局限性
Workshop 不是万能的。它不适合：
- 消费者面向的应用：Workshop 是为内部运营人员设计的，不适合面向最终消费者的 App
- 高度定制化 UI：Workshop 的 UI 组件库虽然丰富但有边界，极度定制化的界面仍需传统开发
- 离线优先场景：Workshop 依赖实时的 Ontology 连接，完全离线的场景不适用
- 非数据密集型应用：如果应用主要是流程而非数据操作，传统低代码可能更合适
对于希望获得 Ontology 驱动低代码能力但又不想被单一供应商锁定的企业，Coomia DIP 提供了基于开放标准的替代路径——支持私有化部署，且与企业现有技术栈无缝集成。
#六、最佳实践
#6.1 仪表盘设计原则
- 5 秒原则：打开仪表盘 5 秒内能看到最关键的信息
- 三层结构：概览层（指标卡）-> 分析层（图表）-> 操作层（数据表 + Action）
- Action 可达：任何需要操作的地方都要有 Action 按钮，不让用户"看得到但做不了"
- 移动友好：关键操作要在移动端也能完成
#6.2 常见误区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 一个仪表盘放太多信息 | 信息过载，没人看 | 按角色拆分仪表盘 |
| 只有图表没有 Action | 看完不知道做什么 | 每个发现配一个 Action |
| 权限配置不当 | 数据泄露或操作越权 | 使用 Ontology 权限继承 |
| 没有全局过滤器 | 用户无法聚焦 | 提供时间/区域/状态过滤 |
#Key Takeaways
- Workshop 与传统低代码的本质区别是 Ontology 绑定——组件不是绑定数据源，而是绑定业务对象。这使得数据、权限、Action 天然贯通，消除了传统低代码中大量的"胶水配置"工作。
- Workshop 的核心价值在于"从看到做"的闭环——它不只是可视化工具，而是操作平台。每个图表、每个表格都可以直接触发业务操作，这才是企业应用真正需要的。
- Ontology 驱动的低代码是行业趋势——无论是 Palantir Workshop 还是 Coomia DIP 的仪表盘构建器，核心理念都是让业务对象成为应用开发的基石，而非原始数据表。
#想要 Palantir 级别的能力？试试 Coomia DIP
Palantir 的技术理念令人赞叹，但其高昂的价格和封闭的生态让大多数企业望而却步。Coomia DIP 基于相同的 Ontology 驱动理念，提供开源、透明、可私有化部署的数据智能平台。
- AI 管线构建器：用自然语言描述，自动生成生产级数据管线
- 业务本体：像 Palantir 一样建模你的业务世界，但完全开放
- 决策智能：内置规则引擎和假设分析，数据驱动每一个决策
- 开放架构：基于 Flink、Doris、Kafka 等开源技术栈，零锁定
相关文章
Palantir开源Ontology
为什么我们要做开源版 Palantir？Coomia DIP 的愿景与路线图
Palantir 无法服务全球 70% 的企业市场，Coomia DIP 用开源方式让 Ontology 驱动的智能决策能力成为每个企业都能使用的基础设施。
Coomia 团队2025年6月6日25min
阅读全文PalantirOSDKOntology
Palantir OSDK 深度解析：Ontology-first 开发范式如何重塑企业软件
深入解析 Palantir OSDK 的设计哲学与核心能力，对比传统 ORM 和 REST API，探索 Ontology-first 开发范式的变革意义。
Coomia 团队2025年6月1日22min
阅读全文Palantir股价分析数据平台
Palantir 股价从 $6 到 $80：资本市场读懂了什么？
深度分析 Palantir 股价从 IPO 低谷到历史新高的完整旅程，解读 AIP 催化剂、Rule of 40 突破以及 Ontology 驱动平台的估值逻辑。
Coomia 团队2025年5月26日21min
阅读全文