TUA-Bench：面向通用终端使用智能体的基准测试

TL;DR TUA-Bench 提出面向通用终端代理的全面基准，涵盖 120 个真实任务，揭示当前最强模型仅 65.8% 通过率，暴露从编程助手到通用数字助手的关键性能差距。

问题

随着大语言模型(LLM)与代理框架的快速演进，终端使用代理(Terminal-Use Agents, TUAs) 逐渐超越编程辅助，开始承担文档编辑、邮件管理、网页信息获取等日常数字任务，以及需要专业软件的科学/工程工作流。业界亟需一个全面且贴近现实的基准来评估这些通用代理的可靠性与能力边界。

现有评估体系存在明显局限：面向通用计算机使用的基准(如 OSWorld、AndroidWorld)几乎完全聚焦于图形用户界面(GUI) 操作，无法覆盖纯终端场景；而基于终端的基准(如 SWE-bench、TerminalBench)又过度偏向编程中心的技术工作流，例如代码调试、DevOps 脚本等，缺乏对日常办公、网页实时信息检索、专业科学软件交互等非编程任务的考察。这种割裂导致没有一个基准能真实反映 TUAs 在多样化数字环境中的泛化使用能力，也使得模型开发者难以定位代理在通用终端任务上的薄弱点。

该问题的挑战在于终端任务的异质性与环境依赖：日常任务涉及交互式网页爬取、复杂文档格式转换、实时邮件操作等；专业任务则需要调用如生物信息学、量子化学等领域的特定软件，这些任务不仅要求代理具备命令级推理，还需理解领域知识并处理执行时的动态反馈。业界对通用代理的关注度持续升温，从 Anthropic 的 Claude Code、OpenAI 的 Codex CLI 到各类 Agent 框架，都在争夺“帮用户操作电脑”的入口，而缺乏统一、硬核的终端基准会阻碍这一进程的透明推进。

这一工作可类比于自动驾驶的城市道路测试集：正如车辆需要从封闭高速走向复杂城区，TUAs 也必须从纯代码任务拓展到充满异构工具的日常与专业终端场景，才能真正成为可靠的数字助手。

核心洞察

• - TUA-Bench 首次将通用终端代理的评估从代码编程扩展到涵盖文档编辑、邮件管理、实时网页检索以及博士级专家协同设计的科学工程工作流，直接暴露了从专用助手到通用代理的性能鸿沟。与侧重 GUI 的 OSWorld 或聚焦 shell 编程的 SWE-bench 不同，这种任务多样性衡量了代理在真实数字环境中的可靠性，揭示了当前代理在泛化与专业软件操作上的不足。
• - 执行基评分协议配合确定性 setup 脚本保证了结果可复现，但实验显示最强代理（Claude Opus 4.8 最大推理努力）仅达 65.8%，在需要多步推理和专业软件操作的任务上差距尤为显著。这明确指出了当前 LMAgent 在规划、工具使用和领域适应性方面的短板，为后续优化提供了直接方向，也暗示通用终端代理距离可靠部署仍有较大距离。

方法

基准构建方法

TUA-Bench 的设计遵循“环境复现 → 任务策划 → 自动评分”的流水线，旨在衡量通用终端使用智能体（TUAs）在多样真实场景下的表现。

1. 统一执行环境

每个任务在独立、可复现的终端会话中运行，通过确定性配置脚本预装所有依赖（命令行工具、Python 包、专用软件等），确保同一任务在不同智能体间完全一致。环境容器化（Docker）避免干扰，同时允许智能体自由执行任何 shell 命令。

2. 多维度任务策划

任务分为两大轨道：

• 日常数字任务（Everyday Digital Tasks）：模拟普通用户行为，如文档编辑（LaTeX/Markdown 排版）、邮件管理（mutt/notmuch 交互）、实时网页信息抓取（curl + 文本处理）等，共 60 个任务，覆盖 3 个家族。
• 专业科学任务（Professional Scientific Tasks）：与 PhD 级领域专家共同设计，要求智能体操作专业软件（如分子动力学模拟、气象数据处理、基因组分析工具），共 60 个任务，覆盖 2 个家族，强调跨领域工具链组合。

每个任务以自然语言指令描述目标，并附带初始工作目录与所需数据。任务难度通过步骤数、工具调用次数和“路障”（如故意引入的格式错误）分级。

3. 执行式评分协议

摒弃静态比对，采用基于最终状态的动态评分：

• 评分脚本检查终端输出、生成的文件内容或特定文件存在性，通过多个检查点累积分数（0–1 分，支持部分正确）。
• 智能体在任务中可自由探索，但仅最后一次提交时的环境状态被用于评分，避免路径依赖。
• 所有评分逻辑在任务设计时写入 eval.py，确保完全自动化与无偏见。

与同类工作的关键差异

先前终端基准（如 SWE-bench、TerminalBench）几乎全部聚焦编程或系统管理，TUA-Bench 首次将评估范围扩展到非技术用户的日常数字化活动及多学科专业软件工作流，从而衡量智能体在通用计算机使用中的真实能力，而非窄化的 shell 脚本技能。

实验

实验设计

