发票软件只覆盖了这份工作的 20%：采购 agent、四类 agent 分类法，以及"在位者不是在收手，是被按住了"（a16z / Lio，2026-10-02）¶

嘉宾: Vladimir Keil（Lio 联合创始人兼 CEO，企业采购 agent；公司创办于 ChatGPT 发布前数周，纽约 + 慕尼黑两地）
同场: Seema Amble（a16z 企业软件合伙人，本期讨论的是她那篇《The Incumbents Are Coming》；a16z 是 Lio 投资方）
主持: Elena Burger（a16z）
来源: YouTube · 59 分钟
转录稿: sources/a16z/20261002-OTQ-lFsq7zA

⚠️ 人名与公司名还原（自动字幕，均据视频简介订正）：Seema Amble（字幕作 "Sema Amble"）、Elena Burger（"Elena Burgerer"）、Vladimir Keil（"Vlad Kyle"）、Lio（字幕全程作 "LEO"/"Leo"，公司官网 lio.ai）。 ⚠️ 其它术语还原：ChatGPT → "CHBT"/"JGBT"、ERP → "EIP system"、evals → "evils"、harness → "hardness"、Decagon → "Dakagon"、McKinsey → "McKenzie"、Coupa → "Koopa"、Granola → "granola"、Pareto → "parto"、index/指数 → "indicy"、forward deployed engineers → "FTDES"、a16z → "A6"、zero-sum → "zero something"。 ⚠️ 一处关键还原：[00:02:00] 那个"cloud force——把 cloud 加 Salesforce 拼在一起"，⚠️ 本库判为 "Claude + Salesforce" 的合成词（自动字幕把 Claude 听成 cloud 是本库常见错误），但照录字幕原文并标为还原。 ⚠️ 两处字幕明显损坏：① [00:26:14] "比公司间采购大得多，更像是 intra company"——按上下文应是 inter（企业之间），字幕的 inter/intra 用反了；② [00:36:18] 第一次提到那个模型时字幕作 "Jeff"，[00:37:19] 第二次作 "Jev"——本库据第二处判为 Jev（TypeSafe 的 system one 模型，本库已有两期材料）。

⚠️ 本页的利益相关声明：这是投资方频道访问自己的被投公司（Amble 在期内被点明写了《Investing in Lio》）。公司的全部业务声明——全自动跑通的采购流程、10 万次谈判、85% 工程师占比、"我们三年前就解决了笔记本和铅笔"——都是自述，本库一条未核实。

✅ 但本页认为它的价值不在那些声明，而在三段本库此前没有的东西：① ⚠️ 一个此后可以反复用的 agent 分类法（retrieval / process / policy / principal），以及"在位者为什么卡在前两档"的组织解释；② ⚠️ 一条把"例外处理就是护城河"量化了的一手数字：发票软件 = 这份工作的 20%；③ ⚠️ "自建能到 70%，但 70% 的性能不等于 70% 的自动化"这条判据，本库认为是目前对"企业要不要自己建"最锋利的一句。

概要¶

