微软CTO:AI已经“能力过剩”,行业需要努力缩小模型能力与实际产品交付之间的差距

360影视 日韩动漫 2025-05-22 16:35 3

摘要:在Scott看来,模型的推理能力已经超前于目前实际应用这些模型的方式。整个行业现在需要共同努力,去弥合模型实际能做的事情和交付给用户的产品之间的差距。

微软CTO Kevin Scott日前接受媒体采访,就AI代理,编程的未来等一系列问题阐述了自己的观点。

在Scott看来,模型的推理能力已经超前于目前实际应用这些模型的方式。整个行业现在需要共同努力,去弥合模型实际能做的事情和交付给用户的产品之间的差距。

为了让代理(agents)真正变得有用,目前AI需要更好的代理记忆系统(以处理更复杂问题),同时需要一个生态系统,它应当像互联网那样(以获取信息)。

“AI代理编程”并不是过去四十年来软件开发第一次经历巨大变革。重点不是怎么做,而是要达成的目标。当工具发生变化时,要保持开放的心态。

以下是访谈重点:

模型的推理能力已经超前于我们实际应用这些模型的方式。整个行业现在需要共同努力,去弥合模型实际能做的事情和我们交付给用户的产品之间的差距。

除了“推理能力”之外,还有很多其他方面的问题需要解决,才能让代理(agents)真正变得有用。这意味着我们需要更好的代理记忆系统,同时需要一个生态系统,它应当像互联网那样。

如果你真正去想象代理能够做什么、普通用户希望它们变得多有用——你就会发现,我们需要像当年互联网兴起时那样的一系列变革再次发生。这一幕的雏形,比如MCP协议,它就是一个非常好的例子。

“AI代理编程”并不是过去四十年来软件开发第一次经历巨大变革。不管是软件还是其他东西,重点不是怎么做,而是我要达成的目标。所以我会选择最强大、最方便的方式去实现它。当工具发生变化时,要保持开放的心态。

我当木工的时间几乎跟我写程序一样久。我十几岁那会儿,圈子里最大的话题是:你如果用了电动工具,你还算是真正的木工吗?真正的木工只用手工工具!今天这种争论仍然存在,不过换成了:你用了 CNC(计算机控制的数控工具),你还算真正的木工吗?

现在最关键的区别,出现在产品设计者的思维方式上。目前一些初创公司,他们并不是靠搞出一套全新的基础设施来创新的;他们创新的方式是:他们对某个用户问题的理解,比任何人都更深入。然后他们基于现成的基础设施,或做些微调,就能以世界级水准来解决那个问题。这种方式,才是我们现在真正需要的。

我认为接下来我们会看到,人们用代理去解决的问题会越来越复杂、越来越有雄心。同时,“代理网络”会越来越完整,连接越来越充分;模型的推理与规划能力也会变得更强。这将促使我们从现在的“同步交互”模式,进入到一个更强的“异步交互”时代。

以下为对谈全文:

主持人:Kevin,欢迎来到我们的节目。

Kevin Scott:不用谢。

主持人:谢谢你来。一件很有意思的事是,我去年也访问过你。你当时说了两件非常重要的事情。一个是——代理(agents)将会无处不在。

主持人:你说的这件事真的成真了,而且来得非常快。还有一件事,我注意到去年你特别强调“规模定律”(scaling laws),对吧?

主持人:当时你展示了很多图表,说我们正在建造大规模基础设施,训练更大的模型,而且每两年性能就会有一次飞跃。但今年,你的重点似乎更多放在“代理网络(Agentic Web)”上。发生了什么变化?从去年到今年,我们学到了什么?

Kevin Scott:

是的,我觉得发生了很多变化。其中一件事是,去年很多人还处在一种怀疑状态中,他们在怀疑“规模定律”是否还能继续有效。而事实上,我们年复一年已经证明,它们依然有效并且运作良好。所以现在已经不再需要向人们重复这一点了。

Kevin Scott:

另一件事,说实话,是模型的推理能力已经超前于我们实际应用这些模型的方式。我最近一直在谈一个概念,叫做“能力悬空”(capability overhang)。

我认为,我们整个行业现在需要共同努力,去弥合模型实际能做的事情和我们交付给用户的产品之间的差距。这也是为什么在今年的 Build 大会上,“规模定律”不像去年那么吸引人的原因之一。

Kevin Scott:

