企业分析基础设施上一次被重新定义，还是云数据仓库把“跑查询”从硬件采购问题变成软件订阅问题。Snowflake 和 Databricks 由此切走了甲骨文和 Teradata 的增量市场，也让“存算分离”“湖仓一体”成为行业口头禅。但这两家公司如今面对的是一个他们并未设计过的场景：AI 代理不再像人类分析师那样按需查询，而是以机器速度持续、不可预测地发起分析请求。一个代理在几分钟内可能触发数百次查询，每一次都在等待基础设施返回结果。当查询延迟从秒级变成代理决策链上的乘法因子，当计算消耗的增长速度超过代理创造的价值，企业 AI 的账就算不过来了。
OliverAI 的创始团队把这个矛盾作为切入点。公司称其产品 OliverDB 是一个专为代理式 AI 设计的高性能分析数据平台，核心主张是让 AI 代理以远低于现有系统的计算消耗实时探查企业数据。Menlo Ventures 和 Unusual Ventures 决定押注这个方向。OliverAI 今日宣布获得这两家机构的 pre-seed 融资，用于扩展 OliverDB。具体金额未披露。
这笔融资的特别之处不在于规模，而在于它发生在一个已经被 Snowflake、Databricks 和 ClickHouse 定义过的市场里。一家成立时间未披露、网站未披露的旧金山公司，声称在 ClickBench 基准测试中跑出了比 ClickHouse 快数百倍到数千倍的成绩，这要么是分析引擎层的一次真突破，要么是又一个在基准测试上做文章的创业故事。答案取决于一个更根本的问题：代理式 AI 的工作负载，是否真的需要一种新的数据基础设施，而不是在现有系统上加一层缓存或路由。
| 字段 | 内容 |
|---|---|
| 公司 | OliverAI |
| 轮次 | Pre-seed（新闻稿口径）；分类标记为种子轮 |
| 金额 | 未披露 |
| 投资方 | Menlo Ventures、Unusual Ventures |
| 总部 | 旧金山 |
| 创始人 | Praneet Sharma、Grace Johnson、Toby O’Brien |
| 官网 | https://oliverdb.ai/ |
ClickBench 上的“数百倍”声明，目前只有内部测试背书
OliverAI 最引人注目的主张来自一组基准测试数字。据公司披露，在使用 ClickBench 查询形态的测试中，Oliver 在 CPU 上比 ClickHouse 快数百倍，在 GPU 执行时快数千倍。ClickBench 是 ClickHouse 开发的开源分析数据库基准测试，在分析型数据库领域有一定公信力，但任何基准测试都天然存在“按考题优化”的空间。OliverAI 在新闻稿脚注中明确标注，这些结果基于内部测试，使用 ClickBench 分析工作负载对 ClickHouse 24.8 进行对比，结果因工作负载和配置而异，且未经独立审计。
这意味着“数百倍”和“数千倍”目前是公司口径，而非第三方验证事实。在数据库行业，性能声明从内部测试走向可信结论，通常需要经过独立审计、客户生产环境复现、以及竞品厂商的回应。ClickHouse 本身以单节点高性能著称，在 ClickBench 上长期占据头部位置。一家新公司声称在 ClickHouse 自己开发的基准上以数量级优势击败 ClickHouse，这要么指向一种完全不同的执行架构，要么指向测试配置中的某些不对称。OliverAI 尚未公开完整的测试方法论、硬件配置、数据规模和查询集细节，新闻稿中提到的“View the complete methodology, configurations, and results”链接在公开文本中不可见。从已披露的信息看，唯一可以确认的是：OliverAI 在 ClickBench 查询形态上做了内部对比测试，并得出了有利于自己的结论。结论的边界到此为止。
分析引擎之外，OliverDB 把治理和模型群打包进同一个产品
OliverDB 的产品设计逻辑与 ClickHouse 或 Snowflake 有一个根本差异：它不只是回答查询，而是试图管理“谁在问、问什么、答案怎么来”。据公司披露，OliverDB 提供跨企业数据库和 Model Context Protocol（MCP）服务器的代理可观测性与治理能力。企业可以为每个代理定义策略，限制其可访问的数据和可执行的动作，并维护每一次交互的可归因记录。
这个设计针对的是代理式 AI 落地时最现实的恐惧：一个能自主调用数据系统的代理，如果权限边界模糊，就是一个内部威胁。传统数据库的权限模型假设用户是自然人，按角色授权；代理的调用模式是高频、组合式、跨系统的，静态角色模型很难覆盖。OliverAI 把治理从数据库层上移到代理层，让策略跟随代理身份而非数据库账号。这个思路在逻辑上成立，但它的验证路径不在基准测试里，而在企业安全团队是否愿意把代理权限管理交给一家新公司的产品。从已披露信息看，OliverAI 尚未公布任何企业客户名称或治理功能的独立安全评估。
另一个差异化组件是“模型群”（model swarm）。据公司披露，Oliver 并行运行多个较小的专用模型来测试竞争性假设、检查替代解释，并由一个“导体模型”（conductor model）对结果加权，返回数据最支持的结论，或者在数据不足时返回“无结论”。这个架构的目标是降低对昂贵前沿模型的依赖，同时提高输出的可靠性。从技术逻辑看，这是一种用并行推理换取单次推理质量的策略，类似于让多个弱模型互相校验。但它的成本结构取决于小模型的调用总量：如果每个查询都要触发多个小模型并行运行，计算消耗是否真的低于调用一次大模型，取决于小模型的具体规模和并行度。OliverAI 尚未披露模型群的具体模型类型、参数规模、并行数量或 token 消耗数据，因此“更少 token 获得更好输出”目前是产品设计主张，而非可核算的成本结论。
Menlo 和 Unusual 押注的是“代理原生基础设施”这个品类，而非一家公司的基准测试
Menlo Ventures 合伙人 Tim Tully 在声明中把 Oliver 放在 Snowflake 和 Databricks 的历史延长线上：“Snowflake 和 Databricks 帮助定义了云时代数据基础设施的新品类。代理式 AI 代表另一次根本性转变。”Unusual Ventures 创始人 John Vrionis 则把重点放在企业信任上：“挑战在于让 AI 系统有意义地访问有价值的企业数据，而不牺牲控制、可靠性或信任。”
这两段话的措辞值得拆解。Tully 说的是品类逻辑：如果代理式 AI 真的创造了新的数据基础设施需求，那么早期投资一家“代理原生”的分析平台，赌的是品类成立，而非某个具体产品的胜出。Vrionis 说的是采购逻辑：企业 AI 的瓶颈从模型能力转向数据访问的治理与信任，这恰好是 OliverDB 试图占据的位置。但两位投资人的判断都建立在同一个未经验证的前提上：代理式 AI 的分析工作负载确实需要新的基础设施层，而不是在 Snowflake 或 Databricks 上增加代理适配功能。Snowflake 和 Databricks 都在快速发布 AI 相关功能，ClickHouse 也在持续优化其分析引擎。如果现有厂商能在 12 到 18 个月内把代理工作负载的延迟和成本降到企业可接受的范围，OliverAI 的窗口期会很短。
从资本结构看，这是一笔 pre-seed 轮融资，金额未披露。Menlo Ventures 和 Unusual Ventures 都是硅谷活跃的早期机构，但 pre-seed 轮的金额通常不足以支撑大规模企业销售和长期研发。OliverAI 需要在这笔钱花完之前证明两件事：一是基准测试结果能在客户生产环境中复现，二是企业愿意为“代理原生”的分析平台切换基础设施。这两件事的验证周期都不短。
把“机器速度的分析工作负载”放进真实产业链，问题比基准测试复杂得多
OliverAI 的核心叙事是：AI 代理产生的工作负载与人类分析师有本质区别——持续、不可预测、机器速度。这个判断本身有事实基础。代理式 AI 的典型工作模式是“感知-推理-行动”循环，每一步推理都可能触发数据查询。一个执行多步任务的代理，查询频率远超人类分析师。如果查询延迟是 200 毫秒，一个需要 50 次查询的代理任务仅等待时间就是 10 秒；如果延迟降到 20 毫秒，等待时间压缩到 1 秒。这种差异在代理工作流中会被放大，因为每一步的延迟都会影响下一步的启动。
但“代理需要更快查询”不等于“代理需要新的分析引擎”。企业可以在现有 ClickHouse 或 Snowflake 上增加缓存层、物化视图或专用连接池来降低延迟。ClickHouse 本身就以亚秒级查询见长，Snowflake 也在推出针对短查询的优化。OliverAI 要说服企业替换或新增一个分析平台，需要证明的不只是“更快”，而是“快到一个量级差异改变了代理的可行性”。从已披露信息看，OliverAI 的基准测试针对的是 ClickBench 查询形态，而非真实企业代理工作负载。ClickBench 的查询集来自 ClickHouse 的公开分析场景，与代理式 AI 的实际查询模式——高并发、短查询、多轮依赖、混合结构化与非结构化数据——可能存在显著差异。OliverAI 尚未披露任何客户在其自身代理工作负载上的对比测试结果。
部署模式是 OliverAI 试图降低企业采用门槛的一个务实选择。据公司披露，OliverDB 可以以托管服务形式提供，也可以部署在客户 VPC 内部。后者对于数据敏感型企业尤其重要，因为代理式 AI 的查询往往涉及核心业务数据，企业不太可能把数据导出到第三方托管环境。但 VPC 内部署也意味着 OliverAI 需要承担更高的交付和支持成本，且难以通过统一托管实现规模经济。对于一家 pre-seed 公司来说，同时支持两种部署模式的运营压力不容忽视。
竞争格局：ClickHouse 是直接对手，Snowflake 和 Databricks 是品类对手
OliverAI 的竞争面可以分成两层。直接对手是 ClickHouse。ClickHouse 是开源分析数据库的事实标准之一，在 ClickBench 上长期占据头部位置，拥有庞大的开源社区和商业客户群。OliverAI 选择在 ClickBench 上对标 ClickHouse，等于在对手的主场发起挑战。如果 OliverAI 的基准测试结果最终获得独立验证，ClickHouse 在代理式 AI 场景下的性能优势将被直接动摇；如果结果无法复现，OliverAI 的可信度会遭受重创。这是一种高风险、高回报的竞争策略。
品类对手是 Snowflake 和 Databricks。这两家公司的优势不在单查询性能，而在企业数据平台的完整生态：数据治理、权限管理、BI 集成、ML 工具链、市场生态。OliverAI 的治理功能试图切入这个领域，但它面对的是 Snowflake Horizon 和 Databricks Unity Catalog 这类已经深度集成到企业数据栈的产品。一家 pre-seed 公司要在治理层面与这些平台竞争，需要找到对方没有覆盖的空白地带。OliverAI 的答案是“代理级治理”——以代理身份而非用户身份为中心的策略管理。这个定位在概念上有差异化，但 Snowflake 和 Databricks 完全可以在现有治理框架上增加代理身份抽象。OliverAI 的窗口在于：现有平台的治理模型是为人设计的，改造为代理原生需要时间，而 OliverAI 从第一天就按代理原生构建。
从已披露信息看，OliverAI 尚未公布任何客户案例、付费客户数量、或与 ClickHouse/Snowflake/Databricks 的客户重叠情况。这意味着竞争格局的分析目前只能停留在产品定位层面，无法判断 OliverAI 在实际企业采购中处于什么位置。
资金用途与待验证假设：这笔钱要买的是时间，还是证据？
OliverAI 表示将把这笔 pre-seed 融资用于扩展 OliverDB。具体资金分配未披露。对于一家产品已经“可用”的公司来说，pre-seed 资金通常流向三个方向：工程团队扩充、早期客户获取、以及基准测试的独立验证。OliverAI 最紧迫的需求可能是第三个。如果“数百倍到数千倍”的性能声明无法获得独立验证，后续的企业销售几乎无法推进。企业采购分析数据库时，性能声明只是入场券，客户会在自己的数据和工作负载上做 POC。OliverAI 新闻稿中邀请企业“用自己的数据和工作负载测试平台”，说明公司清楚这一点。但 POC 周期通常以月计，pre-seed 资金能支撑的 POC 数量有限。
OliverAI 面临的核心待验证假设有三个。第一，代理式 AI 的分析工作负载是否真的需要新的执行引擎，而不是现有系统的优化。第二，OliverDB 在 ClickBench 上的性能优势能否在真实企业代理工作负载中复现。第三，企业是否愿意为“代理原生”的治理能力切换或新增分析平台。这三个假设中，第一个是品类风险，第二个是产品风险，第三个是商业风险。三者叠加，意味着 OliverAI 的验证路径比一般的企业软件创业公司更长。
从已披露的融资结构看，Menlo Ventures 和 Unusual Ventures 的参与提供了品牌背书，但 pre-seed 轮通常不包含对赌性条款或严格的里程碑约束。这意味着 OliverAI 有一定的时间窗口来验证上述假设，但这个窗口不是无限的。如果 12 个月内没有可公开的客户验证结果，下一轮融资的叙事基础将仍然停留在“内部测试显示”的层面。
一个值得注意的信号：新闻稿说了“pre-seed”，分类却标记为“种子轮”
在 OliverAI 的公开信息中，有一个容易被忽略的细节：新闻稿正文明确使用“pre-seed funding”来描述本轮融资，但外部分类中将其标记为“种子轮”。这种不一致可能源于不同数据库对轮次定义的差异，也可能反映了 OliverAI 在对外沟通中的策略选择。Pre-seed 通常意味着公司处于产品早期验证阶段，种子轮则暗示产品已经有了一定的市场牵引力。对于一家声称产品“可用”且性能远超现有系统的公司来说，“pre-seed”的标签与“企业级平台”的定位之间存在张力。
这个细节本身不构成对 OliverAI 的负面判断，但它提示读者在解读公司叙事时需要保持警惕。一家公司同时使用“pre-seed”和“企业级平台”来描述自己，要么是在融资叙事上保持谦逊，要么是在产品叙事上保持激进。两者之间的落差，恰好是 OliverAI 当前所处阶段的真实写照：技术主张远超融资阶段，验证进度落后于产品叙事。
验证边界与可复核指标
本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。
- 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
- 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
- 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。
RecodeX 极客视：OliverAI 的故事之所以值得关注，不是因为它声称比 ClickHouse 快几百倍——数据库行业的性能军备竞赛从未停止，内部基准测试的数字也从来不是终点。真正值得追踪的是它把“代理原生”作为基础设施设计的第一原则，而不是在为人设计的系统上打补丁。如果代理式 AI 的工作负载确实如 OliverAI 所描述的那样——持续、不可预测、机器速度——那么现有分析基础设施的架构假设就需要被重新审视。但“如果”这个词承载了太多未验证的前提。OliverAI 的下一步不是发布更多基准测试数字，而是让一家愿意公开名字的企业客户，在自己的生产环境里跑出可复现的结果。在那之前，这个故事仍然是一个值得观察的假设，而非一个已经成立的品类。
信息来源
本文在采集与核验阶段引用了以下公开来源，按站点去重列出；来源内容归原发布方所有，其口径不代表 RecodeX 的核实结论。