⚠️ 本期最该被长期引用的一条框架（[00:06:01]–[00:08:02]）：Amble 把 agent 按所需判断力分成四档——retrieval（检索）→ process（流程）→ policy（政策）→ principal（委托人）。她用同一个"服务中断要赔偿"的例子走完四档：检索档调出合同条款、确认中断发生过；流程档按政策手册走完信用额度审批并出账，"不涉及判断"；政策档开始要判断——"中断了 20 分钟，这够不够算一次重大中断"，因为这件事本来没有严格定义；委托人档则是"这次中断很糟，为了保住关系，我们是不是该给超出流程和政策的补偿"。
⚠️ 而她对在位者的定位是本期最有结构价值的一句（[00:08:02]）："大多数在位者即使有，也是从第一档开始的。现在它们至少在营销上说自己正在往流程和政策档走。" 但看它们实际发出来的东西——"帮你把一份文件签掉、或者从一份转录里录入信息，这类工作流 agent"——"它们很大程度上仍然限于检索加一点流程。它们还没进到更多判断里。"
⚠️ 她对"为什么进不去"的回答是一句很好的改写（[00:09:03]）：主持人问"为什么有些在位者在收手（holding back）"，她的纠正是："我会说它们是在收手，但它们是被按住的（they are held back）。" 两条原因：① 分发与信任的优势反而是包袱（Agentforce 发布时客户很容易就签了，"尤其当它几乎不额外收钱的时候"）；⚠️ ② 内部激励冲突——"如果你开始做更复杂的 agent，这就和一个现有产品发生内部冲突：那个产品提供的是工作流，而你在做的是把这份工作解掉。"落点很具体："端到端解掉一个客服问题，和给一个人类客服提供工作流，这是两个不同的买家。" 两个 VP、两个组织、两条产品线——"它们永远搞不清正确的激励该怎么设、该卖给谁。"
⚠️⚠️ 本页认为全期最硬的一条一手数字，是一个把"例外处理"量化了的比例（[00:12:04]）：他们做发票 agent（检索信息 → 跨文档比对 → 推回 SAP 或 Oracle）时发现，"那就是整个软件市场的 100%——那就是发票软件，那就是今天人们怎么建它的。" ⚠️ "但它其实只占这份工作、这个待办任务、这个问题的 20%。因为 80% 的问题是：万一这张发票是欺诈的？万一有不匹配？万一我们不走 happy path？" 所以流程 agent 对他们反而成了"支线任务"，他们很快转去做例外处理。
⚠️ "系统记录里看到的那个数，和实际发生的工作量，差了两个量级"——这是本期的主旨（[00:04:00]–[00:05:00]）：ERP 里是"铝 8K"，而看不到的是：供应商曾回推要 10K、一个成本工程师跑了三周 Excel 和 3D 建模去算这个零件该多少钱。他拿销售侧做类比：一份合同签字看起来很简单，但背后大概发生了 30 场利益相关方会议、500 封邮件、20 张 Excel。⚠️ 结论："采购里大部分工作其实发生在 ERP 或任何系统记录之外。"
⚠️ 而那个"错过一封邮件就是上亿美元"的场景，本页认为是全期最具体的一个损失机制（[00:23:11]）："有人发来一条确认：抱歉，这个零件会晚两周到。而这是一个采购经理 Outlook 或 Gmail 里 500 封邮件中的一封。如果他们漏了这封邮件，上亿美元的损失就造成了。而这件事经常发生——因为他们在系统记录里存的唯一东西就是一个日期：不是这个星期三，是下个星期三。系统里你看到的就是这个。但你看不到的是，也许这没事，也许这是一个亿美元的损失，而需要有人来判断这件事。"
⚠️ "要不要自己建"这一问的答案，本页认为是全期最锋利的一条判据（[00:40:19]–[00:41:20]）：他先把门槛主动降到底——Lio 三年前那个"把报价单的信息录进 SAP"的首个爆款用例，现在是 Lio 的招聘作业题，"我们把它给候选人，他们有 8 小时来做"。 ⚠️ 然后给出那条反问："是的你能在 8 小时里建出来，但你只能做到比如 70% 的性能。而问题是：70% 的性能或准确率，并不意味着 70% 的自动化。你可能有 70% 的性能，但你仍然需要做 100% 的工作，因为 70% 不算多——所有人还是得去核对数据。所以也许你甚至制造了比以前更多的工作。"
⚠️ 而 Amble 给这条配了一个一手案例，本页认为比论证本身更有价值（[00:42:22]）：两三周前她和一家 Fortune 500 的管理层聊，对方试着自建一个催收（cash collection）产品，"至少干了三四个月"后发现：上下文不够、上下文质量差（"有很多录音、很多截屏，他们想把这些拉进一个系统里，但就是不够好"）；⚠️ 然后撞上一个更大的问题——"我们现在有两套不同的 ERP，而且我们正要再收一家。谁来更新所有这些映射、谁来测它到底能不能跑？" 而例外处理还得再往一套完全不同的系统上重新映射一遍。她的结论："他们很快意识到自建不合理……这和企业一直在试的那种 DIY 没有区别。"
⚠️ 他对"外部信任"的论证，本页认为是本库在"企业为什么会把权限交给 agent"这个问题上见过的最具体的一条路径（[00:16:06]–[00:17:07]）："没有一家公司、没有一家企业是从第一天就上全自动谈判 agent 的。没人这么干。为什么？因为它们第一天既不信任我们，也不信任这项技术。" ⚠️ 而 human-in-the-loop 对他们是双向有用的："我们有一个整体上完美的采购谈判者，但我们并不确切知道一家 Fortune 10 企业——那家具体的 Fortune 10 企业——是怎么运作的。通过人在环里这套做法，我们把所有反馈和所有习得喂给我们的 agent，然后它们就突然信任我们去跑 1 万次谈判、2 万次谈判、10 万次谈判了。"
⚠️ 一条很反直觉的风险论证，本页认为值得单记（[00:18:08]）：对"以前根本没人谈的那部分支出"，部署 agent 的风险基本为零——"企业在 agent 之前、在 Lio 之前，对 5 万以下的一切就是不在乎，因为它们没有这个人力。" ⚠️ 他甚至把这当成一条给别人的提示："这也许是给其它创业公司的一个 hack——你可以直接给一家企业开一张 4 万的发票，它们大概不会来谈，因为它们没有这个人力。除非它们有 Lio 的 agent，那我们就会来和你谈。" 落点："那么现在有一个糟糕的谈判 agent 的风险是什么？基本为零。我们也许会错过一些谈判，但这比什么都不做好。"
⚠️ "两边都上了 agent 会不会变成零和"——他的回答是本期最好的一条结构论证（[00:47:28]）："价格是 5000 件其它任务的结果，而在那 5000 件其它任务上，双方的激励是完全一样的。销售想要尽可能少的摩擦，买方想要非常快的上市时间。" 他举的例子回到建数据中心："你想让这个数据中心尽可能快地建起来，你不想因为分析供应商的回复太费时间而晚六个月。而你也想让这笔销售快点成。"
⚠️ 他对"harness 够不够"的回答把边界划在一个很具体的地方（[00:34:17]–[00:37:19]）：基础模型他明说当成大宗商品（"我们用所有供应商的多个模型……它们有非常好的通用业务能力"）；有些用例"把基础模型和 harness 组合起来可以走得极远，也许能到这份工作的 100%"；⚠️ 但另一些用例"你可以有最好的基础模型、最好的 harness，还是只能到 80%"。他给的两个例子是 should-cost 建模（成本工程师看图纸判断这个零件该值多少）和价格对标——而卡点是数据："所有这些信息都不是公开可得的，它们都是基于某一家企业、或者跨多家企业的专有数据，所以通用模型没法在上面训。"
⚠️ 而他给出的方向，本页认为是本期最该被交叉链接的一条（[00:36:18]–[00:37:19]）："也许不是训一个 LLM，而是像现在冒出来的 Jev 这类模型在做的——你用文本数据训它，但输出其实是一个结果，或者就是那个完美的价格。" ⚠️ 他对"为什么 harness 做不到"的解释非常具体："如果你给我一份 BCG 的报价和一份麦肯锡的报价，它们可能做完全一样的工作，但价格可能差 10 倍，而我完全不知道哪个更好。可如果你把它给一个采购经理，他一上手就会有一种直觉。" 而直觉写不成规则——"如果你让他们把规则写下来，他们做不到，因为那就是直觉和本能。"

