Palantir的技术史可以被重新理解为一套持续演进的双层架构：早期（2003-2020）以Gotham与Foundry为核心，通过动态本体和数据集群机制，建立了能够接纳残缺、多源、混乱数据的数据融合层；后期（2023之后）以AIP平台为标志，将大模型接入这套系统，补上了长期缺少的认知交互层。

数据融合层解决如何把现实世界的数据收进来并组织起来，认知交互层解决如何让更多用户用自然语言调用、修改和驱动这套系统。

本文追溯这套架构的思想来源，分析动态本体专利与数据集群专利的技术机制，解释不完整信息如何被转化为关系、风险变量和行动依据，再以AIP及经营数据说明，大模型为何能够放大Palantir原有能力，并进一步指出，Palantir的竞争力不在某一项算法或模型，而在于动态本体、数据融合、关系网络推演、细粒度权限、Action、Write-back和FDE现场校准的组合。

本文的核心判断是：Palantir在大模型时代的增长，不是因为接入大模型后突然获得了新的底层能力，而是因为大模型补齐了原有数据融合系统的认知交互层，使一套长期由专家和FDE操作的复杂系统获得了更低门槛、更高频率的使用方式。

01 

引言：一个被误读的公司

Palantir长期被两种叙事所误读。一种是把它称为"神秘大数据公司"的媒体叙事，强调反恐、情报和监控；另一种是"昂贵咨询公司"的华尔街叙事，它派驻FDE，采用项目制交付，无法规模化。

两种叙事都没有触到要害。Palantir真正的故事是架构演进：它用十多年建立了一个能够容纳现实世界残缺数据的数据融合层（Data Fusion Layer）。2023年大模型爆发后，又提供了一个可以用自然语言驱动这套底层能力的认知交互层（Cognitive Interaction Layer）。

本文沿着"早期数据融合层/后期认知交互层"这条主线展开：首先追溯这套架构放弃"完美数据"的思想来源；随后分析动态本体（Dynamic Ontology）和数据集群（Data Clusters）如何接纳、组织并使用混乱信号；接着解释早期Palantir为什么缺少认知交互层，以及AIP和大模型如何补上这一缺口；最后回到商业增长和竞争壁垒，说明为什么真正难以复制的不是某个专利概念，而是本体、执行、安全、组织和FDE的长期结合。

图1：Palantir架构演进

02 

思想谱系：放弃"完美数据"的理念从何而来

Palantir在反恐领域的早期工作，核心是放弃传统IT系统对"完美数据"的要求，转而建立一套能够处理残缺、模棱两可和高度混乱信息的底层架构。这一思路来自以下三类实践的共同影响。

2.1 人机共生：机器处理规模，人处理判断

作为PayPal联合创始人和前CTO，Max Levchin主导了PayPal早期反欺诈技术建设。当时团队面对的难题是：纯算法容易被攻击者摸清规律并绕过，纯人工审查又无法应对海量数据。解决方案是，让机器处理大规模、充满噪音的数据组合，把最终的模式识别、边界判断和决策留给人类。

这套人机共生思想并不等于"机器负责低级工作、人负责高级工作"，而是承认两者拥有不同优势：机器适合持续遍历和计算，人更擅长在不完整信息中判断异常、提出假设并承担后果。Palantir继承了这套思想，后来在情报和企业场景中放大的，正是这种分工。

2.2 从反欺诈到情报整合

9/11之后，Peter Thiel与Palantir早期团队将PayPal反欺诈中的数据整合经验带到国家安全领域：情报线索并非不存在，而是分散在不同机构、系统和数据源中，无法被及时连接。像追踪洗钱一样，把散落的数据点连接起来、绘制隐藏的关系网络，成为Palantir早期Gotham平台的愿景。

这一愿景隐含了一个与传统企业软件完全不同的判断：数据价值不只在于被准确记录，更在于不同对象、事件和行为之间的关系能否被发现、验证并转化为行动。

2.3 从架构思想到本体工程

Thiel提出了要解决的问题，工程师则需要解决如何实现。Nathan Gettings和Stephen Cohen等早期核心成员参与了Gotham及相关系统架构的构建。随后，动态本体专利的发明人团队将其工程化，把如何接纳残缺数据、如何在变化中保持业务语义这些核心问题，落实到对象、属性、解析器和验证器中。

