「模型能力已经够了，要卷就卷 infra」｜对谈戴冠兰：Runta 创始人

本周我们的嘉宾是戴冠兰。冠兰的创业公司 Runloop 刚完成了 2,000 万美元的融资，a16z 是领投方，同时李飞飞、Jeff Dean 等人也以个人身份参与了投资。你好，冠兰，欢迎来到《十字路口》。

Hello，柯姐，十字路口的朋友，感谢这次机会。希望我们能分享一些有意思的事。

我们还是从传统的快问快答开始，帮助大家尽快了解你。请问冠兰，你的年龄？

35 岁。

毕业院校是？

美国东北大学。

你的 MBTI 和星座呢？

我是天秤座。我的 MBTI 在 INTJ 和 ENTJ 之间横跳，但我个人认为自己偏 I 多一些。

一句话介绍一下现在的公司和产品。

我们认为，未来的 AI 智能体会比人类更多。未来这几十亿个 Agent 到底跑在哪里，跑起来之后怎么管理？Runloop 就是为这些 AI 智能体打造执行底座的。

目前团队的规模呢？

我们现在团队在 10 人左右，后面有成百上千个 Agent 在干活。

一句话介绍一下创业之前做过些什么？

我之前在 Cloudflare 做边缘平台，在 Kong 做过网关和云。加起来差不多 10 多年，一直都在做软件和 SaaS 时代的基础设施。

Runloop 这一次的 C 轮融资了 2,000 万美元，a16z 领投，Jeff Dean 和李飞飞也以个人身份参与。我比较好奇，你是怎么拿到他们两位的天使投资的？

首先，大家对 Jeff Dean 可能都了解。他是工程方面的大牛，经历过 Google、DeepMind 等各个时代，是工程领域的传奇人物。

我有机会和他聊过一次，进行了一次比较深度的对谈。他主要问了我一些很深刻的问题。其中有一个问题我印象特别清楚：如果系统最底层的执行单元变成了概率性的，那工程基础设施这一层要怎么构建？

其实这个问题很难回答。过去的系统工程，包括重试、幂等、事务恢复等，都是建立在软件具有确定性的基础上。比如你输入一套东西，同样的输入进去，输出基本上应该是一样的；如果输出不一样，那就是一个异常。

在过去的软件时代，异常是可以枚举的。相当于你在考察：如果这块地基没了，上面的东西要怎么运行、怎么成立？

我当时的想法是，probabilistic，也就是不确定性，本来就是大模型的一个特质，对不对？但一旦 Agent 要上生产，分布式系统里的复杂度，包括恢复、隔离、分叉这些需求，反而会变得更多。

如果这些底层复杂度做不了，就只能把它们压到 runtime 层去解决。上一代基础设施解决的是物理机到底怎么运行，让开发者不需要考虑这些问题；这一代真正要解决的，则是执行本身应该怎么做。

关于这些系统怎么迭代，我也和 Jeff Dean、李飞飞聊了很多。但归根结底，我觉得现在执行层已经变成系统工程里最难的问题了。

现在 Agent 越跑越长。以前一个聊天可能是几分钟、几个 turn，现在已经变成几个小时、几天的 Agent 运行。现有的基础设施实际上还处理不好这些问题，包括隔离、分叉、迁移、热迁移等，很多难题都还没有解决好，所以这件事非常难做。

另外，我觉得他们投资我的一个主要原因，是因为我之前在 Cloudflare 和 Kong 参与过上一代基础设施从第一性原理出发、从头构建的过程。我们刚开始做的时候，Kubernetes、Container 这些技术都还没有。

当时要考虑的是：如何从最根本的需求出发，推导出这个系统到底应该是什么样子。能够参与从头构建这样一套系统，并且最终构建出来的很多基础设施已经成为互联网的基石和标准，我觉得这是很重要的经历。

举一个最具体的例子，在 Kong，可能每天的 API 请求有上千亿次。在这样的规模下，即使是极小概率的错误，哪怕是 0.00001 的概率，也会变成一个极大概率发生的事情。

我经历过、也参与过这一代基础设施的构建，所以我觉得这是综合因素的结果。Jeff 还想多投一些，但我说我的份额不太够了。成为一个对 Jeffrey 说 no 的人，我觉得是一个挺有意思的经历。

a16z 投资了很多公司，但我很少看到他们投资一家很新的公司之后，还专门写一篇博客解释为什么投资。你们这次确实有一篇文章，叫《为什么我们投资 Runloop》。你觉得 a16z 这么重视你们的原因是什么？

这件事还挺有趣的。一般种子轮，他们很少写这种文章，而且一般也很少由 general partner 级别的人亲自来写。这篇文章是 Martin 亲自写的。

我觉得主要是因为他看到了这不仅是一个 feature，也不只是一个普通的产品，而是一个平台级别的机会。他认为这一次是一次计算范式的代际变化。

之前是从客户端、服务器迁移到数据中心，然后从物理机到虚拟机，再到容器化。每一次其实都有代际上的变化。

这一次，归根结底是你真正托管的东西发生了变化：从托管软件、管理软件和服务，变成了管理 Agent、管理智能体。

如果这个判断成立，那就是一个巨大的平台级机会。所以他们愿意花时间把这件事讲清楚，解释为什么这是一个平台性的机会。我觉得这篇文章值得读一读。

用一句特别简单的话给大家解释一下，Runloop 替客户解决的最关键的问题是什么？

