CloudOpsBench v1.0 榜单:Claude Fable 5.1 云运维解决率仅 60.6%

一句话结论:把当前最强的智能体放进真实的 AWS 云运维任务里,最高成绩也只有 60.6%,剩下接近四成的任务必须由人接手。

2026 年 10 月 26 日,一个名为 CloudOpsBench 的开源基准把 v1.0 分支合并进主分支,几天后它的官网放出了第一批完整榜单。榜单上的名字很热闹:Claude Fable 5.1、GPT-6 Astra、Gemini 4 Argon、Grok 4.7、Qwen3.8-Max、DeepSeek V4.1 Flash、Kimi K3.1 Pro,一共 18 条配置横排在同一张表里。但真正刺眼的是第一名的分数本身。

60.6%。这意味着即使是最贵的一档推理配置配上最顺手的命令行外壳,智能体在真实云环境里依然有四成任务做不对。而榜单的另一端,DeepSeek V4.1 Flash 只有 21.8%,Kimi K3.1 Pro 只有 19.1%。

这个基准到底考了什么

CloudOpsBench 由 CloudOpsBench 组织在 GitHub 上开源,采用 Apache 2.0 许可,仓库创建于 2026 年 9 月 15 日,目前 75 个 star、3 个 fork。任务全部围绕 AWS 环境展开,一共 45 个任务,覆盖四类典型运维动作:资源下线(decommission)、数据迁移(migration)、配置变更(config changes)和故障修复(incident fixes)。

任务形态和常见的 SWE 类基准差别明显。它不要求智能体改一段代码让测试通过,而是要求智能体在真实 AWS 资源上执行动作:把一个已经结束的定价实验连同它留在共享桶里的查询结果一起清干净,把试点数据集从 S3 桶迁移到团队共享桶并让源桶保持为空,修好 prod-vpc 里应用服务器连数据库超时的问题,把 CloudWatch 订单错误告警的阈值从 1000 降到 100 以便更早呼叫值班,或者把一个继承了 DynamoDB Streams 毒丸消息的修订版消费者修到能原子投影。

每个任务都带四样东西:初始化环境的 setup 脚本、给智能体看的 instruction.md、自动检查脚本 tests/check.py,以及一份参考解 solution/solve.sh。执行契约写得很清楚:任务渲染成 runner 形态,setup 建立状态,智能体动手,grader 判分,结果只有三种可能,通过记 1,明确失败记 0,setup 或校验器自身出错则记为无有效奖励。任务逻辑与检查脚本不随环境变化,用 AWS 模拟器(比如 Vera)跑和用真实 AWS 账号跑是同一套。

榜单全貌:18 条配置,没有一条超过六成

下表是 CloudOpsBench v1.0 榜单的完整配置与成绩,模型后括号内是推理档位,harness 指驱动智能体的命令行外壳。

排名 模型与档位 驱动外壳 解决率 耗时 Token 成本
1 claude-fable-5-1 (max) claude-code 60.6% 38.6h 97.9M $404.3
2 gpt-6-astra (max) codex 58.9% 16.5h 98.0M $310.9
3 gemini-4-argon (high) gemini-cli 57.5% 34.2h 173.9M $100.5
4 grok-4.7 (high) cursor-cli 56.5% 33.2h 178.3M $138.8
5 gpt-6-astra (high) codex 54.2% 16.1h 62.4M $188.4
6 grok-4.7 (high) grok-build 48.3% 25.9h 173.4M $127.3
7 claude-opus-5-5 (high) terminus-2 47.8% 19.5h 22.6M $45.1
8 claude-opus-5-5 (high) claude-code 46.7% 14.0h 37.4M $36.6
9 claude-fable-5-1 (high) terminus-2 43.8% 19.0h 37.3M $319.1
10 gemini-3.8-flash (high) terminus-2 42.8% 33.2h 337.4M $70.0
11 gpt-6-astra (high) terminus-2 42.8% 12.9h 19.2M $94.6
12 grok-4.7 (medium) grok-build 40.0% 21.4h 121.6M $91.6
13 grok-4.6 (high) cursor-cli 39.7% 19.7h 78.2M $63.8
14 grok-4.6 (medium) grok-build 36.7% 16.2h 59.4M $51.2
15 grok-4.6 (high) grok-build 36.1% 17.7h 72.0M $61.7
16 qwen3.8-max (high) terminus-2 33.7% 79.1h 78.4M $61.8
17 deepseek-v4.1-flash (high) terminus-2 21.8% 22.2h 68.1M $7.5
18 kimi-k3.1-pro (high) terminus-2 19.1% 14.8h 7.4M $10.7

18 条配置横跨 8 个模型家族、6 种驱动外壳。如果只看最高分,智能体在云运维这件事上大概刚过及格线。

换一层外壳,分差能到 16 个百分点

榜单里最值得琢磨的一处细节,是同一个模型在不同外壳下的落差。

GPT-6 Astra 的 max 档配 codex 拿到 58.9%,降到 high 档仍是 54.2%,换成 terminus-2 直接掉到 42.8%,最高与最低之间差 16.1 个百分点。Claude Fable 5.1 也是同样的形状:max 档配 claude-code 是 60.6%,high 档配 claude-code 只有 46.7%,同样两个外壳,仅仅把推理档位从 max 调到 high 就掉了 13.9 个点。Grok 4.7 方面,high 档配 cursor-cli 是 56.5%,配 grok-build 只有 48.3%。

