关键要点
- AWS Emulator 是一个本地 AWS 服务模拟器，完全由自主 AI 代理编写。
- 数千个自主代理编写测试、发现问题并修复代码，无需人工审查。
- 源代码在 GitHub 上以 CC0 许可证发布，并持续更新。
我是个糟糕的画家。一直以来都是如此。我父母让我提前一年上幼儿园。有一天，老师让我们坐在一张长桌旁。她在桌上铺了一张巨大的纸，要求我们画出恐龙时代的地球可能是什么样子。我开始认真地绘制我负责的部分。但作为班里年龄最小的孩子之一，我的运动技能尚未发育到能正确握蜡笔的程度。几分钟后，同学们对我大喊大叫。我把一切都搞砸了。
今年我经常想起那些同学。就像他们对我发脾气一样，我发现自己比愿意承认的次数更多地对 AI 代理破口大骂。但在两种情况下，问题都不是出于恶意。这些代理并不是想违抗我，正如我当时并没有想毁掉全班同学的恐龙画一样。这是能力不足的问题。今年早些时候，我的伴侣买了一本涂色书，我们一起花了好几个小时完成其中的一页。被赋予一个定义明确的区域来填充，知道更大的艺术作品会由此组合而成，这种感觉令人安心。我认为代理也需要这样的“涂色书”。
今天，我们发布了 AWS Emulator，这是一个你可以在本地机器上运行的 AWS 服务模拟器，用于构建和测试你的 AWS 应用程序。该模拟器完全由自主代理编写。我们的团队没有编写或审查任何代码。我们可以做到这一点，是因为我们设置的护栏为代理提供了独立工作的空间，同时也让我们相信它们不会越界行事。
AWS Emulator 始于一个周末的实验
今年早些时候，Anthropic 的研究人员展示了 AI 代理能够自主构建 C 编译器，这是一个顿悟时刻：如果提供明确的规范和参考实现，代理可以自主构建忠实于规范的解决方案；AWS 同时具备这两者——AWS API Models 是我们的规范，而实际的 AWS 云则是我们的参考实现。为了验证我的假设，我给 Kiro 发送了我能想到的最简单的提示，且并未期望它能成功：
- 基于 AWS 命令行界面 (CLI) 编写测试
- 迭代这些测试，直到它们在真实的 AWS 环境中通过
- 构建一个内存实现，使相同的测试在该实现中也能通过
15 分钟后，Kiro 返回了一个可用的 Amazon Simple Queue Service (Amazon SQS) 初版。我优化了我的提示词，并在周末让 Kiro 为我构建其余的 AWS 服务。它确实做到了。虽然显然存在缺陷，但它足够引人注目，以至于我的团队从周一开始用它来测试我们的软件。
将其转化为一个稳健的产品花费了超过一个周末的时间。如今人们很容易看到这样的成果并相信 AI 能构建任何东西，也许最终确实如此，但构建出让你有信心交付给客户的产品仍需严肃的工程努力。就 AWS Emulator 而言，这需要建立确保代理行为符合我们规范的护栏。
三个 AI 代理团队如何构建 AWS Emulator
AWS Emulator 从根本上是由三个代理团队构建的。一个团队管理测试套件；一个团队在模拟器中发现错误；另一个团队修复这些错误。我们将代理责任划分为这些团队，因为我们发现它们在有限定的任务上更容易取得成功。
展示 AI 代理团队如何协作运行测试和解决问题的图表。
第一个代理团队的测试套件以真实 AWS 云为基准衡量保真度。每项测试都是一个真实的 AWS 场景。例如，针对 Amazon SQS 的测试可能包括创建队列、发送消息、接收消息、确认接收以及删除队列。代理团队从公开发布的 AWS API 模型中设计这些测试，并在提交前对每个测试在真实 AWS 上进行验证。我们在所有 AWS 服务上拥有数万个保真度测试，并且随着代理团队发现他们能够用 AWS 完成的新任务，该测试套件不断扩充。这些测试是我们系统中最重要的护栏之一，因为它们为代理团队提供了明确的目标，并且可以反复运行而无需再次调用 AWS。
第二个代理团队重播保真度测试，以查找模拟器中的偏差。当系统最初创建代码库时，它生成了一个空 Web 服务器，该服务器能够处理来自 438 个 AWS API 模型的请求，但本身不执行任何操作。代理团队蜂拥至代码库，找出哪些功能无法正常工作。为了启动这一过程，最初提出的问题仅说明“构建 Amazon SQS 的第一个版本”。一旦服务被引导启动，代理团队就会重播保真度测试，并为失败的测试提交问题报告。他们被要求分析失败原因，并将可能具有共同根本原因的失败进行分组。
每个问题都被分配给第三个团队中的一名代理，其职责是修复该单一问题。他们签出代码，定位问题的根本原因，并编辑代码直至问题解决。随后，他们的代码更改必须通过一道关卡，以确保其符合我们的标准。这道关卡显然会阻止无法编译的更改。但它还包括由代理执行的审查，用于检查代码是否符合编码规范、验证代码安全性，并确保更改未导致保真度退化。如果任何检查失败，更改将被退回给代理进行返工；如果全部通过，则合并到主分支。每天有成千上万的问题被解决，因为数百名代理并发地在代码库上工作。如果没有这道合并关卡，我们就不会信任代理所构建的内容。我们非常注重优化它，因为它对代理构建的速度和可靠性至关重要。
AWS Emulator 如何发布到 GitHub
合并到主分支后，更改会通过一个完全基于 AWS Developer Tools 构建的发布流水线流动，其中 AWS CodeCommit 作为代理的主要代码仓库。提交通常堆叠在一起，在合并到发布分支之前会被构建和重新测试。然后，我们将模拟器打包为一个可供下载的二进制文件。只有在发布流程的最后阶段，我们才会将代码发布到 GitHub。
三组 AI 代理团队构建 AWS Emulator。
我们将代码发布到 GitHub，以便大家也能看到代理团队在数千次提交中构建此模拟器的过程。仓库中记录了所有提交的问题（issue）。其中已修复的问题位于“issues/things-that-now-work”目录；待处理的问题则位于“issues/things-that-do-not-work”。深入挖掘你会发现许多有趣的内容。随着我们不断优化构建流程，代理团队已经构建了该模拟器的多个版本。我个人最喜欢的是早期版本中的一个：当时他们决定自行开发一个 Python 解释器以支持 AWS Lambda 函数。此后，我们指导他们复用现有库——这对不需要涂色书的人来说或许显而易见。我期待在本版本中看到代理团队提出的其他新颖解决方案。但我对最终结果充满信心，因为我们设置了完善的护栏机制。从这段历史中获得的洞察，正是我们决定以 Creative Commons CC0 许可协议将本软件作为公共领域作品发布的核心理由。
AWS Emulator 的未来展望
这是系列文章的第一篇，我将深入探讨诸如多代理工作流的架构设计、保真度衡量方法以及质量与安全标准的保障措施等话题。
源代码和保真度测试均在 GitHub 上提供。