AWS 发布了 AWS Emulator，这是一个提供 AWS API 端点的本地程序，允许开发者在不向云端发送实际调用的情况下测试软件。值得注意的是，模拟器的每一行代码都是由自主 AI 智能体而非人类工程师编写和测试的。此项开发的目的是通过提供一个本地环境来解决测试复杂分布式系统的难题，在此环境中，智能体迭代代码的速度比人类团队在生产环境中验证代码的速度更快。
分布式系统测试的演变
大规模测试分布式系统是出了名的困难，因为并发错误往往只在特定的网络条件或事件顺序下出现。为了解决早期服务（如基于 Paxos 的锁服务“Alf”）的这一问题，亚马逊工程师构建了一个模拟环境，可以在受控的 JVM 环境中丢弃数据包并注入故障。
虽然模拟和形式推理（如 TLA+）提高了软件质量，但随着 AWS 服务增长到 200 多个，手动构建这些环境变得不可持续。AWS Emulator 通过使用 AI 智能体根据现有服务规范自动生成这些测试环境来解决这一问题。
“当智能体编写代码并检查自己的工作时，工程师的工作是给他们提供独立工作的空间，并构建规范、测试和合并门，以决定这些工作何时是正确的。”
— AWS Emulator and the engineer's job when agents write the code
智能体驱动的开发工作流
该模拟器是采用三团队智能体架构构建的。第一个团队将 Smithy API 模型和真实的 AWS 行为转换为“保真度测试”。第二个团队在模拟器上重放这些测试以识别差异，并在“不工作的东西”文件夹中提交问题。第三个团队接手这些问题，编写修复程序并提交审核。
此图表可视化了文章中描述的三团队智能体架构，展示了不同的 AI 团队如何协作构建和维护模拟器。
由 HN Digest 根据 aboutamazon.com 报告的数字绘制的图表；数值按来源所示显示。
这些智能体在“合并门”内运行——这是一系列自动化检查，用于验证代码是否可编译、符合编码标准、安全性良好，并与真实的 AWS 云保持保真度。这允许智能体在循环中迭代代码，在人类看到最终提交之前就纠正自己的工作。
此图提供了关于 Smithy API 模型、真实 AWS 行为以及 AI 智能体使用的特定文件夹之间数据流的更细致的视角。
工程师角色的转变
随着智能体承担大部分编码和测试工作，人类工程师的角色正转向高层监督和基础设施设计。工程师现在的重点是为智能体定义“涂色书”：公共 API 模型、保真度测试以及确保智能体不“越界”的自动化护栏。
该项目证明了 AI 时代的软件质量取决于这些护栏。通过提供一个智能体可以检查自己工作的本地环境，工程师可以更有效地监督流程，从手动实现转向设计管理自动化生产的系统。
用法与限制
AWS Emulator 仅用于构建和测试；它不是为生产工作负载或安全性测试设计的。它在用户的机器上离线运行，虽然它提供了 AWS API 的本地副本，但它并不提供每一个可能云行为的 1:1 复制。
单个服务的差距在仓库的问题目录中进行跟踪。虽然模拟器在本地测试能力方面取得了重大飞跃，但每个服务的“保真度评分”表明，某些行为仍可能与实时的 AWS 环境有所不同。