这组数据把一件事摆得很清楚:模型能力和工程外壳共同决定了智能体在运维场景的实际表现。GPT-6 Astra 此前在 BenchCAD 硬件设计基准上拿下 0.594 分,展现了很强的空间与结构推理能力,那类能力在写代码和做结构设计上是加分项,换到需要精确操作 AWS API、并且不能误伤其他工作负载的运维任务上,优势就被大幅稀释。

另一个细节是耗时。榜首的 claude-fable-5-1 (max) 花掉 38.6 小时才做完一轮,是 Claude Opus 5.5 那条 14.0 小时的将近三倍。而 Qwen3.8-Max 的 high 档用了 79.1 小时,是全榜最慢的一条,代价只有 33.7% 的解决率。慢和强的关联并不成立。

便宜不等于弱,关键看怎么用

如果按单位成本的有效产出重排,榜单会换一个样子。

Claude Opus 5.5 (high) 配 terminus-2 的成本是 $45.1,解决率 47.8%,只消耗 22.6M token,是全榜倒数第三便宜的一档,成绩却排到第七。Claude Opus 5.5 配 claude-code 更省,$36.6、37.4M token、46.7%,成本在榜单上处于最低区间。Claude Opus 5.5 在 Terminal-Bench 这类终端基准上的表现此前就显示出明显分化,云运维榜单同样印证了这一点:高档位不是必需的,够用的档位加上对的工具链,效果可能更划算。

另一端则是另一种逻辑。Kimi K3.1 Pro 只花了 $10.7 和 7.4M token,成本全榜最低,代价是 19.1% 的解决率。Kimi K3.1 Pro 在 Terminal-Bench 4.0 上拿到 65.7% 的成绩,但换到云运维就跌到两成,说明榜单衡量的是特定能力组合,跨基准的高分并不能直接迁移。

DeepSeek V4.1 Flash 的曲线最典型:$7.5 的成本全榜最低,解决率 21.8%。DeepSeek Super-agent 的实测显示,模型的调度与工作流编排能力是影响端到端效果的独立变量,纯粹的模型分数在长链条的运维任务里会被明显稀释。

基准本身还在早期

读这份榜单之前,得先知道它有多新。仓库主分支在 2026 年 10 月 26 日合并 v1.0,10 月 8 日才把许可证从 MIT 换成 Apache 2.0,11 月 4 日还有一次修复提交,针对的是紧急告警资源身份校验的问题。也就是说,榜单对应的代码本身在两周内还在改。

仓库 README 里写得很坦白:45 个任务中,最近加入的 42 个尚未用 oracle 解答和 negative control 跑过完整验证;静态校验通过不等于任务端到端可执行。3 个任务依赖 Terraform,需要平台提供 AGENT_WORKSPACE、Terraform 以及离线 provider 镜像。另有 2 个任务自带受限权限描述文件 agent_policy.json,而 runner 目前尚未真正应用这些权限约束。仓库还专门提醒,不要把真实 AWS 凭证交给模拟器容器,任务会修改和删除资源并产生账单。

榜单页面本身提供按解决率、发布时间、耗时、token、成本五种排序。耗时和成本这两列的存在很关键,它意味着评价标准不只有做没做成这一项,还包括为做成付出了多少。这套思路和 OpenAI LifeVal 用最低分而非平均分刻画模型能力下限的做法属于同一个方向:把单一分数换成可拆解的多维账本。

常见问题

CloudOpsBench 的 60.6% 是什么口径

它是 45 个 AWS 任务上的通过比例,grader 明确判失败记 0,setup 或校验器自身出错记为无有效奖励。榜单统计的是有效执行下的解决率,不是模型回答的正确率。

当前最适合上生产运维的智能体配置是哪一条

从成本与成绩的平衡看,Claude Opus 5.5 (high) 配 claude-code 或 terminus-2 是最划算的两条,成本在 $36.6 到 $45.1 之间,解决率 46.7% 到 47.8%,耗时也低于榜首配置。如果要追最高分,claude-fable-5-1 (max) 配 claude-code 是 60.6%,代价是 $404.3 和 38.6 小时。

这个基准能说明智能体运维能力的上限吗

不能。它测的是 AWS 单云环境下的资源类运维动作,任务的 destructive 程度被刻意控制住,不含跨云编排、数据库内核调优、Kubernetes 集群控制面变更等复杂场景。加上 42 个任务尚未完成完整验证,榜单数字更适合作为横向参考而非能力上限的判定。

小结

CloudOpsBench 的价值不在于给出一个谁更强的答案,而在于它把智能体运维这件事从模糊的印象变成了可以计量的账本。四成任务做不成、换外壳差 16 个点、便宜的小模型未必弱,这些结论都能被复查。榜单上 75 个 star 的项目还处在验证阶段,它给出的分数随时会变,但把成本、耗时、token 三列一起摆出来这种评测方式,值得长期跟踪。

相关阅读