The Rise of the Full-Stack Builder and Hyper-Leveraged Generalist with Microsoft CEO Satya Nadella

这个世界会对那些说“相信我们，我们搞得定，未来会无比辉煌”的 tech 和 tech companies 非常怀疑。这一次，你多少必须拿出切实可见的收益，因为这件事太重要了。它在整个经济中的占比太大了，不可能不是这样。

真正的雄心，在于把不可能变成可能。我从那些负责管理 Azure network 的人身上获得了极大的启发。我们在过去十五个月里建设的 Azure capacity，比前十五年建设的还要多。我的意思是，这太疯狂了。太夸张了。

我们的工作不是去做 Azure networking。我们的工作是去构建那个负责做 Azure networking 的 agentic system（代理式系统）。对吧？人们获取信息的方式、教育自己的方式、以及持续让自己保持更新的方式，都已经发生了巨大变化。也许下一个重大的 start up，会是某个打造一所新大学、甚至一种新 pedagogy（教学法）的人，去帮助人们完成一套 curriculum（课程体系），并找到极具价值的经济机会。

请欢迎 Swix Saragawa、Allod Gil，以及 Microsoft 董事长兼首席执行官 Satya Nadella。

你好，Saad。

我非常兴奋能来到这里。欢迎来到 No Priors in Lane Space 与 Satya Nadella 的一期 crossover episode（联动节目）。恭喜你们做出了如此精彩的成果。

不，真的非常感谢，很高兴能和你们二位在一起。我一直都在听你们两位——或者说这两个 podcast。很高兴能上节目。

非常感谢。

所以，今天一整个上午你刚刚都在谈 Microsoft 整个版图中的这些重大发布，我想大概谈了三个小时。你现在最重要的感想或收获是什么？

我想说有好几个点。也许对我来说最大的一个是：我们不如把这件事更多地概念化为一种 ecosystem（生态系统）打法，而不是单一模型、甚至单一平台，对吧？我的意思是，至少对我而言，我在 Microsoft 成长起来，也见过大概四次重大的平台迁移，我会比较认同这样一种观点：平台从根本上是由它创造的平台之外的价值，相对于它在平台之内捕获的价值的能力来定义的。所以如果你看现在正在发生的事情，我觉得今天早上的 keynote（主题演讲）其实是在讲：任何一家公司，不管是 AI native（AI 原生）公司还是传统 enterprise（企业）公司，如何都能以一等参与者的身份加入进来，能够指向自己创造的 AI，对吧？这并不是说他们不会使用别人的 AI。当然他们会。

但对我来说，问题在于路径是什么？配方是什么？我要怎么做？这个 stack（技术栈）看起来是什么样？tooling（工具链）又是什么样？

什么是有价值的？这件事该怎么做？就是这些。这某种程度上就是我们要做的工作。

对。生态系统战略非常复杂，对吧？因为你最后会自己构建某些组件，为另一些组件建立合作关系，并支持它们。你们刚刚发布了这一大套模型。跟我们讲讲 Microsoft 的训练策略吧。

对。

所以，我们想通过 MAI models 做的事情，是先构建——就像 Mustafa 说的——首先是一条非常好的 lineage（谱系），对吧？从 pre-training（预训练）开始，使用非常高质量的数据，做完所有的 ablations（消融实验），确保各方面都没问题。因为从某种意义上说，现在要构建一个谱系干净的模型反而更难了，仅仅是因为外面的内容太多了，你真的需要把很多东西通过消融排除掉，才能得到一个非常出色的 pre-trained（预训练）模型。事实上，这也是很多 open weight models（开放权重模型）的一个挑战：它们在一两个 benchmark（基准测试）上看起来很棒，但在实际使用中并没有那么好。所以这也是为什么，实际上即使在我们的 FDEs 里，大家也真的对这些 MAI models 感到非常兴奋，因为一个小小的 5B 模型到底怎么能 hill climb（爬坡优化）呢？