核心观点¶

一、⚠️ 在位者问题：Amble 的三方格局，以及四类 agent 分类法¶

来源：a16z / Lio

⚠️ 她先把问题的形状改了一次，本页认为这个改写本身是本期最有价值的框架贡献（[00:02:00]）：传统上是"在位者 vs 创业公司"，即"分发 vs 创新之争"（她注明这是她同事 Alex Rampell 的说法）。而现在多了第三块：在位者可以把一个模型叠上去。 于是市场上出现"一个强悍得多的竞争者"——"那你为什么还需要一家 AI 原生创业公司？如果你已经有了 Claude 加 Salesforce 拼起来的那个东西，你的数据都在那儿、你的员工都已经习惯用那个产品了，为什么还要另一个产品？"（⚠️ "Claude" 为本库还原，见页首标注。）
⚠️ 她给的答案只有一条，而整期都在验证它（[00:02:00]–[00:03:00]）："遗留在位者被限制在它们的系统记录、以及它们手上那份记录里，而它们没有把端到端的那份工作做完。"
她的例子：客户打来说取消之后还被扣费了。要解掉这件事，不只是客户在 chat 里说"我被多扣了"——"它得打到计费、得看全部聊天记录、得看合同。那不是一个系统记录，那是围绕这个客户的知识以及它触及的一切。"
⚠️ 于是创业公司的机会被定成一句话："我们要拥有整条端到端的弧。" 她在法律侧给的类比是"从立案摘要一路到庭审，全都拥有"。
⚠️ 四类 agent 的完整分档（[00:06:01]–[00:08:02]），本页认为这是此后引用这一期的主要理由：
她先回顾了一年前的状态，并给了一个很好用的标签："我做过一个梗叫'拍个聊天机器人上去'战略（the slap on a chatbot strategy）"——在位者基本上就是在系统记录上面架一个聊天机器人，你可以和它对话来检索信息，也许做点轻量分析。
① retrieval（检索）：调出合同条款说的是什么、确认中断确实发生过、把信息拿回来，也许做点综合。 "它在数据库里，它就是把这些分享回来。"
② process（流程）："按我们的政策手册，它从这些日期起中断了，因此你有权获得赔偿"，然后它就能把账单应用上去，把流程走完。 ⚠️ "不涉及判断。"
③ policy（政策）："不只是应用流程，而是会说：在这个情形下它中断了 20 分钟，那够得上算一次重大中断。" ⚠️ "而它们在施加判断，因为这件事本来没有一个严格定义。"
④ principal（委托人）：⚠️ "你其实在权衡：我们是不是该给更多补偿，因为那次中断相当糟糕，而我们想保住这段关系，所以值得做得比流程或政策规定的更多。"
⚠️ 本页标注这套分档为什么有用：它把"agent 能做什么"的刻度换成了"需要多少判断力"，而判断力恰好是本库此前反复撞上的那条边界。⚠️ 对照 Diogo Almeida 的可靠性四层：Almeida 分的是"做出来的东西好不好"，Amble 分的是"这件事需要谁来拍板"——本页认为两套刻度正交而非重合，合起来比任何一套单用更完整。
⚠️ "holding back vs held back"：在位者的两条约束（[00:09:03]–[00:10:04]）
第一条看起来是优势：分发 + 客户信任 → 更容易把更多产品卖给同一个客户。她举 Salesforce 的 Agentforce："客户很容易就说，行我签这个 Salesforce 的 agent——尤其当它几乎不额外收钱的时候。"⚠️ 本页标注：这条同时解释了为什么在位者的 agent 采用数字看起来很高，而深度可能很浅。
⚠️ 第二条是本页认为更该被记住的那条，因为它是组织性的、不是技术性的："如果你开始做更复杂的 agent，这就和一个现有产品发生内部冲突：那个产品提供的是工作流，而你在做的是把这份工作解掉。" 买家不同（端到端解掉客服问题 vs 给人类客服提供工作流），于是是两个 VP、两个组织、两条产品线——"它们永远搞不清正确的激励该怎么设、该卖给谁。"
她对在位者在做什么的描述（[00:09:03]）：有些在"和 OpenAI、Anthropic 这些实验室之一合作，拿那个模型能力来补足并加强它们已有的东西"。
⚠️ 而嘉宾从外部补了一条她没说的信任方向（[00:11:04]–[00:12:04]）："你说的是内部信任，我觉得还有一个外部信任的问题。" 从"检索信息、也许跑跑流程"走到"完全自主做事"，"显然有产品的成分，但主要是人的成分。他们得信任你。" ⚠️ 他给的不对称很锋利："我们作为一家创业/成长公司必须去赢得信任。在位者已经有信任了——但这也意味着它们可以毁掉信任，如果它们发得太早、产品不work、或者做出糟糕的决定。"

