68岁亚马逊CTO：别让恐惧，替企业做AI决策

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 68岁亚马逊CTO：别让恐惧，替企业做AI决策 十三 2026-10-16 15:01:31 来源： 量子位 金磊 发自 深圳 量子位 | 公众号 QbitAI 恐惧是一种非常糟糕的决策方式。 当企业担心错过AI转型窗口，亚马逊CTO Werner Vogels 提醒，越是着急，越需要先想清楚：企业究竟要解决什么问题，AI又能帮上什么忙。 如今每周都有新模型冒出来，大家越看越焦虑，生怕一步慢、步步慢。提效率、搞创新的心情一个比一个迫切，可技术到底能做什么，反倒没顾上弄清楚。 在深圳的一次交流中，他直言，企业不会因为此刻没有用上AI就立即倒闭。所以作决定之前，企业需要先让工程师和管理者充分学习，了解技术的能力。 但这话从Werner嘴里说出来，多少是有点反差在身上的。 毕竟这位担任亚马逊CTO二十多年的技术老兵，向来不愿意接受“不可能”。讲起云计算的幕后故事时，他还特意搬出计算机先驱Grace Hopper的名言，提醒开发者警惕那句“我们一直都是这样做的”。 一个不断鼓励工程师打破常规的人，为什么到了AI这里，又让大家先缓一缓？ 他讲起的一场数据库故障，或许能解释这种看似矛盾的态度。 数据库踩过的坑，AI还要再踩一遍吗？ 2004年12月12日，亚马逊正处在圣诞购物季的关键节点。当时用户购物满25美元就能享受免费配送，但运输需要时间，再晚下单，包裹就可能赶不上圣诞节。 偏偏就在这一天，客户数据库背后的共享磁盘出了故障，用户无法登录，也无法下单。按照Werner的回忆，这次故障持续了 十二个多小时 ，让亚马逊 损失了数百万美元 。 数据库供应商后来找上门，Werner原以为对方会郑重道歉，听到的却是“你们应该做好测试”。 自家的产品出了问题，怎么还怪起客户来了？ Werner当然生气，但他后来也意识到，亚马逊的规模确实已经远远超出了这套商业软件的设计范围。继续和供应商争论，也解决不了下一次故障。 于是，团队开始调查一个更基本的问题。 亚马逊究竟怎样使用数据库？ 调查结果显示，约70%的关系型数据库使用场景，只需要键值访问。 拿购物车来说，系统通常只需要根据用户标识，取出对应的购物车。亚马逊并不需要把所有用户的购物车都调出来，做一次复杂查询。 既然需求如此，团队能不能换一种实现方式？顺着真实的访问方式往下想，他们构建了键值存储系统 Dynamo ，也就是DynamoDB的前身。 这段经历放到今天，颇有既视感。当年大家拿关系型数据库这把大锤处理各种数据问题，如今大模型也很容易成为那把顺手的锤子。 谈到企业采用AI，Werner反复追问的也是类似的问题。 企业究竟想解决什么，AI是否适合，当前这一代AI是否适合？ 他提醒，图像识别、语音处理、预测等领域，早就积累了大量有效的方法。企业选择技术之前，需要先看任务本身。即使用大模型，也未必需要追着榜单第一名跑。 Werner对基准测试有所保留，因为人为构造的测试与真实业务之间，仍有距离。如果一个模型已经足够完成任务，企业继续为更高的排名付钱，就得重新掂量收益。 而且Werner算这笔账， 已经算了二十多年 。 当交流的话题转向云计算带来的根本变化时，他格外看重经济模式的改变。 过去买企业软件，企业往往得先签五年、十年的合同。管理者连明年的需求都很难预测，却要先把钱付出去。Werner觉得，这就像顾客进餐厅先放下一千美元，没吃完也不退款。 云计算把资源使用量和付费联系起来，也让“缩容”有了实际意义。夜里没那么多用户，企业就可以把不需要的资源关掉。成本终于能够进入架构讨论，业务部门也需要回答，某项能力到底值得花多少钱。 到了AI时代，这笔账又有了新项目。 比如在量子位问起， “为什么智能体连遗忘都成了重要工程问题？” 时，Werner直言，如果智能体每次工作前，都要扫描自己知道的一切，系统开销就会很大；开发者需要想办法，让它留下对任务真正重要的内容。 他还提到，一些编程工具重新启动时，会再次加载项目内容。用户昨天已经为这些准备工作付过钱，今天又得重新付一遍。Kiro的跨会话记忆，正是想减少这样的重复劳动。 所以，除了模型有多聪明，开发者还得追问，它为了完成一次任务，反复做了多少无用功。 这也解释了Werner为何愿意谈较小的模型，以及DeepSeek、通义千问、Kimi等开放权重模型。按他的观察，有些客户经过持续实验，发现更小的模型已经能满足需求，使用成本也低得多。 用什么、怎么用、花多少钱，这些老问题，企业到了AI这里依然绕不过去。 谁来替Agent犯的错兜底？ 即使企业算清了成本，还有另一个问题等着开发团队。 聊天机器人给出一段文字，人可以看完再决定怎么办。Agent则会代表用户采取行动，改行程、调用工具、执行程序。模型一旦给错答案，错误就可能顺着执行过程变成真实后果。 Werner在交流的过程中表示，他很乐意让Agent帮忙改签车票，但他也有明确要求。系统得知道如何操作、记住他的偏好，同时受到约束。 而这种对边界的执着，在他讲的 Nitro 故事里，已经有所提及。 早期云计算依赖虚拟化，把一台物理服务器分给多个用户；但负责管理虚拟机、处理网络和存储访问的软件，本身也要消耗资源。随着虚拟机越来越多，管理层还可能成为瓶颈。 AWS后来构建Nitro，把大量网络、存储等功能卸载到专用硬件，并去掉了原先那个完整的Linux管理环境dom0。团队缓解了性能瓶颈，也随之缩小了一大块攻击面。 Nitro还有一个有意思的设计，叫“被动通信”。根据Werner的介绍，虚拟机监控程序等待Nitro控制器下发命令。如果它反过来主动联系控制器，就出现了正常流程里不该有的行为，平台可以据此将相关系统退出服务，展开调查。 顺着这个思路，也就容易理解Werner对Agent的要求了。用户允许系统做什么，必须提前说清楚。他举了一个简单例子，用户可以规定Agent每天不能花费超过100美元，一旦超出，就需要人参与决策。 按他的介绍，亚马逊为Agent设计了规则执行机制，对Agent访问工具、运行脚本等操作进行检查，以限制它在客户明确授权的范围内行动。 用户的授权给自主行动划出了具体范围，即便模型判断某件事值得做，执行系统仍要检查它有没有权限做。 但这些约束，会不会拖累Agent的效率？面对这个问题，Werner先谈的是 责任 。 你构建它，你就对它负责。（You build it, you own it.） 在他看来，Agent的开发者必须能够控制它。系统采取了什么行动、有没有超出边界，最终仍然需要人负责。 Werner也把对AI的信任，放回了分布式系统的经验里。工程师从来不会假定每个组件都永远可靠，所以才需要复制、隔离和各种可靠性机制。团队对单个组件保持警惕，才能建立对整个系统的信任。 不过，工程师要把这些保护机制做成客户用得起、又不会明显拖慢任务的服务，还得经历不少取舍。Lambda就曾遇到过类似的难题。 早年WeTransfer为了处理上传到S3的文件