避开AI应用层的黄砖路上的死亡陷阱

我经常从创始人和求职者那里听到这样一个问题：现在还有没有任何 AI 应用层值得去构建？还是说 OpenAI 和 Anthropic 会把所有的机会都扼杀掉？

这个问题背后隐藏着一种特定形式的 AI 妄想症。有些人已经得出结论，要想避免成为永久的底层，唯一可靠的归宿就是进入大型 AI 实验室内部，或者去前沿领域从事机器人、硬科技等理论上“实验室触碰不到”的行业。如果所有的软件都即将被吞噬——要么是被 Codex 或 Claude 直接吸收工作量，要么是被未来的某个模型让你构建的一切变得毫无必要——那就赶紧跑吧！

听着，我和大多数人一样，是个十足的 AI 极大主义者，我认为他们只说对了一半。实验室确实正在向广阔的应用领域进军。但是，“应用层”并不是一个单一且同质化的机会。正确的视角是，你要看自己走的是“黄砖路（Yellow Brick Road）”，还是处于“奥兹国（Oz）”的其他地方。

“黄砖路”是我们用来指代实验室正在走的路的简称，他们在这条路上投入了极其庞大的资源。实验室之所以最适合解决代码生成、写作或图像创建等问题，是因为这些问题的效果会随着模型原始能力的提升而改善：在预训练和后训练上花费的每一块钱，都会提高产品质量。与此同时，奥兹国的其他地方则充满了更复杂、往往是垂直领域的问题。解决这些问题，不能仅仅是给业务用户提供一个带有标准工具和电脑使用权限的通用（水平）工具那么简单。这里的价值较少来源于底层模型的原始能力（尽管这仍然很重要！），而更多地来源于围绕模型搭建的“脚手架（scaffolding）”，这些脚手架使得输出结果在特定行业内变得可信、合规且可操作。

我们正在实时观察到这一现象的发生：OpenAI 和 Anthropic 实际上在告诉市场，他们无法用一个通用的 AI 同事来解决所有问题。他们已经宣布了大规模的前沿部署合资计划，专门组建整个公司来为企业配置和定制他们的模型。如果你认为下一次模型发布就能解决所有问题，你是不会把数十亿美元投入到这些项目中的。

因此，如果你想通过构建 AI 应用来致富——请避开“黄砖路”，去奥兹国的其他地方进行构建。以下是我们以及我们投资组合中的一些创始人所学到的，关于什么是真正行之有效的经验。

黄砖路 (The Yellow Brick Road)

如果你正在创业，“黄砖路”是最显而易见的路径，但也是最危险的。拿一个高性能的模型，接入一些现成的连接器（比如 G Drive、Slack、Salesforce、Notion、GitHub），然后在这个基础之上发布某种智能体编排层。见证奇迹！

这种做法的问题在于，这正是实验室在使用 Cowork 和 Codex 所做的事情。显然，他们拥有模型，这赋予了他们更好的利润率、控制力，以及对下游任何人施加定价权的能力。但也许最重要的是，他们还拥有决定其产品是为了解决什么问题而构建的架构选择权。到目前为止，他们在“模型+工具调用”的模式上一直非常谨慎，而这正是这条路上横向的、低步骤数量的工作所需要的。即使一家初创公司能以某种方式在性能上超越 Codex 或 Claude Code，实验室也拥有庞大的分销网络和 AI 领域最大的品牌光环。

如果你是一家 AI 应用公司，使用相同的连接器运行着相同的剧本，底层没有子智能体或特殊配置，也没有分销渠道，你很可能正在走向一条死胡同。

奥兹国的其他地方 (The Rest of Oz)

对初创公司来说，并非一切都是黯淡无光的。在黄砖路之外存在着巨大的机会，初创公司有清晰的路径去占领客户并解决复杂的问题。