因此，Palantir的早期架构并不是简单地把更多数据集中到一个数据库，而是重新定义了数据进入系统、被组织和被使用的方式：现实可以是不完整的，系统却必须保留足够稳定的业务关系和行动约束。

03 

数据融合层I：动态本体如何接纳混乱数据

动态本体专利（US7962495B2，2006年申请、2011年授权）解决的第一个问题是：当现实世界的输入持续变化、格式不统一且大量缺失时，系统如何继续接纳数据，而不被固定Schema（数据结构）限制。

简单说明下，以下专利用于说明Palantir早期技术思想和机制线索，包含动态本体和数据集群，不等同于当前Foundry、Gotham或Ontology产品的完整实现。

3.1 固定Schema的问题

传统关系型数据库通常在系统建设时固定Schema，任何结构变化都可能影响表、字段、应用和下游流程，往往需要数据库管理员介入。对财务记账、薪酬核算等规则明确的业务，这种刚性有助于保证一致性；但对情报分析、复杂调查和突发运营而言，现实中的对象和关系往往要在数据进入之后才逐渐显现。

如果系统要求输入数据先被清洗成统一标准，许多边缘线索会在进入系统之前被丢弃。问题不在于数据不够干净，而在于系统把现实中本来就存在的不确定性误当成了输入错误。

3.2 业务逻辑与物理存储解耦

动态本体的核心设计，是把业务语义和底层存储分开管理。用户可以通过Object Type（对象类型）编辑器和Property Type（属性类型）编辑器，定义、调整对象和属性，而不必每次都重构底层数据库。

人、车辆、事件等对象可以拥有各自的属性和关系；当业务问题变化时，分析师能够增加新的对象类型、属性类型或关系边，把新的判断框架加入现有数据体系。这使本体不再是一次性设计的数据库结构，而成为可以随实际调查和业务变化持续演进的语义层。

3.3 解析器与验证器：先接纳，再校验

动态本体并不是放弃结构约束，而是允许输入不整齐，同时在进入业务系统前保留必要的规则校验。

解析器（Parser）：通过正则表达式或代码模块，将格式不同、内容不完整的原始输入转换为可以挂载到本体属性上的结构化碎片。

多个解析器匹配：同一属性可以配置多个解析器，使坐标日志、短信中的地点、人工巡逻记录等不同句法的数据，能够映射到同一语义属性。

验证器（Validator）：在数据落库前施加格式、范围和固定值约束，拦截明显不符合业务规则的数据。

这种设计，把"数据一定要先变得整齐"这个硬规则，改成了更具弹性的规则，即系统先尽量接纳数据，再在语义和业务边界上进行校验。

3.4 从句法解耦到分析师建模

动态本体的意义不仅是多接入几种数据格式，更在于把部分建模权从数据库管理员和后台开发团队交给一线分析师，分析师可以根据调查过程中出现的新对象和新关系，调整本体、配置解析器，并观察数据如何重新组织。

这意味着分析师不必再把现实强行填入预先设计好的表格，也可以直接参与对象、属性和关系的定义。

3.5 示例：不完整线索如何形成关系网络

以反制简易爆炸装置（IED）为例，输入可能包括不规范的巡逻日志、破损账单、模糊车牌和口述线索。传统系统可能只保留可以标准化的字段，而动态本体允许分析师先定义制造者、资金转移、供应商等对象和关系，再把线索挂到相应对象上。

单条线索未必能证明什么，但当多个来源都指向相同地点、人物、账户或交易关系时，系统便可以沿着关系网络展开调查。关键不在于每个数据点都完美，而在于系统能否保留不完整信息，并在后续关联中提供更多线索。

04 

数据融合层II：数据集群如何让关联自动生长

动态本体解决如何把脏数据收进来，数据集群专利（US8788405B1，2014年授权）则进一步解决如何让关联自动显现出来。

4.1 从初始线索到集群

数据集群机制通常从一个初始线索（Seed）开始，例如一个可疑账户、电话号码或交易记录。系统根据预先定义的集群策略和数据绑定规则，从不同数据源中检索与初始线索有关的对象。

前一次搜索得到的结果可以成为下一次搜索的输入：账户指向所有者，所有者指向电话，电话指向通话对象，通话对象再指向其他账户。这样，集群不是一次性查询的结果，而是沿着规则不断扩展的关系网络。

