终端代理足以实现企业自动化 Terminal Agents Suffice for Enterprise Automation
简单的终端代理通过直接API交互可实现高效企业自动化
前置知识
LLM Agent
LLM Agent是指基于大语言模型的智能体，能够感知环境状态、进行推理规划、执行操作以完成多步骤任务。Agent通常以迭代循环方式工作：观察环境、生成行动、执行并获得反馈、重新规划。在企业场景中，Agent需要跨长时间跨度操作，与生产系统交互，错误的操作可能级联传播到多个记录和下游工作流中。
本文的核心是比较不同Agent架构在企业自动化中的效果，理解LLM Agent的基本工作原理对于理解终端代理如何通过终端和文件系统与平台API交互至关重要。
Model Context Protocol (MCP)
MCP是Anthropic提出的标准协议，用于在LLM和外部工具之间建立统一的接口。MCP服务器暴露一组预定义的工具，每个工具有清晰的参数schema，模型通过工具调用来执行操作。这种抽象简化了Agent的执行，将复杂的交互压缩为高级操作，但也约束了Agent只能使用工具注册表中暴露的功能。
本文将MCP作为工具增强代理的代表进行对比评估，理解MCP的工作原理和约束有助于理解为什么MCP代理在复杂企业任务中表现受限。
企业平台API
企业平台API是现代企业软件暴露的程序化接口，允许通过HTTP请求查询数据、创建或更新记录、执行复杂操作。与GUI相比，API提供了更稳定、更紧凑的交互方式，避免了界面变更的脆弱性，但也可能缺少某些只能通过浏览器会话执行的功能。
本文的核心假设是当稳定API可用时，终端代理可以直接通过API交互完成任务，理解企业API的能力和局限性对于评估这一假设至关重要。
成本效率权衡
在企业自动化场景中，成本效率是指Agent完成任务所消耗的资源与任务成功率之间的关系。Web代理因为需要处理大型可访问性树和截图，每次交互的token消耗远高于基于文本的终端代理。评估时使用推理成本而非wall-clock时间作为主要效率指标。
本文的一个重要发现是终端代理在匹配或超越Web代理成功率的同时，成本降低了5-9倍，理解这一权衡对于理解为什么终端代理是更实用的企业自动化解决方案至关重要。
研究动机
当前企业自动化面临一个根本性问题：是否需要复杂的代理架构。现有的两种主流方法各有明显缺陷。GUI驱动代理通过浏览器界面操作，能够执行人类可以进行的任何操作，灵活性很高，但成本高昂。在ServiceNow上使用Claude Opus 4.6时，Web代理每任务成本达到4.21至6.49美元，是终端代理的4至9倍。此外，GUI代理的执行链长而脆弱，对界面变更敏感，在iframe嵌套的UI中容易迷失方向。工具增强代理通过MCP暴露预定义操作，虽然简化了执行，但受到工具注册表的严格限制。在ServiceNow上，尽管有93个可用工具，MCP代理成功率仅为11.5%至18.5%，因为许多任务需要超出这些工具组合的操作。这些复杂架构不仅带来高昂的运营开销，还可能因为引入不必要的抽象层而降低灵活性。
本文的目标是本文的核心目标是验证一个假设：当企业平台暴露稳定、表达性强的API时，配备终端和文件系统的简单编码代理足以完成企业自动化任务，不需要复杂的抽象层。具体而言，作者希望比较三种代理范式在真实企业平台上的性能和效率，量化评估终端代理是否能够在保持竞争力的同时显著降低成本。此外，作者还希望研究文档访问和持久技能等实用扩展对终端代理的影响，理解在不同类型的平台和任务场景中，哪种配置最有效。
与已有工作不同的是，本文的独特切入点在于挑战了主流假设，即企业自动化需要日益复杂的代理栈。大多数现有工作要么专注于改进GUI代理的规划、检索能力，要么设计更精细的工具注册表和技能组合。本文则反其道而行之，提出最简单的架构可能就是最优解。这种少即是多的视角在当前追求复杂代理趋势下显得格外突出。此外，本文还填补了系统比较三种代理范式的空白，之前的评估通常只关注单一类型的代理，而本文在相同LLM骨干网络、相同任务集、相同评估协议下进行公平对比。
核心方法
本文提出的StarShell是一个最小化的终端代理环境，其核心思想是让LLM代理直接通过终端和文件系统与平台API交互，而不是通过预定义的工具或GUI抽象。StarShell的整体设计非常简洁：代理接收任务描述和执行上下文，然后迭代生成命令或代码片段来执行。典型的操作包括查询平台API、过滤结果、更新记录或生成自动化脚本。API响应和执行输出作为观察结果返回给模型，支持迭代推理和修正。文件系统提供持久任务状态，代理可以读取文档、缓存中间结果、持久化可重用的技能如脚本或记录先前发现的解决方案的笔记。这种设计避免了预定义action schemas的限制，代理可以通过阅读文档或检查API响应动态发现平台能力。
本文的核心创新点在于证明了直接API交互结合强大的基础模型就足以实现企业自动化，不需要引入额外的抽象层。与MCP工具增强代理不同，StarShell不依赖预定义的操作schema，而是让模型在REPL风格的循环中通过curl命令直接调用平台REST API。与GUI代理不同，StarShell不需要处理大型可访问性树和截图，避免了高昂的token成本。这种直接API优先的设计将复杂度从代理架构转移到了平台API的设计上，假设现代企业平台已经暴露了足够表达性的API来支持程序化查询、数据更新和复杂操作。另一个关键创新是引入了基于文件系统的技能积累机制。
方法步骤详情
StarShell的执行流程可以分为以下几个步骤。首先，代理初始化，接收任务描述和执行上下文，这通常包括目标平台的基本信息和可选的文档访问路径。其次，代理进入观察推理行动循环：观察阶段，代理查看当前文件系统状态和可用的终端命令；推理阶段，模型分析任务需求，规划下一步操作；行动阶段，代理执行生成的命令，如curl调用平台API、python脚本处理数据或shell命令管理文件系统。第三步是获取反馈，执行结果返回给模型作为新的观察。第四步是迭代修正，模型根据反馈评估进度，可能需要调整策略、重试失败操作或回滚错误操作。最后，当任务完成或达到执行限制时，代理可以可选地将新发现的知识写入技能目录。
技术新颖性
本文的技术新颖性体现在多个方面。首先，这是首个系统性比较GUI代理、MCP代理和终端代理三种范式的工作，在统一的评估框架和四种前沿LLM上提供了全面的基线对比。其次，本文引入了基于文件系统的技能积累机制，并量化评估了其对企业自动化性能和成本的影响，发现记忆可以降低ServiceNow上43.7%的成本和ERPNext上5.8个百分点的成功率。第三，本文对文档访问效果进行了深入分析，发现文档的影响因平台而异。最后，本文详细分析了终端代理的失败模式，发现失败主要由任务难度而非工具不可靠性驱动。
实验结果
本文的核心发现是终端代理在企业自动化中提供了最佳的成本性能权衡。在三个企业平台和四种LLM骨干网络的评估中，终端代理匹配或超越了更复杂架构的成功率，同时持续保持更低成本。具体而言，终端代理在12个平台模型组合中的7个达到了最高或并列最高的成功率。使用Claude Sonnet 4.6时，终端代理在ServiceNow上的成功率为73.6%，远高于MCP代理的11.5%，略高于Web代理的72.4%，但成本仅为Web代理的17%。使用Claude Opus 4.6时，终端代理在所有三个平台上都达到了最高成功率，同时成本显著低于Web代理，在ERPNext上为0.72美元对比6.49美元，相差9倍。使用Gemini 3.1 Pro时，终端代理达到了最经济高效的配置，在所有平台上平均成功率为77.5%，每任务成本仅为0.09美元。文档访问的效果因平台而异，持久技能记忆在所有平台上都提高了成功率，同时显著降低成本。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| ServiceNow企业自动化任务 | 成功率百分比和成本美元 | 73.6%至79.1%成功率，0.78至1.94美元成本 | MCP: 11.5%至18.5%成功率，0.66至0.76美元成本; Web: 69.4%至77.6%成功率，0.54至4.49美元成本 | 终端代理比MCP提升56至67个百分点，比Web持平或略优但成本降低56%至83% |
| GitLab开发任务 | 成功率百分比和成本美元 | 71.3%至80.2%成功率，0.06至0.50美元成本 | MCP: 45.2%至48.9%成功率，0.15至0.90美元成本; Web: 81.4%至84.6%成功率，0.17至0.88美元成本 | 终端代理比MCP提升23至35个百分点，比Web略低2至9个百分点但成本降低47%至68% |
| ERPNext企业资源规划任务 | 成功率百分比和成本美元 | 67.6%至76.8%成功率，0.10至0.72美元成本 | MCP: 55.6%至68.9%成功率，0.07至0.21美元成本; Web: 61.8%至81.6%成功率，0.51至6.49美元成本 | 终端代理比MCP提升2至12个百分点，比Web持平或略低5个百分点但成本降低60%至89% |
| 持久技能记忆效果 | 成功率提升和成本降低 | 1.6pp至5.8pp成功率提升，16.8%至43.7%成本降低 | 无记忆基线 | 在ServiceNow上成本降低最多43.7%，在ERPNext上成功率提升最多5.8pp |
局限与改进
本文作者承认了几个重要局限性。首先，某些平台操作本质上是浏览器会话绑定的，没有API等价物。例如ServiceNow的模拟用户功能，终端代理发现了看似正确的端点并收到HTTP 200响应，但模拟未生效，因为这需要浏览器会话cookie交换。其次，需要读取渲染UI元素的任务对终端代理来说根本不可访问。第三，涉及复杂UI界面交互的任务无法通过终端代理完成。作者还指出，终端代理具有广泛执行能力，这引入了意外或有害操作的可能性，因此必须在API级别强制执行安全和访问控制。评估方面，由于评估矩阵规模庞大，详尽的多种子评估并不可行，因此小的差异应谨慎解读。
独立分析的弱点
独立分析显示，本文方法有几个潜在弱点。首先，终端代理完全依赖于平台API的表达能力和稳定性，如果平台API设计不佳、文档不完整或存在版本不兼容，代理的性能会大幅下降。改进方向可以是引入更智能的代码生成和调试能力。其次，终端代理无法处理需要视觉理解的任务。改进方向可以是开发混合代理，结合程序化API和浏览器视觉能力。第三，技能积累机制虽然有效，但缺乏技能验证和冲突解决机制。改进方向可以是引入技能验证测试和版本控制。第四，评估基准虽然涵盖三个真实平台，但可能无法代表所有企业场景，特别是需要跨平台协调的任务。
未来方向
作者提出了几个有前景的未来研究方向。首先，企业自动化经常需要长时间跨度的代理，这些代理需要跨多个平台协调行动，在扩展交互中维护状态，并纳入人工监督。开发能够捕获这些属性的基准，并将评估扩展到更多企业垂直领域至关重要。其次，结合程序化和基于浏览器的工具可能是一个有前景的方向，允许代理为每个子任务选择最有效的交互模式。第三，需要进一步研究AI友好的文档设计。第四，技能积累机制可以扩展，包括技能共享、技能市场和技能质量评估。最后，安全和访问控制需要作为补充层集成到终端代理抽象之上。
复现评估
本文承诺将在论文被接受后发布完整的评估框架、评估数据集、环境、提示词和文档，以促进可重复性和企业代理系统的进一步研究。所有实验中使用的提示词都包含在附录I中，并将与源代码一起发布。任务定义、成功标准和评估程序在评估框架中完全指定，所有评估指标和评分脚本在给定模型输出的情况下是确定性的。所有代理都在完全容器化的环境中执行，以防止跨任务污染。然而，由于评估矩阵的规模，详尽的多种子评估并不可行。因为任务结果是二元的，作者使用样本比例估计器报告成功率的标准误差。对于ServiceNow、GitLab和ERPNext环境，成功率约为80%时，标准误差分别约为2.2、2.9和2.8个百分点。实验通过LiteLLM框架执行。总体而言，本文的可复现性承诺很强，但实际复现可能需要相当的计算资源和对企业平台API的访问权限。
论文图表
