a16z：当UI不再是产品，软件的护城河还剩什么？

编者按：过去二十年，SaaS 的护城河很大程度上建立在 UI 之上。仪表盘、字段、审批流和用户习惯，不只是操作界面，也塑造了组织的工作方式和数据秩序。当 AI 可以直接读取数据、调用工具、执行流程，依赖人类肌肉记忆形成的粘性开始减弱，UI 不再必然是企业软件的核心界面。

这并不意味着记录系统失去价值，而是其防御性正在转移：从 UI 和使用习惯，转向数据模型、权限体系、合规责任、业务逻辑、执行闭环和多方协作网络。未来真正有壁垒的软件，可能不再只是记录人类工作的数据库，而是能够捕捉上下文、发起任务、协调智能体，并在执行过程中持续生成新数据的行动系统。

当软件走向 headless（去界面化），企业软件的核心问题也随之改变：价值不再只是谁拥有数据，而是谁能围绕数据组织行动。

以下为原文：

上个月，Salesforce 宣布将开放 API，并推出一款 headless（去界面化）产品。本质上，这意味着 Salesforce 正在押注：在 Agent 时代，其核心价值不再主要来自 UI，而是来自数据层。这是一次相当聪明的重新定位。

不过也需要指出，从技术层面看，这次发布似乎并没有带来太多实质性变化。Salesforce 如今以「headless 产品」名义重新包装的 API，很大程度上其实已经存在多年。换句话说，这更像是一场典型的 Salesforce 式营销发布。

这款新产品的核心思路是，Agent 可以直接访问记录系统中的数据，而不必再通过面向人类设计的 UI 完成交互。传统 UI 的作用，是帮助人类用户追踪流程、管理任务和推进工作流；但在 Agent 介入之后，这一层界面的必要性开始下降。

这次发布真正值得讨论的地方，不只是 Salesforce 推出了什么新产品，而是它抛出了一个更底层的问题：如果剥离 UI，只开放底层数据库，那么一个记录系统还剩下什么？它和一个 Postgres 数据库、一套设计良好的数据 schema，以及一组 API 之间，究竟还有多大区别？

进一步说，那些曾经让记录系统具备长期防御性的经典因素，是否仍然成立？还是说，新的竞争标准已经出现？

在 SaaS 时代，记录系统之所以拥有护城河，是因为人类用户长期生活在它的界面之中。界面承载了操作习惯、组织流程和数据沉淀，也由此形成了较高的迁移成本。但在 Agent 时代，这一优势正在被削弱。真正具备防御性的层级，正在一方面下沉到数据模型、权限体系、工作流逻辑和合规能力之中；另一方面上移到网络效应、专有数据生成能力，以及现实世界的执行能力之中。

当软件走向 headless，护城河究竟会转移到哪里？

UI 曾经就是产品本身

所谓记录系统（System of Record，SoR），指的是某一类商业数据的权威事实来源。它是客户关系、员工记录或财务交易等「官方版本」所在的地方，也是其他工具读取数据、写回数据的核心系统。CRM 是收入相关数据的记录系统，HRIS 是人员相关数据的记录系统，ERP 则是资金与财务相关数据的记录系统。

这些系统的强大之处，并不只是因为它们存储了数据，而在于它们最终成为整个组织共同运转所依赖的「现实版本」。

过去二十年里，Salesforce 卖给客户的，其实是一套帮助销售负责人管理团队的方式。仪表盘、销售管道视图、预测工具、动态信息流，才是真正被购买的产品。它的商业模式建立在向用户销售席位之上，而这些席位本质上提供的是对上述功能的访问权限。底层数据库固然关键，但在产品体验中更像是一个隐性的基础设施。

也就是说，真正驱动用户粘性的，是 UI。

UI 约束了数据规范，塑造了共同语言：线索、商机、客户账户。它让成千上万名销售代表持续录入那些他们原本未必愿意录入的数据。过去，UI 正是维持数据一致性和可用性的机制。Salesforce 之所以粘性极强，以至于许多销售负责人在跳槽后仍坚持把 Salesforce 带到新公司，并不是因为它的界面多么出色，而是因为它已经变成了一种肌肉记忆。

