跳转至

Decagon 的企业 AI 应用打法：90% 开源、Duet 自建 agent、"杀死岗位不杀死职业"（a16z，2026-07-31）

  • 嘉宾: Jesse Zhang（Decagon 联合创始人兼 CEO）· Ashwin Sreenivas（Decagon 联合创始人兼 CTO，前 Palantir deployment strategist）
  • ⚠️ 说话人认定说明：转录稿只有 >> 换人标记、无说话人标签，且部分换人处漏标。Jesse 被主持人多次点名（"Jesse, I'm going to mention a piece that you wrote recently"、"Sounds like you created Jesse"）；另一位在文中被自动字幕写成 "Asha" / "Ashan"，本库据两条内证认定为 Ashwin Sreenivas：① 主持人说"你以前是 Palantir 的 deployment strategist"（[00:25:16]），② 他被称"上了纽约时报"（[01:13:41]）。本页凡涉及具体归属处已按内容判断，边界不清处只写"其中一位创始人"。
  • 主持: a16z 企业软件侧合伙人。⚠️ 转录稿从未播报主持人姓名；仅有的线索是自陈"我们大约整整三年前开始合作"（即 Decagon 早期投资方）、"我一直在研究应用软件十多年"、以及一处被自动字幕写成 "Kimberly" 的调侃（[01:13:41]）。本库不做认定。
  • 来源: YouTube · 80 分钟（自动字幕）
  • 转录稿: sources/a16z/20260731-cO1f2wOxSH4
  • ⚠️ 转录稿专有名词对照表（自动字幕误转，引用时以右侧为准）：Dagon/Decon/Deagon/Dakon/Zechon = Decagon；Palunteer/Palanteer = Palantir；Sham = Shyam Sankar（Palantir CTO）；Ragu Ragnaram = Raghu Raghuram（前 VMware CEO）；Zenness = Zendesk；do just / Ducky / det = Duet（其产品名）；tokconomics = tokenomics；FDES/FTEES/four deployed = FDE / forward deployed engineer；Kimmy K3 = Kimi K3；Brian Chesy = Brian Chesky；Patrick Ashanti/Oshanosy = Patrick O'Shaughnessy。另 ⚠️ 一处人名 Jeremy GeFon 本库无法核实，不下断言。

这是本库迄今关于"应用层公司到底在做什么"最完整的一份一手材料，价值在于它同时否掉了 2026 上半年最流行的两种说法："应用层只是套壳 UI + FDE"，和它的镜像"应该全用前沿模型，tokenomics 是首要问题"。

三条最该被引用的：① ⚠️ "更便宜 vs 更聪明"是一个假的权衡——微调后的小模型在那一个任务上同时做到更好、更便宜、更快，"我们三样全拿到了"；② ⚠️ 一条与"开源正在赢"叙事相反的一手观察——"企业里开源推理的份额现在其实在下降"，机制是新用例都从前沿模型起步，开源份额是用例成熟度的滞后函数；③ ⚠️ Jevons 悖论在客服里的具体案例——某客户接入后把支持入口铺满每一页、对免费用户也开放，因为"原来我们的客户有这么多问题"。

与同一天的 Netic 那期 构成同日对照：同一个"实验室会不会吃掉你"的问题，同样落在"模型之外的那一层"，但 Decagon 押横向、Netic 押垂直。

⚠️ 利益相关：主持方 a16z 是 Decagon 投资人（自陈"三年前开始合作"）。本页按"X 认为"记录，公司自报数字无第三方来源。

说话人映射（据补做分离的 speakers.md；转录稿本身无标签，此处认人属 wiki 层编辑判断）： | 标签 | 占比 | 认定 | 依据 | |---|---|---|---| | SPEAKER_02 | 42.0% | Jesse Zhang（CEO） | 排除法（另一位联创为 SPEAKER_03） | | SPEAKER_03 | 37.3% | Ashwin Sreenivas（CTO） | "prove every single thing that Jesse just talked about"（[00:33:16] 块，100%），所以不是 Jesse；高纯度块讲派驻团队如何进入企业（[00:24:16]） | | SPEAKER_00 | 15.2% | 主持 | 点名"Jesse, I'm going to actually u[se]…"（[00:01:00] 块，91%）；"you both are very very technical but also go to market animals"（[00:37:18]，100%） | | SPEAKER_01 | 5.5% | 主持方（第二位或同一人被拆分），未能确认 | "…almost exactly three years ago, and you guys landed on this idea"（[00:23:15]，80%），投资人口吻 |

页头已注明转录稿从未播报主持人姓名。

核心观点

