当AI Agent开始绕过UI直接调用数据，企业软件的底层逻辑正在被重构。a16z播客中Seema Amble与Steven Sinofsky揭示：Salesforce的Headless 360战略背后，是数据可对话性替代界面设计的行业转向。本文深度拆解无头软件如何颠覆传统粘性，以及创业公司如何在巨头博弈的夹缝中寻找真实机会。

你有没有想过，我们天天挂在嘴边的 AI agent，到底还需不需要一个软件界面。如果 agent 不用点鼠标，不用看屏幕，那我们做了几十年的 UI 设计，是不是马上就没用了。这个问题最近一直在我脑子里转，直到我听完 a16z 的一期播客才算有了一点头绪。这期节目的主讲人是 Seema Amble，还有 Steven Sinofsky 和 Elena Burger，他们聊的主题叫 headless software，中文可以理解成无头软件，就是把软件的界面这个头砍掉，只留下底下的数据和逻辑。我一口气听完，又倒回去听了两遍，越听越觉得这个话题比我最初想的要深得多。

这期节目的由头是几个月前 Salesforce 宣布要做 Headless 360，一下子把 headless 这个词从工程师的小圈子拉进了大众视野。三位嘉宾从这条新闻切入，聊到 agent 和 API 到底有什么本质区别，聊到为什么企业软件这么难被替代，聊到 SAP 这种老古董为什么活了几十年还死不了，也聊到创业公司到底该去哪里找真正的机会。听完我最大的感受是，这场对话表面上在聊技术架构，实际上在聊一个更根本的问题，软件的价值到底藏在哪里。

Headless 到底是不是新东西

Seema 开场就把这个概念讲得很实在。她说 headless 软件这个词其实不新，API 也不是新东西，很多公司早就对外开放接口了。但 Salesforce 这次搞的 Headless 360，本质上是把已经存在多年的 API 重新包装了一下，贴上一个新标签而已。她甚至半开玩笑地说，这条新闻单独拎出来看没那么值得大惊小怪。

但她话锋一转，说真正有意思的不是 Salesforce 这一家公司做了什么，而是整个行业都在往这个方向靠。传统软件是为人设计的，人要登录，要点击，要在界面里一步步走完一个工作流。可如果访问软件的不再是人，而是一个 agent，那这个 agent 根本不需要看界面，它要的是数据，是逻辑，是能不能直接拿到结果。界面这层东西对 agent 来说就是累赘。Notion 也做了 headless 产品，Seema 提到 Notion 的用户群体本身技术能力更强，更倾向于自己动手搭 agent，所以这件事在 Notion 身上反而更顺理成章。

我自己想了想，这个变化其实特别像我们做产品经历过的一次次范式转移。以前我们做 to B 产品，天天纠结按钮放哪里，菜单怎么分层，字体多大合适。可如果未来真正的用户是 agent，那这些视觉层面的打磨很可能变得没那么重要，重要的是你底层的数据结构干不干净，你的业务逻辑能不能被清晰地调用。这倒逼我们重新思考，我们做产品到底是在为谁的眼睛服务，还是在为谁的大脑服务。

Agent 和 API 到底差在哪，我们活在一个定义混乱的时代

Steven 在这里说了一句让我印象特别深的话，他说我们现在活在一种定义地狱里。每次技术浪潮出现，大家都会给旧东西起一堆新名字，这是技术演进很自然的一部分。他甚至开玩笑说，agent 这个词说白了就是给一个可能跑很久也可能跑不完的程序起了个好听的名字，以前这种程序出问题我们叫它 bug，现在摇身一变成了最酷的新功能。

玩笑归玩笑，Steven 给出了一个我觉得特别有用的框架，用来区分 agent 到底在做什么事。他把 agent 能干的事分成三类。第一类是查找，就是单纯去找一个信息，这种事其实所有系统都干得不错，技术门槛不高。第二类是执行某个操作，这时候问题就变复杂了，因为你要以谁的身份去执行，用谁的权限，是不是要占一个付费席位，这些企业软件里最头疼的问题全冒出来了。第三类是分析，这是最适合 agent 发挥的地方，因为分析往往要跨多个系统，要花时间试错，可以换不同模型跑出不同答案再做比较。但分析也是幻觉风险最大的地方，因为你分析出来的每一步结论都得能被验证。

