亚马逊AWS CEO与OpenAI CEO首次深度对话：揭示双方合作逻辑

编者按：日前，亚马逊AWS CEO Matt Garman与OpenAI CEO Sam Altman共同参与了Stratechery访谈，就双方合作逻辑进行了深度剖析，双方还探讨了AI变革对创业生态的深远影响，以及当前的AI浪潮与以往的范式转移有何异同。


AWS与初创企业

主持人： Matt 和 Sam，欢迎来到 Stratechery。Matt，欢迎你，这是你第一次来；Sam，欢迎回归（我曾在 2025 年 10 月、2025 年 3 月和 2023 年 2 月采访过 Altman）。

Sam Altman：谢谢。

Matt Garman：谢谢，感谢邀请。

主持人：Matt，由于 Sam 在场，我想我们得跳过通常的“相互了解”环节了。况且，他肯定不想听我们叙旧在凯洛格商学院（Kellogg Business School）的时光。不过，很高兴播客里能有一位校友。

MG：是的，很高兴来到这里。我下次再单独来一次，我们可以聊得更深。

主持人：那太好了。你从实习生时期就在 AWS 工作，现在在这个 AI 浪潮中掌管整个组织。在你看来，构建 AI 业务的哪些方面与构建最初的（姑且称之为）大宗计算业务（Commodity Compute）是相同的，哪些方面又是截然不同的？

MG：我认为相同点在于，我看到了同样的开发者热情——建设者们能够做到以前从未敢想的事情。AWS 刚起步时，最酷的一点是开发者突然能用上以前只有拥有数百万美元、能自建数据中心的大公司才能拥有的基础设施。只需一张信用卡和几美元，他们就能启动应用。这彻底引爆了互联网建设的可能性。我们当时秉持的理念是：人们可以构建任何他们想要的东西，我们不会预设他们应该做什么。如果我们能把强大的工具放在他们面前，全世界的创造力就会迸发出惊人的成果。

我认为现在的 AI 变革对建设者的赋能程度不仅相似，甚至更具颠覆性。想象一下，你不再需要寒窗苦读十年编程才能开发应用，也不再需要数百人的大型团队和数月的时间。小团队就能快速构建、快速迭代。AI 正在解锁世界各个角落的创新。从客户群体的反馈来看，这种兴奋感与当年如出一辙。

主持人：不过，AWS 刚出现时，你们是唯一的玩家，所以你们几乎免费获得了所有的红利。在 AWS 时代，很多关于大宗计算的讨论是关于同质化、弹性、廉价；但在 AI 时代，特别是在训练阶段，获胜的抽象层似乎更倾向于垂直集成的超级集群、极先进的网络，以及软硬件之间的紧密耦合。这对你来说算是一个意外吗？毕竟你们现在介入的方式，不再是“这里只有我们，我们有一套独特的大规模计算方案”，而且至少在 AI 的前几年，这与你们原本的模式似乎并不完美契合？

MG：我不觉得这对我们来说有什么不同。但真正不同的是，这种采纳规模和速度极其惊人，我想这可能超出了所有人的预期。Sam，如果你有不同意见可以补充，但我认为人们拥抱这些能力的速度确实让每个人都感到惊讶。
回顾云计算刚起步时，我们需要花很长时间去解释为什么一家“卖书的”公司要提供计算能力，那需要大量的口舌。人们忘了那段艰苦的时期，但在 2006 年，全球计算会向云端迁移并不是一个理所当然的结论。

主持人：你觉得现在还需要做类似的解释工作吗？因为很多人还停留在“训练时代”，而你可能会说“我们正在考虑推理时代”，这是一种不同的逻辑，也许你仍需要发挥这种解释力？

MG：确实需要，但不同点在于，人们理解你的速度完全不一样。过去人们可能会说“这看起来挺酷，有个能聊天的智能助手真有意思”，而现在转向“我能真正在你的企业里干活”，这虽然也需要一个教育过程，但在技术演进的尺度上，这个过程已经非常快了。

主持人：我们很快就会聊到今天的主角产品，我保证。但 Sam，从初创企业生态系统的角度看，回顾过去，AWS 无疑是革命性的，它彻底改变了门槛，现在任何人都可以起步。有了种子轮和天使轮，门槛后移了——你不需要拿着 PPT 去买服务器，你可以先做出 App，然后再去融 A 轮。在你看来，那时的赋能与当今的世界相比，有哪些异同？