这些企业正在构建智能体体验，在这些体验中，模型穿梭于由工具、自动化和集成（即：软件）组成的复杂网络中，这使得大多数这类初创公司默认就是垂直领域的。他们可以专注于多步骤和多角色的工作，为特定角色和特定垂直任务配备子智能体，这是 Anthropic 和 OpenAI 凭借通用（横向）平台无法触及的领域：跨系统收集上下文，然后将其路由给需要在不同阶段进行审批的多个相关人员。这通常涉及一个或多个遗留系统，倾向于需要结果的确定性（不能容忍模棱两可），并且有时与某些高价值的业务成果直接挂钩。实验室明白这些问题有多么宝贵：这就是为什么他们要建立自己的外包配置团队，也是为什么会出现一整个面向高端市场（upmarket）的强化学习企业群体。

为什么奥兹国的其他地方不会被“巫师”占据

对上述观点的一种反驳可能是：到目前为止，押注模型/实验室不会进步，一直是一笔糟糕的交易。他们很可能会继续变得更好，并最终蚕食这些应用层企业所服务的市场。

实验室当然会进步，但我认为，随着时间的推移，奥兹国的其他地方有几种方法可以保护自己：

数据和学习飞轮：

你所内化（吸收）的大量信息并不在任何训练集中——不成文的行业规范、未记录的标准，以及存在于从业者脑海中的部落知识。这些都不在公开的网络上。再多的训练算力，也无法替代深入这些知识实际存在的业务工作流中。这里叠加了两个飞轮：一个是跨客户的飞轮——当你看到同一问题的更多变体时，模式就会产生复利；另一个是客户内部的飞轮——特定决策背后的“为什么”、未言明的例外情况、以及只有通过与系统真实互动才能浮现的公司内部经验法则。

即使客户数据不能跨客户使用，应用公司也能利用跨客户问题类型的模式识别能力，并以此来指导未来问题的正确架构。一家让其智能体跑过一百次法律红线修改、一千次保险核保周期、或一万次 SDR（销售开发）活动的公司，已经内化了该问题的形态，后来者无法通过第一次启动一个全新的智能体来复制这种能力。

原则上，一个通用的横向智能体也可以构建相同的学习基础设施。它之所以不这么做（除了纯粹的专注度问题之外），原因在于用户体验（UX）：捕获这种知识完全取决于你提供给用户的工作流界面，而垂直领域的玩家可以完全围绕他们的工作流需要展示的内容来塑造这些界面。横向工具做不到这一点。评估（Eval）集、带标签的输出以及边缘案例分类体系可以复合成一个垂直领域专属的数据飞轮，这可以为微调（fine-tuning）提供燃料，而下一个进入者如果没有相当的生产环境暴露度是无法产生这些的。这是否可能取决于数据权利、积累的生产环境暴露量以及客户合同的结构，但模式识别的积累是必然会发生的。

管理模型的可变性和复杂性： 实验室已经在内部进行路由了——针对不同的请求使用不同的模型类别，底层使用模型集成。但他们做不到的是跨供应商路由，或者评估竞争对手的模型在特定子任务上的表现，或者在某些狭窄环节使用真正表现最好的开源微调模型。“奥兹国的其他地方”的公司会在整个模型市场中为每个子任务挑选最合适的模型，而不仅仅局限于其母实验室发布的产品。它还承担了没人愿意做的工作——每次新模型落地时，在升级时重新运行评估、针对客户的边缘案例重新校准提示词（prompts）、在不破坏生产环境的情况下进行部署。实验室不会代表客户做这些事；他们只会把下一个模型卖给你，然后叫你迁移。“奥兹国的其他地方”的公司则吸收了迁移的成本。客户得到的是整个市场上最好的智能，以及每次升级过程中的连续性。

