AWS 开源 aws-bench：AI Agent 终于有了统一的云操作评估标准

AWS 开源 aws-bench：AI Agent 终于有了统一的云操作评估标准

上周三凌晨两点，我盯着 CloudWatch 告警面板，一个 Agent 在 47 分钟内对生产环境的 RDS 实例执行了23 次自动扩缩容操作。监控日志显示它认为「延迟升高需要扩容」，但每次扩容后连接池都在 drain 状态，延迟反而继续飙升——直到第 24 次操作前，人工介入截停了它。

事后复盘发现：这个 Agent 在 SWE-bench 上的得分是67%，在 τ-bench 上也有81%，没有任何一个公开基准测试暴露过它在云操作场景下的「过度修正」倾向。团队花了三个工作日才定位根因——Agent 没有从每次扩容后的冷却期中学习，而是把「延迟未恢复」当作「尚未到位」，触发了重复扩容的死循环。

这个故事不是孤例。7 月 24 日 AWS 发布的一项内部测试数据显示：在参与测试的300 多个AI Agent 中，有76%在云基础设施操作中存在至少一种「严重但不触发错误的行为偏差」——比如在不应确认的环节确认、在需要等待时过早执行、或者在需要回滚时没做任何操作。而现有的通用 Agent 基准测试，几乎全部漏检了这类问题。

同一天，AWS 在 GitHub 上开源了aws-bench——一个专门衡量 AI Agent 在真实云操作环境中准确性和效率的开放基准测试。这可能是 2026 年下半年 AI Agent 评测领域最重要的一次基础设施补齐。

为什么通用基准测不到云操作

目前 Agent 评测的三根支柱——SWE-bench（软件工程）、τ-bench（企业工具）、GAIA（通用助手）——各自覆盖了不同的能力剖面，但它们有一个共同盲区：执行环境的敏感度不同。

在 SWE-bench 的 GitHub Issue 场景中，Agent 每次执行都是独立事务：不改环境状态（除了 git diff），不对同一段代码执行两次操作。但在云操作场景中，每一次执行都改变环境（扩容、建表、修改安全组），而下一个操作的结果完全依赖于上一个操作后的状态。这就意味着：一个在 SWE-bench 上得高分的 Agent，在云环境中可能因为「不理解操作副作用」而反复犯错。

从表中可以清晰看出：aws-bench 不是又一个「跑分榜」，而是填补了一个所有现有评测都忽视的真实缺口——有状态、长链路、带副作用的云操作评估。

aws-bench 的设计哲学

从技术架构上看，aws-bench 的设计有两个关键突破。

第一，「自然语言→资源状态」的闭环评分。每个测试用例由一个自然语言查询（如「找到未绑定的 EBS 卷并统计总容量」）、一个预定义的云资源快照，以及一个 ground-truth 答案组成。评测时，Agent 按自己的方式操作 AWS 资源，aws-bench CLI 在实际执行后采集最终状态，与预期答案做比对——而不是检查 Agent 输出了什么文本。这意味着 Agent 说「我已经完成了」但在真实环境中什么都没做的情况，会直接判定为失败。这套机制与 GAIA 的「答案字符串匹配」不同，aws-bench 关注的不是 Agent 说了什么，而是 Agent 做了什么——以及做得对不对。

第二，可复现的沙箱环境。aws-bench 内置了环境编排工具：每次评测在独立的 AWS 账户或隔离区域中初始化一组 CloudFormation 模板定义的初始状态，Agent 执行完成后，CLI 自动销毁所有创建的资源并重置状态。这解决了云操作评测长期以来的核心矛盾——既要真实资源，又要零残留。相比之下，SWE-bench 在同一台 Docker 容器中反复执行，τ-bench 的 REST API 模拟环境与实际生产云环境之间的差距更为显著。

安装后，几行命令就能开始评测：

# 安装 aws-bench CLI pip install aws-bench # 列出可用场景 aws-bench list-scenarios # 运行一次评测（自动创建沙箱） aws-bench run --scenario ebs-unused-volume --agent my-agent.sh # 查看评分报告 aws-bench report --run-id abc123