我们做的是基础设施工作，但企业真正要落地的时候，面对的是非确定性的、non-deterministic 的、probabilistic 的 workload。我们要在这样的 workload 里加入一些确定性的东西，让企业可以真正把它用起来。

不是要做到所有东西完全确定，而是要给到企业足够多的信任。这包括 Agent 跑在哪里、跑起来以后企业能不能把它交给智能体去干活，包括接触生产权限、访问客户数据，以及它碰了什么、动了什么。

当 Agent 执行的时候，要有一个执行层面的东西把它管理起来，同时还要能够帮助它 scale 起来。这就是我们要做的事情。待会儿我们可以再展开聊整个 Agent Runtime 或者 Agent Infra，包括 Runtime 具体在做什么。

在此之前，我也想和冠兰探讨一下最近整个 AI 和 Agent 领域一个特别大的变化。

我感觉到一个反转：可能 3 个月前，我们还在讲 Token Maximizing。企业消耗特别多的 Token，甚至鼓励员工消耗更多 Token，消耗得越多好像越光荣、越值得骄傲。

但最近画风突然一转，大家开始 Token Minimizing，也就是最小化 Token。据你观察，这个反转大概从什么时候开始出现苗头的？

最早是在 thinking model，也就是 o1 的时候。复杂推理被加入模型之后，比如思维链、CoT，企业管理者就觉得：我用了更多 Token，所以我的系统变得更聪明了，对不对？

后来这个观点被进一步推成了组织管理上的一个观点：一个员工如果消耗的 Token 越多，就越 AI-native。这甚至变成了一个可度量的 KPI。

一旦能够度量 KPI，就可以围绕这个 KPI 一直往前推动，通过一个很大的 KPI，促进组织变革。以 Meta 和 Amazon 为代表，他们最早开始在组织内部推动整套 Token Max 的做法。

去年年底走访一些前沿客户和 AI Lab 的时候，我们甚至看到他们墙上挂着一个显示器，专门显示这周哪个员工使用的 Token 量最高。他们还会设置一些小奖励，比如排在前几名可以拿到什么 reward。

后来这件事演化到了极致。像 Meta 和 Stripe，会把员工的 Token 使用量和业绩挂钩。到年终进行 performance review，也就是业绩考核的时候，会把 Token 使用量作为核心考察的一部分。

这个时候事情就开始变味了。

你看到最大的变味，或者最 drama 的故事是什么？

我听过比较极端的做法：不管什么事情都用推理模型，甚至为了把用量用上去而刷榜。有的员工会故意写一些没用的 loop，把 Token 用量刷上去。

包括今年 3 月，不知道柯姐有没有印象，Jason 说这个人其实不够强。我会觉得这一波有点太过了。

从鼓励大家用得越多越好，到现在企业纷纷开始控制用量，这个反转可能只用了 3 到 6 个月。你觉得中间发生了什么？

首先，大家开始发现 ROI，也就是 return 到底在哪里。特别是最近 Uber 的 CFO 出来说，他们在 4 月已经把全年的 LLM Token 使用量都用完了，但到底收获了什么？

第一，点火阶段已经结束了，大家对这件事的意识已经形成。第三，Token 真的很花钱，而且不是一般的花钱，大家远远低估了模型的价格。

综合这些因素，大家开始意识到，Token Max 可能行不通了。

我们自己也是创业公司，大概 10 个人。你们是怎么制定大家使用 Token 或 API 的规则的？

我们一开始也经历过这个过程。因为我们招了很多来自传统公司、做基础设施的人，所以刚开始我们也是 Token Maximum、Unlimited Token，你爱用什么就用什么，先让大家形成一种 Token 是免费的感觉，反正先用起来。

现在我开始给大家使用阶梯制。首先，我会订阅几个最大的 Ultra Plan，大家可以随便用。用完之后，需要告诉我用完了，以及用在了什么地方。

如果你需要更多，比如一个月需要花 10 万美元，也可以。但我会简单加入一些流程上的小摩擦，让你感觉这个东西不是免费的，并且开始思考现在使用它到底是为了什么。

整体而言，我还是比较宽松地让大家使用 Token。

我们再聊一下 Runloop。刚才简单说到，在 Runloop 之前，你在 Cloudflare 和 Kong 工作过。可不可以详细讲讲，在那两段经历里，你分别处于企业的什么阶段，具体负责什么工作？

我算是最早加入 Cloudflare 的几位工程师之一，负责它的 Edge 边缘云，是边缘云技术负责人。我参与了边缘缓存、WAF，也就是 Web 应用防火墙，以及早期 Workers 系统，也就是边缘侧计算平台的搭建。

我主要负责的是，面对这些软件服务，怎么给它提供中间的一套边缘系统。它要知道什么时候可以访问后面的服务；如果后面的服务需要加速，需要安全功能，我就像一个守门员，负责把这扇门看好。

如何确保服务可以更快地部署到离客户最近的节点，也是我在 Cloudflare 主要解决的问题。

我在 Kong 解决的问题也类似。比如企业的 API 服务需要通过企业网关来做限流、寻址和导流，以及搭建 API 平台和微服务平台。

在 Kong 的时候，我更多接触的是世界 500 强这样的大客户，帮助他们进行数字化转型，以及落地数字化平台。

所以这一次做 Runloop，是你第一次创业？

是第一次以 CEO 的方式创业。

这一次是因为什么原因决定创业？

我们之前服务过很多开发者、业内的开源社区，以及世界 500 强企业客户。我们发现，大家对智能体这个概念非常感兴趣。

大模型相当于把电力转化成 Token，而智能体的工作，是把 Token 转化成企业真正的价值。