成本优化： 把所有的查询都跑在 Opus 4.7（注：假设的前沿大模型代号）上是走向负毛利率的最快途径。最优秀的“奥兹国其他地方”公司会在不同层级的模型之间进行路由——前沿模型处理最难的任务，中端模型处理大头，而在他们有权使用的地方，使用较小的定制或微调模型。有些公司现在甚至在此基础上对自己的模型进行后训练，针对客户关心的狭窄工作切片对其进行优化，并以极低于前沿 API 调用成本的价格提供服务。实验室为底线定价：即 $X 价格下能提供的最低智能水平。而“奥兹国的其他地方”的公司兜售的是相反的理念——用最低的资金成本提供工作流实际所需特定水平的智能。这只有在你确切知道每个子任务需要什么水平的模型时才有可能，而实验室在架构上是不可能跨越每一个垂直领域去了解这些的。这就直接转化为更低的、可控的结果导向定价。

治理（Governance）： 成为客户在该垂直领域运行 AI 的“控制平面（control plane）”具有巨大的价值——权限、审计、智能体被允许做什么，以及智能体实际做了什么，都在这里汇合。这个控制平面是由针对特定用例的护栏（guardrails）构成的，这些护栏在不同的行业和工作类型中看起来截然不同。因为他们端到端地拥有工具、工作流以及智能体接触到的数据，他们能够以横向工具难以企及的方式提供确定性的结果。他们也是为最终买家吸收监管复杂性的实体——法律领域的 FRCP（联邦民事诉讼规则）和律师协会规则，医疗保健领域的 HIPAA，金融领域的 SEC 和 FINRA，各州的保险法规等等。一个横向玩家如果不同时变成一百个不同的垂直玩家，是无法令人信服地做到这一点的。CIO 们希望有一个合作伙伴，能在合同中明确声明他们正在为他们提供的智能体处理合规问题。

所有这一切都归结为一件事：专注。这可以是一个垂直行业（保险、法律、会计），也可以是一个深入钻研的职能（销售、客户支持、财务）。无论是哪种，这项工作都需要一个埋头苦干、专注于一组客户的团队——研究其工作流、其边缘案例、其法规。实验室不是为此而生的。他们必须无处不在，为所有人服务，这就是他们最初铺设“黄砖路”的方式。同样的权衡也把他们挡在了“奥兹国的其他地方”之外——你要么可以同时无处不在，要么可以在一件事上做到极致。鱼与熊掌不可兼得。

以销售为例——来自 11x 技术 CEO 的实用建议

在实践中，你应该如何思考这个问题？以下是来自 11x 首席执行官 Prabhav Jain 的一些实用建议。

关注结果

构建一家能抵御实验室冲击的公司的战术路径是：直接从你的客户真正关心的一个特定结果开始。对我们来说，就是帮助公司生成更多的销售漏斗（pipeline）。从那以后，问题就变得非常战术化了。我们想要端到端地掌控哪些真正能驱动销售漏斗的活动？将每个活动分解为任务。哪些任务是智能体化的，哪些不是。哪些需要复杂的领域洞察，哪些不需要。实验室也会发布工作流，但当工作流包含众多步骤、杂乱的输入、难以解释的状态或现实世界的约束时，单靠一个更好的模型是达不到目的的。这项工作最终落到了传统的软件工程上，而在这一点上，实验室面对一家专注的应用公司并没有任何优势。例如，以下是我们处理的一些任务，有些是智能体化的，有些不是：基于自定义信号的潜在客户开发、潜在客户信息丰富、深度的账户研究、从 CRM 获取上下文的抓取器、针对特定渠道的消息编写器、潜在客户资格审查智能体，以及电子邮件送达率系统。这些不是你可以一蹴而就的任务，需要深度的工程开发。

在“奥兹国”这个比喻中，一个关键的洞察是，在任何真实的工作流中，大约有一半是非智能体化的，而在这一半里，实验室没有任何优势。在编写模型层底层的确定性软件方面，他们并不比你强。而另外一半智能体化的部分，仍然需要你针对你实际想要的结果去调整、训练和约束模型。领域知识通常不存在于通用训练数据中。这些技能是为垂直领域或特定职能从零开始构建的，并在工作流的正确时刻输入到模型中。当我们的智能体在电话中对呼入的线索进行资格审查时，我必须被训练去了解针对那个特定行业和那个特定受众群体，什么样的销售对话才算是好的。这是应用公司的工作，并且它具有复利效应。