但 Agent 正在开始颠覆这一模式。它们不再需要通过 UI 与软件交互，而是可以直接读取和写入底层数据。这也催生了一批绕过传统界面的新工具和替代方案。Salesforce 并不是唯一的例子：我们近期也曾讨论过，SAP 周围正在生长出一整个更适合 AI 调用的生态系统。

与此同时，能够操作电脑的 Agent，也会让偏好、培训、未文档化的上下文等传统人类层面的因素，随着时间推移逐渐变得不再重要。换句话说，成为一个持久记录系统所需满足的条件，正在发生变化。

过去的评分标准

在讨论 Agent 时代会发生什么变化之前，有必要先更精确地回到一个问题：过去到底是什么让记录系统具有粘性？

前几个因素，主要都与人类如何使用软件，以及人类自身的偏好有关。软件之所以难以被替换，很大程度上依赖 UI、使用习惯、人类工作流，以及已经嵌入组织流程的制度安排。

第一，它被访问的频率有多高？

CRM 每天都会被 GTM 团队以及更多相关部门使用。正是这种高频使用，让它成为关键基础设施。而建立在其上的人类层——例如团队例会、操作习惯、管理节奏等经过多年形成的组织惯性——往往才是最难迁移的部分。原因在于，它甚至经常不会被识别为「需要迁移的东西」。

第二，它是只写入，还是既读又写？

真正有粘性的记录系统，通常是一个读写双向的系统。以 CRM 为例，它不是一个只负责存档的写入系统，而是会被持续读取。每一通电话记录、每一次阶段更新、每一个任务创建，都是由某个用户输入的，而这个用户通常也在意这些数据之后如何被使用。

这种双向流动意味着，任何替代品都必须能够承接实时运营数据，而不只是导出一份历史数据。迁移过程中几乎不存在一个绝对安全的切换时点。因此，一旦企业完成上线，往往就会长期留在原供应商体系内。

与之相反，候选人追踪系统（ATS）通常更接近「只写入」系统。候选人被录用或拒绝之后，企业再回头使用这些数据的理由就相对有限。

第三，有多少未被文档化的 SOP？

真正关键的业务上下文，往往并不写在任何 wiki 里，而是沉淀在管理员和系统集成商多年搭建出来的工作流规则中。

以销售系统为例，这些未被文档化的上下文可能包括：超过 10 万美元的企业级交易需要 VP 审批；EMEA 区域的交易必须经过隐私审查；战略客户的折扣只有在季度末才能绕过财务审批。

这些上下文，往往决定了一件事能否被及时推进，或者能否在不违反关键流程的情况下完成。迁移系统，意味着要重新拆解每一条自动化规则；否则，企业就可能直接丢失一部分组织记忆。

第四，内部或外部依赖有多复杂？

核心问题在于：有多少内部系统、团队流程，或外部利益相关方依赖这个记录系统？

内部连接性，指的是有多少下游软件或工作流依赖它。外部连接性，则指审计师、会计师、监管机构等外部主体，是否需要直接访问其中的数据。ERP 就是典型例子。

无论是内部还是外部，只要连接性越高，迁移时需要拆解和重建的关系就越复杂。

第五，从合规角度看，数据有多关键？

这里的核心问题很简单：这个系统是否具有合规关键性？

像薪酬系统、ERP、人力资源数据这类合规关键系统，必须提供一个在法律上站得住脚的事实来源，并具备严格的管理员权限控制。任何迁移都可能需要审计师和监管机构直接介入。这使得它们的粘性显著更强。

销售数据和 Zendesk 这类客户支持工具则处在另一端。企业当然在意连续性和上下文，但如果数据发生迁移，或有人获得访问权限，通常并不会立刻引发监管层面的风险。

并不是所有记录系统都拥有同等程度的切换成本。把 CRM 和 ATS 放在同一组维度下比较，差距会非常明显。

ATS 是一种服务于有限流程的工作流工具，它围绕招聘展开。一旦候选人被录用或拒绝，相关记录大多就变成了一次性写入的数据。它的集成范围更窄，用户群体也更小、更集中。