还有一点我们发现了:随着过去一年代理数量的爆发式增长,以及用户在这些代理中花费时间的增加,我们意识到,除了“推理能力”之外,还有很多其他方面的问题需要解决,才能让代理真正变得有用。这也是我今天在 Build 大会主题演讲中提到的重点之一:我们需要更好的代理记忆系统。

Kevin Scott:目前的代理记忆受限于许多方面,它们更像是一次性的、事务性的——你用它完成某个任务,期间记忆是连贯的,但这个记忆很可能会在下次交互时完全消失,这就使得我们很难将更复杂的任务委托给它们。

Kevin Scott:而且还有一个核心问题:如果代理要变得有用,它们就必须能够替你采取行动,能够使用工具,在系统中作出改变,访问丰富多样的信息源。

要实现这些,我们需要一个生态系统,它应当像互联网那样:如果你是信息源,你已经有了网站、有了 API,那么你必须弄清楚怎么把这些资源接通,让代理能与之通信,并且要让各方的激励机制协同一致,使他们愿意参与到这个“代理网络”中来。

Kevin Scott:所以我认为这才是今年最大的故事——我们看到了真正进展的曙光,比如 MCP 这样的超级简单、开放协议,在代理网络中扮演的角色就像 HTTP 在互联网中一样。还有像 NL Web 这样的标准,它在“代理网络”中扮演的角色,就类似 HTML 在网页世界中的作用。

Kevin Scott:我觉得你将会看到这些系统越来越多地采用简单、可组合、可层叠的结构,开放社区将会非常活跃,最终推动代理真正实现能力的落地。

主持人:那我总结一下我听到的意思:现在我们已经有了代理(agents),而且它们开始真正发挥作用了,对吧?而要让这些代理变得强大,它们就需要访问权限。

主持人:它们需要能够访问互联网上的各种资源、你电脑上的内容,等等类似的信息。也就是说,你基本上需要建立起一套协议和流程,来让代理可以访问这些东西,对吧?

主持人:所以你现在关注的是整个技术堆栈的不同层级——比如说运行时层面,你们在那儿构建记忆系统、其他组件;然后还有像 MCP(memory coordination protocol)这样的协议,它能把代理连接到更广阔的互联网世界,从而获取信息,让信息流入代理系统中。

主持人:那我想问一下,**这件事对微软来说为什么重要?**你们希望在这个生态系统里扮演什么样的角色?

Kevin Scott:嗯,我觉得这里面有两点,也可能是三点特别重要。

第一点是,我们自己在做代理。而我们做的这些代理要对用户真正有用,就必须解决这些底层问题。就算你把范围缩小到企业级代理,作为微软的 CTO,我一直在推动的一件事就是:我希望我们公司内部所有系统都采用统一的标准协议,能和我们内部构建的代理对话。

Kevin Scott:这样我们才能避免把整个世界暴露在所谓“康威定律”(Conway’s Law)之下。你知道,康威定律是软件架构里一个非常有趣的现象。

康威说,一个系统的结构往往会反映出开发该系统的组织结构,比如编译器的阶段数通常由负责这些部分的团队数量决定。

主持人:没错。

Kevin Scott:所以你想象一下,如果你在微软这样的大公司内部开发东西,你肯定不希望你造出来的代理,其结构完全是按照你的组织结构拼出来的。

但现实中如果你没有通用的协议和标准服务,这样的“组织图产品”就会反复出现。作为工程师,看到那种低效开发场景,真的很让人抓狂。

Kevin Scott:

但我认为,更重要的是,如果你真正去想象代理能够做什么、普通用户希望它们变得多有用——你就会发现,我们需要像当年互联网兴起时那样的一系列变革再次发生。我现在就能看到这一幕的雏形,比如 MCP 协议,它就是一个非常好的例子。

Kevin Scott:它是一个非常简单但关键的协议,解决了一个非常重要的问题——不仅是为那些构建代理和平台基础设施的人服务,也同样帮助了系统的最终用户,让他们的体验变得更加有用。它还为那些服务提供方提供了机会,比如有人可能会说:“我也想参与到这个新型的大网络里来。”

但现在的问题是,很多人以前知道怎么去连接某个服务、怎么构建服务,但如今他们面对的是一群代理,坐在那里思考:“我该怎么把我的系统接进来?这对我到底意味着什么?”

Kevin Scott:甚至从商业模式的角度来说,他们也会想:我为什么要接入这个系统?它对我到底有什么价值?

