@LangChain：“芯片设计中的很多瓶颈实际上是热问题。”@cognition 总裁 @russelljkaplan 谈及特斯拉之争……

芯片设计里的很多瓶颈,其实是散热问题。Cognition 总裁 @russelljkaplan 聊到了那场塑造他推理方式的特斯拉辩论。YouTube: https://youtube.com/watch?si=Ff-wq0tBPTx-SC8V&v=bBUotstDLdk&feature=youtu.be… Apple: https://podcasts.apple.com/us/podcast/the-misaligned-incentives-behind-ai-coding-agents/id1891551672?i=1000779120914… Spotify: https://open.spotify.com/episode/7JNB5YXA6NVgUDAhy8eA3V…

TL;DR:Cognition 总裁 Russell Kaplan 回顾了 Devon 从 2024 年发布时的 13% SWE-bench 分数,到如今用“可合并性”新评估 Frontier Code 衡量下一代编码智能体的过程;他反复指出,瓶颈已从“训练更大的模型”转向“运行评估”,而且成本与速度正取代能力成为很多团队最关心的事。

从病毒式演示到生产环境智能体

Russell Kaplan 说,Devon 在 2024 年 3 月发布时,那个演示视频“超级病毒式传播”。当时编码智能体还只是“刚刚处在可能的边缘”,你得“眯着眼睛才能看到:好吧,这东西将来是能成的”。他们拼凑了一个第一版例子,展示它可能是什么样子。

主持人补充了一个关键数字:Devon 当时在 SWE-bench 上大约是 13%,“几乎是之前最好成绩的三倍”。Russell 确认了这个数字,并说那“真的非常令人兴奋”。但他强调,从一个原型到“内部真正有用的东西”,又花了好几个月。

“我记得大概是在 2024 年 6 月,Devon 成了 Devon 的头号提交者,那是我们的第一个重要里程碑。”

这个里程碑来自大量手动“吃自己的狗粮”式的打磨。之后又花了好几个月才真正部署到生产环境,并在客户那里产生价值。

早期 PMF:迁移和重构

在 2024 年那种“异步云端编码智能体”时代,智能体其实做不了软件工程里的大多数任务,但已经有一些利基场景。Russell 认为早期最好的场景之一就是迁移和重构:

“如果你基本上跑一个类似 ReAct++ 风格的工作流,跨越一个大代码库,再撒上一点智能,这其实在 2024 年底就已经能跑得不错了。”

为什么这个场景特别合适?有几个技术原因:

1. 对于一个非常大的重构、迁移或 ETL 转换,本身就值得投入精力去精心做 prompt 工程,让云端智能体保持准确性。
2. 你可以在 prompt、设置和喂进去的上下文上反复迭代,调整到刚好合适后,就可以把它应用到代码库里 10,000 个模块上。
3. 这是非常高的 ROI,而且明显比单纯的查找替换、字符串改动要好得多。
4. 它不需要那种“我们现在委派各种编码任务时所需的完整通用软件智能”。

所以即使在早期,这个场景也运行得不错,但它仍然有点小众。

自助服务版与 Slack 界面

到了 2024 年 12 月,Devon 发布了自助服务版,任何人都可以注册。Russell 说当时内部有一场大辩论,到底应该重点强调什么、聚焦在哪里:

“我记得我们当时把整个公司飞到了犹他州,就是为了在 12 月集中把所有事情搞完,把它推出去,赶在年底之前。”

最终他们确定把 Slack 作为主要界面。整个自助服务版的发布视频,内部叫它“Devon 里的 Devon”,内容就是“在 Devon @ Devon @ Devon”——目的是强调一种用户体验上的变化:和智能体的协作更像是和队友协作。

从那之后,Devon 获得了更多用户和增长。Russell 说,云端智能体从那以后一直在变得更好,无论是基础设施、成熟度、模型还是执行框架(harness)。“现在我认为大部分工作就是通过直接委派给异步智能体来完成的。”

智能体真正起飞靠什么?

主持人问:有哪些东西变好了,才让它们真正起飞?Russell 的回答是:人们总是谈模型变好了,这当然超级重要,但基础设施的成熟度也是一个关键因素。