二、⚠️ 发票软件 = 这份工作的 20%：把"例外处理就是护城河"量化了¶

来源：a16z / Lio（[00:12:04]–[00:13:04]）

本页认为这是全期最有引用价值的一条一手数字。

他们做的那个"清晰流程"：检索一些信息 → 跨其它文档做比对 → 推回 SAP 或 Oracle。"一个非常清晰的流程。"
⚠️ 然后那个发现："然后我们搞明白了：好，那就是整个软件市场的 100%——那就是发票软件，那就是今天人们怎么建它的。但它其实只占这份工作、这个待办任务、这个问题的 20%。因为 80% 的问题是：万一这张发票是欺诈的？万一有不匹配？万一我们不走 happy path？"
⚠️ 于是流程 agent 对他们成了"支线任务（side quest）"，他们"非常快地转向了 agent 的下一步，也就是做那些例外处理"。
他们的推进方式他自己说带着运气（[00:13:04]）："我觉得我们运气好，一直稍微领先曲线一点，所以我们能去 pitch 下一代 agent。" 节奏是先 pitch → 确认这是个真问题、是个他们愿意付钱的真用例 → 几周后把它交付；他说三年前"仅仅是检索一份文档"在当时"疯狂地令人印象深刻"，而现在他们对流程 agent、全自主 agent、长时运行 agent 在做同样的事。
⚠️⚠️ 本页认为这条必须和 Amble 自己三个月前的框架并读，因为它是那条判断的一手量化：她在 2026-07-07《Software in the Age of Agents》里的核心判断就是"护城河 = 例外处理"。⚠️ 而这一期是本库第一次看到一个创始人给这条判断配上比例：happy path 是软件市场的 100%，却只是问题的 20%。 本页标注：这个 20/80 是单一公司在单一品类（发票）上的自述，不是行业测量，但它的形状与 Steven Sinofsky 的"例外处理"、Decagon 的 90% 开源 + Duet、Almeida 那条"按唯一性重算只有 50% 左右，剩下全是改密码" 三处一致。
⚠️ 而 Almeida 那条恰好是反方向的同一现象：他指出宣称的自动化率被重复工单虚高；这里指出宣称覆盖的流程只覆盖了简单路径。两条合起来，本页的判断是：企业 AI 的"覆盖率"这个指标在两头都被高估。 详见 AI 的商业模式与价值捕获。

三、采购到底是什么：本库第一份"实体世界采购"的运作描述¶

来源：a16z / Lio