一、开源之路：为什么走、走到哪、以及一条反直觉的份额观察

  • 动机不是成本，是延迟（[00:02:00]–[00:03:00]）：起步当然用前沿模型（"目标就是先把东西跑起来"）；规模变大 + 上线语音 agent 之后，延迟成了硬约束——"不只是能不能给出好回答，你得非常快地给出来"。而把延迟降下来、同时让 agent 按你要的方式运行，唯一的办法是用更小的模型；而"⚠️ 前沿实验室确实有小模型，但你没法按你想要的方式控制它们，而且大多数开箱小模型在我们要它做的任务上不够好——所以你必须微调它们、改造它们"。这就是他们大约一年多前转向开源的起点。
  • 为什么"一个任务"就够（[00:03:00]）：agent 的活是对话，它一次要做很多事——这是什么话题？这个人是不是来捣乱的坏演员？"每一个单独的任务都不需要一个大模型的全部智能。"
  • ⚠️ "假权衡"这一段，是本期最该被引用的技术判断（[00:05:00]）：

    "推特上这些辩论的权衡往往被说成：我们要非常贵的最聪明的模型，还是把它变笨一点换便宜？我其实认为那是一个假的权衡……我们在实践中看到的是，即使是所谓更笨的模型，当我们微调更小、更笨的模型时，它们只是没那么通用，但在我们要它做的那个具体任务上，它们的表现确实超过又大又聪明的 SOTA 模型。" "所以我们最后三样全拿到了：它在这个任务上更好、更便宜、而且更快。"

  • 现状：今天 90% 的工作流跑在开源上；剩下 10% 仍用闭源前沿模型，用于新项目/新产品（[00:04:00]）。
  • 评估模型的三个维度：成本 / 智能 / 延迟——"看你需要什么，你要顶到这三者的极限，有时候可以互换"（[00:04:00]）。
  • 前沿模型留在哪里（[00:06:02]）：辅助任务，以及开放式探索型任务。给的例子是 Duet Autopilot——"它要去审阅一百万条刚发生的对话、找趋势、造出主模型的变体、看哪个变体表现更好"。这类"更宽、更开放"的活，"很聪明、能试很多东西的前沿模型非常合理"。
  • ⚠️ 与"开源正在赢"叙事直接相反的一条一手观察（[00:08:02]）：

    "现在企业里虽然对开源有很多炒作，但开源推理的份额其实在下降。因为大家在起一堆新用例，而如果你在起新用例，你当然会用前沿模型，直到它跑通为止。" 但这些用例里"有些会死掉，有些企业会说'好，我们要继续发布并推广它'——一旦到了那个点，他们就有强烈动机转开源，因为便宜得多也快得多"。 机制含义：开源份额是用例成熟度的滞后函数，而不是一个单调趋势。

  • 企业自己做后训练会来，但比人们以为的慢（[00:07:02]–[00:09:02]）：微调非同小可，"你要拿到数据，更重要的是你得有好的 eval——⚠️ 我们的 eval 极其针对我们自己，你不能拿一个公开 eval 集来顶事，我们必须自己造基准和 eval"。加上企业侧的惯性、模型风险治理（model risk governance）和安全流程，"一次只能起那么多用例"。
  • ⚠️ "model factory"——为什么不是一次性工程（[00:09:02]–[00:10:03]）：模型的形态在不停变，"我们不是建好一套开源模型然后就完事、两年后再回来看"。随着前沿能力变化，新用例会冒出来——"这个任务好像重复得很多，因为我现在有了一个此前没有的能力"。所以他们不断训练全新模型、并淘汰不再相关的旧模型。Decagon Labs 因此被定义为"某种意义上的模型工厂——我们建它就是为了压缩'新模型出来'到'对我们任务有用的微调模型从另一端掉出来'之间的时间"。
  • 自建 vs 外采的判据（[00:11:04]–[00:12:04]）：与用例紧耦合的（训练工具链、eval 基础设施）自建，因为"⚠️ 如果我们能把 eval 直接对齐到客户结果，那比看 loss 曲线好太多了……我们衡量的是整个系统端到端，不是'这个模型在这个任务上好不好'，而是'这个模型和其它所有模型协同工作时，有没有交付我们在乎的那个终端客户结果'"。通用的（打标数据、衡量数据集多样性）则外采——"唯一在乎的是怎么最快把最好的模型送进生产"。

二、tokenomics：他们为什么不太关心

  • 驱动因素是性能与延迟，成本是副产品（[00:12:04]–[00:13:05]）："这是少数几个你能免费拿到所有东西的任务之一——我们不用在成本、延迟和性能之间取舍，只要照着延迟和性能优化，成本就作为一个好的副作用掉下来了。"
  • 成长期公司的优先级："我们当然得对成本负责，但那不是最高优先级，最高优先级就是增长。而且你跟客户谈的时候，他们根本不在乎你的成本，他们只在乎你的 agent 表现多好。"
  • ⚠️ 一条反直觉的单位经济学事实（[00:13:05]）：他们的产出单位是一次对话，"客户不在乎那次对话花了我们多少钱、里面有多少 token。而且随着时间推移，我们每次对话用的 token 数其实是上升的——因为我们在做更多次模型调用来提高质量、做更多检查、并行更多东西。这就是我们现在所处的阶段。"（"等赢下市场了，再来看能不能优化成本"。）
  • ⚠️ 对 tokenomics 之辩的元观察（[00:14:06]）："tokenomics 的辩论真正围绕的是——我今天在前沿模型上，该怎么分析我的成本、该不该转开源。在那个语境下这个辩论完全说得通。但一旦你已经跳过去了、知道怎么拆解问题、怎么快速训练部署模型，成本这件事就没那么紧迫了。"