SA：我认为有四个大规模赋能初创企业的平台级时刻：互联网、云、移动端，然后是 AI。作为成年人经历的第一个时刻是云。在 YC（Y Combinator）早期，云对初创企业的改变大到难以言表。在此之前，初创企业需要租用机房（Colocation）、组装服务器、布线，那是一件极其复杂的事情，你不得不为此融一大笔钱。然后云突然出现了，大概就在 YC 成立后的那一年。

主持人：我正想问——归根结底，它们之间的紧密程度是不是比你当时意识到的还要高？

SA：当时感觉它们就是并行的。感觉 YC 从一开始就踩在了云的浪潮上。

主持人：如果 AWS 存在，你就不需要投入那么多钱就能让初创项目跑起来，这和以前完全不同。

SA：这是一个巨大的赋能，也是为什么 YC 当时听起来那么疯狂的原因之一。人们会说：“你们不可能靠几万美元就资助一家公司，那不可能，服务器成本都不止这些。”所以，这彻底改变了小额资本能做的事情。

当大的平台转型发生时，初创企业通常会赢，因为你可以用更快的周期和更少的资本去做事，这是初创企业击败大公司的经典路径。在我的职业生涯早期，我亲眼目睹了云时代的这一幕；现在观察 AI 领域，方向性上非常相似，但正如 Matt 所说，它的速度简直疯狂。

主持人：是不是大公司、现有的巨头们，采纳 AI 的速度比当年采纳云的速度要快得多？

SA：确实有这个趋势。但我也指初创企业收入增长的速度。我最近在 YC 演讲，最后问他们：“现在 YC 结项时，一家优秀公司的收入预期是多少？”他们说：“这几乎每个月都在变，批次开始和结束时的答案可能都不一样。”这在以前从未发生过。人们在这个新平台上构建规模化业务的速度，是我从未见过的。

主持人：Matt，AWS 曾是几乎所有初创企业的首选云平台，那是整个时代的巨大优势。今天，是什么让你们成为首选？因为很多人是直接在 OpenAI 的 API 上构建的，你会觉得“其实我们是从一个完全不同的角度切入，我们有庞大的存量客户在乞求 AI 功能”，还是说你们对 Sam 提到的那一批初创企业关注较少？

MG：我觉得有几点。首先，我们对这次合作非常兴奋，我认为它对很多初创企业意义重大。但即便在今天，如果你去和初创企业聊，绝大多数规模化的初创企业依然在 AWS 上运行。原因有很多：规模、可用性、安全性、可靠性，还有其他独立软件开发商构成的合作伙伴生态系统都在 AWS 上。

主持人：每个人不论愿不愿意都用过 AWS 的控制台，所以大家都习惯了。

MG：而且我们会帮助他们。我们投入大量时间赋能初创企业，不仅是提供抵扣额度，还包括如何架构系统、如何思考进入市场（Go-to-market）的建议。初创企业非常看重这些。我们一直认为初创企业是 AWS 的生命线。从 Sam 说的那个时代起就是如此，今天依然如此。我每季度仍会去硅谷等地直接见创业者，听听他们在做什么，确保我们构建的东西能真正落地。虽然现在的竞争比 20 年前更激烈，但对我们来说，争取初创企业的关注一如既往地重要。

主持人：那么可以这样理解吗：那些直接在 OpenAI API 上构建（而不是 Azure 版本）的人，更倾向于把常规计算放在 AWS，而把 AI 放在 OpenAI？

MG：这是目前很多初创企业非常普遍的模式，绝对没错。


Bedrock托管智能体（Managed Agents）

主持人：这引出了今天的公告：由 OpenAI 提供支持的 Bedrock 托管智能体。我的理解是，它的卖点不仅仅是“OpenAI 模型在 AWS 上可用”——我认为那是（协议）不允许的——而是 OpenAI 的尖端模型被封装在了一个 AWS 原生的智能体运行环境（Runtime）中，包含了身份认证、权限状态、日志记录、治理和部署。Sam，这样表述准确吗？

SA：是的，说得很到位。

主持人：谢谢。那这到底是什么？请用通俗的语言解释一下。

SA：我认为 AI 的下一阶段是从“你提供文本，智能体回传文本（或代码）”进化到“让智能体在公司内部运行，处理各种不同的任务”。

