详解Palantir AIP的三个Flow：Dataflow、AI flow、Workflow

推荐语

探索Palantir AIP如何通过Dataflow、AI flow和Workflow三大核心模块，实现企业级AI应用的完美落地。

核心内容：
1. Dataflow：从多源异构数据到语义化本体的高效转换
2. AIflow：将大模型能力嵌入业务流程的逻辑编排
3. Workflow：构建人机协同的决策交互界面与业务流

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

几年前猛的研究过一阵子Data、AI和应用的关系，试图探索出AI落地企业应用的一条路径或产品设计范式，并最终将体会总结成了三个Flow：Dataflow、AI flow、Workflow。当时还高兴了好一阵子，如获至宝，以为独创了一个什么新鲜玩意，各种画PPT。

如今在研发Palantir竞品过程中，对照AIP再反思这三个Flow，发现AIP才是真正完美将这三个Flow落实到了产品，每个Flow都有对应的模块和功能，而且都是核心一级模块，有形、有神、形神兼备。

整个Palantir AIP产品就是围绕这三个Flow来架构和设计的。

Palantir AIP = Dataflow  x  AI flow  x  Workflow

总结成一张图如下：

三个Flow绕着业务数字孪生沙盘Ontology转。

Dataflow对应的是Palantir的Pipeline Builder一级大模块。

AIflow对应的是Palantir的AIP Logic一级大模块。

Worflow对应的是Palantir的Workshop/workflow一级大模块。

Dataflow负责把散落的数据打通，经过变换，映射，灌到本体中去。

AIflow负责把AI大模型嵌入到整个业务流程、业务逻辑的编排中去，以逻辑函数的形态，基于本体这个上下文，实现大模型落地企业应用。

Worflow从应用的层面，支撑workshop的整体编排，打造Human+AI的决策交互界面。如果把应用比作一枚硬币，workflow和workshop就是这枚硬币的两面，workshop是正面，编排人机交互的所有UI和元素；workflow是背面，勾勒了dataset、ontology、transformer、variable、function、application等是如何串联成一条线的。

我们详细分析一下。

一、Dataflow的目标：从杂乱数据到语义化本体

Palantir传统优势在于 Foundry / Gotham 上的数据集成和本体建模。到了 AIP 时代，Dataflow 的核心仍然是

• 汇聚复杂、动态、海量、多模态数据：ERP、MES、CRM、PLM、IoT、日志、文档、邮件……

• 统一建模：在本体（Ontology）中变成“实体 + 关系 + 属性 + 时序/向量/地理/文档”等。

  
  

最终形成可被 AI 和应用直接消费的语义层。

所以，Dataflow = 把底层数据工程和本体工程流水化、可视化、可复用。

AIP在Dataflow的关键产品组件包括

• Pipeline Builder / Code Workbook：ETL + Transform。一个是可视化的，一个编码级别的。

• Ontology（本体）：实体类型、属性、关系设计及

• 对象探索 / 报表 / 图分析组件：数据验证与可视化。

在 AIP 的实际使用中，Dataflow就是一个可视化的数据加工产线，主要使用Pipeline builder进行编排

（1）数据接入

通过各种连接器接入千奇百怪的数据源，包含连接数据库、数据湖、文件存储、API等。做基础 Schema 映射、字段类型转换。

（2）数据编排

Pipeline builder提供了很多种算子进行数据变换。去重、填补缺失值、数据标准化（如统一币种、单位）。业务规则校验（如负库存、异常温度）等等，上百种，也包含LLM等AI算子。

（3）特征与属性构造

计算派生字段（如滚动 30 天平均库存、设备过去 1 个月最高温度）。聚合、窗口函数、时序指标。都有对应的算子来完成。

（4）本体写入

把数据写入具体本体对象，如：Machine、Material、Order、Customer、Transaction……建立关系边：供应链上下游、设备与工单、客户与订单等。

（5）向量 / 地理 / 文档等高级数据类型构建

向量：对文本、图像、结构化记录做 embedding。

地理：GeoPoint / Geometry 等。

