Terminal-Bench 4.0 评测解读：Sonnet 5.5 与 Opus 4.7 在 DevOps 终端任务中的选型实践

1. 从 Terminal-Bench 4.0 的分数异动说起

Terminal-Bench 这个评测集在 DevOps 圈子里一直是个挺特殊的存在。它不像那些跑分软件一样只看模型能不能答对题，而是把模型丢进一个真实的终端环境里，让它去完成一系列运维任务——装包、改配置、排查服务、写脚本、处理文件权限。说白了，它测的是"这个模型能不能真的帮你干活"，而不是"这个模型能不能背出答案"。

最近 Terminal-Bench 4.0 的榜单出来之后，Sonnet 5.5 的成绩引起了不少讨论。有人说是"倒反天罡"，意思是它在某些维度上反超了定位更高的 Opus 系列。这个说法有点夸张，但背后确实反映了一个值得聊的现象：在终端操作这类任务上，模型的能力排序和它在通用对话、代码生成上的排序并不完全一致。

我自己这段时间在几个实际项目里同时用了 Sonnet 5.5 和 Opus 4.7 来做 DevOps 相关的辅助工作，包括写 Ansible playbook、调试 Docker 网络、处理 systemd 服务依赖、写 CI 流水线脚本。踩了一些坑，也总结了一些选型上的判断逻辑。这篇文章就把这些经验摊开来讲，顺便把 Terminal-Bench 这类评测到底在测什么、分数该怎么看、以及实际选型时该关注哪些维度说清楚。

如果你是一个正在做 DevOps 工具链选型的工程师，或者你只是想知道"我到底该用哪个模型来帮我处理终端任务"，那这篇内容应该能给你一些直接可用的参考。

2. Terminal-Bench 到底在测什么

2.1 评测设计的核心逻辑

Terminal-Bench 的设计思路和传统的代码评测集有本质区别。像 HumanEval 那种，给你一个函数签名和 docstring，你补全函数体，跑单元测试看通过率。这种评测的局限性很明显：它测的是"在高度结构化的输入下生成正确代码片段"的能力，但真实的终端操作根本不是这个形态。

真实的终端操作是什么样？我给你一个场景你就明白了。假设你接手了一台服务器，上面跑着一个 Node.js 服务，现在这个服务启动失败了。你需要做的事情包括：看 systemd 的日志、检查端口占用、确认环境变量有没有加载、看 Node 版本对不对、检查依赖有没有装全、可能还要看 SELinux 或者 AppArmor 有没有拦截。这一整套流程里，每一步都需要你根据上一步的输出决定下一步做什么，而且很多信息是藏在错误信息的细节里的。

Terminal-Bench 就是模拟这种场景。它给模型一个终端环境，然后给一个任务描述，比如"让这个 Web 服务在 8080 端口正常响应"，模型需要通过执行命令来完成任务。评测会检查最终状态是否满足要求，而不是检查模型执行了哪些命令。

这种设计的好处是它测的是端到端的任务完成能力，包括：

• 能不能正确理解任务意图
• 能不能选择合适的命令
• 能不能根据命令输出调整策略
• 能不能处理意外情况
• 能不能在有限步骤内收敛到正确结果

2.2 分数背后的能力维度拆解

Terminal-Bench 4.0 的评分机制比前几版更细了。它不只是一个总分，而是拆成了几个维度。根据我看到的评测报告和实际使用体验，这几个维度大致可以对应到以下能力：

Sonnet 5.5 在"步骤效率"和"错误恢复"这两个维度上的表现特别突出。我自己的体感也是这样：它不太会像某些模型那样，遇到一个报错就反复重试同一个命令，而是会去读错误信息，然后换一个思路。这个能力在终端操作里太重要了，因为终端环境的反馈是即时的，你每一步操作都会立刻看到结果，能不能利用好这些反馈决定了你解决问题的速度。

Opus 4.7 在"任务完成率"上依然是最高的，尤其是在那些需要多步骤推理、涉及多个服务交互的复杂任务上。但它在"步骤效率"上反而不如 Sonnet 5.5，有时候会做一些"保险起见"的额外检查，导致步骤数偏多。

2.3 为什么终端任务和对话任务的能力排序不一样

这个问题我想了很久，后来在實際使用中慢慢想明白了。终端任务和对话任务对模型能力的要求有本质差异。

对话任务的核心是"生成合理的内容"。你问一个问题，模型生成一段回答，这段回答的质量取决于它的知识储备、语言组织能力和逻辑性。这种任务对模型的"知识广度"要求很高，Opus 系列因为参数量更大、训练数据更丰富，在这方面有天然优势。