“虚拟同事”是我听过最不差的描述方式了，但目前还没人能准确定义它。我们正在共同封装一款新产品，旨在帮助那些想要构建此类有状态（Stateful）智能体并将其部署到企业环境的公司。同样，我们现在还不知道世界会如何称呼或使用它们，但如果你看看 Codex 的表现，就能预见到未来的走向。

主持人：模型周围的“外壳”（Harness）、运行环境、工具、状态（State，你提到的一个关键词）、内存、权限、评估，对于让智能体真正跑起来有多重要？

SA：其重要性怎么强调都不为过。我不再认为“外壳”和模型是完全可以分离的东西。在我的使用体验中，当我让 Codex 去完成一件惊艳的事情时，我并不知道该归功于谁。

主持人：模型很棒，还是外壳很棒？

SA：没错。

主持人：这种“外壳”在多大程度上是与模型协同开发的？这种集成发生在什么时候？是在后训练阶段，还是在提示词（Prompt）阶段？

SA：两者皆有。它不是预训练的一部分，但有趣的是，过去我们多次看到，原本被认为是可以分离的东西，正被越来越深地嵌入其中。比如我们最初对工具调用（Tool-calling）的看法，它现在是模型使用的核心，但最初我们并没想过要把它深度集成到训练过程中，而随着时间的推移，我们做得越来越多。

我猜想，模型和外壳会随时间推移而更加融合，预训练和后期训练也会如此。虽然说“我们还处于早期阶段”很老生常谈，但我仍要说，现在的行业成熟度就像当年电脑爱好者俱乐部（Homebrew Computer Club）的简陋时期。

主持人：这就是为什么我觉得这很有趣。我在几周前写过，在任何价值链中，最终都会出现一个“集成点”。我的论点是，这种“外壳与模型”的集成就是关键点。这符合你们的利益，听起来你也同意。

SA：我确实同意。但更广泛地说，你真正在乎的是你在 Codex 里输入想要的结果，然后它就实现了。

主持人：你并不在乎实现细节。

SA：我想大家都不在乎。当我们还在摸索时，有很多事必须在系统提示词（System Prompt）层面解决，但后来就不需要了。一般的观察是：随着模型变得越来越聪明，你引导它们按你预期行事的灵活性就越高。

主持人：告诉一个 10 岁的孩子该做什么，比告诉一个 5 岁的孩子要容易。

SA：回想起 GPT-3 时代，为了榨出一点点效用，我们费了多大的劲；而现在，模型出厂就能理解并做得很好。这个趋势还会走得更远。

MG：我想补充一点——我完全同意。当客户确切知道他们想要系统做什么时，在这次联合协作之前，他们不得不自己去把这些碎片拼凑起来。他们希望模型和智能体能协同工作，希望集成到现有系统中，不仅是第三方工具，还有他们自己的工具。他们希望智能体学习自己的数据、应用和操作环境。目前，这种集成工作几乎落在了每个客户自己的头上。

所以，这次联合协作的一部分就是共同构建一种新产品，将这些东西紧密结合在一起。这样客户就能更轻松地实现目标：身份认证已经内置，连接数据库的操作都在你的 AWS VPC（虚拟私有云）内完成。如果 OpenAI API 在这边，AWS 在那边，你要实现这些虽然也有可能，但通过共同构建，我们让客户能更快地在企业环境中获得价值。

主持人：所以你的意思是，虽然可以用通用的外壳构建功能性智能体，但那太难了，你们是在降低难度？还是说，如果不把两者绑在一起，有些事情根本做不到？

SA：回到刚才的比喻，在 AWS 出现前，如果你愿意买服务器、雇网络工程师、钻进机房，你也能做成很多事。但一旦你登录 AWS 控制台点击一下，由于“启动门槛”和基础工作的难度大幅降低，你能做成的事情就会多得多。现在的模型也一样。

每当我看到有人费劲地设置环境时，我既为他们对这项魔法技术的折服感到高兴，又为他们为了让它跑通而经历的痛苦感到揪心。这不仅是开发者的问题，普通用户用 ChatGPT 时，看他们在那儿复制粘贴、写复杂的提示词——我知道这些痛苦都会消失，我对此感到很兴奋。现在还处于非常早期、非常简陋的阶段。

主持人：只要别取消和 BBEdit 的集成（我最喜欢的 ChatGPT App 功能），我就没意见。