文档：PDF、合同、报告，建立索引与元数据。

Dataflow 结束时，企业就获得了一套结构化的“真实业务的数字孪生”，可以被后续 AIflow 与 Workflow 直接消费。当 Dataflow 构建完成后，一切AI 分析/决策都不再直接面对数据库表，而是面对语义更加清晰的本体世界。这一点十分重要。

二、AIflow：让 AI 变成可编排、可监管的决策引擎

根本就不是一个聊天机器人那么Low的事情。

AIflow 的目标是从一个大模型到一个可控的智能AI Logic流水线。有了 Dataflow 之后，企业进入下一个问题：

我如何在这些数据之上，用 LLM 和其它模型做判断和生成方案？而且是可控的、可审计的，而不是一个黑箱对话？

AIflow把使用AI拆成一系列可视化 Block / Node，主要是使用AIP Logic的系列逻辑块来实现的。

• 检索（Semantic Search / RAG）：用向量 + 结构化过滤从本体中找相关对象。

• 推理（Use LLM / Use Model）：把上下文、数据和 Prompt 喂给 LLM / 传统模型。

• 工具调用（Tools / Functions / ObjectQuery）：在 AI 推理中调用算子、API、函数。

• 评分与对齐：对输出进行规则 / 模型校验与过滤。

  
  

一个典型的 AIflow 会包含以下几类逻辑块，这也是AIP Logic的逻辑块类型，一共是七大类

（1）输入逻辑块（Input）

来自 Workflow 的用户输入，例如 query、目标 KPI、设备 ID；来自系统上下文，例如当前用户角色、组织、权限。

（2）语义搜索逻辑块（Semantic Search / Rerank）

对于文本或半结构化需求，把 query embed 后在向量空间检索；支持结构化条件过滤（如只检索某组织、某时间窗口内的数据）；可叠加 rerank 模型，以提高召回质量。

（3）数据转换逻辑块（Transform / Enrich）

对检索结果做二次加工，例如：按时间排序、聚合；只保留关键字段；补充额外维度（如供应商评级、风险分）。

（4）LLM 调用逻辑块（Use LLM / Use Model）

设定 Task Prompt、System Prompt；引用多个对象的多个字段作为上下文（例如：多个物料、多个供应商的属性）；指定输出结构（JSON Schema），方便后续机器处理。

（5）评估与安全逻辑块（Guardrails / Validators）

对 LLM 输出做规则校验（字段是否完整、数值是否在合理范围）；触发“拒绝回答 / 要求澄清 / 请求人工复核”等分支。

（6）输出逻辑块（Output）

把 AIflow 的产出封装成结构化结果，返回给 Workflow 使用；可包含：文本说明（给人读）；结构化决策建议（给系统执行）；不同方案的对比列表（供审批人选择）。

（7）其他逻辑块

包括定义变量块等。

在这个 AIflow 中，LLM 不是一个瞎聊的机器人，而是一个在严格数据和规则约束（基于本体作为context来约束LLM的）下，利用自然语言推理和组合能力，为用户生成结构化决策方案的智能算子逻辑单元。

三、Workflow：让决策在一线用户界面中跑起来

Workflow 的目标是从AI 能力到业务操作。Dataflow + AIflow 搞定了数据和智能，但如果没有 Workflow，一线调度员、采购员、业务人员无法方便地使用这些能力；决策依然停留在分析报告层面，落不到操作动作。

Workflow 做的事情，就是把 AIflow 打包成一个可视化的业务流程，挂在应用界面上，让业务用户像操作普通系统一样调用 AI。这个是通过workshop来实现的。

在 Palantir 的产品体系里，具体对应到AIP 的 Action Flow / Workshop Application Builder / Scenario App 等；可以配置页面组件（表格、图表、地图、表单等很多组件）、用户交互（按钮、下拉框、输入框、审批流）、触发逻辑（当点击按钮 → 调用哪个 AIflow / Dataflow → 决策结果如何更新本体）。

一个典型的 Workflow 包含：

（1）触发入口（Trigger）