⚠️ 他先把范围划清，而这条划界本身说明了这个品类的分层（[00:21:08]）："我们说采购的时候，不是在说笔记本和铅笔——那个 Lio 的 agent 也解，但那很容易，我们三年前就解决了。" 他们说的是造飞机、造机器人、造无人机，⚠️ 以及"我们现在正在做一期关于 AI 热潮的播客——可 AI 也是要被造出来的，所以：数据中心。"
规模（[00:22:11]）："如果你要造一架飞机，你需要采购数千家供应商。你还得建一座工厂来造这架飞机。" 而"非常小的摩擦可以有疯狂的影响"——"一个具体零件晚两周到，这可能造成上亿美元的损失并让项目延期。"
⚠️ 那条"500 封邮件里漏掉一封"的损失机制见上文概要（[00:23:11]）。本页在这里只补他的落点："所以我们的 agent 不只是检索信息，它们还要做决定——这件事有影响吗？什么样的影响？我们怎么解决？"
⚠️ "实体世界里哪些事能干预"——他的回答把问题换成了概率（[00:24:11]–[00:25:13]）：
"显然你改变不了船上出了损坏这件事，但如果你有全部上下文，你可以预测它。"
⚠️ 他给的那个取舍例子很具体："你有一家供应商 20% 的货会缺，另一家 1% 会缺。而那家 20% 的便宜 10 倍。但对这个用例，你付 10 倍的钱是合理的——因为这东西真的会到的概率更高。"
⚠️ 而上下文的范围被他推到企业之外，本页认为这是全期在"agent 需要什么上下文"上最大胆的一条（[00:25:13]）："不只是一家企业内部的上下文，还有外部世界的上下文——agent 应该有外面所有新闻的上下文，甚至也许有 Polymarket 上某些赌注的上下文：好，这些中断会发生。" 再加上供应侧、卖方侧、需求侧的信息。他的落点是一句很强的声明："长期来看我不会说这里存在限制。" ⚠️ 本页记为愿景而非能力声明。
⚠️ "谈判不只是价格"这一条拆得很清楚，而它正是 Amble"出盒子"论证的具体版本（[00:20:08]）：合同怎么设计 = 法务；回款怎么设计 = 财务；成本结构 = 成本工程；商务条款 = 采购。 ⚠️ 而他对这些人的定性值得记："这些不是后台人员。这些是受过高度训练的人，他们掌握着一家非常具体的公司、一个非常具体的行业、一个非常具体流程的非常具体的知识。"
Amble 的总结："采购历史上也许更像是装在一个盒子里的，而现在它触及法务、触及财务、触及一堆不同的软件系统和人，既有专家也有更通才的人。"
⚠️ 多 agent 系统为什么是必需的，而不是时髦（[00:26:14]–[00:27:15]）："为了端到端做完一份工作，这些 agent 需要互相共享信息，而且要按一个非常具体的顺序做。" ⚠️ 他给的量级是本页记这一条的理由："人这边的同一份任务涉及 8 个人、8 个利益相关方，也许 3 个部门和 5 个不同的软件工具。我们需要覆盖所有这些才能端到端做完这份工作。" 演进路径是检索/copilot（三年前）→ 单 agent → 多 agent，而转折点很具体："我们很快发现，你没有一个合同 agent、没有一个看新闻的 agent，连一次谈判都解不了。"
⚠️ "一颗螺栓"的端到端流程，本页认为这是本库目前最完整的一条企业 agent 工作链（[00:28:15]–[00:30:16]）：
起点本身就很难："有人有一个需求，而连这一步都极其复杂——你也许是个建筑工人，你每两周才打开一次笔记本电脑，而现在要求你去用 SAP 或别的 ERP 系统。你连这个需求都发不出来。" ⚠️ Lio 的做法是把入口降到最低：拍一张照片、上传一份报价单或一张 Excel。
⚠️ 而他对此给了一句本页认为非常好的产品判断："这其实就是你应该知道的关于采购的全部了——采购部门之外，没人在乎品类、GL 科目、框架合同。没人在乎。我们采购的人会在乎，但部门外没人在乎。"
然后 agent 接手：查库存 → 问另一个厂区能不能内部调货 → 叫 sourcing agent 查内部/外部供应商 → 另一个 agent 起草 RFQ 并通过邮件发出 → 回来一堆邮件（有些完全是废话，有些正文里，有些是 PDF，有些是 Excel）→ 把信息抽出来 → 基于价格对标判断有没有谈判空间 → 由 agent 决定下一步：带人在环的战略谈判 / 自主谈判 / 竞拍与电子竞拍 → 调用对应的 agent 去谈 → 确认订单、追踪发运、处理发票。
⚠️ 他对机会的两面切分，本页认为是全期最该被迁移到别的品类的一条思路（[00:30:16]–[00:31:16]）：
一面："他们一天做一千次、但其实一天想做零次的事是什么？" → 这里要的是全自主跑通（自动化）。
⚠️ 另一面："他们一天做零次、但如果一家企业一天做一千次就会有疯狂 P&L 影响的事是什么？" → 这里要的是在从没谈过的那部分支出上做自主谈判。
⚠️ 本页标注：前一面是替代人力，后一面是创造以前不存在的活动——而后者的风险论证（见概要里的"基本为零"）恰恰来自"以前根本没人做"。
indirect 与 direct 的分野，以及为什么自主程度必须不同（[00:31:16]–[00:32:16]）：
indirect（间接）：MRO 零件、建厂、那颗螺栓、笔记本和铅笔、营销服务、搭一个播客录音棚。可能涉及5 万家供应商。
⚠️ direct（直接）：真正用来造那架飞机/无人机/机器人的供应商——"我们不说 5 万家供应商，我们说 100 家或者最多 2000 家。而这些是极其具有战略重要性的。你在一家供应商上可能有 10 亿的支出。"
⚠️ 所以："你不会想跑一次自主谈判。你会想跑一次持续三个月的谈判，而且你准备得疯狂充分"——团队里有工程师在分析"铝的指数是多少？油的指数是多少？价格怎么变的？"，并接手所有那些图纸、检查零件质量。
而这类谈判 agent 明确是"后台"（[00:32:16]）："90% 的工作是准备。" ⚠️ "你在系统记录里看到的最终结果是：哦，本来 10 亿，我付了 9 亿。但那背后是三个月的准备和 10 个人全职干这件事。"
⚠️ 而他给了一个实时辅助的用例，本页认为是全期最具体的一个"agent 在谈判桌上"的画面（[00:33:16]–[00:34:17]）：谈判过程中屏幕上弹出实时洞察——对方说"油的指数涨了 10%，所以我们要把价格提 10%"，而弹窗立刻给出：⚠️ "那是真的，油涨了 10%，但这个产品只含 30% 的油，所以你不该提 10%，也许只该提 4%。"

四、⚠️ harness 的 80% 天花板，以及为什么他指向了 Jev 那类模型¶

来源：a16z / Lio（[00:34:17]–[00:37:19]）

