综述 | 终端智能体：命令行环境中的 AI Agents

论文题目：Terminal Agents: A Survey of AI Agents in Command-Line Environments 作者：Yi Bin、Xiaoyang Yuan、Haoxi Zeng、Wencheng Ye、Wenqi Shao、Chen Qian、Wei Ye、Yujuan Ding、Zheng Wang、Pengpeng Zeng、Jingkuan Song、Heng Tao Shen 机构：同济大学、上海交通大学、香港理工大学、上海创智学院 论文链接：https://arxiv.org/pdf/2608.20485 项目地址：https://github.com/EnigmaYYYY/awesome-terminal-agents

导读

大模型智能体正在从“回答问题”走向“操作环境”。在软件工程、数据处理、科学计算、运维、云管理和安全分析中，越来越多智能体通过终端执行命令、读取输出、修改文件、安装依赖、运行测试、查看日志，并根据失败反馈继续修复。终端不再只是一个输入接口，而成为承载行动、观察、验证和恢复的执行基底。 这篇综述提出“终端智能体”这一统一视角：如果一个系统的主要任务进展依赖终端命令执行、文本反馈和有状态环境交互，那么它就应被视为终端智能体。论文把终端智能体同普通命令行包装器、聊天式代码助手、图形界面智能体区分开来，并给出三个工作负载级边界测试：终端是否是主要执行基底，命令输出是否影响后续行动，移除终端访问是否会改变核心行为。 论文进一步提出七维终端能力画像：命令与动作构造、反馈与产物解释、运行时与环境管理、状态任务与上下文跟踪、进展验证、恢复与适应、治理与副作用控制。围绕这七个维度，作者系统梳理终端智能体的系统架构、能力获取、评测诊断和未来研究议程。一个重要判断是：终端智能体的表现不是单纯由模型决定，而是由模型、接口、脚手架、运行时和环境共同塑造；因此评测也不能只看最终成功率，还需要可重放轨迹和过程级证据。

1 Introduction：引言

研究背景

大语言模型正在从提示词驱动的文本生成器，演化为可以在外部环境中行动并根据反馈修正行为的交互式系统。它们可以执行代码、调用工具、操作计算环境、修改数字工作区，并在多步过程中完成复杂任务。 终端之所以重要，是因为它提供了紧凑、可脚本化、文本化的有状态运行时入口。通过终端，智能体可以访问文件系统、依赖包、进程、测试、日志、远程机器和命令行工具；命令会改变环境，输出、退出码、差异、堆栈、日志和产物会反过来影响下一步决策。 现有综述通常把相关研究分散到通用大模型智能体、软件工程智能体、工具使用、图形界面计算机使用或智能体评测中，缺少以“终端介导执行”为核心的统一框架。本文的目标正是把终端智能体的范围、架构责任、能力学习和评测问题组织到同一个分析语言中。

主要贡献

论文贡献包括三点。第一，给出基于执行基底的终端智能体定义，并提出工作负载级边界测试，区分真正以终端推动任务进展的系统和只是表面使用命令行的相邻系统。第二，构建七维终端能力画像，用于连接系统架构、能力获取和评测证据。第三，综合分析模型、接口、脚手架、运行时和环境如何共同决定行为，并通过有界诊断展示不同基准暴露的过程信号不同、组件归因存在局限。

2 Background and Scope of Terminal Agents：终端智能体背景与范围

终端作为执行基底

论文把终端视为一种命令执行基底，而不只是表面接口。一个可见的命令行、集成开发环境、网页控制台或平台界面都可能只是表层；真正决定是否属于终端智能体的是：任务进展是否依赖命令执行、文本反馈和有状态环境变化。 终端介导执行有四个关键性质。第一，动作会改变持久状态，例如文件、依赖、服务和配置。第二，观察结果以文本证据形式返回，包括标准输出、错误输出、日志、差异和测试结果。第三，重复运行和测试把执行与验证连接起来。第四，命令、补丁和配置编辑本身都是可组合的文本产物。

范围边界