这又有点回到我认为最终最关键要做的事情上，也就是尝试去寻找那个 cognitive core（认知核心）。所以对我来说，要先从一个干净的 lineage（谱系）开始，然后建立一种能力，让公司能够使用它，对吧——不只是把它当作一个 generalist（通才模型），而是通过在它周围构建这个 hill climbing scaffold（爬坡脚手架），去创造他们自己的 specialist（专家模型）。对吧？所以不只是模型本身，而是你还要在它周围有一个 hill climb scaffold（爬坡脚手架）。然后你就会开始构建你的 RLE。

你会开始收集 traces（轨迹数据）。最重要的是，你会有 private evals（私有评测），因为我们知道外面所有那些 evals（评测）都不错、也很有意思，但在这个阶段它们其实没有那么关键，因为它们都可以被刷满。所以关键在于，每家公司都会有自己的 private eval（私有评测）。因此，围绕我们的模型展开的这种端到端平台叙事，就是我认为有意思的地方。还有一点，Sara，既然你提到了，我确实觉得这里有一个新的 frontier（前沿）。

比如，人们总是在谈 frontier（前沿），谈你是否在前沿上运作。有意思的是，如果你给它加入一点 temporality（时间性），你就可以用——比如说，实际上我们展示的那个 Land O'Lakes demo（演示）就很酷。我们用了 GPT-five point five，对吧？然后你收集了一堆 traces（轨迹数据），再拿一个 5B 的 reasoning model（推理模型），结果反而做得更好。所以这也是“看起来像是——我的意思是——在前沿上运作”所包含的另一个方面。

是的。我首先得祝贺你：你基本上在两年内就在 Microsoft 内部建起了一个前沿 neural lab（神经网络实验室）。我想问的是，你现在正在推出整套 AI strategy（AI 战略），那么你现在知道了哪些事情，是你希望自己两年前就能知道、并告诉当时的自己的？等等。

两三年前吧。Jensen partnership（与 Jensen 的合作）是三年前，MAI 是两年前。

是的。我的意思是，我经常会反思的一点是，对吧，显然，我最初是因为 skating loss paper 而对这一切感到兴奋的；还有，你知道，当初 OpenAI partnership 达成时，那些人说，嘿，我们会真的投入大量 compute 到 transformers（Transformer）上，而事实证明这确实有帮助。我总会回过头来说，哇，这些东西的 capability（能力）确实是在不断攀升。我的意思是，用一种很粗糙的说法来讲，“intelligence is log of compute” 这件事某种程度上是成立的。

但现在，我认为我们也许低估了的是：要把这些东西真正部署到现实世界中、让它们切实交付现实价值，其真实世界的复杂性。对吧？所以，任何 benchmark（基准测试）衡量出来的结果都很有意思，也很重要。但真正的 eval（评估）是：外面的人是否能够用它做出那些只有他们自己才真正看重的独特事情。而且这是可以非常明确衡量的。

对。这件事我希望我们当时在意识里能更早、更强地建立起来，对吧——也就是作为一个 industry（行业）整体。因为现在，我觉得当人们说，哇，我不想要 token max 时，这其实是一个 artifact（产物）：说明我们整个行业没有真正把“我们是在用 token（词元）一步一步创造价值”这件事想透。所以我想，这大概就是我希望我们当时能更早到达的地方；不过我也很高兴我们现在已经走到这里了。

你看到哪些 use case（使用场景）为你的客户创造了最多价值？因为我知道，人们谈 code（代码）谈得很多，而且我觉得很明显，这已经在产生非常大规模的影响了。除此之外，还有没有一些你发现很常见、并且客户确实从中受益很多的领域？

是的。我觉得，是的，正如你所说，显然，coding（编程）现在已经——不过顺便说一句，Ladish，就连谈 coding 这件事本身也很有意思，对吧？因为 coding 的效果好到一个程度：我们现在不得不重建 IDE（集成开发环境）了，对吧？我的意思是，看到我们推出的这些东西，真的有点疯狂。