基础模型被他明说当成大宗商品："我们用所有供应商的多个模型，我们真的把它看成一种大宗商品。它们有非常好的通用业务用途——读 PDF、生成 PDF、生成 Excel，所有这些东西。"
⚠️ 而边界被划在一个很清楚的地方：有些用例"把基础模型和 harness 组合起来可以走得极远，也许能到这份工作的 100%"；⚠️ 另一些用例"你可以有最好的基础模型、最好的 harness——不管那是什么意思——还是只能到 80%"。
他给的两个 80% 用例：
should-cost 建模：成本工程师分析图纸，然后定义"这个零件实际上该花多少钱"——"所以它叫 should cost modeling"。
⚠️ 价格对标："理想世界里你就把报价单拖进去，然后拿到完美的价格。但所有这些信息都不是公开可得的——它们都是基于某一家企业、或者跨多家企业的专有数据，所以通用模型没法在上面训。"
⚠️ 他给的方向，本页认为是本期最该被交叉链接的一条（[00:36:18]）："也许不是训一个 LLM，而是像现在冒出来的 Jev 这类模型在做的——你用文本数据训它，但输出其实是一个结果，或者就是那个完美的价格。"（⚠️ [00:36:18] 字幕作 "Jeff"、[00:37:19] 作 "Jev"，本库据第二处判定。）
⚠️ 而他对"为什么 harness 做不到"的解释是本页认为全期最好的一个认识论例子（[00:36:18]–[00:37:19]）：
"如果你给我一份 BCG 的报价和一份麦肯锡的报价，它们可能做完全一样的工作，但价格可能差 10 倍，而我完全不知道哪个更好。可如果你把它给一个采购经理，他一上手就会有一种直觉。"
他的第二个类比："我不知道该付多少钱给一个做视频的人，但这背后有一种直觉。如果你问另一个视频创作者怎么判断——可如果你让他们把规则写下来，他们做不到，因为那就是直觉和本能。"
⚠️ 落点：所以机会在"训一个 agent，但也许不是经典的 LLM，而更确切地说是像 Jev 这类模型现在在做的那样——基于结果（outcome based）"；他点名的两个目标就是 价格对标 + should-cost 建模。
⚠️⚠️ 本页认为这是本库里一次很有价值的三方汇合，值得单独标注：
⚠️ TypeSafe / Jev 自己的口径是"让代码而不是人来消费模型"、system one 模型、RLCD、反公开基准；⚠️ Almeida 在 a16z 那期的口径是 smart software、prod not god。
⚠️ 而这是本库第一次看到一个第三方应用层创始人，在完全不同的垂直里，独立地把 Jev 那类模型指认为自己 80% 天花板的解法。 本页认为这提高了"system one 模型"这个类别的可信度，因为它来自需求侧而非供给侧。
⚠️ 但本页同时标注两条限定：① 他只是"在思考、已经开始微调"，没有给出任何已兑现的结果；② 他和 Almeida 同在 a16z 的内容生态里（两期都是 a16z 频道），⚠️ 所以这不是一次完全独立的佐证。
主持人在这里提到的行业背景（[00:34:17]）："我们知道像 Harvey 和 Decagon 这样的公司现在真的在微调模型。" ⚠️ 本库此前关于 Decagon 的材料记的是"90% 开源 + Duet"，与"在微调"一致，但那期没有用"微调"这个口径。本页记为一处可对照的措辞差，不构成矛盾。

五、⚠️ 什么是耐久的垂直 AI 公司：Amble 的答案是"别去预测护城河"¶

来源：a16z / Lio（[00:37:19]–[00:39:19]）

她列的三条质素：拥有端到端的那份工作、积累起一份数据资产、做一件此前没被做过的事。
⚠️ 但她紧接着做了一次很反常的否定，本页认为这是她在本期最该被引用的一条："说了这么多，我觉得当你大谈护城河的时候——其实非常非常难去前瞻性地预测你的护城河。如果你回看所有最好的生意在早期阶段，它们想的只是'我在赢得客户信任、我在卖更多给他们、而且机会很多'，而不是'我要走这六步、然后走到第七步、然后我们就有护城河了'。"
⚠️ 她给的可观察信号是"依赖"而不是"壁垒"："一部分是你在锁住客户——依赖更多了，他们觉得有价值，而你在做更多的工作。" 她的对照很具体："老的 CRM 公司是所有交易的记录本。新的销售 AI agent 其实拥有了很大一部分销售准备流程和外呼流程，接住 inbound 并做掉一堆工作。整体上客户依赖那个产品——而这是通向护城河的一个非常重要的信号。"
⚠️ 而她把流行词全部降格为二阶产物："我们谈的所有关于黏性、网络效应之类的东西，都是那个最初的客户使用和产品价值的下游。"
⚠️ 本页交叉标注：这条与本库 Michael Lee 的"买下在位者再重新创办它" 是同一问题的两条相反路径——⚠️ Lee 的路径是"把分发买下来再换引擎"，Amble 的路径是"用端到端的工作把依赖造出来"。 本页不裁决，但指出一条可比较的判据：两条路径都把"分发"当作稀缺项，而对"谁更容易拿到判断力"给出了相反的答案。 详见 AI 的商业模式与价值捕获。