听到这我突然明白了一件事，我们平时讨论 agent 的时候经常把这三件事混在一起说，结果讨论着讨论着就变成鸡同鸭讲。有人在聊查找类的 agent，觉得已经很成熟了，有人在聊分析类的 agent，觉得幻觉问题还远远没解决，两边说的其实不是一回事。这个三分法我觉得特别值得记下来，以后再看任何 agent 产品，先问一句它到底属于查找、执行还是分析，很多争论会立刻清晰很多。

软件的粘性从哪里来，答案比我想的更接地气

接下来这段讨论我听得特别有共鸣。主持人问，历史上软件的粘性到底是怎么来的，agent 又是怎么开始动摇这种粘性的。Seema 给出的答案很朴实，她说粘性很大程度上来自软件是围绕人的使用习惯搭建的。你多久要读写一次数据，多久要访问一次，围绕这个软件形成了多少没写进文档但大家都懂的操作规范，这些东西日积月累就变成了肌肉记忆和组织流程。她举了个例子，销售团队离不开 CRM，是因为销售代表天天要进进出出，财务要靠它的数据出账单，市场部门也依赖它的数据做上游决策，这些依赖捆在一起，粘性就出来了。

更关键的是，很多行业还有合规和法律层面的要求，必须保证有唯一一套可信数据，账目对不上是要出大事的，这种硬约束让软件的粘性又叠加了一层。

Steven 在这里补了一刀，他说其实最有粘性的一件事就是从客户那收钱。一旦你在收钱，客户想停下来都很难，想清楚不给你钱之后该怎么办更难。他讲了个特别生动的例子，说想把 Outlook 从邮件系统里换掉的人，很快就会撞上代理访问权限和多人共享日历这些问题，没有哪次产品会议专门讨论过要把日历做成 Outlook 最难替换的部分，但现实就是通用汽车不会因为日历功能就放弃六十万个账号的迁移。粘性这个东西经常不是设计出来的，而是软件一点点长进组织的血肉里长出来的。

我听到这里想起自己做 Dashform 的时候一直在思考的问题，我们总想着靠功能取胜，但这段对话提醒我，真正的护城河往往不是某个漂亮功能，而是用户已经养成的操作习惯，是那些散落在流程各处、没人写下来但人人都懂的默契。这种默契一旦形成，替换成本会高到超出你的想象。反过来说，如果我们想让用户迁移过来，光靠功能更强是不够的，得想办法把这种默契也一起接过来。

SAP 为什么死不了，vibe coding 替代不了企业软件

这一段可能是整期节目里我最认同的部分。Steven 提到九十年代末 Larry Ellison 曾经公开抨击企业软件行业，说大家都在过度定制，他主张企业应该老老实实用那种覆盖百分之八十场景的标准方案就够了。但大部分企业软件的人听完的反应是，这话说得轻巧，因为你的软件本来就只能满足我百分之八十的需求，而且现实根本不是这么运作的。

Steven 用汽车行业举了个特别有说服力的例子。福特、丰田、通用这些公司造的车用的都是差不多的技术，装配线、工人、供应链大同小异。真正把这些公司区分开的，是它们内部怎么决策要造什么车，买多少原材料，对冲哪种货币，什么时候招人，什么时候推新产品线，而这一整套企业资源规划全都跑在 SAP 里。所以这些公司本质上是被一群坐在会议室里盯着 SAP 屏幕的人在运营，福特和丰田的区别不是他们看的屏幕不一样，而是他们选择看哪些屏幕，做了哪些定制。

Seema 顺着这个话题点出了一个我觉得特别重要的误解，她说现在很多人觉得只要有个 Postgres 数据库加上一堆 API 就能把 SAP 换掉，这个想法完全不成立。真正值钱的不是数据存在哪个数据库里，而是封装在 SAP 里的那套业务逻辑，这套逻辑往往要花好几年才能实施到位，不是因为系统集成商效率低，而是因为它真的要贴合企业实际运作的方式去定制。