SA：好吧。（笑）

SA：A）现在的操作太难了，如果我们能让它变容易，对开发者和企业价值巨大；B）有很多事情你现在根本无法可靠地完成。通过我们的联合协作，这不仅是一个易用性的故事，我们还会共同摸索出很多新东西，让人们能构建出以前即便费尽周折也无法实现的各种产品和服务。


本地 vs 云端

主持人：我想回到关于“构建什么”的那一点。但先快速聊聊 Codex——Codex 包含外壳和模型，且在本地运行。为什么现在本地运行智能体反而更容易？

SA：事实上，我们起初是让它在云端运行的，我认为最终你还是希望它在云端。

主持人：当然。但我现在是在看转向云端托管的过程。当时为什么要转回本地？

SA：因为你的整套环境都在本地，电脑设置好了，数据在那儿，你不需要去考虑太多——短期内它更容易跑通，尽管这不是终态。但最终智能体肯定会在云端运行，当你需要处理高强度任务，或者需要关掉电脑时，你可以把它移交给云端处理，这显然会很棒。但在短期内，使用本地环境在易用性上胜出了。

主持人：我有一种理解方式：旧式的安全模型是“护城河加城堡”，而新模型是“零信任”，所有东西都有相应的权限结构和认证。在本地运行就像是自己给自己搞了个“城堡护城河”，默认里面的东西都是安全的。Matt，你觉得这样理解对吗？要在生产环境中让这些组件运作，你甚至不能让它们全部在本地，必须从一开始就运行在这个环境里？

MG：我不认为有任何计算环境能彻底摆脱客户端。本地操作总是有好处的，比如连接性、延迟，或者直接访问本地文件。正如 Sam 所说，它简单、好用。但它也有局限性，它无法扩展。

你无法扩展你的笔记本电脑；而且一旦进入企业合同，两人之间的协作、权限管理、安全边界都会变得困难。所以，本地环境不是坏事，只是不一样。最终你会希望在这两者之间架起一座桥梁。

主持人：这就是我的问题。在云时代，容器帮助缩小了本地和生产环境的差距。但在智能体时代，如果它是一个“虚拟同事”，有自己的身份和权限，那么为了构建它，你必须从一开始就处在它将要部署的那个环境里。

SA：这里面有太多需要摸索的东西。举个例子：如果你是公司员工，当你使用某项服务时，是应该让智能体直接用你的账号，还是给它一个独立账号以便服务器区分？

主持人：如果你想要很多个智能体呢？

SA：没错。我怀疑我们真正需要的东西还没被发明出来。也许当 Ben 的智能体以 Ben 的名义登录时，它使用 Ben 的账号，但会标注这是一个智能体。我们现在甚至没有这种基本概念（Primitive），但我们很快就需要搞清楚。随着智能体加入劳动力市场，其自主性和任务复杂度不断增加，我们现有的关于软件运行、访问控制和权限管理的思维模型都必须进化。

主持人：Matt，你如何看待智能体的安全和访问策略？

MG：这正是将这些工作负载移入云端的价值所在——作为一个中心化组织，你可以对安全组件有更多控制。客户最担心的是：“我喜欢这些强大模型和智能体的潜力，但我该如何确保不会因为操作失误导致公司倒闭？”

我认为我们可以提供帮助，因为这些问题是可解的。让客户有信心，比如“它在 VPC 内运行”，你至少能控制边界并知道它有权访问什么。你可以给它分配权限，就像给环境中的其他角色分配权限一样。这些是我们在过去 20 年里建立起来的丰富能力。有了这套安全结构，我们可以帮助客户更快地利用这项技术，并拥有“跑得快”的安全护栏。


AgentCore与托管智能体

主持人：你提到的这些开发了 20 年的能力，目前很多是通过 AgentCore开放的。那么，“由OpenAI 驱动的 Bedrock 托管智能体”与 “Bedrock AgentCore” 之间是什么关系？

MG：我们共同构建的产品很多是基于 AgentCore 的基础组件，从而将这些部分整合在一起。

主持人：所以是在其之上的一套“超融合”？

MG：AWS 团队和 OpenAI 团队共同使用了 AgentCore 的组件、OpenAI 模型以及其他部分来打造这款产品。

AgentCore 是我们的一套原语（Primitives），就像 AWS 的其他服务一样，如果你想构建自己的智能体工作流，你可以用它。它有内存组件、安全执行环境、权限管理能力，你可以自己配置。