六、⚠️ 前置部署（forward deployed）这一层：目标是把自己自动化掉¶

来源：a16z / Lio（[00:48:28]–[00:51:30]）

主持人立的问题很好（[00:48:28]）："过去有一种逻辑是你不该把软件过度定制给某一个终端用户。但 LLM 和 AI 的某些性质可能让'定制而不把自己作为一家公司拖慢太多'变得越来越可能。"
⚠️ Amble 的回答给了"为什么现在有这么多前置部署工作"一个很干净的解释（[00:49:30]）："部分原因是客户数据的状态、以及理解客户 N 比理解客户 N+1 难得多。所以我们整体上还处在部署的早期阶段，这也是为什么这个产品里还有很多人。"
⚠️ 而她顺手指出这件事对在位者更难，本页认为这是本期关于在位者的第三条独立论证，而且是组织结构层面的："顺便说，这件事对在位者更难，因为它们的组织方式——它们产品反馈循环的运作方式——它们有实施团队，但那很大程度上是个事后附加，而不是一个会反馈进产品侧的东西。"
她给的演进方向："AI 的好处是它会随时间学习。所以当我们谈学习循环、并且你有正确的 eval 流程时，你能随时间做越来越复杂的工作，而其中一部分就是把部署本身自动化掉。" 终局是：定制越来越由自动化处理，并且"客户能通过软件自己去转那些定制的旋钮和拉杆"——对照的是"原来你请 Accenture 来做 SAP 定制"。
⚠️ 而嘉宾侧给的组织数字与 KPI 设计，本页认为是全期最可操作的一段（[00:50:30]–[00:51:30]）：
⚠️ "看 Lio 的组织结构，85% 的人是工程师。即使那些头衔不是工程师的人，大多也有工程背景。原因是我们显然不想做成一家咨询公司。"
⚠️ FDE 的 KPI 被设成一个自我消解的目标："我们前置部署工程师的工作，一方面是把它做成自助式的，但在内部其实是把他们自己的工作自动化掉——他们的 KPI 就是：你的工作字面意义上就是把你自己自动化掉。然后你把自己自动化掉了，你就去做下一个任务。" 他说"我觉得这也是 Google 之类在用的做法"。
⚠️ 本页交叉标注：这与本库 Decagon 的打法、Legora、Netic 的前置部署材料是同一条线；⚠️ 而"把 FDE 的 KPI 定成自动化自己"是本库第一次看到这条被写成明确的考核口径。 详见 AI 与就业。

七、⚠️ 双边都上 agent：零和的那一面被他切掉了¶

来源：a16z / Lio（[00:44:25]–[00:48:28]）

⚠️ 一条反直觉的观察（[00:44:25]–[00:45:26]）："销售侧一直领先于采购侧。但我们现在在这些 Fortune 500 的供应商身上看到的，其实不是这样。它们也许在视频录制、用 Granola 这类工具上比较先进，但并没有真的部署 agent、把工作自动化掉。"
⚠️ 而他由此推出一条很有产业结构味道的扩张路径，本页认为是全期最该被记住的商业论证（[00:45:26]–[00:46:27]）：
"销售是性感的，采购是不性感的。但它是同一个流程，而采购是那个对手方。"
⚠️ "而现在好处是，在这些工业公司里，采购对供应商有更大的权力——作为一家典型的汽车供应商，你对你的供应商规定它们该用什么、质量必须如何、必须怎么回应一份具体的 RFQ。所以机会就是：如果我们服务采购部门，而它们能规定供应商该用什么——那我们为什么不也把它们推向 Lio 的 agent，去帮它们把工作自动化、从而同时拥有这笔交易的两边？"
⚠️ 本页标注这条的性质：这是一条通过客户的议价权做的渠道扩张论证，⚠️ 而它成立的前提恰恰是采购侧对供应商的强制力——所以它在采购强势的行业（汽车、工业）成立，在采购弱势的行业不一定成立。本页记为有适用边界的论证。
⚠️ Amble 把它推到了一个更难的场景（[00:46:27]）："它甚至可以延伸到法律工作，而那是两个非常对抗性的方。但如果你有两家律所、客户利益不同，双方都受益于知道：这是最新的草稿、未决问题在哪、哪些已经达成一致。而就连追踪这件事现在都不真的存在——那全是人在做。所以那个协调工作，一个 agent 可以来做。"
⚠️ 而对"价格是零和"这一问，他的回答本页认为是全期结构最清楚的一段（[00:47:28]–[00:48:28]）：
"价格是 5000 件其它任务的结果，而在那 5000 件其它任务上，双方的激励是完全一样的。"
具体化："销售想要尽可能少的摩擦。买方想要非常快的上市时间。" 回到他自己的例子："你想让这个数据中心尽可能快地建起来，你不想因为分析供应商的回复太费时间而晚六个月。而你也想让这笔销售快点成。"
⚠️ 本页标注：这条论证的真正内容是"把零和的那一项（价格）从非零和的那 5000 项里隔离出来"，而非零和部分才是平台化的基础。本页认为这是一个可迁移的框架，但也标注它的弱点：⚠️ 他没有回答"当双方都用同一家供应商的 agent 时，那家供应商在价格这一项上的中立性如何保证"——而这一问在期内没有被提出。

