68岁亚马逊CTO，劝企业先三思再AI

恐惧是一种非常糟糕的决策方式。

当企业担心错过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的文件，需要一直运行一批计算实例，等待新文件到来。客户光是为了等待事件发生，就得维护一整套基础设施。

AWS希望把这些工作接过来，让客户提交代码，按执行时间和内存使用量付费。团队想清楚了收费方式，底层怎样高效实现，却仍是一道难题。

为了隔离不同客户，早期Lambda使用的虚拟机，对函数任务来说依然太大，成本很高。后来，团队通过Firecracker把隔离单元做成更轻的微虚拟机，才提高了资源利用率。

隔离问题得到解决之后，团队还得处理冷启动。函数真正执行前，系统需要准备好运行环境、代码和依赖。SnapStart通过保存已初始化环境的快照，减少这部分准备开销，改善启动表现。

客户看到的，可能只是一次函数调用。工程团队却要在背后持续打磨隔离、资源分配、启动和网络机制。

Werner把这些工作称为“看不见的工程创新”（Invisible Engineering）。

Agent要进入实际业务，开发团队同样少不了这些细活。演示跑通之后，团队还得继续明确权限怎样限制、异常怎样处理，以及用户愿意把多大范围的任务交给它。

经验没有压缩算法

当Agent开始写代码，上面这些问题又回到了开发团队自己身上。

谈到初级工程师的就业，Werner回应，亚马逊招聘初级工程师的数量与过去一样。随后，他把话题转向了新人进入团队之后的学习。

一个刚毕业的人加入S3团队，面对的可能是二十年前的代码。学校很难提前教会他，怎样理解这样一个系统，以及怎样和维护它的人协作。

因此，Werner看重好奇心、学习能力和开源项目经历。一个新人参加过开源协作，意味着他的代码接受过其他人的审视，他也需要与别人一起解决问题。

AI可以帮新人解释团队规则，让资深工程师少花一些时间反复说明。Werner介绍Kiro时，强调的也是规格说明驱动。开发者先把需求、架构和开发规则交代清楚，再让系统开展工作。

不过，AI生成代码的速度上来了，团队理解和检查代码的速度，未必跟得上。

Werner提到了一个值得开发团队留意的概念，验证债。

过去为了赶进度，开发者走了捷径，记下以后要修，积累的是技术债。现在，AI生成的代码中，有些部分还没经过验证，团队也就留下了另一笔债。

一个界面元素偏了几毫米，与一段可能泄露客户信息的代码，后果相差甚远。开发团队需要根据风险安排检查，把精力投入最需要验证的地方。

沿着Werner的思路看，团队很容易增加代码产量，但能否理解这些代码、承担它们带来的后果，还需要另外衡量。否则，开发者今天省下的时间，可能会在后续排查和返工中重新花掉。

这也是Werner为什么坚持让初级工程师阅读代码，和资深工程师一起审查、讨论。工具可以解释知识，人面对具体问题时所需要的判断，仍要一点点积累。

经验没有压缩算法。（There is no compression algorithm for experience.）

Werner的这句话，用来回答开发者的焦虑，颇为贴切。

不过，谈到中国之行，他又讲起了一个让他对AI应用更乐观的例子。他花了不少时间介绍“大米和小米”的参访经历。

这家机构为自闭症、注意缺陷多动障碍等有发展支持需求的儿童提供干预服务。据Werner介绍，机构利用AI分析教学记录、观察孩子的进展，并向康复师提供方案建议。康复师再结合专业判断，决定采用哪些建议。

让他印象深刻的，是AI帮助专业人员减少了事务性工作，让他们能把更多精力留给孩子和家庭。

谈到这里，Werner的乐观有了具体对象。技术能让哪些人少一点负担，又能帮助哪些原本难以获得支持的人？这些具体应用，让他看到了AI的价值。

回头看那句“先按暂停键”，企业需要停下来想清楚的事情，也就具体了。任务是否适合交给AI，成本能否承担，行动范围怎样规定，结果由谁验证，开发团队都得逐项回答。

Werner说，开发者最出色的工作，往往藏在别人看不见的地方。

AI替人多写了一段代码，工程师还得知道，这段代码上线后会发生什么。

文章来自于微信公众号 “量子位”，作者 “量子位”