论文提出三个边界测试。主要执行基底测试关注终端命令执行是否是任务推进的主要方式；迭代命令反馈测试关注输出、错误、日志、差异、返回码和状态变化是否实质影响后续动作；终端依赖测试关注移除终端访问是否会改变工作负载的核心行为。 这意味着，“偶尔调用命令”不够，“一次性生成代码或补丁”也不够。真正的终端智能体必须依赖一个执行-观察-修正循环。SWE-agent 这类系统在仓库修复任务中属于典型终端智能体；而纯聊天代码助手、主要依赖图形界面的计算机使用智能体，或只是把非终端流程包装成命令行的产品，则属于相邻系统。

七维能力画像

论文提出七个能力维度：命令与动作构造，反馈与产物解释，运行时与环境管理，状态任务与上下文跟踪，进展验证，恢复与适应，治理与副作用控制。 这七维不是低层命令清单，而是终端智能体在真实环境中必须承担的系统责任。比如，恢复能力依赖反馈解释、状态跟踪和验证；运行时管理依赖动作构造；长期任务则同时要求状态跟踪、验证和恢复。该画像为后续架构、学习和评测提供共同语言。

3 Terminal-Agent System Design and Architectures：终端智能体系统设计与架构

设计重点演进

论文把终端智能体设计的演进概括为四个重叠阶段。第一阶段是工具增强提示，模型通过工具调用获得外部行动能力，但执行仍被视为外部动作通道。第二阶段是结构化可执行动作，例如把搜索、编辑和运行封装成模型可理解的交互原语。第三阶段是把终端介导智能体作为一等目标，终端交互成为训练和评测分布本身。第四阶段是运行时和脚手架中心化设计，系统开始直接优化上下文包装、工作区持久化、验证、权限、沙箱和控制流。 这个演进说明，终端智能体能力越来越依赖模型外部结构。一个强模型如果缺少良好观察格式、运行时管理、恢复机制和权限控制，仍可能在长任务中失败；反过来，经过优化的脚手架也可能显著提升同一模型的表现。

分层架构

论文将终端智能体系统拆为若干责任层。接口与观察层决定动作单元和反馈格式，例如直接命令、结构化编辑、运行事件、日志、退出码和文件差异。终端运行时与工作区层管理持久状态、依赖、服务、容器、远程机器和资源边界。控制、恢复与治理层负责沙箱、回滚、审批、错误边界和安全策略。脚手架与上下文层则管理轨迹包装、记忆、模型调用顺序和上下文压缩。 这些层共同塑造中心行动-观察循环：模型发出命令或动作，运行时返回观察，工作区发生状态变化，验证与治理机制提供反馈，脚手架再把相关上下文交给模型。

架构权衡

论文强调若干关键权衡。直接命令访问表达力强，但观察噪声和回滚难度高；结构化接口更可靠，但可能牺牲跨任务通用性；持久运行时扩大任务面，但也会传播错误中间状态；权限门、审批和沙箱提升可审计性，却增加延迟并打断自主执行。 因此，比较终端智能体不能只看模型名称，还要看系统如何分配责任：哪些能力由模型承担，哪些由接口约束，哪些由运行时保证，哪些由脚手架和治理策略补足。

4 Terminal Competence Acquisition and Adaptation：终端能力获取与适应

可执行轨迹作为学习信号

终端能力获取关注可执行交互如何转化为学习和适应信号。与普通问答数据不同，终端轨迹包含动作、观察、状态变化、验证结果和恢复决策；一个有价值的学习样本不是孤立的提示-回答对，而是带有后果、失败、验证和修复的有状态轨迹。 数据来源包括终端原生 rollout、可执行仓库环境、合成子技能生成、以失败为中心的轨迹等。成功轨迹可以教会系统常见工作流，失败轨迹则能保留诊断、回滚和恢复信息，而这些往往是成功样本中缺失的。

学习与适应范式

论文总结多种互补方法。基于成功轨迹的监督微调可以学习常见命令序列和工作流，但容易忽视失败恢复。强化学习可以利用可执行奖励，例如测试通过、任务完成或环境反馈，但可能过拟合特定基准和奖励渠道。验证器引导优化可以利用步骤判断、验证器排序和失败检测强化过程质量。运行时记忆与适应则关注长会话上下文管理、历史检索和状态压缩。 这些方法的共同挑战是覆盖不足。当前数据主要集中在软件工程和仓库修复，运维、数据工程、科学工作流、网络安全和云管理等领域的终端轨迹仍不充分。长期任务中的权限控制、恢复质量和副作用治理也缺少系统训练信号。