更重要的是，这些技能会经常过时，因为业务是在不断发展的，所以你进化这些工作流和上下文的能力就成了一种竞争优势。举个例子，当我们开始做规模化的电子邮件外展产品时，“AI”写的邮件刚刚开始流行。快进到今天，人们对 AI 写的邮件和人写的邮件已经有了敏锐的嗅觉，而关键是，这种情况每隔几个月就会发生变化。由于市场动态，我们的智能体必须不断适应，但这正是护城河建立的地方。事实上，尽管有这种动态变化，我们在过去几个月的积极回复率还是上升了 4 倍，我们已经为客户生成了数亿美元的销售漏斗。

在复杂性高的问题上做文章

复杂的问题才是真正能释放业务价值的地方。否则，你会发现自己只是在做一个“薄薄的套壳（thin wrapper）”。

分解任何足够复杂的业务问题，混乱就会迅速显现。这是一个来自 GTM（走向市场）领域的例子，听起来很琐碎：如果那家公司已经是你的客户，你就不应该去联系那家公司的联系人。但这绝非易事。也许你在 CRM 中有与该公司关联的域名。但是对于拥有数十家子公司的企业怎么办？如果 CRM 记录中只有母公司的域名怎么办？如果 Salesforce 中一个过时的匹配字段导致给现有客户的 CRO（首席收入官）发了一封冷推销邮件怎么办？现实世界的数据是杂乱的。人类处理起来都很吃力。模型也不会奇迹般地跨过这道坎。要想从这种混乱中理出头绪，需要针对问题的特定形态专门设计构建的智能体，而不是一个指向 CRM 的通用型 Copilot。事实上，基于我们拥有的数据，我们发现我们的数据质量和新鲜度远高于我们的客户，所以默认情况下，我们以自己的数据为锚点。

护栏不仅是为了防止坏事发生，那更是客户付钱给你的原因。

护栏的作用被严重低估了。即使在同一个产品内部，每个用例也需要自己的护栏。对我们来说，一个受监管的金融服务潜在客户所要求的保证，与中型市场 SaaS 客户截然不同，而这些保证会细化到：智能体被允许怎么写、它可以联系谁、它可以触碰什么数据、它在电话里能说什么，以及每一个决策是如何被记录的。

一个“一刀切”的系统会在这种差异性下崩溃。必须针对每个用例构建护栏，为每个客户进行配置，并进行持续审计，而这项工作完全由应用公司承担。这就是为什么我们有 FDE（前沿部署工程师）和技术部署策略师，他们需要针对每个客户的需求进行调整。作为一个例子，我们与一家财富 1000 强机构合作，通过语音向其庞大的 SMB（中小企业）客户群进行同意授权的外呼。最初的几次迭代接听率很低——我们必须快速迭代，了解如何让这种特定类型的受众在通话的前 10 秒内产生互动。SMB 企业主的行为与大型 B2B 买家或消费者截然不同。我们现在一天内为他们生成的销售机会，比他们整个针对该细分市场的销售团队一个月生成的还要多。

以保险业为例——来自 FurtherAI CEO 的实用建议

销售是一个例子。保险业是另一个，它从不同的角度阐述了相同的观点。以下是 FurtherAI 首席执行官 Aman Gour 关于在“避开主干道”构建产品时的思考：

当我们开始在真实的保险业务中部署 AI 时，我们不断听到一个特定的假设：模型就是智能，而工作流只是围绕它的脚手架。

我们合作的保险公司越多，我们就越确信这种看法是本末倒置的。