三、应用 vs 基础设施：这个二分法是假的

  • 被反驳的叙事（主持人给的原话，[00:15:07]）："这个叙事主导了 2026 年上半年——Anthropic、OpenAI 是最后的创业公司，它们会通吃一切；应用层不过是套着 FDE 的薄 UI。"
  • ⚠️ Jesse 拆掉一个常见误解（[00:16:08]）："人们常有的误解是，微调是为了给那个客户做定制。事实上，我们做的绝大多数微调是为了我们的用例做定制，即客服这个用例。对我们值得，因为我们只干这个……但如果你是那家企业，值得把你宝贵的研究资源拿去调一个客服行为的模型吗？大概率不值得。"
  • ⚠️ 业务逻辑不能靠微调，这是本期最有工程价值的一条区分（[00:17:10]–[00:18:11]）：

    "我不是在为行为做微调，我是在教 AI 我自己的流程。而那件事不是通过微调发生的，是在上下文里发生的——因为如果你把它微调进去，每次你改流程都得把它逆转回来，这说不通。" "这些业务逻辑跟模型本身毫无关系……它必须存在于应用层。"（例子：航班取消了要一次改签三个人。） 由此推出的应用层清单：深度集成、承载业务逻辑的能力、跑测试与实验、复盘对话、跑 QA、给合规团队做监控的工具。

  • ⚠️ Ashwin 的"AGI 也需要软件"论证（[00:19:13]–[00:21:15]）：

    "大家都在往彼此的地盘里渗——实验室都在往上建应用，因为企业就是这样从他们那里看到 ROI 的；我们在应用层则发现，可以靠自己造模型为我们在乎的用例挤出更多性能、延迟和成本。这种互相渗透是合理的，而且会继续。" "我不太买'实验室是最后的创业公司'这套。某种意义上人类本身就是 AGI，而人类为了做各种事一直需要用软件——你需要数据库来放东西、需要 CRM 来追踪。即使有了 AGI，我们所有的 AGI agent 也需要一个地方来存放工作、拉取信息、对事情做推理。" 他保留的部分："一类纯粹为了让人干活而建的 SaaS 公司可能会挨点烤火"；以及"也许长期来看，应用层公司就变成了特定垂直领域的实验室，因为你的主要产品最后就是那些特别擅长做那些特定任务的模型"。

四、FDE 是不是陷阱：本期最具争议的一段

  • ⚠️ Ashwin 的"spicier take"（[00:21:15]–[00:22:15]）："我认为这（大量招 FDE）是个陷阱。"
  • 他承认 FDE 现在必要，但给的理由是新的："FDE 对早期 AI 公司是新近必要的，因为工作流是新的。五年前建 SaaS 公司，大部分 SaaS 产品的工作流已经被探索过了……但对 AI 产品，没人知道工作流是什么，因为没人用过这些东西。"
  • 所以 FDE 的真实职能是："老实说就是嵌进客户那里，在客户第一次学会这个工作流的同时，自己第一次学会这个工作流"——"某种意义上他们是在边看火车往哪开、边铺轨道"。
  • 长期结论："一旦你知道了工作流，就不该再依赖 FDE 了。如果能产品化就该产品化，然后成为一家有科技公司规模化属性的典型公司。"
  • 另一位创始人补的那句："如果你做不到那一步，你就只是在建一家被美化的咨询公司。"
  • ⚠️ Palantir 对照（Ashwin 有一手经验）（[00:25:16]–[00:26:16]）："硅谷把 FDE 这个词用得非常松，把'免费的咨询工作'和'真的在做产品'这两件事混起来是危险的。"
  • 他引 Shyam Sankar 的内部说法："forward deployed engineers eat pain and excrete product."（FDE 吞下痛苦、排出产品。）
  • 他指出的误读："首先，几乎没有公司能做 Palantir 做的事——一上来就签下巨大的合同，因而值得把那么多力气砸进去。" 那些走"超级 FDE、什么 AI 用例都替你做"路线的公司"最终得面对一个清算：我们能不能找到一个可规模化的产品？否则你就是在建一个现代版的 Accenture——如果那正是你想要的，也行"。
  • Decagon 自己的做法（[00:23:15]–[00:27:16]）：FDE 建的是核心产品——"他们的产出不是给那个客户的一次性东西，而是贡献进核心产品，让接下来问同样问题的 10 个客户免费拿到"；agent PM 则同时产出产品改进和流程改进（帮企业走完从现状到 AI agent 大量干活的转型）。
  • 产品驱动 + 销售驱动的双重定位（[00:26:16]–[00:27:16]）："我们内核是一家产品驱动的公司……但同时也是销售驱动的，意思是产品由销售来告知。我们不是坐在那里凭空想产品该造什么。"FDE 的职责是"把所有从销售那里学到的东西编译进核心产品"。

