Databricks 融资 50 亿美元：企业 AI 真正值钱的，是那条数据管道

Databricks 完成了 50 亿美元 Series M 融资，估值来到 1900 亿美元。

这轮融资最扎眼的，不是估值，而是认购情况：原计划融资 10 亿美元，投资人给出了 150 亿美元的认购意向，实际募资 50 亿美元。换句话说，想上车的钱，足足是计划规模的 15 倍。

市场为什么这么激动？

因为 Databricks 已经不只是一个“跑数据仓库”的工具。它在押注一件企业最缺、也最难做好的事：把散落的数据、权限、模型和业务流程，接成真正能做事的 AI Agent。

年化收入达到 69 亿美元，同比增长 80%；其中 17 亿美元来自 AI 产品线。这个比例很说明问题：企业花钱买的，不再只是算力和报表，而是能落到业务里的 AI 工作流。

这笔融资背后，藏着企业 AI 的一个现实

很多团队做 AI，开局都很热闹。

买了大模型 API。搭了个聊天机器人。做了一页炫酷的“智能问答”界面。演示时效果不错，真要交给销售、运营、财务去用，问题一股脑冒出来：

回答引用的是哪个版本的数据？
客户能不能看到不该看的订单？
模型胡说八道，谁来兜底？
一份数据要同步到几个向量库？
Prompt 改了，结果变差了，怎么回滚？
每个月的模型账单，到底是谁烧出来的？

折腾一圈，大家会撞上一堵墙：模型很好接，企业数据很难接。

真正卡住企业 AI 的，往往不是“选 GPT 还是选开源模型”，而是下面这堆脏活累活：

数据分散在数仓、CRM、ERP、客服系统和 Excel 里。
同一位客户，在不同系统里名字都可能不一样。
权限体系乱成毛线团，AI 一接入就有泄露风险。
数据更新很快，昨天建的知识库，今天就过期。
Agent 要执行动作，比如退款、创建工单、改库存，不能只会聊天。

Databricks 的路线很直白：别让企业把数据搬来搬去，也别让每个 AI 项目从零造一套管道。直接在统一数据平台上，让 Agent 读取数据、调用工具、执行任务。

这才是它被资本追捧的核心原因。

把 Databricks 的 AI 拼图拆开看

从公开提到的产品线看，Databricks 正在补齐企业 AI 的关键位置。

1. AI Gateway：给模型调用装上“总闸门”

团队一旦开始大规模调用模型，常见画风会迅速失控。

有人用 OpenAI，有人用 Anthropic，有人连了本地模型；密钥散在代码、Notion、聊天记录里；出了高额账单，没人知道哪段程序干的。

AI Gateway 干的事情，可以把它理解成模型调用层的统一入口。

它该解决的核心问题包括：

统一管理不同模型供应商
管理 API Key，避免密钥满天飞
记录调用日志，方便排查问题
控制访问权限
设置限流和预算
对敏感内容做拦截或脱敏
在多个模型之间切换和路由

一个很实用的场景

假设你们在做客服 Agent。

普通问题，用成本较低的模型回答。
涉及退款、合同、投诉，用效果更稳的模型。
遇到身份证号、银行卡号，进模型前自动打码。
单个用户一分钟问 100 次，直接限流。

没有统一网关时，这些规则很容易散落在十几个服务里。几个月后，谁也不敢动。装一个统一“总闸门”，事情会清爽很多。

模型网关不是锦上添花。只要你们有两个以上 AI 应用，它就该进入架构清单。

2. Genie Agent：让业务人员直接用自然语言问数据

数据团队最熟悉的一幕，大概是这样的：

“帮我拉一下华东区上个月新客户的复购情况。”

这个需求通常要经过好几站：业务提单 → 数据同学理解口径 → 写 SQL → 校验 → 导出表格 → 再解释一遍指标。

Genie Agent 这类产品瞄准的，就是把这条链路缩短。

业务人员直接提问：

“华东区 6 月新客在 30 天内复购的比例，和 5 月比怎么样？按城市列出来。”

Agent 理想状态下会完成几件事：