感觉就像，哦，天哪，我这里有 100 个 agent（智能体）session（会话）。它带回到我这个人类身上的 cognitive load（认知负荷）实在太大了，所以现在我需要一种新的 UI（用户界面）。哦，顺便说一句，如果 chat（聊天）是唯一的 artifact（交互产物），那也同样行不通。所以，这就是为什么我们需要一个 canvas（画布式界面）。所以，围绕“软件到底还需要在哪里”“UI 到底还需要在哪里”这些问题，这一切其实都挺有意思的。

即使对代码来说，在一个完全 agentic 的世界里，你某种程度上也需要这一点，对吧。但话虽如此，我们开始看到的一件事是，我们开始看到这种协同工作；甚至我们用 Autopilot 展示的一些成果，对吧，你在 Claws 上看到的就是一个很好的例子。因为如果你仔细想想，大量的人力资本其实都在做那种胶水式工作（glue work），对吧；如果你现在能用长期运行、持久存在的 token agent 来增强这些工作，那么即便这些工作本质上仍然是判断性工作和胶水式工作，你扩展它们的能力也会像写代码那样被放大。所以我很肯定，六个月后，我们都会说，哦，哇。就像一整夜里，有一大堆事情，都是这些我让它们代表我工作、拥有我所委派权限的 autopilot 在替我完成。

对吧？我某种程度上甚至可以基于我的身份，让它做完一大堆工作。然后，当然，我会需要我的新 ADE 来说一句：你都做了什么？比如，这项工作是我做的吗？诸如此类。

所以我认为，工作流的压缩、任务的完成，很多价值就是在这里被创造出来的。

我觉得你提了一个非常有意思的点：一方面有实际在写代码的 agent，另一方面还有包裹在它周围的 harness。那就是环境、上下文，以及作为开发者你围绕 coding agent 所搭建的一切。那企业里的 harness 是什么？对于更广义的生产力工作，是否有一个对应的概念？或者你会如何理解这个被泛化后的概念？

没错。所以从某种意义上说，你会希望 harness 去定义 model、data 和 tool，这样你就能在这三者之间形成一个 loop。所以，我们首先要确保的是：我们构建的每一个产品，对吧，无论是 GitHub Copilot、security copilot、我们用 Emdash 展示的东西，还是 scientific discovery，都无所谓。它们全部都是带有 tool access 的 multimodal harness，这样你就可以对 tool 做渐进式披露（progressive disclosure），从而让它们在 token 使用上更高效。然后你再给它输入非常丰富的 context。

因为这也是我们过去两年学到的另一个艰难教训：天啊，你需要做的大量工作，其实是去准备 context layer，好让你的 plan 能以最高效率执行，而魔力恰恰就在这里。所以在我们这边，我们有 GitHub harness，本质上我们在所有产品里都在用它。它在 Foundry 里可用。而且我们是开放的——你可以用你的 Lama harness，或者别的什么；你也可以使用任何 open harness，或者你自己的任何 harness，再结合你的 tools、多个 models 和你的 context 来训练。所以这就是我们的主张。

因为现在很多讨论都在说，嘿，如果我把 harness、tools 和 model 一起训练，你就会得到 evals。而我们正在证明的是——其中最好的例子，就是我们用 Emdash 做的事，对吧？因为它发布时，发现了一些 mythos 没找到的 bug 或 vulnerability。所以我会说，这已经构成了存在性证明：你完全可以拥有一个 multimodal harness，而且它在现实世界里实际上可以有更强的性能表现。

所以，独立 Frontier Labs 背后的训练前提其实是：你知道，我们会拥有这些 models，我们会有一个 API 业务，也会支持 enterprise 和 startup，但真正驱动大部分收入的是 first-party product，不管是 productivity、code 还是 search。我觉得这和你刚才描述的 Microsoft ecosystem 是一种不同的价值方程。如果情况确实如此——如果确实如此的话，你告诉我，因为显然你们既有 first-party product，也有 enablement product——那么在那样一个世界里，developer 的角色是什么？比如说，什么会变难？developer 需要具备怎样的一组技能？以及 developer 会如何捕获价值？