但仔细想的话，Agent 更像人类，而不像传统软件。因为它是概率性执行的，每次都会自己决定下一步该执行什么，整个行为都是概率性的。

所以你没办法像对待软件一样，用预定规则把它穷尽。你也穷尽不了，因为 Agent 每次运行，甚至每次生成的代码都不一样。

但它和人也不完全一样。比如柯姐，如果你投资了一家公司，结果发现这家公司不好，你的 LP 可能会来找你，问你为什么投了这个东西，这会影响你的个人声誉。

再比如我在 Kong 服务的客户服务不好，可能 CEO 会来找我，问为什么出了事故。人类实际上是有背锅能力的，出了问题要负责任，最坏的情况可能会坐牢或者被调查。

但 Agent 出了问题，谁来背锅？是大模型公司背锅，还是写这套 Agent 的开发者背锅，还是企业负责人背锅？这个问题怎么处理？

这里面特别复杂。它既有软件的一些行为，又有人类行为，但又和两者都不一样。

让我决定做 Runloop，是因为我觉得 workflow 发生了翻天覆地的变化，而现在的基础设施没有一个是针对这种 workflow 设计的。所以这里面存在一个特别大的机会。

我之前搭建过 SaaS 这一代、云这一代的基础设施，经历过这几套基础设施之后，我发现现在又出现了一种全新的智能体形态。它的执行底座应该是什么样，这套基础设施应该怎么构建？这是一个特别让我着迷、也特别想解决的问题。

我看到很多创业公司在尝试做类似的事情，但我觉得它们思考得还不够深、不够底层，大部分只是把现有技术拼拼凑凑，先把产品上线。

我觉得这很缺乏一个能够看到底层、从第一性原理出发去思考和推导的团队。这也是我为什么放弃在 Kong 比较好的机会出来创业的原因。

如果今天大家用的是 Codex 或 Claude Code，它们可以使用 Runloop 吗？还是必须自己开源部署 Agent，才有使用 Runloop 的必要？

如果是使用 coding agent，我们也支持。你可以在 Runloop 上启动各种类型的 Agent，包括 coding agent。

比如在云端运行一个 24 小时、可以弹性伸缩的 Agent，管理它的花费，管理它的触达。假设你让 coding agent 去收取邮件，这里面哪些邮件它应该收取，哪些邮件不应该访问，包括凭证、密钥等，它能访问什么、不能访问什么。

只要你把现有的 harness、coding agent，或者企业现有的 Agent 放到我们的执行层面上，就能获得这些额外能力。

我们提供了一套云托管平台，上面有虚拟化 workload、定制操作系统和网络处理流程。我们不挑你具体运行的是什么 Agent。

目前你们接触到的客户认为 Runloop 带给他们最大的价值是什么？

特别是这个月，我聊下来比较多的是，大家对预算、刚才提到的 Token Max，以及 compute spending 的关注。

比如 Agent 跑在什么地方。如果 Agent 跑得比较多，怎么样给它提供一个更好的环境，让它以更有弹性、更能伸缩的方式运行。这一部分是 spending 管理。

另外，金融类客户很看重之前提到的 governance，也就是管理能力。他们一方面特别希望让 Agent 干真正的活，和竞争对手拉开差距；但同时又特别担心 Agent 一旦开始运行，会不会出现不可控的问题。

举一个例子。最近我看到一项关于安全的调研，发现世界 500 强公司里，大部分如果使用 Agent，都已经出现过 Agent 泄露机密或客户信息的情况。这会是一个巨大的问题。

为什么这是创业公司的机会，而不是公有云的机会？

公有云，包括现在所有公有云，三朵云，国内五朵云，实际上都是为上一代 SaaS 和传统软件设计的。我经历过这一代基础设施，所以很清楚，它们的计费模型和整套基础设施底座，都是为软件和人设计的。

可以类比 GPU 这一波浪潮。上一代数据中心是以 CPU 为主搭建的，这一波以 GPU 为主。你看最近出现了多少家 New Cloud，实际上就是因为传统的数据中心需要重建，GPU 的整体架构完全需要重新设计，所以才出现了这么多 New Cloud 的机会。

我觉得公有云会朝这个方向迭代，但它本质上的计价模型会和新的需求发生冲突，内部也会有很多既有包袱。这个机会更多会由创业公司把它做起来。

除了公有云之外，理论上还有另一类可能做 Agent Infra 的公司，就是基模厂商，比如 Anthropic、OpenAI。你觉得相比他们，你们有哪些差异化优势？

这个问题也是每个投资人来聊时都会问的：你们怎么想？这件事会不会属于模型的主赛道？模型公司会不会去做这些事情？

Anthropic 已经发布了相关的 Agent 管理系统，所以我觉得模型公司肯定会做这件事。

但如果要真正落地到企业，企业肯定不会绑定一家模型，也不会绑定一朵云。现在这个时代是多模型、多 harness、多云，实际上这是为了分散风险。

另外，企业可能会使用国内一些很优秀的新模型，那要如何整体控制成本，也是一个问题。

归根结底，对大模型公司来说，它们最核心的事情是提升模型能力。它们做的一切，实际上都是为了获取足够多的信号，改善模型本身。

所以我觉得，模型能力和基础设施底座能力，是两个相对明确、职责不同的领域。

你觉得竞争最可能来自哪里？如果不是公有云，也不是基模厂商的话。

我觉得反而可能是 New Cloud，或者上一代转型过来的公司，比如上一代做 serverless 的公司。