模型能力的几次“阶跃变化”

Russell 提到几个阶段性的模型变化:

• 大约 2024 年 11 月的模型系列是一次巨大的阶跃提升,让他们觉得“这东西现在真的能好用很多了”。他们决定做自助发布,很大程度上也是基于那个(OpenAI 的模型)。
• Anthropic 的模型也开始变得非常好。
• 大约 2025 年 7 月,又迎来了一次巨大的阶跃变化。
• 现在有了 Fable 5 这样的东西,新一代模型仍在持续阶跃变化。

但 Russell 说,阶跃变化的幅度已经高到“不再只是能力提升”。在某种意义上,他看到的是相反的趋势:软件工程里越来越多的任务正在变得“智能饱和”。

“很多开发者的敏感点已经从‘等等,我必须用最好的模型’完全变成了‘我的天,我在编码智能体上花了这么多钱,怎么能更省一点’。”

对于某些工作负载,你总是想要最前沿的智能,尤其是多方之间的对抗性游戏,比如竞争性交易或类似场景。但对于很多想构建的软件来说,会存在一个饱和阈值:一旦它足够好了,你真正关心的就是速度和成本。

主持人还援引了一个观察:有些组织里,人均 token 支出已经开始超过人力薪资支出;而通过更聪明的路由,“我们可以获得大约 35% 更好的性价比,同时质量还略有提升”。Russell 说,这正是他们在大量需求中看到的趋势。

模型选择:没有“最好的模型”,而是组合使用

主持人问 Fable 类模型适合什么任务。Russell 说,最新这一代模型在几个领域有特别大的提升,首先就是网络安全漏洞的检测和修复。

他提到一个有趣的细节:Fable 类模型的公开版本现在有很多护栏,所以实际上要引导它们帮忙“可能会有点棘手”。但在实际使用中:

“如果你只是说‘清理一下我的安全积压’…… Fable 类模型在高精度方面确实很好。但我们实际上发现,GPT-5.5 和 5.5 Cyber 在召回率上更好。所以你必须两者都用。”

换句话说,目前“找到并修复安全漏洞”的最佳执行框架(harness),是用 GPT 系列找出更好的候选,再用 Fable 系列处理。这是一个很大的例子。

另一个例子是处理来自 Datadog 等系统的集成数据。Russell 说他们确实看到 Fable 在自己的评估上有一个阶跃式的提升。主持人问是因为那些数据特别庞大且杂乱,所以需要更多智能吗?Russell 认为很大程度上是的:

“是因为有数量上的考虑。也有多步推理上的考虑。而且我觉得你可以看出来,在这些非常真实、并且被大规模放大的数据源上,做了很多强化学习。”

第三个类别,也是最明显的类别,是他们在构建编码新评估时才学会检测和理解的一个类别。

Frontier Code:衡量“可合并性”的新评估

回到 SWE-bench:当 Devon 在 2024 年发布时,分数是十几分;现在 SWE-bench 已经完全饱和了。于是他们需要寻找下一个难度的评估层级。

Russell 说,他们把所有的 evals 都看了一遍,却找不到任何能匹配内部那种模糊直觉的评估——就是“这个模型感觉好得多”的直觉。深入挖掘后,他们发现评估里的核心缺口在于“可合并性”:

“这段代码技术上是对的,但你真的会把它合并进去吗?你会为此感到开心吗?它会不会提升你代码库的质量?”

“可合并性”可能意味着:在风格上符合你已有的预期;意味着它的实现方式未来容易修改;或者如果将来有其他修改发生,它能够优雅地处理这些修改。这些“小的风格上的东西”都没有被现有评估捕捉到。

所以他们做了一个新评估,叫做 Frontier Code,用来更好地衡量这一点,同时为前沿编码能力设立一个新的更高难度水位线。Russell 强调:“这是新的最难的编码评估。”

怎么创建 Frontier Code?

创建过程的第一步,是找到“品味极高的开发者”——既要有很强的风格质量,也要有很高的代码正确性标准——来回答那个核心问题:你真的会合并这段代码吗?而不仅仅是这段代码能不能通过测试、功能上正不正确。

