不是 API，而是新计算：OpenAI 与 AWS 合建的究竟是什么？
早上好，
正如我昨天提到的，今天这篇 Stratechery 访谈在时间安排上提前了——从周四改到周二——而在发布时间上又推迟了——美国东部时间下午 1 点，而不是早上 6 点——因为这一话题受到禁运限制。过去几天，这项禁运让我陷入了一种有些奇怪的处境：
- 上周五，我采访了 OpenAI CEO Sam Altman 和 AWS CEO Matt Garman，话题是由 OpenAI 提供支持的 Bedrock Managed Agents；很自然，我提出的一个问题是，这与 OpenAI 和 Microsoft 之间的合作如何契合——根据这项合作，Azure 对 OpenAI 模型拥有独家访问权。
- 周日晚些时候，我从小道消息听说 Microsoft 会在周一上午宣布一些消息；我当时还在想，会不会是一场先发制人的诉讼！
- 周一，Microsoft 和 OpenAI 宣布，双方已修订协议 ，允许 OpenAI 通过包括 AWS 在内的其他云服务提供商提供其产品。
事情如今已经明朗了。
我认为，Microsoft 与 OpenAI 的这笔交易对双方来说都很有道理。以下是 Microsoft 发布的博文中概述的新安排要点：
- Microsoft 仍将是 OpenAI 的主要云合作伙伴，OpenAI 产品将优先在 Azure 上线，除非 Microsoft 无法并选择不支持所需能力。OpenAI 如今可以通过任何云服务提供商向客户提供其全部产品。
- Microsoft 将继续拥有 OpenAI 模型和产品知识产权的许可，期限至 2032 年。Microsoft 的许可现将改为非独家。
- Microsoft 将不再向 OpenAI 支付收入分成。
- OpenAI 向 Microsoft 支付的收入分成将持续至 2030 年，不受 OpenAI 技术进展影响，分成比例保持不变，但设有总额上限。
- Microsoft 作为主要股东，继续直接参与 OpenAI 的发展。
我认为最重要的一点是最后一条。Azure 此前凭借作为唯一能够提供 OpenAI 模型的超大规模云服务商，拥有了实实在在的竞争优势，但这也对 OpenAI 形成了掣肘，尤其是在越来越明显地看到，许多企业首先最关心的是能否在自己当前选择的云平台上获得这些模型之后； 我一段时间以来一直指出，这对 Anthropic 而言是真正的竞争优势 。换句话说，Azure 的排他性实际上正在损害 Microsoft 对 OpenAI 的投资，而鉴于 Anthropic 今年的快速增长，Microsoft 需要照看好这笔投资，即便这会削弱 Azure 的差异化优势。
与此同时，OpenAI 显然将 AWS 视为一个巨大的机会——以至于未来几年他们愿意放弃与 Azure 相关的收入（根据前一点，这也会让 Azure 管理层对失去独家合作权感觉好一些；因为不用再向 OpenAI 支付收入分成，他们的损益表看起来会好看得多）。OpenAI 也在将 Microsoft 从 AGI 条款中解除出来 ；如今，两家公司之间的协议无论如何都将持续到 2032 年。
可以明确看出，OpenAI 的重心将放在 AWS 上，而最有力的证据正是此次采访的主题：由 OpenAI 提供支持的 Bedrock Managed Agents。理解这项产品最简单的方式，就是把它看作 AWS 中的 Codex；Codex 之所以能够发挥作用，很大程度上在于它是本地化的，这使你能够“免费”获得大量复杂能力，尤其是在安全方面。而要弄清楚如何让代理在整个组织范围内运作，则完全是另一回事；这项产品的目标，就是让那些大部分数据已经位于 AWS 中的组织，更容易接入这类工作流。
为此，在这次采访中，我们讨论了 AWS 如何开创了整个云计算这一类别、它对初创企业产生了怎样的影响，以及 AI 与此前那次范式转变有哪些相似与不同之处。随后，我们谈到了 Bedrock Managed Agents，它是什么，以及它与 Amazon 现有的 AgentCore 产品有何区别。我们还谈到了 Trainium，以及为什么芯片对大多数 AI 用户而言并不重要，也谈到了相较于 Google 专注于全栈整合，合作为何更具合理性。
提醒一下，所有 Stratechery 内容，包括采访，都可作为播客收听；点击这封电子邮件顶部的链接，即可将 Stratechery 添加到你的播客播放器中。
进入采访：
OpenAI 首席执行官 Sam Altman 与 AWS 首席执行官 Matt Garman 谈 Bedrock Managed Agents
本次采访经轻微编辑，以便表述更清晰。
话题：
AWS 与初创公司 | Bedrock Managed Agents | 本地与云端 | AgentCore 与 Managed Agents | Trainium | 客户需求 | 构建 AI 技术栈
AWS 与初创公司
Matt Garman 和 Sam Altman——Matt，欢迎来到 Stratechery——Sam，也欢迎你再次做客［我此前曾在 2025 年 10 月 、2025 年 3 月和 2023 年 2 月采访过 Altman］。
Sam Altman： 谢谢。
Matt Garman： 谢谢，感谢邀请我来。
Matt，这是你第一次做客 Stratechery。可惜的是，我想 Sam 的到场会让我们没法进行惯常的“先来认识一下你”环节。再说了，他也不想听我们一起回忆在 Kellogg Business School 的时光，不过能在播客里迎来一位校友，还是很高兴的。
MG： 是的，很高兴来到这里。下次我会再来，我们可以做一次更深入的探讨。
那太好了。你从实习生时期就在 AWS 工作，如今在这波 AI 浪潮中掌管整个组织。恕我找不到更好的说法，在打造 AI 业务这件事上，哪些方面与当年打造最初的大宗计算业务相同，哪些方面又确实不同？
MG： 我认为，相同之处在于，我看到了同样的兴奋，也看到了那些构建者如今能够做到他们过去根本无法做到的事情。其中很酷的一点是，在我们刚开始做 AWS 的时候，开发者突然能够接触到过去只有那些拥有数百万美元、可以自建数据中心的大公司才能使用的基础设施。只要一张信用卡和几美元，他们就能快速搭建应用，这真的极大拓展了在互联网世界中进行构建的人们所能实现的可能性。我们当时秉持的理念是，人们可以构建任何他们想要的东西，而我们不会预设他们应该做什么；只要把强大的工具摆在他们面前，世界各地的人们就会凭借创造力，打造出有趣而令人惊叹的事物。
我认为，这对于赋能开发者所做之事而言，至少同样具有变革性，甚至可能更具变革性。展望未来的可能性，你不必先上学校、花上10年时间学习编程，才能去构建一个应用程序；你也不需要拥有数百人的庞大团队，以及一个又一个月的漫长时间，才能把东西做出来。你可以用小团队进行构建，可以快速构建，并且迅速迭代，而人工智能正在释放遍及世界各个领域的各种创新。我认为，从很多方面来看，这非常相似；看到它正在为广大的顾客群体带来这样的能力，确实令人无比兴奋。
不过，确实有那么一段时间，当 AWS 出现时， 你们是唯一一家 ，因此你可以自然而然地享受所有好处，也承担所有代价。是否也有这样一种感受：在 AWS 时代，很多事情都围绕着通用算力展开，强调其可替代性、弹性和低成本——而在 AI 领域，尤其是训练方面，最终胜出的抽象层似乎更多是这些高度垂直整合的超级集群、极其先进的网络，以及软件与硬件之间极为紧密的联结。对你来说，这是否算是一种意外？因为你现在切入这个领域时，情况已经不是当年那种“我们是这里唯一的玩家，我们对大规模算力有自己的一套看法”，而且至少在 AI 发展的头几年，这套看法或许并没有完全契合现实？
MG： 我不确定这对我们来说是否有什么不同。不过，我认为真正不同的，是采用规模扩张的惊人速度，而我觉得这大概让所有人都感到意外。Sam，如果你不同意，也可以补充，但我认为，用户采纳的速度，以及人们如此迅速地抓住这些能力并加以应用，确实让所有人都感到惊讶。
情况不一样。我们刚开始做云计算时，花了很长时间去解释，为什么一家卖书的公司会为你提供算力；为了说明什么是云计算，我们做了大量解释工作。很多人已经忘了当年的艰辛，但在2006年，这并不是一个不言自明的事实——全球计算会就这样迁移到云上，因此我们确实为此付出了很多努力。
不过你觉得现在是否也需要做一些解释？因为很多人的思维还停留在训练时代，而你们在说：“我们考虑的是推理时代 。”这将会是完全不同的东西，也许你们还是得重新启动那套解释能力？
MG： 确实如此，但关键在于，人们理解你所说内容的速度完全不同。所以我认为，是的，当人们从“这看起来确实挺酷，而且我还能和这个智能聊天机器人对话，真不错”，转变到“它实际上可以在你的企业中完成工作”时，确实需要一个逐步教育市场的过程，但从技术演进的速度来看，这一过程也相对很快。
我保证，我们很快就会谈到今天的主角——这款产品。但 Sam， 从创业生态系统的角度回看，AWS 显然具有变革性 ，它彻底改变了门槛所在的位置，现在任何人都可以开始创业。你有种子轮融资，有天使投资人，门槛被进一步后移了——你不再需要只靠一份 PPT 去争取服务器资源，你可以先构建一个应用，然后再去融 A 轮，或者其他任何轮次。那么，从你的角度看，与 AWS 当年所促成的变化相比，今天这个时代有哪些不同，又有哪些相同？
SA： 我认为，推动初创公司实现大规模发展的平台赋能时刻，曾有四个最重要的节点：互联网、云、移动端，以及人工智能。对我来说，我算是真正以成人身份经历的第一个阶段是云计算；而在 YC [Combinator] 早期，很难夸大这一变化对初创公司的意义。此前，这些初创公司还得租用主机托管空间 ，自己组装服务器，再把各种设备部署进去，整个过程极其复杂，而且还必须筹集大量资金。然后突然之间，虽然云计算其实是在 YC 成立后不久才出现的，我想应该是第二年。
我正想问这个——归根结底，它们实际上是不是比你当时意识到的更加密不可分、并肩而行？
SA： 当时它们就已经显得密不可分。你知道，感觉 YC 从一开始就在乘着云计算这股浪潮前行，因为在 AWS 出现之前也有一些早期的先例。
如果有 AWS 的存在，创业公司要把项目启动起来，就不需要像以前那样投入那么多资金。
SA： 这是一个巨大的赋能性变化，也是为什么 YC 在当时听起来如此疯狂的一部分原因。人们会说：“嗯，你不可能只靠几万美元就资助一家初创公司，这根本不可能，光服务器成本就比这还高。” 所以，这彻底改变了创业公司凭借少量资本所能做到的事情。
通常情况下，当出现重大的平台转移时，初创企业往往会胜出，因为它们能够以比以往更快的周期和更少的资本去做成事情，这是初创企业击败大公司的经典方式。我的职业生涯刚开始时，我亲眼见证了这种情况在云计算领域发生。如今，看着各家公司围绕人工智能开展建设，这种趋势在方向上确实颇为相似；但正如 Matt 所说，这一切发展的速度快得惊人。
现有巨头、大公司在采用这种方式上的速度，是否比当年采用云计算时快得多？
SA： 这种情况肯定更多了，但我指的也包括初创公司营收增长的速度——我最近在 YC 做了分享，临结束时我问了一个问题：“一家优秀的公司在 YC 结束时，营收预期应该是多少？”他们回答说：“这个数字几乎每个月都在变化，也许在这一期开始时和结束时，我们的答案都会不一样。”这种情况以前从未出现过。人们能够在这个新平台上以如此之快的速度构建起具备规模的业务，这是我此前从未见过的。
Matt，在那个时代，你们几乎是所有初创公司的首选云服务商，这本身就是一个巨大的优势。那放到今天，是什么让你们依然成为首选云服务商？是因为你会想到有很多人在基于 OpenAI API 进行构建，还是说你们的想法其实是：“实际上，我们是从一个非常不同的视角进入这个市场的——我们拥有庞大的既有客户基础，他们正迫切要求我们提供 AI 相关能力；而对于 Sam 所说的这一整批创业公司，我们的可见度反而没那么高。”
MG： 我认为有几件事。其一是，我们对这项合作关系感到非常振奋，我认为这将对大量初创企业产生非常重要的意义。但即便是今天，如果你去和初创企业交流，绝大多数处于扩张阶段的初创公司如今仍然是在 AWS 上实现扩张，这背后有很多原因。规模在那里，可用性在那里，安全性在那里，可靠性在那里，其他独立软件供应商构成的那类合作伙伴生态也在 AWS 上，客户也在 AWS 上。
（笑）不管愿不愿意，大家都用过 AWS 控制台，所以对此都已经很熟悉了。
MG： 而且我们会帮助他们。我们投入了大量时间来扶持初创企业，无论是提供额度支持，但不只是额度支持，还包括就如何搭建系统、如何思考市场进入策略等提供建议。诸如此类的很多事情，我认为都受到了众多初创企业的高度认可。我们投入了大量时间和精力来确保这一点，因为我们确实认为，初创企业是 AWS 的生命线。从一开始就是如此，就像 Sam 刚才谈到的那样，而且直到今天依然如此。我现在仍然每季度都会去一次硅谷或其他地方，直接与初创企业会面，了解他们在做什么，以确保我们所构建的东西真正符合他们的需求。因此，如今围绕初创企业关注度的竞争，确实比 20 年前更加激烈；但这对我们来说，重要性丝毫未减，我们也投入了大量时间，以确保我们能够满足这些初创企业的需求。
是否可以公平地说，相较于直接使用 Azure 版本 OpenAI API 的人，那些直接基于 OpenAI API 进行开发的人，更有可能在常规计算方面采用 AWS，而在人工智能方面使用 OpenAI？
MG： 我认为，这确实是如今很多初创公司都非常常见的一种模式。
Bedrock 托管代理
那么这就引出了今天的发布内容：由 OpenAI 提供支持的 Bedrock 托管代理，我想我说得没错。据我理解，其核心卖点并不只是 OpenAI 模型可在 AWS 上使用——我想这可能并不被允许——而是 OpenAI 的前沿模型被封装进一个原生于 AWS 的代理运行时之中，涵盖身份、权限状态、日志记录、治理和部署。Sam，这样表述准确吗？
SA： 对，这样说相当不错。
谢谢。这是什么？现在请用英语解释一下。
SA： 我认为，AI 的下一阶段将从你向一个智能体提供一些文本并获得更多文本返回，或者甚至你提供一大堆代码并获得更多代码返回，转变为这些智能体将在公司内部运行，承担各种不同类型的工作。
“虚拟同事”算是我听过的描述里相对没那么糟糕的一种说法，但还没有人真正找到准确的语言来定义它。而我们正在共同打包一款新产品，帮助那些希望构建这类有状态智能体并将其投入使用的公司。再次强调，我认为我们还不完全知道世界将如何谈论它们、使用它们，但如果你看看 [with Codex] 正在发生的事情，我认为这很好地展示了我们可以看到这一切将走向何方。
胸背带 ——也就是围绕模型的运行时、工具、状态，以及正如你所指出的、对你来说非常重要的一个词——记忆、权限、评估——对于让智能体真正发挥作用，有多重要？
SA： 其重要性再怎么强调都不为过。我现在已不再把工具框架和模型看作是完全可以分开的两样东西。就我使用这些产品的体验而言，我很清楚地意识到，有时当我在 Codex 里发出一个指令，它为我完成了一件令人惊叹的事时，我并不总是知道这到底该归功于多少——
是模型本身足够出色，还是工具框架足够出色？
SA： 对，正是如此。
工具框架在多大程度上是与模型协同开发的？这种整合发生在哪里？是在后训练阶段吗？是在提示词层面吗？究竟是什么让这种整合发挥作用？
SA： 两者都有。这其实并不真正属于预训练过程的一部分，但我想说，你可以从中看到——这里还有一个更有意思的现象，那就是我们过去已经多次见过这样的例子：那些我们原以为彼此可以清晰分离的东西，会越来越多地被整合在一起。比如我们最初对工具调用的理解，如今它已成为我们使用这些模型的关键组成部分，但一开始我们并没有认真考虑将其深度整合进训练流程，而随着时间推移，我们在这方面做得越来越多。
我也怀疑，随着时间推移，模型和支撑系统会越来越融合；就此而言，我也预计，预训练和后训练最终也会随着时间推移而更加趋于一体。虽然这么说听起来很老套，但我还是要这么说，因为我认为这确实非常、非常真实——我们在这一切的范式演进中还处于极其早期的阶段，这仍然有点像这个行业真正成熟之前的 Homebrew Computer Club 时代。
这就是为什么我觉得这件事如此有趣， 我几周前写过这个问题 ：在任何价值链中，最终都会出现一个整合点，真正重要的是，这两个部分必须结合在一起，才能发挥作用。而随着时间推移，显然大量价值也会在这里汇聚——我的观点是，这种“harness”与模型的整合就是那个关键点。这符合你们的利益，不过听起来你也同意这一点。
SA： 这确实符合我的利益，我也同意，但我还想更广泛地说，你真正关心的是，你在 Codex 里输入你希望发生的事情，然后它就会实现。
你并不在意实现细节。
SA： 我不认为是这样。在我们摸索这一切的过程中，已经有太多例子表明，我们曾不得不在系统提示层面做某些事情，而后来则不再需要。这里一个总体观察是，随着模型变得越来越聪明，你就有更大的灵活性让它们按照你希望的方式行事。这听起来像是句显而易见的话，但事实确实如此——
告诉一个10岁的孩子该做什么，比告诉一个5岁的孩子要容易。
SA： 回想起在 GPT-3 时代，为了从这些模型中榨出哪怕一丁点实用价值，我们必须付出多少努力，而如今这些都已不再需要——因为模型当然已经能够开箱即用地理解并很好地完成任务——这种趋势或许还会继续大幅推进。
MG： 我想补充一点——我完全同意这一点。我认为，当你与那些对这些系统究竟要完成什么有着清晰设想的客户交流时，就会发现，在我们此次共同推进的这类联合合作出现之前，客户某种程度上一直被迫自行把这些拼接整合起来，对吧？他们希望这些模型和智能体能够记住彼此协作良好，希望将其集成到现有系统中，而且不仅仅是第三方工具，也包括他们自己的工具。他们希望这些系统了解自己的数据、自己的应用程序以及自己的运营环境，而如今，至少到目前为止，所有这类集成工作基本上都只能由每一位客户独自完成。
因此，我们双方正在推进的这一联合合作的一部分，就是共同构建一种全新的产品形态，把这些能力真正更紧密地整合在一起，让客户能够更轻松地完成他们想做的事情。在这一产品中，身份能力本身就已经内建其中，访问并认证其数据库的过程也都发生在他们的 AWS VPC [Virtual Private Cloud] 内部。如果我们这边是 OpenAI API、那边是 AWS，理论上其中很多事情同样也可以做到；但通过双方共同打造这一方案，我们让客户能够更容易、更快速地实现价值，并在其企业环境内部完成他们希望完成的任务。
所以你的意思是，你可以在一个通用胸背带中构建一个可用的智能体，只是难度要高得多？你们是在把这件事变得更容易？还是说，实际上如果不把它们整合在一起，甚至会有一些事情根本无法做到？
SA： 回到你之前那个类比，在 AWS 出现之前，如果你愿意走进机房、买上一堆服务器、自己想办法把它们连接起来，再雇一名网络工程师，你当然也能做成很多事情。可突然之间，只要登录 AWS 控制台，点一下“我需要一个新的 S3 实例”之类的按钮，你就能完成更多事情，因为启动门槛、也就是把基础工作搭起来所需要付出的成本，已经大幅降低了。所以今天，借助这些模型，你已经可以做很多事。
不过，每次我看别人使用我们的模型，或者尝试搭建 Matt 刚才提到的这类系统时，我心里总是很矛盾：一方面，我很高兴他们对此印象深刻，觉得这是一项神奇的技术；但另一方面，看到他们为了让任何东西真正跑起来所经历的种种痛苦和折磨，我又恨不得抓狂。而这不仅仅发生在构建这些产品的开发者身上——即便是使用 ChatGPT，看着人们把内容从这里复制粘贴到那里，再试着组织一套复杂的提示词，我也知道，这一切终将消失，而我对此非常兴奋。只是现在仍然太早了，也还太糟糕。
只求你们别取消与 BBEdit 的集成 ，这可是 ChatGPT 应用里我最喜欢、排名第一的功能。
SA： 好。
（笑）谢谢。
SA：A）这类事情实在太难做了，我们认为，如果能把它变得容易得多，就会为开发者和企业带来大得多的价值；但 B）还有很多事情你根本无法稳定可靠地让它运行起来。我认为，通过我们的共同合作，这不仅会是一个关于易用性的故事，也不仅是不必再自己去构建 colo 之类的东西；我们还将共同探索并打造许多新东西，让人们能够构建出一些产品和服务，而这些即便付出大量痛苦和代价，也依然做不到。
本地与云端
我其实还想回到关于有哪些东西需要构建这一点。但先很快回到 Codex——Codex 是一个胸背带和模型，它在本地运行。为什么现在让智能体在本地运行更容易实现？
SA： 其实，我们一开始就是让它在云端运行的，而且我认为最终你还是会希望它在云端运行。
当然。我是在梳理过渡到这项云端产品的过程。但你们为什么又回到了本地？
SA： 你的整个环境都在那里，你的电脑已经配置好，你的数据也在那里，你不用再去操心——这样开始工作就是更容易，尽管这还不是最终形态。但我认为，迈向这样一个世界显然会很棒：智能体能够在云端运行，而当你——如果你有一项非常密集的任务，或者你需要合上电脑之类的时候，你就可以把事情交给云端继续处理。不过，就我们在短期内能够明显实现的易用性而言，最终还是让它使用你的本地环境更占优势。
我有一种看法：这有点像你从旧式的安全模型转向新式安全模型。旧式模型就像“城堡加护城河”那一套，而现在你正在转向一种零信任的新安全模型，要求一切都具备适当的权限结构、身份验证，以及诸如此类的各个环节。对我来说，理解本地运行的一种方式是：这就像是你自己搭建的“城堡加护城河”，所有东西都在里面，我只是假定一切都没问题，而且做起来很简单。而我现在在想的一点是，Matt，你看看你是否也有同感——如果想让所有这些组件真正能在生产环境中运行，根本不可能把这一切都放在本地，你从一开始就必须在这样的环境中运作。这样理解对吗？
MG： 我不知道是否存在任何一种计算环境能够完全摆脱客户端；本地运行始终有其优势。你大多数 iPhone 应用之所以也都有本地组件，无论是出于连接性、延迟、本地算力，还是访问文件和应用程序的需要，都是有原因的。正如 Sam 所说，本地客户端确实有其独特之处——它简单，运行效果很好，但同时也受到约束，存在其局限性。
你无法把本地笔记本电脑横向扩展；你手头有什么就只能用什么。而一旦开始进入企业合同场景，两个人之间共享就会变得更困难一些——无论是考虑权限，还是考虑安全边界，都会更复杂。所以这里面有很多环节，在我看来，我不会说拥有本地环境是不好的，它只是不同而已。我认为最终你还是会希望在这两者之间搭起一座桥梁。
这正是我的问题，因为在云时代，你有容器来帮助本地环境和生产环境趋于一致；但在这个场景下，如果你必须处理智能体，正如你所说，假设它像一个虚拟同事之类的存在，如果它们有自己的身份、有自己的权限，以及诸如此类的各种设置，那么似乎就连构建它们，你也需要处在与最终部署时相匹配的正确环境中。至少我是这么理解的。
SA： 我认为这里还有太多问题需要厘清。举一个例子，如果你是一家公司的员工，当你使用某项服务时，你是希望只有一个账户，然后你的智能体直接使用你的账户，还是说你的智能体应该使用一个不同的账户，这样服务器才能分辨两者？
或者，如果你想要很多智能体呢？
SA： 没错。我怀疑，我们真正想要的其实是某种我们现在还没有想清楚的东西。也许情况会是，当 Ben 的智能体以 Ben 的身份登录时，它使用的是 Ben 的账户，但会标明自己是一个智能体，而不是真正的 Ben。我们甚至还没有一个基础概念来思考这件事，但我们可能很快就需要把它弄明白。我的感觉是，类似这样的情况还会有 50 种——随着智能体加入劳动力队伍，并以越来越高的自主性和任务复杂度开展行动，我们关于软件如何运作、关于一家企业内部乃至更广泛互联网环境中访问控制和权限机制如何运作的许多思维模型，都将不得不演进。
Matt，从安全、访问策略等角度来看，你是如何思考智能体相关问题的？
MG： 是的，我确实认为，随着你将更多这类工作负载迁移到云端，作为一个中央化组织，你就能对其中一些安全环节拥有更多控制。而且我确实认为，我们一直在与客户交流时发现，这正是他们担心的问题，也就是：“我很看好这些极其强大的模型和智能体所能带来的前景，但我该如何确保自己不会因为操作失误而引发一场足以葬送公司的事件？” 这种担忧确实存在。
我认为我们可以在这方面提供帮助，因为这些都是可以解决的问题，确实如此。而且我认为，让一些客户建立起这样的信心——“它运行在这个 VPC 内部”——至少这样你就能够控制这个边界，并清楚它可以访问什么；或者它通过这个网关运行，你可以为它授予权限，就像你在其余环境中为它分配角色一样。过去 20 年里，我们围绕这些机制构建了极其丰富的能力，因此，不只是 Y Combinator 的初创公司，全球性银行、医疗机构、世界各地的企业以及政府机构都能够使用 AWS。而在此基础上建立起来的整套安全架构，我认为能够帮助我们进一步加快他们利用这项技术的步伐，并在具备这些防护措施的情况下实现快速推进。
我认为很多时候，当你身处一家企业，尤其是那些处于风险厌恶环境中的公司时，拥有这样的安全护栏——他们会说，“如果它是在这个沙箱里运行，我就愿意加速推进”——实际上能够帮助我们的许多客户开始将这些技术应用到更广泛得多的场景中。
AgentCore 与 Managed Agents 对比
你刚才谈到的这些能力，很多都是你们在过去 20 年里打造出来、如今正试图为智能体落地部署的，而这些能力目前已经通过 AgentCore 对外提供。那么，由 OpenAI 提供模型支持的 Bedrock Managed Agents 与 Bedrock AgentCore 之间是什么关系？
MG： 我们共同打造的很多东西，都是基于 AgentCore 的基础构件来完成的，目的是把其中一些组件整合在一起。
所以，这相当于是一个构建在其之上的超级集合？
MG：AWS 团队和 OpenAI 团队将 AgentCore 组件、OpenAI 模型以及一系列相关模块结合起来，共同联合开发了这款产品。
AgentCore 可以说是我们提供的一组基础构件。也就是说，在 AWS 上，如果你想去构建自己的智能体工作流，就可以这么做。你可以拥有记忆组件，可以拥有安全的执行环境，也可以拥有权限管理能力；你可以对所有这些进行配置。如今，我们已经有客户在生产环境中运行这些能力，并且正在做一些非常酷的事情。
但 OpenAI 不会如此。
MG： 但和 OpenAI 还不是这样，他们现在必须使用不同的模型，这一点没错。其实，这也不对，我们确实有人在用 OpenAI 来做这件事。
哦，就是调用另一个云上的服务之类的。
MG： 他们只是直接调用 OpenAI 模型。所以实际上，今天我们绝对已经有客户在结合 OpenAI 来做这件事，不是在 Bedrock 内部原生完成，但他们仍然在使用它。这是一个开放的生态系统，你可以调动不同的能力来构建任何你想要的东西，我的判断是，人们今后仍会继续这样做。外面有很多开发者，就像 Sam 打的那个比方一样，至今仍然喜欢在家里自己组装电脑，尽管你其实没这个必要；同样，人们也喜欢自己动手构建，我们认为，在很长一段时间里，人们仍会自己构建自己的智能体，但其中绝大多数人会希望有一种更简单的方式来做到这一点，他们不想自己去配置所有这些组件，而这正是我们此次合作推出的部分内容。
只是为了说得非常清楚一些，你提到这种通过 Bedrock Managed Agents 提供的托管体验，用户也可以使用 AgentCore 并调用某个模型，无论这个模型是在 AWS 上还是在其他地方。还有，Sam，我想确认一下，这个问题是问你的：这与比如说 OpenAI 在 Azure 上的情况不同，后者只是让你直接访问 API；而这与 Amazon 上的这项托管服务是有区别的。这样理解对吗？
SA： 对，没错。
而且你对此感觉非常好，认为这在各项条款上的界定都是恰当的，未来也不会成为问题？
SA： 是的，我认为情况会随着时间推移而演变，但我觉得把这作为一个起点非常好。
这会是 AWS 的独家服务吗？还是说你们预计也会在其他云平台上推出这种托管代理服务？
SA： 是的，我们正与 Amazon 独家合作开展这项业务，我们对此感到非常兴奋。
这种“独家”在多大程度上意味着，“看，我们用了 Amazon 的所有 API，当然只能部署在 Amazon 上”，还是说这其实是关于整体托管体验的理念，不只是“我们在使用 Amazon 的 API”，而是“目前这项服务将部署在 Amazon 上”？
SA： 从理念上说，我们希望把这件事做成两家公司之间的联合合作。
明白了。公关稿里确实提到了这一点，这也回到了你刚才提到的那个点，Matt，也就是你可以调用其他 API，然后自己把这一切整合起来。在这种情况下，客户数据会留在 AWS 内部，那么 OpenAI 究竟能看到什么，这又意味着什么？
MG： 没错。也就是说，整个系统基本都会留在你的 VPC 内，因此数据会在 Bedrock 环境中受到保护。
明白了。这将通过 Bedrock 在 OpenAI 模型上运行，这些模型会运行在 Trainium 上吗？
MG： 会采用不同基础设施的组合——其中一部分会运行在 Trainium 上，另一部分会运行在 GPU 上。
这只是时间点的问题吗？因为我认为，作为你们几个月前发布公告的一部分——
MG： 我觉得一部分是时间因素，另一部分则是能力方面的考量。我们会把构建系统的不同组件结合起来，为其中不同部分采用最合适的基础设施。不过，随着时间推移，越来越多的部分将会运行在 Trainium 上。
SA： 我们非常期待让这些模型在 Trainium 上运行。
Trainium
马特，最后问一个简短的问题，一个关于 Trainium 的总体性问题。对于 Trainium，这样理解是否合适——我现在就是这么想的，所以想确认自己理解无误。Trainium 这个名字起得很不幸，因为未来它实际上更多将是围绕推理展开的——其最主要的体现形式会是通过像 Bedrock 这样的托管服务，顾客甚至未必知道自己使用的是什么算力，这样理解公平吗？
MG： 第一，我对 AWS 所有服务中糟糕的命名负有责任。
听着，我有一个名叫 Stratechery、靠口碑传播的网站，所以我完全理解糟糕命名这回事。
SA： 我觉得 Trainium 这个词很酷。
MG： 这的确是个很酷的词。
这确实是个很酷的词，只是它听起来像是一款推理芯片，而不是训练芯片。
MG： 确实如此。不过，是的，撇开名称不谈，它对于训练和推理都很有用。你看，这是一款让我们极为兴奋的芯片，无论是当前这一代，还是后续持续推进的产品，我们都认为这将成为一项巨大的业务，也将真正赋能我们共同推进的许多事情。
顺便说一句，我认为就像 GPU 一样，你将会通过抽象层与很多这类加速芯片交互。因此，绝大多数客户其实也不会直接与 GPU 打交道，除了可能在笔记本电脑之类的设备上用于图形处理时会接触到一些。但当你与 OpenAI 交互时，即便其底层运行在 GPU 之上，你也不是在和 GPU 对话；如果你在使用 Claude，无论它是通过 GPU、Trainium 还是 TPU 运行，你也不是在和这些芯片中的任何一种对话，你面对的是接口。而目前绝大多数推理，都是在少数几种模型之一上完成的。
所以，无论是 5 个人、10 个人、20 个人还是 100 个人，都不是数以百万计的人在直接为这些东西编程；而且未来也会如此，因为这些系统太复杂了，规模也非常庞大。如果你要去训练一个模型，并没有那么多人有足够的资金去训练模型，也没有那么多人具备真正管理它的专业能力。这些系统非常复杂，而 OpenAI 团队在从超大规模计算集群中榨取价值方面的能力令人惊叹。但无论用的芯片究竟是什么，真正拥有这样一支团队、能够做到这一点的人并不多。所以坦率地说，我认为这对所有加速器芯片都会是一样的。
SA： Ben，我越来越觉得，作为一家公司，我们必须做的事情就是成为一家“代币工厂”。但顾客真正关心的是，我们能否以最低的价格，提供最优的智能单位，并且按他们需要的规模和容量，尽可能多地交付。
你认为我们应该继续沿用目前这种定价方式吗——也就是基于代币定价？从长远来看，这合理吗？
SA： 不是。事实上， 我们刚刚发布的模型就有一个有趣的例子，5.5 的单 token 成本比 5.4 高得多，但要得到同样的答案，它所需的 token 数量却大幅减少。实际上，你并不在乎答案用了多少 token，你只想把这项工作完成，而且你希望为此获得合适的价格和足够的容量。
所以，也许我说“token 工厂”并不准确，但我们更像是一家智能工厂之类的存在。我们只是希望以最低的价格获得尽可能多的智能单位。至于是更大的模型运行更少的 token，还是更小的模型运行更多的 token，使用的是 GPU、Trainium，还是其他什么，又或者我们是否以创造性的方式在这方面做出各种其他安排，我认为客户并不关心。
事实上，他们并不会真正与这些层面打交道。当你把某项任务放进 Codex，或者你在 SRE[ 有状态运行环境 ]中构建一种新型智能体时，你根本不应该去考虑这些；你只会惊讶于，花这么少的成本，竟然能得到这么多。
代币使用量减少，这是模型的作用，还是框架的作用？
SA： 这主要是模型的作用，也有一小部分是框架的作用。
明白了。顺便问一下，Matt，我刚才已经向 Sam 提了那个独家问题，你预计未来也会为其他模型提供类似的托管服务吗？
MG： 我们目前专注于与 OpenAI 推进这项合作。我们对双方正在共同开展的工作感到非常兴奋，而来日方长。
时机成熟还需要很长时间，这个问题我就先让你自己体会吧。没关系，我总得问这个问题。
客户需求
我确实有一个关于客户的问题想问。Sam，顺着你刚才的观点，也想请你们两位都谈谈看法——我很好奇，当客户真正投入生产环境时，OpenAI 的责任边界在哪里结束，AWS 的责任又从哪里开始？在我看来，如果所有数据都在 AWS 上并且始终留在那里，而他们又是在更高层面上运行，那么这最终就是 AWS 的责任？从客户的角度看，我这样理解对吗？
MG： 对，我认为你的理解是对的。当你需要联系谁时，你会联系 AWS 支持团队来获得帮助；它是你 AWS 环境的一部分，你们是一起构建它的，你的 AWS 客户代表也会在这方面为你提供帮助。在构建过程中，我们也会请 OpenAI 的同事加入，帮助你弄清楚如何最好地利用这项能力，诸如此类。在某些情况下，如果我们遇到某个需要他们协助处理的漏洞或问题，我们会升级转交给他们，但 AWS 会是你首先接触到的一线支持团队。
Sam，相较于你们核心的 API 业务，你如何看待这项业务的规模？
SA： 我希望它会非常庞大，我们正在为此投入大量精力，也承诺采购大量算力。我相信，这里将会产生大量收入来支撑这项业务。近来我越来越认同这样一个框架：当价格低到一定程度时，人们对智能的需求本质上是没有上限的。
所以从这个角度看，它的弹性非常大吗？价格下降，需求就会上升？
SA： 当然有这方面的因素，但话说回来，你可以降低水的价格，也许人们会多喝一点水，也许会从一天洗一次澡变成一天洗两次澡，需求的确存在一定弹性，但到某个时候，你会觉得：“你知道吗，我的水已经够用了。”
此外，如果有需要，无论价格多高，你也会买水。
SA： 其他公用事业也是如此——如果电更便宜，你当然会用得更多。但如果把智能看作一种公用事业，我所知道的没有哪种公用事业会让我觉得：“我就是想要更多，只要价格够低，我就会一直多用，一直多用。”
MG： 我想说，实际上很有意思的是，这在算力领域很大程度上也一直成立。如果你想想今天一个计算周期的成本和 30 年前相比，我甚至都不知道便宜了多少个数量级，而如今售出的算力也比以往任何时候都更多。
没错。人们其实并不会太去想算力成本，至少在规模高到足以构成实质性支出之前不会；但总体而言，从战略层面看，大家基本默认你就是会拥有算力。AI 要走到哪一步，才能让它不再是决策中的首要问题——“我在这上面要花多少钱？”
SA： 我不认为这才是首要考虑。眼下，向我们提出这样要求的客户远多于和我们争论价格的客户：“不管价格是多少，你们能不能给我更多？我就是需要更多容量，我愿意额外付钱。”
但我确实认为，我们会继续以近乎疯狂的幅度把价格降下来。现在也许我们降得越多，想要流入的财富规模反而会越来越大、越来越大、越来越大。但我有信心，我们将继续能够相当大幅度地降低当今这一智能水平的成本——有一件事多少让我有些惊讶，那就是总市场需求中有多大一部分集中在绝对前沿。我也不知道这种情况是否会持续下去，但至少在今天，情况确实如此。
对，这方面有很多疑问。提供最前沿版本的服务成本非常高，人们其实也可以直接使用前一个版本，但你的意思是，不管怎样，人们就是想用最前沿的版本？
SA： 到目前为止，确实如此。
MG： 我认为，这清楚地表明我们离自己想要达到的目标还差得很远，而且市场需求远比现在所见的更大。40 年前，如果你回头看计算需求，电脑曾经贵得惊人；而如今，它的算力早已被人们手机中的性能远远超越，而这类设备的销量还多出了数十亿台。我确实认为，AI 世界也会发生同样的事情：今天，大家都在追逐最前沿的模型，因为只有这样才能完成大量真正有用的工作，而所有人也都对现有能力感到无比兴奋。
我认为，随着时间推移，模型将会呈现出一种混合格局。顺便说一句，到那时，一些较小的模型将能够完成甚至连 OpenAI 最新模型目前都还做不到的事情，而且它们会变得更小、更便宜、也更快；与此同时，也会有那些超级庞大的模型，去尝试攻克癌症等重大问题。但我认为，我们仍然只处在可能性的早期阶段；而当你在这样一个早期阶段就看到如此强劲的需求和如此迅猛的增长时，这确实让人对未来充满期待。
这里是否也有一点玩世不恭的看法：Sam，你那边有一大批客户会说，“我们很想用 OpenAI 的模型，但我们的所有东西都在 AWS 上，我们不会迁移”；而 Matt，你这边则会说，“你看，我们所有东西都在 AWS 上，你们能不能把 OpenAI 模型带过来？”这次合作只是满足了这一需求——而且事实证明，由于 AWS 规模最大，这种需求的体量也大得惊人。这是否只是最简单的答案？还是说，这其中还有另一层考量：你们确实认为自己能够提供某种高度差异化的东西，也会因此为彼此吸引到新客户？
SA： 我们显然非常高兴能够接触到 AWS 的客户，而且有那么多人都喜爱 AWS。没错，这确实是事实。
MG： 这一部分绝对是真的。
（笑）
MG： 反过来也是一样，我们的客户也非常期待能够获得 OpenAI 技术的使用权限。
SA： 但我确实认为，我们可以共同构建出某种令人惊叹且全新的东西。我希望，一年后当人们回顾这件事时，大家谈论的最重要的事情不会是“哦，终于可以通过 AWS 访问这些模型了”之类的话题，而是会说：“哇，我们当初没有意识到这款新产品竟然如此重要。”我认为，在模型、调度机制和能力层面，我们已经接近一种完全全新的计算形态，而那将与人们现有的思维方式截然不同，不再只是想着“我需要一个访问这个模型的 API”之类的事情。
MG： 我完全同意，正是如此。第一部分很棒，也很好，而第二部分则是我认为真正让我们所有人都无比兴奋的地方。
构建 AI 技术栈
说到这一点，我之前提过我想回到这个话题，不过我有一个理论，未必一定正确，我很好奇你们对此怎么看，也就是关于还有哪些东西有待构建。具体来说，最终可能会出现这样一个真正的中间件或中间层：在一个组织内部，存在各种不同的数据库、SaaS 应用，以及横跨不同系统的各类零散数据；其上方则是代理层，或者说带有胸背带的这一层，我想是这样；而中间似乎还有一些东西值得去构建，OpenAI Frontier 在某种程度上也触及了这一点。这是其中的一部分吗？还是说这是另一个有待构建的东西？或者是我完全搞错了方向，其实我们根本不需要这个？
SA： 你说得完全对，我们确实需要这样的东西。最近我一直在和客户交流，比如大型企业，他们会说：“我想要某种智能体运行环境，我想要一个管理层，让我能够把我的数据连接到智能体上，同时确保我了解自己在 token 上的支出情况，并对此进行某种监督；我还想要某种工作空间”——希望会是 Codex——“为我的员工提供类似这样的东西。” 人们所要求的这一整套方案，正在变得惊人地一致，但现在确实还需要投入工作去构建完整的产品供给。
这感觉像是几乎需要一个双重智能体层。一个是用于维护中间层的智能体层，它会持续深入挖掘所有这些数据源；另一个则是真正的用户界面层，也就是人们实际进行交互的地方。这种理解符合我们的发展方向吗，还是说有些偏离重点？
SA： 关于这两点，我同意，这确实描绘了当今世界的样貌。随着模型变得越来越聪明，我认为我们并不确切知道未来的架构会是什么样子。
眼下，在某种可以称为用户代理层的层面，人们确实希望与多个代理交互，而我们会让你能够为这个和那个构建代理，让它们彼此沟通，以及处理其他各种事务；到了公司管理层，人们又会设置各种控制机制，来决定你如何帮助 AI 深入探索文件系统中的文件。
而到了某个时刻，你会意识到，自己只是在毫无理由地抓着过去不放，这些东西本就应该直接在模型里。
SA： 这正是我想说的。到了某个阶段，你可能会说：“实际上，我们已经拥有如此惊人的能力，那就把整个体系重新架构吧。”
MG： 是的，我同意。而且我认为其中确实有些不同之处，我们现在或许还不完全清楚那到底是什么，但这也是其魅力的一部分：你会看到客户去使用、去构建，然后你可以从他们身上学习，弄清楚怎样才能让这一切对他们来说更容易、更快、更好。
Sam，这是我们第二次做这种产品发布采访， 上一次是和 Kevin Scott 谈 New Bing——当时你对自己给 Google 带来的威胁相当有信心，你觉得结果如何？
SA： 我认为我们的表现比我预期的更好。ChatGPT 我想是自 Facebook 以来，第一个真正大规模的新消费者产品。
所以这真的是你的答案吗——你们的表现比预期更好，但这种成果主要体现在 ChatGPT 上，而不是其他领域？
SA： 不，我认为我们在 API 方面也做得相当不错，尤其是在 Codex 上，但那并不是我当时在想的事情。当时我在想，也许这类新型语言界面将改变人们在互联网 上查找信息的方式。你知道，Google 也是一家绝对了不起的公司，我认为在很多方面，单就其业务的广度和深度而言，Google 依然被低估了，但我对 ChatGPT 的相对表现感到满意。
Matt，我其实也想以类似的方式问你一个关于 Google 的问题。Google 这周刚刚在台上，Thomas Kurian 谈到了他们完全集成的技术栈，从模型到芯片再到智能体层，一路向上向下，诸如此类。你今天是和另一家公司的高管一起坐在这里，从定义上说，这并不是 Amazon 内部的完全集成；但会不会有这样一种情况：此前大家都批评你们没有前沿尖端模型——而现在我们进入了这种推理阶段，你们又一直很擅长服务大量企业。某种程度上，正因为保持中立，你们反而处在了更有利的位置？这是有意为之，还是说你们无意间走到了一个极佳的位置，而当时并没有意识到会如此？
MG： 某种程度上是有意为之。自 AWS 创立以来，我们始终把合作伙伴视为支持最终客户的关键组成部分。从一开始，与合作伙伴深度合作就是我们战略中极其重要的一环。也许和一些其他公司不同，我们认为，只要合作伙伴取得成功，在我们的平台上构建业务，或者与我们共同构建，那么如果他们成功了，我们也就成功了，这非常棒。
我们认为，这意味着共同把蛋糕做大，那就是双赢，而其他人未必是这样看待这个世界的。有时候，他们会说：“我必须拥有一切”，这也没关系，这也是一种看法。但我认为，这种选择很重要，也正因为如此，最好的产品才能胜出。顺便说一句，在这样的世界里，你可以有第一方产品，也可以有很多第三方产品，但我们的看法是，我们希望客户能够选择最适合他们的东西。如果最适合的是你们自己打造的产品，那也很棒。
对我们来说，如果最好的东西是我们的合作伙伴打造的，但它建立在我们的基础之上，我们也将其视为一种胜利，因为这才是对客户最好的结果。我们长期以来一直这么认为，而事实上，这也正是我们在 AI 领域打造 Bedrock 平台的方式。我们希望支持广泛的模型，也希望支持广泛的能力；这一点确实如此，而且从数据库、计算平台到其他类似领域，一直都是如此。
所以我认为，这一直是一项有意为之的战略。我也认为，这是一项客户所欣赏的战略，因为他们喜欢这样的做法，而我们也很高兴继续在这方面加大投入。
是的，这很有意思。软件、平台和基础设施之间需要取得平衡，而且每个人都说自己会服务所有人。但回过头看 AWS 刚起步的时候，感觉就像是先从 I（基础设施）开始，而这几乎——在我看来，这给了你最大的灵活性，能够在中间与 Sam 对接。Sam 拥有非常出色的 S（软件），而你们正在一起构建一个 P（平台），我想大概可以这么说。
MG： 没错。你会说，“我们只有一个 S3”，没有别的 S3 产品，这一点确实如此。所以正如你所说，其中一些核心组件位于基础设施层，我们确实会相当重度地依赖我们自己构建的东西。但随着你往这个技术栈的上层走，我认为能力的范围会更广；如果你这样看待这个世界——我不认为在任何情况下会有一家公司拥有所有应用程序。随着你在技术栈中继续向下，当你来到模型和服务层时，这类参与者会更少；再往下到基础设施层，参与者就更少了。我们的看法是，拥抱这一整套合作伙伴关系，对我们和最终客户来说都是好事。
Sam，还有什么最后想说的吗？
SA： 我觉得这番话说得非常到位。我确实认为，如今开发者能够构建的新一代产品有着巨大潜力。鉴于我们预计未来一年模型能力将会以很陡峭的曲线持续提升，我们将在此时共同踏上这段旅程，并努力真正打造一个使这一切成为可能的平台，时机正好，我想人们会非常喜欢它。
非常好。Matt、Sam，感谢你们来到 Stratechery。
MG： 太好了。感谢邀请我们。
SA： 谢谢。