它们已经经历过从传统软件到上云的转变。但问题还是一样：它们已经有既有客户群和基本盘，如何再往上加一层？

对于它们来说，这可能是一条副业；但对于创业公司来说，这是我们每天 24 小时都在思考的问题。专注的团队可以把这件事做得更好。

另外一些专注做 Agent Infra 的团队，比如 E2B 或 Daytona，主要做 Sandbox。你怎么看它们和你们的区别与竞争？

Sandbox 是从上一代基础设施里迁移过来、非常好用的一套东西。现在主流的技术，比如 Firecracker，实际上来自上一代 serverless，包括 AWS Fargate 这类产品研发出来的技术。

但 serverless 解决的是什么问题？比如 15 分钟内、1 小时内运行的短时任务。

所以我觉得目前市面上的 Sandbox 方案，对于短时间运行一段代码、快速给出结果，然后把整个环境隔离起来，确实是一个很不错的方案。

但现在 Agent 实际上运行得越来越久。这个时候，上一代技术是否还够用？

我们已经遇到很多瓶颈。比如什么时候应该使用 GPU，什么时候不应该使用 GPU；怎么做动态迁移；怎么做内存的动态伸缩。上一代方案在很多地方已经不够用了。

所以我觉得想要转型还挺难的。必须从底层、从第一性原理出发去思考：针对 AI 智能体，我到底需要什么样的基础设施？然后从下往上搭建整套系统，才有可能真正处理未来 10 亿个智能体到底应该在哪里运行的问题。

虽然你们成立时间还不长，可不可以讲讲目前拿到的最大订单大概是什么体量？

我们现在还处在比较早期的探索阶段。我会觉得，早期营收并不是我们优化的目标。

我们更愿意真正把这个东西从底层往上做，做成一个通用的平台。真正搭建这样一个平台，才是我们现在优化的目标。

我记得我们之前聊过，到底是做非标品，还是做标品。我也想和柯姐聊一下，从你的角度来看，做哪个更合适？也希望听听你的经验。

直觉上应该做标品，因为做标品更容易 scale。如果做非标品，服务一家新公司就要搭建一个新的服务组织，从管理上来说，这不是那么让人向往的一种企业类型。

另一方面，我没有足够的背景知识，不知道最大的客户到底能有多大。如果服务一家客户一年就能赚 5,000 万美元，那服务 4、5 个客户，就已经有 2、3 亿美元的 ARR 了。这样的话，确实非常值得为他们搭建专门的团队。

所以我也比较好奇，未来会怎么发展。

我的看法是，现在可以先服务最 Agent-native 的客户，使用最前沿的 harness 和最前沿的方法论。我们想服务好这样的客户，因为他们代表着最新鲜的生产力。

除此之外，我们也会经常和世界 500 强公司保持阶段性的沟通，了解大家现在把智能体部署到了哪一步，最近遇到了什么痛点和难点，以及哪些问题是他们目前最在意的。

所以我的看法是还是要两把抓。但目前对我们来说，还是服务 Agent-native 的公司，因为他们最愿意接受新技术。这是我这方面的思考，我不知道你怎么看，柯姐。

这些 Agent-native 的公司，大多数是 AI 创业公司，还是也可能并不是做 AI 的？比如做自媒体、广告，但是非常善于使用 Agent 的公司？你指的是哪一种？

我更多指的是 Agent builder，也就是制造 Agent 给别人使用的开发者；以及垂类 Agent 公司，比如剪视频的 Agent、做 Marketing Agent 的垂类公司。

为什么选这类客户？因为它们有规模。我们把服务提供给它们之后，它们就可以服务成千上万个 Agent。

当我们说企业里有几百个 Agent 时，怎么定义一个 Agent 的边界？

有时候我只是在 Codex 里放了一个新任务，这也可以叫一个 Agent 吗？这个边界我不知道你是怎么定义的。

现在还没有一个约定俗成的 Agent 定义。大家目前有几方面的认知。

第一是拟人化：我给这个 Agent 起一个名字，比如张三、李四，给它一个身份。

另外一方面是，它有具体的分工。这背后牵扯到一长串技术问题：这个 Agent 到底应该拿什么权限？

还有一种方式是，每次 Agent 干活时，只给它分配完成这项工作所需要的权限，工作完成以后马上收回来。现在有很多种管理方式，但还没有形成共识。

有时候我也需要让 Codex 去取我的 Gmail，但心里其实很不踏实，因为里面有太多隐私信息。第一次我还会费点劲，设置成这个权限一个小时之后自动收回。

但慢慢地，我的边界就被它吞噬了。后来我会想，反正现在就随便看吧，我相信你不会乱搞。

我觉得你这种情况叫 approval fatigue，也就是审核疲倦。

在这方面，我有一些最简单的想法。首先，权限管理要有一些硬规则。比如这个 Agent 可以读邮件，但不能发邮件，这就是一个硬规则。

我不知道柯姐会不会让 Agent 发邮件？

会。现在大量邮件都是它帮我发的。

你会用它发什么样的邮件？

我特别喜欢观鸟，经常去新的地方旅行。我会找当地专业的鸟导带我去看鸟，也会让 Manus 帮我找当地的鸟导，然后发邮件联系他们，请他们按照我的计划报价。

这样的邮件我已经发过三四次了。

你怎么确定它发的邮件确实是在找鸟导？你会定期审核吗？

最开始我会说，你先写 draft，然后我来点发送。得到我的信任之后，我也懒得等它写好 draft 再点发送了，就会直接说你发吧。