所以第二点就是——我们希望让自己构建的代理变得更有用。

Kevin Scott:第三点是,作为一家平台型公司,这一点甚至比我们自己要写的代理更重要。微软已经在构建平台技术这条路上深耕了五十年,我们想要确保,当这个全新的“超级网络”兴起时,我们能够帮助解决其中出现的问题。

主持人:是啊,看到你们现在在 MCP 上投入这么多,并把它整合进整个 Windows 系统,真的很酷,很厉害。这让我想到一个问题——我最近听到一些人在讨论 MCP,他们开始关注它的安全模型问题。

主持人:我很好奇你是怎么看这个问题的。因为你前面提到过很多 MCP 技术栈和互联网技术栈之间的类比。而我们知道,互联网是有一套完整的安全机制的,比如“同源策略”(Same-Origin Policy),它确保了网站在执行代码时只能操作自己域名下的数据,对吧?但 MCP 目前似乎还没有类似的机制。所以你觉得,什么样的安全模型才是适合 MCP 的?

Kevin Scott:嗯,说实话,我也不敢说我完全知道什么才是“正确”的安全模型。但 MCP 有一点很有趣,就是它的设计极其简洁明了,这其实使得整个社区可以相对容易地就这个问题达成共识。

Kevin Scott:我们在企业层面上确实有很多非常重视的需求,我们也和 MCP 团队合作得很好,正在推进相关工作。

Kevin Scott:比如说,我们需要让代理具有“身份”——这样我们才能建立起权限系统。你可以定义:某个代理是代表某个用户在操作,然后它就有权访问系统中某些资源。

Kevin Scott:甚至代理本身可以主动查询多个系统,然后说:“这是我想完成的一件事,要实现这件事,我需要访问以下这些系统。那我需要获得哪些权限才能做这件事?”

Kevin Scott:它可以向被委托给它的用户请求授权,说:“你能不能给我访问这些资源的权限,这样我才能替你完成你交代的任务?”是或否。

然后系统管理员也需要有权限来审查,比如:“我是否允许这些操作发生?”所以,这整个流程虽然并不“简单”,但其实在 MCP 架构上实现起来是可行的、逻辑清晰的。

Kevin Scott:而关键在于:我们应该以开放的方式来做这件事。我们并不希望这些机制是专属于微软代理或微软系统的——我们真正需要的是让它像互联网一样运作的生态系统。

主持人:对我来说,这其实是个很有意思的问题。我觉得现在围绕 AI 的发展,有两种可能的模式或者“市场路径”(Go-to-Market)正在浮现,而你们微软似乎都在关注这两个方向。

一种是所谓的“垂直一体化”模式,在这种模式下,你控制模型、应用、整个上下游——一切都在你手中。

主持人:而这种模式的一个好处是:安全性可以得到很强的保障。就像苹果的 App Store 或 iPhone 模式,你可以在多个层面上强制安全策略。

但另一种则是“开放模型”——你牺牲一部分控制权和安全性,但能换来更强的创新活力,因为没有中心化的权威机构去限制开发者。

所以我想问的是,你们在微软是怎么思考要走哪条路的?你们是怎么做出这个决策的?

Kevin Scott:是的,你看,这确实是很多人现在在讨论的一个核心问题——但我觉得,那可能是一个伪命题(false dichotomy)。

你知道,在这些开放系统中,它们的特点是“无需许可”(permissionless)。这种开放式创新的能力,确实带来了巨大的优势。对我个人来说,现在最让我兴奋的一件事就是:你可以不经任何人批准就去创新、去构建产品,不需要别人给你发许可,不需要通过什么中介流程才能把你的作品推向世界。

你不再需要通过一堆复杂的守门人机制,在你这个有想法的人与那些可能真正从中受益的人之间设下重重阻碍。

Kevin Scot:我觉得我们这几年建立起来的那些“中间层”,其实并没有为最核心的两方带来多少价值:一边是辛辛苦苦做出东西的人,另一边是愿意为这些成果付出注意力、金钱或其他资源的用户。

这就是为什么我对开放系统特别兴奋,也正是我们在做战略选择时的重要原因之一。

Kevin Scott:但我也认为,在这些系统中,其实是有办法实现强健安全性的。我们可以借助 AI 本身的一些能力,构建出更智能的安全模型。

比如说,你运行的代理可以照顾到你个人的安全需求——哪些信息你愿意分享,哪些你不愿意;它还能做风险评估。