对。所以我认为，一直都会存在这样一种情况：某个作为 platform builder（平台构建者）而极其成功的人，也同时会拥有 first party products（第一方产品）。Windows 时代是这样；在 SaaS 和 cloud（云）这两边，我们和其他公司也都是这样，等等。但关键在于，这不应该成为其他人也取得同样成功的限制，对吧？

我认为，这才是核心差异。这一次，围绕 intelligence（智能）的 network effects（网络效应）之所以如此强，是因为它们从 data（数据）中学习，而且其实不需要海量数据。你只需要看到少数几个 sample（样本），就能理解某件事的新意在哪里。所以，博弈就变成了如何保护这些东西。这也是为什么我会说，每家公司拥有 private evals（私有评测）也许会成为最大的 IP（知识产权），对吧？

我会这样想：那个 private eval（私有评测）到底是什么？你可以拿它来让哪怕是 frontier model（前沿模型）不断 hill climb（爬坡优化），同时又不泄露 traces（轨迹/痕迹）；这也许会成为 IP（知识产权）的最大驱动力之一。换句话说，另一个资产测试是：你有一个私有的 eval，用的是 model A。那你能不能切换到 model B，然后继续往上爬、持续优化？

如果你能，那你就在掌控之中；如果你不能，那你就不在掌控之中。而这也正是为什么，连 harness（调度/编排框架）的选择都会变得超级重要，对吧？所以，拥有一个开放的 harness，让所有 model（模型）都能接入，再加上你的 evals、你的 context（上下文）、你的 tools（工具）来帮助你持续 hill climb（爬坡优化），我认为这就是 AI native startup（AI 原生创业公司）、SaaS 公司，或者其实每一家 enterprise（企业）都需要具备的能力。

对。我觉得从一个非常真实的意义上说，你们某种程度上就是历史上的 Microsoft：先是一家 operating systems（操作系统）公司，然后变成一家 cloud（云）公司；也许第三幕就是，你们会成为一家 harness 或 evals 公司，不管你想把这组概念组合成什么名称。并且我觉得，赋能每一家公司拥有 frontier intelligence（前沿智能）——或者你当时用的那个准确说法我有点忘了——这就是使命，对吧？

没错。

这就是那个 platform（平台）的承诺：和我们一起构建，你就能为你的 data（数据）获得属于你的 intelligence（智能）。

对。对我来说，如果要为这整场 developer conference（开发者大会）提炼一句 tagline（宣传语），那就是：每个人都能否以自己的 frontier intelligence（前沿智能）在 frontier（前沿）上运作？对我而言，这一点太重要了，因为否则，我不知道你要如何实现 stable equilibrium（稳定均衡），对吧？也就是说，我要怎么才能进一步说，我的公司将会拥有 terminal value（终局价值），因为我现在已经知道，如何持续地在一个会不断变好的 platform（平台）之上进行 compound（复利式积累）。

对吧？所以当 Windows 显然推出之后，Adobe 做了，Autodesk 做了，或者甚至就拿 Jensen 说的话来讲。我们构建了 DX，而他在其之上构建了，你知道的，CUDA。对吧？我的意思是，我总会对 Jensen 说，天哪，这件事的功劳算是让他占尽了。

对吧？我真希望我们当时认出来这一点。但尽管如此，这样一种想法——你可以构建一个 platform layer（平台层），然后别人就能在其上进一步扩展，并在这个案例里构建他们自己的 intelligence layer（智能层）——我认为，这就是一切。对吧？没有这个，为什么还要办 developer conference（开发者大会）呢？

我完全可以来这里，让你们大家某种程度上都去膜拜某一个 model（模型）的神坛。是啊。但那就不是 developer conference（开发者大会）了。