五、Duet 与 Duet Autopilot：把 FDE 的活变成第二个 agent

这是本期最具体的产品演化史（[00:29:16]–[00:34:16]）：

  • 早期做主 agent 的时候，人要干的活：写 AOP（agent operating procedures，他们自创的一种流程格式）教 AI 怎么做事、写这些流程能调用的工具（访问系统、拉 API）、写测试来模拟各种情形、上线后人工逐条读对话。
  • ⚠️ Duet 就是把这一整摞活变成第二个 agent："它是一个更大、更慢的第二个 agent，它的活就是做我刚才描述的所有任务。"

    "你可以真的直接告诉它：嘿，我到现在什么都还没建，但这里有一堆转录稿和一些文档，你去想出做这些流程的最好方式——它就去做了。然后它会自己主动写出配套的测试和仿真。上线后又是它在监控所有对话，标出哪些做得好、哪些做得差——'我读了这一千条对话，其实有一个话题我们做得很差，而且我已经替你起草了改进方案'。"

  • ⚠️ 一条关于模型能力跃迁的证词（[00:32:16]）：

    "我们刚创业的时候这是不可能的。只有当所有推理模型都变好之后才变得可能。 Anthropic、OpenAI 造这些推理模型主要是为了 Claude Code 那类东西，但它们对 Duet 这种也非常好用。" "很清楚，这些模型没有在我们这个特定任务上被训练过——就是写这些流程、写这些测试——但它们仍然做得很好。"

  • 产品谱系（全部来自把 FDE 的活产品化）（[00:33:16]–[00:34:16]）：
  • AOP 本身就是第一次产品化——"在 AOP 之前，你得用代码写所有这些流程"，发现太耗 FDE 工程，于是改成纯文本写；
  • Duet = 产品化"进新客户要花大量时间手写 AOP"这件事；
  • Duet Autopilot = 产品化"上线之后迭代 agent（复盘对话、找改进）"这件事。
  • 他们的方法论一句话："我们思考产品改进和 FDE 投入的方式，全部围绕：我们能从 FDE 的工作里产品化出什么，好让工程师和任何面向客户的资源不必那么重地介入。"

六、护城河：十年后 Decagon 凭什么还存在

主持人的直球问题："假设我们到了 AGI，模型能做今天想象不到的事，Decagon 的护城河是什么？"（[00:34:16]）

⚠️ Ashwin 的回答是本期最完整的一条应用层护城河论证（[00:35:17]–[00:36:18]）：

"短期来看，是与企业资源协同工作的能力。我的意思是：今天模型的能力远远大于它们在企业内部被使用的程度。你不能直接拿一个模型说'我把企业里的一切访问权都给它，它自己会搞明白'——实际上不是这么回事。"

他把"假设模型完美无缺"之后仍然剩下的东西列成了四条：

  1. 能力边界："我需要一种方式告诉模型它能做什么、不能做什么，并确保它不能做出任何灾难性错误的事。"
  2. 组织协同："我需要一种方式，让企业内几百个人能协作，确保 agent 在他们各自是专家的那些用例里按预期行事。"
  3. 合规测试："我需要一种方式去测试这个模型，确保它不越过我有的任何监管红线。"
  4. 洞察抽取："我需要一种方式，从发生的几百万条对话里替我的其它团队抽出洞察。"

"所以有大量的基础设施和软件必须围绕这些模型建起来，才能让它们在企业里可部署、才能让它们跟这些公司的遗留系统一起工作。"

⚠️ 他罕见地给出了这条护城河的失效条件与时限："一旦这些因为 agent 能即时造出来而被商品化——那我就不知道了，我们三年后再来搞清楚。"