因为感觉发出去的代价也没有那么大。

但如果它突然发一封邮件给你的 LP，说你不想干了，或者说 carry 太低了，你会不会有一种内在的恐惧，担心某一天它突然发出一封无法收回的邮件？

目前肯定没有发生。但我觉得只要发生过一件这样的事情，哪怕不是发生在我身上，而是发生在别人身上，发出一封灾难性的邮件，之后大家都会变得非常谨慎和小心。

如果我现在想用 Runloop 帮我管理这些权限，目前你们对个人开放吗？

我们现在有一个开源项目叫 Cloud Shell，里面已经支持 OpenClaw 和 Hermes 这类 Agent 的本地运行。如果你在本地运行 Agent，可以使用我们的开源产品来管理邮箱。

但在 Runloop 上，我们提供的能力会复杂得多，比如数据库、代码仓库等资源的管理。

回到刚才那句话，我觉得这类安全事故是必然会发生的。我做一个预言：未来 10 年内，必然会有灾难性的 email 通过 Agent 发出去，而且特别难以挽回。Mark my words，我觉得绝对会发生。

现在的情况是，包括我自己在内，大部分人都会用安全换便捷。但这种灾难性后果必然会发生。发生之后，大家才会有机会反思这一块到底应该怎么管理。

安全本身在于，你给这个智能体多少信任。它和传统网络安全不一样。传统网络安全可能会主动扫描、做特征匹配，但我们不做这类安全。

我们更多做的是管控，让 Agent 在可控的边界里执行。即使出现最坏的情况，我们也能够从中恢复，并且做到可审计。

这样才能让企业对 Agent 产生更多信任。我觉得这不是用一个安全框架把它框起来，而是通过一个相对更好的执行底座，帮助它释放真正的能力。

你现在接触客户的时候，需要说服他们认识到这件事的必要性吗？

我现在发现，用安全换便捷的企业并不少。大家内心其实都有恐惧，只是还没有一套好用的基础底座来帮助大家解决这个问题。

这是一波一波的浪潮。未来这件事一定会发生，我们现在做的一切，都是在准备迎接这个趋势。

你们最终的愿景，是希望企业真正把非只读权限、把生产权限交给 Agent，对吗？

这一次创业和前两次有什么不同？前两次感觉是已经出现了很具体的问题，然后你们去解决问题。现在更像是在模糊的状态中先迈出半步，觉得这个方向未来很需要，于是先做一些现在有必要的基础设施，一边走一边看。

我觉得现在已经起飞了。你看之前提到的 AI 基础设施创业公司，它们的营收和具体服务客户已经很明确了。针对 AI 设计的基础设施，特别是执行侧，已经处于起飞状态。

可以举一两个你感觉它正在起飞的信号吗？

有特别多企业客户排队想使用 Runloop 的服务，但因为团队的交付能力有限，而且我们现在优先服务 Agent-native 团队，所以有很多订单进来。

现在你们有没有抽象出一些标准化产品？就是根据客户各种各样的需求，做出标准化的产品？

我们已经有一些比较标准化的东西，比如执行平台、Sandbox 调度，以及如何管理 Token。

举个例子，我们最近有一个比较有意思的功能。首先，我们是在执行平面底座上运行，harness 可以运行任何东西。无论是 Codex、Claude Code，还是你自己手搓的一套 harness，都可以跑在上面。

运行之后，我们可以分析这套 harness 有没有浪费 Token，浪费在什么地方，以及它是怎么浪费的。我们还可以帮你生成一些提示词，让这套 harness 继续迭代，并告诉你哪些方面需要优化。

我们正在做这样一套闭环：你的 harness 在上面运行，我们告诉你怎么让它运行得更快、更好、更省。

你们现在搭建产品，或者给客户提供服务的时候，web coding 占多大比重？

95% 以上。入门程序员的工作基本上都由 Agent 代替了。

但反而是那些依赖基础设施经验和底层架构判断力的工作，仍然需要人类工程师投入很多时间。

举几个例子，比如架构设计、API 设计，以及组件之间如何耦合。这些架构能力，反而是现在人类工程师还不可或缺的一部分。

你们用 Agent 写代码，再用 Agent 去治理其他 Agent，这本身是不是也有风险？

肯定有风险。所以这一块必须有好的预警机制，要能够判断它是否还在有效期内。

另外，我们每天都在使用自己的平台，让 Agent 在我们的执行环境里干活，也一直用自己的产品进行自我迭代。

在你看来，如果未来出现安全问题，大概率是模型的问题、harness 的问题，还是更可能出现在其他地方？

首先，我觉得大模型肯定会不停地在安全性上加入训练措施。比如最近发布的一些模型，如果你聊到它认为比较敏感的信息，它会自动跳转到更弱的模型。

但归根结底，大模型使用的是 Transformer 这套架构。即使未来 GPT-7、GPT-8 出来，如果它没有改变 Transformer 这套架构，它必然还是一个概率性执行的模型。

归根结底，它是 next-token prediction，只是在判断哪个 Token 最有可能、最适合完成这件事。

实际上，模型没办法区分你给它的信息到底是在控制它，还是数据。比如你让 Agent 发一封邮件，模型无法判断这是在控制它，还是普通数据。

对模型来说，所有东西都是一堆一堆进来的 Token。即使你加入一些特殊字符，把信息分割开来，在模型看来也都有可能被绕过。

