最贵的 AI 公司，卖的不是 AI

Cursor 成立三年，今年 2 月 ARR 突破 $2B。这是 B2B 史上最快的速度。

如果你去问：他们的核心技术是什么？工程师可能会说：一个更好的代码编辑器，里面集成了 AI。但这个答案掩盖了一个更有趣的事实——Cursor 本身并不造 AI 模型。它调用 OpenAI、Anthropic、Google 的 API，然后在 API 之上构建了一套精密的系统，专门处理一件事：把你的私有代码库，变成 AI 能够理解和引用的上下文。

这套系统叫做检索增强生成（RAG，Retrieval-Augmented Generation）。通俗地说，就是让 AI 在回答问题之前，先去翻阅你的私有资料，然后基于这些具体材料作答——而不是单纯依靠训练时习得的通用知识。

Glean 估值 $7.2B，Harvey 估值 $11B。这三家公司合计估值近 680 亿美元，全部建立在调用他人 API 的基础上。

这里有一个让人困惑的悖论：最有价值的 AI 公司，为什么不造 AI？

模型是商品，上下文是护城河

要理解这个悖论，先要理解一个基本事实：大语言模型（LLM）正在快速商品化。

GPT-5 出来，Claude 4 出来，Gemini 出来。对于多数应用场景，这些模型的能力差异越来越小，而价格越来越低。如果一家公司的核心竞争力是「我的模型比你的模型好」，这个壁垒正在以肉眼可见的速度缩小。

真正很难复制的是什么？在推理时，把最准确、最相关的上下文喂给模型的能力。

这不是一个纯粹的技术问题。它同时是一个数据问题、一个信任问题、一个与客户业务深度绑定的问题。

三种上下文，三种生意

Cursor、Glean、Harvey——三家公司，上下文来源完全不同，于是走向了三种截然不同的商业模式。

Cursor 的上下文是你的私有代码库。

用 Cursor 打开一个代码仓库，后台会悄悄启动一个索引流程：将代码分割成语义单元（函数、类、逻辑块），通过专门训练的向量模型转换为数值向量，存入 Turbopuffer 向量数据库。关键细节：原始源代码不会离开本地，Cursor 服务器只存储混淆后的元数据。

这套索引的规模现在有多大？Cursor 在 Turbopuffer 上管理超过 8000 万个命名空间、超过 1 万亿条文档。相比传统向量数据库方案，成本降低了 95%。

当你向 AI 提问「这个 bug 是哪里引入的」，Cursor 不是在问一个通用模型，而是在先检索你的代码库，把最相关的代码片段塞入上下文，再让模型作答。官方数据显示，语义搜索与 grep 结合，相比单独使用 grep，回答代码库问题的准确率提升 12.5%。

上下文来源决定了客户：你的私有代码库只有你自己能提供。所以 Cursor 的生意是面向开发者的订阅工具——$20/月的个人订阅，$40/用户/月的团队版。Fortune 500 中 64% 的公司已在使用。

Glean 的上下文是企业内部知识。

Slack 的消息、Google Drive 的文档、Salesforce 的客户记录、Jira 的工单——这些散落在不同系统里的企业知识，构成了 Glean 的上下文来源。它有 100 多个预置连接器，实时同步这些数据。

但 Glean 真正的差异化，不是连接了多少个系统，而是它如何处理权限。企业最大的顾虑从来不是「AI 不够聪明」，而是「AI 会不会把 A 部门的数据泄露给 B 部门」。Glean 的架构是：权限强制执行先于数据传送给 LLM，用户只能检索到自己有权访问的内容，权限变更几分钟内即生效。数据在客户自己的私有云环境（VPC，Virtual Private Cloud）内处理，不流向 Glean 的服务器。

这个架构决定了 Glean 只能做企业 SaaS。个人用户没有「内部知识库权限管理」的需求。按席位收费，大型企业部署需要一次性实施服务——这是 Microsoft Copilot 无法完全替代 Glean 的原因，因为 Copilot 的上下文局限在 Microsoft 365 生态内，无法跨系统检索 Salesforce 或 Slack 的数据。

今年 5 月，Glean ARR 突破 $300M，Fortune 500 客户数同比近翻倍，85% 的客户在 5 个以上部门部署。

Harvey 的上下文是法律语料加私有案件数据。

法律行业有一个特殊性：每家大型律所的先例库、合同模板、合伙人审批风格，都是高度定制化的私有资产。标准化的 SaaS 产品在这里几乎无法落地。

Harvey 的解法是「嵌入式法律工程」（Embedded Legal Engineering）：向 BigLaw 客户派驻前置部署工程师（Forward Deployed Engineers，FDE），在客户内部嵌入 6–9 个月。这些工程师的工作不是写代码，而是对接客户的文档管理系统（通常是 iManage 或 NetDocuments），梳理先例数据，调整检索逻辑，让 Harvey 说出这家律所特有的「语言风格」。

在技术层面，Harvey 使用法律专用的向量嵌入模型——据第三方分析，相比通用 embedding 模型，在法律检索中无关内容减少约 25%。根据其发布的 BigLaw Bench 基准测试，Harvey 相比通用聊天机器人，幻觉减少 60%，引用来源准确率提升 23%。

这套定制化程度，使 Harvey 的商业模式无法大规模标准化——但也正因如此，Am Law 100（美国最大的 100 家律所）中已有超过 50% 在使用 Harvey。客户总数超过 1,500 个组织，142,000 名律师。估值 $11B。

但 Midjourney 没有 RAG

如果「上下文检索系统是护城河」这个论点是对的，Midjourney 怎么解释？

Midjourney 是纯粹的图像生成模型，没有 RAG，没有私有数据检索，据估计年营收约 $5 亿，从未接受过风险投资，员工人均营收约 $300 万，是行业平均水平的数倍。

这说明「上下文检索是护城河」并不是一个放之四海而皆准的结论，而是存在边界条件。

边界在哪里？任务类型。

图像生成的输出质量，主要取决于模型在训练时习得的视觉语言，而不是推理时的私有数据检索。没有哪个企业客户需要「用我们公司的私有图片库来辅助生成图像」——他们需要的只是一个审美能力足够强的生成工具。Midjourney 的护城河是独特的图像风格、2100 万用户的社区生态，以及用户在 Discord 上公开生成结果所形成的社区品味飞轮。

这是社区飞轮，不是数据飞轮。两者都有效，但适用于截然不同的商业场景。

架构划定的，不只是技术边界

把这四个案例放在一起，会发现一个更精确的结论：

Cursor 选择建立代码库索引，这个选择在第一天就决定了它的目标客户是开发者。Glean 选择建立跨系统企业知识图谱，这个选择决定了它的客户必须是有私有数据隔离需求的大企业。Harvey 选择在律所内部嵌入工程师来构建定制化上下文，这个选择决定了它无法快速复制到每一个行业——但也决定了它在已进入的行业里极难被替代。

这不是「架构决定商业模式」这么简单。更准确的表述是：架构选择在第一天就划定了你能做什么生意、不能做什么生意的边界。 传统 SaaS 时代，产品可以先做大，再慢慢调整商业模式。AI Native 时代，技术架构和商业模式之间的绑定，发生得比以前更早、更深。

三家公司使用的基础模型——OpenAI、Anthropic、Google——彼此都可以互换。互换不了的，是那套接入了私有代码库、企业知识图谱、律所先例数据的上下文检索系统。

模型是商品。你控制了哪个领域的上下文，你才控制了那个领域的 AI 入口。