Palantir 的两条产品线：Gotham（国防）与 Foundry（企业）
大多数科技公司只有一条产品线。Google 的核心是搜索，Salesforce 的核心是 CRM，Snowflake 的核心是云数据仓库。
Palantir 的两条产品线：Gotham（国防）与 Foundry（企业）
“系列：S1 Palantir 解密 · 第 2 篇 | 难度：入门 | 阅读时间：15 分钟
#TL;DR
- Gotham 是 Palantir 的"长子"，为情报分析和军事行动而生，核心能力是多源情报融合、实体关联分析和协作调查。
- Foundry 是 Palantir 的"增长引擎"，将 Gotham 验证过的方法论移植到企业场景，核心是 Ontology + Pipeline + Actions 的完整闭环。
- 两者共享同一个灵魂——Ontology，但面向完全不同的用户群体，这种"军转民"的路径是 Palantir 独特竞争力的来源。
#引言：一棵树的两根主干
大多数科技公司只有一条产品线。Google 的核心是搜索，Salesforce 的核心是 CRM，Snowflake 的核心是云数据仓库。
Palantir 不一样。它有两条完全独立又深度共享的产品线：
- Gotham：服务情报机构和军方，2004 年诞生
- Foundry：服务商业企业，2016 年推出
这不是简单的"政府版"和"企业版"的关系。它们面对不同的用户、解决不同的问题、提供不同的交互体验，但在最核心的技术层——Ontology 和数据整合——它们共享同一套引擎。
理解这两条产品线，是理解 Palantir 商业逻辑的关键。
#一、Gotham：为战争迷雾而生
#1.1 背景：情报分析的困境
2001 年 9 月 11 日之后，美国情报界做了一次深刻的反思。911 委员会报告的核心结论是：
“"这不是情报不足的问题，而是情报整合不力的问题。"
各个情报机构——CIA（中央情报局）、NSA（国家安全局）、FBI（联邦调查局）、DIA（国防情报局）——各自拥有大量相关情报，但它们：
- 存储在不同的系统中
- 使用不同的数据格式
- 受制于不同的访问权限
- 缺乏跨机构的关联分析能力
一个 CIA 分析师知道某个嫌疑人的资金流向，一个 NSA 分析师截获了同一个人的通话记录，一个 FBI 探员调查过此人的签证申请——但这三条线索从未交汇。
Palantir Gotham 就是为了解决这个"连点成线"的问题而诞生的。
#1.2 Gotham 的核心能力
┌──────────────────────────────────────────────────────────────┐
│ Gotham 能力架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │协作调查 │ │地理时空 │ │模式发现 │ │行动规划 │ │
│ │平台 │ │分析 │ │与预测 │ │与执行 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ ┌────┴────────────┴────────────┴────────────┴────┐ │
│ │ 知识图谱 / Ontology │ │
│ │ 人物 ← 通话 → 地点 ← 资金 → 组织 │ │
│ └────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────────┴─────────────────────────────┐ │
│ │ 多源数据融合引擎 │ │
│ │ SIGINT + HUMINT + OSINT + FININT + GEOINT │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
能力一：多源数据融合
Gotham 的第一个核心能力是将来自完全不同来源的数据融合到一个统一的视图中：
| 数据类型 | 来源 | 示例 |
|---|---|---|
| SIGINT（信号情报） | 通信截获 | 电话记录、邮件元数据、卫星通信 |
| HUMINT（人力情报） | 线人报告 | 情报员提交的报告和笔记 |
| OSINT（开源情报） | 公开信息 | 新闻、社交媒体、公开记录 |
| FININT（金融情报） | 银行系统 | 汇款记录、账户关联、可疑交易 |
| GEOINT（地理空间情报） | 卫星/GPS | 地理位置、移动轨迹、设施图像 |
| MASINT（测量情报） | 传感器 | 化学/核探测、声波分析 |
这些数据格式完全不同——有的是结构化表格，有的是非结构化文本，有的是地理坐标，有的是图像。Gotham 的融合引擎将它们统一映射为 Ontology 中的实体和关系。
能力二：实体解析与关联分析
当数据融合后，下一步是识别"同一个人/同一个组织/同一个事件"——这就是实体解析（Entity Resolution）。
CIA 数据库："Abu Ahmed al-Kuwaiti"，电话号码 +92-XXX-XXXX
NSA 截获："Ahmed from Kuwait"，同一号码出现在通话记录中
FBI 记录："Ahmed Khan"，签证申请中填写了关联地址
Gotham 实体解析：
→ 高置信度匹配：三条记录指向同一个人
→ 自动关联：此人与 5 个已知嫌疑人有通话关系
→ 地理关联：此人的活动区域与 3 个已知安全屋重叠
这种跨系统、跨格式的实体识别和关联分析，是 Gotham 最核心的能力。
能力三：知识图谱与模式发现
Gotham 将所有实体和关系构建成一个巨大的知识图谱，分析师可以在上面进行模式发现：
- 网络分析：某个人的 2 度关系网络中，有多少已知嫌疑人？
- 时间序列分析：某个地点的通信活动在过去 30 天是否异常增加？
- 资金流向分析：某笔资金经过多少次中转到达了最终目的地？
- Pattern of Life（生活模式分析）：某个人的日常行为模式是否突然改变？
典型分析场景：
分析师发现：
嫌疑人 A 每周四下午给 B 打电话
B 每次通话后 2 小时内向海外账户 C 转账
账户 C 的资金在 48 小时内被提取
提取地点在已知训练营 50 公里范围内
→ Gotham 自动标记此模式为"高风险资金链路"
→ 推送给分析师审核
→ 分析师确认后，标记为"活跃情报线索"
能力四：协作调查平台
Gotham 不只是一个分析工具，它是一个多人协作调查平台：
- 共享工作空间：多个分析师同时调查同一案件，看到彼此的标注和发现
- 权限隔离：不同密级的分析师看到不同层级的数据（这是 Palantir 权限模型的起源）
- 版本控制：调查过程中的每一步都被记录，可以回溯
- 知识沉淀：一个分析师的发现自动成为其他分析师的输入
能力五：行动支持
Gotham 的最终目标不是"分析"，而是"行动"：
- 生成行动建议
- 支持指挥官的决策
- 追踪行动执行状态
- 评估行动效果
分析 → 发现嫌疑目标 → 生成行动建议 → 指挥官批准 → 执行 → 效果评估
↑
Gotham 覆盖全链路
#1.3 Gotham 的知名案例
案例一：追踪 IED 网络（伊拉克/阿富汗）
在伊拉克和阿富汗战场，路边炸弹（IED）是联军最大的威胁。制造 IED 需要：
- 炸药来源（供应链）
- 制造者（人员网络）
- 安放者（执行网络）
- 资金支持（金融网络）
Gotham 将这四条线索融合在一起，帮助军方识别出完整的 IED 网络，而不是只抓到"安放炸弹的人"。
案例二：反恐情报融合
据公开报道，Gotham 在 2011 年追踪本·拉登藏身地点的情报分析中发挥了作用（Palantir 对此不置可否）。核心方法论就是前面提到的：多源情报融合 + 实体解析 + Pattern of Life 分析。
案例三：乌克兰战场数据整合（2022-至今）
2022 年俄乌冲突爆发后，Palantir 向乌克兰提供了 Gotham 系统，帮助乌军：
- 整合战场传感器数据、无人机影像、通信情报
- 构建战场态势感知图
- 优化弹药和物资调配
这是 Gotham 首次在公开冲突中被大规模报道。
#二、Foundry：把军事级能力带给企业
#2.1 从军事到商业的认知迁移
2013 年前后，Palantir 做了一个关键的战略判断：
“情报分析的本质问题——多源数据整合、语义统一、关联分析、决策支持——在商业世界同样存在。
区别只是：
| 维度 | 军事/情报 | 商业企业 |
|---|---|---|
| 数据来源 | SIGINT、HUMINT、OSINT | ERP、CRM、IoT、日志 |
| "敌人" | 恐怖分子、敌对势力 | 市场变化、供应链中断、欺诈行为 |
| "行动" | 军事打击、抓捕 | 调整排产、冻结账户、采购替代 |
| 权限要求 | 军事密级 | 企业数据合规 |
| 决策速度要求 | 分钟级 | 小时到天级 |
本质问题完全相同：数据散、理解难、决策慢、行动断。
2016 年，Palantir 正式推出 Foundry。
#2.2 Foundry 的核心架构
如果说 Gotham 是一把"手术刀"（精准但需要专业技能），Foundry 就是一个"手术平台"（标准化、可扩展、人人可用）。
┌──────────────────────────────────────────────────────────────┐
│ Foundry 能力架构 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Workshop │ │ Contour │ │ AIP │ │
│ │ 低代码应用 │ │ 交互式分析 │ │ AI 平台 │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ ┌─────┴──────────────┴──────────────┴──────┐ │
│ │ Actions + Rules + Functions │ │
│ │ 业务操作 + 自动化规则 + 自定义函数 │ │
│ └─────────────────┬────────────────────────┘ │
│ │ │
│ ┌─────────────────┴────────────────────────┐ │
│ │ Ontology │ │
│ │ ObjectType + RelationType + ActionType │ │
│ │ 客户 ← 订单 → 产品 ← 库存 → 供应商 │ │
│ └─────────────────┬────────────────────────┘ │
│ │ │
│ ┌─────────────────┴────────────────────────┐ │
│ │ Pipeline Builder │ │
│ │ 数据接入 + 转换 + 版本控制 + 增量计算 │ │
│ └─────────────────┬────────────────────────┘ │
│ │ │
│ ┌─────────────────┴────────────────────────┐ │
│ │ Data Connection Framework │ │
│ │ 200+ 连接器 (SAP, Salesforce, Kafka...) │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
让我们逐层拆解。
第一层：Data Connection Framework（数据连接框架）
Foundry 的第一步是连接企业现有的所有数据源：
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ SAP │ │Salesforce│ │ Kafka │ │ S3 │
│ ERP │ │ CRM │ │ 事件流 │ │ 数据湖 │
└────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
│ │ │ │
└────────────┴────────────┴────────────┘
│
┌───────┴───────┐
│ Foundry 连接层 │
│ 统一抽象 │
└───────────────┘
关键设计原则：
- 不搬数据：建立连接和同步，不是把数据全部复制过来
- 增量同步：只同步变化的部分
- 元数据发现：自动识别源系统的表结构和字段含义
第二层：Pipeline Builder（数据管道构建器）
连接之后，需要对数据进行清洗、转换和编排。Foundry 的 Pipeline Builder 提供了三种模式：
| 模式 | 适用人群 | 描述 |
|---|---|---|
| 可视化拖拽 | 业务分析师 | 像流程图一样编排数据转换 |
| SQL | 数据分析师 | 用 SQL 写转换逻辑 |
| Python/Java | 数据工程师 | 用代码写复杂的转换逻辑（称为 Transform） |
Pipeline Builder 的杀手特性是版本控制：
main branch: [v1] → [v2] → [v3] → [v4]
↗
feature branch: [v3] → [v3.1] → [v3.2]
↘
merge → [v5]
每次数据转换都有完整的版本历史，可以：
- 回滚到任意历史版本
- 分支出去做实验（不影响生产数据）
- 查看每个字段的数据血缘（这个值从哪来的？）
这和 Gotham 的"调查历史可回溯"是同一个设计思想。
第三层：Ontology（语义层）
这一层在上一篇文章中已经详细讲过。在 Foundry 的语境中，Ontology 的作用是：
把 Pipeline 处理后的数据，变成业务人员能理解的对象。
Pipeline 输出:
table: processed_orders
columns: order_id, customer_id, product_id, amount, status, created_at
Ontology 映射:
ObjectType: 订单
属性: 订单号, 金额, 状态, 创建时间
关系: 属于 → 客户
关系: 包含 → 产品
操作: [审批] [取消] [发货]
指标: 平均处理时长（派生属性，自动计算）
第四层：Actions + Rules + Functions（行动层）
这是 Foundry 区别于所有"数据平台"的关键层。
Actions（动作）：预定义的业务操作
ActionType: "审批订单"
参数: order_id (必填), comment (可选)
前置条件: 订单状态 = "待审批"
执行逻辑:
1. 更新订单状态为 "已审批"
2. 通知仓库准备发货
3. 记录审批人和时间
权限: 需要 "order:approve" 角色
Rules（规则）：条件触发的自动化
Rule: "库存预警"
条件: 产品.当前库存 < 产品.安全库存阈值
动作:
1. 创建采购建议单
2. 通知采购经理
3. 标记产品为"库存预警"状态
频率: 实时（基于数据变更事件）
Functions（函数）：用户自定义的计算逻辑
@function
def calculate_churn_risk(customer: Customer) -> float:
"""计算客户流失风险"""
days_since_last_order = (now() - customer.last_order_date).days
order_frequency_change = customer.recent_frequency / customer.historical_frequency
return churn_model.predict(days_since_last_order, order_frequency_change)
第五层：Workshop / Contour / AIP（应用层）
Workshop — 低代码应用构建平台
不需要写前端代码，直接拖拽组件搭建业务应用：
┌─────────────────────────────────────────┐
│ 供应链风险监控看板 │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ 风险指标 │ │ 供应商地图 │ │
│ │ KPI 卡片 │ │ (地理可视化) │ │
│ └──────────┘ └──────────────────────┘ │
│ ┌──────────────────────────────────────┤
│ │ 风险事件列表 │
│ │ [查看详情] [处理] [升级] [忽略] │
│ ├──────────────────────────────────────┤
│ │ 趋势图表 (近 30 天风险事件数) │
│ └──────────────────────────────────────┘
└─────────────────────────────────────────┘
Workshop 中的每个组件都直接绑定 Ontology 中的对象和操作——点击"处理"按钮，就直接触发一个 Action。
Contour — 交互式数据分析
类似于"企业级 Excel"，但背后连接的是 Ontology：
- 拖拽维度和指标
- 交叉筛选和钻取
- 联动图表
- 分享给同事协作
AIP — AI 平台（2023 年新增）
让大模型在 Ontology 之上工作：
用户（自然语言）: "帮我找出本月退货率最高的 5 个供应商，
并为每个供应商生成质量审核任务"
AIP 执行:
1. 理解意图 → 转化为 OQL 查询
2. 查询 Ontology → 获取供应商 + 退货数据
3. 计算退货率 → 排序取 Top 5
4. 对每个供应商 → 调用 ActionType "创建质量审核任务"
5. 返回执行结果 → "已为以下 5 家供应商创建审核任务：..."
#2.3 Foundry 的典型企业案例
案例一：空客——300 万零件的供应链编排
空客制造一架 A350 需要来自全球 30 个国家、数百家供应商的约 300 万个零件。
痛点：
- 任何一个零件延迟都可能影响整架飞机的交付
- 供应链变更需要在数十个系统中追踪
- 质量问题需要追溯到具体批次和供应商
Foundry 方案：
Ontology 建模:
飞机 ← 由...组成 → 部件 ← 由...组成 → 零件
零件 ← 供应 → 供应商
零件 ← 批次 → 质检记录
供应商 ← 位于 → 地理区域
自动化规则:
IF 零件.交付状态 = "延迟"
AND 零件.关键等级 = "A级"
THEN
通知项目经理
自动查找替代供应商
评估对交付时间的影响
效果：供应链中断响应时间从天级降到分钟级。
案例二：摩根大通——反洗钱与交易监控
痛点：
- 每天处理数万亿美元的交易
- 反洗钱合规要求越来越严格
- 传统规则引擎误报率极高（>95%），分析师疲于应付
Foundry 方案：
Ontology 建模:
客户 ← 持有 → 账户 ← 发起 → 交易
交易 ← 流向 → 账户 ← 持有 → 客户
客户 ← 关联 → 客户（亲属、商业伙伴）
客户 ← 标记 → 风险等级
分析能力:
- 交易模式分析（频率、金额、目的地的异常检测）
- 关联网络分析（资金在关联账户间的流转路径）
- 历史行为对比（与客户自身历史模式的偏差）
效果：误报率下降 60%+，分析师效率提升 4 倍。
案例三：英国 NHS——新冠疫情应对
痛点：
- 疫苗需要在特定温度下运输和存储
- 不同地区的接种需求不同
- ICU 床位和医疗物资需要动态调配
Foundry 方案：
Ontology 建模:
疫苗批次 ← 存储于 → 仓库 ← 服务 → 区域
区域 ← 包含 → 接种点
接种点 ← 预约 → 居民
居民 ← 属于 → 优先级分组（年龄、基础疾病）
决策支持:
- 预测各区域未来 7 天的疫苗需求
- 优化疫苗分配（考虑保质期、运输距离、接种能力）
- 实时监控冷链温度异常
效果：支持了英国全国疫苗接种计划的物流编排。
#三、Gotham vs Foundry：深度对比
#3.1 功能层面对比
| 能力维度 | Gotham | Foundry |
|---|---|---|
| 数据整合 | 多源情报融合（SIGINT/HUMINT/OSINT） | 企业多系统数据集成（ERP/CRM/IoT） |
| 核心交互 | 调查式分析（图形化探索、链接分析） | 运营式工作流（看板、审批、操作面板） |
| 分析模式 | 自由探索、假设驱动 | 结构化分析、指标驱动 |
| 用户画像 | 情报分析师（高技能、深度使用） | 多角色（从数据工程师到业务经理） |
| 行动输出 | 情报简报、行动建议 | 自动化 Action、工作流触发 |
| 协作模式 | 调查协作（多人调查同一案件） | 企业协作（跨部门数据共享与操作） |
| 可视化 | 知识图谱、地理空间、时间线 | Dashboard、图表、KPI 卡片 |
| AI 集成 | 模式识别、异常检测 | AIP（自然语言→动作） |
| 部署环境 | 高安全环境（气隙网络、SCIF） | 云 + 私有化 + 混合部署 |
#3.2 技术共享层面
虽然面向不同用户，Gotham 和 Foundry 共享了大量底层技术：
Gotham 独有 共享层 Foundry 独有
───────────── ────────────── ──────────────
情报融合引擎 Ontology 核心 Pipeline Builder
链接分析 UI 数据整合引擎 Workshop (低代码)
地理空间引擎 权限与安全模型 Contour (分析)
Pattern of Life 版本控制 AIP (AI 平台)
SIGINT 适配器 审计追踪 200+ 连接器
战术 UI 搜索引擎 Transform 语言
实体解析
API 层
关键共享组件：
- Ontology 引擎：对象和关系的建模、存储、查询——完全相同的核心
- 权限模型：从军事密级继承的 RBAC + ABAC 模型，是 Foundry 企业安全的基础
- 数据版本控制：Gotham 的调查历史回溯能力，变成了 Foundry 的数据分支和 What-if 分析
- 审计追踪：军事场景中"谁看了什么数据"的审计要求，直接迁移到企业合规场景
- 实体解析：Gotham 中识别"同一嫌疑人"的技术，在 Foundry 中变成识别"同一客户"
#3.3 商业模式对比
| 维度 | Gotham | Foundry |
|---|---|---|
| 合同类型 | 多年期政府合同 | 年度订阅 + 扩展 |
| 实施模式 | 重度定制 + 驻场支持 | 平台化 + 自助使用 |
| 收入增长 | 稳定但增速有限 | 高速增长 |
| 毛利率 | 高（政府预算充足） | 正在提升 |
| 客户集中度 | 高（少量大客户） | 分散化中 |
2024 年财报数据：
- 政府业务收入：约 13 亿美元（同比增长 ~20%）
- 商业业务收入：约 12 亿美元（同比增长 ~29%，其中美国商业增长 ~54%）
商业业务正在快速追赶，预计 2025 年将超过政府业务。
#四、从 Gotham 到 Foundry 的启示
#4.1 "军转民"的方法论
Palantir 的"军转民"路径给了我们一个重要启示：
“最硬核的企业软件，往往诞生于最极端的场景。
军事和情报场景对软件的要求是最苛刻的：
- 数据量巨大：全球范围的情报数据
- 安全要求最高：军事密级、零容忍泄露
- 决策速度要求最快：生死攸关、分秒必争
- 容错率为零：错误决策可能导致人员伤亡
在这种环境中锤炼出来的技术，移植到企业场景时，会带来"降维打击"：
军事场景要求: 企业场景现状:
───────────── ─────────────
毫秒级响应 ─────降维─────→ "能在一天内出报告就不错了"
零信任安全 ─────降维─────→ "权限管理？我们用 Excel 管"
全链路审计 ─────降维─────→ "审计？出事了再查吧"
实时决策 ─────降维─────→ "每周开一次决策会"
#4.2 Ontology 是跨场景的通用抽象
Gotham 和 Foundry 证明了一个核心判断：
“无论场景多么不同，"将数据变成有语义的对象，在对象上定义操作，通过规则自动触发操作"——这个模式是通用的。
- 在情报分析中：嫌疑人是对象，通话是关系，"标记为高风险"是操作
- 在供应链中：供应商是对象，供应是关系，"切换供应商"是操作
- 在金融风控中：账户是对象，交易是关系，"冻结账户"是操作
- 在医疗中：患者是对象，就诊是关系，"创建处方"是操作
模式完全相同，只是实体和关系不同。
这就是 Ontology 作为抽象层的力量——它不关心你是在打仗还是在做生意，它只关心"世界由哪些东西组成，它们之间有什么关系，你能对它们做什么操作"。
#4.3 先做最难的事
Palantir 的创业路径给了另一个启示：
“先搞定最难的客户（CIA、NSA），再去服务容易的客户（商业企业）。
这和多数 SaaS 公司"先做 SMB、再做大企业"的路径完全相反。
好处是：
- 技术壁垒极高（没有人能在不做军事客户的情况下积累同等的安全和数据整合经验）
- 参考案例无敌（"美军都在用"是最好的销售话术）
- 安全能力成为护城河（企业客户最关心的数据安全问题，Palantir 早已解决到了最高标准）
#五、对我们的启发：coomia-dip 的设计哲学
我们的 coomia-dip（智策平台）在设计上吸收了 Gotham 和 Foundry 的核心理念：
| Palantir 理念 | coomia-dip 对应 |
|---|---|
| Ontology 驱动 | 8 个 Layer 中，Ontology 是核心中的核心（Control Layer 的 SchemaRegistry） |
| 多源数据融合 | Data Layer 的 Data Connection + Flink CDC + Pipeline |
| 军事级安全 | 三层权限模型（RBAC+ABAC+ReBAC）+ 7 级数据分类 + 6 种脱敏模式 |
| 从数据到行动 | Reasoning & Decision Layer 规则引擎 → Reasoning & Decision Layer 决策引擎 → Agent Runtime Layer 执行引擎，完整闭环 |
| 数据版本控制 | Nessie + Iceberg 实现 World/Branch/Release（类比 Foundry 的 Branching） |
| 审计追踪 | Metadata & Governance Layer 的 AuditService（13 种事件类型 + 完整决策链审计） |
| AI 原生 | Reasoning & Decision Layer 的 RAG + AIP Logic + ML 模型管理 |
在后续的架构全景系列（S2）中，我们会详细展开每一项设计决策。
#关键收获
- Gotham 是战场锤炼的产物：在最极端的情报和军事场景中证明了 Ontology + 数据融合 + 决策支持的方法论
- Foundry 是方法论的平民化：将 Gotham 的核心技术移植到企业场景，加上 Pipeline Builder、Workshop、AIP 等工具层，降低了使用门槛
- 两条产品线共享同一个灵魂——Ontology：这证明了"数据→语义→决策→行动"这个模式的通用性——无论你是在反恐还是在优化供应链
#下一篇预告
《为什么美军把最高机密交给 Palantir？Gotham 深度拆解》 — 深入 Gotham 的技术架构和实战案例，理解 Pattern of Life 分析、协作调查平台和军事级权限模型的设计。
“本文是「Palantir 解密」系列的第 2 篇，共 20 篇。
如果这篇文章对你有帮助：
- 关注我们的技术博客，每日更新
- 访问 coomia-dip 开源项目了解我们的实现
- 加入技术社区参与讨论
标签：#Palantir #Gotham #Foundry #Ontology #入门 #所有人