ERP 则处在另一个极端。总账本身就是审计轨迹，会计师、审计师和监管机构都会成为迁移过程中的直接利益相关方。

替换 ATS 是痛苦的，但仍然可承受。替换 CRM 像是在做开胸手术。替换 ERP，则像是在病人跑马拉松的同时给他做开胸手术。

传统上，记录系统并没有真正利用专有数据、网络效应这类护城河来源；通常来说，工作流本身就已经足以形成壁垒。某种程度上，将工具与网络结合起来的，更多是消费级业务；历史上的 SoR 并没有走上这条路径。

专有数据。许多记录系统虽然沉淀了大量客户数据，但并没有真正围绕这些数据展开深度利用，而且在很多情况下，合同条款也不允许它们这么做。因此，尽管 CRM 拥有丰富的数据集，理论上也可以汇总不同客户的数据，生成跨客户的洞察，但它们从未以真正有意义的方式做到这一点。当然，Salesforce 的 Einstein 这类产品曾做过一些尝试。

网络效应。对记录系统来说，最理想的护城河本该是网络效应：例如，CRM 会因为软件卖家能够在其中找到买家而变得更有价值。但和数据一样，历史上记录系统的网络效应一直很弱，甚至可以说几乎不存在。

如果 UI 消失了，Agent 到来之后，软件还剩下什么？

Agent 并不需要浏览器。它需要的是 API、上下文、指令，以及执行动作的能力。有两件事让这一切能够规模化发生：一是 LLM 已经具备足够强的推理能力，因此 Agent 如今可以读取上下文、制定计划、选择工具、执行动作并复盘结果，而在大多数任务中不再需要人类介入；二是 MCP 标准化了工具访问方式，为 Agent 调用外部能力提供了一套通用接口。

一个拥有 MCP 访问权限的 Agent，可以在毫秒级时间内、大规模完成过去人类用户在平台上执行的操作，而且不需要浏览器。在上下文充分的情况下，能够操作电脑的 Agent 甚至可以直接使用既有软件界面，而不一定需要 API。

简单来看，软件买家现在有三条路径：

第一，继续使用既有系统，并在其上叠加 Agent。
通过既有系统的 CLI 和 API 使用它们，既可以使用厂商原生的 Agent 产品，比如 Salesforce 的 Agentforce、SAP 的 Joule，也可以在其上自建 Agent。当然，这里暂且假设 API 是完整且可用的，也暂且忽略「headless 化」在实际运营中可能带来的复杂性。

第二，完全自建记录系统。
企业可以从零开始搭建自己的数据模型、运营逻辑、权限体系、审计追踪、系统集成，以及自己的 Agent 栈。这一路径很可能会借助第三方 Agent 开发工具和数据库工具。

第三，购买 AI 原生替代品。
企业也可以购买新一代从一开始就为 Agent 时代设计的软件。这类产品强调机器可读性，将 Agent 编排作为一等能力，而不是在旧系统之上打补丁式地增加一个 AI 功能。这类产品也可能是 headless 的。

那么，旧有评分标准中哪些东西会被保留下来？

由人类行为和偏好驱动的因素会逐渐减弱，比如访问频率、读写双向属性等与人类肌肉记忆相关的指标。Agent 或许会削弱「肌肉记忆」作为护城河的价值，但它们不会消灭运营逻辑和业务上下文的护城河。某种意义上，它们反而会让这些逻辑变得更加重要，因为 Agent 要安全地执行任务，必须依赖清晰的规则、权限和流程定义。

未被文档化的 SOP，在短期内仍然重要。
组织内部沉淀在工作流规则中的制度逻辑，正是 Agent 代表你正确执行任务所需要的东西。同时，这也是最难重建的部分。至少目前，它还无法被干净地导出，尤其是在部分流程仍然需要人类参与的情况下。不过，捕捉上下文正在变得越来越容易；随着 Agent 替代更多人工劳动，这一因素的重要性也会逐渐下降。

连接性仍然难以拆解，而且会向更深处延伸。
连接性的含义正在发生变化。它不再只是为了配合人类工作，而是要维持传统上彼此割裂的职能和软件之间的连接。

