如何验证 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 run：tb 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），仅供参考
如何验证 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 run：tb 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），仅供参考