Steven 接着讲了个我很喜欢的类比。创业公司看企业软件的时候经常按自己的规模去理解问题，比如报销这件事，四十个人的公司随便找个人处理一下就够了，甚至可以说干脆全体员工拍照上传收据自动识别分类就完事了。这套方法在小公司很好用，可一旦你有十万员工分布在二十个国家，各国法律不同，公司政策还层层叠加，这套简单方案立刻就撑不住了，而这正是企业真正的复杂度所在。

他还讲了个我特别喜欢的老故事。早年推广 Excel 的时候，他们去高盛拜访，跟银行家吹嘘 Excel 比 Lotus 123 好用，结果对方回了一句，我们靠 Excel 赚的钱比你们卖 Excel 赚的还多。后来才明白，高盛把 Excel 玩到了极致，自己写插件，自己定义模板，这种深度定制已经变成了他们的核心竞争力。Steven 由此提醒大家，现在很多人严重低估了普通人靠 vibe coding 就能攻入企业软件腹地的难度，一个成长期公司的 revops 负责人想自己重建 Salesforce 系统，以为把字段和数据导进去就搞定了，但真正难的是怎么决定该采集什么信息，组织架构怎么对应，谁来长期维护，这些才是硬骨头。

这段听完我心里挺感慨的。我们做 SaaS 创业最容易犯的错误，就是拿自己团队的规模去想象客户的复杂度。别人的系统看起来笨重，可能恰恰是因为它扛住了你根本没经历过的那种规模和例外情况。这也提醒我，做 Dashform 或者看任何要切入企业市场的产品，第一步不是想着怎么颠覆，而是先搞懂对方那套笨重逻辑到底在保护什么。

例外处理才是整个游戏的核心

这部分讨论让我拍案叫绝。Seema 提出一个观点，说现在的重点已经从单纯采集数据变成了怎么让数据变得可对话、可用起来。以前要从 SAP 里拿数据得写 SQL，得在一堆界面里翻找，现在如果能用自然语言直接查询，能自动生成定制化报表，这才是真正的价值所在。

但紧接着 Steven 抛出了他认为最关键的洞察，他说企业软件几乎从来不缺功能，SAP 能生成任何你想要的报表和图表，问题从来不是软件做不到，而是你搞不清楚怎么让它做到，或者你压根没有权限。他甚至开玩笑说企业软件里用得最多的两个功能，导出 Excel 和导出 CSV，恰恰是原生软件里从来没有真正内置好的，客户拿到软件第一件事就是问能不能导出，因为这是他们绕开系统局限的应急出口。而现在有了语言模型，这个应急出口一下子被打通了，你可以把二十份 PDF 丢进模型里做以前根本做不到的分析。

Elena 在这里补充了一个我觉得特别扎实的例子，她说如果有个 agent 要做外呼或者外发消息，它确实不在乎字段怎么排列，点几次鼠标，但它必须搞清楚一件事，就是遇到不同情况该怎么应对。她说这几个月大家都在聊 context graph，中文可以理解成上下文关系图，说白了就是那些例外情况，那些从来没被写进系统字段、只存在于某个老员工脑子里的处理经验。比如同一封邮件，发给亚洲客户和发给欧洲客户的语气完全不同，这种默契 Salesforce 里根本没有记录。

我读到这里立刻想起自己团队做客户运营时踩过的坑。系统里的字段永远只能覆盖标准情况，真正让客户满意或者流失的，往往是那百分之二十的例外怎么处理。Steven 后面举了麦当劳自助点餐机的例子，说你只要在旁边站十五分钟，就会看到无数人在机器上放弃，转头去柜台点一份混合两种口味的麦旋风，因为这种需求根本不在选项里。他说企业自动化说到底就是在处理例外，这句话我听完真的愣了一下，因为这几乎是我们做产品这么多年一直在绕着走、却从没直说过的真相。