一个 CRM Agent 需要把销售、账单、客户成功等不同环节的数据和上下文串联起来。如果你的平台还成为多个外部组织之间的 Agent 进行交易的节点，比如买家、卖家、合作伙伴都通过这里完成交互，那么依赖关系会进一步加深。

既有厂商叠加 Agent 时，可能很难在不同底层软件的基本对象和逻辑之间顺畅协作；企业如果只靠一个自建数据库和一组 Agent，也会面临类似问题。

合规关键数据仍然重要。
涉及监管机构、监管风险或法律风险的数据，仍然需要一个单一、可信的数据事实来源。如果客户已经信任现有产品，他们切换系统的可能性就会更低。

以薪酬和会计数据为例，Agent 可能确实需要访问这些数据，但企业通常不太可能选择在内部自建并长期维护这类系统。

在一个完全 Agent 化的世界里，最难解决的问题之一是：哪些 Agent 被授权做什么？它们代表谁行动？这些行为如何被审计？如果一个记录系统能够成为 Agent 之间交互的身份与权限层，它就会获得一种真正难以被替代的结构性角色。这里的壁垒不只是它持有什么数据，而是它执行着怎样的信任架构。

往前看，对于 AI 原生创业公司而言，一组新的因素将变得越来越重要，并决定它们能否形成防御性。

第一，重建这个记录系统到底有多难？

数据会在几个层面变得更加重要。

首先，在短期内，关键在于提取并重建记录系统底层数据的难易程度。AI 正在让这件事变得更容易，一批工具正在帮助用户完成这类迁移和重建。

短期内，既有厂商可以、也很可能会让这件事变得更难：它们可以让 API 难用、设限、不完整，或者在经济上变得不划算，甚至根本不提供 API。但随着提取工具不断进步，尤其是能够操作电脑的 Agent 能力提升，数据重建会变得越来越容易。

与此同时，新公司也正在从邮件、电话、语音 Agent 和内部文档中重建一套更丰富的数据。AI 降低了重建一个记录系统前 80% 的成本。真正区分一个有用切入口和一个真正替代品的，是剩下 20%：异常情况、审批流程、合规要求，以及边缘场景下的工作流。

第二，是否拥有真正有意义的专有数据？

其次，数据本身会变得更有价值。

真正具备防御性的数据，并不是你导入的数据，而是你的产品独特地促成其产生的数据。我们常说「数据围墙花园」：这些数据要么是专有的，要么受到监管约束，要么需要持续更新。一个在收集权威且完整数据上投入大量资源的软件供应商，相比通用型供应商或缺乏这类数据的竞争对手，会拥有明显优势。

数据还有另一个重要方向：它是否依赖产品内部产生的动作。

最好的公司不会只是储存从别处录入的数据。它们会因为自己处在流程之中，持续产生新的数据尾迹，例如观察到的行为、响应率、时间模式、流程结果、行业基准、异常模式，以及 Agent 的执行轨迹。

关键在于：数据如今就是上下文。

第三，是否掌握动作层？

在旧世界里，存储记录本身就已经足够。但在新世界里，Agent 会直接采取行动，防御性可能会转向那些能够形成闭环的产品：从采取行动，到捕捉结果，再到利用反馈优化未来决策。

对 ERP 来说，这可能包括审批支出、触发薪资发放、核对发票、发送通知等。能够闭环的产品更具防御性，因为它们嵌入了执行过程，而不仅仅停留在观察层面。它们会生成独特数据，随着使用而持续改进，也会因为一旦移除就会破坏工作流而变得更难替代。

当然，随着上下文越积累越多、边缘场景处理得越充分，这里的价值也会进一步上升。

第四，是否包含现实世界的执行环节？

有些商业模式与现实世界的运营连接在一起，而这些环节不会被完全自动化。最明显的例子，是拥有运营网络的公司，比如 DoorDash。它们历史上并不属于记录系统，但在这里很有启发意义。

更广泛地说，任何能够把软件闭环延伸到服务、履约、物流、现场运营或支付环节的公司，都拥有一种不同于纯 SaaS 的防御性。这类公司不只是存储记录，也不只是推荐动作；它们会派遣人员、移动货物，或完成具体服务。