主持人：但（AgentCore）之前不能用 OpenAI。

MG：确实，以前原生不支持。不过事实上，我们已经看到有人在通过这种方式使用 OpenAI 了。

主持人：只是调用另一个云端的 API 或者是别的什么。

MG：他们直接调用 OpenAI 模型。虽然不是原生在 Bedrock 内部，但他们依然在使用。这是一个开放的生态系统，你可以拉取不同的能力。我打赌人们会继续这样做。就像 Sam 的比喻，总有人喜欢在家里自己组装电脑，即便并不一定要这么做。长期来看，很多人会继续构建自己的智能体，但绝大多数人会想要一种更简单的方式，不想自己去配置每一个碎片。这就是我们这次合作推出的产品的初衷。

主持人：确认一下：这种托管体验是 Bedrock 托管智能体提供的，但你也可以用 AgentCore 去调用任何模型。Sam，这对你来说是个关键点：这不同于 OpenAI 在 Azure 上的模式（那里你可以直接访问 API），这在亚马逊上是一个托管服务。对吗？

SA：没错。我觉得目前的界定非常清晰，未来也不会有问题。

主持人：这会是 AWS 的独家服务吗？你预计会在其他云平台上提供这种托管智能体服务吗？

SA：我们只和亚马逊合作这个，我们对此很兴奋。

主持人：这种“独家”是因为使用了亚马逊的 API 导致天然绑定，还是说“托管体验”这个整体概念目前只会在亚马逊上？

SA：从精神层面来说，我们希望将其作为两家公司之间的共同努力。

主持人：明白。Matt，你之前提到客户数据留在 AWS 内部，那 OpenAI 到底能看到什么？这具体意味着什么？

MG：整个流程都留在你的 VPC 内，数据在 Bedrock 环境中受到保护。

主持人：明白。它运行在 OpenAI 模型上，那么底层硬件是 Trainium 吗？

MG：会是混合的——一部分在 Trainium 上，一部分在 GPU 上。

主持人：这只是时间问题吗？因为我记得几个月前的公告里提到过。

MG：有时间因素，也有能力因素。我们会混合使用不同的组件来构建系统。但随着时间推移，Trainium 的占比会越来越高。

SA：我们非常期待让这些模型在 Trainium 上运行。


Trainium 芯片

主持人：关于 Trainium，Matt，我有一个通用问题。我现在的理解是：Trainium 这个名字起得有点不巧，因为它未来更多会关乎“推理”（Inference）。它最主要的体现形式会是通过像 Bedrock 这样的托管服务，客户甚至不需要知道他们在用什么算力。这样理解对吗？

MG：首先，我为 AWS 所有服务中起得不好的名字负责。

主持人：没事，我给自己网站起名叫“Stratechery”，我对起错名字深表同情。

SA：我觉得 Trainium 听起来挺酷的。

MG：撇开名字不谈，它对训练和推理都很有用。我们对这款芯片感到非常兴奋，无论是当前一代还是未来的版本。

主持人：但感觉它更像推理芯片，而不是训练芯片。

MG：它是。但其实你会通过“抽象层”来接触这些加速芯片。绝大多数客户并不直接与 GPU 打交道，除非是在笔记本电脑里跑图形任务。当你和 OpenAI 交流时，即使他们在 GPU 上运行，你也不是在和 GPU 说话。你和 Claude 交流，底层可能是 GPU、Trainium 或 TPU，但你面对的是接口。

绝大多数的推理任务都会集中在少数几个模型上。所以无论是 5 个、10 个还是 100 个模型，并不会有数百万人直接针对底层芯片编程。因为系统太复杂了。如果你想训练模型，没有多少人有足够的资金或专业知识去管理它。OpenAI 团队之所以强大，是因为他们能从大型计算集群中压榨出价值。

SA：Ben，我越来越觉得我们公司的职责就是做一个“Token 工厂”。但客户关心的是我们能否以最低的价格提供最好的“智能单元”，而且容量管够。

主持人：你觉得我们要一直坚持按 Token 计费吗？长远看这合理吗？

SA：不合理。事实上，我们刚推出的 5.5 模型就是一个有趣的例子。它的单 Token 成本比 5.4 高得多，但完成同样任务所需的 Token 数量却少得多。用户其实不在乎消耗了多少 Token，他们只想要任务完成。

