Command Palette
Search for a command to run...
终端 Agent 足以胜任企业自动化任务
终端 Agent 足以胜任企业自动化任务
Patrice Bechard Orlando Marquez Ayala Emily Chen Jordan Skelton Sagar Davasam Srinivas Sunkara Vikas Yadav Sai Rajeswar
摘要
近年来，构建能够与数字平台交互并自主执行具有实际意义的企业任务的 Agent 引起了广泛关注。现有探索方向包括基于模型上下文协议（Model Context Protocol, MCP）等抽象机制构建的工具增强型 Agent，以及通过图形用户界面（GUI）运行的 Web Agent。然而，考虑到此类复杂 Agent 系统所带来的成本与运维开销，其必要性仍有待验证。本文主张，仅配备终端（terminal）和文件系统（filesystem）的 Coding Agent，通过直接调用平台 API，能够更有效地解决众多企业级任务。我们在多种真实世界系统中对该假设进行了评估，结果表明，这类低层级的终端 Agent 在性能上可媲美甚至超越更为复杂的 Agent 架构。研究结论表明，结合强大的基础模型（foundation models），简单的程序化接口已足以支撑实用的企业自动化场景。
一句话总结
ServiceNow 和 Mila 的研究人员提出了 StarShell，这是一种极简的终端智能体。它通过直接与企业合作 API 交互，在性能上超越了复杂的 GUI 和工具增强型系统，证明了简单的程序化接口结合强大的大语言模型（LLM）足以在 ServiceNow 和 GitLab 等平台上实现高效、低成本的自动化。
主要贡献
- 论文证明，直接与 API 交互的简单终端智能体在企业自动化中既有效又高效。通过对前沿 LLM 的系统评估，其表现优于基于 MCP 的工具增强型智能体，并在大幅降低成本的同時，达到或超越了 Web 智能体的性能。
- 引入了一个统一的基准测试，涵盖多个生产平台，包含经过验证的评估环境和数据集，旨在捕捉真实的企任务。
- 探索了终端智能体的实用扩展，包括集成基于文件系统的文档访问，以及智能体创建自身可复用技能的能力。
引言
企业自动化日益依赖由 LLM 驱动的智能体在生产系统中执行复杂的多步骤任务，其中可靠性和成本效益至关重要。先前的方法通常依赖 GUI 驱动的导航或工具增强型框架（如模型上下文协议 MCP），这些方法引入了脆弱的动作链，将表达能力限制在预定义的操作内，并产生高昂的运营开销。作者利用一个极简的基于终端的编码智能体，通过与平台 API 直接交互，证明了简单的程序化接口结合强大的基础模型可以匹配甚至超越这些复杂架构。他们的工作引入了跨多个生产平台的统一基准，并表明直接 API 交互为广泛的现实企业任务提供了更优越的灵活性、弹性和成本效益。
数据集
-
数据集构成与来源：作者在三个企业平台上评估智能体：ServiceNow、GitLab 和 ERPNext。这些环境涵盖了 IT 服务管理、软件开发生命周期管理和企业资源规划。该数据集结合了来自先前 ServiceNow 和 GitLab 基准的改编任务，以及为 ERPNext 新构建的基准。
-
每个子集的关键细节：
- ServiceNow：包含 330 个任务，源自 33 个模板，改编自先前的工作，但重新设计以支持程序化验证。
- GitLab：包含 192 个任务，改编自现有基准，并更新了评估流程。
- ERPNext：包含 207 个全新任务，由专业语言学家从头设计，涵盖多样化的记录类型和工作流复杂度。
- 任务类型：所有子集均包括记录创建、检索、更新、删除、过滤、排序、导航以及多步骤复合工作流。
-
在模型中的使用：作者将这些环境用作评估基准，而非训练数据。每个任务都要求智能体检查系统状态、检索信息并执行操作以修改平台记录。评估依赖于针对实时平台实例的程序化验证，而非硬编码值或浏览器脚本。
-
处理与设计策略：
- 导航要求：每个任务都省略了起始 URL 或直接链接，迫使智能体仅根据自然语言目标识别相关的 API 端点或页面。
- 消除歧义：目标描述经过系统性重写以消除歧义，例如指定确切的表名而非通用术语。
- 文档集成：为每个平台提供本地文档语料库，通过抓取官方文档或仓库获得，并将其转换为带有 YAML 前缀的 Markdown 格式。
- 环境设置：所有平台均在容器化实例中运行，具有隔离的数据、API 访问权限、可选的 MCP 工具注册表，以及按主题层级组织的标准化文档。
方法
作者评估了三种不同的智能体交互范式，以确定企业自动化的最有效方法：工具增强型智能体（MCP）、Web 智能体和终端智能体。工具增强型智能体依赖通过 MCP 服务器暴露的精选 API 工具集，这简化了执行过程，但将智能体限制在预定义的功能内。Web 智能体通过图形界面运行，观察渲染后的 UI 并发出点击或输入等低级操作。相比之下，所提出的方法专注于一个通过终端和文件系统运行的简单编码智能体。该智能体编写并执行代码以直接与平台 API 交互，从而实现灵活的交互和探索，无需依赖 GUI 或预定义的工具注册表。
对特定任务上这些范式的比较分析证明了终端方法的高效性。
如框架图所示，MCP 智能体因缺乏可用的订单工具而无法完成订单，而 Web 智能体因 UI 复杂性和提交错误在 25 步后失败。终端智能体通过查询目录 API 并直接处理 JSON 负载，在 11 步内成功完成任务，实现了更低的成本和更快的执行时间。
该终端智能体的核心实现是 StarShell，这是一个专为企业自动化设计的极简编码智能体环境。该系统通过包含规划、执行、检查和迭代的 REPL 风格循环运行。
如下图所示，该架构依赖于一个极简接口，包括用于命令执行的终端和用于存储工件的文件系统。智能体接收任务描述，并迭代生成要运行的命令或代码片段。典型操作包括查询平台 API、过滤结果和更新记录。API 响应和执行输出作为观察结果返回给模型，从而实现迭代推理和修正。
设计的一个关键组件是持久技能目录。文件系统提供持久的任务状态，允许智能体读取文档、缓存中间结果，并持久化可复用的技能，例如捕获先前发现解决方案的脚本或笔记。与基于工具的智能体不同，StarShell 不依赖预定义的动作模式。相反，它通过阅读文档或检查 API 响应来动态发现平台功能。这种设计允许智能体组合那些可能未包含在精选工具注册表中的操作，促进与 GitLab、ServiceNow 和 ERPNext 等平台的直接 API 集成。
评估环境在每次任务前完全重置，以确保独立性。验证器在智能体完成前后检查平台状态，而不是检查智能体的动作。对于 ServiceNow 和 GitLab 等平台，验证器会对实时实例发出 API 调用，以验证是否创建或更新了预期记录。对于 ERPNext，验证器直接对数据库执行 SQL 查询。对于面向读取的任务，验证器解析智能体的最终消息以提取返回的答案或 URL，并将其与真实值进行比对。这确保了任务是根据实际平台状态进行评估的，而不仅仅依赖字符串匹配。
实验
- 交互范式的比较验证了终端智能体提供了最佳的成本效益权衡，其成功率匹配或超过了 Web 智能体，同时避免了浏览器渲染的高推理成本和 MCP 智能体的刚性工具限制。
- 对文档访问的评估显示，其效用取决于平台；面向任务的文档在某些平台上提高了性能，而参考式文档可能会误导智能体，并通过鼓励次优的 API 策略而增加成本。
- 关于持久内存的实验表明，允许智能体存储和重用自生成的技能显著提高了成功率并降低了成本，特别是在 API 不熟悉或字段映射复杂的平台上。
- 对失败模式的分析证实，任务失败源于智能体无法取得逻辑进展，而非工具不可靠，因为成功和失败任务中的工具调用错误率相似。
- 单智能体与多智能体系统的比较显示，规划器 - 执行器架构为较弱的模型在复杂的多步骤工作流上提供了适度的提升，但在使用更强的 LLM 骨干时，相比单智能体几乎没有优势。
- 混合智能体实验表明，结合终端和浏览器访问可以解决仅靠 API 无法完成的任务，但其效率很大程度上取决于模型能否正确地将子任务路由到适当的工具。