对创业者来说，这意味着机会可能出现在这样一些市场：软件越来越能够做决策，Agent 越来越能够协调流程，但最后一公里仍然需要现实世界的执行。例如，与现场服务绑定的垂直软件，就是一个典型方向。

第五，是否存在网络效应？

历史上，大多数记录系统的网络效应都很弱，因为它们主要是内部软件。但在 Agent 时代，如果一个系统嵌入了多方工作流，网络效应可能会变得重要得多。

如果一个系统负责调解多方之间的重复互动，比如买家与卖家、雇主与员工、公司与审计师、供应商与客户、付款方与服务方，那么每增加一个参与方，都可能让这个网络对下一个参与方更有价值。

其中一种方式，是共享工作流协同：产品成为流程双方进行交易、交换上下文、处理异常的场所。

另一种方式，是基准与智能：系统可以基于网络中观察到的模式，呈现行业常态、异常情况和行动建议，这一点又与前面提到的数据价值相互强化。

第三种方式，是信任与标准化：一旦交易对手方开始依赖同一套轨道来完成审批、交接、合规或支付，这个产品就不再只是一个数据库，而是市场本身的协同基础设施，因此也会更难被替代。

第六，买方的技术能力有多强？

在一个任何人理论上都可以自建 Agent 的世界里，不同买方真正具备的建设能力仍然差异巨大。尤其是在垂直行业，以及那些过去并没有强大内部工程资源的职能型买方中，他们自己搭建、维护并持续改进数据库、工作流逻辑、Agent 栈和治理层的概率仍然很低。

成本在这里同样重要。DIY 理论上可能减少软件授权费用，但往往会把支出转移到实施、维护和内部复杂性上。

这意味着，在那些运营复杂但技术供给不足的品类中，仍然存在真实机会。例如制造业、建筑业后台、工业流程、现场服务工作流，以及会计等领域。

还有一些因素也同样重要，并且会逐渐成为软件的基本门槛。

比如，本体论需要发生变化。很多「自建数据库」的想法，低估了对象模型本身承载的价值。既有软件是为仪表盘、报表和人类用户构建的，它们捕捉的是工作流中的对象，比如商机、工单、候选人等。

但 Agent 时代的 schema 需要捕捉推理、动作、状态跟踪、异常处理、任务委派，以及跨系统协同。原生对象模型可能不再是商机、工单和候选人，而是任务、意图、线程、策略或结果。

同样，权限体系也需要更新。它不再只是管理人类用户，而是要管理 Agent。这包括：谁可以做什么，通过哪个 Agent，在什么策略下，需要哪些审批，留下怎样的审计轨迹，以及如何进行回滚和异常处理。

当然，所有这些都离不开成本问题，例如搭建和维护 Agent 及数据库需要多少钱，API 访问成本有多高。这又会重新回到几个核心问题上：数据重建有多难，依赖关系有多少，以及系统到底嵌入了多深。

那么，结论是什么？

随着既有软件厂商走向 headless，它们实际上是在做一个隐含押注：数据层仍将是价值的核心来源。在某些品类中，尤其是金融服务这类深受合规约束的领域，这一押注或许还能在一段时间内成立，headless 化的进程也可能来得更慢。

但对软件创业者而言，随着既有厂商开始去界面化，如何与它们竞争、如何构建具备长期防御性的软件，问题正在发生变化。

下一代记录系统已经开始呈现出不同形态：它们不再只是用于记录人类工作的数据仓库，而是更具 Agent 属性——能够捕捉上下文、主动发起工作，并记录执行过程中产生的数据尾迹。

更进一步，最有意思的公司将会延伸到现实世界的执行层：它们会协调现场工作人员、物流服务商、服务团队和实体资产，或者处在多个参与方之间，成为多方协作的中间层。

这些公司将混合旧世界的多种商业模式。而传统记录系统的核心，也就是数据，将逐渐退到后台，成为支撑整个系统运转的底层基础。

[原文链接]

点击了解律动BlockBeats 在招岗位

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia