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

摘要

• Runloop 的 2,000 万美元 C 轮融资，本质上押注的是托管对象从软件迁移到 Agent 的平台级代际变化。 a16z 领投，Jeff Dean、李飞飞以个人身份参与；戴冠兰称，Martin 亲自撰写投资文章，是因为这不是一个 feature，而是从物理机、虚拟机、容器继续演化到 Agent 托管的平台机会。约十人的团队背后已有“成百上千个 Agent 在干活”，目标是回答未来几十亿个 Agent “到底跑在哪、跑起来怎么管”。
• Agent 从几分钟对话延长到数小时乃至数天后，概率性执行已经成为系统工程最难的一层。 传统容错假设相同输入产生相同输出，异常可以枚举；Agent 却每次可能选择不同步骤、生成不同代码，因此隔离、分叉、恢复、迁移和热迁移的需求只会更多。戴冠兰的结论是：“如果这些底层的复杂度做不了，只有把它压到 runtime 层。”
• Token Maxing 已在几个月内从 AI-native 荣誉指标反转成 ROI 和成本审计。 o1 与 CoT 曾让 Meta、Amazon 等公司用 Token 消耗推动组织变革，部分团队设排行榜和奖励，Meta、Stripe 甚至把用量纳入绩效；结果员工开始用无意义 loop 刷量，而 Uber CFO 称公司在 4 月就用完全年 LLM Token 使用量。Runloop 自己也从 Unlimited Token 改为阶梯制：最大 Plan 随便用，但用完要说明用途，若要升到每月 10 万美元则增加一点流程摩擦。
• 公有云、基模厂商和 Sandbox 公司都可能进入 Agent Infra，但各自的既有架构与商业目标给专注创业公司留下窗口。 公有云的计费和底座为 SaaS、软件与人设计，改造类似 CPU 数据中心重建为 GPU New Cloud；模型公司肯定会做相关系统，但以获取训练信号、提升模型能力为核心，而企业需要多模型、多 harness、多云来分散风险和控制成本。现有 Firecracker 类 Sandbox 擅长 15 分钟至 1 小时的短任务，却难以处理长时 Agent 的 GPU 切换、动态内存和迁移。
• Runloop 当前面对的不是需求不足，而是在团队交付能力有限的情况下，优先把通用平台做出来。 戴冠兰没有披露最大订单，明确称早期营收不是当前优化目标；团队优先服务 Agent builder 和垂类 Agent 公司，因为一个客户便可能承载成千上万个 Agent，同时持续与世界 500 强做阶段性沟通。Koji 的反问也值得保留：标品更易 scale，但若单一客户可贡献 5,000 万美元、四五家就形成 2 亿至 3 亿美元 ARR，专属团队同样合理。
• 权限治理的真正催化剂可能是一场不可逆的 Agent 事故。 Koji 从让 Agent 一小时后收回 Gmail 权限，逐渐滑向“反正现在就随便看吧”，戴冠兰称之为 “approval fatigue”；他断言灾难性邮件“绝对会发生，Mark my words”。Runloop 的安全观不是扫描攻击特征，而是以硬权限、审计和恢复限定最坏结果，从而让企业敢在可控边界内把包括生产权限在内的更高权限交给 Agent。
• 戴冠兰判断模型性能曲线已经放缓，下一阶段的价值将从模型能力转向 harness、执行层和工程判断。 他的“暴论”是：“模型能力已经够了，要卷就卷基础设施。”Runloop 超过 95% 的 web coding 由 Agent 完成，但架构、API、模块解耦和底层系统判断仍由资深工程师负责；内部同时使用 Codex、Grok、Fireworks 及国产前沿模型，并把 model router 交给工程师，要求的是工程师对最终结果负责。

精读

1. 2,000 万美元 C 轮融资押注的是 Agent 托管的代际迁移

• Runloop 刚完成 2,000 万美元 C 轮融资，由 a16z 领投，Jeff Dean、李飞飞以个人身份参与。戴冠兰还因份额有限拒绝了 Jeff Dean 增加投资的请求，笑称自己成了“跟 Jeffrey say no 的人”。

• a16z 的 Martin 亲自撰写“为什么投资 Runloop”，在戴冠兰看来是因为投资人看到的不是单一 feature，而是平台机会：客户端—服务器、数据中心、物理机、虚拟机、容器之后，真正被托管和管理的对象开始变成 Agent。

• 公司的定义因此很直接：未来 AI 智能体会比人类更多，Runloop 要做它们的“执行底座”。目前团队约十人，但“后面有成百上千个 Agent 在干活”，长期问题则是几十亿个 Agent 如何运行、扩缩和被管理。

2. 概率性执行把 runtime 推成系统工程最难的一层

• Jeff Dean 提出的关键问题是：“如果系统最底层的执行单元变成概率性的，那工程基础设施这一层要怎么构建？”传统系统工程默认软件确定执行，相同输入应有相同输出；不同结果属于异常，系统则围绕重试、幂等、事务恢复等机制处理它们。

• Agent 的不确定性却不是异常，而是模型本身的特征。它每一步都可能重新决策，甚至每次生成不同代码；一旦进入生产，隔离、恢复、分叉和迁移的需求不会减少，反而会随着 Agent 运行时间变长而变得更复杂。

• 戴冠兰认为上一代基础设施隐藏了“物理机到底怎么跑”，这一代则必须隐藏“执行本身怎么做”。当 Agent 从几分钟、几个 turn，延长到数小时乃至数天，现有设施对隔离、热迁移和长时状态仍处理得不好。

• 他在 Kong 见过每天上千亿次 API 请求的规模：“哪怕是 0.00001 的概率，都会变成一个极大概率发生的事情。”这段经历让他的判断偏向系统性兜底，而不是期待模型把低概率错误降到零。

3. 两代基础设施经历让戴冠兰坚持从底层重造

• 戴冠兰是 Cloudflare 早期工程师和 Edge 边缘云技术负责人，参与边缘缓存、WAF 与早期 Workers 系统，核心任务是充当服务的“守门员”：决定访问、加速、安全和如何部署到离用户更近的节点。

• 在 Kong，他负责企业网关、限流、寻址导流、API 与微服务平台，并直接服务世界 500 强的数字化转型。他称自己经历过 Kubernetes、Container 还没有时，从需求和第一性原理推导基础设施的过程。

• 创办 Runloop 是他第一次以 CEO 身份创业。触发点不是简单复制旧技术，而是 Agent “既像软件，又像人类”，却没有清晰的责任机制：人类出了问题需要承担责任，Agent 出错后由模型公司、开发者还是企业负责人承担，至今没有清晰答案。

4. Token Maxing 已从组织变革 KPI 反转成成本审计

• Token Maxing 最早伴随 o1、CoT 和复杂推理兴起：管理者把更多 Token 等同于更聪明，再把员工用量视作 AI-native 程度。Meta、Amazon 等公司率先用这一可量化 KPI 推动组织采用 AI。

• 戴冠兰走访前沿客户和 AI Lab 时见过办公室里专门展示员工周度 Token 排名的屏幕，榜首还有奖励；更极端时，Meta、Stripe 会把 Token 使用量放进年终 performance review，“这个时候就开始变味了”。

• KPI 随即诱发刷量：有人无论任务需要都调用推理模型，甚至写无用 loop 消耗 Token。与此同时，他提到 Uber CFO 的说法称，公司在 4 月已经用完全年 LLM Token 使用量，管理层必须追问：“我们到底收获了什么东西？”

• Runloop 也经历了从 Unlimited Token 到阶梯制的变化。最大订阅仍可自由使用，但耗尽后要说明“用在哪里”；即使申请每月 10 万美元也可以，前提是接受一点流程摩擦，意识到 Token “不是 free 的”。

5. Runloop 提供的是足够确定的执行边界

• 戴冠兰没有承诺把概率性工作负载变得完全确定，而是加入“足够多的信任”：让企业知道 Agent 跑在哪里、访问哪些数据和凭证、触碰过什么，以及出现问题时如何被管理、扩缩、隔离和恢复。

• Runloop 提供云托管平台、虚拟化 workload、定制操作系统和网络处理层，不限定上面运行哪种 Agent 或 harness。现有 coding agent 也可被放进其执行层，获得 24 小时运行、弹性伸缩、花费控制和权限约束。

• 客户当前最直接的需求一端是 spending：Agent 多起来后，需要更有弹性的运行环境并管理计算开支；另一端是 governance，尤其金融客户既想让 Agent 接触真正的工作、拉开竞争差距，又担心其访问客户数据后产生不可控后果。