当两个集群共享某个实体或属性时，Resolver（实体解析与合并机制）可以将其融合为更大的集群；Scoring Strategy（集群评分策略）则根据账户余额、交易频率、关系数量等聚合特征为集群评分，把最值得关注的网络优先交给分析师。

4.2 把调查过程固化为系统机制

数据集群机制对应了人类调查中的几种认知动作：

从一个线索出发，沿关系寻找下一层证据；

把多个局部事实放在一起，形成比单条记录更完整的事实链；

根据假设选择检索路径，再根据新结果修正假设；

通过实体匹配和集群融合，发现原本分散的事件可能属于同一网络。

这种机制与传统数据库有较大差别：数据库更擅长回答某个字段是什么；而数据集群试图回答以下更深一层的问题：这个对象还和什么有关，以及这些关系组合起来意味着什么。

05 

机制综合：从混乱信号到业务变量

现实中，有大量来自邮件、日志、传感器和人工记录、但信息不完整或格式不统一的输入，我们统称为"混乱信号"。动态本体负责接纳并挂载这些混乱信号的输入，而数据集群负责沿关系扩展。两者结合后，混乱信号不再只是被动存储，而会参与后续的搜索、融合、评分、推演和行动。

5.1 混乱信号的五种使用方式

第一，作为搜索跳板。一条残缺电话号码、模糊地点或不完整别名，一旦被挂载到某个对象上，就可以成为下一次全局关联搜索的输入，推动集群继续生长。

第二，作为实体融合的介质。不同数据源中的相似号码、别名、地点或设备特征，可以成为Resolver识别实体交叉的依据。多个弱信号的相互印证，有时比单个高置信度字段更有价值。

第三，作为风险评估的聚合特征。系统不必要求每个信号都绝对可靠，而是通过多个关系和属性的聚合，降低单点噪音的影响，把更值得关注的集群推送给分析师。

第四，作为影响业务约束的外部事件。一封关于港口罢工、供应商延迟或设备异常的非结构化信息，可以被挂载到货轮、供应商或设备对象上，并沿关系网络传导，观察它是否会冲击安全库存、产线吞吐量或交付承诺。

第五，作为人机协作的决策上下文。分析师不仅查看关系和结果，还可以回看原始证据、保留假设、比较不同分支，并在必要时触发经过权限和规则校验的Action。

这一过程，我们概括为从"噪音"到"变量"：混乱信号可以是搜索的跳板、融合的引线、评分的因子、推演的扰动，也可以成为行动决策的上下文。

5.2 三类场景中的完整链路示例

在反恐情报场景中，不规范短信中的地点和号码可以被解析并挂载到嫌疑人对象上，再以残缺号码为初始线索，检索通信记录和关联人员。在金融反欺诈场景中，残缺设备特征可以与另一调查集群中的相似特征碰撞，触发集群融合和风险评分。在供应链场景中，供应商邮件中的暴雨、封路等信息可以成为风险事件，沿供应商、零部件、产线和客户订单的关系传播。

这些场景的共同机制是：解析器负责接纳不完整的输入，图谱和业务规则负责组织、筛选和约束这些输入，Action负责把分析结果转化为可控动作。

5.3 噪音如何被控制

接纳混乱数据必然带来噪音风险。系统需要避免所有节点因弱相关信号被连接在一起，导致图谱失去决策价值。

早期的抗噪机制包括三层：解析后的验证器负责拦截明显错误；真实信号通过多个关系相互印证，孤立噪音往往无法形成大集群；Scoring Strategy则降低由单一弱信号组成集群的优先级，避免占用专家注意力。

大模型接入后，进一步增加了语境理解，辅助识别隐喻、反讽和语义歧义，也可以建议切断关联过多、但缺乏排他性证据的节点。但大模型不应拥有无条件删除信号的权限，尤其涉及关键基础设施、核心账户或高风险行动时，低置信度和高潜在影响的组合应触发人工裁决，保留影子节点、分支沙盒和完整审计记录。

06 

应用版图：Palantir解决的是灰度决策问题

这套架构最初服务于反恐和情报，后来逐步延伸到企业场景，如供应链、金融和医疗等，但核心问题没有改变：如何在不完整信息和刚性业务约束之间形成判断，并将判断转化为受控行动。

企业运作可以大致分成两类业务场景。