所以我觉得，模型安全是一个没有办法从模型侧根治的问题。这也是基础设施有机会的原因之一：在基础设施侧加入确定性的东西，确保这套非确定性的架构能够在企业可控的范围内执行。

最近出了一个事故，OpenAI 的模型入侵了 Hugging Face，拿走了 reward signal。这个事情里，反而是 Hugging Face 后来用开源模型帮助 OpenAI 找到了真正的问题。

OpenAI 本身有安全限制。有人对它说，这里发生了安全事故，请你帮忙调查一下，OpenAI 却认为这属于敏感问题，不是模型要处理的事情，直接停止了响应。

后来他们使用开源模型，真正找到了问题在哪里，即使那个开源模型并不是 SOTA 级别的最优方案。

我们正好聊到开源和闭源。最近有很多开源、闭源之间的竞争。感觉除了 OpenAI 和 Anthropic 之外，其他人都组成了“复仇者联盟”，掀起了一个新的思潮：不要再用闭源模型，因为它贵，而且数据还可能被拿去二次训练，既没有安全性，也没有性价比。

从微软到 Palantir，再到公有云，大家都在讲开源。你怎么看开源和闭源？再过几年，双方的竞争会怎么发展？

开源模型肯定会一直往上爬坡。最近 Kimi 也接近 SOTA，进入了第一梯队；DeepSeek 最新的 Flash 模型，也让大家看到了在多、快、好、省方面的很多进步。

这其实是一个此消彼长的过程。美国在算力上毕竟有巨大优势，它们有更多机会去尝试不同的探索。

最近 AI for AI 这一波浪潮也很有趣。我们也在服务这类公司，研究如何通过 Agent AI 改善模型训练。

如果未来模型能力稳定在某个 SOTA 水平，模型会不会变成一种商品？到那时大家都卖不了很高的利润，模型就会像今天的电和水一样，变成一个不那么性感的生意。

这也是大家对大模型公司今天高企估值的一个很大担忧。你怎么看？

我觉得最终会到达这一步，但到底是一年还是 5 年，我不知道。

现在已经有一些 early signal。比如 Fable 5 和我之前用的 Opus，我觉得对于开发者、对于我们来说，没有本质上的区别。

我觉得这个爬坡已经开始放缓了。所以我先下一个暴论：模型能力已经够了，要卷就卷基础设施。

模型能力已经来了，但基础设施和 harness 这一整块都没有跟上，所以现在还没有真正落地。这也是我创建 Runloop 的另一个原因。

现在你感觉到卷吗？你所在的基础设施赛道有多卷？

基础设施赛道的话，Frontier Labs 做类似事情的团队，可能每家至少有几十个人，甚至上百人在做。

但它们做的事情，正如我刚才说的，主要是为了模型本身，是为了提升模型能力去搭建基础设施底座。

在执行底座这一块，我反而觉得大家虽然已经看到了问题，但还没有形成共识：执行底座真的那么重要吗？

我希望一年以后，大家不要再问 Agent 执行到底需不需要执行底座。就像问“我的数据存在哪里”，答案是数据库里。

我希望大家形成这样的认知：Agent 需要跑在它的 Agent 执行底座里。

我参与这个节目，也希望让大家慢慢意识到，这里面确实需要做这样一件事，需要建设这样的基础设施。

而且我希望这个领域越卷越好，参与的人越多越好。归根结底，我希望真正把 Agent 智能体落地这件事情做下来。

如果你既想做很底层的基础设施，又想对客户有实际价值，我觉得 Runloop 这边有很多很好的机会，大家可以来考虑一下。

欢迎大家加入 Runloop。

你们现在主要都在旧金山，还是在其他地方也有办公室？

我们在新加坡和旧金山都有团队。

可不可以给刚参加工作的工程师一些职业建议？

刚加入职场的人，首先可以 Token Maxing。刚入职场，最大的财富就是没有包袱。

同时，也要对之前的基础保持敬畏之心，把架构能力、底层思考能力锻炼起来。

柯姐，到时候可以把我的联系方式留下来。如果有对这些方向感兴趣的同学，我特别乐意和大家沟通，一起探讨未来的发展方向。

在你自己的职业生涯里，做对了哪些最关键的选择？

首先要意识到浪潮来了。

举个例子，我之前为什么加入 Cloudflare？因为我看到边缘计算的浪潮刚刚开始。当时数据中心正在从主机房迁移到云上，这一波浪潮刚刚起来。

正好有一家创业公司在做这方面的探索，而且技术特别好。我觉得这波浪潮值得跟，所以当时加入了 Cloudflare。

在 Kong 的时候，我看到的是微服务和云原生的浪潮。柯姐不知道还有没有印象，大概在 2020 年前后，正好是 K8s、Mesos、Docker Swarm 这波技术混战的时候。

当时大家开始思考，分布式系统的复杂度到底怎么解决，有没有办法让一个普通工程师也能解决很难的分布式系统问题。

所以我觉得，加入一家能够原生参与这波浪潮的公司，是一件很有意思的事情。

现在也是一样。AI 浪潮、智能体浪潮，是一个特别好的机会。这也是我为什么出来创业：我看到了这波浪潮，觉得这件事非做不可。如果不做，我可能会后悔一辈子。

即使之前的公司待得很舒服，条件也很好，我在 Kong 还是创始工程师，也是第一位 Engineering Manager，是建立核心团队的元老级人物。大家都说，冠兰，你应该退休了，为什么还要出来做这个？

我说，我真的想做这件事。因为我觉得这就是一个使命，这波浪潮真的来了，而这里面的基础设施做得很差。我还没有看到真正能力很强、真心想把这件事做好的团队。