在后台，我们——你当时有一段讨论，是关于什么是 IP，或者说一家公司的价值到底是什么。过去，这取决于人在公司里积累的人类经验长度；而现在，它变成了另一种东西，也就是 evals，以及某种把 agents（智能体）应用到公司中的经验。他——我只是想请你把这个再展开讲一点，Marcus。

对，这是一个很好的 framing（框架方式）。对吧？因为，没错，说到底，每家公司都会同时拥有两者：human capital（人力资本）依然会非常有价值，因为人类，以及人类发现始终存在的那些 gap（缺口）的能力，将会是我们所有人创造价值的方式。对。

我的意思是，所以我显然属于这样一派：即便 token capital（token 资本）不断上升，这件事的核心仍将是表达新形式的人类 agency（能动性）和 ambition（抱负）。对吧。所以假设任何一家 corporation（公司）都有很多 tokens 和很多 human capital（人力资本）。问题在于，你如何让这两者复利式地结合？所以如果你——比如在团队里，我有一批 agents（智能体）在工作，也有一批 humans（人类）在工作，而它们之间的 traces（轨迹/痕迹），就是关于这个企业如何创造价值的极其重要的上下文。

然后这又回到了：去训练的不是一个 generalist model（通才模型），而是去训练那个 company veteran agent（公司老兵智能体）。对吧？这就再次变得极其有价值了。也就是当一家公司说，我的看法是，它事实上应该被计入 balance sheet（资产负债表）。对吧？实际上，过去 human capital（人力资本）从来没法放到资产负债表上，因为你不知道该如何捕捉 tacit knowledge（隐性知识）；而现在我认为，借助那些随着时间、通过所有这些 traces（轨迹/痕迹）学习而成的 agents（智能体），你可以做到这一点。

所以至少我们认为，接下来会发生的就是这个。

我认为 SEC 可能不得不为 token 专业能力制定会计标准。

你说的是均衡状态，以及一种稳定均衡：公司拥有这种复利式累积的价值，并且能够为自己看到 terminal value（终局价值）。对这种所谓均衡的另一项挑战是：好吧，有一些 application 和 workflow（工作流）在某种 vertical（垂直领域）或 horizontal（横向职能）里是相对通用的。而这就像 SaaS 公司那一代的起点。你知道，Microsoft 也有很多 SaaS 资产。然后，还有一些东西对每家 enterprise（企业）来说都非常具体，并且正是它们形成差异化竞争的基础。

我相信你已经听过很多、也参与过很多关于“software 终结”的讨论，因为现在这些 workflow 的生成成本都很低。你觉得未来的均衡形态会不会不同——也就是 enterprise 内部构建的 agent，和它们的 vendor（供应商）所构建的 agent 之间，会不会出现不同的分工格局？

是的。所以我认为这里正在发生的事情是，你看，我们过去有一种特定的方式来在 app 里承载、或者说固化 workflow，对吧？因为我们先构建了一个 data model（数据模型），对吧？我们把某个 business process（业务流程）的一部分做了 schema 化（模式化）。然后我们又构建了一整套 business logic（业务逻辑）。

对。然后我们再在上面放上一大层 UI（用户界面）。所以这基本上就是每一家 SaaS 公司——

再加上一点 configuration（配置）。

差不多二十年来，都是这样，

没错。一直就是这样。所以很有意思的是，现在你某种程度上可以重新审视、重新辩论这种 vertical stacking（垂直堆叠）了，对吧？不过我仍然认为，比如说，每个 SaaS application 底下构建的那个 data model 依然非常有价值，对吧？比如，为什么要重复造轮子呢？

比如，总账就应该是总账。我不需要去创建新的 schema（模式）。事实上，那种 entity relationship（实体关系）其实已经是一个相当不错、很健壮、我想要拿来喂给系统的东西。

而且你会希望它是稳定的。

没错。对。business logic（业务逻辑）也是一样，对吧？如果你看看，我们有一个叫 Power BI 的产品。

