2004年，我刚加入亚马逊不久，便选中了当时正在阿姆斯特丹自由大学攻读博士的Swaminathan Sivasubramanian（简称Swami）。这或许是我在担任亚马逊CTO的22年中做出的最佳决定之一。同年圣诞节，亚马逊遭遇数据库危机，商业关系型数据库无法满足需求。我要求Swami调研数据库使用情况，他发现70%的操作并非关系型，而是键值存储。这一洞察直接催生了Dynamo项目，Swami参与了其架构设计。实习结束后，我甚至在他完成博士论文前就将其全职聘请。Swami的学术背景与亚马逊务实的工程文化碰撞，引发了关于最终一致性、CAP定理等话题的深度讨论。他随后成为AWS数据战略的核心架构师，也是亚马逊AI创新的重要推动者。今天，他撰文详解AWS模拟器背后的分布式系统原理，以及智能体编码时代工程师角色的转变。从“Alf”到AWS模拟器：分布式系统的测试演进。AWS模拟器的发布，让我想起早期与工程师Al Vermeulen合作开发的分布式锁服务“Alf”。Alf基于Paxos协议构建，至今仍是S3、DynamoDB等系统的核心组件。分布式系统极难测试。Paxos虽是共识协议的黄金标准，但在亚马逊的规模下，需应对数万客户端并发、网络分区等复杂场景，且必须保证强一致性。传统的大规模系统测试和混沌测试成本高昂，且难以按需重现特定故障。为解决这一问题，我们在JVM中高保真模拟Alf的运行环境，通过注入数据包丢失等故障，结合TLA+等形式化推理技术，在部署前消除了大部分并发错误。这种模拟方法在小规模服务时代行之有效，但随着AWS服务超过200个，手工构建测试环境已不可持续。智能体自主构建测试环境。AWS开发者工具团队资深首席工程师Matt Goldberg提出假设：给定服务的书面描述（公开API模型）和真实AWS作为核对基准，智能体能否独立构建可用的服务版本？智能体基于从公开API模型设计的端到端保真度测试工作。例如，测试SQS消息在可见性超时前的隐藏状态。智能体不断修正模拟器，直到其通过所有在真实AWS上通过的测试。Matt最初仅针对SQS尝试，当向Kiro提供相关提示后，约15分钟便返回了可接受的SQS模拟器初版。如今发布的AWS模拟器，代码全由智能体编写和测试，涵盖200多个AWS服务的400多个API模型。它在用户机器上免费离线运行。智能体团队通过与真实AWS比对测试修复差距，每项更改均需经过包含多个安全智能体对抗性审查的严格合并门禁。编码循环中的基础设施与工程师新职责。编码智能体在“编写-运行-阅读结果”的循环中工作。AWS模拟器将基础设施置于本地循环中，使智能体能即时检查工作，提高首次生成正确代码的概率。当智能体编写代码并自我检查时，工程师的职责转变为提供自主工作空间，并构建规范、测试和合并门禁等“护栏”，以判定工作的正确性。我曾花费四个月重建Alf复制引擎，而在建立规范和测试环境后，重建过程仅需两小时。AWS模拟器的智能体从一开始就具备公开API模型和真实AWS这两大护栏。内部版本在周末组装完成，一个月内开始获得采用。人工智能时代的软件质量，取决于工程师围绕智能体设计的护栏，包括经真实AWS验证的测试、多重安全审查及确定性检查。我们正处于学习如何驱动智能体团队构建高质量软件的早期阶段。AWS模拟器代码已通过CC0协议向公共领域发布。完整的提交历史及智能体发现的问题均在GitHub公开，其中“things-that-do-not-work”文件夹记录了尚未与真实AWS行为匹配的问题。更多细节将在re:Invent大会上分享。