理解业务术语，比如“新客”“复购”“华东区”。
找到对应的受管数据表。
生成并执行查询。
给出结果、图表和可追溯的数据来源。
遇到模糊口径时，主动追问，而不是硬编。

听起来很美，落地时最关键的不是模型能力，而是指标定义。

“复购”到底是第二次支付成功？还是第二次下单？退款订单算不算？跨店订单算不算？这些问题没定义清楚，Agent 写出再漂亮的 SQL 也没用。

给数据团队的建议

在开放自然语言问数前，先整理一份业务语义表：

| 业务词 | 推荐定义 | 数据来源 | 负责人 | | --- | --- | --- | --- | | 新客 | 历史无支付订单、当前周期首次支付的用户 | orders | 增长团队 | | 复购 | 首次支付后 30 天内再次支付成功 | orders | 增长团队 | | GMV | 已支付订单金额，不扣除退款 | payments | 财务团队 |

别嫌这一步土。没有这张表，AI 问数很容易变成“用自然语言制造数据事故”。

3. Lakebase：让 Agent 有地方存“记忆”和任务状态

很多人做 Agent 时只盯着对话框，忽略了一个基本事实：Agent 不是一次性文本生成器。

它要做连续任务，就需要保存状态。

比如一个销售线索 Agent：

上午识别到客户有购买意向。
中午查到客户过去有三次试用记录。
下午创建跟进任务，分配给对应销售。
第二天检查销售是否联系。
三天后根据结果决定是否继续提醒。

这类流程离不开数据库。它需要记录：

用户是谁
任务进行到哪一步
调用了什么工具
产生了什么结果
哪次操作失败了
哪些信息需要长期保留

Lakebase 指向的是 Agent 应用所需的数据库与状态管理能力。这个方向非常现实：企业不会满足于一个“会回答问题”的机器人，他们要的是能接流程、能留痕、能处理异常的数字员工。

Databricks 的真正打法：数据、治理、Agent 放在一张桌子上

企业 AI 项目最怕“拼装怪”。

数据在 A 平台，向量库在 B 平台，模型服务在 C 平台，权限在 D 系统，监控又在 E 系统。每接一个组件，集成成本就多一层。出了问题，五个厂商互相看一眼，场面很安静。

Databricks 想卖的，是一个相对完整的工作台：

业务数据 / 文档 / 日志
        ↓
数据清洗、表管理、权限治理
        ↓
特征、检索、语义层、向量检索
        ↓
模型调用与 AI Gateway
        ↓
Agent 推理、工具调用、任务状态
        ↓
业务系统：客服、销售、运营、财务

这套思路有一个很硬的价值：数据权限可以跟着数据走。

举个例子。

区域销售经理只应看到自己负责区域的客户数据。传统做法里，你可能要给 BI、知识库、Agent、CRM 导出表分别配一次权限。漏配一次，敏感数据就可能飞出去。

如果数据平台、治理和 AI 应用共享统一的权限体系，Agent 查询数据时也会自动继承用户权限。销售经理问“我的待跟进客户”，看到的是自己的客户；全国负责人问同一个问题，看到的是全量数据。

这种能力不酷，却非常值钱。企业采购时，安全部门往往比业务部门更有一票否决权。

你们要做企业 Agent，可以照着这条路线走

不需要一上来就建“全自动公司”。那种 PPT 容易让人热血，落地时常常让人血压升高。

挑一个高频、规则明确、能量化结果的场景，跑通闭环更靠谱。

一套能执行的 30 天落地清单

第 1 周：把数据摸清楚

别急着写 Prompt，先盘点数据。

列出目标场景需要的表、文档和接口。
标记每份数据的负责人、更新频率和敏感等级。
找出同名不同义、同义不同名的字段。
选定一个可验证的数据切片，比如近 90 天订单。
明确哪些数据绝不能进入模型上下文。

建议直接建一张表：

