AWS 发布了一个本地模拟器,允许开发人员在自己的机器上运行和测试 AWS API 端点。该项目的独特之处在于每一行代码都是由自主 AI 智能体编写的。此工具可在开发环境和持续集成 (CI) 流水线中进行软件测试,且无需激活 AWS 账户或产生服务费用。通过提供实时的云资源的本地替代方案,该模拟器旨在简化开发周期,同时保持与实际 AWS 环境的高度一致性。

AI 驱动的开发流水线

该模拟器是使用涉及三个自主 AI 智能体团队的专门工作流开发的。第一个团队负责管理测试套件,将 Smithy API 模型和真实世界的 AWS 数据转换为数万个“保真度测试”。这些测试代表真实世界的场景,例如创建和删除 Amazon SQS 队列,并在保存到共享仓库之前针对实际的 AWS 云进行验证。

显示 Smithy API 模型和真实 AWS 数据输入到测试编写者智能体团队的流程图。
AI 智能体如何将 API 模型和真实世界数据转换为保真度测试的详细工作流。www.aboutamazon.com

此图像提供了文章中描述的开发流水线第一阶段更细致的视角。

第二个智能体团队在模拟器代码上重放这些保真度测试,以识别差异。当测试失败时,智能体会对失败进行推理并将问题按根本原因分组。第三个智能体团队随后接手单个问题,检出代码并进行编辑,直到故障解决。这些更改必须通过多阶段门禁——包括构建检查、代码标准审查、安全审计和保真度验证——然后才能合并到主干代码中。

展示三个 AI 智能体团队与共享 CodeCommit 仓库交互以开发 AWS Emulator 的图表。
说明三个团队自主 AI 智能体工作流的图表:测试编写者、问题查找者和修复者。www.aboutamazon.com

该图表可视化了不同 AI 智能体团队处理测试创建、问题识别和代码修复的专门工作流。

“数千个自主 AI 智能体编写了 AWS Emulator 的每一行代码,这是一款现在可供下载的全新 AWS 本地模拟器。”

— How we built the agents that built AWS Emulator

运行模式和技术要求

开发人员可以通过两种主要方式与模拟器交互。在“服务器模式”下,模拟器作为一个提供 AWS API 端点的本地程序运行;用户可以通过环境变量将他们的 AWS CLI 或 SDK 指向此本地地址。在“嵌入模式”下(专门为 Rust 测试设计),模拟器直接编译到测试二进制文件中,允许测试将模拟器的 HTTP 客户端直接连接到 SDK 客户端,而无需外部端点或证书。

虽然模拟器免费使用,但从源代码构建它需要大量的本地资源。所有服务 crate 的完整调试构建可能需要至少 100 GB 的可用磁盘空间和一台多核机器。对于大多数用户,AWS 提供预构建的 Linux(RPM/Debian)软件包以及 Windows 和 macOS 的 Docker 容器,以避免这些高昂的构建成本。

保真度与局限性

AWS 为每个服务提供保真度评分,以指示模拟器与真实云的匹配程度。虽然模拟器涵盖了 438 个 AWS API 模型,但它明确不用于生产工作负载或测试安全协议。该项目维护一个公共问题追踪器,记录服务行为中的各个差距,并将其分为“无法工作的内容”和“现在可以工作的内容”。

该模拟器默认还包含遥测数据,以帮助 AWS 了解该工具的使用情况。此遥测数据采用严格的数据最小化设计,确保绝不会收集请求内容、代码、凭据或个人数据。偏好保持本地测试私密性的用户可以通过命令行标志、环境变量或配置文件选择退出遥测。

Hacker News 读者的反应

  • 替代方案: 一位评论者对该工具的长期维护表示怀疑,并建议使用 Floci 或 Testcontainers 等现有替代方案。 评论 ↗
  • 质疑: 一位用户质疑该项目的动机,暗示它可能主要是为了训练大语言模型而非为了通用开发用途。 评论 ↗
  • 质疑: 另一位评论者认为该项目本质上是 AI 模型的产品而非 AWS 自身的工程产物,并指出此类能力现在很容易被其他人复制。 评论 ↗

以上为 Hacker News 讨论中观点的摘要,并非经过核实的事实。 阅读完整讨论 ↗