所以也许我说“Token 工厂”不对，我们更像是“智能工厂”。我们只想提供尽可能多的智能单元。无论是一个运行更少 Token 的大模型，还是一个运行大量 Token 的小模型，无论是 GPU 还是 Trainium，客户并不在乎。

主持人：Token 消耗的减少是因为模型还是外壳？

SA：主要是模型，有一点点外壳的因素。

主持人：明白。Matt，顺便问一下，你会为其他模型提供类似的托管服务吗？

MG：我们现在的重心是和 OpenAI 的合作。时间还长着呢（The fullness of time is a long time）。


客户需求

主持人：关于客户，我想问：当人们真正投入生产环境时，OpenAI 的责任到哪里结束，AWS 的责任又从哪里开始？听起来，如果数据都在 AWS 上，那么最终的（客服）责任方是 AWS？

MG：是的。你会给 AWS 支持团队打电话，它是你 AWS 环境的一部分。我们会引入 OpenAI 的同事来协助解决如何优化利用模型等问题。如果遇到需要他们帮忙的 Bug，我们会向上报送，但 AWS 是你交互的第一线。

主持人：Sam，你觉得这块业务相对于你们核心 API 业务的规模如何？

SA：我希望它能变得非常巨大。我们投入了大量精力，承诺购买大量计算资源。我相信会有巨大的收入来支撑这一点。我一直以来的观点是：只要价格足够低，对“智能”的需求基本上是无上限的。

主持人：所以它在这个意义上是极具弹性的？价格下降，需求就会暴涨？

SA：确实如此。如果你降低水的价格，你可能会多喝一点，或者一天洗两次澡，这里有弹性，但到某个点你会说“我喝够了”。

主持人：但如果没有水，无论多贵你都会买。

SA：像电这样的公用事业，如果电更便宜，你肯定会用得更多。但如果你把“智能”看作一种公用事业，它是唯一一种让我觉得“只要价格够低，我会无限用下去”的东西。

MG：事实上，这在计算能力上已经得到了印证。如果你想想现在的计算周期成本比 30 年前便宜了多少个数量级，而现在的计算销量比以往任何时候都多。

主持人：人们确实不太考虑计算成本，除非到了极高的规模。那么，AI 什么时候能达到这种“不再是第一考量因素”的境界？

SA：我觉得现在它已经不是第一考量因素了。比起争论价格，现在有更多的客户在问：“不管多少钱，能不能给我更多算力？我需要更多容量，我愿意加钱。”

但我相信我们会继续疯狂地降低价格。今天的智能水平，其成本将大幅下降。让我有些惊讶的一点是，至少在今天，几乎整个市场的需求都集中在“绝对的最前沿”（Absolute Frontier）。

主持人：确实。提供前沿模型的服务非常昂贵，大家明明可以用前一代的。你是说人们无论如何都想用最新最强的。

SA：目前看来是这样。

MG：这也是一个信号，说明我们还没达到预期的终点，需求依然巨大。就像 40 年前，电脑贵得离谱，但现在每个人手机里的算力都远超当年。我认为 AI 世界也会发生同样的事情。

虽然大家现在都在追逐前沿模型以完成有用的工作，但随着时间推移，你会看到模型组合：有些小模型能做大模型做不了的特定任务，而且更便宜、更快；而超级大模型则去尝试攻克癌症之类的难题。我们仍处于“可能性的早期阶段”。

主持人：有一个略显刻薄的观点：Sam，你有很多客户想用 OpenAI 但不想离开 AWS；Matt，你有很多客户在 AWS 但想用 OpenAI。这种合作只是为了满足这个现成的需求——而由于 AWS 规模巨大，这个需求是天文数字。这是最简单的答案吗？还是说，你们认为能提供某种高度差异化的东西，从而吸引新客户？

SA：我们当然很高兴能接触到 AWS 的客户。

MG：这一点绝对是事实。反之亦然，我们的客户非常渴望获得 OpenAI 的技术。

SA：但我确实认为我们可以共同构建一些令人惊叹的新东西。我希望一年后人们回顾时，最重要的谈资不是“终于可以在 AWS 上用这些模型了”，而是“哇，我们之前没意识到这个新产品竟然如此重要”。我们正处于模型、外壳和能力的交汇点，即将开启一种全新的计算方式。