一类是财务合规、标准化制造、薪酬考勤等刚性流程。SAP、Oracle等传统企业系统已经在这些领域形成成熟的规则、字段和审批流程。这些系统要求现实服从规则，优势是稳定、可审计和可重复。

另一类是供应链突发、战略资源调度、复杂制造异常、情报分析和跨部门运营决策等场景，其共同特征是：信息来自多个系统和组织，输入往往不是标准字段，影响会沿着复杂关系传播，最终还需要有人决定是否采取行动。我们把这种需要在不完整信息下权衡方案、并由人决定是否行动的场景，称为"灰度决策"。

表1：传统系统与本体引擎的能力对比

Palantir的价值不是替代所有刚性系统，而是把外部变化挂载到刚性业务骨架上。这里的刚性业务骨架，是指库存、产能、权限和流程等不能随意突破的约束。系统据此理解一个模糊的外部风险如何沿供应商、物料、产线和客户订单传播，并在安全边界内提出或执行应对动作。

因此，Palantir真正进入的是企业最有价值、也最难标准化的部分：不确定信息与确定性约束发生摩擦的地方。只处理刚性流程的系统擅长核算和执行；能够接纳灰度信息、完成推演并支持行动的系统，才开始具备运营层面的智能。

07 

认知交互层：早期Palantir缺少什么

动态本体解决了数据和结构问题，但并没有解决如何交互的问题。早期系统仍依赖专业人员通过图形用户界面（GUI）、正则表达式和代码模块配置对象、属性和解析逻辑。

现实中的情报分析和企业决策工作却充满假设、怀疑和直觉。分析师可能会说，我怀疑这两个名字是同一个人，或者，把这个只进不出的账户作为一个新的调查对象，但早期系统无法直接理解这种自然语言表达，用户必须把判断翻译成对象定义、查询条件和图谱操作。

Palantir曾用图谱画布和工作空间弥补这一缺口：

假设节点：允许分析师创建数据库中尚不存在的虚拟对象，并把真实数据与其关联；

分析状态追踪：保存分析师隐藏、放大和排列数据的过程，使推理过程可以共享和复盘；

沙盒与分支：允许分析师在不污染主数据的情况下，围绕弱线索建立假设并进行推演。

这些设计说明Palantir很早就意识到，企业系统不仅需要记录客观事实，还需要承载人的推理状态。但在大模型普及之前，用户仍需要学习较重的图谱和配置工具，对人的要求很高，认知交互层因此存在明显门槛。

08 

AIP与大模型：认知交互层的补全

8.1 大模型成为更通用的语义解析器

大模型的出现，使系统不必再依靠人工编写大量规则来穷举信息表达差异。无论输入来自手写便签、邮件、巡逻黑话还是业务人员的自然语言，大模型都可以先完成语义理解，再将结果映射为目标本体中的对象、属性、关系或查询条件。

这种用自然语言的交互方式，使用户不必先学习底层配置语言，而是直接描述希望查找、比较或推演的业务问题，大模型再把意图翻译为系统可以执行的结构化操作，大大降低了对人的要求和交互成本。

8.2 大模型不能替代本体引擎

大模型降低了交互门槛，但不能替代本体、关系和执行系统，理由如下：

概率不能替代确定性：大模型不能凭语言概率判断某个账户是否真实发生过一笔交易，必须调用底层数据绑定和查询能力。

语言理解不能替代业务语义：模型可以理解词语之间的关联，但并不天然拥有企业业务中时间、权限、责任和物理约束的真实含义。

自然语言不能替代受控写入：当模型提出切换供应商、调拨物料或改变生产计划的建议时，必须由本体、权限和审批机制判断对应的Action是否允许。

生成能力不能替代精确聚合和实体对齐：大规模财务求和、关系遍历和实体消歧，仍需要确定性计算与Resolver。

因此，大模型更适合被理解为柔性的认知和交互入口，而不是企业运行的最终底座。

8.3 AIP如何改变Palantir的使用方式

在AIP出现以前，Palantir的复杂能力主要由专业用户和FDE推动。前线指挥官或企业高管提出的自然语言问题，需要被翻译成图谱操作、查询路径和业务规则，使用门槛高、部署周期长。

AIP将大模型接入本体和Action机制后，业务人员可以直接提出类似以下问题：如果切断供应商A的合作，下季度欧洲区的交付违约风险是多少？有哪些替代方案？系统的关键不是生成一段听起来合理的回答，而是把问题转化为可追溯的数据查询、关系推演和受控的Action建议。

