AWS 发布 aws-bench：用真实云任务评估 AI Agent 的基础设施能力

预计阅读时间：11 分钟

评估云领域 AI Agent，不能只看它是否生成了一段看起来正确的 Terraform 或 AWS CLI 命令。真正困难的地方在于：Agent 是否理解任务约束，能否在真实环境中完成资源配置，是否会留下安全风险，以及遇到错误后能否恢复。AWS 最近发布的开源基准 aws-bench，正是针对这类问题设计的。

从文本题目转向真实 AWS 任务

传统 Agent 基准通常把任务简化成问答、代码生成或静态规划。例如，让模型输出一个 S3 Bucket 配置，或者解释某条 IAM Policy 是否安全。这些测试可以衡量语言和推理能力，却无法充分反映云环境中的实际工作质量。

aws-bench 的核心思路是把评估放进真实 AWS 任务中，覆盖两类具有代表性的场景：

发现并修复云资源中的错误配置。
根据任务要求完成基础设施 provisioning。

这意味着 Agent 的输出不再只是文本，而是会影响实际资源。评估系统需要检查资源是否创建成功、配置是否符合要求、权限是否过宽、网络是否可达，以及任务结束后环境是否处于预期状态。

这种方式更接近工程团队使用 Agent 的真实过程：Agent 读取上下文，调用云 API 或命令行工具，观察执行结果，根据错误调整方案，然后接受自动化验证。

一次评估为什么需要 disposable AWS account

在真实 AWS 账户中直接运行 Agent 存在明显风险。Agent 可能创建高成本资源、修改生产配置、扩大 IAM 权限，或者因为清理失败留下长期运行的实例。因此，隔离环境是这类基准能够落地的前提。

aws-bench 使用 disposable AWS accounts，也就是一次性或可重置的 AWS 账户来承载测试资源。一个典型流程可以抽象为：

创建或选择一个隔离账户。
部署测试任务所需的初始资源和错误状态。
为 Agent 提供任务描述、凭证范围和可用工具。
允许 Agent 在限定环境中执行操作。
使用自动化 verifier 检查最终状态。
记录得分、失败原因和资源清理结果。

这里的关键不只是“账户隔离”，还包括权限隔离和成本控制。测试角色应只获得完成任务所需的权限，账户需要配置预算、服务配额和自动清理策略。对于涉及 EC2、RDS 或 NAT Gateway 的任务，还应该设置超时和强制回收机制。

自动化 verifier 决定了评估是否可信

如果只根据 Agent 的最终文字回答打分，评估结果很容易失真。Agent 可以声称任务已经完成，但真实资源可能不存在；也可以创建出一个能工作的资源，却违反了加密、网络隔离或最小权限要求。

自动化 verifier 应该直接读取 AWS 的实际状态，并将结果映射为明确的评分项。比如，一个基础设施任务可以拆成以下检查：

目标资源是否存在。
资源名称、区域和标签是否符合约束。
加密是否启用。
公网访问是否被禁止。
IAM 权限是否限制在指定资源范围。
应用端点或依赖服务是否能够正常工作。
不应存在的临时资源是否已经清理。

下面是一个可以改造成测试 verifier 的 Python 示例。它假设任务要求一个指定名称的 S3 Bucket，且 Bucket 必须启用默认加密，并明确关闭公共访问。运行前需要配置 AWS 凭证和区域；不要在生产账户中执行。

import os
import boto3
from botocore.exceptions import ClientError

BUCKET_NAME = os.environ["BENCH_BUCKET_NAME"]
REGION = os.getenv("AWS_REGION", "us-east-1")

s3 = boto3.client("s3", region_name=REGION)


def check_bucket() -> dict:
    result = {
        "bucket_exists": False,
        "public_access_blocked": False,
        "default_encryption_enabled": False,
    }

    try:
        s3.head_bucket(Bucket=BUCKET_NAME)
        result["bucket_exists"] = True
    except ClientError:
        return result

    try:
        public_access = s3.get_public_access_block(Bucket=BUCKET_NAME)
        config = public_access["PublicAccessBlockConfiguration"]
        result["public_access_blocked"] = all(
            config.get(key, False)
            for key in (
                "BlockPublicAcls",
                "IgnorePublicAcls",
                "BlockPublicPolicy",
                "RestrictPublicBuckets",
            )
        )
    except ClientError:
        pass

    try:
        encryption = s3.get_bucket_encryption(Bucket=BUCKET_NAME)
        rules = encryption["ServerSideEncryptionConfiguration"]["Rules"]
        result["default_encryption_enabled"] = bool(rules)
    except ClientError:
        pass

    result["score"] = sum(
        int(value) for key, value in result.items() if key != "score"
    )
    return result


if __name__ == "__main__":
    print(check_bucket())

这个例子的重点是 verifier 不判断 Agent 说了什么，而是查询 AWS 的最终状态。实际基准还可以将每个检查设置不同权重，例如安全约束比资源命名更重要；也可以把“任务完成”和“清理完成”分开计分，避免 Agent 只追求创建成功而忽略后续风险。

对 Agent 评估方式的影响

aws-bench 代表了一种更贴近生产的评估方向：测试对象从“模型能否生成答案”变成“Agent 能否在受控环境中完成闭环任务”。这会带来几个变化。

第一，工具调用质量会变得和语言能力同样重要。Agent 需要正确选择 AWS API、处理返回值、识别权限错误，并在状态变化后重新检查，而不是一次性生成一大段命令。

第二，错误恢复能力需要被单独观察。云任务经常因为资源尚未就绪、参数冲突、区域限制或权限不足而失败。一个可靠的 Agent 应该能区分可重试错误与配置错误，避免无休止地重复执行。

第三，安全性不应只是额外加分项。为了完成任务而临时授予 AdministratorAccess，或者把资源设置为公开访问，可能会让成功率看起来更高，却无法满足生产要求。verifier 必须把这些行为纳入硬性约束。

第四，成本和清理能力也属于 Agent 的工程质量。真实云环境的失败并不总是发生在任务执行期间；资源残留、快照堆积和未释放的弹性 IP 同样会造成后续影响。

落地时需要明确的边界

aws-bench 使用真实资源，这使结果更有参考价值，也带来了比纯模拟环境更高的运营成本。团队在采用类似方法时，应提前定义以下边界：

账户隔离：测试账户不能与生产组织权限混用。
凭证范围：为每个任务生成短期、最小权限凭证。
资源上限：限制实例类型、数量、区域和可调用服务。
时间上限：任务超时后立即停止 Agent 并触发清理。
成本监控：配置预算告警，并定期检查残留资源。
验证一致性：verifier 应是确定性的，避免因为最终一致性或时间窗口造成随机得分。
可复现性：保存任务初始状态、Agent 工具调用、AWS 返回结果和最终验证结果。

对于早期实验，可以先从低成本、可快速清理的 S3、IAM、Lambda 或 CloudFormation 任务开始，再逐步加入网络和计算资源。这样既能覆盖真实 API 交互，也能控制测试风险。

结语：评估 Agent，必须观察它改变了什么

aws-bench 的价值在于把云 Agent 的评估从静态输出带到了真实执行结果。一个 Agent 是否优秀，不仅取决于它能否提出合理方案，还取决于它是否能安全地改变云环境、验证结果、处理失败并完成清理。

如果团队正在建设 AWS Agent，建议把以下指标纳入内部测试：任务成功率、首次执行成功率、错误恢复次数、安全约束通过率、资源残留率和单任务成本。只有当这些指标同时达到要求时，Agent 才具备进入更高风险云工作流的基础。