AWS 发布 AWS Emulator，让编码智能体在本地测试 AWS 服务

2026年11月11日 • 1671 词

2004年，我刚加入Amazon不到一个月，就获得了为团队挑选一名实习生的机会。相比同事，我有一个优势：我早已听说一位才华横溢的年轻人正在阿姆斯特丹自由大学攻读博士学位（我恰好也是在那里获得博士学位的 :-)）。我立刻选中了Swaminathan Sivasubramanian，也就是大家现在熟知的Swami。这大概是我担任Amazon CTO 22年来做出的最佳决定之一。

2004年经历了一个灾难性的圣诞节——当时商用关系型数据库无法满足Amazon的规模需求——之后，我请Swami深入研究关系型数据库在Amazon的实际使用方式。结果发现，70%的数据库操作根本不是关系型的，而是键值型的。这一洞察催生了Dynamo，Swami参与设计了它的架构。实习结束后，我立刻全职聘用了他，甚至在他完成博士学业之前。

引入另一位有主见的学者，促成了他与Amazon务实工程师之间许多精彩的讨论——这些工程师通过真正大规模构建系统，已成为规模扩展方面的专家。最终一致性与强一致性、CAP与Paxos，等等。随着时间推移，Swami成为AWS数据战略的主要架构师之一。而正如近年来所见，他也是Amazon AI创新背后的思想驱动者之一。

我很荣幸他愿意撰写一篇客座文章，讲述支撑许多AWS服务的基础分布式系统工作，以及当智能体编写代码时工程师的工作会如何变化。今天发布的AWS Emulator，为智能体提供了这类工作所依赖的测试环境。Swami的故事是隐形工程的又一个绝佳范例。

现在，去构建吧。

-W

AWS Emulator，以及当智能体编写代码时工程师的工作

今天我们发布AWS Emulator，它为编码智能体提供了一份本地AWS副本用于测试，并且它与我在职业生涯早期参与的一个项目有关。在很多方面，这次模拟器的发布让我想起我们为提升所构建分布式系统的质量而在可靠软件工程上投入的努力。为此，我们想分享一个故事：

大约二十年前，Werner让我与Amazon最早的工程师之一Al Vermeulen合作，开发一个名为“Alf”的分布式锁服务。Alf构建在Paxos之上——这是一种基于Leslie Lamport工作的协议，能让一组服务器就某个值达成一致——其中的复制引擎使数据副本在各服务器之间保持一致。时至今日，Alf仍是支撑我们许多复杂分布式系统（如S3、DynamoDB等）的服务（尽管它经过各种叠加改动已演进不少——留待另一篇博客再讲！）。

分布式系统很难测试

Paxos 是分布式系统共识协议中的黄金标准，在学术界已有充分理解。然而，在 Amazon 和 AWS 当时所处的增长规模下构建它并非易事。我们不仅要处理跨服务器和数据中心的复制问题，还要应对数以万计的客户端同时请求锁、在网络分区期间续租，同时满足核心要求：始终正确！当时，测试分布式系统的最佳思路是大规模系统测试和混沌测试。两者都有效，但成本高昂，且无法按需复现多种条件。这对 Alf 至关重要——Alf 旨在成为真相存储，为每个客户端提供强一致的真相视图，并且必须在服务器故障和丢包的情况下持续工作。多篇行业论文指出，基于 Paxos 的锁服务很难做对，而测试难度大是部分原因。

我们通过尽可能高保真地模拟 Alf 的环境来解决这个问题。我们在 JVM 内运行服务器，并模拟网络及其依赖的其他基础设施，使整个系统运行在一个我们可控的程序中。我们可以随时丢包并注入其他故障，还构建了工具来探查模拟中的缺陷和可扩展性问题。并发缺陷只在事件以特定顺序发生时才会出现，而在模拟中我们可以故意构造许多这样的顺序，并检查 Alf 如何处理每一种情况。我们还通过 TLA+ 等理论技术进行形式化推理，这也发现了许多问题。通过这种测试方式，我们在 Alf 运行于真实服务器之前就消除了大部分并发缺陷。随后在真实环境中测试又暴露了不同的问题，因为现实世界会暴露模拟无法覆盖的情况。

手工构建的测试环境已不够用