TUA‑Bench 在真实终端环境中对前沿Agent进行执行驱动评分。任务实例均配备确定性 setup 脚本，确保可复现；评估指标为任务是否成功完成（基于执行结果自动判断）。实验覆盖了多款主流Agent，包括 Claude Code + Claude Opus 4.8、GPT‑4o 等，并划分 日常数字任务 与 专业科学任务 两大赛道，以全面考察通用终端使用能力。

关键发现

• 当前最强组合 Claude Code + Claude Opus 4.8（max reasoning effort） 总成功率仅 65.8%，且在日常与专业两赛道均存在巨大性能缺口（原文称 “substantial gaps across both tracks”）。
• 专业科学任务尤其暴露出Agent的短板：需要操作专门软件、遵循精密实验流程的任务，对模型的领域知识、工具调用稳健性提出更高要求，而非简单编码能力可覆盖。
• 与以往终端基准的对比显示，TUA‑Bench 首次将评估推向非编程化、通用计算场景，而多数现有Agent在此类任务上表现不佳，说明从代码助手到通用终端使用者的角色跃迁仍有距离。

基线深度解读

传统终端基准（如 SWE‑bench、Bash 任务）侧重编程与系统管理，GUI 基准又忽略 terminal 场景。TUA‑Bench 的 120 项覆盖文档编辑、邮件管理、实时信息检索及专家级科研工作流 的任务，迫使Agent同时具备跨工具协调、不确定环境适应与长程记忆能力。顶尖Agent 65.8% 的成绩表明，即便推理强化与工具链整合已大幅进步，真实数字活动中的鲁棒性、宽容错能力仍远未达标，为后续Agent架构优化（如安全中断恢复、动态规划）提供了明确方向。

行业影响

落地场景

TUA-Bench 面向通用终端智能体（Terminal-Use Agents, TUA）测评，其任务覆盖日常数字活动（文档编辑、邮件管理、实时网页信息检索）与专业科学/工程工作流（需专用软件，如仿真、数据分析）。这直接赋能浏览器/IDE 插件式智能体、企业自动化 RPA、云工作台 AI 助手等产品，使其能跨 CLI 环境完成多步、跨应用操作，例如自动处理合同文档、批量数据清洗、科研实验脚本编排等。

商业价值

基准为智能体能力提供了标准化度量，可推动模型厂商（如 Anthropic、OpenAI）优化终端操控能力，从而降低企业重复性人力操作成本。当前最强模型 Claude Opus 4.8 在 TUA-Bench 上仅 65.8%，表明仍有大量失败场景，意味着精准度提升可直接转化为终端用户信任与留存，减少人工干预，支撑大容量、高并发自动化服务。对于 SaaS 平台，集成高可靠 TUAs 可将“人工操作界面”升级为“意图驱动执行”，提升 ARPU 与客户终身价值。

与现有产品/工作流的接口

TUA-Bench 提供确定性环境构建脚本与执行评分协议（execution-based scoring），可嵌入现有 CI/CD 或 Agent 集成测试流水线。工程团队可将其作为回归测试关卡，评估新版本模型在真实 CLI 任务上的表现，并基于失败归类微调提示词或函数调用策略。与 LangChain、AutoGen 等编排框架配合时，可利用该基准的多任务家族（5 个家族，120 个任务）快速验证智能体组合的鲁棒性，实现从评测到上线的闭环。

具体落地 use case

• 金融量化研究：研究人员可通过 TUAs 自动获取经济数据、执行统计模型代码、生成 LaTeX 报告，并在出现异常时自动调试。TUA-Bench 中的专业科学任务 直接验证此类复杂流程，降低策略迭代周期。
• 电商运营自动化：运营人员使用终端智能体自动抓取竞品价格、更新库存报表、发送通知邮件，并可跨多个 SaaS 工具协同。基准的日常数字任务（如文档编辑、邮件管理）能模拟此类工作，帮助厂商评估智能体在真实数据平台间的迁移能力。
• 医疗影像分析流水线：科研团队利用 TUA 编排 DICOM 文件处理、运行分割模型、上传结果至数据库，基准中的科学工程任务可检验工具链稳定性，减少手动脚本错误，确保可复现性。

局限

• **任务覆盖的广度与深度限制**：TUA-Bench 包含 120 个手工设计的任务，涵盖日常数字活动与专业科学工作流，但任务数量仍有限，可能无法完全反映现实终端使用的多样性。尤其专业科学任务依赖特定领域软件（如计算化学工具），版本更新可能导致任务不可复现，且领域覆盖偏重合作专家的研究方向，其他学科（如生物信息学、金融建模）的代表性不足。这会影响基准的泛化评估能力。
• **评估协议对部分完成不敏感**：采用基于执行的确定性评分，只判定最终命令序列或文件输出的完全匹配，忽略了代理在中间步骤中展现出正确推理但最终输出格式略有偏差的情况。这可能导致对“部分正确”的代理能力低估，也错失了细粒度诊断失败模式的机会（例如，命令语法错误与逻辑错误的区分），限制了其对工程改进的指导价值。
• **前沿代理的覆盖与实验深度不足**：实验主要评估了商业闭源代理（如 Claude Code 搭配 Claude Opus），对开源终端代理（如 OpenClaw 等）及不同推理努力级别、工具配置的 ablation 不够全面。同时，未系统分析代理在长多步任务中的持续可靠性（如上下文窗口溢出影响），也未对比在GUI基准与终端基准上的能力迁移，这削弱了基准与现有评测体系的连接。