AWS 发布由自主 AI 智能体编写的本地模拟器 AWS Emulator

AWS于2026年11月11日发布了AWS Emulator，这是一个正式可用的本地模拟器，基于438个AWS API模型构建，覆盖200多个服务。自主AI智能体编写并测试了其代码，为开发者和编码智能体提供了一种无需AWS账户即可在自己的机器上调用AWS API的方式。

AWS CLI、AWS SDK和编码智能体通过本地HTTPS端点连接，使用的API与它们在云中使用的相同。环境变量将这些工具重定向到用户自己的机器，应用程序代码保持不变。一篇AWS发布文章详细介绍了适用于Linux的RPM和Debian软件包、适用于macOS和Windows的Docker，以及用于Rust测试的嵌入式模式。不收取额外服务费，但客户仍需为他们在云中部署的AWS资源付费。

对于编码智能体而言，该模拟器将AWS基础设施置于“写入—运行—读取”循环之中：智能体可以创建资源、检查结果并修改代码，而无需等待部署到AWS区域。AWS文档还将开发服务器和持续集成列为该模拟器的适用环境，请求会发往模拟资源而非AWS。

AWS高级首席工程师Matthew Goldberg在一篇工程记述中表示，他的团队既未编写也未审查该模拟器的代码。人类转而构建了围绕这项工作的脚手架，包括规格说明、测试机制、合并门禁和发布流水线。该项目始于Kiro编码智能体根据一个编写测试、针对真实AWS验证测试并构建能通过测试的内存实现的提示，在大约15分钟内生成了一个尚可用的Amazon SQS模拟器。随后Goldberg让Kiro在一个周末内扩展了这个原型；要将其转变为稳健的产品，还需要周边的防护措施。

现在有三个边界明确的智能体团队分工协作。测试编写者根据公开的API模型设计场景，并针对真实AWS进行验证。问题发现者重放测试，并将可能具有相同根因的失败分组，而修复智能体则各自处理一个问题。Goldberg报告称有数万项保真度测试，随着数百个智能体并发工作，每天修复数千个问题。

每个拟议的修复都必须能够编译，并通过针对编码标准、安全性和保真度的自动化检查后才能合并。一个独立的安全智能体在开发期间以及发布流水线中再次以对抗性方式审查变更。“如果没有这道合并门禁，我们就不会信任智能体所构建的东西，”Goldberg写道。

随后，变更在发布到GitHub之前会经过AWS CodeCommit和CodePipeline。公共仓库公开了提交历史，并设有分别存放已解决和未解决保真度问题的文件夹。AWS以CC0（公有领域贡献）发布该代码，但Apache 2.0下的厂商代码除外；该仓库不接受拉取请求，不过用户可以通过GitHub Issues报告缺陷和保真度缺口。

保真度分数界定边界

保真度测试是针对真实AWS校验的简短工作流。要通过测试，模拟器必须使每次调用的响应都匹配，包括状态码、响应体以及确切的错误码和错误消息，还要匹配工作流创建的资源与数据。未实现的操作会返回HTTP 501（未实现），因此失败会立即显现。每个版本都附带各服务的通过计数，AWS提醒说，即使模拟器有所改进，增加测试也可能降低分数。

公共评估套件中的每个测试都至少针对两个沙箱化的AWS账户进行了验证，仓库明确表示，没有测试的行为未经验证。

这些分数并不能使该模拟器成为安全测试环境。它不会像AWS那样评估AWS身份与访问管理（IAM）或基于资源的策略，因此AWS会拒绝的请求在本地可能会成功。支持的用途是构建和测试；生产负载和应用安全测试不在范围内。每个实例旨在对应一个账户和一个区域，将资源保存在内存中，并在停止时删除它们。

在发布文章中，Swaminathan Sivasubramanian将工程师的角色描述为决定应该构建什么，并创建规格说明、测试和合并门禁来确定正确性，而智能体则编写和检查代码。

他与Alf（Amazon早期的一个分布式锁服务）的对比提供了一个具体例子。最初的复制引擎大约花了四个月才构建完成。Sivasubramanian说，Kiro的重建最初耗费了四个有人监督的夜晚，因为智能体无法检查自己的结果；在他提供了规格说明和测试环境后，重建大约花了两个小时。

AWS Emulator将这一经验转化为一款已发布的产品：智能体生成并修复实现，而工程师定义可接受的行为并自动执行这些要求。其实际适用范围现在取决于不断增长的公共测试套件和剩余的保真度缺口，而安全与生产验证仍然需要真实的AWS。