他们和很多领先的开源作者做了深度合作和招募活动。Russell 说:“如果没有他们,这是不可能完成的。”具体做法是:

“我们要去找开源社区里那些最知名、编码标准非常高的库,然后和他们紧密合作,把他们对‘什么样的 PR 我会接受’的人类直觉,编码成精心设计的测试。”

这些测试既包含程序化断言,也包含正确性测试。风格元素也可以用程序化方式断言。Russell 举了个例子:

“如果你在这个 PR 里做了这个改动,你必须使用这个模块,即使现在用另一个模块是等价的;但长期来看,如果它们发生偏移,如果你没有用正确的模块,将来就会引入 bug。”

这种断言可以通过确定性方式执行,但需要人类作者来判断和敲定。

另一个关键原则是:Cognition 团队的每一位研究员都亲手贡献并审查了评估。Russell 认为很多做机器学习、和智能体协作的人仍然做得不够:

“这可不是你随随便便扔过墙、然后说‘好吧,数据质量这块是个苦差事,别人去做吧’的事情。你必须自己直接投入进去。”

主持人提到,很多团队会讨论如何用 Linksmith 之类的东西为自己的系统构建评估;Russell 说 Frontier Code 会跑在开源代码库上,他们可以在自己的基础设施里运行。为了避免污染,他们没有公布完整的问题集,只公布了一些示例问题,并希望能尽可能多地为社区保留这个评估,直到它被完全超过。

至于 Frontier Code 的成绩:Diamond 子集在 Fable 5 之前是十几分,现在 Fable 5 已经把它推到了三十几分。Russell 笑着说:“所以我们就有了……我不知道这个评估还能撑几个月。”

从特斯拉到软件工程:瓶颈的转移

Russell 回忆说,自己的机器学习职业生涯是在特斯拉的自动驾驶团队开始的,那是 2017 年左右。当时的瓶颈非常明确,就是 GPU 和算力:

“你会想:好吧,怎么搞到更多算力,我们就是需要更多算力。”

但他在节目录制当天和特斯拉的朋友聊了聊,发现情况已经变了:

“瓶颈已经不再只是训练越来越大的模型,而是运行评估。因为对于自动驾驶系统来说,人工干预太罕见了,你必须在海量的驾驶里程里才能发现堆栈里的任何一个问题。”

他把这个类比带到软件工程上。Russell 说,软件工程还没到那一步,仍然能发现 bug,但“我们可能比想象中更快触达那个阈值”。

这也是 Cognition 整体思路的一部分:用专门的评估智能体检查一个会话是否高效,从而对客户做出“1000 万美元生产力保证”之类的承诺。但 Russell 也承认,随着智能体能力持续变强,做出能区分“好”与“足够好”的评估会水涨船高。

“我担心的是,要找到好的 evals、好的基准,会随着能力提升变得越来越难,因为你需要更强的方法来评估你自己的智能体。”

当前瓶颈:电力和数据中心的传输功率

主持人问到:芯片设计的瓶颈到底是什么?Russell 在节目中最喜欢的一句台词是:

“芯片设计里的大量瓶颈,其实是热。你花了很多精力把布局摆好,但最后其实是在处理散热。”

但他澄清,有两大类问题:有些是内存受限或数据移动受限,还有的是 compute-bound。而在软件工程中,瓶颈更普遍地是数据移动和推理成本,而不是训练时的接线功率。不过他也同意,当你不断把更大的模型堆到同样的系统里,训练和推理的接线功率本身确实会成为瓶颈,这也是为什么他认为在推理侧,一个重要的瓶颈是“电力与数据中心的传输功率”。

然后他转回作为一家公司的心智模型:这基本上是一个如何分配计算和成本的问题,而且这个问题没有简单的答案:

“大多数 AI 应用仍然处于这个比例关系之中,烧钱、烧任务,烧得越多收益越高,直到某个收益率递减的点。而在那些收益率递减的点上,你确实会看到工作负载对价格极其敏感。”

编码智能体实用建议:启动、扩展和选择最佳模型

给构建者/初创公司的建议:以“开发者出活”为中心

