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

当企业担心错过AI转型窗口，亚马逊CTO Werner Vogels 提醒，越是着急，越需要先想清楚：企业究竟要解决什么问题，AI又能帮上什么忙。 如今每周都有新模型冒出来，大家越看越焦虑，生怕一步慢、步步慢。提效率、搞创新的心情一个比一个迫切，可技术到底能做什么，反倒没顾上弄清楚。 在深圳的一次交流中，他直言，企业不会因为此刻没有用上AI就立即倒闭。所以作决定之前，企业需要先让工程师和管理者充分学习，了解技术的能力。 但这话从Werner嘴里说出来，多少是有点反差在身上的。 毕竟这位担任亚马逊CTO二十多年的技术老兵，向来不愿意接受“不可能”。讲起云计算的幕后故事时，他还特意搬出计算机先驱Grace Hopper的名言，提醒开发者警惕那句“我们一直都是这样做的”。 一个不断鼓励工程师打破常规的人，为什么到了AI这里，又让大家先缓一缓？ 他讲起的一场数据库故障，或许能解释这种看似矛盾的态度。 数据库踩过的坑，AI还要再踩一遍吗？ 偏偏就在这一天，客户数据库背后的共享磁盘出了故障，用户无法登录，也无法下单。按照Werner的回忆，这次故障持续了 十二个多小时 ，让亚马逊 损失了数百万美元 。 数据库供应商后来找上门，Werner原以为对方会郑重道歉，听到的却是“你们应该做好测试”。 自家的产品出了问题，怎么还怪起客户来了？ Werner当然生气，但他后来也意识到，亚马逊的规模确实已经远远超出了这套商业软件的设计范围。继续和供应商争论，也解决不了下一次故障。 于是，团队开始调查一个更基本的问题。 亚马逊究竟怎样使用数据库？ 调查结果显示，约70%的关系型数据库使用场景，只需要键值访问。 拿购物车来说，系统通常只需要根据用户标识，取出对应的购物车。亚马逊并不需要把所有用户的购物车都调出来，做一次复杂查询。 既然需求如此，团队能不能换一种实现方式？顺着真实的访问方式往下想，他们构建了键值存储系统 Dynamo ，也就是DynamoDB的前身。 这段经历放到今天，颇有既视感。当年大家拿关系型数据库这把大锤处理各种数据问题，如今大模型也很容易成为那把顺手的锤子。 谈到企业采用AI，Werner反复追问的也是类似的问题。 企业究竟想解决什么，AI是否适合，当前这一代AI是否适合？ 他提醒，图像识别、语音处理、预测等领域，早就积累了大量有效的方法。企业选择技术之前，需要先看任务本身。即使用大模型，也未必需要追着榜单第一名跑。 Werner对基准测试有所保留，因为人为构造的测试与真实业务之间，仍有距离。如果一个模型已经足够完成任务，企业继续为更高的排名付钱，就得重新掂量收益。 而且Werner算这笔账， 已经算了二十多年 。 当交流的话题转向云计算带来的根本变化时，他格外看重经济模式的改变。 过去买企业软件，企业往往得先签五年、十年的合同。管理者连明年的需求都很难预测，却要先把钱付出去。Werner觉得，这就像顾客进餐厅先放下一千美元，没吃完也不退款。 云计算把资源使用量和付费联系起来，也让“缩容”有了实际意义。夜里没那么多用户，企业就可以把不需要的资源关掉。成本终于能够进入架构讨论，业务部门也需要回答，某项能力到底值得花多少钱。 到了AI时代，这笔账又有了新项目。 他还提到，一些编程工具重新启动时，会再次加载项目内容。用户昨天已经为这些准备工作付过钱，今天又得重新付一遍。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替人多写了一段代码，工程师还得知道，这段代码上线后会发生什么。 版权所有，未经授权不得以任何形式转载及使用，违者必究。 Agent Werner Vogels 云计算 亚马逊云科技 十三 扫码分享至朋友圈 相关阅读 技术、场景、生态共振：京东健康发起“AI普惠医疗加速计划” 京东健康发布“AI医院”、升级“京医千询2.0” Agent 京东 医疗大模型 自动驾驶量产上车只是挑战开始！运营难搞，鹅厂献策 解车企燃眉之急 云原生 云计算 自动驾驶 车云一体 GPT-4o连验证码都解不了？？SOTA模型成功率仅40% Agent “云计算一哥”深夜放大招：几分钟，纯靠Prompt打造一个App！ 一年多发布326个生成式AI功能 云计算 亚马逊云科技 生成式AI 飙着车学「机器学习」？要不是380万人围观我都不敢相信 全球最知名的自动驾驶玩具车竞赛 亚马逊 亚马逊云科技 有人把巴菲特芒格炼化成Agent，然后开源了… 让小散有了「大师模型」。 Agent 热门文章 智谱新模型，490 tokens/s！ DeepSeek服务器全球宕机！神秘Harness账号同时现身 DeepSeek Bot来了！民间版，DSH装个插件就能用 超清双2亿，掌中电影机，荣耀Magic9 系列正式发布，售价4499元起 何恺明团队发布多模态Harness框架 加入我们 寻求报道 商务合作 追踪人工智能新趋势，报道科技行业新突破