七、销售：为什么大企业的成交周期这么快

  • 主持人的观察（[00:36:18]–[00:37:18]）："你们两个都非常技术，同时也是 go-to-market 动物……最让我们这些研究了十几年应用软件的人惊讶的是，销售周期快得离谱——通常你不会这么快就把这么大的合同卖给这么大的企业，那有时要两年。"
  • 与 Sierra 的对比（本期唯一一段竞争对手细节）（[00:38:18]–[00:39:18]）：他们说最近一个客户从 Sierra 转来，问原因得到的回答是——"用 Sierra 时主要是 FDE，感觉像个黑盒：什么事都得走 FDE。要建新 journey、或者哪怕只是更深入理解对话里在发生什么，都要过他们……时间久了 FDE 被派去别的事，拿到洞察要等很久"。
  • ⚠️ 可核验的对照数字（转述客户口径）：那家客户在 Sierra 一年建了 3 个 journey；转到 Decagon 后大约一个月内起了 7 个新 journey。
  • 他们给这套打法起的名字："glass box（玻璃盒）而不是 black box（黑盒）"——"即使我们在那里帮忙、即使我们 forward deployed，那也是为了帮他们建一个他们自己能用、能快速迭代、一切尽在掌握的产品"。他同时承认"也可能有别的团队就是喜欢'你们全替我们做'那种方式"。
  • 他们对 Sierra 与其它大平台的评价是"很有敬意"，只说"平台本身动得慢一点……他们同时在优化很多不同的东西"。
  • ⚠️ 真正解释"为什么快"的那条，是部署路径本身被产品化了（[00:42:20]–[00:43:23]）：

    "在很多这些企业内部，除了'这个产品对我管不管用'之外，他们还有一个内部问题：我到底能不能把它上线？ 在很多企业里这其实很复杂，尤其你在金融服务、还受监管。" "所以我们花了大量时间把那段旅程也画得很清楚——当我们走进一家企业，我们能非常颗粒地带他们走完从今天第一次会议到 100% 上线的全过程：在你这个阶段，你的模型风险流程大概长这样；你的测试流程该长这样；初始 rollout 该怎么做；出问题怎么抓、怎么修、怎么保证不再发生。" 他的结论："产品和技术很重要，但对这些大公司来说，同等重要的是我们帮他们想清楚真正把它部署到规模所需要的流程——这件事经常被卖给企业的科技公司忽略。"

  • 创始人时间分配（[00:44:24]–[00:46:27]）：其中一位说自己大概 80% 的时间在销售。原因不只是"客户想见创始人"，而是：① 把项目切成小块——"不是一次在所有面、所有用例上部署，而是挑一两个最顶的用例先拿下一个胜仗"；② 只有创始人会不断想出新的配置方式——"你不会指望销售团队一直想出新配置，因为他们不为产品负责、不为公司端到端的流程负责"；③ 贴近反馈回路："模型能力一直在变，人们会看到别处的新东西，说'哇这个好酷，你们没做'——我们永远不想放掉这个回路。"
  • 早期销售团队画像（[00:41:19]–[00:42:20]）：两位创始人此前都没卖过企业软件，"碰巧我们俩都觉得销售很带劲"；很多早期成交是"因为我们这个领域太热了，我们其实不需要说服人们投入这个领域，更多是'我们是适合你的那条路'"。早期销售人：非传统销售背景（有些是主动冷申请过来的、此前就在这个领域看着 Decagon 在做什么）、以及常春藤运动员。

八、从客服到 AI concierge：模型到底变好在哪

  • ⚠️ 产品定位的原始设计（[00:48:28]–[00:49:29]）：

    "归根到底，我们建的东西——而且我们一开始就是有意这么建的——不是一个把客服做得好的 agent，而是一个把业务流程跟得好的 agent。" 所以执行运营工作流、做销售线索资格判定、回答某些客服问题，"归根到底都只是一个 agent 在跟随一条业务流程"。

  • 为什么当初从客服开始：① 那是早期客户最大的痛点之一；② "那也是当时模型能力的边界所在"。
  • 客户自己发现的扩展逻辑："你现在很了解我们的产品（因为做客服你必须懂）、你知道我们喜欢怎么跟客户说话、知道我们的品牌——你能帮我们做 inbound sales 吗？"另一个客户则用于运营工作流：在看到账户出问题时主动外呼。
  • ⚠️ 模型具体变好在哪：指令跟随（[00:49:29]–[00:50:31]）：

    "具体来说就是跟随指令的能力。几年前的模型你得给非常非常紧的指引、非常具体、不许偏离。随着模型变聪明，你可以给越来越宽、越来越大的指引，并且信任模型有足够的判断力像人一样去解读、把缺的空白填上。" 判据落到用例上：客服可以走一条很紧的路径就够了；销售资格判定则要问开放式的探索问题，对话会来回摆动，所以需要模型自己填合理的东西。

  • 产品路线图（[00:50:31]）："在今天的 AI 世界里，很难有一个精确到点的 12 个月路线图。" 你可以有一些主题，"但理想情况下如果你有那些东西，你现在就该直接把它建出来，因为现在建东西太快了"。长期愿景倒是清楚："AI agent 应该就是你这门生意或品牌的正门。与客户的每一次交互，无论是被动的还是主动的，都该由 AI 来处理。"