构建AI技术栈

主持人：关于“待构建的新东西”，我有一个理论：组织内部有很多不同的数据库、SaaS 应用和零散数据，在这些数据之上，可能需要一个真实的“中间层”或“中间件”，而智能体层/外壳就坐落在它上面。这是你们计划的一部分吗？

SA：你完全正确。当我最近和大型企业客户聊天时，他们会说：“我想要一套智能体运行环境，一个管理层，能把我的数据连接到智能体，同时能让我看清 Token 花在哪儿了，我还需要一个给员工使用的空间（可能是 Codex）。” 这种需求包正变得非常一致。

主持人：感觉需要一个“双重智能体层”：一个智能体层负责维护中间层，不断在数据源中挖掘；另一个则是用户界面层。这符合你们的愿景吗？

SA：在现阶段，我同意这是目前世界的样貌。但当模型变得真正聪明时，我不确定未来的架构是否还会长这样。现在人们希望与多个智能体交互，我们让你能为这个、那个任务构建智能体并让它们对话。但在公司管理层面，人们有很多控制项来帮助 AI 在文件系统中“探险”。

主持人：也许到某个点你会发现，我们只是在为了保留过去而保留，这些东西应该直接进模型？

SA：这正是我想说的。到那时候，你可能会说：“既然我们有这么强的能力，不如重构整个架构。”

MG：我同意。这其中会有一些不同的东西，我们现在不一定全知道，但这正是美妙之处——让客户去使用、去构建，我们从中学习，然后让它变得更容易、更快、更好。

主持人：Sam，这是我们第二次做产品发布访谈了，上次是和微软的Kevin Scott谈新Bing。你当时对 Google 构成的威胁挺有信心的，你觉得结果如何？

SA：我觉得我们做得比我预期的还要好。我认为 ChatGPT 是自 Facebook 以来第一个真正大规模的新型消费级产品。

主持人：所以答案是做得比预期好，但主要体现在 ChatGPT 上，而不是其他领域？

SA：不，我们在 API 方面，特别是 Codex，也做得很好。当时我可能觉得这些新型语言接口会改变人们在互联网上获取信息的方式。Google 依然是一家非凡的公司，他们在深度和广度上仍被低估。但我对 ChatGPT 目前的表现很满意。

主持人：Matt，我想问你一个类似的问题。Google 本周刚开完会，Thomas Kurian 谈到了他们全集成的技术栈（从模型到芯片到智能体层）。你作为 AWS 的高管，在定义上并没有像 Google 那样完全集成，但在推理时代，你们习惯于服务众多公司。你们这种“中立”的立场，是否反而让你们处于一个更好的位置？这是有意为之，还是“美丽的意外”？

MG：有意为之。从 AWS 成立起，我们就一直将合作伙伴视为支持终端客户的关键。我们的策略一直是倚重合作伙伴。与某些人不同，我们的成功观是：如果合作伙伴在我们的平台上或是与我们共同构建并取得了成功，那就是我们的成功。

这叫共同做大蛋糕，这就是双赢。但这不一定是别人的看法，有些人觉得“我必须拥有一切”。那也行，是一种观点。但我认为“选择权”很重要，这样最好的产品才能获胜。

对我们来说，如果合作伙伴构建了最好的东西且跑在我们的平台上，我们视为胜利，因为这对客户最好。这一直是我们构建 Bedrock 平台的初衷：支持广泛的模型和能力。从数据库到计算平台，我们都是这么做的。

主持人：挺有意思。软件、平台、基础设施之间存在平衡。AWS 从 I（基础设施）起步，这给了你们极大的灵活性，让你们能和 Sam 在中间相遇。Sam 有很棒的 S（软件），你们正在共同构建 P（平台）。

MG：没错。越往技术栈上方走，能力就越多样化。我们认为没有哪一家公司能包揽所有应用。越往下走（模型和服务层、基础设施层），玩家越少。拥抱所有的合作伙伴对我们的终端客户来说是件好事。

主持人：Sam，还有什么总结陈词吗？

SA：刚才说得很好。我真的认为新一代的开发者产品潜力无限。鉴于我们对明年模型能力进步斜率的预期，在这个时间点合作构建这个赋能平台，时机恰到好处。我想人们会喜欢的。

主持人：非常好。Matt，Sam，感谢来到 Stratechery。

MG：太棒了，谢谢邀请。