AWS 用自主 AI 代理开发 AWS Emulator 本地模拟器，三周提交约 900 个问题

本周，云测试领域变得有点奇怪了。嗯，实际上是好多了。

AWS 发布了 AWS Emulator，一个（几乎）覆盖其所有服务的本地模拟器。你把 SDK 或 CLI 指向它，请求就不再发给 AWS，而是发给你笔记本上运行的一个程序。不用账号、不用账单，周一早上也不会有人在 Slack 里问“那个 NAT Gateway 是谁忘了关”。

吸引我注意的是 issues 文件夹。他们把过程中发现的每一个缺口都公开了。不是精选列表。是全部！！！

所以我当然去读了。全部读完。（你疯了吗？我找了帮手，当然是 Claude。神志正常的人不会用自己眼睛去读 137 MB 的 markdown 还能保持清醒。）

让我说说 Claude 帮我找出来的东西里，我挑出了什么。

这大约是每天 900 个 issue。持续了三周。

没有人类团队能每天提交 900 个 issue。也没有人类团队真的这么做了。

AWS 写了自主 AI agent 如何构建 AWS Emulator 的过程，值得一读。它始于一个周末实验。agent 大约 15 分钟就交回了 SQS 的第一个版本，所以下一步自然就是……把 AWS 剩下的全做了。就在那个周末。（公平地说，把它变成真正的产品花了长得多的时间。）

那人类呢？用他们自己的话说：“我们的团队没有编写或审查任何代码。”人类搭建了护栏（测试、issue 流程、合并门禁、发布流水线），然后让 agent 在里面自由运行。

那篇文章里我最喜欢的细节：在早期版本中，agent 需要 Python 来支持 Lambda，于是它们自己构建了一个 Python 解释器。团队不得不介入，告诉它们请直接使用现有的库就好。我和这样的工程师共事过。我可能也曾经是其中之一。

所以这就是为什么每个测试资源都叫 sim2real-something，为什么 issue 是写给“the issue fixer”的。机器人找 bug，机器人修 bug，机器人写非常非常长的描述，两者都写。

而且因为每个测试都先对照真实 AWS 验证过，所以每个 issue 都会把模拟器的行为，与真实 AWS 对同一请求的录制结果做比较。这意味着这些 issue 讲两个故事。一个是关于模拟器的。另一个是关于 AWS 本身的。

每个模拟器都得伪造一些东西。这个模拟器偶尔伪造得特别自信。

Amazon Rekognition 有一个 API 叫 RecognizeCelebrities。你给它一张照片，它告诉你照片里有哪些名人。

模拟器永远返回空列表。每张脸都进了“未识别”堆。

Brad Pitt？未识别。Taylor Swift？没听说过。你？和 Brad Pitt 一样。终于！！

Amazon Transcribe 能检测说的是哪种语言。在模拟器里，答案永远是 en-US。他们用相同设置喂了英语音频和法语音频。两个都返回美国英语，还附带一个自信的分数。

我的希伯来语会被归类为 en-US。我的孩子们会争辩说我的英语不该是。

Application Auto Scaling 有预测性扩缩容。它会查看你的负载历史，预测接下来会发生什么。

对于一个零历史的服务，真实 AWS 会诚实地表示“我不知道”（返回 NaN）。模拟器还是给出了漂亮、有限、数值化的预测。

那不是预测。那是星座运势。（顺便说一句，这个已经修了。）

AWS Backup Gateway 需要来自真实设备的激活密钥才能创建网关。模拟器接受你给的任何字符串，然后创建网关。issue 称之为“phantom gateway”，老实说这是个很棒的乐队名。

IAM 服务关联角色是为 AWS 服务创建的。真实的服务。模拟器乐呵呵地为 sim2real-not-a-real-service.amazonaws.com 创建了一个，还附带了针对这个不存在服务的信任策略。

这个服务的名字里字面写着“not a real service”。它还是拿到了一个角色。我见过门槛比这低的面试。

DescribeInstanceTypes 告诉你每种 EC2 实例类型的规格。在模拟器里，这个目录的一部分是用它自己的公式算出来的，而不是 AWS 公布的值。issue 说基于它做容量规划是“computed from fiction”。

我最喜欢的细节：默认 TCP established 超时。AWS 说是 350 秒。模拟器说是 432,000 秒。那是五天。你的 TCP 连接可以去度个假，回来发现会话还在等它。

在 Kinesis 里，MillisBehindLatest 告诉你落后流有多远。模拟器永远说 0。你永远不落后。永远。我想要我的收件箱也这样。

同一个 issue，附加题：一个带 Kinesis 流的 CloudFormation 栈报告 CREATE_COMPLETE，还给你一个格式完美的 ARN。那个流不存在。下一次调用就当场打脸。

模拟器里有些资源有注定的命运：

永远。这个词就在 issue 标题里。某个地方有一个应用版本还在等待，就像《飞出个未来》里的那只狗。

有几个服务共享签名名称，所以模拟器的路由器有时搞不清你在调用哪个服务。于是它用一个叫 AmbiguousService 的错误拒绝了请求。一个在 AWS 里不存在的错误。

然后是 Sustainability 服务，它用 UnknownService 拒绝了所有请求。Sustainability？没听说过。要我说，这非常符合这个行业的调性。

公平地说，这些现在都修了。但下次开会有人问我一个含糊的问题时，我会用上“AmbiguousService”。

记住，每个 issue 都把模拟器和真实 AWS 的录制结果做比较。所以为了忠实，模拟器必须精确复现 AWS。包括那些没人会故意写出来的部分。

所以机器人现在在小心翼翼地保留 AWS 的拼写错误。

OpenSearch 那个 issue 甚至说这是 AWS 自己的措辞，“grammatical oddity included”（包括语法怪癖）。我喜欢那句话里的克制。

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