九、瓶颈是招人，不是模型

  • ⚠️ 被问"现在的瓶颈是什么，能力侧？持久记忆？"，回答是一个字："招人。"（[00:51:32]）
  • 追问"那你为什么不雇 AI agent 去做你们在做的事"，回答："我们是 token 的贪婪消费者，我们的 token 账单非常非常大"，但——"我不觉得我们已经到了 AI agent 能决定该建什么的那个点，以及那种'这件事做完了没有'的品味。我们可以外包大量具体的执行步骤，但它们还不能拍板该建什么、该排除什么**。"
  • 技术侧仍在等的东西：voice-to-voice 模型（"还在做研究的一个有意思的前沿"）、让小模型开箱就更聪明。"但从生意角度，瓶颈更少在模型侧，更多在你能不能把公司建得够快。"
  • ⚠️ 对"一人独角兽"的反例与机制（[00:53:33]）：

    "一个容易的反例是——所有 AI 编码创业公司都在疯狂招人。他们大概是这些模型最老练的用户，而他们在疯狂招人。" 机制："因为每个人都能拿到这些工具。如果我们的竞争对手要用它们建更多东西，我们就得建更多东西。如果有人说'这是我们的路线图，现在我们能用三分之一的时间做完'然后停止招人，我们只会理解成：哇，我们能用三分之一的时间做完，太好了，那就建三倍的东西。结果每个人都做同样的算术。所以每个人都既需要继续招人，也发布更多东西。" 结论："这对这些模型的消费者是好事。但我不认为它实质改变了我们的招聘计划。"

十、文化：grind slop、team sport、国际化

  • ⚠️ 对 "grind slop"（晒加班）叙事的回应（[00:55:33]–[00:56:33]）："我们从来没发过 grind slop，因为我们觉得努力工作这件事，人们不是为了 grind 才努力的，只是要做的事很多……'这是我们人生里一段有意思的时期，我们想把自己的天赋和潜力用出来、别浪费掉'。"
  • 她们的具体政策："我们从不强制人周末来，我们不太在意他们在办公室待多久。人们在办公室，只是为了把沟通最大化。"
  • 他自己的定位："我不觉得我们不正常地 grindy 或不正常地有野心。我身边都是有野心的人，所以这就变成常态了。"
  • team sport（[00:56:33]–[00:57:33]）："我们各个组之间很少有界线——你会经常看到工程师出现在早期销售电话上，看到销售在 debug 产品的一部分。"这既是"需要人在办公室（大家一起 jam）"的理由，也是"有意思"的来源。
  • 文化扩张的做法（[00:58:33]–[00:59:33]）：坦承"这对我们不是一个已解决的问题"；"前 100 人不太要紧，因为大家彼此都认识；但长大之后可能根本没人跟新人传达过愿景和文化"。具体机制两条：① 每个新入职的人都被带到旧金山待几周，浸泡在"最初那锅文化汤"里；② 全新办公室会派 hub 的人过去待几个月，直到那个办公室足够大、长出自己的文化。
  • ⚠️ 国际化被提前拉动的两条机制（[01:00:33]–[01:01:34]）：
  • 自上而下的压力："AI 是这么大一个现象，每个买家都试过 ChatGPT 之类的东西，所以有大量来自董事会和 CEO 的压力要求'赶紧动起来'。而这些企业想'我们怎么采用 AI'——答案就是'搞点编码 agent，搞点客服'，因为那是最显然的两个。"
  • ⚠️ "用 AI 之后语言容易多了"："过去的阻碍可能是'我的 app 在德语里不 work'……现在适配容易得多。"
  • 反向摩擦：数据驻留（data residency），以及"更懂本地市场的本地竞争者"。他们的策略是只重投"已经从美国办公室自然接到客户"的市场。
  • 邀请 Raghu Raghuram（前 VMware CEO）加入，除投资外帮他们建国际能力（[00:59:33]）。

十一、横向 vs 垂直、CRM 会不会死、以及"民主化 concierge"

  • ⚠️ 他们明确押横向（[01:02:35]–[01:03:36]）：

    "我们之所以建得这么横向，是因为我们相信在我们这个空间里，赢家会是横向的。真正超级垂直化、能让一个纯垂直方案活下来的东西并没有那么多，而且历史上在我们这个空间就是如此——Salesforce 非常横向，Zendesk 非常横向，所有这些方案都很横向，因为你从规模、从一个非常健壮和深的产品里拿到的，比从非常垂直的特定功能里拿到的更多。" 他们会随时间往里加垂直功能，但判断是"从垂直和市场分层的角度看，会发生整合（consolidation）"。

  • ⚠️ "民主化 concierge"——本期最好的单位经济学论证（[01:03:36]–[01:04:36]）：

    "如果你去一家你每年花 10 万美元的商家，你会得到最个性化的对待，他们完全知道你是谁、你的偏好是什么……但如果你在一家你只花 10 美元的商家，他们没法为你做这件事，因为他们做不出经济账。" "这不是缺乏为客户做这件事的意愿，只是单位经济学不支持。" "所以我们在做的，实质上就是——如果你能用 10 美分给他们那种体验，那它突然就算得过账了，而他们本来就想那么做。"

  • CRM 不会消失（[01:04:36]–[01:06:37]）："如果你今天的 concierge 是个人类，他还是会把你的信息写进 CRM 好以后追踪。当我们有了这些 AI agent，它们也需要一个地方去放那些信息。"
  • 另一位补的更有意思的版本："CRM 某种意义上就是数据库，人们对它的不满常常是界面很难用；但未来也许是 agent 在用这些界面，你甚至不需要图形界面——那 CRM 仍然非常有价值，因为它们持有事实来源，只是被 ping 得多得多了。"
  • 他们自己的边界："我们对建 CRM 零欲望，因为 agentic 层要做的事太多了。"主持人的总结："所以 SaaS 没死。"

