AI 模型与平台
AWS 发布完全由自主 AI 智能体编写的本地模拟器
将 Unite.AI 添加到您在 Google 上的首选来源
AWS 于2026年11月11日发布了 AWS Emulator。这款本地模拟器已正式推出，基于438个 AWS API 模型构建，涵盖200多项服务。自主式 AI 代理编写并测试了它的代码，让开发者和编程代理无需 AWS 账户，就能在自己的机器上调用 AWS API 进行测试。
AWS CLI、AWS SDK 和编程代理通过本地 HTTPS 端点连接，使用的 API 与云端相同。环境变量会将这些工具的请求重定向到用户的机器上，无需改动应用程序代码。AWS 发布公告详细介绍了适用于 Linux 的 RPM 和 Debian 软件包、适用于 macOS 和 Windows 的 Docker 版本，以及供 Rust 测试使用的嵌入式模式。这项服务不收取额外费用，但客户仍须为部署在云端的 AWS 资源付费。
对于编程代理而言，这款模拟器将 AWS 基础设施纳入“编写—运行—读取”的循环：代理可以创建资源、检查结果并修改代码，无需等待将资源部署到 AWS 区域。AWS 文档还将开发服务器和持续集成列为该模拟器的适用环境；在这些环境中，请求会发往模拟资源，而非 AWS。
三个智能体团队分工构建和维护代码
AWS 高级首席工程师 Matthew Goldberg 在一篇工程实践文章中表示，他的团队既没有编写也没有审查这款模拟器的代码。相反，团队中的人员为这项工作搭建了配套框架，包括规范、测试机制、合并门禁和发布流水线。项目起步于 Kiro 编程代理：收到一条提示，要求编写测试、用真实 AWS 验证测试，并构建一个能通过这些测试的内存实现后，它在大约15分钟内就生成了一款尚可使用的 Amazon SQS 模拟器。随后，Goldberg 让 Kiro 在一个周末内扩展这个原型；要将其打造成稳健的产品，还需要配套的防护机制。
如今，三支职责边界明确的代理团队分工协作。测试编写代理根据公开 API 模型设计测试场景，并在真实的AWS环境中验证这些场景。问题排查代理会重新运行测试，并将可能有相同根本原因的故障归类；修复代理则各自负责一个问题。Goldberg 表示，目前已有数万个保真度测试；数百个代理并行工作，每天能修复数千个问题。
每项拟议的修复都必须通过编译，并在合并前通过针对编码规范、安全性和保真度的自动检查。独立的安全智能体会在开发期间以对抗性方式审查更改，并在发布流程中再次审查。Goldberg 写道：“没有这道合并关卡，我们就不会信任智能体正在构建的东西。”
变更随后经由 AWS CodeCommit 和 CodePipeline 流转，之后发布到 GitHub。公开代码库展示了提交历史，并设有分别存放已解决和未解决保真度问题的文件夹。AWS 以 CC0 公共领域贡献声明发布代码，但供应商代码采用 Apache 2.0 许可；该代码库不接受拉取请求，不过用户可以通过 GitHub Issues 报告错误和保真度缺口。
保真度评分界定能力边界
保真度测试是一段与真实 AWS 对照验证的简短工作流。要通过测试，模拟器必须对每次调用都给出与真实 AWS 相符的响应，包括状态码、响应正文以及准确的错误代码和错误消息，还必须创建相同的资源和数据。尚未实现的操作会返回 HTTP 501（未实现），因此失败会立即显现。每次发布都会附上各项服务的通过测试数量；AWS 提醒，即使模拟器有所改进，新增测试也可能拉低评分。
公开评测套件中的每项测试都至少在两个经过沙箱隔离的 AWS 账户中验证过；代码库也明确说明，未经测试的行为尚未得到验证。
这些评分并不意味着这款模拟器可用作安全测试环境。它不会像 AWS 那样评估 AWS 身份与访问管理（IAM）或基于资源的策略，因此，AWS 会拒绝的请求在本地可能会成功。该模拟器适用于构建和测试；生产工作负载和应用安全测试不在适用范围内。每个实例都面向单个账户和区域，资源保存在内存中，并会在实例停止时删除。
工程工作转向规格说明和测试
在发布文章中，Swaminathan Sivasubramanian 将工程师的职责描述为：确定要构建什么，并制定规格说明、测试和合并关卡，以判定结果是否正确；与此同时，智能体负责编写和检查代码。
他将其与 Alf（一种早期的 Amazon 分布式锁服务）进行比较，给出了一个具体例子。最初的复制引擎花了约四个月才建成。Sivasubramanian 表示，使用 Kiro 重建时，起初花了四个有人监督的夜晚，因为智能体无法检查自己的结果；在他提供规格说明和测试环境后，重建只花了约两个小时。
AWS Emulator 将这一经验转化为正式发布的产品：智能体负责生成和修复实现，工程师则负责定义可接受的行为，并自动落实相关要求。它目前的实际适用范围取决于不断扩大的公开测试套件以及仍然存在的保真度差距；安全性和生产环境验证仍需在真实 AWS 上进行。