Steven 后面还举了亚马逊的例子，说亚马逊几乎不让人打客服电话，遇到问题机器人直接判定重新发货，压根不追问细节，这套逻辑背后是把决策权彻底倒向客户体验，然后用积累下来的数据反过来优化仓储和物流。他预测短期内客服体验反而可能变差，因为默认判给客户的做法一旦被规则化审视，用户得重新证明自己的诉求，而不是像以前那样理所当然地被优待。这个反直觉的判断我觉得特别值得记住，技术进步不一定线性地让体验变好，有时候会先经历一段拧巴期。

效率提升不会消灭工作，只会制造更多新工作

这一段可能是整期播客里格局最大的部分。Steven 提出一个观点，说技术转型期最容易犯的错误就是用线性思维去理解指数级的变化。工程师看到能自动化的东西就以为一切都会变得轻松可预测，然后大家就会陷入一种恐慌，觉得所有工作都要被 API 取代。但他们忘了效率提升本身会催生全新的场景，而不是让活儿变少。

他用报销这件事又举了一次例子，一开始什么都没有，后来大家学会用表格记账，再后来公司搭出一整套系统能做分析，紧接着差旅这件事就从单纯订机票变成了一个更大的课题，公司开始研究怎么用积分，怎么把差旅请求路由到最优价格，怎么用特定信用卡换取额外权益。原本订机票这件小事，最后演变成了一整套差旅优化甚至远程办公优化的新工作，规模比最初大得多。

Steven 还提到一个流传很广但因果关系存疑的例子，放射科医生很早就拥抱 AI 辅助诊断，结果现在反而出现放射科医生短缺。他说这背后原因很复杂，但恰好说明了创新从来不是静态的，市场需求也从来不是静态的。他还拿法律行业举例，说很多人以为 AI 会让合同变得更快搞定不再需要律师，可现实很可能是合同会变得更长更复杂，覆盖的场景比任何一个人能想到的都多，这反而会催生更多围绕合同的诉讼和新生态。

这段话对我冲击特别大。我们做内容创业或者做 SaaS 产品，经常担心 AI 会不会让自己的工作变得没有价值，但这场对话给了我一个新的角度去想这件事。效率提升带来的不是工作总量的萎缩，而是长尾变得更长，只是换了一种方式变长。就像我们做深思圈的内容生产，AI 能帮我们更快产出初稿，但这不代表内容这件事的工作量减少了，反而会倒逼我们去做更深度的选题挖掘，去做更精细的读者洞察，这些以前没时间做的事情，未来反而会成为新的核心工作。

MCP 和中间层为什么天生不稳定

Steven 在这段讲了一个我之前完全没想过的角度。他说这一整波关于 MCP 和 headless 的讨论，很大程度上是工程师视角在主导，工程师天然喜欢干净的 API，最好是一个命令行接口，文本进文本出，简洁又优雅。但现实世界根本不想这么运作，因为没有一个软件公司愿意甘心被架在中间层之上，被简化成一个只负责存数据的哑巴数据库。

他打了个比方，说客户其实并不想把自己的业务场景拼凑在一堆不同供应商之上，因为整个系统的稳定性最终取决于最不稳定的那一环。如果你依赖的某个报销小工具突然倒闭了，你就彻底陷入被动。所以客户嘴上说着讨厌某个软件越做越复杂，心里其实希望这家公司活得好好的，能持续给自己提供服务。而这些被中间层试图抽象掉的软件公司，也绝不会坐以待毙，它们会看看左边看看右边，把用户真正在用的新功能不断吸收进自己的产品里。SAP 周围长出的整个生态就是这么回事，很多创业公司不是在替代 SAP，而是在围着 SAP 打补丁，帮客户绕开它的复杂度。

我听到这里对 MCP 这类协议的理解一下子立体了很多。以前我总觉得只要标准接口做得足够好，各个系统之间就能无缝协作，但这场讨论提醒我，商业世界不是一张干净的网络拓扑图，每个节点背后都是一家想活下去、想增长的公司，谁都不甘心只做别人的数据后台。这也让我重新思考自己在做 Dashform 的时候要不要开放更多接口，开放到什么程度，因为一旦你把自己变成纯粹的数据层，就等于把议价权和成长空间都让了出去。

