我们为什么要做中国版 Palantir？以及我们的路线图
1. [Palantir 为什么不服务中国？](#1-palantir-为什么不服务中国)
Coomia发布于 2025年6月21日29 分钟阅读
分享本文Twitter / X
“系列：S1 Palantir 解密 · 第 20 篇 | 难度：入门 | 阅读时间：15 分钟
我们为什么要做中国版 Palantir？以及我们的路线图
#TL;DR
- Palantir 因地缘政治和数据主权无法服务中国市场，但它解决的"从数据到决策"的核心问题在全球每个企业中普遍存在
- coomia-dip（智策平台）采用开源、第一性原理、Ontology 驱动的方法，用 8-Layer 架构构建了对标 Palantir Foundry 的完整能力——目前已有 6000+ 测试、95% 后端就绪、109 个功能能力
- 我们的愿景是让 Palantir 级别的企业智能决策能力成为每个企业都能使用的开源基础设施，而不是只有财富 500 强才能承担的奢侈品
#目录
- Palantir 为什么不服务中国？
- Palantir 解决的核心问题是普遍的
- 我们的方法：开源、第一性原理、Ontology 驱动
- 8-Layer 架构总览
- 当前状态：我们走到了哪里
- 技术选型及原因
- 路线图：已完成与计划中
- 如何参与
- 愿景：让每个企业拥有 Palantir 级别的能力
#1. Palantir 为什么不服务中国？
在前面 19 篇文章中，我们深入解析了 Palantir 的产品、技术、商业模式和市场表现。一个不可回避的事实是：Palantir 不服务中国市场，而且在可预见的未来也不会。
#三层原因
Code
+-------------------------------------------------------------------+
| 第一层：地缘政治限制 |
| |
| - Palantir 核心客户是美国国防部/CIA/NSA |
| - Alex Karp 公开表态支持"西方价值观" |
| - 公司章程明确：不在中国和俄罗斯运营 |
| - 美国出口管制（EAR/ITAR）限制技术转让 |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| 第二层：数据主权法规 |
| |
| - 中国《数据安全法》(2021) 要求数据本地化 |
| - 中国《个人信息保护法》(PIPL) 限制跨境传输 |
| - 关键信息基础设施数据不得出境 |
| - Palantir 的云架构不支持纯本地化部署 |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| 第三层：市场策略选择 |
| |
| - Palantir 聚焦北美+欧洲+五眼联盟 |
| - 中国市场需要完全不同的销售/部署模式 |
| - 本地竞争对手的存在降低了进入动机 |
| - 投资者关系风险：在中国运营可能影响美国政府合同 |
+-------------------------------------------------------------------+
#这不仅仅是中国的问题
Palantir 不服务的市场远不止中国：
Code
Palantir 不服务或有限服务的市场:
+------------------+-------------------------------------------+
| 市场 | 原因 |
+------------------+-------------------------------------------+
| 中国 | 地缘政治 + 主动排除 |
| 俄罗斯 | 制裁 + 主动排除 |
| 中东（部分） | 出口管制 |
| 东南亚（多数） | 市场策略 + 部署成本 |
| 非洲 | 市场规模 + 部署复杂度 |
| 南美（多数） | 有限覆盖 |
| 中小企业 | 价格门槛（年费 $1M+） |
+------------------+-------------------------------------------+
= 全球约 70% 的企业无法使用 Palantir
#2. Palantir 解决的核心问题是普遍的
Palantir 解决的不是一个美国特有的问题，而是一个全球性的普遍挑战：如何让组织从"有数据"变成"能决策"。
#每个企业都面临的困境
Code
典型企业的数据困境:
有数据，但是...
|
+--------------+--------------+
| | |
数据在孤岛 数据不互通 数据不产生决策
| | |
+----------+ +-----------+ +----------+
| ERP | | 无法回答 | | 分析报告 |
| CRM | | 跨系统的 | | 看完就完 |
| WMS | | 业务问题 | | 无法执行 |
| MES | | | | |
| 自建系统 | | | | |
+----------+ +-----------+ +----------+
"我有100个系统 "供应链问题 "CEO说要数据驱动
但它们不说话" 影响了哪些 可我们只做到了
客户的哪些 数据展示驱动"
订单？"
#Palantir 的解决方案（抽象后）
Code
Palantir 的核心解决方案可以归纳为四步:
步骤 1: 数据整合（Data Integration）
100个孤岛系统 --> 统一数据层
"所有数据在一个地方，保持鲜活"
步骤 2: 语义建模（Ontology）
原始数据 --> 业务对象 + 关系
"不是表和行，是客户、订单、工厂、供应商"
步骤 3: 智能分析（Reasoning + AI）
业务对象 --> 推理 + 规则 + AI
"自动发现异常、计算影响、推荐决策"
步骤 4: 操作闭环（Actions）
决策 --> 自动执行
"不只是看报表，而是触发真实操作"
+----------+ +---------+ +----------+ +--------+
| 数据整合 | --> | 语义建模 | --> | 智能分析 | --> | 操作 |
| Data | | Ontology | | Reasoning| | Action |
+----------+ +---------+ +----------+ +--------+
这四步，与国家和文化无关。
每个企业都需要。
#中国企业的特殊需求
在普遍需求之上，中国企业还有一些特殊的要求：
Code
+---------------------------+--------------------------------------+
| 特殊需求 | 原因 |
+---------------------------+--------------------------------------+
| 数据必须在境内 | 数据安全法、PIPL |
| 支持国产数据库 | 信创要求（达梦、TiDB、OceanBase） |
| 支持私有化部署 | 央企/国企/军工不允许公有云 |
| 中文 NLP 能力 | AI 场景需要中文理解 |
| 合规审计 | 等保 2.0 / 密评 / 国标 |
| 适配中国云生态 | 阿里云/腾讯云/华为云 |
| 可控的技术栈 | 不依赖可能被制裁的组件 |
+---------------------------+--------------------------------------+
#3. 我们的方法：开源、第一性原理、Ontology 驱动
coomia-dip（智策平台）不是简单地"复制 Palantir"。我们采用了第一性原理的方法，重新思考"Ontology 驱动的智能决策平台"应该如何构建。
#三大原则
Code
原则 1: 开源优先
+-------------------------------------------------------------------+
| "如果 Ontology 是企业智能的基础设施， |
| 那么它应该是开放的，就像 Linux 之于操作系统。" |
| |
| - 核心平台完全开源 |
| - 社区驱动的发展 |
| - 透明的开发过程 |
| - 企业版提供商业支持和高级功能 |
+-------------------------------------------------------------------+
原则 2: 第一性原理
+-------------------------------------------------------------------+
| "不是复制 Palantir 的产品，而是解决 Palantir 解决的问题。" |
| |
| - 从问题出发而非从解决方案出发 |
| - 每个技术选择都有明确的理由 |
| - 不盲目追随，也不盲目反对 |
| - 在某些方面做得比 Palantir 更好（如推理引擎原生集成） |
+-------------------------------------------------------------------+
原则 3: Ontology 驱动
+-------------------------------------------------------------------+
| "Ontology 不是可选的附加功能，而是整个平台的内核。" |
| |
| - 所有操作在 World Context 下执行 |
| - 所有数据通过 Ontology 语义化 |
| - 所有决策可追溯到 Ontology 中的规则和关系 |
| - AI/LLM 通过 Ontology 理解业务 |
+-------------------------------------------------------------------+
#与 Palantir 的定位差异
Code
+------------------+-------------------------------+-------------------+
| 维度 | Palantir Foundry | coomia-dip 智策 |
+------------------+-------------------------------+-------------------+
| 源代码 | 封闭 | 开源 |
| 部署模式 | SaaS + 有限私有化 | 自部署优先 |
| 目标客户 | 财富 500 强 / 政府 | 所有企业 |
| 年费 | $1M - $100M+ | 开源免费 |
| 数据主权 | 数据在 Palantir 云上 | 数据完全自主 |
| 技术可控 | 依赖 Palantir 专有技术 | 全栈自主可控 |
| 社区 | 无开放社区 | 开发者社区 |
| AI 集成 | AIP (2023年后) | 原生集成(Day 1) |
| 推理引擎 | 有限（规则主要在 Workshop） | 原生推理引擎 |
| 场景模拟 | World (受限) | World Fork(完整) |
+------------------+-------------------------------+-------------------+
#4. 8-Layer 架构总览
coomia-dip 采用 8-Layer 架构，每个 Layer 是一个独立的工程责任域，可以独立开发、测试和部署。
#架构全景图
Code
+====================================================================+
| 智策平台 (coomia-dip) |
| Ontology-driven Intelligent Decision PaaS |
+====================================================================+
| |
| +-------------------------------+ +----------------------------+ |
| | SDK & Developer Experience Layer: SDK & Dev Exp. | | Deployment & Operations Layer: Deployment & Ops | |
| | Python SDK (OntoPlatform) | | Docker Compose | |
| | TypeScript OSDK Generator | | K8s Platform Console | |
| | 28 sub-modules, 39 gRPC | | Monitoring & Alerting | |
| +-------------------------------+ +----------------------------+ |
| | | |
| v v |
| +==============================================================+ |
| | gRPC Gateway Layer | |
| +==============================================================+ |
| | |
| +-----------+------------+--------------+ |
| | | | | |
| v v v v |
| +--------+ +--------+ +--------+ +----------+ |
| |Control Layer | |Data Layer | |Reasoning & Decision Layer | | Pipeline & Orchestration Layer | |
| |Control | | Data | | +E Int.| | Pipeline | |
| | Layer | | Layer | | Runtime| | & Orch | |
| | | | | | | | | |
| |Spring | |Quarkus | |FastAPI | | Quarkus | |
| |Boot 3 | | 3.x | |Python | | Dolphin | |
| |Java 21 | |Java 21 | | 3.x | | Scheduler| |
| | | | | | | | | |
| |Schema | |Query | |Reason | |Pipeline | |
| |Action | |Storage | |Decision| |Schedule | |
| |Policy | |Sync | |Agent | |Transform | |
| |Object | |Search | |Function| |Connection| |
| |Metric | |Export | |Rule | | | |
| |Notif. | |Analyti.| |Approval| | | |
| +--------+ +--------+ +--------+ +----------+ |
| | | | |
| +-----+-----+-----+-----+ |
| | | |
| v v |
| +==============================================================+ |
| | Metadata & Governance Layer: Metadata & Governance | |
| | Audit Service | Classification | Lineage | Compliance | |
| +==============================================================+ |
| | |
| v |
| +==============================================================+ |
| | Unified Storage Layer | |
| | +--------+ +--------+ +-------+ +-------+ +---------+ | |
| | | Doris | | Iceberg| | Nessie| | Redis | | Kafka | | |
| | | (OLAP+ | | (Version| | (Git- | | (Cache| | (Event | | |
| | | Vector| | Tables)| | like | | +Pub/ | | Stream)| | |
| | | +Full | | | | Branch| | Sub) | | | | |
| | | Text) | | | | ing) | | | | | | |
| | +--------+ +--------+ +-------+ +-------+ +---------+ | |
| +==============================================================+ |
+====================================================================+
#每个 Layer 的职责
Code
+-------+----------------------------+----------------------------------+
| Layer | 名称 | 核心职责 |
+-------+----------------------------+----------------------------------+
| A | Platform Deployment & Ops | 部署编排、监控告警、 |
| | | K8s 平台控制台 |
+-------+----------------------------+----------------------------------+
| B | Control Layer | Ontology Schema 管理、 |
| | | Action/Policy/Object 管理、 |
| | | 认证授权、通知 |
+-------+----------------------------+----------------------------------+
| C | Data Layer | 数据查询引擎、存储同步、 |
| | | 全文搜索、分析聚合、 |
| | | 数据导出、实时订阅 |
+-------+----------------------------+----------------------------------+
| D+E | Intelligence Runtime | 规则推理、决策树、 |
| | (onto-intelligence) | Agent 运行时、Function、 |
| | | 审批工作流、场景模拟 |
+-------+----------------------------+----------------------------------+
| F | Pipeline & Orchestration | 数据管道、调度、 |
| | | 转换、连接器 |
+-------+----------------------------+----------------------------------+
| G | Metadata & Governance | 审计日志、数据分类、 |
| | | 数据血缘、合规管理 |
+-------+----------------------------+----------------------------------+
| H | SDK & Developer Experience | Python SDK、TypeScript OSDK、 |
| | | 代码生成器、开发者文档 |
+-------+----------------------------+----------------------------------+
#设计原则
Code
1. World Context 是一级概念
所有操作必须在 Project + World 上下文中执行。
World 可以 Fork（类似 Git Branch），支持场景模拟。
2. gRPC 优先（内部通信）
Layer 之间通信全部使用 gRPC，不使用 REST。
gRPC 提供: 类型安全 + 流式传输 + 高性能 + 代码生成。
3. 契约驱动
Layer 之间通过 .proto 文件定义契约。
任何一方可以独立开发和测试。
4. 版本化一切
数据、Schema、Pipeline、Function、Rule、Code —— 全部版本化。
Fork World 时快照所有制品版本，确保推演 100% 可重放。
5. SDK 是能力暴露层
SDK 不承载业务逻辑，仅封装 gRPC 调用。
所有业务逻辑在后端 Layer 中实现。
#5. 当前状态：我们走到了哪里
截至 2026 年 3 月，coomia-dip 已经完成了核心后端的绝大部分开发工作。
#总体进度
Code
+-------+---------------------------+-------+------------+-----------+
| Layer | 名称 | 进度 | 代码文件 | 测试数 |
+-------+---------------------------+-------+------------+-----------+
| A | Deployment & Ops | 20% | Docker脚本 | - |
| B | Control Layer | 90% | 211+ Java | 1,238 |
| C | Data Layer | 98% | 520+ Java | 1,961 |
| D+E | Intelligence Runtime | 98% | 200+ Python| 2,519 |
| F | Pipeline & Orchestration | 92% | 100+ Java | 20+ |
| G | Metadata & Governance | 87% | 4 Services | 16+ |
| H | SDK & Developer Exp. | 99% | 125+ Py+TS | 475 |
+-------+---------------------------+-------+------------+-----------+
| 总计 | | ~95% | 1,156+ | 6,229+ |
+-------+---------------------------+-------+------------+-----------+
#功能能力清单（109 个）
coomia-dip 目前实现了 109 个独立的功能能力，覆盖了 Palantir Foundry 的核心功能集：
Code
Ontology 管理 (16 个能力):
Object Type CRUD | Link Type CRUD | Property 管理 |
Schema 版本控制 | 约束定义 | 派生属性 | ...
数据操作 (18 个能力):
对象实例 CRUD | 批量操作 | 条件查询 | 排序分页 |
关系遍历 | 聚合查询 | 时间序列 | TopN | 分布分析 | ...
Action & Function (12 个能力):
Action Type 定义 | Action 执行 | 参数验证 |
Function 注册 | Function 执行 | 代码绑定生成 | ...
推理 & 决策 (15 个能力):
规则集 CRUD | 规则推理 | 流式推理 |
决策树 CRUD | 决策执行 | 模拟 |
审批工作流 | 触发规则 | 变更规则 | ...
场景模拟 (6 个能力):
World CRUD | World Fork | 分支合并 |
快照对比 | 推演重放 | ...
搜索 & 分析 (12 个能力):
全文搜索 (6种模式) | 分面统计 | 拼写建议 |
保存搜索 | 分析聚合 | 时间桶 | ...
数据管道 (8 个能力):
Pipeline CRUD | 调度管理 | 连接器 |
转换定义 | 执行监控 | ...
治理 & 安全 (10 个能力):
审计日志 | 数据分类 | 数据血缘 |
策略管理 | 权限控制 | ...
平台运维 (6 个能力):
指标管理 | 通知 | 仪表盘 |
数据导出 | 实时订阅 | ...
SDK & 开发者 (6 个能力):
Python SDK | TypeScript OSDK | Async 客户端 |
gRPC 客户端 | 代码生成 | ...
#详细设计文档
Code
已完成的详细设计文档: 116+ 份
+------------------+---------+
| 类别 | 数量 |
+------------------+---------+
| Control Layer 详设 | 40 份 |
| Data Layer 详设 | 25 份 |
| Reasoning & Decision Layer + Agent Runtime Layer 详设 | 17 份 |
| Pipeline & Orchestration Layer 详设 | 23 份 |
| Metadata & Governance Layer 详设 | 5 份 |
| SDK & Developer Experience Layer 详设 | 6 份 |
+------------------+---------+
#6. 技术选型及原因
每一项技术选择都有明确的理由。以下是核心选型及其背后的思考。
#为什么 gRPC 而不是 REST？
Code
+------------------+------------------+------------------------+
| 维度 | REST/JSON | gRPC/Protobuf |
+------------------+------------------+------------------------+
| 类型安全 | 无（JSON 无类型）| 有（.proto 定义） |
| 代码生成 | 需要 OpenAPI | 原生支持 |
| 流式传输 | 不原生支持 | 原生双向流 |
| 性能 | 文本序列化 | 二进制序列化（快 10x） |
| 契约优先 | 文档优先 | Schema 优先 |
| 跨语言 | 需要 SDK 封装 | 原生跨语言代码生成 |
+------------------+------------------+------------------------+
决策: 内部服务间通信全部使用 gRPC。
SDK 对外也提供 gRPC 接口（更高性能）。
HTTP REST 仅作为 Gateway 层的可选暴露方式。
#为什么 Apache Doris 而不是 ClickHouse + Qdrant？
Code
传统方案: 多个引擎拼接
+------------+ +----------+ +---------+
| ClickHouse | | Qdrant | | Elastic |
| (OLAP) | | (向量) | | (全文) |
+------------+ +----------+ +---------+
| | |
需要同步数据 需要同步数据 需要同步数据
| | |
+--------------------------------------+
| 数据一致性？同步延迟？运维成本？ |
+--------------------------------------+
coomia-dip 方案: 统一引擎
+--------------------------------------------+
| Apache Doris |
| |
| OLAP 分析 + 向量搜索 + 全文检索 |
| (列式存储) (ANN索引) (倒排索引) |
| |
| 一份数据，三种查询能力 |
| 零同步延迟，零一致性问题 |
+--------------------------------------------+
决策理由:
- 运维复杂度: 1个组件 vs. 3个组件
- 数据一致性: 实时 vs. 最终一致
- 开发效率: 单一 SQL 方言 vs. 三套 API
- 社区生态: Doris 在中国有强大社区和商业支持
#为什么 Nessie + Iceberg 做版本化？
Code
版本化需求:
- World Fork 需要数据快照
- 推演/回溯需要历史版本
- Schema 变更需要可回滚
- 多分支并行开发需要隔离
Nessie + Iceberg 的方案:
+-------------------------------------------+
| Nessie (Git-like 版本控制) |
| +-------+ +-------+ +-------+ |
| | main | | fork1 | | fork2 | ... |
| | branch| | branch| | branch| |
| +-------+ +-------+ +-------+ |
| | | | |
| v v v |
| Iceberg (版本化表格式) |
| - 快照隔离: 每个分支看到自己的数据版本 |
| - 时间旅行: 回到任意历史时刻 |
| - Schema 演化: 无缝添加/删除列 |
| - 零拷贝 Fork: 分支创建是 O(1) 操作 |
+-------------------------------------------+
这与 Palantir 的 World/Branch 机制高度一致，
但使用的是开源组件而非专有技术。
#为什么 Python + FastAPI 做智能层？
Code
Intelligence Layer 技术选型理由:
+-------------------+-------------------------------------------+
| 选择 | 理由 |
+-------------------+-------------------------------------------+
| Python 3.x | AI/ML 生态最丰富（PyTorch、 |
| | Transformers、LangChain） |
+-------------------+-------------------------------------------+
| FastAPI | 异步原生、自动 OpenAPI、 |
| | Pydantic 类型验证 |
+-------------------+-------------------------------------------+
| gRPC (grpcio) | 与 Java Layer 统一通信协议 |
+-------------------+-------------------------------------------+
| Pydantic v2 | 高性能数据验证、JSON Schema 生成 |
+-------------------+-------------------------------------------+
不使用 Spring Boot 的原因:
- AI/ML 库在 Java 中不成熟
- Python 开发效率在推理场景中显著更高
- 数据科学家更熟悉 Python
- 规则引擎的 DSL 在 Python 中更自然表达
#为什么 Control Layer 用 Spring Boot？
Code
Control Layer 技术选型理由:
+-------------------+-------------------------------------------+
| 选择 | 理由 |
+-------------------+-------------------------------------------+
| Spring Boot 3.x | 企业级成熟度最高、生态最丰富 |
| Java 21 | Virtual Threads 提升并发性能 |
| Spring Data JPA | Schema 管理的 CRUD 场景最合适 |
| Spring Security | 认证授权框架完善 |
| gRPC-Spring | gRPC + Spring 无缝集成 |
+-------------------+-------------------------------------------+
不使用 Python 的原因:
- Schema 管理需要强事务支持
- Java 的类型系统更适合元数据管理
- Spring 生态在企业级中间件集成方面更成熟
- 与 Data Layer (Quarkus) 共享 Java 生态
#完整技术栈一览
Code
+------------------+--------------------+---------------------------+
| 层次 | 技术 | 用途 |
+------------------+--------------------+---------------------------+
| SDK | Python 3.x | 主 SDK 语言 |
| | TypeScript | 前端 OSDK |
| | Protobuf | API 契约定义 |
+------------------+--------------------+---------------------------+
| Control Layer | Spring Boot 3.x | 元数据管理 |
| | Java 21 | 核心运行时 |
| | Spring Data JPA | ORM |
| | gRPC-Spring | 服务通信 |
+------------------+--------------------+---------------------------+
| Data Layer | Quarkus 3.x | 数据服务 |
| | Java 21 | 核心运行时 |
| | Apache Doris | 统一存储引擎 |
| | Iceberg + Nessie | 版本化数据表 |
+------------------+--------------------+---------------------------+
| Intelligence | FastAPI | API 框架 |
| | Python 3.x | 推理/决策/Agent |
| | Pydantic v2 | 数据模型 |
| | Temporal | 工作流编排 |
+------------------+--------------------+---------------------------+
| Pipeline | Quarkus 3.x | 管道服务 |
| | DolphinScheduler | 调度引擎 |
+------------------+--------------------+---------------------------+
| Governance | Java + gRPC | 审计/分类/血缘 |
| | Kafka | 审计事件消费 |
+------------------+--------------------+---------------------------+
| Infrastructure | Docker Compose | 开发环境 |
| | Kubernetes | 生产环境 |
| | Redis | 缓存 + 发布订阅 |
| | Kafka | 事件流 |
+------------------+--------------------+---------------------------+
#7. 路线图：已完成与计划中
#已完成里程碑
Code
Phase 1: 基础架构 (2025 Q3-Q4) ✅
- 8-Layer 架构设计
- 多 Agent 协作规范
- 开发工具链搭建
- Sprint/Release 工作流
Phase 2: 核心功能 (2025 Q4 - 2026 Q1) ✅
- Ontology Schema CRUD (Control Layer)
- 对象实例管理 (Control Layer + Data Layer)
- 数据查询引擎 (Data Layer)
- 规则推理引擎 (Reasoning & Decision Layer)
- 决策树引擎 (Reasoning & Decision Layer)
- Python SDK v1.0 (SDK & Developer Experience Layer)
Phase 3: 高级功能 (2026 Q1 - Q2) ✅ 进行中
- Action 执行链路 (Control Layer)
- 全文搜索 (Data Layer)
- 分析聚合查询 (Data Layer)
- 实时订阅 (Data Layer)
- 数据导出 (Data Layer)
- 审批工作流 (Reasoning & Decision Layer)
- 审计服务 (Metadata & Governance Layer)
- SDK 39 gRPC 客户端全部接线 (SDK & Developer Experience Layer)
#计划中的里程碑
Code
Phase 4: 产品化 (2026 Q2-Q3) -- 规划中
+---+----------------------------------+----------+
| # | 任务 | 优先级 |
+---+----------------------------------+----------+
| 1 | 前端 UI (React + TypeScript) | P0 |
| 2 | TypeScript OSDK 代码生成器 | P0 |
| 3 | 派生属性依赖 DAG | P1 |
| 4 | K8s 部署编排 | P1 |
| 5 | 监控告警集成 (Prometheus+Grafana) | P1 |
| 6 | 数据管道可视化 | P2 |
| 7 | Ontology 可视化浏览器 | P2 |
+---+----------------------------------+----------+
Phase 5: 企业级 (2026 Q3-Q4) -- 规划中
+---+----------------------------------+----------+
| # | 任务 | 优先级 |
+---+----------------------------------+----------+
| 1 | 多租户隔离 | P0 |
| 2 | RBAC + ABAC 完整实现 | P0 |
| 3 | 数据脱敏引擎 | P1 |
| 4 | 等保 2.0 合规 | P1 |
| 5 | 国产数据库适配 (达梦/TiDB) | P1 |
| 6 | LLM 集成 (AIP 等价层) | P0 |
| 7 | 文档和教程完善 | P1 |
+---+----------------------------------+----------+
Phase 6: 生态 (2027 Q1+) -- 远期
+---+----------------------------------+----------+
| # | 任务 | 优先级 |
+---+----------------------------------+----------+
| 1 | Ontology 模板市场 | P1 |
| 2 | 行业解决方案模板 | P1 |
| 3 | 第三方连接器生态 | P2 |
| 4 | 开发者认证体系 | P2 |
| 5 | 社区贡献指南和流程 | P1 |
+---+----------------------------------+----------+
#8. 如何参与
coomia-dip 是一个开源项目，欢迎所有人参与。
#参与方式
Code
+---+---------------------------+----------------------------------+
| # | 方式 | 适合人群 |
+---+---------------------------+----------------------------------+
| 1 | Star & Fork | 所有人 |
| 2 | 提交 Issue | 发现问题的用户 |
| 3 | 贡献代码 (PR) | 开发者 |
| 4 | 编写文档 | 技术写作者 |
| 5 | 行业方案设计 | 行业专家 |
| 6 | 翻译 | 多语言使用者 |
| 7 | 测试和反馈 | 早期使用者 |
| 8 | 社区布道 | 技术博主和演讲者 |
+---+---------------------------+----------------------------------+
#贡献一个 Layer
coomia-dip 的 8-Layer 架构天然支持分布式协作——每个 Layer 可以由独立的团队或个人负责：
Code
如果你擅长... 可以贡献...
+-------------------------+--------------------------------+
| Java + Spring Boot | Control Layer (Control Layer) |
| Java + Quarkus | Data Layer (Data) / F (Pipeline) |
| Python + FastAPI | Reasoning & Decision Layer + Agent Runtime Layer (Intelligence) |
| Python SDK 开发 | SDK & Developer Experience Layer (SDK) |
| TypeScript + React | 前端 UI / TypeScript OSDK |
| DevOps + K8s | Deployment & Operations Layer (Deployment) |
| 数据治理/合规 | Metadata & Governance Layer (Governance) |
| 技术写作 | 文档和教程 |
+-------------------------+--------------------------------+
#开发环境搭建
Bash
# 1. 克隆仓库
git clone https://github.com/your-org/coomia-dip.git
cd coomia-dip
# 2. 阅读必读文档
cat CLAUDE.md # 项目规范
cat AGENTS.md # 协作规范
cat PROGRESS.md # 当前进度
# 3. 启动开发环境
docker-compose up -d # 启动依赖服务
# 4. 选择你的 Layer
# Control Layer (Java)
cd control-Layer && ./gradlew build
# Data Layer (Java)
cd data-Layer && ./gradlew build
# Intelligence Layer (Python)
cd intelligence-Layer && pip install -e . && pytest
# SDK (Python)
cd python-sdk && pip install -e . && pytest
#9. 愿景：让每个企业拥有 Palantir 级别的能力
#当前的不公平
Code
现状:
财富 500 强企业:
+--------------------------------------------+
| Palantir Foundry |
| 年费 $1M-$100M+ |
| 专属工程师驻场 |
| 完整的 Ontology + AI + 决策能力 |
| --> 竞争优势: 数据驱动的决策速度 |
+--------------------------------------------+
其他 99% 的企业:
+--------------------------------------------+
| Excel + BI工具 + 一堆不互通的系统 |
| 数据在孤岛里 |
| 决策靠经验和直觉 |
| AI是"别人家的技术" |
| --> 竞争劣势: 决策速度差 10x |
+--------------------------------------------+
#我们想要的未来
Code
愿景:
所有企业:
+--------------------------------------------+
| coomia-dip (开源) |
| 免费使用核心平台 |
| 自主部署，数据完全可控 |
| 完整的 Ontology + AI + 决策能力 |
| --> 普惠: 每个企业都有 Palantir 级别能力 |
+--------------------------------------------+
类比:
- Linux 让每个人都能运行服务器级操作系统
- Kubernetes 让每个团队都能管理容器集群
- coomia-dip 让每个企业都能建立 Ontology 驱动的智能决策体系
#为什么这件事值得做？
Code
1. 数字化转型的最后一公里
多数企业已经完成了:
✅ 上云
✅ 建数据湖/数仓
✅ 部署 BI 工具
但卡在了:
❌ 数据 --> 决策 的转化
❌ AI 安全落地
❌ 跨系统的业务对象建模
coomia-dip 解决的就是这最后一公里。
2. 开源是正确的方式
Ontology 驱动的决策平台应该是基础设施，
而基础设施应该是开放的。
正如:
- 操作系统: Windows (闭源) --> Linux (开源)
- 数据库: Oracle (闭源) --> PostgreSQL (开源)
- 容器编排: 各种闭源 --> Kubernetes (开源)
- 决策平台: Palantir (闭源) --> coomia-dip (开源)
3. 中国需要自主可控的替代方案
不仅仅是"替代"，更是"适配":
- 适配中国的数据法规
- 适配中国的云生态
- 适配中国企业的部署习惯
- 适配中文 AI 能力
#从 S1 到 S2：下一季预告
这篇文章是 S1 系列（Palantir 解密）的最后一篇。在 S1 的 20 篇文章中，我们从 Palantir 的历史、产品、技术、商业模式到股价分析，完成了一次全面的解读。
Code
S1 系列回顾（20 篇）:
+------+-------------------------------------------+
| 编号 | 主题 |
+------+-------------------------------------------+
| 01 | 什么是 Palantir？ |
| 02 | Gotham vs. Foundry |
| ... | ... |
| 17 | Palantir 的竞争对手分析 |
| 18 | 股价从 $6 到 $80 |
| 19 | OSDK 开发者体验 |
| 20 | 我们为什么要做中国版 Palantir（本文） |
+------+-------------------------------------------+
S2 预告: coomia-dip 深度技术系列
+------+-------------------------------------------+
| 编号 | 主题 |
+------+-------------------------------------------+
| 01 | 8-Layer 架构：为什么这样分？ |
| 02 | Control Layer 深度解析 |
| 03 | Data Layer：统一存储的秘密 |
| 04 | Intelligence Layer：推理引擎设计 |
| 05 | SDK 设计哲学：39 个 gRPC 客户端的故事 |
| ... | 更多精彩内容 |
+------+-------------------------------------------+
S2 系列将深入 coomia-dip 的技术细节，面向想要理解、使用或贡献的开发者。如果 S1 是"为什么"，S2 就是"怎么做"。
#Key Takeaways
-
Palantir 不服务中国和全球约 70% 的企业市场，但它解决的"数据到决策"的核心问题是普遍的、迫切的。 coomia-dip 用开源的方式，让这个能力变得可获得——不再是只有财富 500 强才能享用的奢侈品。
-
coomia-dip 的 8-Layer 架构和技术选型不是盲目模仿 Palantir，而是基于第一性原理的重新思考。 gRPC 而非 REST、Doris 而非 ClickHouse+Qdrant、Nessie+Iceberg 做版本化、Python+FastAPI 做智能层——每个选择都有明确的工程理由。
-
6000+ 测试、95% 后端就绪、109 个功能能力、116+ 份详设文档——coomia-dip 不是一个概念或计划，而是一个正在快速成型的真实产品。 从 S1 到 S2，我们将从"解密 Palantir"转向"构建替代方案"的深度技术分享。
#下一季预告
“S2-01: 8-Layer 架构：为什么这样分？
深入 coomia-dip 的架构决策过程。为什么是 8 个 Layer 而不是微服务？Layer 之间的边界如何确定？gRPC 契约如何设计？多团队并行开发如何协调？从 ADR（架构决策记录）到代码实现的完整链路。
tags: coomia-dip, 智策平台, 中国版Palantir, 开源, Ontology, 8-Plane架构, 路线图, gRPC, Apache Doris, Nessie, Iceberg, 愿景