5 Benchmarks, Metrics, and Evaluation：基准、指标与评测

从仓库修复到终端原生评测

终端智能体评测决定了哪些能力可见、哪些能力被最终结果掩盖。SWE-bench 及其后续工作把仓库问题修复和可执行验证推成主流范式，但仓库修复能力并不等同于完整终端能力。终端原生和命令行中心基准则把命令介导交互作为任务定义的一部分，更直接暴露命令使用、输出解释、状态检查和工作流持久性。 论文把评测文献按四个分析轴组织：基准设计强调什么任务和目标，证据层记录什么过程，覆盖图显示哪些七维能力可被观察，协议有效性决定分数能否跨设置解释。

过程评测的重要性

仅看最终成功率是不够的。两个智能体可能同样通过任务，但一个过程简洁、安全、可复现，另一个则依赖偶然重试、未受控副作用或隐藏状态污染。过程感知评测应记录步骤质量、命令经济性、错误传播、恢复尝试、验证行为、环境配置和治理触发。 环境感知评测也很关键。依赖安装、服务启动、容器配置和运行时修复不是“评测前准备”，而是终端能力的一部分。长时程评测进一步揭示上下文漂移、状态污染、错误累积和权限治理问题。

6 Bounded Diagnostics：有界诊断

基准暴露差异

论文通过固定条件诊断说明两个问题。第一，不同基准暴露的过程信号不同。有些基准更能看到环境配置摩擦，有些更能看到恢复与验证，有些只强烈反映最终结果。第二，匹配系统比较显示性能具有基准依赖性，同一个模型和不同系统组合的表现不能简单归因于某个组件。 作者强调，官方基准结果应与轨迹派生过程指标分开报告。过程指标可以来自确定性规则，也可以来自受规则约束的语义判断，但都需要可见证据、步骤标识和可复查记录。这样才能区分“任务通过了”和“系统以怎样的方式通过”。

归因限制

终端智能体的归因尤其困难。性能提升可能来自模型能力、上下文管理、观察压缩、重试策略、脚手架优化、运行时稳定性或验证器设计。若不报告系统与运行时条件，就很容易把脚手架贡献误归因给模型，或把某个基准上的优势误解为通用终端能力。 因此，论文建议报告可重放轨迹、运行时版本、事件模式、缺失信息、恢复行为、人工干预和验证器调用，以支持更可信的横向比较。

7 Research Agenda：研究议程

跨领域能力

未来研究需要把终端能力从软件工程扩展到更广领域，包括运维、数据工程、科学工作流、网络安全和云管理。不同领域的命令结构、状态对象、验证方式和风险边界不同，不能假设仓库修复基准上学到的能力能自然迁移。

新鲜且可重放的过程评测

基准需要同时具备新鲜性和可重放性。新鲜任务可以减少过拟合和数据污染，可重放轨迹则支持过程分析、失败复查和治理审计。理想评测应同时记录环境版本、事件模式、缺失数据、恢复、干预和验证调用。

运行时可治理性与安全

终端智能体拥有广泛副作用能力：删除文件、联网、安装包、修改配置、访问凭据、启动服务或触达外部系统。未来系统必须把权限、审批、沙箱、资源限制、回滚和审计作为核心能力，而不是部署后的补丁。

模型与脚手架归因

论文呼吁更严格的模型-脚手架归因研究。比较系统时，应控制模型、任务、运行时和接口差异；比较模型时，也应固定脚手架和环境。否则，评测结果无法说明到底是模型更强，还是外部系统更会组织上下文、执行验证和处理失败。

8 Conclusion：结论

终端智能体为研究环境接地智能提供了一个非常具体的场景：命令会改变状态，文本反馈提供证据，测试和验证发生在同一执行基底，失败恢复和副作用治理可以通过轨迹被观察。本文的价值在于把这些现象统一为“终端介导执行”的分析框架。 从实践角度看，终端智能体的未来不只是更强代码模型，而是更好的执行基底设计：清晰的动作接口、可解释观察、稳定运行时、持久状态管理、过程验证、失败恢复、权限治理和可重放评测。只有同时报告模型、接口、脚手架、运行时和环境条件，社区才能真正比较终端智能体能力，并推动其从软件工程走向更广泛的数字工作负载。