LangChain CEO 谈推理市场、模型路由与垂直智能体
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
我觉得我们把工程预算的30%都花在编程工具上了。
-
其实过去两个月这个比例还降了，但我们用掉的token数量反而涨了。
-
今天我们请到了Harrison Chase，LangChain的创始人，一家估值几十亿美元的公司。
-
它在创建和监控agent方面是行业领先者。
-
今天请他来到这个位置，聊聊为什么现在构建agent这么难，以及关于agent的未来，有什么是所有人都该知道、却没人知道的。
-
然后是我最喜欢的环节，一些特别古怪的预测，别人都不信会发生，但他确信一定会发生。
-
我真的严重低估了推理的需求。一切都跑得很顺。
-
这个市场太大了。
-
需求实在太多了。准备好了吗？
-
Harrison，兄弟，我太期待这次了。
-
我已经期待很久了，因为我记得Miles在Benchmark的时候跟我提起过你，对你赞不绝口。所以我想促成这件事已经有一阵子了。谢谢你来做客。我很高兴能来。
-
现在，给不了解的人介绍一下，60秒。
-
什么是LangChain，你觉得它在技术栈里处于什么位置？
-
我们做的工具让构建agent变得简单。
-
我们主要做开发者工具。我们有一个开源框架，基本上就是把模型和你构建有用agent所需的其他一切连接起来，比如工具、数据、计算之类的。然后我们还有LangSmith。LangSmith是做可观测性和评估的。agent总是会出错，你怎么知道
-
它们是怎么出错的？
-
你怎么衡量它们，好让它们的表现随着时间不断提升？这就是LangSmith做的事。好。
-
为什么靠问蠢问题为生？这就是我当播客的原因。
-
为什么构建agent这么难？
-
构建agent最难的地方在于，它们不会按你希望的方式行事。
-
所以这些模型就像是这种非确定性的黑箱，对吧？
-
它们把自然语言作为输入，然后输出自然语言。
-
而且在黑箱内部，它们也是非确定性的。
-
所以这意味着你得到的输入在维度上是无限的，可以是任何东西。
-
你把一个聊天机器人放到某人面前，他们可以随便输入任何东西，对吧？
-
这就让人很难知道他们到底会输入什么。
-
然后一旦进入这个模型——顺便说一句，agent可不只是一次模型调用，而是一连串的模型调用，而且它们还在和其他工具交互。
-
所以你就有这些小型的黑箱，被放进这个庞大的系统里，基本上就会产生这种层层叠加的错误。
-
所以你的输入空间非常大。
-
你的输出空间也非常大，因为两个相似的输入进去，可能会得出完全不同的答案。
-
而让这一切变得困难的，正是大语言模型本身。
-
是的，它们非常非常聪明，但你并不确切知道它们会做什么，而且输入稍有变化，它们给出的答案就会变。
-
所以你构建了这个系统，但它其实很不稳健。
-
而让这个系统可靠地运行，这才是最难的部分。
-
比如我们三四年前谈的agent和今天的agent相比，它们已经好了很多。
-
主要发生的变化是：第一，模型变好了；第二，我们搞清楚了怎么构建能更好地驾驭这些模型的系统。
-
而第二部分，也就是对这些模型的驾驭，正是我们专注的地方。
-
随着模型变好，你的业务会以人们看不到的方式发生怎样的变化？
-
随着模型变好，我们业务变化的主要方式就是，我们基本上不得不删掉产品的一大部分。
-
我的意思是——Cursor也说得很好，我觉得这其实是他们公司的一条运营原则，叫“抹掉产品”或者“删掉产品”，他们好像是这么叫的——基本上就是，这些模型越来越好，而你六个月前不得不做的事，
-
你就不用再做了。
-
所以，这一点在我们的开源项目里非常相关。
-
我们的开源项目，基本上就是围绕这个“驾驭”的框架，用来拿这些模型去帮它们做事。
-
而拿这些模型帮它们做事的正确方式，每个月、每三个月、每半年都在变，时间周期你随便挑，但变化是相当快的。
-
面对这么不确定的未来，你怎么去做产品？
-
你是不是只能跟那些实验室绑在一起，搞清楚他们的路线图，免得花六个月做了个东西，结果被他们直接抹掉？这个问题没有简单的答案。
-
一方面，你能怎么办呢？
-
不能不建啊——我经常跟问这个问题的创始人这么说：我该怎么办？
-
东西一直在变，模型在变，我现在做的东西，六个月后可能就没用了。那替代方案是什么？干脆什么都不做吗？
-
所以我觉得，你得对哪些部分将来还会存在、哪些不会存在，做出有根据的猜测。比如早期我们在LangChain里做工具调用，方式是让模型生成JSON、一种DSL，然后再解析它。
-
当时我觉得我们所有人都认为或者知道，这多多少少算是个取巧的办法，但我们必须这么做，因为那是唯一能真正让它去操控事情的方式，你得让它完成这种工具调用。
-
然后几个月后，OpenAI推出了工具调用，我觉得我们很早就意识到……
-
这是一种更原生的工具调用方式，直接内置在模型和API里。
-
我觉得我们很早就意识到那才是未来，所以我们投入了大量精力，直接从JSON解析完全切换到了这种工具调用。
-
所以我觉得，你基本上得分辨清楚，哪些东西是短期的取巧，哪些东西是长期的、会一直存在的东西。
-
模型永远不会知道你的专有数据。
-
它们永远没法真正拿到API的输出。
-
你得把它的API调用拿过来，传给API，拿到输出，然后再继续这个循环。
-
所以我觉得，围绕模型、把它跟其他地方连接起来的这套系统，会一直存在。
-
但我们围绕思维链、规划或者工具调用做的很多取巧手段，那些其实可以更紧密地集成进模型或者模型API里的东西，都会消失。
-
我觉得你就得快点意识到这一点，然后继续往前走。
-
为什么我们需要中立的框架？
-
说白了，我们看到很多非常出色的智能体开发者，就来自模型公司自己。
-
为什么你这一层不会被他们直接吃掉？
-
我觉得我们需要中立框架的原因是，在你构建智能体之前，或者作为智能体运行的一部分，你会积累大量的状态。
-
这些状态可以包括记忆，不管是短期记忆还是长期记忆，记忆也有不同的形态。
-
它可以来自与智能体的交互，也可以来自智能体从环境中学习。
-
这些状态之所以会积累起来，是因为智能体会交互、会出去、会学习、会聊天，然后学到东西让自己变得更好。
-
我觉得现在最有意思的事情之一，就是怎么让这些智能体随着时间推移表现得越来越好、不断学习。
-
其中一部分学习和一部分随时间变好会体现在模型权重里，但很多是在模型之外，很多是在这个上下文里。
-
而现在，当你积累起这个上下文时，你真的不希望它跟某一个模型提供商绑定在一起。
-
原因是一旦绑定了，你就没法换到别的模型了，而能切换模型这件事，进攻和防守两方面都很重要。进攻在于，不管最好的模型是谁出的，一出来你就想能用上它。
-
防守在于，你不想被锁死，免得他们涨价之类的。
-
所以你得能切换模型。
-
这个框架可以跟模型绑得很紧，也可以是中立的。
-
而现在的上下文跟框架是紧密交织在一起的。
-
所以框架的职责，基本上就是拿着模型去跟其他所有东西交互。
-
其他所有东西包括数据和API，也包括记忆。
-
所以如果你构建这个记忆的方式是跟框架绑定的，而框架又跟模型绑定，那你就有点被困住了。
-
你就有点卡在这些状态之间了。
-
所以框架结构的真正价值，抱歉又说一遍，在于它让用户的数据可以自由迁移。对。
-
对，你基本上就是不想被锁死在某一个模型上。
-
而如果记忆、如果上下文开始以一种特定于某个模型与记忆交互、与上下文交互的方式积累起来，那对可迁移性来说就非常糟糕，然后这就会让你在往后发展业务时处于劣势。
-
我们跟很多人聊过“拥有自己的智能”这件事，以及它到底意味着什么，而对此有很多不同的理解版本。
-
我们认为“拥有自己的智能”意味着的版本，我们认为这里面有几个不同的组成部分。
-
但其中一个关键部分，就是拥有这种开放且可控的智能体。
-
你得能够调整所有不同的部件。
-
你得能够调整模型。
-
你也得能够调整框架。
-
因为有时候这些模型实验室在训练框架，让它在对他们来说属于分布内的那些事情上表现得特别好，而这往往就是编程，编程很好，围绕编程有大量的用例，但也有很多用例并不是编程。
-
也许它们会把写代码作为其中一部分，但它们是拿这个来做销售、做研究、做法律，做其他垂直领域的特定事情。
-
所以当你走出模型实验室训练所覆盖的分布范围时，你就想要能控制框架到底做什么。
-
然后你也想要能控制上下文。
-
所以模型、框架本身，还有上下文，共同构成了这种开放且可控的智能体架构，我们认为这就是“拥有自己的智能”很重要的一部分。
-
我想稍微往回退一点。
-
当我们谈智能体的价值，可以这么说，有些人说价值其实在于验证，在于它做得好不好，因为那才解锁了下一步，也就是自动化。
-
如果价值是通过验证产生的，那谁赢？框架吗？
-
如果价值是通过验证产生的，我觉得赢的是领域专家，是那些能够把那个价值量化出来的人，而这非常难。
-
比如构建评估就是一项非常难的工作。
-
所以我认为很多价值会归于那些能写出这些验证器、能捕捉住那部分领域知识的人。
-
正因为这个原因，我非常看好各个领域的垂直智能体，因为我觉得最适合写那些验证器、或者像我们说的那样构建那些评估的领域专家，他们能够构建出框架和模型。
-
而且不会只是框架，也不会只是模型，而是它们某种程度的结合。
-
所以非常实际地说，如果你要开始构建一个垂直智能体，我强烈建议你从框架层开始，做上下文工程，稍微调整一下框架，然后等你有了用户，再开始在后期训练中调整模型。
-
我觉得先从上下文层或框架层入手，投资回报率要高得多。
-
所以我觉得我们会看到所有这些不同的垂直领域。
-
他们能够以一种非常领域特定的方式，把对他们来说什么算好量化出来，这会让他们不仅能构建垂直智能体，还能构建垂直智能体的体验。
-
不同的智能体可能有不同的体验。
-
所以我觉得很多价值会……
-
我非常看好垂直智能体，所以我们想推动其中的很多事。
-
你说过，如果是我来构建那个，我会从框架层开始。
-
我们看到很多公司，不管是Harvey还是我记得是Ramp，都在构建自己的模型。
-
他们到底在多大程度上是真的在构建自己的模型？
-
Mike Cannon-Britts上次上节目的时候，他很明确地说，这基本上——恕我直言——是胡扯，他们只是在微调开源的中国模型。
-
这是真的吗？你怎么看这件事？
-
我觉得很大程度上，他们是在后期训练开放权重的模型。绝对是这样，我仍然觉得这是一件有价值的事。
-
我不觉得这有什么问题。我觉得在拥有自己的智能这件事上，你可以往不同维度走。我觉得最便宜的方式就是你只控制上下文，用一个现成的框架、现成的模型。再往下一层是，
-
你开始调整框架，这比只控制上下文给你更多掌控，但做起来会稍微贵一点。
-
再往下一层，你对一个开放权重的模型做后期训练。
-
所以你可能会拿一个现有的开放权重中国模型，针对你的领域做后期训练。
-
然后最底层，就是他们真的从零开始训练一个模型。
-
我觉得没多少人真的从零开始训练模型，大多数都是在做后期训练。
-
我觉得如果你要从零开始训练一个模型，那你大概得是Neolab那种级别的。
-
我觉得他们算是少数几个在做这件事的。
-
不过话说回来，像Ramp和Harvey这样的公司，他们人才济济。
-
他们有大量数据，有大量使用量，也在琢磨怎么真正把它优化好，所以他们已经把上下文能榨的都榨干了，把框架能榨的都榨干了，现在基本上就走到对这些模型做后期训练这一步了。
-
我想问你，就像我们刚才提到的，这些专门化模型在后期训练领域的实际效果，目前还没有定论。
-
有些报告说效率高得多、效果也好得多，有些则说没那么好。
-
你觉得这事会怎么发展？
-
就后期训练来说，我们看到的情况是，现在真正有实际意义的后期训练，大多是用在那些构成更大框架的较简单任务上。
-
我的意思是，当你有一个在做有意思的事情的智能体框架时，实际上很少是只有一个模型在跑这个循环。
-
那可能是核心，但还会有很多其他的模型调用，要么是作为护栏，要么是做路由，要么是子智能体、子工作流之类的。
-
所以我们现在看到后期训练效率高的很多地方，都是用在比较简单的任务上，比如分类、抽取或者摘要，这些可能是智能体用的一个工具，或者一个护栏之类的。
-
我觉得这类后期训练现在非常合理，以后也会继续这样。
-
我觉得更没答案的问题是那个驱动循环的核心模型，因为智能体运作的主要方式就是一个大语言模型在循环里调用工具。
-
所以问题是，对于这个驱动循环的模型，它们会是那种后期训练出来的模型，还是那种前沿模型？
-
我觉得这地方我们看到更多的是来回拉锯，就是每出一个新的前沿模型，它们在跑这种核心循环上都更强。
-
我们确实看到Harvey、Ramp这些公司在尝试用后期训练的模型来跑这个核心循环。
-
所以我觉得Harvey最近，大概过去一个月左右，就宣布了正好是这个方向的东西。
-
我觉得这还是个没有答案的问题。我觉得……
-
如果你自己在做一个垂直应用，你会自己去做后期训练吗？
-
一开始不会，绝对不会一开始就这么做。
-
但如果我们说的是五年之后，假设我用量非常大，我觉得这确实有可能。
-
我想，harness还需要做的一件事就是根据请求做模型路由。
-
模型路由这一层到底有多大价值？
-
模型路由特别有意思，我觉得这是现在最热门、可能也是最有争议的话题之一。我说几点想法。
-
首先，有个问题是模型路由到底该放在哪儿。
-
应该放在harness这一层，还是放在网关这一层？
-
这就有点深入到技术细节了。
-
抱歉，这两者有什么区别？
-
区别在于，放在harness层，就是放在它运行时的代码里；而放在网关，就只是一个API调用。
-
放在网关层的好处是，因为它只是一个API调用，你可以把它插进任何harness里。
-
你可以把网关层做的这个路由直接用到cloud code里，用到任何harness里，都不用改代码。
-
坏处呢，也是为什么我们更看好把路由放在harness里——我记得factory和cognition也写过类似的东西——是因为在harness里，你对正在发生什么了解得更多。
-
你对状态的感知更清楚。
-
而API一般假设自己就是类似OpenAI Chat Completions API那种形式，所以它只能接收一定量的状态信息。
-
在harness里你有更多的状态信息，能知道，嘿，prompt缓存现在是什么情况？
-
你会想让prompt缓存保持热着、随时可用。
-
你也能更容易地改prompt。
-
因为很多这些模型有不同的提示策略。
-
所以如果你在harness层做路由，改prompt就更容易。
-
所以我觉得我们看到的情况，很大一部分就是关于网关和harness之间、路由到底该放在哪里的这场争论。
-
我觉得我们大概认为它应该放在harness里。
-
先让我们搞清楚OpenRouter和其他那些提供商，这类有好几家，而且很多。
-
它们在网关这一层，它们在网关这一层。
-
显然，OpenRouter是家很厉害的公司，用量惊人。请过他们上节目，很喜欢Alex，Alex很棒。
-
我觉得很多人用OpenRouter、Vercel和其他网关，很大程度上主要是为了获取模型。
-
所以我觉得路由器和网关之间也是有区别的。
-
所以我大概会说，OpenRouter的大部分用量，Alex显然比我清楚这些数字得多，但如果让我猜，我会猜其中很大一部分只是因为它是个网关，而不是路由器。
-
所以人们会事先指定想要哪个模型，而OpenRouter只是提供一个统一的API和一把统一的API key来访问它。
-
至于智能路由，我觉得实际用上的比大家以为的少得多。
-
而且我觉得真用上的时候，也是像Factory这样的公司把它做进harness里的。
-
我觉得Factory在这方面做得非常出色。
-
他们写了不少技术博客，讲他们怎么做路由，写得非常好。
-
但我觉得目前，我相当坚定地认为，路由必须得了解harness。
-
你得知道任务是什么。
-
你得知道harness长什么样。
-
所以我不认为会有那种既适用于法律、又适用于金融、又适用于编程，全都一样的路由。
-
它会非常依赖具体领域，也非常依赖具体harness。
-
不好意思，听你这么一说，路由应该放在harness层，考虑到那里存储的记忆上下文，这似乎是不容置疑地显而易见。
-
当我遇到这么显而易见的回答时，我就想弄明白，我是不是傻？
-
那把它放在网关层，理由是什么呢？
-
我觉得人们说放在网关层的时候，大概说的是两件事。
-
第一，这样迁移起来容易得多。
-
所以你可以直接用 Claude Code。
-
大家都很喜欢 Claude Code，对吧？
-
如果你跟人说，嘿，你不能用 Claude Code 了，你得用另一个 harness。
-
市面上确实还有别的不错的 harness，但咱们先假设你就是特别喜欢 Claude Code。
-
你想让他们继续用这个，但又想做点类似路由的事，比如路由到 DeepSeek 或者某个开源模型之类的。
-
那唯一的办法就是在网关层做，因为你控制不了那个 harness。
-
顺便说一句，这也是支持开源 harness 的另一个理由，因为你能控制和修改它。
-
然后第二点，人们说在网关层做路由的时候，我觉得他们往往默认存在某个领域。
-
所以大概有两个通用领域，你或许可以说能为它们构建通用路由器。
-
而且我觉得 OpenRouter 在某种程度上已经做到了。你可以说编程就是一个。
-
编程是最热门的领域，所有的使用量都在往那儿走。
-
咱们来做一个对编程特别好用的路由器。
-
也许我们做不到感知 harness，但我们可以做到感知用例。
-
我们知道在编程里不同的模型擅长不同的事，然后把它放在网关层。
-
另一种情况是，嘿，我们有个这种通用聊天机器人。
-
我们不是想在法律领域做到顶尖，也不是想在金融领域做到顶尖，我们就是想做一个公司里通用的聊天机器人。
-
而且我们足够清楚，如果你说“嗨，你好吗？”
-
这种事你不需要用 Opus，用个便宜的模型就行。
-
所以我觉得，大家聊网关层的路由时，其实都默认你做的要么是通用聊天，要么是编程，而不是某个特定领域的东西。
-
一旦你进入某个特定领域，我真的觉得路由必须放在 harness 层。
-
那种情况下你不会用现成的网关路由器。
-
所以你觉得两三年后，大部分路由会因为上下文带来的好处而放在 harness 里，但对于非常通用的任务，还是会放在网关。我觉得完全是这样。
-
如果你在做垂直领域的 agent，我觉得路由就得放在 harness 里。
-
如果你考虑的是通用的横向任务，比如普通聊天或者编程，那也许可以放在网关。它算不算商品化？
-
就是大家都会自己去做吗？
-
我不觉得路由是商品化的东西。
-
我确实觉得大家会去做，但我觉得就算在今天，做这个也挺难的。
-
我觉得部分原因是模型变化太快了。
-
你可以说某些模型在某些方面更强，但接着一个新的 OPIS 或者新的 OpenAI 模型出来，它在所有方面都更强。
-
那路由的价值就下降了。你信任 evals 吗？
-
我觉得 evals 有用，但我不会完全信任它们。
-
我的意思是，现在很多学术界的 evals，就是很多模型发布时会用的那些，其实已经没那么有用了。
-
我觉得现在出来的所有模型，基本上都在那些 evals 上刷到顶了，所以你学不到太多东西。
-
我觉得你自己内部做的、针对你所在领域的 evals，绝对还是有用。所以我会……
-
我是说，这就是为什么构建 evals 是打造垂直领域 agent 如此重要的一环。
-
我觉得你总得有某种衡量方式。
-
而且我觉得一般来说，你可以信任那些 evals。
-
但即便如此，最重要的事情之一就是去看数据。
-
就是去看数据，看看它到底在做什么。
-
别太依赖某一个单一的数字。
-
我觉得这就是为什么你需要 traces，你需要去看看具体发生了什么。
-
也许你的 evals 并不完美，evals 真的很难做，你能有一些感觉，但也许模型表现得更好了，只是用了一种你之前不知道怎么捕捉的方式。
-
所以我确实觉得，是的，你可以信任垂直领域的 benchmarks，但你也得让它们不断演进，这就是我们看到的主要情况之一，因为这些模型就是在以不同的方式变得越来越好。
-
我能问你一下吗，你刚才提到 traces，如果 traces 是 agent 工作的产物，那价值到底在哪里？
-
是在应用层、可观测性层，还是模型层？到底在哪？
-
如果你在构建一个 agent，我觉得价值就在于让这个 agent 在你所处的领域或垂直行业里表现出色的那些东西。
-
我的意思是，再说一次，我觉得控制 agent 行为有几种不同的方式。
-
有上下文，有 harness，还有模型。
-
在这些方面拥有专有的东西，都可能是一种优势。
-
我觉得控制上下文是最简单、也是最显而易见的起点，比控制 harness 要容易。
-
那包括数据、记忆、特定的 API、你能用的特定工具。
-
控制 harness 会稍微难一点，但你仍然可以把很多领域知识放进去，比如该做什么、路由以及里面的各种东西。
-
然后模型是最难控制的，但潜在的上限也最高。
-
而让你能在这些方面不断迭代的，就是 evals 和 traces。
-
所以这些东西有巨大的价值，但价值只在于你能从中捕捉到洞察，再把它带回上下文、带回 harness，或者带回模型。
-
而这个具体的过程可以各不相同。
-
所以后训练，非常适合把这些来自 traces 的洞察带回模型。
-
要把东西带回上下文或记忆，你大概会想在这些 traces 上跑另一个 agent，然后让那个 agent 输出类似给记忆用的学习成果。
-
而要把 traces 里的这些学习成果带回 harness，你大概会想在这些 traces 上跑一个 agent，去更新 harness 本身的代码。
-
我们其实有个东西能帮大家做这件事，叫 engine。
-
它是 LangSmith 里的一个 agent，会跑在 traces 上，试着去更新代码。
-
然后当你更新了这些东西，你得知道它确实变好了，这就是 evals 派上用场的地方。
-
我能问一下，持续学习会怎么改变 agent 以及它们的运作方式？
-
持续学习，我觉得它不太会改变 agent 的运作方式，但我觉得它会改变你希望在 agent 周围运行的那些系统。
-
我的意思是，我觉得对一个持续学习的 agent 来说，核心循环，也许可以说是核心内循环，大体上还是不变的。
-
它会是一个 大语言模型 在循环里跑，调用工具，和模型以及环境交互。
-
我觉得持续学习加进来的是一个外循环。
-
一个外循环，去看 agent 产生的那些输出，然后拿它去做点什么。
-
而且再说一次，它具体做什么，可能取决于持续学习对你来说意味着什么。
-
所以我觉得持续学习也是那种没有特别精确定义的说法，或者说……你会怎么做？
-
我会把它定义成一个随着时间推移变得越来越好的系统。
-
随着它运行，再说一次，它变好的方式有很多种，它可以更新上下文，可以更新 harness 的代码，也可以更新模型的权重，而外循环对所有这些来说大致是一样的。
-
它会是这样：拿 traces，得到学习成果，修点东西，测量一下确认它变好了，然后重复，但那个具体做法，再说一次，更新模型权重和更新一个像记忆文件那样的文本文件，是非常不一样的。
-
如果我们看上下文这一层，我们提到数据是其中一部分，我们看到数据公司以史上最快的速度把营收做到几亿美元。我是说，史上最快，最快，最快。
-
而且人人都在卖数据。
-
考虑到你不参与其中、只是与之相邻的中立立场，你预期这个市场会怎么发展？
-
未来几年，这会是一个走向整合的市场吗？
-
你觉得它会怎么发展？
-
其实我觉得，从大局来看，数据市场还处在相当早期的阶段，毕竟我们说的是某种面向智能体的上下文层。
-
我的意思是，现在有一堆数据库，ClickHouse 可能就是个很好的例子，它最近做得特别好，我觉得它们基本上还是专注于……它们就是个数据库。
-
它们是那种老派的数据库，擅长存储数据和查询数据，但用的还是相当传统的方式，ClickHouse 在 AI 出现之前就存在了。当我们谈到面向智能体的上下文层，而且再说一次，软件系统会产生大量数据，这很好。
-
我觉得现有的数据库，ClickHouse、Mongo、Elastic 什么的，都很适合做这个。
-
当我们谈到面向智能体的上下文层，我觉得其中一个关键部分是，没错，里面有个数据库，但我其实觉得数据库周围还有一套系统。
-
我觉得面向智能体的上下文层，更像是一个围绕数据库的智能体，而不只是一个数据库。
-
原因在于，要把所有这些学到的东西摄取进数据库，你需要某种智能来做这件事。
-
而我觉得这种智能其实非常非常难。
-
记忆最难的部分其实根本不是数据库。
-
我们跟不少公司聊过，他们做记忆的方式就是把它存在一个文件里，非常简单。
-
但难的部分是，把所有发生的观察——不管是用户跟软件交互，比如说传统的 SaaS，还是用户跟智能体交互——提炼成足够有价值、能放进这个上下文层的信息。
-
这就是现在记忆最难的地方。为什么这么难？
-
因为要让 大语言模型 做你想让它做的事，这很棘手。
-
而这种元反思，我觉得 大语言模型 其实还是很吃力，比如反思提示词、改进提示词，反思智能体架构、改进智能体架构。
-
我们应该在内部为这个建一个基准测试。
-
我们确实有一些这方面的基准测试，就是 engine，那是我们跑在各种任务上的智能体，但我觉得这种元反思对智能体来说还是真的很难。
-
我觉得这对人类来说一般也是件难事。
-
我不知道我们是不是真的理解，有些人可能理解，所以我不该这么说，但我不确定我们是否理解我们大脑里发生了什么。
-
我感觉我们的大脑仍然是复杂的东西，我们并没有完全理解。
-
所以如果我们现在想在一个系统里复制这种学习过程，我觉得这里面有很多不同的部分。
-
所以我觉得你得，对，我觉得模型在反思这方面还不太行，而且我觉得我们也不知道这个系统应该长什么样。输入应该是什么？输出应该是什么？
-
这个智能体的框架应该是什么样的？
-
不同的工作流应该是什么样的？
-
十二个月后模型在反思方面会有明显提升吗？大概会。
-
我是说，它们好像什么都会变好。
-
你觉得模型改进的速度会继续保持这种加速的势头吗？
-
还是说你觉得我们正在接近某种渐近的平台期？
-
我觉得模型改进的速度这事，不在实验室里面的话真的很难说。
-
我想说的是，我觉得有很多任务，模型的改进会趋于平缓，因为已经够好了。
-
比如我觉得有一堆任务，模型就是已经够好了。比如写代码。
-
对，写代码快到位了，还有摘要、路由这类任务。
-
可能还有更难的任务，或者我们甚至都没想到要去想、没想到要丢给模型的任务。
-
我大概会说，这种元学习就是模型现在还不擅长的任务之一，我猜这对实验室来说非常重要，比如在攻克递归自我改进之类的事情上。
-
所以我确实觉得模型在这方面会随着时间变得更好，而且有可能这个进展看起来会比之前快得多。
-
我觉得不在实验室里面，真的很难有一个有根据的判断。
-
有些任务已经饱和了，还有些任务我觉得可能只会比以前增长得更快。
-
现在有什么智能体的事听起来很疯狂，但你觉得两三年后会变得极其普遍？
-
我是说，我觉得智能体的这个记忆层还远远没被解决。
-
我觉得智能体有一件事现在很罕见，但未来几年会变得极其普遍，就是这个记忆层。
-
我的意思是，如果你看看像 Instinct 或 Muse 这样的产品，我觉得它们做对的一点就是这种个性化、学习和让人觉得这是为你量身定做的，不管是因为它说话的语气，还是因为它会主动跟进、有那种主动性。
-
所以我觉得记忆这块还非常非常早期。
-
我们跟人聊记忆已经聊了大概两年了，也试着在开源里做点东西，我们发布了一个 alpha 版本，后来又把一个商业化的记忆方案给砍掉了。
-
记忆这块真的太早期了，而且太依赖具体领域了。
-
对 Instinct 或 Muse 来说，记忆长什么样，其实跟一个公司或组织用的工具里的记忆挺不一样的，跟法律、金融这些领域里的记忆也很不一样。
-
所以我觉得记忆是真正能带来差别的一件事。你能看到它确实带来了差别。
-
我觉得 Instinct 和 Muse 在这方面做得很好，所以你能看到它在那里带来了差别。但我觉得这还非常非常早期，我预计几年后所有产品都会带点记忆的功能。
-
恕我直言，这难道不是挺明显的吗？
-
我觉得记忆会有影响这件事确实挺明显的，这也是为什么你看到这么多人对它感兴趣，过去几年一直都对它感兴趣。
-
但我还是觉得答案是什么并不明显。
-
我还是觉得答案是什么极其不明显。
-
我不认为有谁知道记忆的答案是什么。
-
既然这事这么明显，而且几乎所有东西都明显需要它，你为什么要砍掉那个商业方案呢？
-
我觉得我们砍掉它是因为没找到产品市场契合点。
-
为什么没找到产品市场契合点呢？
-
我觉得我们其实是做得太通用了。
-
我觉得记忆现在太早期了，所以我觉得你想做的很多方案其实都非常依赖具体领域或具体智能体。
-
所以你会去做针对具体垂直领域的记忆方案。你会怎么做才不一样？
-
回到记忆最难的部分是什么，我觉得最难的是那个从事实中学习、判断该记住什么的过程，以及那个负责记忆的智能体。
-
就像我说的，我非常看好垂直领域的智能体。
-
所以我觉得，让这些智能体擅长学习各自领域特有的东西，是其中的关键。
-
所以我的确认为，这类学习型智能体至少在起步阶段，大概必须是领域特定的。
-
我也不确定是否存在一个通用的，就是说这些学习型智能体的框架到底长什么样？
-
它大概会跟我们现在的很多框架挺像的。
-
它大概会挺像的，我们做了deep agents。Deep agents就是一个智能体框架。大概跟那个差不多。
-
我就是在跑这个循环，但它有特定的指令和特定的工具。
-
也许还有一些特定的子智能体，它们特别擅长，你知道，在已有的记忆结构里导航，或者提炼出事实，所以我觉得你会有专门处理记忆这类事情的智能体。
-
我只是觉得它们会是领域特定的。你觉得消费类应用会有垂直智能体吗？
-
我理解，我也同意你的看法，你看金融、会计、销售、营销、法律，你提到muse和instinct，它们会是横向智能体。
-
你觉得我们会有垂直的消费级智能体吗？
-
我对消费领域的看法是，两者都会有。横向和垂直智能体都会有，而且横向智能体会跟垂直智能体交互。
-
什么情况下适合有垂直智能体，什么情况下不适合？
-
我觉得对大多数应用来说，大概都适合有一个垂直智能体，而我觉得垂直智能体之所以说得通，原因大概有两方面，也许更多，但马上想到的有两个。
-
第一，这些应用里很多都掌握着关于你的信息，能比一个通用的横向智能体更好地学习你如何使用那个应用。
-
所以回到领域特定性这一点，你使用音乐的方式，比如说Spotify，跟你使用Strava的方式非常不一样。
-
所以那些应用其实大概最擅长学习关于你的东西。
-
而我觉得把这些学到的东西呈现出来的最好方式，大概就是通过一个智能体。
-
另一件事是，这些应用里很多都有大量的API。
-
所以你可能会说，嘿，你知道，Spotify，别做智能体了，就把一堆API暴露出来就行。
-
我其实觉得，如果有一个智能体把这些API包起来，对外提供一个，也许是多个，但大概是一个自然语言接口，让横向智能体去跟那个垂直智能体交互，体验会更好。
-
当智能体成为网站的基本接口时，基础设施会怎么变？
-
我的意思是，你知道，我想要某场演唱会的票，我就说每五分钟查一次，只要有座位空出来就买，结果它连着三天每五分钟就查一次。
-
查询量是人工操作时的一千倍。
-
在智能体交互或人类交互的世界里，基础设施需要怎么变？
-
当智能体在交互时，请求数量会大幅上升。
-
我觉得，我觉得你看到过一个新闻，好像是Rezzy封了一个用户的账号，因为那人用Instinct去抓取，我不知道频率多高，但挺频繁的。
-
所以我觉得，是啊，基础设施承受的压力就是大得多。
-
这怎么传导到更底层的层面？
-
这个我还不确定自己有没有看法。
-
我觉得你得构建能承受更强突发流量的系统，能扩展得宽得多。
-
更具体的我就说不上了。
-
你觉得服务商会允许智能体使用吗？
-
我觉得未来是服务商推出自己的智能体，让人们要么直接跟那个智能体交互，要么让人们自己的横向智能体去跟那个智能体交互。
-
所以我的横向智能体，我就是想搞清楚这一点，会去跟Rezzy的垂直智能体交互。
-
我觉得完全就是这样。
-
那这为什么行得通？
-
因为这仍然解决不了很多这类企业面临的两个核心问题：广告。
-
他们失去了那套广告模式，然后追加销售也没了，还有你可能喜欢的其他东西，那些侧边推荐也没了。所以你的客单价就降低了？
-
智能体对智能体为什么行得通？
-
我觉得你可以在智能体的回复里包含一些这类东西。所以你可以在Rezzi或者Etsy之类的平台上为特定商品做广告，然后把它放进智能体的回复里。比如，嘿，我找到了这三样东西。
-
你可能还会想考虑另一个东西。这就变成了一段自然语言的回复，传回给主智能体。我觉得这也关系到系统压力的问题。因为如果你有一个垂直领域的智能体，
-
它跟底层系统交互时，会比第三方智能体更好、更高效。
-
所以我觉得这会让它们做这件事的效率高很多。
-
当我们看查询的数量，以及智能体带来的那种体量变化时，完成所有这些工作要消耗大量token。
-
token的成本、也就是这种智能的成本，随着时间会怎么变化？
-
因为我们一直以为它会越来越便宜，结果并没有便宜多少。
-
那我们到底该怎么看待这个问题？
-
成本是我们现在跟人聊的时候重点谈的大问题之一。
-
我觉得这有几个不同的维度。
-
第一，我觉得前沿模型相对来说是在慢慢变便宜的。
-
Astra的性价比，跟一年前存在的很多东西比，简直太棒了。
-
第二，需求就是多了太多。
-
当你开始谈智能体跟智能体对话，或者多智能体系统的时候，被烧掉的token就是多得多，所以成本在往上涨。
-
我们在编程这块主要看到这个现象。
-
编程成本一路飙升，我觉得很多组织，包括我们自己在内，现在都在想办法把这些成本压回来。
-
这事最后怎么解决？
-
如果你看我们是怎么处理编程智能体的，我觉得那里有一些线索。
-
我们处理编程智能体的时候，会把它分成三步来想。
-
第一，我们基本上就是想先做到可见性，让管理员看到大概会花多少钱、已经花了多少钱。
-
第二是成本控制，所以你可以说，嘿，去帮我订个位子，但别花超过5美元。
-
然后第三点其实是直接影响harness本身。
-
所以我觉得，很多harness工程主要是围绕让智能体更高效来做的，因为那是……
-
或者说，抱歉，很多harness工程是为了让智能体本身更好、更准确，因为那才是最大的障碍。
-
我觉得随着成本越来越受关注，我们看到大家更在意提示缓存这类东西，它们对降低成本确实很有帮助。
-
我们看到模型提供商也在让这件事变得更容易，这说起来有点细枝末节了，但他们引入了一些功能，比如可以在运行中途更改智能体可用的工具。
-
以前这么做会破坏缓存，导致成本大幅上升。
-
现在你可以动态地加上这些，成本还能保持不变。
-
所以我觉得，无论是在模型API还是harness层面，大家都在更关注成本控制。
-
你现在跟大型企业聊，他们最看重什么？对他们来说什么最重要？是准确性吗？
-
是成本，还是安全性？
-
顺便说一句，还有一个是延迟。
-
我们每年都做开发者调查，问开发者在意什么。
-
过去两年，排第一的回答基本都是准确性，差不多是第二、第三名的两倍。
-
所以那仍然是首要的。
-
接下来两个是延迟和成本，安全性稍微靠后一点，但也很接近。
-
最近我们跟大型企业聊，我觉得成本方面的担忧上升了。
-
我大概还是会说它低于准确性，但可能高于延迟，然后安全性，对大型企业来说，安全性更高一些，但可能还是低于准确性和成本。
-
我能问你一下吗，大概来说，不是具体数字，你们花在编程工具上的钱占工程师薪资的百分之多少？
-
我觉得我们大概把工程师薪资的30%花在了编程工具上。
-
其实过去两个月这个比例还降了。
-
虽然token，我们用的token数量其实反而涨了。
-
所以这个，我们是通过三步做到的。
-
第一步基本上就是可见性。
-
我们把所有编程agent的使用情况都追踪到LangSmith里，这样就能看出谁花了多少、花在什么上。
-
我们可以基于这些做分析。
-
第二步就是基本的成本控制。
-
我们设了个类似预算的东西，如果你超了预算，可以去找我们的工程VP，他几乎总是会给你提高，但这只是个保险措施，防止agent被用错或者陷入死循环。
-
然后第三步就是我们控制harness。
-
所以我们做的一件事就是自己内部建了一个云端编程agent。
-
不是IDE，也不是终端里的agent。
-
那方面大家想用什么就用什么，但我们自己建了一个云端agent，叫OpenSui。
-
我现在写代码只能靠它了，因为我一直在Slack上，所以我就从Slack给它发消息，它就启动了。
-
但在这个harness里，我们做了不少工作来控制成本。
-
比如prompt缓存，还有路由之类的东西，我们都做进了这个harness里。
-
我其实觉得这套三步流程挺可复制的，能把编程agent的花费控制住。
-
就是第一步可见性，第二步基本控制，第三步试着改进harness本身。完全理解。
-
我就是想把这个展开聊聊。
-
你提到可见性，看谁花了多少。
-
花钱最多的人是不是效率最高的？
-
有时候花钱最多的人效率最高，有时候又不是。
-
我的意思是，我们有几位资深工程师花得很多，我百分之百相信他们做的事完全值这个钱，这点毫无疑问。
-
我们也遇到过一些挺蠢的错误，或者说是配置不当之类的问题，反正就是用量突然暴涨。
-
举个例子，有一两个任务里用到了某个插件，它基本上会截屏或者抓取网页的DOM快照，然后代理每跑一轮就把它发回去，因为他们当时在做前端工程，想看看页面长什么样就直接发回去
-
发回去。
-
结果就一直在跑一个巨大的循环。
-
所以我觉得光那一件事，我们一周就花了四万美元。
-
所以碰到这种情况，再说一次，我觉得我们公司整体上挺宽松的，也信任大家，但我知道那笔钱大概是不值的。
-
所以这只是一个例子，再说一次，那不是恶意的，甚至都不是有意这么用的，真的就只是个失误。
-
所以我觉得光是能及时发现这种情况，就非常值得。
-
所以这要看处在光谱的哪一端。
-
就像你说的，工资的30%。那是个粗略估计，对。
-
粗略估计，完全没问题。
-
那两年后会是什么样？
-
我觉得估算编码代理支出最难的地方在于，各个组织的变动实在太快了。
-
我的意思是，我觉得未来会出现这样一种情况：组织规模小得多，而编码代理的支出跟人的工资一样多甚至更多，或者多出一个数量级。
-
然后你有一小部分人，以极快的速度、极高的效率在推动和执行。
-
我觉得这是个挺诱人的愿景，就你思考的东西而言。
-
我觉得，我不认为很多公司，包括我们，大概都还没到那一步。
-
我觉得我们仍然看到，需要一群背景各异、专长各异的人在一起协作，有大量的沟通、开销、评审，而且，是的，
-
理想情况下是一个人驱动100个代理，把构成产品很大一部分的东西全都带起来。
-
但我觉得我们只是看到，这仍然有很强的人的因素在里面。所以我花了很多时间思考组织设计，比如，有没有可能让很小的团队、一个人的团队、两个人的团队来驱动代理。
-
我觉得这非常诱人。
-
在那种情况下，我会说，你知道，代理的花费可能是三倍的成本，但另一方面，能做到这一点的工程师也极其有价值。
-
所以也许实际上它就会保持不变，因为真正能做到这一点、能驱动所有这些代理的人，人数更少了，但你付给他们的钱多得多。
-
所以花费实际上保持不变。
-
所以，我觉得组织设计现在非常非常有意思，也正因为如此，我觉得这个问题其实很难回答。
-
对我来说，那个数字太核心了，因为它是决定Anthropic企业价值的根本因素。
-
如果那个数字变成5%，那2万亿美元的IPO可能就有点定价过高了。
-
如果那个数字真的像麦考那样达到300%，那它就是被严重低估了。
-
所以，这就是为什么我这么关注它。
-
你同意那个数字是Anthropic价值的基础吗？
-
我觉得那个数字是Anthropic价值的基础，这大概是对的。
-
我觉得棘手的地方在于，到目前为止，我们真正看到代理产生效果的唯一领域就是软件工程。
-
而企业里还有一大堆其他领域，我认为尚未受到代理的影响。
-
所以我觉得有可能，再说一次，软件工程，我觉得很难预测，但我觉得这里基本上有两个杠杆。
-
一个是软件工程里会发生什么？是和今天一样？还是更多？还是更少？
-
但我觉得毫无疑问，对于其他领域，它会比今天多得多。
-
所以从这个角度看，我觉得这对Anthropic、OpenAI和其他模型提供商来说是非常看涨的。
-
我觉得很多人还在问的另一个问题是，开源模型的激增以及这如何改变格局。
-
你和一些非常大的企业合作。
-
我的一位好朋友，SAS的Jason Lemkin说我不该模仿他的口音，因为我会搞砸，我以前模仿过，他觉得效果不怎么样。他说不太好。
-
你觉得大型企业会害怕使用中国的开源模型吗，还是其实他们并不介意？
-
我们看到有些企业确实害怕使用中国的开源模型。
-
我们也看到另一些企业根本不太在意。
-
你觉得这种担心合理吗？
-
我不太觉得这种担心是合理的。
-
我觉得存在一些不同的顾虑。
-
我觉得一个顾虑是，它运行所依赖的数据会不会以某种方式回流到中国的实验室。
-
再说，如果你用的是Fireworks或者自己托管，我觉得那就纯属无稽之谈了。
-
我觉得还有其他担心，就是它训练所用的东西会让它的回应方式不符合企业的价值观之类的。
-
我觉得这正是评估能派上用场的地方，我认为这种担心基本上是没有根据的，但当然，也许在某些领域，确实有点道理。
-
我觉得这大概，我觉得这大概基本上是没有根据的，但在某些领域，因为那种回应方式，我能看到其中确实有些微妙之处。
-
你觉得未来12个月里，我们会拥有可比的美国开源模型吗？
-
我觉得未来12个月里，我们绝对会有可比的美国开源模型。
-
我觉得你看看NVIDIA为了跟生态合作所做的一切就知道了。
-
我觉得他们非常在意这件事。
-
我觉得你看看Reflection最近发布了一个模型。
-
我觉得它在某些基准测试上还是稍微落后于一些中国模型，但我觉得那个领域投入了极大的关注，所以我绝对相信会赶上来。
-
我能问你吗，当你审视今天开源模型的格局时，以你的位置来看，有什么是外界看不到而你看得很清楚的？
-
我觉得说到开源模型，它们的用量很大，但我确实觉得它们更多是用于比人们想象中更窄的任务。
-
所以我觉得我们看到很多人用的开源模型和后期训练模型，比我一年或一年半前预想的要多。
-
但我还是觉得它们主要用于那些比较简单的任务，比如路由、护栏、抽取或者摘要。
-
我不觉得它们真的在驱动很多主要智能体的核心智能体循环。
-
所以我觉得开源模型这事儿挺有分歧的，因为有些人站在一端，觉得太好了，它们够用了，什么都用它们吧。
-
但我觉得它们还没到那个程度。
-
然后我觉得还有另一拨人，你知道，他们会说前沿模型只会越来越好、越来越便宜。对，这话没错。
-
但如果你真的清楚自己要做什么，也就是你得有一个高用量的场景，而且其中有些环节足够简单，那我觉得针对这些场景去做后期训练或者用后期训练模型，投资回报率是非常好的。
-
所以我说，可惜的是，这大概是个比较微妙的立场，介于我觉得推特上那些极端观点之间。
-
你怎么看推理市场接下来的走向？
-
你提到Fireworks，我们很公开地是Fireworks的大投资方，我很喜欢Lin和这个团队，但所有人都在做这件事。
-
你知道，我们节目请过Crusoe的Chase，他们业务里也有这一块。
-
我跟Nebius那帮人是朋友，他们业务里也做这个。
-
这块业务会怎么发展？你怎么看必须做全栈，还是像Fireworks或Base 10那样只做推理的提供商？
-
我觉得说到推理这块接下来会怎么发展，有一件事我……
-
从LangChain起步到现在，有两件事我确实严重低估了。
-
一个是对……的需求，另一个是对编程智能体的需求。
-
我觉得这两个市场都比三四年前我想的大太多了。
-
所以我觉得其实是Benchmark的Eric Visscheri最近在推文或者播客里说的，他基本上就是说，一切都跑通了。
-
这个市场太大了。
-
我觉得Thomas Tungs也说过类似的话，就是说推理市场太大了，以至于……
-
我觉得Eric说的范围比推理更广，但我觉得套用到推理上也成立。
-
我觉得任何推理方案都能行得通。
-
就是说，你知道，需求实在太大了。
-
我也不知道这需求短期内会不会减少。
-
所以，是啊，当然，Fireworks能行，AWS能行，Crusoe也能行。
-
我就是觉得需求太大了。
-
那你今天不会投哪些领域？
-
我可以给你举几个例子。
-
我觉得客服这个领域特别没意思。
-
20家供应商，过去18个月全都融了超过1亿美元，那儿还有Salesforce和Atlassian这些大玩家，还有Intercom和TalkDesk这种稍微老一点的也在做。行吧，挺好。
-
所有机器人领域，比如bold tape，但投进机器人的钱太多了，可离拥有ChatGPT时刻还差得远，尤其是人形机器人，在形态上真的很难搞。
-
我就是觉得融资和热度远远超过了实际能力，这就是我的回答。
-
我愿意认为自己算是个乐观主义者，所以我觉得，我确实觉得这项技术是变革性的，所以我觉得会有大量机会。
-
我觉得，所以我可以先回答这个，然后通过这个我们就能反推出我不会投什么。就像我觉得推理我们已经聊过了，我觉得有巨大的……好，咱们就这么来。
-
你是我在基金里最新的合伙人了。欢迎。你第一天上班，能请到你真是太好了。谢谢。
-
第一，我们应该有推理。我们应该有推理。好。
-
以后会写出多得多的软件，所以我们也应该投一些更底层的基础设施原语。
-
Modal，非常棒的公司。
-
Temporal，非常棒的公司。我觉得那个……
-
他们不是跟Fireworks竞争吗？
-
Modal在某些方面确实做，对。好吧。但他们做的还不止这些。
-
他们也做沙箱。
-
所以，我们有推理层，第一层，还有编码层。
-
或者我会说推理，然后是基础设施。
-
所以，像底层基础设施，Temporal、Modal、Supabase、Convex，还有垂直智能体。
-
我觉得垂直智能体将会是一个很好的层。
-
我觉得——有具体的垂直领域吗？
-
我不确定有没有哪个垂直领域我会特别重仓。
-
但我觉得重要的部分是，要有一种针对特定领域的视角，并且真正深入进去。
-
我记得Patrick Carlson在最近一期播客里说过这个。
-
我记得是和Replo的Amjad聊的时候，他谈到下一个、他会创办什么样的创业公司，那大概不会是什么光鲜亮丽的领域。
-
而是某个技术、或者至少AI渗透率还比较低的领域，但那里已经积累了大量领域专业知识，然后进去真正地改造它。
-
但我觉得关键部分基本上就是拥有一些领域专业知识，这些知识要么能被捕捉进数据里，要么能变成放进框架里的逻辑，最终也许还能进到模型权重里，但我不会从那儿开始，先有一些能被捕捉的领域专业知识，然后把它用起来。
-
顺便说一句，我觉得在所有这些里面，我大概会看三样东西，而且我觉得它们是先决条件。
-
如果你看看所有这些正在成功的团队，第一，我觉得他们拥有的人才非常强。
-
Modal有一支极其强大的人才团队。Lin和Fireworks，对吧？他们写了PyTorch。
-
那有多酷，对吧？第二。
-
我们见到他们的时候，你知道见创始人的时候，最后一次做简短介绍，就像，“我写了PyTorch。”对。
-
哦，好吧，那行得通。
-
对，对，那个框打勾了。
-
所以我觉得，要打造这种真正深度的基础设施，你必须在技术上非常强。
-
而且能做到这一点的人真的没那么多。
-
第二，你必须跑得非常非常快。
-
能够快速迭代，我觉得这一点极其重要。
-
市场变化实在太快了。
-
我觉得就是速度，执行的速度。
-
说到我们在LangChain的优势，我觉得我们迭代得非常非常快。
-
而且我觉得这是我们相比其他公司的一个优势。
-
然后最后一点就是品牌。
-
我觉得很多在AI领域做成的公司，基本上都是抓住了天赐良机，然后乘着这波浪潮把它拿下了。
-
你看LangChain早期的时候。
-
我们一下子就火了，然后我们把这个势头执行到位了。
-
Cursor就是个很好的例子，他们一下子就火了，然后把这个势头执行到位了。
-
Jev，甚至Claude Code、ChatGPT。
-
这个领域感觉发展得太快了，而且因为竞争对手太多了，也许甚至正是因为这一点，因为竞争对手太多，你知道，LangChain出来之后两个月里，大概有100个不同的框架冒出来。
-
但我觉得我们有一个积累起来的品牌优势，我觉得那是一个持久的优势，我们算是乘着它往前走。
-
所以Instinct，另一个例子大概是一堆个人助理。
-
但我觉得，如果说有的话，就估值而言，可能有些估值比理性水平要高，但就这些正在完成的融资轮来说，当有一家突围而出的公司，技术团队非常强，已经证明了自己能快速执行。
-
我觉得你就别管价格，直接投就完了。
-
先发优势是不是比以往任何时候都更重要？我觉得是的。绝对是。对。
-
你看，我是说，追上来是有可能的。
-
我觉得OpenAI在追赶Codex这件事上做得非常出色。
-
但先发这件事，Anthropic和Claude Code，那真是，哇。
-
那个优势太大了。
-
但就像你说的，对，区块链出来之后，几个月内就冒出越来越多。
-
但Instinct也一样，一样的，不过那种因为率先登场而带来的持久品牌垄断，是真实存在的。
-
我觉得这一点太真实了。
-
我也觉得，在那之后你必须执行得极其出色才行。
-
跟我刚才说的相反的例子是，先发并不意味着你一定能成功。
-
Auto GPT，不知道你还记不记得Auto GPT这个项目，它是在LangChain之后几个月出来的，是史上增长最快的GitHub项目。
-
然后，你知道，那之后我就没怎么听到他们的消息了。这不是贬低。
-
要快速执行是非常难的。
-
但我觉得，仅仅因为你在某个领域先发，并不意味着你就能活下来。
-
我从来不喜欢贬低别人。
-
所以我觉得在某些方面，夸赞他们反而更有帮助。
-
如果你要写一份加入这家公司的备忘录，说明我们为什么应该投资90亿美元的GEV轮，你对GEV的看多理由会是什么？
-
对GEV的看多理由是，现在有一种新型的推理和新型的模型，而那个模型类别 literally 就是以他们命名的。
-
所以他们会乘上这波浪潮，而且他们是一支非常有才华的团队，能够把这件事执行好。
-
我对这个团队不算特别了解。
-
但从我看到的一切来看，在那个估值上做一轮融资，这大概就得是前提假设。
-
看起来确实是这样，但这就是看多的理由。
-
他们基本上开创了一个新的模型类别，跟这个类别紧密关联，而且有一支很有才华、能打硬仗的团队。
-
拿Benchmark的钱会改变一家公司的轨迹吗？百分之百会。
-
我觉得Benchmark，当时Miles还有整个Benchmark合伙团队投资我们的时候，就只有我和Ankush两个人。
-
我们真的把他们当成某种意义上的第三位联合创始人。
-
你想，从两个人做到今天这个规模，大概400人，他们在这段旅程里一直是我们最稳定的合作伙伴，这一点是肯定的。
-
你知道，我不是VC，从来没做过VC，可能还有别的市场因素，比如有Benchmark这样的顶级机构参与本身就是一种信号，而且我们很幸运，在Benchmark那轮之后两三个月，Sequoia也加入了，他们也是非常棒的合作伙伴。
-
Sequoia那边是谁？
-
是Sequoia的Sonia，我觉得她是这个圈子里人脉最广的人之一。
-
他们的风格有什么不同？
-
他们俩都非常非常聪明、敏锐，而且都带着真正的实战经验。
-
我觉得Benchmark可能更偏向于，公司的核心内核是什么，
-
然后他们会围绕这个当你的参谋，帮你把这块做好。
-
我的意思是，很多公司建设、定位方面的事，我会去找他们，他们也愿意花时间在这上面。
-
Sequoia的风格，我觉得是他们什么都帮。他们就是一台机器。
-
他们会帮忙招IC、招高管。
-
他们帮忙做市场和发布，而且全都非常落地、非常运营导向。我觉得是这样，对。
-
我是说，我们很多候选人都是通过Sequoia的推荐来的。对。
-
他们有人才网络，我们从那里招到了一批非常非常强的候选人。
-
你会跟创始人们说，为了Sequoia值得接受估值打折吗？
-
我觉得为了Sequoia和Benchmark，或者说这些顶级、一线VC里的任何一家，接受估值打折绝对值得，不过我们合作的就是这几家。
-
关于融资，你现在知道了什么，是当初只有你们两个人的时候希望有人能告诉你的？
-
我觉得融资这事儿几乎就像一场游戏，我一开始完全不知道。我是第一次创业。
-
我也觉得自己注意力很集中，基本上所有时间都花在产品上，所以我非常专注在这上面。
-
我确实觉得融资有这么一套玩法，就是你想做到“不融资也能融资”。
-
你想的是，一旦拿到一个条款，你想先拿到一份term sheet，然后告诉别人你已经有term sheet了，然后……
-
在Twitter上发一张营收增长图，然后就会带来一堆主动上门的……对。你喜欢这套吗？
-
我他妈讨厌这套。
-
可能我现在玩这套太老了，但这纯粹就是装腔作势。
-
就像，Harrison，你是真的喜欢我、想跟我一起做一番事业吗？
-
我给你一样的价格、一样的钱，别的都无所谓，咱们就直接干吧。
-
别他妈装腔作势了。
-
我觉得，我一点都不喜欢融资。
-
我觉得，就像你说的，我想和我喜欢共事的人一起做出点了不起的东西。
-
我觉得，对，尤其是以我们的野心规模来说，我们需要融资才能把这事做成。
-
我觉得这就是Benchmark当时的做法，我们从他们那儿融资的时候也是这样，就是“嘿，咱们先看看彼此喜不喜欢、想不想一起干”。
-
顺便说一句，他们那手谈判谈得非常漂亮，所以我觉得他们也是非常厉害的谈判者。
-
但回头看我们最近几轮融资，B轮我们是从IVP的Tom那里融的。我从大概Sequoia那一轮前后就开始跟Tom聊，聊了两年半多，所以那是一段慢慢建立起来的关系，我了解了他，他也了解了我。
-
所以等到真正融资的时候，我觉得那里面的套路少了很多，我真的很欣赏这一点。
-
我很想玩个快问快答。
-
我说一句简短的话，你马上告诉我你的第一反应。这样可以吗？来吧。好。
-
你最喜欢的一次风投会面是哪次？
-
跟Benchmark的第一次路演。为什么？
-
因为屋里坐着那么多传奇人物。
-
跟谁相处最酷？Bill Gurley。
-
你当时有被镇住吗？
-
我觉得我当时太天真了，根本不知道怕。
-
而且他本人就是个块头很大的人。
-
那身形往你面前一杵，确实挺有压迫感的。
-
关于agent，你坚信但生态里大多数人不会同意的一点是什么？
-
就是它还是特别难做，真的，真的特别难。
-
也许大家会同意这一点，但我觉得它的难度被严重低估了。
-
过去12个月里，你改变想法最多的是什么？
-
推理市场太大了。
-
我记得一年半前跟董事会讨论过要不要做一个gateway，当时我们没看出来相比open router这类东西我们能加什么价值，我觉得那完全是错误的决定。
-
对你和团队来说，最难的技术活是什么？
-
我们自己建了一个数据库来存agent的Trace，叫SmithDB。
-
你怎么看既要跟ClickHouse竞争、又是它的客户这件事？是有点怪还是正常？
-
我觉得有500家公司跟我们都是亦敌亦友的关系。
-
所以我自己已经非常习惯了。
-
你可以投资一家IPO。
-
OpenAI按1.5万亿美元估值，还是Anthropic按2万亿美元估值？OpenAI。为什么？
-
我觉得他们有更多元、更多不同的路径，能真正达到极高的退出估值。完全理解。
-
你现在知道了什么，是2022年刚起步时希望自己早就知道的？
-
我希望我当时就知道今天的harness长什么样，那样我们就能更早把它们做出来。
-
最后一个问题。
-
展望五年后，你最期待的是什么？
-
我特别期待我们能用AI做出哪些有创意的事情。
-
我觉得很多AI，你知道，我们做的很多工作，都是帮企业提高效率、交付成果。
-
我觉得像Suno这样的创意产品特别有意思，我希望能看到更多这样的东西。完全同意。我记得请过Mikey上节目，那期其实挺有意思的。
-
这次聊得真是太开心了，Harrison。
-
非常感谢你包容我的随性和变来变去的日程，你真是个很棒的嘉宾。
-
不不，非常感谢你邀请我。