模拟和形式化推理都提升了我们所应用的分布式系统的软件质量。模拟之所以有效，是因为一个小团队可以手工构建单个系统环境的副本，而当时 AWS 只有少数几个服务。但如今 AWS 拥有超过 200 个服务，一个调用 AWS 的应用程序需要为其使用的每个服务准备测试环境。全部手工构建将耗费数年的工程时间，而如今智能体编写代码的速度远超任何团队能在生产环境中检查的速度。因此，我们想知道智能体能否自行构建和测试这些环境。

这个想法来自 Matt Goldberg，他是 AWS 开发者工具团队的高级首席工程师。他的假设是：给定一个服务应如何行为的书面描述以及用于对照的真实服务，智能体可以自行构建该服务的可用版本。对 AWS 而言，书面描述是以 Smithy（AWS 用于描述服务操作及其输入、输出和错误的格式）编写的公开 API 模型集合。用于对照的真实服务就是 AWS 云本身，即客户使用的同一系统。

这些智能体依据保真度测试开展工作，这些测试是从公开 API 模型设计出的端到端客户场景。例如，某个测试可能会检查在 Amazon Simple Queue Service 中，已接收的消息在其他读取者看来是否一直处于隐藏状态，直到其可见性超时结束。智能体会修正每个测试，直到它针对真实 AWS 通过，因此该测试记录了 AWS 的行为方式。随后智能体构建模拟器，直到它通过同一个测试；仍然失败的测试则指向模拟器中的缺口。Matt 最初只从 SQS 入手，当他给 Kiro 一个描述此方法的提示时，Kiro 在大约 15 分钟内返回了一个可用的 SQS 模拟器初版。Matt Goldberg 的发布文章讲述了该原型如何发展为 AWS Emulator。AWS Emulator 的所有代码均由智能体编写和测试，它基于 400 多个 API 模型构建，覆盖 200 多项 AWS 服务。它可在你自己的机器上免费离线运行。智能体团队会针对真实 AWS 对其进行测试，并修复发现的缺口。每项变更都要经过合并门禁——一套深度自动化检查，每项变更在进入代码库前都必须通过，其中包括多个安全智能体进行对抗性审查。

编码循环中的基础设施

编码智能体在一个循环中工作：它编写代码、运行代码、读取结果，然后决定下一步要改什么。在分布式系统中，这个循环运行在基础设施内部，因此它调用的服务必须表现得像真实服务一样。当它们做到这一点时，智能体就能在编写过程中检查自己的工作，从而大幅提高首次尝试就产出正确代码的概率，进而提升软件质量。AWS Emulator 将这套基础设施放进了你本机上的循环中。

智能体编写代码时工程师的工作

当智能体编写代码并检查自己的工作时，工程师的工作就是给它们留出自主工作的空间，并构建规范、测试和合并门禁，以判定工作何时正确。这是我在用 Kiro 重建我和 Al 为 Alf 构建的复制引擎时吃尽苦头才学到的教训——第一次我们花了大约四个月。我监督了智能体四个晚上，才发现它根本没有办法检查自己的结果。一旦有了规范和测试环境，重建只花了大约两个小时。

构建 AWS Emulator 的智能体从一开始就同时拥有这两者：公开 API 模型和真实 AWS。一位工程师构建了运行它们的脚手架。一个内部版本在一个周末内成型，并在一个月内开始获得采用。将其转变为稳健的解决方案则需要多得多的努力。

AI 时代的软件质量取决于工程师围绕智能体设计的护栏。在 AWS Emulator 中，这些护栏包括针对真实 AWS 验证的保真度测试、一个包含多个安全智能体的合并门禁（每个安全智能体从不同的攻击方式角度审查变更，并与一名通用代码审查员协同工作），以及阻止智能体触碰其不应触碰代码的确定性检查。我们预计智能体将构建并检查大多数软件，而工程师决定构建什么以及工作何时正确。我们才刚刚开始了解工程师如何驱动智能体团队构建可靠、高质量的软件，而 AWS Emulator 的诞生方式正是这一实践的良好范例。我们预计会持续增加护栏并改进智能体的构建方式。

发布时须知

模拟器代码以 CC0 发布，这是 Creative Commons 将其贡献给公有领域的奉献声明。

我们将在 re:Invent 上分享更多关于这项工作的内容。完整的提交历史和智能体提交的每一个 issue 都在 GitHub 仓库中公开，其“things-that-do-not-work”文件夹收录了描述智能体发现的、目前尚与真实 AWS 不符的行为的 issue。