| 数据资产 | 用途 | 更新频率 | 是否含敏感信息 | 负责人 | | --- | --- | --- | --- | --- | | 订单表 | 查询购买状态 | 实时 | 是 | 数据团队 | | 商品知识库 | 回答商品问题 | 每日 | 否 | 商品团队 | | 客服工单 | 判断问题类型 | 实时 | 是 | 客服团队 |

第 2 周：定义 Agent 的边界

给 Agent 写清楚“能做什么、不能做什么”。

例如客服 Agent：

可以查询订单状态。
可以生成回复草稿。
可以创建工单。
不可以直接退款。
不可以修改收货地址。
遇到投诉、法律、医疗、资金问题，必须转人工。

边界越具体，后面返工越少。

第 3 周：接入工具，跑通一个闭环

Agent 不需要一开始接 20 个工具。接 2 到 3 个就够了。

比如：

查询订单 → 检索退换货政策 → 生成回复 → 创建工单

每个工具调用都要记录：

调用人是谁
调用了什么参数
返回了什么结果
是否执行成功
是否触发人工审核

别把“日志以后再补”当成计划。出了问题，没有日志就是抓瞎。

第 4 周：用真实任务压测

准备至少 50 条真实样本，覆盖正常情况和刁钻情况。

例如客服场景，可以放进这些题：

“我的订单怎么还没发货？”
“我要退款，钱什么时候到账？”
“把这笔订单改到另一个地址。”
“给我看看其他客户的购买记录。”
“你们这个产品能治疗焦虑吗？”

测试时别只看回答像不像人。更该盯住：

有没有越权查数据
有没有编造订单状态
有没有把该转人工的问题硬答了
工具调用有没有误操作
同一个问题重复问，结果是否稳定

企业 Agent 最容易踩的 6 个坑

1. 只做聊天，不接业务动作

一个只能回答“建议您联系人工客服”的机器人，用户用两次就烦了。

让 Agent 至少能完成一个真实动作：查订单、建工单、更新标签、生成报表。动作要小，但必须落地。

2. 把所有文档一股脑塞进知识库

文档越多，不代表答案越准。

过期制度、重复 FAQ、无权限资料混进去，检索结果会越来越乱。知识库要有版本、来源、失效时间和访问权限。

3. 忽略指标口径

“销售额”“活跃用户”“转化率”这种词，十个团队能有十种算法。先把口径定死，再谈自然语言问数。

4. 给 Agent 太大权限

能查数据，不等于能改数据。

能生成退款建议，也不等于能直接打款。高风险动作至少要加一层人工确认，别把生产环境当游乐场。

5. 只看 Demo，不做评测集

Demo 永远挑最好看的案例。真实用户不会配合你演。

建立固定测试集，每次改模型、Prompt、检索策略或工具接口，都跑一遍。结果变差，立刻能发现。

6. 不算成本

Agent 会思考、会检索、会调用工具，账单也会思考。

给每个任务设成本上限。简单问题走轻量模型，复杂任务再用高能力模型。把长文本切片、缓存和重复查询优化好，月底看账单时能少喝两杯苦咖啡。

Databricks 还会继续融资，还是走向 IPO？

Series M 已经排到很后面的字母了，确实有点“融资轮次快不够用”的味道。

从这轮规模、1900 亿美元估值、69 亿美元年化收入和 80% 增长速度看，Databricks 具备了冲击 IPO 的基本叙事：收入规模够大，AI 增长够快，企业客户的需求也够硬。

至于会不会立刻上市，外部人没法替公司拍板。它手里刚拿到 50 亿美元，现金很充足，没必要为了“赶上市”而上市。

更值得普通团队关注的，不是它哪天敲钟，而是它已经把一个信号摆得很明白：

企业 AI 的下一轮竞争，不是谁的聊天框更花哨，而是谁能让 Agent 在可信数据上安全做事。

如果你正在规划 AI 项目，少花点时间争论“哪个模型最强”，多花点时间把数据、权限、工具调用和评测体系搭起来。

这部分听着没那么性感，却决定了你的 Agent 是演示玩具，还是能让团队每天早下班一小时的生产力工具。

Databricks 融资 50 亿美元：企业 AI 正在从“买模型”转向“把数据接进 Agent”