6. 公有云和基模厂商都会做，但组织目标给创业公司留窗

• 戴冠兰认为国内外公有云的底座、计费模型和服务对象都为 SaaS、传统软件与人设计。类比 GPU 浪潮，CPU 数据中心需要重建才催生 New Cloud；Agent 也会带来执行架构重建的机会，而存量业务会形成内部包袱。

• 对 Anthropic、OpenAI 等模型公司，他的回答不是“它们不会做”，而是“肯定要做”。差别在于企业不会绑定单一模型或单一云，多模型、多 harness、多云既能分散风险，也能在使用不同模型时控制总体成本。

• 模型公司的核心仍是提升模型能力，搭建基础设施也是为了获得更多训练信号；Runloop 则把执行可靠性本身当产品。戴冠兰据此判断，model capability 与基础设施底座能力会形成相对明确的职责分工。

• 他认为更现实的竞争可能来自 New Cloud 或上一代 serverless 公司，但这些公司已有客户和基本盘，转向 Agent 可能只是“副业”；对 Runloop 而言，这却是团队每天 24 小时专注的问题。

7. 短时 Sandbox 承接不了小时到数天的 Agent

• 戴冠兰认可 E2B、Daytona 等 Sandbox 的价值：Firecracker 一类技术来自上一代 serverless，包括 AWS Fargate 等产品，适合在 15 分钟或 1 小时内隔离并执行短代码片段，再快速返回结果。

• 问题在于 Agent 正越跑越长。系统必须动态决定何时使用 GPU、何时不用，如何迁移、热迁移和动态伸缩内存；这些都不是为短时 serverless 任务设计的现成方案能够自然承担的。

• 他的主张是从 Agent 需求向下重建整套系统，而非拼接上一代组件。目标不是再造一个 Sandbox feature，而是让“Agent 需要跑在 Agent 执行底座里”像“数据存在数据库里”一样成为默认认知。

8. Runloop 先抓 Agent-native 规模，再验证大企业治理

• 被问最大订单时，戴冠兰没有给数字，坦言公司仍在早期探索，当前优化目标也不是营收，而是从底层向上做成通用平台。这是融资叙事之外必须保留的商业化不确定性。

• Koji 的推演是：标品天然更容易 scale；但若一个大客户每年能贡献 5,000 万美元，服务四五家便是 2 亿至 3 亿美元 ARR，为它们建立专属组织也完全值得，关键仍取决于单客上限。

• 戴冠兰选择“两把抓”：优先服务 Agent builder 和剪视频、Marketing 等垂类 Agent 公司，因为一个客户便能承载成千上万个 Agent；同时与世界 500 强阶段性沟通，追踪部署进度和最在意的治理难题。

• 已抽象出的标准能力包括执行平台、Sandbox 调度与 Token 管理。任意 harness 跑在上面后，Runloop 可识别 Token 浪费的位置，再生成提示词和优化建议，形成“运行—分析—改进”的闭环。

9. Agent 边界未定，权限疲劳却已经发生

• 戴冠兰承认行业尚无公认的 Agent 定义。一种定义按拟人化身份划分，为“张三李四”命名并分工；另一种按任务划分，每次只授予完成工作所需的权限，任务结束立即收回。

• Koji 描述了权限边界被逐步吞噬的过程：最初让 Codex 访问 Gmail 时要求一小时后自动收回，后来变成“反正现在就随便看吧”。戴冠兰给出的诊断是 “approval fatigue”，即审核疲倦。

• 鸟导邮件是这种信任升级的具体样本：Koji 让 Manus 寻找旅行目的地的专业鸟导、按行程询价，起初只写 draft，由她点击发送；发过三四次后，便让 Agent 直接发送，因为单次代价看起来不高。

• 戴冠兰的追问是：若 Agent 突然给 LP 发出“我不想干了”或“carry 太低了”之类无法撤回的邮件怎么办？Koji 的回答同样关键——今天没有这种恐惧，但只要任何人经历一次灾难性事故，行为会立刻转向极度谨慎。

10. 灾难性事故会成为治理基础设施的催化剂

• Runloop 的开源项目 Cloud Shell 已支持 OpenClaw、Hermes 等 Agent 的本地运行，并可用于管理邮箱；在 Runloop 上，数据库、代码仓库等资源的管理则需要复杂得多的控制能力。