终端任务的核心是"在反馈循环中做决策"。你执行一个命令，得到一个输出，然后根据这个输出决定下一步。这个过程更像是一个控制问题，而不是一个生成问题。它要求模型：

• 快速解析结构化程度不高的输出（终端输出往往很杂乱）
• 从输出中提取关键信号（哪个是错误、哪个是警告、哪个是正常信息）
• 基于不完整信息做决策（你永远不可能知道所有信息）
• 控制操作风险（有些命令执行了就回不去了）

Sonnet 5.5 在这个反馈循环上的表现更好，我猜测是因为它的训练中可能加强了这类交互式任务的比重。它在解析终端输出时更"务实"，不会过度解读，也不会忽略关键信息。

3. Sonnet 5.5 在 DevOps 场景下的实际表现

3.1 我实际测试的几个典型场景

为了写这篇文章，我特意设计了一组测试场景，在相同的环境里分别用 Sonnet 5.5 和 Opus 4.7 跑了一遍。这些场景都是 DevOps 日常工作中会遇到的真实问题，不是刻意构造的评测题。

场景一：Docker 容器网络不通

我起了一个自定义 bridge 网络的容器，容器内服务监听在 3000 端口，但从宿主机访问不通。任务描述就是"让宿主机的 8080 端口能访问到容器内的 3000 端口服务"。

Sonnet 5.5 的处理路径：

1. 先docker ps确认容器在跑
2. docker port看端口映射，发现没有映射
3. docker inspect看网络配置，确认容器在自定义网络里
4. 直接给出docker run时加-p 8080:3000的方案，并解释了为什么之前的启动方式不对

Opus 4.7 的处理路径：

1. 先docker ps确认容器状态
2. docker inspect看完整配置
3. 检查了 iptables 规则
4. 检查了宿主机的端口占用
5. 最后才定位到是端口映射缺失

两个模型都解决了问题，但 Sonnet 5.5 用了 4 步，Opus 4.7 用了 7 步。Opus 的排查更全面，但在这种明确的问题上，多出来的步骤其实是冗余的。

场景二：systemd 服务启动失败

我故意写了一个有问题的 systemd unit 文件，服务启动时报错。任务描述是"修复这个服务，让它能正常启动"。

这个场景里 Opus 4.7 的表现更好。它不只是看了systemctl status的输出，还去检查了 unit 文件里的ExecStart路径、User配置、EnvironmentFile是否存在、以及服务的依赖关系。Sonnet 5.5 虽然也找到了问题，但它在第一次修复后没有检查依赖关系，导致服务虽然启动了但很快又挂了，需要第二轮修复。

这个差异说明：在涉及多个系统组件交互的复杂问题上，Opus 4.7 的全局视野更好。

场景三：写一个日志清理脚本

任务描述是"写一个脚本，清理 /var/log 下超过 30 天的 .log 文件，但要保留最近 7 天内有修改的，并且要记录清理了哪些文件"。

这个场景两个模型都完成得不错，但 Sonnet 5.5 的脚本更简洁。它用了find的-mtime和-atime组合，加上-delete和-print的配合，整个脚本只有几行。Opus 4.7 的脚本更"防御性"，加了更多的错误检查和日志格式化，代码量大概是 Sonnet 5.5 的两倍。

从运维角度来说，我其实更倾向于 Sonnet 5.5 的风格。清理脚本这种东西，越简单越不容易出问题，复杂的错误处理反而可能引入新的 bug。

3.2 终端命令执行的准确性对比

在终端命令的准确性上，我记录了一组数据。在 50 个常见的 DevOps 操作任务中（包括文件操作、进程管理、网络配置、包管理、权限设置等），两个模型的首次命令正确率如下：

从数据上看，Opus 4.7 在大多数类别上略占优势，但差距不大。真正拉开差距的是"错误恢复"环节——当首次命令失败后，Sonnet 5.5 平均需要 1.8 次尝试就能找到正确方案，而 Opus 4.7 需要 2.3 次。这个差异在长时间的操作会话中会累积成显著的效率差距。

3.3 一个让我印象深刻的案例

有一次我在处理一个 Nginx 配置问题，场景是：一个反向代理配置，后端服务正常，但通过 Nginx 访问时返回 502。我同时开了两个会话，分别用两个模型来排查。

Sonnet 5.5 的排查过程：

1. nginx -t确认配置语法没问题
2. 看error.log，发现是connect() failed (111: Connection refused)
3. curl直接访问后端服务，确认后端正常
4. 检查 Nginx 的proxy_pass配置，发现写的是http://localhost:3000，但后端实际监听在127.0.0.1:3000
5. 指出在某些系统上localhost可能解析到 IPv6 的::1，而后端只监听了 IPv4
6. 建议改成127.0.0.1:3000或让后端监听双栈