对吧？它就像是到处都是人们做出来的 dashboard（仪表板）。而这个 dashboard 底层真正美妙的地方，是一个非常丰富的 semantic model（语义模型），对吧？有人费了很大功夫去创建 dashboard，并把所有 measures（度量指标）都做好了。你当然会想要那个，对吧？

那就是 business logic（业务逻辑），对吧？我希望它能够为我所用。所以我认为，SaaS 商业模式的挑战在于，我们过去是用一种方式把它打包起来的。现在我们得学会如何把这些东西拆开，再用新的方式重新打包，并发现新的商业模式，对吧？我的意思是，如果你看一看，今天 Microsoft March 正在发生的事情就是一个很好的例子。

对吧？我们有一个叫 WorkIQ 的东西。事实上，我们正在意识到，天哪，如果你仔细看，这其实还有一个历史上的对应案例，对吧？我们最先卖的是 Exchange 和 SharePoint。然后，你知道，在 Teams 之前，我们还有一个叫 Link Server 的东西，诸如此类。

我们当时以为，哦，这些都会迁移到云上去。但我们几乎没意识到，会在云里使用 server（服务器）的人数会变成 10 倍、100 倍，对吧？因为人们以前并不是在买 server，他们买的只是 subscription（订阅）。现在 M365 也正在发生同样的事情，因为通过 WorkIQ，我们把一个也许是公司里最重要的 database（数据库）暴露出来了——它以前从来没有被当作 database 来使用，因为它只被我们的 app（应用）封闭式地占用。对吧？

所有 email 都跑在它上面。Teams 跑在它上面。Word、Excel、PowerPoint、SharePoint 都跑在它上面。但现在，这就是我用 WorkIQ 能做的最酷的事情之一：我去一个 GitHub repo，然后我说，嘿，我上周参加了一堆和这个 repo 相关的设计会议。

你能把这些都梳理出来，并告诉我我应该做哪些改动吗？我的意思是，你想想看，对吧？它真的可以去查看所有那些 transcript（转录记录），然后带着一个修改你的 code base（代码库）的方案回来。对吧？以前你根本不会想到把 M365 用在这种事情上。

所以，现在在 agent 世界里的价值创造机会，实际上大了 10 倍。但这确实要求我们，比如说，围绕 M365 会出现 usage（使用量）层面的需求，对吧？这类需求甚至可能比终端用户本身还多。而且我们还必须重新做架构。实际上，我用来服务 inbox 或 mailbox 的那套东西，不能拿来服务 agent。

所以，这大概就是我们正在做的事。

我不相信这些领域里会存在什么永久不变的商业模式。但从短期来看，对于 outcomes based pricing（按结果定价）、token based pricing（按 token 定价）、enterprise bundles（企业捆绑方案）这些模式，你有没有什么判断？

对。我的看法一直是这样：我们过去一直都有——比如我们甚至就拿 per user price（按用户定价）来说。

嗯。

按用户定价，其实只是这样一种产物：有人在制定预算，而他们需要确定性。对吧？因为这才是最重要的事。比如说，有人就是想要一个预算。嗯。

他们需要的是一个 per user（按用户）的方式。而 per user 本质上只是一组关于 usage（使用量）的 entitlements（使用权益）。对吧？大概就是这么回事。所以最早的一种 bundling（捆绑）方式，会是拿一部分 usage，把它打包进 per user 组合里，然后再去卖 subscription（订阅）。

所以我认为 subscription（订阅）会一直存在，per user 也会一直存在。接下来下一个大的东西会是 consumption（按量消费）。于是人们会说，我想要按量消费。也有可能人们会说，我甚至不想为任何 subscription 或 consumption 的 outcome（结果）付费。

但要记住，大多数人喜欢 outcome（结果）——直到他们真的拥有一个 outcome。因为一旦你有了 outcome，就像是在分出去 royalty（版税）一样。对吧？我的意思是，我遇到过一些客户，他们一开始很喜欢 outcome based pricing（基于结果的定价）。我会说，我完全支持——直到他们突然觉得，哦天哪。