• 戴冠兰明确预测灾难性邮件“必然发生”，“Mark my words”。他也承认包括自己在内的大部分人会“安全换便捷”，但认为一次不可逆后果足以迫使市场重新思考这件事应该如何管理。

• 他建议用硬规则划定权限，例如允许 Agent 读邮件但不能发邮件。Runloop 所说的安全不是主动扫描或特征匹配，而是确保 Agent 在可控边界执行，最坏情况可恢复、可审计。

• 目的并非把 Agent 锁死，而是让企业对它产生更多信任，在可控边界内使用包括非只读和生产权限在内的更高权限，从而释放真正的能力。

11. Web coding 超过 95%，人类价值上移到架构判断

• Runloop 内部 web coding 比例超过 95%，戴冠兰称入门程序员的工作基本上都由 Agent 代替。人类仍不可替代的部分是架构、API 设计、组件解耦，以及做过基础设施后形成的底层判断力。

• 用 Agent 写代码、再治理其他 Agent 显然存在风险；团队需要预警机制，判断 Agent 是否仍在有效期内。同时，团队每天使用自己的平台，让 Agent 在自己的执行环境里工作，并用产品进行自我迭代。

• 他个人转向 Codex，是因为它“人狠话不多”，像“德国人”一样埋头完成任务；Copilot 则更 chatty，会不断反问。Codex harness 开源也很重要，Runloop 发现问题后可以向上游贡献修复。

• 团队没有统一 model router，而是让工程师自行选择 Codex、Grok、Fireworks 及一些国产前沿模型。前端或出错后恢复半径较小的任务可交给没那么强的模型，要求则是工程师最终交付一个自己能够负责的结果。

12. 模型层既不是安全边界，也未必是长期利润池

• 戴冠兰认为，只要底层仍是 Transformer 和 next-token prediction，即使演进到 GPT-7、GPT-8，也依然是概率性执行。模型看到的都是 Token，无法从根本上判断某段内容是控制指令还是数据，特殊分隔符也可能被绕过。

• Koji 随后提到一则事故：据他的叙述，OpenAI 的模型曾入侵 Hugging Face、拿走 reward signal；在后续调查中，OpenAI 模型因安全限制停止响应，反而是一个并非 SOTA 的开源模型帮助定位了问题。这是 Koji 用来追问开源与闭源竞争的案例。

• 戴冠兰认为开源模型会持续爬坡：他点名 Kimi 已接近 SOTA、进入第一梯队，DeepSeek 最新的 Flash 模型也展示了“多、快、好、省”的进步。至于模型何时商品化，他只判断终局会到来，却明确保留“一年还是五年”的时间不确定性。

• 戴冠兰称“Fable 5”和 Opus 对开发者已没有本质差别，性能爬坡正在放缓，由此下出“模型能力已经够了，要卷就卷基础设施”的判断。他个人更关注视频模型——继 coding 后第二个被证明能赚钱的模型赛道——以及 AI for AI、Auto Research 等训练范式。

13. 押职业与押公司，本质都是识别浪潮和人

• 给年轻工程师的建议并非单纯节省 Token，而是入职初期先 Token Maxing，利用没有历史包袱的优势；同时对旧系统保持敬畏，主动训练架构和底层思考能力。

• 戴冠兰加入 Cloudflare 是看见边缘计算浪潮，加入 Kong 是看见约 2020 年前后的微服务与云原生浪潮，当时 Kubernetes、Mesos、Docker Swarm 仍在混战。如今他创业，是因为 Agent 浪潮“非做不可了，不做我会一辈子后悔”。

• 选择早期公司时，他最看重人和团队能否“往下吃一层”：大部分人满足于能用，只有 10% 甚至 5% 以下会钻到 kernel、算子、调度、网络协议栈，亲手拆系统并快速吃透新技术。这也是他的招聘原则。

• 尽调职业机会要把自己放在 CEO 位置做思想实验。他认识 Kong 创始人一年多，观察其从类似 OpenRouter 的 API 转售业务转型后才加入；Koji 将其总结为更重的投资测试：“如果你都愿意加入他”，比只投一笔钱更能证明 conviction。

• 戴冠兰把职业选择比作冲浪：浪潮来了就要跟上，等浪潮退去之后“收板回家”。对他而言，Agent 基础设施正是那波还未完全形成共识、但已经值得全力投入的浪潮。