主持人问:对于还在观望的人,这个空间发展这么快,应该从哪里开始?Russell 说,最重要的原则之一,是早上醒来想的应该是“如何让开发者出活”,不管采取什么形式。他把这称为“Devon 的核心指标、北极星指标”:

“围绕这个北极星去构建一切:设一个目标,然后往后推导需要什么工具、需要什么基础设施,才能把这个目标做对。”

内部他们围绕这个指标构建了链路跟踪、可观测性、评分系统等所有东西。然后,对正在构建编码智能体的团队,他还有一个建议:给你的评估环境喂大量真实任务:

“基本上,每次客户给你一个任务并且做成功了,你必须把它收进你的评估环境里,作为你的长期 evals。没有捷径的。”

到某个点,这就成了护城河:你从大量真实任务里积累起来的评估基础设施和测试集。

给 Agentic Rollout 的策略:从 20 个开发者试点开始

主持人问:如果我想在团队里 rollout,怎么选 pilot 组?Russell 认为你应该从“至少 20 名开发者”这样规模的试点开始,而不是 2 个人随便玩玩:

“因为你要清楚地看到数据。如果是 2 个人,你会被个别的极端情况带偏。20 个人才能真正反映大多数情况。”

而且要让开发展拥有真正的所有权和负责感,把试点设计成他们有动力去尝试的工作流。他警告说,组织里过早的标准统一化会扼杀创新——这主要是心理层面的原因:

“如果有一两个开发者在这样的环境里做试点,他们很容易在文化上感到‘如果我搞砸了怎么办’的焦虑。所以你需要一个心理上安全的环境,在那里的人们愿意去尝试、乐在其中,并且相信别人会理解这可能会失败。”

不过,至少 20 人的规模会带来一个问题:你如何知道他们用了正确的模型组合?主持人指出,Cognition 的 evals 显示,在内部基准上,Fable 5 编码能力强很多,而在外部基准上差异不大。如何帮助这类组织部署?Russell:一切都要给你的内部环境做评分,通过测量每个模型在每个客户环境里的特性来持续调整模型选择。

模型选择:为任务选择合适模型

• GPT-5.5:通用全才,完成大多数任务,速度和成本都不错。
• Fable 5:写得少,但写得非常仔细,擅长推理密集型、正确性敏感和安全类工作。更高的推理成本意味着你应该把它放在那些推理困难的任务上。
• 更小/更便宜的模型:对于简单任务,真的不需要太大;一个更小的模型可能就能很好完成任务且便宜得多。
• 长上下文模型:在某些情况下对拖拽大量上下文很有好处,对 5000 行文件做改动也很有用。
• 路由的重要性:好的路由策略能带来 35% 的成本改进,而质量没有下降。

主持人也问到了 Anthropic 模型在那一代的表现。Russell 说,Anthropic 的模型“在那次阶跃变化之前是标准”“非常好”,而且它们是市场上真正推动了智慧能力的少数几个竞争者之一。但“我会把事实就那样摆出来:对于编码来说,还没有看到它们在性能上是标准’。他们的模型确实很不错。”

他补充说,这里有个重要的复杂因素:不同的模型在不同的客户环境中的表现不一样,而且你必须考虑到“单一模型部署的风险”:如果某一个前沿模型的能力向其他方向偏移,你就会受影响。他们的工程心里模型是某种“混合架构”:

“我们实际上是把几个前沿模型组合使用。我认为在这之后的很长一段时间内,这都是正确的做法。”

他还专门说到了 Anthropic 的 CLI 产品“在特定任务上非常出色”,而且使用命令行界面的人会有种几乎“上瘾”的使用体验。“我想顺便说一句,Anthropic 的 CLI 确实是我用过的最令人愉快的工具之一。”

1000 万美元生产力保证:如何衡量和完成

背景

主持人之前和一个 CIO 聊过,那位 CIO 对智能体很兴奋,但对于如何计算投资回报率感到沮丧。Cognition 为此推出的做法是“生产力保证”:为一家大公司承诺 1000 万美元的生产力收益,但只有在达到的时候才收费。