八、为什么选采购：三个条件相乘¶

来源：a16z / Lio（[00:52:32]–[00:58:40]）

⚠️ 他对这个品类历史的诊断，本页认为是全期最适合迁移到其它垂直的一条（[00:52:32]–[00:53:35]）：
"看过去 26、27 年采购是怎么工作的，涌现了大量工具——你在 LinkedIn 上能找到那些技术全景图，你会看到有 500 个采购工具。"
⚠️ "但我挑战任何人去找一个喜欢和采购打交道的人。没有人喜欢。请求方讨厌，供应商讨厌，甚至采购部门里的人自己也讨厌做采购。"
⚠️ "那如果有一千个工具，到底是怎么了？原因是所有那些工具只是把流程变得更有效率了，仅此而已。但它们从来没有改变那些人实际上怎么工作。"
⚠️ "而且很疯狂的是，他们是在邮件里、在 Microsoft Teams 里、在 Excel 和 PowerPoint 里工作的——那是他们工作的主渠道，而那里是零 AI 的。"
⚠️ 本页标注：这条诊断把"软件渗透率高"和"工作方式被改变"彻底分开了，而本页认为这是本库目前见过的对"为什么一个被软件覆盖得很彻底的品类仍然可以被重做"最好的一句解释。详见 AI 的商业模式与价值捕获。
他们做的线下动作（[00:52:32]、[00:54:37]）：第三届 "Bots and Buyers Summit"，这次在纽约办、就在办公室几个街区外，来了 100 多位采购负责人，只邀 C 级与 VP 级；⚠️ 而他们的呈现方式很具体——"AI agent 很抽象，所以我们搭展位，办公室里也有，你可以走过那些展位、真正上手体验所有这些 agent"。下一场约 700 人，在慕尼黑。
⚠️ 他的三条件框架，本页认为可以直接当作选品类的判据（[00:56:39]–[00:58:40]）：
⚠️ 高情绪："如果你和这些人聊，他们真的很沮丧——这意味着这是个高情绪的话题。虽然说实话，这是 B2B SaaS，但它真的高情绪。"
⚠️ 枯燥且小众："这也是个优势，因为对我们来说很容易震撼到这些人——他们看到的真正上一次革命是 20 年前，之后也许 10 年前有个更好看的界面，然后什么都没发生过。"
⚠️ 疯狂的商业影响："它对整个经济有影响——数据中心怎么建、飞机怎么造、汽车怎么造、无人机怎么造。"
⚠️ 而他给的那条毛利套算是本页记这一节的主要理由："要让毛利提高 1%，你需要多做 10% 的收入、10% 的销售。所以如果你只是做到 1% 的节省，它就等于你为了在 P&L 上得到同样结果而必须拿到的 10% 的销售。"（⚠️ 这是一个与具体毛利率绑定的经验比例，本库未核实其适用范围。）
⚠️ 落点与推广："你把这三件事组合起来，你就有了一个万亿美元的商业机会。那是我对采购的看法——但大概也有其它东西同样是情绪化的、枯燥的、而且有疯狂的商业影响。"
主持人给了这个品类一条很生动的一手注脚（[00:55:38]–[00:56:39]）：七八年前她接触过一位采购出身的人，对方的反应是"我讨厌聊这个产品，我用的是这套遗留系统记录，我在 Coupa 上，我不想再买任何东西，我不想谈这个，就这样挺好"——"那是我做过的大概几百万次客户访谈里最不满的一次。"

⚠️ 本页的五条限定¶

⚠️ 这是投资方频道访问自己的被投公司（Amble 写了《Investing in Lio》）。公司的全部业务声明均为自述，本库一条未核实：那条端到端"全自主跑通"的螺栓流程、1 万 / 2 万 / 10 万次谈判、85% 工程师、"笔记本和铅笔三年前就解决了"、第三届峰会 100+ 人、下一场 700 人。
⚠️ 那条 20/80（发票软件只是问题的 20%）是单一公司在单一品类上的自述，不是行业测量。 本页采用它的理由是它的形状与本库另外三处独立材料一致（Sinofsky 的例外处理、Decagon、Almeida 的"按唯一性重算只有 50%"），而不是因为那个数字本身可靠。
⚠️ "自建只能到 70%"这条判据既是他最有说服力的论证，也是他商业上最需要成立的论题。 Amble 那条 Fortune 500 催收项目的一手案例是独立于他的，⚠️ 但它同样来自投资方一侧，且是转述、未具名。
⚠️ 他指向 Jev 那类"输出是结果而非文本"的模型，目前只是"在思考、已开始微调"，没有任何已兑现的结果。 ⚠️ 而他与 Almeida 同在 a16z 的内容生态里，所以这不构成对 system one 模型类别的完全独立佐证。
⚠️ "双边都上 agent"那条平台化论证有一个期内未被提出的问题：当买卖双方用的是同一家供应商的 agent 时，这家供应商在"价格"这唯一一项零和任务上的中立性如何保证？ 本页明确记下这个缺口。另有两处字幕损坏已在页首标注（inter/intra 用反、"Jeff"/"Jev"）。