AREX Feed Article
AWS 发布免费本地工具 AWS Emulator，官方称全部代码由自主 AI 代理编写、未经人工审查
当地时间 11 月 11 日（周三），AWS 发布了免费工具 AWS Emulator：一个跑在开发者自己机器上的 AWS 服务模拟器，由 400 多个 API 模型构建，覆盖 200 多项 AWS 服务。开发者和 AI 编码代理不用联网、不用为真实云资源付费，就能在上面测试代码。AWS 高级首席工程师（senior principal engineer）Matt Goldberg 在发布当天的中写道：“该模拟器完全由自主代理编写。我们的团队没有编写或审查过任何代码。” 在当日报道中指出，AWS 把这件事本身当作卖点来宣传。
模拟器已按 CC0 许可（公有领域贡献）发布在 GitHub，完整提交历史和代理提交过的每一个 issue 一并公开；Goldberg 称，目前有数百个代理并行工作，每天修复数千个问题。以上进展与数字均出自 AWS 官方博客的单方口径，经 GeekWire 等媒体转述，尚无独立验证。
起点是一个周末实验：15 分钟做出 Amazon SQS
Goldberg 在博客中把想法的源头追溯到 ：16 个 Claude 代理在几乎无人干预的情况下，经过近 2,000 次 Claude Code 会话、花费 2 万美元 API 费用，从零写出一个 10 万行的 Rust 版 C 编译器，能构建 Linux 6.9 内核。这让他提出一个假设：只要给代理一份明确的行为规格和一份参照实现，它就能自主构建出忠实实现该规格的方案。AWS 两样都有——用 AWS 接口描述格式 Smithy 编写的公开 API 模型（描述每个服务的操作及其输入、输出和错误）是规格，真实 AWS 云本身就是参照实现。
为了验证假设，他给 Amazon 的 Kiro 编码代理一个三步提示：基于 AWS CLI 编写测试；反复迭代，直到这些测试对真实 AWS 全部通过；再构建一个内存实现，让同一组测试对它也通过。15 分钟后，Kiro 交出了第一个尚可使用的 Amazon SQS（消息队列服务）版本。Goldberg 随即细化提示，让 Kiro 在周末把“其余的 AWS”也建了出来。漏洞明显，但已够用——他的团队周一就开始用它测试自己的软件。
Goldberg 同时提醒，把周末原型变成敢交给客户的产品仍需要认真的工程投入，核心是搭建护栏，确保代理“不涂出格线”。他把自己比作幼儿园时的自己——因为年龄小、握不好蜡笔，把全班合作的恐龙群像画坏了，被同学们吼。他由此得出的结论是：“我认为代理也需要涂色书。”
三组代理如何分工，又如何互相把关
据 GeekWire 报道，这些代理运行在 Amazon Bedrock AgentCore 上。Goldberg 的博客给出了分工细节：第一组编写“保真度（fidelity）测试”，从公开 API 模型出发设计真实场景——例如对 SQS 创建队列、发送消息、接收、确认、删除队列——每条测试先对真实 AWS 验证通过，再存入共享的 CodeCommit 仓库。目前这套测试已有数万条，可以在不调用真实 AWS 的情况下反复重放，是整个体系最基本的护栏之一。
第二组把保真度测试重放到模拟器上找差距。按 Goldberg 的描述，系统最初生成的只是一个能响应 438 个 AWS API 模型请求、但什么都不做的空 Web 服务器；代理们从一句“构建 Amazon SQS 的第一版”起步，之后不断重放测试、按根因归并失败项并提交 issue。第三组一个代理认领一个 issue，修改代码直到修复，再通过合并门（merge gate）：编译检查、编码规范审查、安全审查、保真度回归，任何一项不过就打回重做，全部通过才并入主线。
Goldberg 写道：“没有这道合并门，我们不会信任代理构建的东西。”合并后的代码经构建在 AWS Developer Tools 上的发布管线打包成可下载的二进制，代码最后才发布到 GitHub。这套方法为何可行，AWS 主管代理式 AI 与新兴技术的副总裁 Swami Sivasubramanian 在 里给出过一个亲历样本：约 20 年前，他和 Amazon 早期工程师 Al Vermeulen 手工构建分布式锁服务 Alf 的复制引擎花了约 4 个月；今年他用 Kiro 重建它，盯了四个晚上才发现代理根本没有办法核对自己的结果——一旦给了规格和测试环境，重建只用了约 2 小时。“当代理写代码、自己检查自己的工作时，工程师的职责是给它们独立工作的空间，并搭好规格、测试和合并门，由这些来判定工作何时正确。”他在文中写道。
开发者怎么用：把 AWS 端点指到本机
据 报道的 AWS 声明，模拟器在本机复刻 AWS 服务的 API，暴露一个本地 HTTP 端点，AWS CLI、各类 SDK 和编码代理用与访问真实云端相同的 API 访问它。开发者把 AWS_ENDPOINT_URL 环境变量指向本地端点，现有应用代码和测试无需修改即可运行在模拟服务之上。工具可免费下载，支持 Linux、macOS 和 Windows，用 Rust 编写以降低 CPU 和内存占用。
GitHub 仓库的 README 补充了更多细节：不需要 AWS 账号；Linux 上安装 RPM 或 Debian 包运行，Windows 和 macOS 走 Docker；另有内嵌模式，把模拟器编译进 Rust 测试二进制。本地端点是 127.0.0.1:9297 上的 HTTPS（自签名证书）；从源码构建需要至少 100 GB 的空闲磁盘，因为每个 AWS 服务对应一个 crate（Rust 的编译单元）。面向编码代理的接入方式是安装 aws-emulator 技能包，要求 AWS CLI 2.35.0 或更高版本。README 同时写明：这个工具面向构建和测试，不要用于生产负载或安全测试；遥测默认开启，可用 --telemetry off 关闭。截至 11 月 12 日发稿，aws/aws-emulator 仓库已有约 2,800 个 star。
这类工具瞄准的痛点，GeekWire 概括得很直接：Kiro、Claude Code 这类编码代理写代码的速度已经超过团队对真实云做测试的速度，而代理靠“写代码—运行—读结果”的循环自查，每一轮都打到真实云上，就叠加了延迟和费用。Broadcom 高级站点可靠性工程师（SRE）Advait Patel 对 InfoWorld 说：“代理的工作是个循环：写代码、运行、看报错、修复、再来。如果每一轮都打到真实 AWS，你要等预置、为资源付费，还要清理代理忘了删的东西。把这个循环挪到笔记本上，每一轮的时间从几分钟降到几秒。”
同类产品收紧免费档，AWS 反向选择 CC0 完全公开
本地模拟 AWS 并非新事物。据 GeekWire 介绍，第三方 AWS 模拟器中最为知名的是 LocalStack。据 ，它已在 2025 年 12 月宣布：自 2026 年 3 月起，LocalStack for AWS 统一为需要注册账户、凭 auth token（访问令牌）运行的单一版本，免费档限定非商业用途，社区版不再获得定期更新。AWS Emulator 则不要求注册账户，仓库整体以 CC0 1.0 发布，仅 vendor/ 目录的框架代码为 Apache 2.0。Goldberg 在博客中说，这是该系列的第一篇，后续还会展开多代理工作流的架构和保真度的度量方式；AWS 也表示将在即将召开的 re:Invent 大会上分享更多。
公开的缺口清单，以及“本地通过”的风险
模拟器的能力边界写在公开仓库里：GitHub 仓库的 issues 目录中，已修复的问题放进 issues/things-that-now-work，尚未修复的待办就挂在 issues/things-that-do-not-work；每次发布还随附各服务的保真度得分。按 InfoWorld 报道的 AWS 声明，AWS 通过把模拟器的 API 响应与真实 AWS 对比、并检查多步工作流是否符合预期来度量保真度，未实现或未验证的操作会返回 HTTP 503，而不是被当作成功。
IDC 研究总监 Devin Pratt 对 InfoWorld 指出，发布时的模拟器不模拟限流（throttling）、停机故障、快照与恢复以及各 Region 的可用性差异，而这些恰恰对系统韧性最重要；它也不隔离（sandbox）所运行的代码——如果被测函数里带着真实生产凭证，代码仍可能访问真实 AWS 资源。Patel 把话说得更直白：“从 SRE 的角度看，限流、部分故障和区域差异正是把生产系统搞挂的东西。如果你的测试从没见过 429 或超时，你的重试和退避逻辑就从未被测试过。所以是的，确实存在假信心风险，尤其是当团队开始把‘本地通过’当作‘可以上线’的时候。”他的结论是：部署到生产之前，仍要在真实云环境里验证应用。