如何验证 AI Agent 能否在终端里真正干活Terminal-Bench 完整指南【免费下载链接】terminal-bench-1A benchmark for LLMs on complicated tasks in the terminal项目地址: https://gitcode.com/GitHub_Trending/tb/terminal-bench-1如果你正在开发基于大模型的 Agent多半被这个问题卡住过模型在聊天窗口里看起来聪明可一旦放进真实的终端环境——装依赖、调试脚本、起服务、跑测试——它到底能不能把事做完Terminal-Bench 就是为回答这个问题而生的开源基准平台。它由两部分组成一套两百多个真实终端任务构成的数据集当前仓库original-tasks/目录下就有 241 个任务目录以及一个把语言模型接入 Docker 沙箱终端的执行工具harness让评测全程自动、可复现。先看痛点为什么聊天看起来聪明不够用问答型评测只能证明模型会说而真实的终端任务是链条式的一条指令背后往往连着读文件、改配置、编译、验证输出一长串动作中间任何一步出错任务就失败。Terminal-Bench 的处理方式很直接给 Agent 一份英文指令和一个干净的 Docker 沙箱让它自主操作最后由测试脚本判定成败。这样得到的不是主观印象而是每个任务通过/未通过的硬指标并且换一台机器重跑也能得到可复现的分数。5 分钟跑通第一次评测 最快的安装命令Terminal-Bench 以 pip 包形式发布安装后获得tb命令行工具uv tool install terminal-bench习惯传统工具链的话pip install terminal-bench同样可以。由于任务跑在 Docker 容器里宿主机还需要装好 Docker仓库本身用uv管理依赖见 pyproject.toml。一条 tb run 启动评测安装完成后核心入口就是tb runtb run \ --agent terminus \ --model anthropic/claude-3-7-latest \ --dataset-name terminal-bench-core \ --dataset-version 0.1.1参数含义可以对照 CLAUDE.md 理解--agent决定用哪个 Agent 把模型输出翻译成终端命令内置的 terminus 是目前最常用的起点更多实现在 terminal_bench/agents/ 中--model指定被测模型--dataset-name与--dataset-version锁定任务集版本。terminal-bench-core的0.1.1版本对应官方排行榜数据集版本元数据记录在仓库根目录的 registry.json 中固定版本号才能和别人横向比分数想控制并发可加--n-concurrent官方示例取 8机器紧张时降到 2–4 更稳用--task-ids只跑部分任务--n-attempts调整每个任务的尝试次数--output-path自定义结果落盘位置。跑之前如果不确定有哪些参数tb run --help是最快的参考。看懂一个任务的内部构造 打开 original-tasks/ 任意目录比如最简单的hello-world每个任务都是三件套task.yaml英文指令加上元数据。hello-world 的指令只有一句创建 /app/hello.txt写入 Hello, world!文件里还标了difficulty、category、超时时间max_agent_timeout_sec等字段。注意文件开头的 canary GUID 注释——它用于标记基准数据防止这些任务意外混入模型训练语料。run-tests.sh 与 tests/判定 Agent 是否做对的测试脚本。hello-world 的 run-tests.sh 会在容器里装好 uv 和 pytest然后运行tests/test_outputs.py检查文件内容。solution.sh参考解oracle solution。hello-world 的参考解就一行echo。它用来验证任务本身可解也方便人工对照 Agent 的解法路径。再配上 Dockerfile / docker-compose.yaml 定义沙箱环境任务就齐了。难度跨度非常大从fix-git、configure-git-webserver这类系统管理到compile-compcert、make-doom-for-mips这类编译构建再到cartpole-rl-training、mcmc-sampling-stan这类训练与统计建模任务覆盖了终端环境里 AI 该会的活的主要面。Agent 与模型怎么搭--agent和--model是互相独立的两层Agent 负责把意图变成命令的策略与解析仓库在 terminal_bench/parsers/ 里放了针对不同输出格式的解析器模型负责推理。同一模型换 Agent、或同一 Agent 换模型分数差异本身就是有价值的实验信息。另外docker/mcp-server/ 提供了在沙箱内运行 MCP 服务的镜像docker/agents/goose/ 则展示了把第三方 Agent如 goose带进终端容器的方式——评测框架本身不绑定某一家模型或 Agent这正是它被用作跨团队对比工具的原因。评测结果怎么读 一次 run 结束后harness 会为每个任务留下通过与否、Agent 执行轨迹依赖 asciinema 录制和运行日志聚合起来就是这次评测的总通过率与分任务明细。想看得更直观可以用仓库自带的 Streamlit 面板dashboard/ 目录下的dashboard.py配合数据库初始化脚本db_init.py、migrations.py把结果导入后提供可视化的任务级钻取。日常建议养成两个习惯汇报成绩时写清数据集与版本号比如terminal-bench-core 0.1.1否则分数没有可比性对未通过的任务直接回放终端录屏定位失败点——是命令写错、环境没装好还是超时通常一眼可见。二次扩展从用别人任务到写自己的任务 自定义任务三步走想把自己遇到的真实运维/开发场景变成基准任务步骤和 hello-world 的结构一致在任务目录里写task.yaml用英文把指令、难度、超时时间写清楚用 Dockerfile 或 docker-compose.yaml 描述沙箱的初始环境预装什么、留下什么坑编写tests/下的测试与run-tests.sh判定逻辑并附一份能跑通的solution.sh。提交前可以先过一遍 scripts_bash/ 里的检查脚本如check-dockerfile-sanity.sh、validate-task-fields.sh它们会拦截任务目录结构、字段和 Dockerfile 的常见错误比人工自查快得多。把 SWE-bench 等外部基准接进来仓库的 adapters/ 目录已经内置了一批适配器swebench、mlebench、quixbugs、swelancer 等每个适配器由adapter.py负责把外部任务转换成 Terminal-Bench 格式parity_experiment.json记录与原始基准的对齐实验结果。如果你的模型团队需要一套流水线跑多个公开榜单从这里看起是最短路径。收尾这套工具适合谁如果你在做 LLM Agent 的落地开发Terminal-Bench 给出的任务通过率 可回放轨迹比任何 demo 都更能暴露真实短板如果你在比较不同模型或 Agent 框架的终端能力固定数据集版本即可得到可横向比较的分数如果你只是好奇现在的 Agent 到底能干什么跑一遍terminal-bench-core再打开 dashboard 看分任务结果半小时内就能建立体感。【免费下载链接】terminal-bench-1A benchmark for LLMs on complicated tasks in the terminal项目地址: https://gitcode.com/GitHub_Trending/tb/terminal-bench-1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
