a16z观点：SaaS 的入口正在从数据库挪到推理层

a16z 这周发了一篇观点文章，标题就是结论 - From "System of Record" to "System of Intelligence"。同一天 Notion 也上了它的 Developer Platform：Workers（云端隔离沙箱跑自定义代码）、Database Sync（从 Salesforce / Zendesk / Postgres 同步数据）、External Agent API（把第三方 agent 接进工作区）、基于 MCP 的 Agent Tools、还有一个 Notion CLI。

两件事放在一起看不是巧合 - 是 SaaS 产品形态的一次方向调整。a16z 用了两个缩写贯穿全文：System of Record（数据库式的"记录系统"，下文简称 SoR）和 System of Intelligence（坐在记录系统之上的"推理系统"，下文简称 SoI）。下面分几节聊聊：a16z 的核心论点、SoI 落到实际场景长什么样、为什么不是又一次 SaaS 形态翻转的空喊、Notion 这一步具体兑现了什么，以及一个 a16z 没正面回答的隐忧。

a16z 的类比 - news feed 大于 friend graph

文章用 Facebook 的演化做了类比。社交媒体早年最值钱的是 friend graph，但最终 news feed 才是真正的产品 - 个人主页沦为众多输入信号里的一个。a16z 的判断是 CRM 也会走同样的路：Salesforce（1400 亿估值）和 HubSpot（90 亿）不会消失，但它们会逐渐从"用户每天打开的入口"变成"被 API 调用的基础设施"。

为什么？因为 AI agent 不需要数据集中在一个地方才能工作。它可以同时拉 CRM、邮件、日历、电话录音、Slack、计费、产品运行数据，再合成出一个建议或动作。当上下文可以跨系统编排，"谁存了数据"就不再是一道护城河。a16z 说："In the AI era, gravity will come from orchestration." - AI 时代的重力来自编排层。

这套类比并不新，2023 年就有人讲过。新的是现在能看到具体公司在这条路径上跑起来。

SoI 落到实际场景长什么样

a16z 用销售（GTM）作为切入点，因为这是 SaaS 商业模型最饱和、产品壁垒最依赖数据沉淀的场景之一。他们列举的几个具体形态：

• 梳理账户的早间情报 - 客户经理早上打开看到的不再是静态的客户清单，而是一个按昨夜新闻、市场动态、对手活动排过序的信息流
• 外呼系统实时给出反对话术 - 销售在电话里听到客户反对一个点，外呼系统实时给出三条历史里成功过的应对路径
• 通话 AI 自动写 CRM 笔记 - 通话结束销售开发员不用再花 15 分钟敲 Salesforce
• 复盘销售纪律的会议分析 - 跨整个团队的电话录音里找出"哪个销售在哪类对话上漏问关键问题"

这些都在销售这一个场景里。把镜头拉远，相同的形态在每个 SaaS 类目都能复现：

• 编码 - Cursor 不是 IDE 2.0，它是坐在 IDE 上的推理层；底层文件系统和 Git 仓库变成了它的"数据库"
• 会议 - Granola、Otter、Fireflies 把"开会"和"会议笔记 / 待办事项 / CRM 写入"合成一个工作流，原来的录音存储成了被消费的资源
• 企业搜索 - Glean、Lindy 把分散在 Drive / Slack / Confluence / Jira 的内容做成一个统一推理层；那些底层 SaaS 不再是日常入口

每个类目都有同样的结构：一个 SoR 形态的存量市场，一个 SoI 形态的新切入。

不是空喊 - 几个可观察的信号

类似的论点容易写成"未来会怎样"的纸上谈兵。但有几个具体信号说明这次不是。

第一个信号是老牌 SaaS 自己的姿态调整。 Salesforce 过去一年明显在往 API-first 走，发了 Agentforce 也开始把自家功能拆成可被外部 agent 调用的工具。HubSpot 类似。这不是"应对竞争"，是承认自己更适合做基础设施而不是入口 - Stripe 当年走过同一条路，结果反而做大。

第二个信号是企业采购的预算结构在变。 a16z 的一个反直觉观察是：SoI 工具不替代销售团队的规模，反而把总预算做大了。逻辑是销售业绩达成率提升、ROI 改善、可以养更多销售。这点和"AI 取代销售"的叙事相反，但和过去几年实际企业采购单看到的更吻合 - Clay、Apollo、Common Room 这些都是加法不是减法。

第三个信号是协议层的成熟。 一年前要让一个 agent 同时拉 5 个 SaaS 的数据要写 5 套集成代码。MCP 普及之后这件事的边际成本急剧下降 - 这才是 SoI 在 2026 年具备工程可行性的真正原因。

Notion 这一步具体兑现了什么

回到开头。Notion 同一天发的 Developer Platform 是把 a16z 的论点落到自家产品上的一次公开兑现：

• Notion Workers - 云端隔离沙箱跑自定义代码。意思是不用自己跑后端，业务逻辑直接编排在工作区里
• Database Sync - 从 Salesforce、Zendesk、Postgres 把实时数据拉进 Notion。Notion 不再要求你把数据搬过来，它去取
• External Agent API - 第三方 agent 可以以一等公民的身份接进 Notion 工作区
• Agent Tools - 基于 MCP 的自定义工具构造器
• Notion CLI - 工具链开始向开发者倾斜

自 2 月推出 Custom Agents 起，用户已经造了 100 万+ 个 - 这个数字单看不重要，重要的是 Notion 已经验证了"在工作区里直接写 agent"这种做法有用户基础。Workers 在 8 月之前免费用，是经典的"先把人吸进来再说"的扩张姿态。

把这套东西放回 a16z 的框架：Notion 之前的护城河是"我帮你把所有 doc / db / wiki 存在一个地方"，是典型的 SoR。今天它在主动让出这个位置 - 数据可以不存在 Notion，但编排必须经过 Notion。这是一次形态切换。

一个 a16z 没正面回答的隐忧

a16z 文章下有一条评论很尖锐：编排层一旦积累两年的推理与行为数据，它自己就会变成新的客户锁定来源，故事再循环一遍。这点 a16z 整篇文章都没正面回应。

我觉得这条评论说对了一半。"编排层会变成新的锁定来源"这点几乎一定会发生 - 但形态会和数据锁定不一样。

数据锁定是显式的：要换 CRM，得迁数据，痛苦但可量化。编排锁定是隐式的：你的 agent 经过两年积累，知道你们公司的对话风格、知道哪个客户值得加分、知道哪些任务可以自动执行、哪些必须人审。这是隐性知识，连显式描述都很难，更别说迁移。

所以下一代企业软件的护城河可能既不是数据，也不是 UI，而是 agent 对一家公司具体业务的"理解程度"。这个东西不在数据库里，而是分散在提示词、工具定义、历史决策样本、人 + agent 的交互模式里。这种护城河没人形容过、没有现成的术语，但是它比数据更难绕开。

builder 看到什么、buyer 看到什么

对正在做企业软件的人：a16z 这篇值得读完。它没有告诉你怎么做（这类文章本就不该告诉你），但它告诉了你哪个方向现在是开放的 - SoI 形态的新公司，每个垂直类目都还没有明确赢家。

对正在评估企业软件的人：可以开始留意"这家公司的 agent 是不是真的能跨我现有系统拉上下文"，而不是"它的数据库有多大"。前者是它的 SoI 能力，后者只是它的 SoR 锁。

对自己写 agent 的人：这两年里你做的 agent 工具集（特别是 MCP server）、agent 的指令文件、积累的运行轨迹样本比数据更值钱 - 因为它们就是上面说的那种隐式知识的载体。保护好它们。