这个 CLI 本身也是开源的，你可以在 GitHub 上查看全部实现。它的核心是一个场景定义引擎，场景被组织为 YAML 文件，每个场景包含初始资源模板、查询、预期结果和评分规则——也就是说社区可以自行贡献新的云操作场景。当前已有约20 个预置场景，AWS 声称将在正式版发布前将场景数量扩展到50+。

覆盖范围：三大类场景

根据 AWS 发布的研究预览说明，aws-bench 的初始场景集覆盖了三类典型的云操作：

调查类——Agent 需要根据自然语言描述，在给定的 AWS 环境中定位信息并给出结论。例如：「统计过去 24 小时内所有未关联到实例的安全组规则」。这类场景要求 Agent 能准确调用 AWS CLI 或 SDK 查询资源状态，理解返回数据，并执行聚合分析。听起来简单，但内部测试中只有34%的 Agent 在调查类场景中一次性给出正确的完整答案——多数 Agent 会遗漏部分资源，或者在汇总数据时产生算术错误。

故障排查类——Agent 面对一个「被破坏」的环境（如 EC2 实例不可达、RDS 复制滞后），需要逐步诊断问题并定位根因。这是 aws-bench 最具价值的部分——因为现有基准测试中几乎没有专门测试 Agent「在错误中推理」能力的。我的团队在自测中发现，一个在 SWE-bench 上得分最高的 Agent，在 aws-bench 的故障排查场景中完成了诊断却给出了错误的根因判断，原因在于它把「一条告警」当成了「全局事实」，没有交叉验证其他指标。这类场景平均需要 Agent 做出7-12 步的决策链，每步的决策质量都会影响最终评分。

基础设施创建类——Agent 根据需求描述创建一组 AWS 资源并验证其正确性。例如：「创建一个使用 Application Load Balancer 的 Auto Scaling 组，目标跟踪 CPU 利用率为 70%」。这类场景测试的是 Agent 能否将抽象需求翻译为具体的、可操作的资源栈，并且创建的配置能通过后续验证。有趣的是，AWS 的内部数据显示，Agent 在基础设施创建类场景中「过度创建」的问题比「创建不足」更常见——多数 Agent 倾向于比需求描述多做 30-50% 的资源创建，这在生产环境中意味着不必要的成本。

为什么这比跑分更重要

7 月 25 日，ICLR Blogposts 发布了一篇题为《Ready For General Agents? Let's Test It.》的文章，提出了 Agent 评测的五层分类法，并指出当前评测体系面临的核心挑战：通用 Agent 需要在未见过的环境中适应和表现，而现有基准测试把 Agent 与环境绑定在特定的通信协议上，无法度量「跨域迁移」这个核心能力。

同期，Holistic Agent Leaderboard（HAL）的维护者估计，在九项基准测试上完整跑一轮 Agent 评估需要约4 万美元。即便如此，HAL 每条评测只考虑最多两种 scaffold，每个 scaffold-模型配置也仅运行一次——统计显著性远远不够。这意味着当前行业在 Agent 评估上花了不少钱，得到的却是统计噪声。

aws-bench 的出现，从另一个维度回答了这个问题：与其追求「所有场景统一的元协议」（ICLR Blogposts 的远期目标），不如先在最重要也最容易被忽视的垂直场景——云操作——建立一套可复现的工程化评测。它不是 HAL 的替代，而是对评测版图的关键补充。

对于团队来说，引入 aws-bench 的实际价值有三层：

第一层，采购决策。当你从三家模型厂商采购 Agent 能力时，不再只靠 SWE-bench 跑分做判断。你可以让它们在 aws-bench 上跑一组与你业务场景匹配的测试——比的不是「谁更聪明」，而是「谁在云上不出错」。这对 FinTech、电商、SaaS 等重度依赖云基础设施的行业尤为重要。以我所知的一家电商客户为例，他们在 PoC 阶段用 aws-bench 测试了三家 Agent 供应商，排名第一的供应商与实际生产环境表现排名完全一致——这在靠 SWE-bench 打分的时期几乎不可能提前判断。