这解释了Palantir在2023年之后的结构性变化：底层本体和数据融合能力不但没有被大模型替代，恰恰相反，原本沉淀在平台和FDE经验中的能力，开始通过更自然的交互方式被更多用户调用。

8.4 经营数据：架构补全的商业表现

Palantir自2023财年开始的连续三年财务数据和经营指标，可以作为观察产品与交互变化的经营背景：

表2：Palantir2023-2025财年主要财务与经营指标

这些数据不能单独证明大模型导致增长，但与产品和交互变化结合起来，可以支持一个谨慎但合理的判断：AIP降低了复杂平台的调用门槛，使Palantir原有的本体、数据和FDE能力具有更强的软件杠杆。

表3：Palantir2023-2025财年员工与营收对比

2023—2025年，Palantir营收和员工规模均在增长，但营收增速高于员工增速，人均营收因此有所提升。这支持平台复用和软件杠杆增强的判断，但仅凭员工与营收数据，不能单独证明增长完全来自AIP或大模型。

09 

复制困境：为什么Palantir难以复制

动态本体和数据集群的基本概念并非不可理解，而真正难以复制的是，这套技术如何长期嵌入复杂业务，并承担从数据到行动的责任。

9.1 架构壁垒：从记录系统到业务关系网络

传统ERP、CRM和数据湖通常分别记录物料、客户、交易和日志，Palantir则试图把人、机器、组织、事件和外部扰动都纳入同一个具有属性和关系的对象网络中。

它不要求所有输入先被清洗成完美数据，而是把解析层和刚性业务骨架分开：供应商邮件、设备异常和天气预警可以作为动态信号，挂载到相应对象上；产线吞吐量、安全库存和审批权限，则构成不能随意突破的刚性约束。

核心变化不只是把数据湖替换为图数据库，而是改变系统对业务对象、关系和行动的基本理解。对于已经围绕"数据先清洗再入库"建立产品体系和工程文化的公司，这种转向不仅仅只是增加一个模块，而是架构上的变化。

9.2 Write-back写回壁垒：从只读分析走向受控执行Action

把不完整数据连成图谱、做成可视化仪表盘相对容易；真正困难的是系统能否在本体层生成一个Action，并经过权限、规则、审批和影响分析后，安全写回ERP或其他业务系统。

例如，当系统识别到供应商延迟可能导致产线停产时，它不能只显示风险，还需要比较调拨物料、切换供应商、降低产线速度等Action所产生的影响，尤其是对其他订单、库存和财务约束。Action执行之后，还需要记录一系列问题：谁提出、谁批准、依据什么证据、产生了什么结果。

只读图谱和可写本体之间，隔着细粒度权限、实体溯源、业务规则和责任审计。没有这条闭环，平台就仍然是分析工具，而不是能够参与运营的业务系统。

9.3 安全与责任壁垒

当AI只生成一份报告时，错误可能表现为认知误导，不会有太大负面影响；当AI通过系统写入一条生产指令、调拨命令或账户操作时，错误会直接变成现实中的业务或财务后果。

因此，企业级AI需要解决的不只是模型准确率，还包括：谁能看到什么、谁能执行什么、哪些动作必须审批、如何回看证据、如何撤销或补偿，以及出现损失时谁承担责任。Palantir的本体、权限和Action框架之所以重要，正是因为它们把业务责任转化为系统中的对象、规则和审计记录。

9.4 FDE壁垒：从翻译需求到校准本体

FDE不是传统意义上的软件配置和实施顾问，而是进入客户真实业务现场，用代码、业务判断和产品能力共同调整本体的人。FDE需要理解客户的对象、关系、权限、例外和组织约束，再把这些经验反馈到产品和平台中。

这种模式长期以来成本很高，也不符合标准化SaaS追求低边际成本的商业逻辑，但正是这种持续进入真实业务摩擦的过程，使Palantir获得了对复杂场景的建模经验和能力。

大模型会减少FDE的部分翻译工作，却不会自动消除业务校准和责任判断。随着Agent可以生成更多配置，FDE更可能逐渐从原来把客户问题翻译成图谱操作，转向更高阶的"审计和裁决Agent对本体的修改"。这一角色，我们称为"本体校准者"，指负责检查本体修改是否符合客户业务、权限和责任边界的人。