所以我思考职业发展时，始终觉得一定要看到浪潮，有把握浪潮的能力。浪潮来了，就一定要跟上，要有勇于冲浪的能力。

等浪潮退去之后，就收板回家。我觉得这种勇气还是很有必要的。

当时不管是 Cloudflare 还是 Kong，你都是 founding team 的 engineer，是最早加入的一批人。

事后证明，当时这两个领域也有很多竞争对手，但你最后都选择了后来在各自领域冲出来的公司。一个浪潮刚来、行业还在混战的时候，怎么选对公司？有什么心得吗？

投资其实和我选团队很像。你们投资的是 capital，是财富，是钱；而我是投资个人的青春和自己的精力。

我觉得关键还是在人。这个团队到底靠不靠谱，是不是最有想法、最有干劲、最聪明、最敢闯、最敢想的那批人？

首先要选对方向，然后看执行。执行看什么？看团队的综合能力。

我最看重的是，这个团队有没有往下吃一层的能力。

举个例子，现在做 LLM 基础设施，最牛的工程师是什么样？就是能往下钻到 kernel 级别，能够钻到算子优化，能够把调度做起来。

包括我们之前做 Kong 的时候，因为做网关，我会看你对网络协议栈、对系统这一层到底有多深刻的理解。

这也是我招聘的一个秘诀：有没有往下钻一层的能力。

大部分人只会觉得，东西刚好够用，能做、能用就行。但极少数人，可能只有 10% 甚至 5% 以下的人，会对它充满好奇心，想去看下面到底是怎么做的，想知道能不能从更底层去优化上面的东西。

我特别看重这种能力：亲手捣鼓一套系统的能力，研究最新技术的能力，以及快速把一套东西吃透的能力。

我当初加入这些公司的时候，就是在早期创始人身上看到了这些能力，所以才决定加入。

我觉得这里面肯定有一个非常有共鸣的点，就是投资人，尤其在一个行业刚起步的时候，大家没有谁能够想清楚未来一二三四五六七八步，甚至一二三步都想不清楚。

所以这时候只能看这个人是不是有领导力、学习能力，是不是有一定要把事情做成的热情和韧性。

但我另外一个好奇是，替年轻工程师们问：很多时候你了解一家公司，渠道其实很有限，可能就是面试时的几次交流，但留给你提问的时间也不多。

当时你去 Cloudflare、去 Kong 的时候，是怎么了解它们的？有没有什么技巧或经验可以分享？

对于刚入职场或者还没有进入职场的年轻人来说，最多的其实是时间。回过头看，时间是最多的，但同时也是最宝贵的。

我的经历也可以和大家分享：多花点时间好好研究这件事。你可以花 24 小时去思考，如果你是 CEO，你会怎么做；然后做一些头脑实验。

等你再去和对方聊的时候，就可以看出他有哪些认知是你没有的。你的头脑实验和头脑风暴，能够给你带来更高一层的视角。

所以，真的要多花时间去思考这家公司到底要做什么。你可以从自己的角度推测怎么做，也可以从创始人的角度推测怎么做。

但归根结底，还是要做足够多的功课。包括我在 Kong 的时候，我实际上和创始人认识了至少 1 年多，他一直希望我加入。

Kong 最早做的事情有点像 OpenRouter：把不同的 API resell 出去。但那时候还没有大模型 API，可能是卖地图 API、查询 API 等等。

那时还太早，浪潮还没有来。我觉得那一波不是很好的时机，所以花了特别多时间去思考、调研，充分理解这家公司，并和创始人沟通。

他们转型成为 Kong 的那几个月里，我才加入这家公司。也就是说，他们之前并不是做这一块的。

所以年轻人一定要多花时间研究。可以多听柯姐的 Podcast，多从投资人的思维去了解怎么思考、怎么投资。我觉得这里面有很多共性：你怎么投资一家公司，和你怎么投资自己的职业，有很多值得学习的地方。

如果一件事特别值得投资，那么你的能力、认知、理解，以及你和这件事的匹配程度，应该达到了一个比较好的平衡。

那时候你会在内心告诉自己：如果我不加入这家公司，我这辈子都会后悔。这里有时间，有浪潮，而且你必须乘上这波浪。

投资的时候可以换一个问题：如果换成你是求职者，你愿不愿意加入这个创始人？

如果你愿意加入他，那其实就应该投资他，因为你要去给他打工。这比给他一笔钱更重，是更大的 commitment。

所以，如果这件事你都愿意做，那你确实应该投。我觉得这里面有很多共性。

我自己也会做天使投资。柯姐这边有个说法叫“开天眼”，不知道你们有没有听过。它的意思是，作为创业者，也要经常思考怎么投资。

这相当于从不同角度思考问题：既要从更高的维度思考，也要从更底层的维度思考，还要经常切换自己的角色。

一旦能够把这些问题想清楚，我觉得这会成为一个很大的优势，而且可能是别人很难追上的优势。

如果今天做一个思想实验，给你一笔 300 万美元的虚拟资金，要求你现在立刻投出去，投给 3 个人，你脑海中有这样的人吗？你会投给谁？

具体的人名我就不说了，因为他们可能还在融资过程中。

我可以举一个例子：头部视频模型公司的早期创始成员。我最近也在帮他们找投资，甚至可能会个人参与。

首先，视频模型是继 coding 模型之后，第二个已经被证明可以赚钱的赛道。但目前真正能把视频模型做好的创业公司并不多，真正从模型侧把它做好的公司，我还没有看到几家。