我举个实际例子:今天早上我正准备上台演讲的时候,突然收到一堆邮件,因为我是我妻子的备用安全账户。

有人在她账户上尝试篡改两步验证(2FA)设置。我第一反应是发短信给她,而不是发邮件——因为我担心她的邮箱可能已经被未经授权的第三方访问了。

Kevin Scott:我发信息问她:“你是不是在改配置?”她回复:“是的,是我。”

所以你可以想象,如果有一个代理可以接入你多种通信渠道,监测到这种异常行为,并调用各种资源进行“三角校验”,判断这些行为到底是合法的还是非法的,那将是非常有用的。

所以我认为,两种模式是可以共存的。并不是说非得二选一——就像你刚才设想的那样。

主持人:这很有道理。我还有一个特别好奇的问题是——现在看来,软件工程正在发生根本性变化,对吧?

而你是一个在软件工程领域深耕多年的老兵,我觉得你也很重视“工艺”本身——制作事物的技艺。

我们刚才聊到你平时做陶艺、做包,喜欢亲手参与制作的过程。我觉得很多人对“用代理写代码”有点抵触,觉得这样会削弱那种“手工打造”的感觉,虽然我并不完全同意这个观点。

但我还是很想知道,作为一个真正关心编程工艺的人,你怎么看待未来的“代理编程”?

Kevin Scott:我先说一句,我真的很欣赏“我的人”——我这里说的“我的人”,指的是广义的创作者群体。

包括软件工程师、机械工程师、木工、陶艺师等等这些人。我们都是从零或者原材料开始创造新东西的人。

Kevin Scott:如果你真的热爱你的工作,你一定会对怎么做、用什么工具、用什么材料、如何组合这些细节有非常强烈的主张。这是你成为真正优秀从业者的必备条件。

但有趣的是——人们的观点五花八门。

正如你刚才提到的,我做这行已经很久了——我写第一个程序的时候只有 12 岁,也就是说我编程已经有 41 年了。

Kevin Scott:如果你在一个领域坚持得够久,你就会看到:这并不是过去四十年来软件开发第一次经历巨大变革。每次这种变革发生时,人们都会对其含义有非常强烈的反应。

但现实是,人们是有选择权的。

我现在仍然喜欢用文本编辑器。说实话,我可能不该说这个,因为我们公司做了 Visual Studio Code(笑),但我就是一个老古板——我还在用 vim。

Kevin Scott:至少我会用 vim,但我最爱的还是那种古早的编辑器。我就是不愿意换别的工具。

尽管我知道,这在某种程度上已经降低了我的效率,但我还是出于“自主选择”的理由坚持使用它。

但在我做的其他项目中,比如不管是软件还是其他东西,有时候我也会说:“这里的重点不是怎么做,而是我要达成的目标。”

所以我会选择最强大、最方便的方式去实现它——不管别人会不会因此嘲笑我。

Kevin Scott:

这种情况无处不在。比如我当木工的时间几乎跟我写程序一样久。

我还记得我十几岁那会儿,圈子里最大的话题是:“你如果用了电动工具,你还算是真正的木工吗?”

“真正的木工只用手工工具!”

Kevin Scott:

今天这种争论仍然存在,不过换成了:“你用了 CNC(计算机控制的数控工具),你还算真正的木工吗?”

我觉得这种讨论本身就很有意思,但最终大家做出不同选择,是因为他们的价值观不同。

如果你更重视过程,你可能会做出完全不同的选择;而如果你更看重结果,你就可能用别的方式。

主持人:我觉得类似“你算不算是真正的木工”“你是不是个真正的程序员”这种问题,说到底其实是在说:“只有按照我成长时的方式去做,你才是真正的XXX。”这其实是一种有偏见的说法。

Kevin Scott:对,是这样。但现实是——这个世界的情况太多样化了,对吧?

所以我要说的是:我绝不会告诉任何人不要对自己的技艺有强烈的主张。你尽管有你的坚持,那很好!

但如果说我有什么建议的话(这不是命令,只是我个人发现有用的建议),那就是——当工具发生变化时,要保持开放的心态。

Kevin Scott:

我都数不清多少次了,有些新的技术出现在其他“非软件”的创作领域,我一开始都会下意识地抗拒——比如说我当时对 3D 打印机完全提不起兴趣,我拖了很久才去学怎么用它们。