Opus 4.7 的排查过程类似，但它在第 4 步之后还额外检查了 SELinux 的布尔值、防火墙规则、以及 Nginx 的运行用户权限。这些检查在本次问题中都是多余的，但如果你遇到的是一个更隐蔽的问题，这些检查可能就有用了。

这个案例很典型地反映了两者的差异：Sonnet 5.5 更像一个经验丰富的运维工程师，凭直觉快速定位最可能的原因；Opus 4.7 更像一个严谨的排查手册，把所有可能性都过一遍。

4. DevOps 选型的实际判断框架

4.1 什么场景选 Sonnet 5.5

基于我这段时间的使用经验，以下场景我会优先选 Sonnet 5.5：

交互式排查和调试。当你需要在一个终端里来回操作、根据输出快速调整策略时，Sonnet 5.5 的响应速度和步骤效率优势很明显。它不会让你等太久，也不会做太多无用操作。

日常运维脚本编写。写个日志清理、备份、监控脚本这类任务，Sonnet 5.5 的输出更简洁直接，改起来也方便。Opus 4.7 有时候会过度工程化，给你一个带完整错误处理、日志、参数解析的脚本，但你其实只需要三行find命令。

CI/CD 流水线调试。流水线失败的时候，你需要快速定位是哪一步出了问题。Sonnet 5.5 在解析 CI 日志、定位失败步骤方面表现很好，而且它给出的修复建议通常更直接。

成本敏感的场景。Sonnet 5.5 的调用成本比 Opus 4.7 低不少，如果你需要大量调用（比如在自动化流程里集成），这个成本差异会很明显。

4.2 什么场景选 Opus 4.7

复杂系统的架构级问题。当问题涉及多个服务、多个配置文件的交互时，Opus 4.7 的全局视野更好。它能同时考虑 Nginx、后端服务、数据库、缓存、消息队列之间的依赖关系。

安全敏感的操作。Opus 4.7 在操作前会做更多的风险评估，对于涉及权限变更、防火墙规则、证书管理的任务，它的谨慎性更有价值。

需要深度推理的排查。有些问题不是靠经验能快速定位的，需要从现象反推原因，涉及多层次的逻辑推理。这种场景下 Opus 4.7 的推理能力更强。

文档和知识整理。如果你需要模型帮你整理运维文档、写 runbook、总结故障处理流程，Opus 4.7 的输出质量更高。

4.3 混合使用的策略

实际工作中，我大多数时候是混合使用的。一个典型的模式是：用 Sonnet 5.5 做前期的快速排查和定位，等确定了问题范围之后，如果问题比较复杂，再切到 Opus 4.7 做深入的方案设计。

另一个模式是：用 Sonnet 5.5 生成初版脚本或配置，然后用 Opus 4.7 做 review。Opus 4.7 在审查时能发现一些 Sonnet 5.5 忽略的边界情况。

这种混合策略的好处是兼顾了效率和深度。你不需要在每个任务上都用最贵的模型，也不需要为了省钱而牺牲复杂问题的处理质量。

5. 实操环境搭建与工具链配置

5.1 终端环境的基本要求

不管你用哪个模型来做 DevOps 辅助，终端环境本身的质量会直接影响效果。我踩过的一个坑是：在一个输出格式很乱的终端里，模型解析命令输出的准确率会明显下降。

几个我建议的配置：

使用结构化的 shell 提示符。默认的 bash 提示符信息量太少，模型有时候分不清当前在什么目录、什么用户下操作。我习惯用这样的 PS1：

export PS1='\[\e[32m\]\u@\h\[\e[0m\]:\[\e[34m\]\w\[\e[0m\]\$ '

这样提示符里包含了用户名、主机名和完整路径，模型能更准确地感知环境。

开启命令历史的时间戳。在.bashrc里加上：

export HISTTIMEFORMAT='%F %T '

这样history命令的输出会带时间戳，模型在排查问题时能知道操作的先后顺序。

配置合理的终端回滚缓冲。默认的 1000 行有时候不够用，尤其是排查长日志的时候。在终端设置里调到 10000 行以上。

5.2 模型接入方式的选择

目前接入这类模型做终端辅助，主要有几种方式，各有优劣：

我个人的选择是：日常交互用官方 CLI，自动化流程用 API 直接调用。CLI 工具的好处是它已经帮你处理好了终端交互的很多细节，比如命令执行的确认机制、输出的截断策略、上下文的维护等。API 调用则适合那些需要批量处理或者集成到现有工具链里的场景。

5.3 安全边界设置