就像，他们会说：你在说什么？你要分享我的 outcome？不。不。不。

我希望你回到 per user pricing（按用户定价），我希望你改成 consumption pricing（按用量定价）。对吧？所以我认为，这场争论还会继续。但这些 business model（商业模式）各自都有特定的适用时间和场景，而不是有一个模式能统治一切。如果说有什么启示的话，那就是：如果你是 SaaS vendor（SaaS 供应商）或者 platform vendor（平台供应商），拥有这种灵活性很重要。

说实话，我们在 GitHub 也面临这个问题，对吧？我们最近刚刚在 GitHub 宣布了更高层级的 per user pricing。因为最初的 GitHub Copilot 是按 per user 的层面构建的，那时候我们甚至还没真正理解 agents（智能体）使用强度会有多高。它原本是一种交互式方式，让开发者使用 CodeComplete，也许再做点 task（任务）。它并不是那种“我一下启动 10,000 个 agents，让它们整天运行”的模式。

所以，这就是这次调整的核心。也就是说，今后我们真正想要的是：per user 这种方式会一直存在，但也必须配上一个 consumption meter（用量计费机制）。

你如何更广泛地看待 SaaS 的持久性？我观察到的一件事是，在很多企业内部，会有一些团队几乎进入了 agent euphoria（agent 狂热）状态。他们对自己能构建出来的东西突然暴增这件事非常兴奋，以至于正试图重建很多应用，或者去找他们的 SaaS vendor 说“我们不再和你们合作了”，又或者说“我们在考虑做一个内部项目”。但看起来，六到九个月之后，其中一些人也许会回来并说，实际上，我们没法把所有东西都重建一遍。你怎么看，在这个世界里什么是 durable（可持续、持久）的，什么不是？

我认为，我们必须完整经历一个 budget cycle（预算周期），才能真正看到那种 equilibrium（均衡）的出现。因为归根结底，哪怕只是生成一个 app（应用），也是有 marginal cost（边际成本）的。对吧？事实上，甚至可以用一个很简单的方式来表述：如果你自己构建并维护某样东西的 marginal cost 更高，那你就应该始终选择 acquire（购买）它。对吧？

这应该是一个可量化的东西，对吧？一个 quantifiable（可量化）的判断。而 maintenance（维护）这一部分很重要。对吧？你甚至得记住，嘿。

你知道，现在所有那些 AI 会发现的安全问题，你最好也得尽快修掉。当然，会有 coding agent 来帮你，但那又会消耗 token。对吧？所以这到底是谁的责任？这有点像一个你必须通盘想清楚的循环。

我觉得，我们已经经历过“我可以生成很多软件”的那种兴奋阶段了。我认为下一步会是：我到底真正想生成什么软件？我想使用别人做的什么软件？我该怎么把这两者组合成某种我自己拥有 agency（自主掌控权）的 agentic workflow（智能体式工作流）？对吧？

因为我觉得，在 vendor（供应商）层面，任何缺乏灵活性的人都会几乎不被容忍。但与此同时，我也认为，任何真正具备这种灵活性、能够出现、交付价值的人，都会一次又一次被请回来。对吧？我们本质上还是在卖软件，只是商业模式变了而已。

说到构建软件，我记得我最喜欢的一个时刻，应该是之前某次 build，大概一两年前吧，当时他们有一个很大的环节——就是你自己动手构建自己的软件。我很好奇，你现在还在做什么东西吗？

对。所以我觉得，首先，我们得面对现实。对吧？构建软件这件事，已经让像我们这样的公司里哪怕是 CEO 的无能，都还能自己动手做点东西了。所以，谢天谢地。