十二、创始人自己怎么用 AI

  • ⚠️ Ashwin 给自己造了一个"越过肩膀看"的上下文 agent（[01:06:37]–[01:08:38]）：

    "模型已经很聪明了，我们俩经常用它头脑风暴，因为它们真的很会出好点子。然而我意识到，至少对我做的很多工作来说，瓶颈是业务上下文——每个想法背后有大量上下文：我们的约束是什么、我们要达成的目标是什么，这些东西每次都很难重新解释给 agent 听。" 所以他花了一段时间给自己造 agent 来捕捉业务上下文，"它就一直越过我的肩膀看着，不断编译上下文——我们招了哪些人、还要招哪些人、在谈哪些单子、现在有哪些问题和挑战"。 用法举例：问"我们在考虑招这个新人，你怎么看"，它能自己推理出"我们之前有两个非常相似的候选人，他们有这些短板/缺的技能。如果招这个人，会是又一个有完全一样问题的人，所以我们需要互补的人"；或者"这个单子我们正沿着一条非常相似的路走，因为我们上次没有足够早地验证这些事，所以这次该早一点验证"。 他的自陈动机："我的工作就是在大量上下文下做决策。如果我能把这件事越来越多地外包给模型，也许我能更快地把自己弄失业。"

  • 单人创始人的结构性劣势（[01:08:38]）："做单人创始人最大的挣扎之一，是你没有人可以碰想法，所以你到达结论的速度慢得多。"（两人此前都做过单人创始人。）
  • ⚠️ 模型不再谄媚了（[01:08:38]）："现在你跟 Fable 之类的谈，说实话挺好的，看起来很有原创性……过去它们就是一堆马屁精，你说什么它都说'好主意'。现在它们会说'不，那是个坏主意，别那么干'。"
  • 一段有画面感的花絮（[01:09:39]）："Mark 有一次贴过他给 Claude 用的 prompt，大意是'跟我唱反调、非常直接'。我用了，非常好用……我拿给我太太说'这个太棒了你也用'。她开了，一天后跟我说：'哇 Claude 一整天都对我特别刻薄，我只好关掉了。'"（⚠️ 这个 "Mark" 转录稿未给全名，本库不做认定。）
  • X vs LinkedIn 的定位差（[01:10:39]–[01:12:40]）：早期主要用 LinkedIn（"我们的客户在 LinkedIn 上"）。
  • ⚠️ 他对 X 的模型很有意思："如果你只是在 X 上推销自己，那完全不会有任何 traction。但它是一条所有人都在读的单一时间线——所以它某种意义上把所有人的注意力都统一到同一件事上了。而这就是在里面有一点发言权的价值所在。"
  • 他转述某人的说法（⚠️ 人名转录含糊、本库无法核实）：过去世界上最大的身份象征是当亿万富翁（"祭司阶层"），"而现在人们成了亿万富翁之后想成为 X 上的影响者，因为那些人握着真正的权力——他们能影响全世界在想什么"。
  • 他现在的做法：不发 Decagon 的事，发对正在发生什么的想法。并指出 LinkedIn 和 X 完全不同，同一个东西两边发都不会都成（LinkedIn 适合发布、产品、融资公告）。
  • 归因很难，但有二阶效应："我在 X 上发了一贴，然后 All-In 播客上的人在聊它，CIO 肯定看到了……CIO 自己整天刷 X 吗？也许不。但如果你在那条主时间线上，总会有这些二阶效应，然后主流媒体记者会来找你。"

十三、就业：Jevons 悖论的一个具体案例