在保险业中，大量的智能就存在于工作流本身之中。两家保险公司在处理一份投保申请时，表面上可能走的是相同的路径：提交申请、审核、报价、承保生效。但路径只是最简单的部分。区分这两家保险公司的，是路径内部的所有细节：哪些风险会被升级处理，哪些损失信号是关键的，当两条风险偏好规则冲突时哪一条胜出，什么时候需要人工签字，需要引入哪些外部数据，以及最终的决定是如何被记录的。

这些逻辑并没有存在于一个干净利落的规则引擎中。它是分散在 SOP（标准作业程序）、经理的审查、核保理念、特定保险公司的风险偏好以及多年的运营经验之中的。其中很多内容并没有以一种模型可以直接读取的形式被写下来。

这就是为什么我们不相信那种每次都从头开始推理的纯粹智能体，我们也不相信那种一遇到现实的混乱就会崩溃的僵化工作流。相反，我们一直在构建“智能体化工作流”。工作流为你提供了可重复性、可审计性和成本控制。智能体处理变数，并在偏离理想路径（happy path）时进行恢复。而在责任归属至关重要的判断环节，人类始终保持在环路中。

在第一天，这可以自动化人工工作。但随着时间的推移，每一次升级处理都会成为一个信号，每一次例外都会成为反馈，每一次人工纠正都会显示出操作手册在哪里是不完整的。随着时间的推移，工作流不再是一个脚本，而是开始成为这家保险公司的运营记忆。这正是实验室发现难以触及的部分。他们会不断发布更好的模型和更好的通用智能体，他们也理应如此。但他们并没有在保险公司的生产工作流中待得足够久，以至于无法了解到：为什么一个账户被升级处理了，为什么一个风险被拒绝了，或者为什么一个核保员推翻了风险偏好指南并且这么做是对的。

这种理解只有在生产环境中，将工作流运行成千上万次后才能获得。你在第一天交付的工作流并不是护城河。生产环境的使用随着时间推移所创造的反馈循环才是。

对我们来说，这就是“在路外构建（build off the road）”的意义。

你如何判断自己是否处于“奥兹国的其他地方”？

工具和步骤测试（The tools-and-steps test）： 这项工作需要多少个步骤，你需要构建多么复杂的工具来支持它？比较一下这两者：在 Google Drive 中进行横向的 AI 搜索——一个步骤，针对一个工具，结果容错率高，用户阅读摘要，如果错了就重新问；与针对该所过去三年判例的多步骤法律红线审查相比——跨越多个工具的几十个步骤，输出结果必须通过合伙人的审查，并且可能需要在法庭上辩护。两者看起来都像是“一个智能体在做工作”，但只有后者需要一个专注的团队花费数年时间构建的深层软件。

系统测试（The system test）： 你构建的是一个客户将其工作运行在其中的“系统”，还是一个凌驾于他们现有系统之上的“工具”？系统端到端地拥有工作流——数据捕获、治理、完成工作的记录——它们是客户在描述实际工作如何发生时所指向的东西。另一方面，工具只是给客户已经运行的工作流增加了智能。工具案例能产生实际收入，但实验室可以抢走它，因为客户并不依赖你作为编排层。高 ACV（客单价/客户年度合同价值）通常是“系统”的信号，因为系统取代了实际的人头数（员工）并获得相应的报酬，但这不是绝对的保证。问问你自己：如果实验室发布了某种据称直接与你竞争的产品，客户还会需要你的工具吗？如果答案是肯定的，你构建的就是一个系统。如果答案是否定的，你就是一个工具——即使你的 ACV 很高。

对冲基金 / 损益表测试（The hedge fund / P&L test）： 实验室的性能是根据基准测试来评估的，而“奥兹国其他地方”的性能是根据你客户的 P&L（损益表）来评估的。你的客户不关心你的模型在 SWE-Bench 或 MMLU 上得分多高——他们关心的是你的智能体是否促成了交易、是否正确地审查了合同红线、或者是否签发了正确的保单。如果他们关注的是其工作流的特定结果，而不是一个通用的能力得分，那你就在“奥兹国的其他地方”。如果他们花钱买的是通用能力，那么你卖给他们的东西，他们买个 Claude 或 Codex 的席位也能得到。最好的智能体企业需要像对冲基金一样执行——依靠在客户损益表上衡量的超额收益（alpha）获胜，而不是基准测试的分数。