所以我觉得这块机会特别难得。如果柯姐感兴趣，我可以推荐你和其中的创始人聊一聊。

另外一块，我觉得 AI for AI 的创业公司也有机会。也就是怎么样通过 AI 训练更好的模型，在 Auto Research 的基础上，利用长程的方式，让 Agent 能做更多事情。

这件事我也有一些个人的考虑。我希望通过和这样的公司合作，把 Runta 的底座做得更好，同时探索打造下一代大模型的范式。

我知道前沿模型公司、Frontier Labs 也在做类似的事情，所以我对这方面比较关注。

我们最后聊两个轻松的话题。你更喜欢 Claude Code 还是 Codex？

我现在用 Codex 更多。

什么原因？你肯定也是从其他产品迁移过来的，大家都有一个搬家的过程。

对。Codex 就是人狠话不多，给它任务之后，它就吭哧吭哧干活，质量也很高。

我记得 OpenClaw 的作者做过类似的分享，我觉得挺有意思。他说 Codex 更像一个德国人：吭哧吭哧干活，质量还很高。

Copilot 更像一个美国人，会很 chatty，和你说一堆话：你有没有考虑这个？你有没有想透？它们就是不同的性格。

我使用 Codex，首先是因为没有看到它和其他产品在模型能力上有代际差别。Codex 经常会有新的更新，也经常有一些对开发者友好的功能，而且它的 harness 是开源的。

对开发者来说，这像是打了一场翻身仗，把我们从 Copilot 转移到了 Codex。我觉得这套 harness 在 coding 上还是站住脚了，值得使用。

不过，我们把 Codex 放到自己的执行环境里运行时，发现它有各种各样的问题。我们计划向上游提供一些修复，因为它是开源的。

Claude Code 是闭源的，我们没有办法直接贡献。我们希望通过自己的执行底座优化上面的 harness，这也是我们的考虑之一。

所以你们内部是统一使用 Codex 吗？现在还有人在用 Claude Code、Cursor 或者其他产品吗？

我个人用 Codex 比较多，也会用 Grok、Fireworks，以及一些国产的前沿模型。

我们现在内部有一个共识：把 model router 交给工程师自己。工程师最有体感，他们知道什么时候该用什么模型。

我们也会用 Grok 做一些前端工作，或者一些不需要资深工程师参与、出错之后恢复半径比较小的工作。我们会把这些工作交给没那么强的模型。

但具体用什么模型，全部让工程师自己决定。他们爱用什么就用什么。我们使用的模型五花八门，但我希望最终工程师交付的是一个自己能够负责任的结果。

我不管你用什么模型，但我希望大家通过这个过程培养体感，培养对当前模型状态的认知，真正理解它们的能力。

我也特别欢迎大家使用各种模型，用各种奇思妙想让模型多、快、好、省。因为我们要支持客户做这件事，所以也希望我们的工程师具备这方面的能力，对模型有体感，进而改进下面的执行层。

除了 Codex，你使用最多的其他 AI 产品还有哪些？

我个人会用 Hermes 和 Pi。我们团队对 OpenClaw 这类产品不太满意，觉得里面写得比较差，所以他们也自己手搓了一套 harness。

我看下来，自己做的效果其实还不错。所以我会觉得，harness 可能没有那么高的护城河，每个企业最终可能都会自己搭一套。

我个人还会用 ElevenLabs 做音视频，比如配音；也会尝试一些文生图模型和产品，比如 OpenArt。

我会强迫自己使用各种产品，包括早期的各种 AI Agent，因为我想知道现在智能体到底发展到了哪一步。

我还会用一些录音笔之类的硬件，也会尝试智能客服帮忙打电话。还有一个朋友正在创业，做的是自动语音客服，比如发现被多扣了钱之后，自动帮你把钱要回来。

这些 Agent 我用得还挺激进。我应该是我们公司里使用 Agent 最激进的人了。

我感觉冠兰你整个状态非常有活力，也非常开心。创业确实特别是作为 CEO 创业，每天都像过山车，可能每天有 5 个好消息，也有 5 个坏消息。

但我觉得这个状态真的很让人羡慕。

焦虑的原因在于，大家往往会被那几个坏消息牵着走。其实我偶尔也会有困惑。

但从更大的角度来看，首先，我们是不是在解决一个特别让人兴奋的问题？我觉得自己正在解决一个特别让人兴奋的问题。

其次，我们是不是最适合做这件事的团队？我觉得目前的团队配置，包括正在招聘的人，都在朝这个方向演进。

包括我们的投资人，以及背后支持我们的网络，我觉得也都非常适合。大家真正相信，我们是在做一件特别 meaningful 的事情，而且这件事会深远地改变 AI 和智能体的格局。

这些事情让我很兴奋。即使有坏消息也无所谓。对于未来 10 亿、几十亿个 Agent 的落地来说，现在这些事情又算什么？

用好奇心驱动自己去探索问题，我觉得这能带来很多兴奋感。

真好，这个状态非常让人羡慕。那我们今天谢谢冠兰，也希望你的快乐或者创业的激情可以感染到听这期节目的朋友们。

也感谢 Coach 给这样一个机会。如果各位听众朋友对参与未来 AI 基础设施建设感兴趣，欢迎找我来聊。

我们会把联系方式放在播客的介绍里面，欢迎大家联系冠兰、联系 Runloop。好，那我们今天先到这里，谢谢。

好的好的，感谢柯姐，拜拜。

好，拜拜。