这是本期最该被单独引用的一段（[01:14:43]–[01:18:44]）：

  • 主持人的框问：客服"可能是第一个真正能端到端做完一整份工作的用例"，而编码从一开始就是结对编程。
  • ⚠️ 他们的经验数据："我们一直都能看到这个。我们发现对很多客户来说，客服这类东西的需求其实大于供给。"

    "企业意识到——好，如果我们做客服的成本下降 30%，大多数人不会立刻说'那我现在裁掉 60% 的团队'。他们说的是：好，既然这件对我客户明显有价值的事变便宜了很多，那我就多做一点——好让我的客户留存更久、流失更少、更早激活。"

  • ⚠️ 具体案例（约两年半前）：某客户原有的支持入口带来大约 每月 5 万张工单。

    "他们开始用我们之后说：哇，原来我们的客户有这么多问题。让我们把支持变得更容易触达吧——不要只藏在一个支持面板里，把支持放在每一页上，在人们更容易卡住的地方放得更显眼，并且对免费用户也开放即时支持，而不只是付费用户。" 结论："支持的潜在需求比供给多。所以自动化并不必然导致人们裁掉整个团队。"（主持人的评价："这可能是我听过的现实中 Jevons 悖论最好的例子。"）

  • ⚠️ "杀死岗位，但不杀死职业"（[01:17:44]）：

    "AI 会杀死一些岗位，但某种意义上不会杀死职业，因为那些现在被做的活本来就不该由人来做——非常单调、非常琐碎，是超高量的用例，人只是在接电话、'好，我点这里、点这里，好，答案在这'。那该由 AI 来做。" "但实际上有近乎无限多的事情，人可以去做来让客户更满意、更好地照顾他们。 所以人最后会去做那些事，而越来越多单调可重复的东西会被 AI 吃掉。"

  • ⚠️ BPO 的实际数据是分化的，他没有做单一结论（[01:18:44]）：被追问"你之前说客户用 BPO 做客服的，你并没有真的看到 BPO 那边裁员"，他的回答是——

    "真的取决于情况。 确实有一些场景里人们用 BPO 用得少很多、或者不再需要 BPO 了。也有另一些场景里他们完全不在成本削减模式，他们的目标要么是生意长得太快、不想让运营跟着增长规模（用 Decagon 把它压平），要么是'我们还是需要人，但现在有这些别的、更能产生收入的事可以做'。" 他给的落地顺序："AI 成熟的过程里，你会先从这些砍成本的用例开始，因为那些容易；然后产生收入的用例也该能通过这个对话界面完成。"

  • 相关的一段前置（[00:28:16]–[00:29:16]）：主持人自陈曾劝一位同事别离开 a16z 去前沿实验室，理由是这里有长期职业发展；对方的回答是"我们会有 AGI，长期不需要职业生涯了"——"这真的击中我了，因为我以为我已经很 AGI-pilled 了"。Jesse 的回应："我相当确定 AGI 之后会有职业生涯……我们大多数工作本来就是编出来的——除非你在建基础设施或者种粮食，大多数工作本来就是叠在别的东西之上的一层层抽象。这不是说这些工作没价值，只是它们某种程度上是被造出来的。所以 AGI 来的时候它会改变人的工作，但你仍然会为别的人类做事。"

与本库其它观点的关系

事实性断言与预测（可验证）

  • Decagon 今天 90% 的工作流跑在开源模型上，约一年多前开始转向；剩余 10% 用闭源前沿模型做新项目（公司自报，[00:02:00]–[00:04:00]）。
  • ⚠️ 企业里开源推理的份额"现在其实在下降"，因为新用例都从前沿模型起步（断言，未给数据来源，[00:08:02]）。
  • 每次对话消耗的 token 数随时间上升（更多模型调用/检查/并行）（断言，[00:13:05]）。
  • 某客户从 Sierra 转到 Decagon：在 Sierra 一年建 3 个 journey，转来后约一个月建了 7 个（转述客户口径，[00:38:18]–[00:39:18]）。
  • 某客户接入前月工单约 5 万张；接入后主动扩大支持入口（每一页 + 免费用户）（断言，约两年半前，[01:16:44]）。
  • 创始人之一自陈约 80% 的时间花在销售上（断言，[00:44:24]）。
  • Decagon 已开设 澳大利亚、伦敦、纽约办公室；Raghu Raghuram（前 VMware CEO）在投资之外协助国际化（断言，[00:57:33]–[00:59:33]）。
  • AOP（agent operating procedures） 为 Decagon 自创的流程格式；Duet 与 Duet Autopilot 为其自动化 agent 产品（断言，[00:30:16]–[00:34:16]）。
  • Shyam Sankar（Palantir CTO）的说法："forward deployed engineers eat pain and excrete product"（转述，[00:25:16]）。
  • 预测（Ashwin）：企业自己做开源模型后训练会发生但会慢；护城河的失效条件是"agent 能即时造出部署所需的基础设施"，时限自估约三年（[00:07:02]、[00:36:18]）。
  • 预测（Ashwin）："也许长期来看，应用层公司就变成了特定垂直领域的实验室"；但"软件作为整体不会以任何有意义的方式消失"（[00:20:15]）。
  • 预测（Decagon）：他们所在空间的赢家会是横向的，垂直与市场分层上会发生整合（[01:02:35]–[01:03:36]）。
  • 预测（Jesse）："AI 会杀死岗位，但不会杀死职业"；AGI 之后仍有职业生涯（[00:29:16]、[01:17:44]）。