Russell 解释说,这个概念来自一个认知:许多客户(尤其是大企业)都对智能体能否真正兑现价值抱有怀疑和犹豫。所以他们想传递一个信息:这是我们有信心的东西,甚至可以签下协议,把我们的经济收益和它绑定。

这对销售和产品化和都很有用,也让团队聚焦:“我们不再说我们会交付这个软件、这些功能,而是说:我们会交付生产力。”他们会先做审计,和客户一起确定有价值的任务,然后围绕那些任务构建一切,设立一些护栏,再全公司推广。

但要做到这一点,你得能衡量生产力。这恰恰回到“可合并性”和他们内部构建的其它度量上。

衡量生产力:大规模评估

Russell 承认这很难,因为他们关注的是长期的、复合的开发者生产力,而不是单周内产出的代码行数。但他们已经有了一个内部代理指标:给智能体本身打分。

“我们的代理指标基本上是对智能体在每一个会话上的质量进行评分。”

具体做法是:对每一个会话,运行一个专门的评估智能体,它知道该任务的元数据,会用正确性、代码风格、是否有不必要的改动等维度来给会话打分。这个评估智能体本身必须非常强,才能真正评估一个会话“好不好”。这又回到了他们的理念:评估实际上是和智能体本身同等重要的系统。

主持人问:这些评估是什么?是用一个模型来评判另一个模型吗?Russell 说,他们的专业评估智能体会考虑“功能性正确性、风格、安全性、对代码库其余部分的干扰”等因素。然后:

“最终我们会在内部把这些分数之间结合起来,形成一个粗略的生产力指标。我们拿这个指标和客户看到的业务生产力之间做过校准。但它们是代理指标,不是直接测量。有时候客户会问我如何测量他们的真实业务生产力,这其实要一起设计。”

在客户层面,一旦界定了任务的价值,他们就会在部署前用 eval 来验证它带来了实际收益。但 Russell 也承认,团队自身的生产力提升(他们开发用的编码任务有 50% 以上都由 Devon 完成)比较容易量化,因为整个过程是可追踪、可评分的。

他们如何评估一个 10 分钟会话是否浪费了?

最后主持人抛出了一个很有意思的问题:对于一段大约 10 分钟的会话,如何判断智能体是否“浪费”了那段时间?比如 10 分钟里,它在做没有成果的循环,但它看起来在做事情。

Russell 说,他们的基础做法是代理评分器(grading evaluator),这个评分器能看到会话的完整回放,包括每一个逐步的 token 生成和所采取的工具调用。他们已经在尝试让评分器实时评估一段会话做得好不好,然后实时介入。但是:

“让一个评估智能体实时运行,让它决定干预、纠正这个过程,这在技术上非常困难,因为你其实是在构建另一个智能体。”

换句话说,你基本上需要一个完整的智能体,才知道另一个智能体做得好不好。这又体现了他反复讲的那个主题:瓶颈不是模型能力,而是评估能力。

其他有意思的想法

• Devon 很看重“在 eval 循环里,模型切换要快”:在编码智能体场景,保持快速切换模型的灵活性是很重要的。
• 路由带来的成本节省(35%)来自“更智能的成本和任务复杂度的匹配”。
• 不少公司像“一群拿着旧云原生理论的程序员”来做编码智能体,但真正需要的是从开发者的实际生产力出发来考虑问题和设计架构。
• 对于“关键任务”的提示,一个“足够好”的最强模型加“边缘情况”的辅助,会比只用一个最强的模型更好,也许未来我们会更多看到这类模型组合。
• 关于安全、合规等问题,Russell 认为,智能体在引导方面的一些阻碍,可以做得比现在好得多,但保险模式和对责任的恐惧会拖慢进度。

结语

Russell Kaplan 的核心洞察可以浓缩成一个矛盾:瓶颈不是智能,而是评估。随着智能体能力的持续提升,真正的稀缺资源变成了判断“好”与“足够好”的能力。编码本身在变得“智能饱和”;在 2025 年,部署前沿模型、测算它的价值,比训练更好的模型更棘手。这正是为什么 Frontier Code 和代理评分器这样的系统,慢慢成为新的护城河。