用户点击按钮：例如“生成缺料调整建议”“生成投资备忘录初稿”；系统自动触发：例如每天晚上批量跑一次“风险扫描”。

（2）参数收集（Form / Context）

从用户界面中收集必要参数，如时间窗口、业务单号、目标 KPI；结合用户身份、权限形成完整上下文（如管哪个工厂、哪个业务线）。

（3）调用 Dataflow / AIflow / 其它服务

Workflow 在后台调度一个或多个 Flow；先跑一个 Dataflow 更新最新指标；再调用一个 AIflow 生成方案；有时候还会调用外部 API（如报价系统、合同系统）。

（4）结果展示（UI Components）

把 AIflow 的输出映射到前端组件：表格展示物料清单与建议；图表展示风险随时间变化；地图展示受影响工厂 / 客户；说明文本（LLM 生成的自然语言解释）。

（5）人机协同与审批（Human-in-the-loop）

用户可以逐条接受 / 拒绝 / 修改建议；对于高敏感动作（停线、改配方、调价），必须走审批流程；每一次人工选择都会被记录，反过来可用作训练 / 评估数据。

（6）落地执行（Action / Write-back）

Workflow 的最终节点往往是更新本体中的状态（如订单状态、风险标记）；推送任务到其他系统（如 ERP、MES、CRM）；触发消息通知（邮件、IM、任务系统）。

通过Workflow 把 AI 能力嵌进了真实的业务操作闭环。

四、三个 Flow协同实现数据 → 智能 → 决策闭环

我们可以用一个公式来概括 Palantir AIP 的架构：

AIP = Dataflow × AI flow × Workflow

三者并不是平行的模块，而是层层相依：

（1）没有 Dataflow，AI flow 只是空谈

没有高质量、语义化的数据，LLM 就只能泛泛而谈；检索不到准确的上下文，就无法做严肃业务决策。

（2）没有 AIflow，Dataflow 很难释放潜力

单纯的数据汇总和可视化，难以应对复杂不确定场景；AIflow 把数据转化为可选的决策方案，极大提升数据价值。

（3）没有 Workflow，再好的 AIflow 也落不到地

一线用户不可能每天在 Notebook 里调模型；必须以应用和流程的形式呈现，才能产生真正的业务影响；Workflow 也是人机协同、合规审计的重要容器。

从实施路径上看，一个AIP 项目可以按以下顺序演进：

• 先建 Dataflow：把关键场景的数据跑通、建好本体；

• 再搭 AIflow：围绕1到2个具体 use case，设计 AI 决策流水线；

• 最后做 Workflow：做一两个精致的业务应用，把 AI 变成按钮、面板和审批流。

五、掌握三个 Flow，就是掌握了AIP 的全栈心法

从工程视角看

Dataflow：是数据工程 + 本体工程；

AIflow：是模型工程 + 领域工程 + RAG/ORG + 安全治理；

Workflow：是应用工程 + 业务流程再造 + 人机协同设计。

从业务视角看

Dataflow回答：“我到底有什么数据？能不能变成业务看得懂的世界模型？”

AIflow回答：“在这些数据之上，我能用 AI 做哪些判断和方案生成？”

Workflow回答：“一线业务如何使用这些能力，让决策闭环跑起来？”

在设计一个 AIP use case 时，可以用这三个问题审视方案：

（1）Dataflow 够不够？

 有没有把关键实体、关系、指标建进本体？数据质量和新鲜度是否支撑 AI 决策？

（2）AIflow 清不清？

业务问题拆成了哪些步骤？什么时候检索？什么时候调用 LLM？什么时候用规则 / 传统模型？输出是否结构化、可评估、可审计？

（3）Workflow 顺不顺？

一线用户的操作路径是不是简单自然？哪些环节必须人拍板？结果如何写回系统，形成长期积累与优化？

真正掌握了这三条 Flow，就不是在配置一个聊天机器人，而是在设计一条条端到端的智能业务生产线，这也是 Palantir AIP 与传统企业信息化系统、单一LLM 工具的本质区别所在。