AWS 开源 aws-benchAI 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在云环境中可能因为「不理解操作副作用」而反复犯错。维度SWE-benchτ-benchGAIAaws-bench操作独立性✅ 完全独立✅ 部分独立✅ 完全独立❌ 状态依赖环境副作用检测❌ 不检测❌ 不检测❌ 不检测✅ 核心指标真实云资源操作❌ 无❌ 无❌ 无✅ EC2/Lambda/S3故障恢复场景❌ 无少数❌ 无✅ 核心场景多步依赖链短链3-5步中链5-8步短链长链10步从表中可以清晰看出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? Lets Test It.》的文章提出了 Agent 评测的五层分类法并指出当前评测体系面临的核心挑战通用 Agent 需要在未见过的环境中适应和表现而现有基准测试把 Agent 与环境绑定在特定的通信协议上无法度量「跨域迁移」这个核心能力。同期Holistic Agent LeaderboardHAL的维护者估计在九项基准测试上完整跑一轮 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 开发迭代。如果你在构建面向云运维的 Agentaws-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 才能真正从「在榜单上赢」走向「在生产环境中可靠」。