AWS 推出由智能体团队开发的免费开源 AWS 模拟器

AWS 周三发布了一款名为 AWS Emulator 的 AWS 模拟器。这件事本身就很有意思，也可能引发一些关于 LocalStack 未来的疑问。但或许最引人注目的是，这款模拟器完全由一个智能体团队构建，并且今后也将由它们来维护。由于 AWS 不确定自己是否真的能为这些智能体的工作主张版权——也不愿在可能不存在版权的地方强行主张——这款模拟器采用 Creative Commons Zero 许可发布，从而将代码放入公有领域。

AWS 首席开源软件策略师 Tom 'Spot' Callaway 对 The New Stack 表示，过去显然也有过其他模拟器——AWS 自己也构建过一些。“挑战在于，它们很快就会过时，”他解释道。“它们并不总能反映实际状况，正因如此，它们往往不被信任。我们内部甚至也不信任它们。”随着智能体编程工具的兴起，团队也意识到需要一款更好的模拟器，帮助智能体针对 AWS 服务测试代码，而无需把 AWS 凭证交给智能体。

构建 AWS Emulator 的智能体系统。图片来源：AWS。与此同时，团队也在寻找一个用智能体构建完整项目的测试案例，而这款模拟器被证明是一个很好的试验场，很大程度上是因为它提供了一个边界明确、目标清晰且结果可验证的问题。由于 AWS 已经以 Smithy 模型的形式发布了一整套 API 模型，并基于这些文件生成所有 SDK，“我们没有理由不能围绕同样的逻辑也生成模拟仿真，”Callaway 说。### 一个周末的 Kiro 实验这个项目可以追溯到 AWS 开发者工具团队高级首席工程师 Matt Goldberg 的一次实验。Callaway 说，团队“深受 Anthropic 工作的启发，他们实例化了一个编译器”，指的是 Anthropic 研究人员今年早些时候让一个智能体团队构建的 C 编译器。Goldberg 在一篇博客文章中写道，他最初让 AWS 的智能体编程工具 Kiro 为 Amazon Simple Queue Service (SQS) 构建一个模拟器。15 分钟后，第一版就出来了。随后他让 Kiro 用一个周末的时间把 AWS 其余部分也构建出来。他指出，那个版本不出所料存在缺口，但他的团队在接下来的周一就开始用自己的软件对它进行测试。“我得承认，第一次听说这件事时，我的反应是，‘你确定这是个好主意吗？’”Callaway 说。他补充说，团队迭代得越多，他就越放心，认为这是一个适合智能体接手的好问题。在当前版本中，AWS Emulator 支持 438 个公开的 AWS API 模型，覆盖 200 多项服务。随着 AWS 更新这些模型并发布新服务，智能体也会迅速更新模拟器。Callaway 预计，从新 AWS 服务发布到模拟器支持它之间的差距将是“几天，而不是几周，更不是几个月”，不过他指出，团队还没有看到项目公开后这一预期会如何发展。模拟器本身用 Rust 编写，可在 Linux、macOS 和 Windows 上本地运行，无需网络连接或 AWS 账户。“AWS Emulator 内部没有 AI，”Callaway 说。“它完全不会调用 LLM。”### 三个智能体团队AWS 表示，它将工作分配给三个智能体团队。第一个团队根据公开的 Smithy 模型开发测试场景，并针对真实 AWS 服务运行这些场景，以确定模拟器应有的行为。这些场景可能涉及多个服务协同工作，而不仅仅是单个 API 调用。正如 Callaway 所解释的，“如果文档不说真话，那么云就成为真相的来源。”第二个团队针对模拟器运行这些场景，并调查其行为与 AWS 不同之处。它将看似有共同原因的失败归类，并在代码仓库中提交 issue。最后，第三个团队接手这些 issue 并修改代码加以解决。在这些更改可以合并之前，它们必须通过构建和测试检查，以及由其他智能体进行的安全问题、编码规范和模拟器行为回归审查。与此同时，人类工程师则专注于改进指挥智能体的系统。“我们不编辑它。我们不修改它，”Callaway 谈到模拟器代码时说。“如果我们发现代码有问题，我们会尝试把这些问题追溯到智能体，并修复智能体，使它不再产生糟糕的代码。”因此，当这些智能体生成的代码出现问题时，团队会改变智能体的工作方式，而不是手动修补代码。Goldberg 写道，早期版本的智能体曾一度决定编写自己的 Python 解释器，以便模拟器支持 Lambda 函数。团队此后已指示它们复用现有库。“我认为我们在沙箱方面学到了很多，”Callaway 说，“过去几个月里，我们大家不都是这样吗？”他说，该系统最初的几个迭代“没有他们需要的那么严格的沙箱”，而且早期还有一些担忧，担心智能体查看 AWS 内部服务的源代码，以弄清楚如何实现 Aurora 之类的东西。团队还花了很多时间安抚 Amazon 高管，让他们相信构建模拟器的框架不会“失控”。### 不接受 pull request这种放手不管的方式也适用于外部贡献者。“我们根本不会接受该项目的 pull request，”Callaway 说。“智能体会做这件事。我们会接受客户提交的 issue。”他把这些智能体描述为“他们自己的小小 pull request 军队”。如果它们持续把某个特定 API 弄错，“那就是智能体的 bug，”他说，他预计客户主要会贡献模拟器目前还处理不好的场景。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）