让模型直接操作终端是有风险的。我见过最危险的情况是模型执行了一个rm -rf命令，虽然是在测试环境里，但也吓出一身冷汗。几个必须设置的安全边界：

命令白名单/黑名单。在接入层配置危险命令的拦截规则。比如rm -rf /、mkfs、dd写磁盘设备这类命令，必须拦截。

操作确认机制。对于写操作、删除操作、权限变更操作，要求模型先输出计划再执行，或者要求人工确认。

环境隔离。不要让模型直接操作生产环境。至少要在测试环境里验证过方案之后再手动应用到生产。

操作日志审计。所有模型执行的命令都要有日志记录，方便事后追溯。

提示：如果你用的是官方 CLI 工具，它通常有内置的确认机制。但如果你是通过 API 自己实现的，这些安全边界需要你自己来加。不要偷懒，这一步省不得。

6. 常见问题与排查技巧实录

6.1 模型执行命令时的典型问题

问题一：命令在交互式环境下挂起

有些命令在终端里执行时会进入交互模式，比如apt install会问你是否继续，mysql会进入交互式 shell。模型如果直接执行这些命令，会话就会卡住。

解决方法：在命令前加非交互式参数。比如apt install -y、mysql -e "..."。或者在接入层设置超时，超时后自动发送 Ctrl+C。

问题二：输出太长被截断

有些命令的输出非常长，比如journalctl不加限制会输出几千行。模型如果只能看到前几百行，可能会漏掉关键信息。

解决方法：在命令里加过滤条件。比如journalctl -u myservice --since "10 min ago" | tail -50。或者用grep过滤关键信息。

问题三：环境变量不一致

模型执行的命令和你手动执行的命令，环境变量可能不一样。这会导致一些奇怪的问题，比如PATH不同导致找不到命令，或者LANG不同导致输出格式不一样。

解决方法：在接入层显式设置环境变量，或者在命令里用绝对路径。

问题四：权限问题

模型可能没有权限执行某些命令，或者执行了需要 sudo 的命令但没加 sudo。

解决方法：明确告诉模型当前用户的权限级别，或者在接入层配置 sudo 免密。

6.2 排查思路的速查表

6.3 我踩过的几个坑

坑一：过度信任模型的命令

有一次模型建议我用chmod -R 777来解决一个权限问题。这在测试环境里可能没问题，但在生产环境里是灾难性的。后来我养成了一个习惯：模型给出的命令，尤其是涉及权限、删除、覆盖的操作，一定要先理解再执行。

坑二：忽略模型的"不确定"信号

模型有时候会在回答里加一些限定词，比如"通常"、"一般来说"、"你可能需要确认"。这些词是它在表达不确定性。我早期会忽略这些信号，直接按它说的做，结果就踩坑了。现在我会特别关注这些词，遇到不确定的地方就自己去验证。

坑三：上下文污染

在一个长时间的会话里，模型会记住之前的操作和输出。如果之前的操作有错误，这些错误可能会影响后续的判断。我现在的做法是：当一个任务完成后，如果要做另一个不相关的任务，就开一个新会话，避免上下文污染。

坑四：版本差异

不同版本的模型在命令偏好上有差异。比如某些版本更倾向于用apt，某些版本更倾向于用apt-get。在写自动化脚本时，这个差异会导致兼容性问题。我的做法是：在 prompt 里明确指定包管理器和命令风格。

7. 从评测分数到实际选型的思考

Terminal-Bench 4.0 的分数是一个参考，但它不是选型的唯一依据。我见过太多团队因为某个模型在某个榜单上高了几分就全面切换，结果发现实际使用中并不适合。

选型的时候，我建议从这几个维度来评估：

你的任务类型分布。如果你的工作主要是交互式排查和脚本编写，Sonnet 5.5 可能更合适。如果你的工作涉及复杂的系统设计和安全敏感操作，Opus 4.7 更稳妥。

你的成本预算。两个模型的价格差异在大量调用时会很明显。如果你的预算有限，Sonnet 5.5 的性价比更高。

你的团队习惯。如果团队已经有一套成熟的工具链和工作流，切换模型的成本可能比模型本身的差异更大。

你的风险容忍度。Opus 4.7 在安全性上更保守，如果你操作的环境比较敏感，这个特性很重要。

我自己的做法是：保持两个模型都可用，根据任务类型动态选择。这不是骑墙，而是务实。工具就是工具，哪个好用用哪个，没必要搞品牌忠诚。

Terminal-Bench 这类评测的价值在于它提供了一个相对标准化的比较框架，但你的实际工作场景永远比评测复杂。分数可以看，但最终还是要回到你自己的需求上来。