9.5 壁垒来自组合，而非单点技术

真正难以复制的不是某一项技术，而是动态本体、多源数据融合、拓扑推演、细粒度权限、Action与Write-back、FDE现场校准，以及组织责任与业务流程的组合。

以上组合中，单独拥有其中任何一项，都不足以形成Palantir式的企业AI闭环。

10 

收束讨论：双层架构留下的三个问题

10.1 大模型会不会替代本体？

两者分工不同。大模型能够理解自然语言、生成结构和提出候选路径；本体负责定义业务对象、关系和约束；底层数据系统负责确定性查询；权限和Action负责把建议限制在可执行范围内。本体和大模型的分工，说明了柔性认知必须建立在刚性业务结构之上。

10.2 FDE会不会被Agent替代？

FDE的翻译职能会被部分自动化：大模型可以根据样本生成解析规则、查询路径和初步本体配置。但客户业务中的隐性约束、组织政治、责任边界和例外处理，仍需要人来判断。FDE的工作重点会从操作配置，转向本体校准、异常判断和业务落地。

10.3 谁为Write-back后的行动负责？

企业AI的最终难点在于，能否把建议变成可控、可审计、可追责的行动。机器可以处理规模、遍历关系和提出方案，但人仍然需要对高风险Action进行授权，并承担决策后果。自动化越深入，系统越需要明确保留人工裁决、分支推演和责任留痕。

11 

结论：从数据融合到认知交互

11.1 Palantir的三层核心能力

Palantir的能力可以从三个层面理解。

第一，认知哲学：接纳现实的混沌与残缺。Palantir没有要求所有信息先被清洗成规整表格，而是用动态本体、解析器和验证器，让现实碎片进入一个仍然可控的业务结构。

第二，计算架构：从孤立报表到拓扑推演。以初始线索为起点自动生长关联集群，通过实体融合和Scoring Strategy形成上下文，再让外部柔性信号与内部刚性业务约束发生碰撞。

第三，系统定位：人机共生与双向写入。机器承担大规模遍历、计算和语义解析，人类提供假设、常识、边界判断和最终授权；系统不止展示结果，还要在安全校验后把获批Action写回真实业务系统。

11.2 一条清晰的演进路径

Palantir的二十年可以被概括为一条架构弧线：

Levchin的人机共生和Thiel的情报整合愿景，形成了接纳混乱数据的思想起点；

动态本体以句法解耦接纳残缺数据，数据集群以策略化生长发现关系；

图谱画布、假设节点和沙盒分支，早期承担了认知交互功能；

2023年之后，LLM以自然语言补齐交互层，降低了复杂平台的使用门槛；

本体的确定性与LLM的概率性结合，使数据融合、认知判断和业务执行能够形成连续链路；

Write-back、安全、FDE和组织责任，则决定了这条链路能否真正进入生产级业务。

因此，Palantir的护城河从来不是某一项算法或产品组件，而是一种架构哲学：承认世界的本质是混乱和残缺的，不去逼迫现实服从表格，而是建立一张足够柔性且足够强韧的业务网络，把现实碎片接住，再让智能在网络中形成判断并受到约束地行动。

11.3 对企业AI的双向启示

只有大模型没有本体，企业AI很难稳定进入真实业务；只有本体没有认知交互层，系统又只能服务少数专家。前者缺少确定性、权限和责任，后者缺少自然交互和规模化使用方式。

Palantir的案例说明，企业AI真正需要的，不是更聪明的模型与更大的数据简单相加，而是让柔性认知建立在刚性业务结构之上，并把最终行动纳入权限、审计和责任体系。

写作说明：本文根据由中科创达联合创始人兼CTO邹鹏程主导的一段关于Palantir技术哲学的长对话整理、提纯、重构而成；对话中的问答线索被保留为论证骨架，并经学术化改写、结构性重排与公开数据核实补强。

同时因篇幅原因删减了原对话中的十章"侧翼与颠覆者：谁能接近Palantir"，并简化了第十一章"讨论：十二个开放问题"。文中公开资料截止2026年9月，财务表格数据截止2025财年。

近期厂商征集

AI数据基础设施研究项目征集

点击申报

截至时间：10月31日

本体市场研究项目征集

点击申报

截至时间：10月31日