这期在讲什么
a16z Show 这一期由 Elena Burger 主持，Seema Amble 和 Steven Sinofsky 讨论「headless software」：当 AI agent 变成企业软件的主要用户，软件的前端界面会失去一部分护城河，真正重要的东西下沉到数据、业务逻辑、权限、审计和异常处理。节目标题是「Is Software Losing Its Head?」，对应 Seema Amble 在 a16z 发表的同名文章。3
这不是「把 Salesforce 或 SAP 换成一套 Postgres + API」那么简单。三位反复强调，企业软件里最难搬走的往往不是表结构，而是多年沉淀下来的审批规则、合规要求、例外流程、跨部门依赖和业务人员默认知道但没有写在文档里的上下文。1
嘉宾背景
Seema Amble 是 a16z 合伙人，关注早期 SaaS 和 B2B fintech 投资，2019 年加入 Andreessen Horowitz；本期讨论基于她此前发表的「Is Software Losing Its Head?」。4
Steven Sinofsky 是 a16z board partner，曾长期在 Microsoft 负责 Windows 与 Office 相关产品组织；他在节目里把企业软件粘性拆到异常处理、组织流程和历史迁移成本上。5
Elena Burger 是 a16z writer，本期负责提问和推进对话，围绕 Salesforce、MCP、SAP、agentic workflow 和创业机会组织讨论。6
图集顺序
- 封面：软件正在失去前端？
- Seema Amble：a16z 合伙人，早期 SaaS 与 B2B fintech 投资。
- Steven Sinofsky：a16z board partner，前 Microsoft Windows 负责人。
- Elena Burger：a16z writer，本期对话主持与提问者。
- 核心观点：UI 不再是护城河。
- 金句：企业里最有价值的工作，往往都是例外处理。
- 反误区：Postgres + API 不能替代 SAP。
- 创业机会：从 system of record 到 system of execution。
核心观点
1. 「无头软件」首先是一次访问方式变化
传统 SaaS 的产品形态围绕人设计：人登录界面，填字段，看仪表盘，按流程推进。Salesforce 宣布 Headless 360 后，Seema 的判断是：这个动作本身更像把已有 API 重新包装成面向 agent 的入口，但它承认了一个更大的变化，未来访问 CRM 数据的人可能不是销售代表，而是 agent。1
如果 agent 不通过界面，而是直接读写系统底层数据，界面的习惯、肌肉记忆和操作路径就弱了一层。软件价值不再只在「人怎么点」，而在「数据能不能被正确理解、权限能不能被正确执行、业务逻辑能不能被安全调用」。Seema 在文章里把这个变化写成：防御层从 UI 下沉到数据模型、权限、流程逻辑和合规，同时也可能上移到专有数据、行动层和真实世界执行。3
2. UI 会变弱，但系统记录不会自动消失
Steven 提醒，很多人把「headless」「agent」「API」混在一起讲，其实要先区分 agent 在做什么：只是查询，还是要写入系统，还是要跨多个系统做分析。查询比较轻；一旦要行动，就会碰到身份、权限、席位、审计和回滚；一旦要分析，就会碰到幻觉、验证和跨系统一致性。1
这也是为什么 SaaS 不会因为 agent 出现就集体「死亡」。CRM、ERP、HRIS 这类系统之所以能成为 system of record，不只是因为它们有数据库，还因为它们承载了公司共同承认的事实版本。客户是否成交、员工是否入职、发票是否合规，这些不是聊天机器人能随便重写的字段。3
3. 企业软件真正难替换的是「例外」
节目里最有价值的一条判断来自 Steven：企业里最有价值的工作，往往都是例外处理。流程图里的标准路径容易自动化，真正决定系统能不能替换的是长尾情况：日本客户该怎么催款、EMEA 交易什么时候必须走隐私审查、战略客户季度末折扣能不能绕过普通审批。1
Seema 也把这些称为 agent 需要的 context graph。Agent 可以拿到 CRM 里的字段，但它还要知道不同地域、不同客户、不同销售动作背后的处理习惯。很多上下文不在 Salesforce 字段里，而在人脑、邮件、会议、录音、文档和历史操作里。AI 的机会之一，是把这些过去没被结构化记录的例外逐渐捕获下来。1
4. 「Postgres + API 替代 SAP」是创业者最容易低估的地方
Seema 明确反对一个常见误区：有了数据库和 API，并不等于可以替代 SAP。SAP 里最重要的不是「数据刚好存在某张表里」，而是多年实施过程中写进去的业务规则、审批逻辑、合规要求和公司运行方式。1
Steven 用汽车公司解释这件事：同样是造车，Ford、Toyota、GM 和 Daimler 的差异不是谁看了哪张表，而是各自如何决定生产、采购、汇率、材料、人员和新品节奏。ERP 不是一套通用表单，它把公司的运营规则编码进系统。把它抽象成「一个数据库」会漏掉最难迁移的 20%。1
5. AI 会扩大工作边界，不只是替换现有任务
Steven 反复反驳「AI 自动化会把工作做完，然后人就没事了」这个静态假设。他的看法是，生产率提升会创造新场景：当一个流程被自动化，企业会立刻开始分析更复杂的问题，制定新的优化策略，产生新的工作层。1
他用差旅报销举例：最早只是把票据录进去，后来有了报销系统，再后来企业会分析差旅成本、航司选择、信用卡权益、销售绩效和远程工作策略。自动化没有让长尾消失，只是让长尾换了形态。1
对创业者的启发
不要正面复制已有类别
Steven 给出的创业建议很直接：不要用同样方式正面复制一个成熟企业软件类别。成熟客户会拿 20 年框架问你是否满足 8000 个旧需求。更好的机会在两个既有系统之间，尤其是老厂商只把 AI 接到现有产品边上的地方。1
这类机会的核心问题不是「你能不能替换 Salesforce」，而是「你为什么存在」。如果产品能用 AI 连接两个过去不顺畅的职能，比如销售和财务、产品和设计、现场服务和后台合规，就有机会形成新类别。Steven 把 Figma 连接设计和产品开发作为类似例子。1
新系统要拥有行动闭环
Seema 的判断是，下一代系统不会只记录数据，还要发起行动、捕获结果、继续学习。比如 CRM 不只是记录通话，而是判断哪些客户该优先跟进、发送外联、观察回应、更新下一次行动策略。真正有价值的数据，不只是导入来的历史记录，而是产品在行动过程中自己创造的新数据。3
这也是最后一张图里的「system of record 到 system of execution」：记录、行动、结果、学习形成闭环，软件才有机会从后台数据库变成执行系统。3
垂直行业和真实世界执行会更重要
Seema 特别提到制造、施工、现场服务等场景，因为这些行业的工作不完全发生在软件里。Agent 可以协调、记录和分析，但最后一公里仍然需要人、机器、物流、支付或服务交付。能把真实世界动作带回系统里的软件，会比只做数据看板更难替代。3
按对话顺序的中文精译
Elena 开场问：如果 AI agent 成为企业软件的新用户，软件还需要前端吗？Seema 先解释，所谓 headless software 不是新词，但因为 Salesforce 宣布 Headless 360，它重新进入讨论中心。传统软件围绕人来设计，界面负责让人输入数据、查看流程、执行工作。到了 agentic world，agent 不一定需要进入界面，它可以直接访问数据和底层逻辑。
Seema 随后区分 Salesforce 这次公告和更大的行业趋势。她认为 Salesforce 的动作本身可能没有多少技术变化，更多是把已经存在的 API 换一种说法；但它承认了一个真实趋势：越来越多 agent 需要访问系统记录里的数据。Notion 这类用户更偏技术、构建 agent 意愿更强的产品，也会面临同样问题：到底开放哪些 API，怎样让 agent 访问自己的能力。
Steven 接着把概念拆开。他说这一轮技术浪潮里大家发明了很多新词，agent 很多时候像是「运行很久、不一定结束的程序」换了一个更好听的名字。但如果严肃讨论，就要看 agent 到底做三类事情中的哪一类：查询、行动、分析。查询相对容易；行动要牵涉身份、权限和席位；分析要跨多个系统，还要证明每一步没有错。
谈到软件为什么粘，Seema 认为过去的粘性很大一部分来自人和界面的关系。销售代表每天进入 CRM，管理层看仪表盘，市场和财务依赖 Salesforce 的输出，久而久之形成流程、肌肉记忆和上下游依赖。企业还需要一个唯一事实源，所有人都承认某个客户状态、某笔交易、某个员工记录应该以这里为准。
Steven 从另一个角度补充：最粘的软件往往是已经让客户付钱的软件。只要企业持续把钱付给某套系统，替换它就会变得很难。真正让它粘住的原因，常常只有当客户威胁要替换时才会浮出水面。Outlook 的日历代理权限、递归会议例外，可能不是产品经理一开始设计的护城河，却足以让大公司不愿意迁移。
谈到 SAP，Steven 把它称为企业软件粘性的终极例子。保险公司几十年前写下来的系统、Stripe 重新实现收款这件事、SAP 在大型制造和零售企业里的角色，都说明企业软件经常把外部规则和公司运行方式编码进去。Seema 顺着这个点说，认为「Postgres + API 就能替代 SAP」是严重误判。SAP 里沉淀的逻辑、审批、合规和业务流程，比数据库本身重要得多。
Steven 用创业公司常见的误解举例：40 人团队做报销，可以靠一个人处理票据，也可以拍照 OCR；但 10 万人、20 个国家、多种法律和公司政策叠在一起，报销就不再是表单问题，而是组织规则问题。Larry Ellison 曾说企业应该接受 80% 方案，但企业恰恰会为剩下的 20% 付出巨大系统复杂度。
Seema 接着把 AI 的短期机会放在「让既有系统更好用」上。很多 AI 产品不是马上替换 SAP，而是在 SAP 之上提供可对话、可查询、可生成报告的层，让用户不必在复杂界面里找数据。Steven 说，企业软件里最常用的两个功能常常不是原生功能，而是导出 Excel、CSV 或 PDF。现在模型可以读取这些输出，做过去靠复制粘贴才能完成的分析。
对 Salesforce 这类系统，Seema 强调 agent 需要的不只是字段，还需要上下文。一个 outbound agent 可以读取客户信息并发送邮件，但它还要知道不同地区、不同客户类型、不同回应方式该怎么处理。这些例外原本存在销售人员脑中，现在需要通过语音、邮件、录音、点击行为和历史结果被系统捕获。
Steven 进一步把异常处理放到核心位置。他说企业里所有有意思的工作几乎都是例外处理。流程标准化之后，真正难的是「不按默认路径走」的情况。Amazon 客服是一个反例式样本：它把很多例外默认判给客户，再用后台数据改进仓储、物流和描述。AI 可能推动公司重新定义如何处理例外，但不会让例外消失。
节目中段谈到自动化的边界。Seema 认为权限会成为重要问题：谁能读、谁能写、什么情况下能调用数据、agent 之间如何互动，这些都会慢慢被解决，但不会一夜完成。Steven 则提醒，技术转变中最容易误判的是指数变化和生产率变化。自动化某个任务后，人们会发明新任务、新分析和新流程。工作的边界会扩大，而不是只把现有工作按比例减少。
他们用法律、放射科、差旅报销和开源软件做类比。Steven 的意思是，AI 会让合同更长、更复杂，医学影像需求可能增加，差旅分析会从报销走向绩效优化。开源发布是否冻结代码、公司是否关账、谁批准什么动作，本质上都是人对状态做判断。软件改变这些判断的工具和层级，但不能把所有判断降成一个 API。
后半段回到 MCP 和软件架构。Steven 认为，MCP 很多讨论来自工程师视角：希望所有工具都有干净 API，最好像命令行一样输入输出文本。但现实世界不按这个方式运作。软件公司不愿意变成别人上层工具背后的「哑数据库」，客户也不想把关键场景拆成一堆供应商拼装，因为系统稳定性会被最弱的一环决定。
Seema 把买方路径分成三种：继续用 Salesforce、SAP 等 incumbent，并在上面打开 agent 或 API；完全 DIY 自己的数据库、逻辑、权限和 agent；购买 AI-native replacement。她对第一种和第二种都保留意见：老厂商不愿被抽象成后台数据，企业自己重建完整系统又太难。第三种机会在于，AI 原生公司先在旁边观察、行动、收集新数据，慢慢变成新的记录系统。
最后谈创业机会。Seema 看好三类方向：从数据采集走向行动；通过 agentic loop 产生新的数据 exhaust；处理施工、制造、现场服务等物理世界场景。Steven 的建议是避开正面替换成熟类别，去两个既有软件或两个组织职能之间做新连接。成熟厂商会把 AI 接到旧产品边上，不会轻易破坏自己的产品线和销售方式，新公司可以在这些缝隙里定义新类别。
最后一个问题是企业软件能否拥有网络效应。Steven 认为跨公司网络效应会受合规和安全限制，但公司内部已经出现网络效应：一个人用 AI 写白皮书、做分析、改进工作方式，很快会带动团队里其他人使用。真正大的机会，是让两个原本难以沟通的职能开始共享上下文、交接任务和协同决策。
Comentar
Inicia sesión para comentar.