创业公司真正的机会在哪，我听完最有启发的一段

节目临近结尾，主持人抛出了那个所有人都关心的问题，创业公司现在到底该往哪个方向切入。Steven 给出的答案我觉得特别精彩，他说企业软件世界里最愚蠢也最难成功的做法，就是选择和一个现有品类正面硬刚，用同样的方式和现有巨头对着干。真正的机会永远藏在两个既有品类中间，因为技术剧变期，巨头唯一不会做的事情就是主动打乱自己现有的产品线和销售体系，它们只会把 AI 一层层贴到现有产品上，绝不会推倒重来。

他举了 HTTP 和 HTML 取代 client server 架构的例子，说 Web 之所以能赢，不是因为它把 client server 能做的事情全部做了一遍，恰恰相反，它几乎什么都没模仿，而是用一种全新的方式重新实现了同一个概念。他说创业公司的机会正是这样，不要去回答巨头那套二十年前定义出来、如今早已过时的问题清单，而是要敢于问一个只有自己能回答的问题，就是你存在的理由到底是什么。

Seema 补充了另一个我觉得很有洞察力的角度，她说除了在两个巨头中间找机会，现在还多了一层新的机会，就是在一个组织内部原本互不沟通的不同职能部门之间架桥。她提到 IT 预算这个例子，说 IT 部门和财务部门以前用的工具完全不通，后来云计算的出现才让两边第一次能一起做预测。她认为这种打通组织内部信息孤岛的产品是一个全新的品类，值得认真关注。

Steven 最后聊到网络效应的时候讲了个特别打动我的类比。他说企业软件领域外部的网络效应因为合规和安全原因极难实现，但企业内部的网络效应正在因为 chat 这种交互方式悄然发生。他讲了个八十年代 Excel 广告的画面，一群穿着老式西装戴着眼镜的银行家挤在电梯里，看着同事用当时那台十二磅重的笔记本电脑做表格，一个个瞪大了眼睛问这是怎么做到的。他说二零二五年的今天，同样的场景正在用 chat 重演，他有个在 SAP 工作的朋友写白皮书卡住了，他随口帮忙问了几句提示词就把白皮书生成出来发回去，他确信这背后悄悄启动了某种病毒式扩散，团队里的人开始看到工作原来可以这样做，然后自己也开始用起来。

他说这种能让组织里原本互不搭理的两个职能部门第一次真正对话起来的工具，价值巨大，这本质上是企业软件集成这件事从人工外包、找埃森哲这种重资产模式，变成了一种由 AI 驱动的轻量连接方式。Figma 当年在设计和产品开发之间搭的桥就是这个逻辑的先例。

我自己听完之后最想说的一句话

整期节目听下来，我最大的感受是，我们这个圈子讨论 agent 的时候太容易陷入一种技术乐观主义的幻觉，觉得只要接口够干净，模型够聪明，企业软件几十年积累下来的复杂度就能被一键抹平。但这场对话像一盆冷水，把我拉回了现实。真正难的从来不是查数据这件事本身，而是数据背后那套没人写下来的业务默契，是无数次例外处理堆积出来的组织智慧，是那些藏在老员工脑子里、连他们自己都说不清楚为什么这么做的判断力。

我越想越觉得，agent 时代真正的护城河可能不在于谁的模型更强，而在于谁能把这些散落在人脑里的隐性知识，用一种系统化的方式沉淀下来，变成 agent 真正能调用的上下文。这件事听起来枯燥，甚至有点反性感，但恰恰是这种枯燥的活儿，才是留给创业公司最扎实的机会。做出一个漂亮的 demo 从来不难，难的是让这套东西经受住十万员工、二十个国家、无数条例外规则的真实考验。

我想把这场讨论里最打动我的一点分享给正在做产品或者正在创业的朋友，别急着去想怎么正面颠覆一个巨头，先去想清楚你能不能站在两个巨头中间，用一种他们绝不会主动尝试的新方式，把某个具体的例外处理得漂漂亮亮。这可能才是这一整场 agent 浪潮里，真正留给我们的空间。