两者都可以（也将会）获胜

我们将会在“黄砖路”上和路上之外看到巨大的赢家。模型公司将继续获胜，因为他们拥有模型，并且拥有他们所设计的横向工具的分销渠道。

如果“奥兹国的其他地方”的企业能够拥有工作系统（system of work）——即公司实际执行工作的界面以及从中流出的数据被捕获的地方，他们就能获胜。这些公司拥有数据捕获、工作流行动系统以及治理权。随着更复杂的工作流在一个垂直领域中成熟，它们会复合成一种客户赖以生存的核心体验。当现有巨头和新进入者发布新一代模型时，这家应用公司就成为了将它们集成并交付给客户的连接层。底层的模型是可替代的（fungible）；而工作系统则不可替代。

下一代的企业软件将诞生在主干道之外。

如果你正在构建这样的产品，请联系：jschmidt@a16z.com。

本通讯仅供参考，不应作为法律、商业、投资或税务建议依赖。此外，本内容不构成投资建议，也不得供任何投资者或 a16z 旗下任何基金的潜在投资者使用。本通讯可能链接到其他网站或包含从第三方来源获取的其他信息——a16z 未独立验证，也不对这些信息的当前或持久准确性做出任何陈述。如果本内容包含第三方广告，a16z 未审查这些广告，也不认可其中包含的任何广告内容或相关公司。提及、提到或描述的任何投资或投资组合公司并不代表 a16z 管理的工具中的所有投资；请访问 https://a16z.com/investment-list/ 获取投资的完整列表。其他重要信息可在 a16z.com/disclosures 找到。您收到本通讯是因为您之前选择了订阅；如果您希望拒收未来的通讯，您可以立即取消订阅。

---

重要术语及翻译对照表

英文原文	中文翻译	上下文含义及备注
Application layer	应用层	位于底层AI大模型之上，直接面向用户提供服务的软件层。
The Yellow Brick Road	黄砖路	文中隐喻，指代大型AI实验室主导的、显而易见的横向通用大模型发展路径（源自《绿野仙踪》）。
The rest of Oz	奥兹国的其他地方	文中隐喻，指代除了大厂主导的通用路径外，初创公司可以深耕的垂直、复杂的应用领域。
Horizontal / Vertical	横向（通用） / 垂直（细分）	Horizontal指适用于多行业的通用工具；Vertical指针对特定行业深度定制的解决方案。
Agentic / Agent	智能体化的 / 智能体	具备自主规划、工具调用、任务执行能力的AI系统。
Scaffolding	脚手架	围绕基础模型构建的辅助代码、规则、工具链和工作流，用于确保AI输出的可控和可用。
Flywheel	飞轮 / 飞轮效应	指数据、产品体验和用户规模之间相互促进、产生复利效应的良性循环。
Orchestration layer	编排层	负责协调多个智能体、模型和工具执行复杂多步任务的系统层。
Forward-deployed (FDE)	前沿部署 / 驻场部署	指将工程师直接派驻到客户业务一线（或针对特定客户高度定制），以解决实际业务部署难题。
Control plane	控制平面	在IT架构中负责管理、配置和审计AI系统权限与行为的集中控制中心。
Guardrails	护栏	为防止AI产生不当言论、错误操作或越权访问而设置的规则和安全边界。
ACV (Annual Contract Value)	客单价 / 客户年度合同价值	SaaS和企业软件中衡量每个客户平均每年带来收入的核心指标。
System of work	工作系统	承载企业核心业务流转、数据沉淀和业务规则的端到端系统。