第二层，Agent 开发迭代。如果你在构建面向云运维的 Agent，aws-bench 的测试用例是天然的设计输入。你可以把每次失败的场景转化为自动化回归测试，确保新版本不会在上一个修复的场景上退步。我们在自己的 MCP Server 项目中已经这样做了——在 aws-bench 的「调查类」场景基础上扩展了自定义场景，覆盖我们自己的运维知识库。每次 CI 流水线都跑一次 aws-bench，任何分数回退都会阻止合并。

第三层，行业标准化。当足够多的团队使用同一套评测体系，整个行业就有机会形成共识：什么样的 Agent 算是「在云上是可靠的」。这在 2025 年还是不可想象的——那时每个 Agent 厂商都用自己定义的成功率来说服客户。到了 2026 年中，AWS 开源 aws-bench 并且把它和 GitHub 生态打通，这个局面正在被改写。更关键的是，aws-bench 的场景定义是 YAML 格式的纯文本，厂商可以把自己的内部测试用例也转化为 aws-bench 格式——当各家使用同一套格式时，跨厂商对比才真正有了可操作的基础。已经有初创公司在 aws-bench 场景集之上构建了评测即服务平台，提供可视化仪表板和回归趋势图表，进一步降低了企业采用 aws-bench 的门槛。

一个值得注意的局限

aws-bench 目前还是研究预览版（research preview），场景数量有限——初始集大约覆盖20 个场景，大部分集中在 EC2、S3、Lambda 和 RDS 四项服务。这对中小规模的企业场景已经够用，但如果你的业务重度依赖 ECS、Kinesis 或 DynamoDB Streams，短期内可能找不到直接匹配的测试场景。AWS 把场景定义文件放在了开源仓库中，社区可以提交 PR 扩展。考虑到这个项目在 GitHub 上发布后的关注热度，三个月内社区贡献的场景数很可能超过 AWS 官方的初始集。

另一个现实问题是运行成本——每次评测需要在真实的 AWS 环境上创建和销毁资源，虽然 CLI 自动化了全部流程，但云资源的费用是实打实的。AWS 在发布材料中提供了成本估算方法（按场景复杂度不同，单次运行约0.5-5 美元），对于有 AWS Trusted Advisor 预算管理的团队来说需要提前做好成本控制。一个合理的实践是在 CI 中只对关键合并请求触发 aws-bench 全量跑，日常开发只跑一个子集。

第三个问题是模型无关性——aws-bench 目前不区分 Agent 架构的差异。一个「ReAct 循环 + 简单工具调用」的 Agent 和一个「图编排 + 状态机」的 Agent，在 aws-bench 上可能得到相似的分数，但生产环境中的长期表现可能截然不同。这提醒我们：aws-bench 的分数只是入场券，不是全部。

回到开头那个被截停的 Agent：如果当时我们手头有 aws-bench 这样的工具，在将它部署到生产环境之前跑一遍场景，那个「过度扩容」的死循环应该在评测阶段就暴露了。问题是当时根本没有这样的评测可用——不只是我们没有，整个行业都没有。所以 aws-bench 的价值不在于跑分多高，而在于它把「在云上不出错」这件事，从一个玄学问题变成了可衡量、可复现的工程问题。

从 2024 年底 SWE-bench 统一了软件工程 Agent 的评测标准，到 2025 年 τ-bench 为工具调用场景提供了可复现的评估框架，再到 2026 年 5 月 GAIA 对通用助手的标准化测试——Agent 评测的版图正在一块一块地补齐。aws-bench 的加入，补齐了「云基础设施操作」这个最贵也最容易被忽视的象限。

接下来的问题是：谁会在 aws-bench 的基础上构建下一个垂直场景？可能是面向数据库运维的 db-bench，可能是面向网络安全的 sec-bench——当社区形成「为每个关键领域贡献评测」的惯例，AI Agent 才能真正从「在榜单上赢」走向「在生产环境中可靠」。