现在我真的后悔了,因为它们几乎对我做的所有事都非常有用。出于种种复杂的原因,我没有让自己产生好奇心,这是我自己的问题,也确实有点奇怪。

所以我的建议就是:保持好奇,去尝试。如果某样东西适合你,那就用它;如果不适合,也无妨。

主持人:没错。那么你怎么看“软件工程代理(software engineering agents)”的未来?

会不会出现那种“一个代理统治一切”的局面?还是说我们会同时使用很多具有不同风格的代理?你认为这个生态系统会如何发展?

Kevin Scott:我认为将来一定是有很多不同类型的代理。这是好事。

我们当然会在 GitHub Copilot 以及我们正在开发的 GitHub Agent 上非常努力,希望成为很多开发者首选的工具,因为我们想让它真的对大家有用。

但要说全世界的开发者都统一使用某一个工具来完成工作中的关键部分,我认为那不现实。

Kevin Scott:成为一个开发者的乐趣之一,就是你有权选择工具。你可以尝试各种东西,做一些看起来“非理性”的事,也可以选择完全理性的方式。

这是我在过去四十年程序员生涯中始终观察到的一件事:人们不断更换自己的工具。总是在变化。

主持人:那你有没有想过:这些代理会在哪些维度上有所不同?

Kevin Scott:

我觉得最关键的区别,可能会出现在产品设计者的思维方式上。

现在我看到最有意思的一些初创公司,他们并不是靠搞出一套全新的基础设施来创新的;他们创新的方式是:他们对某个用户问题的理解,比任何人都更深入。

然后他们基于现成的基础设施,或做些微调,就能以世界级水准来解决那个问题。这种方式,才是我们现在真正需要的。

Kevin Scott:这也会推动代理多样性的形成——哪些代理被用来解决什么问题,最终都会受到这个维度的驱动。

而且说实话,现在你更容易对用户的问题形成这种“细致入微的理解”,也更容易拿起各种工具尝试去解决这些问题。

所以我们会看到大量公司、团队去打造各种东西来尝试解决不同的需求。

Kevin Scott:哪怕在“软件开发工具”这个领域都已经开始疯狂了——过去一年冒出来的工具简直数不过来。

而且这些工具都挺有趣的,各有各的特点。

对于像我们这样的软件工具开发公司来说,这确实压力很大,因为你要应对那么多创新和变化。

但从技术角度来看,这真的太有意思了。

我们发现:只要你对用户的需求有某种细腻的认知,就总会有人愿意尝试你的解决方案。尤其是那些有高容忍度和高兴趣度的用户。

主持人:是啊。我们时间快到了,但我还有个问题。

假设一年之后我们又在 Build 大会上坐下来聊,你觉得:现在的一些热门话题或大问题,一年后会变得不再重要?而一年后什么会成为真正重要的讨论焦点?你有哪些预测?

Kevin Scott:

我觉得现在那些还在坚持说“这项技术还没准备好”的人——比如说:“我试过了,但稍微有点贵”或者“功能上还差一点点”——如果他们把这些当作不行动的借口,那他们很快就会被远远甩在后面。

因为这些问题都会随着时间变得微不足道:技术每年都会变得更便宜、更强大。

Kevin Scott:我觉得在 2025 年,这个观点其实已经不需要“游说”了。过去确实有很多人大声说:“技术进展很快就会停滞,大家都会失望。”

虽然现在还有人这么说,但我觉得已经没什么人认真听他们的了。毕竟你听这些“唱衰者”的话,又能获得什么呢?你是在赌失败,而“赌失败”和“赌乐观”之间的成本差异,其实非常大。

Kevin Scott:

Kevin Scott:现在的交互方式是:你坐下来,想着要完成一件事,然后给代理发出指令,等它返回一个结果,然后你基于那个结果再操作。

但到了明年,你可能会看到这样的使用方式:“嘿,去帮我搞定这件事。”

然后代理会花时间去处理:它会调用很多外部系统,它会去整合信息,它会反复迭代,它会不断处理、汇总、推进,最后,在一个非即时但有深度的时间之后,代理会告诉你:“我已经帮你推进到这一步了,接下来轮到你了。”

主持人:听起来真是我想活在的未来。

Kevin Scott:我也这么想,真心的。

主持人:好吧,Kevin,非常感谢你今天来参加节目。真的非常精彩的谈话。

Kevin Scott:很高兴能和你聊这场对话,我也非常享受,谢谢你邀请我来。

来源:华尔街见闻

相关推荐