不过话说回来，我确实觉得，像 GitHub Copilot 这样的东西——尤其是新的 sessions app 或者那个新 app——已经让你更有可能对那些你以前觉得自己根本碰不了的 artifacts（产物）拥有 agency（自主掌控权）。对吧？所以对我这个 CEO 来说，哪怕只是走进一个 code base（代码库），能够去了解它、学习它，都已经不一样了。我记得很多年前我刚加入 Microsoft 的时候，你会觉得，天啊，每个人都得进去看，不管是 Cutler 的、Malik 的，或者其他谁的代码，才能学会怎么写出好的 c plus plus 代码。所以现在，这种让你在 full stack（全栈）上下贯通的能力变得非常好，但这并不意味着我们每个人都应该去做同样的事。问题在于，你怎样才能具备检查事物、学习事物、看清事物的能力？

我觉得这真的强太多了。所以对我来说，我现在大量在构建的是这种 long running foundry agents（长时运行的 foundry agent）。对吧？也就是 autopilots。最简单的例子是，对我来说，我想我上周甚至刚做了一个，它的想法是，嘿——

我能不能有一个 agent，持续地监控，基本上就像是我自己的 chief of staff autopilot（幕僚长自动驾驶）？对吧？他们显然会在 Scout 里有这个功能。这就是我们展示过的东西。但做起来实在是太容易、太简单了。

我把它交给了 WorkIQ。我说，用 WorkIQ。去构建一个 Foundry 的 long-running agent。把所有 memory 都用 Rayfin 存起来，对吧，基本上就是作为我后端的一个 service。结果还真就把它做出来了。

而且不只是做出来了，我还可以说发布到 Teams，它就真的把那玩意儿发布到 Teams 了。所以，像这样一个端到端的项目能够被完整做成，这种能力简直有点不可思议。

你觉得这会如何影响未来存在的不同类型的 engineering 角色？因为现在，我觉得大概有十几种不同类型的 engineer 可以做，从 QA、front end 等等。覆盖面很大。我听到有些人主张，四五年后，我们基本上会只剩下四种 engineering 角色。会有负责管理 agents 的人。

会有 forward deployed engineers，也就是 FDEs。会有 security engineers，

然后

会有为少数几个 service 构建大规模基础设施的人，除此之外，其他一切都会收缩进 agentic 世界里。

对。你

觉得这是一种对世界的正确看法吗？

对。我是说，我觉得我们得靠不断试验来摸索出路。不过你说的这一点是对的：确实有一些已经在大规模推进的做法。在 LinkedIn，他们确实做了结构性的调整，而且你知道，基本上建立起了一种新的职能，叫 full stack builder。对吧？

所以他们会说，嘿，我们把 design、product management、front end engineering 的人都拉到一起，整合成一个团队，但同时每个人也要保有自己的 edge（专长优势）。对吧？这并不是说 design 的人就没有 design 的优势了，或者 front end 的人就没有 front end 的优势了，而是你可以把自己的角色 scope（职责范围）做大，不再被局限在单一角色里。与此同时，infrastructure（基础设施）也会变得非常关键。对吧？

换句话说，我是说，像 RLE 这样的东西，我们意识到的一点是，即便是对 Excel team 来说也是如此，比如说，去构建一个能够学习 reward（奖励）的 RLE，实际上是最难的 infrastructure 问题之一。所以你其实甚至需要新的人才，对吧？哪怕是在过去被认为是 end user app team 的团队里，也需要 distributed systems 的人，因为这对应的是完全不同的 skill set（技能组合）。所以没错，infrastructure 是一方面，science 当然也是另一方面。所以我觉得我们会看到这些东西如何继续演化。对吧？

真正的情况在哪里呢？我是说，这个世界永远都会有一大批 specialists（专家型人才）。不过我觉得，generalist（通才）这个角色会是最令人兴奋的，对吧？因为 generalist 的 leverage（杠杆效应）会是我们看到最大回报的地方，对吧？当你问“嘿，你是在写代码吗？”时，我现在基本上会把它翻译成：我是在做 knowledge work（知识工作），对吧？