← 返回 2026-03-17

EnterpriseOps-Gym:面向企业场景的有状态智能体规划与工具使用评估环境 EnterpriseOps-Gym: Environments and Evaluations for Stateful Agentic Planning and Tool Use in Enterprise Settings

Shiva Krishna Reddy Malay, Shravan Nayak, Jishnu Sethumadhavan Nair, Sagar Davasam, Aman Tiwari, Sathwik Tejaswi Madhusudhan, Sridhar Krishna Nemala, Srinivas Sunkara, Sai Rajeswar 📅 2026-03-13 👍 149 2026-07-13 08:36
企业应用 基准测试 工具使用 智能体 规划推理

首个大规模企业级智能体基准,揭示当前最强模型仅37%成功率,规划而非工具调用是核心瓶颈

前置知识

Agentic Planning(智能体规划)

智能体规划是指 LLM 代理在接收到用户指令后,将其分解为一系列有序的工具调用步骤,并在执行过程中根据中间结果动态调整策略的能力。与简单的单轮问答不同,规划需要考虑步骤间的依赖关系、前置条件验证、以及副作用管理。在企业场景中,规划的正确性直接影响业务流程的完整性和数据一致性,一个遗漏的步骤可能导致数据库状态不一致或违反业务规则。

本文的核心发现就是规划能力是智能体的主要瓶颈,而非工具调用本身。理解规划的概念才能理解为什么人工编写的计划能带来14-35个百分点的性能提升。

Stateful Tool Use(有状态工具使用)

有状态工具使用指智能体在执行多步操作时,工具调用之间存在持久的状态依赖。例如在企业系统中,创建一个客户案例后,后续的知识库关联、SLA配置、通知发送都依赖于这个案例的存在和正确状态。与无状态的API调用不同,有状态场景下每一步操作都会改变系统状态,且这些改变是不可逆的,错误会级联传播。

EnterpriseOps-Gym 的核心特征就是164张数据库表构成的有状态环境,智能体必须在执行过程中追踪和管理这些状态变化,这是该基准与现有工具调用基准的本质区别。

Outcome-based Verification(基于结果的验证)

基于结果的验证是一种评估方法,不检查智能体是否按照预定路径执行,而是检查任务完成后的系统最终状态是否满足所有要求。验证通过SQL脚本实现,检查目标完成、状态完整性、权限合规、以及是否有副作用。这种方法允许多条有效的执行路径,更贴近真实场景中对结果的关注。

这是EnterpriseOps-Gym评估方法的核心创新,使得评估更关注实际业务结果而非执行轨迹的匹配度,也使得人工编写的计划能够作为参照但不强制唯一路径。

Infeasibility Detection(不可行任务检测)

不可行任务检测指智能体识别某些请求因工具不足、策略冲突或资源不可用而无法完成,并选择拒绝执行而非强行尝试的能力。这类任务通常包含多个相互冲突的约束条件,例如要求在系统迁移模式下执行写操作,或要求违反访问控制策略。正确拒绝不可行任务是企业部署安全性的关键。

本文设计了30个不可行任务来专门评估这一能力,结果表明即使是最好的模型也只有53.9%的拒绝成功率,这直接关系到智能体在企业环境中的安全部署。

ReAct Loop(推理-行动循环)

ReAct(Reasoning and Acting)是一种将推理和行动交替进行的智能体执行范式。在每一步中,智能体先进行推理(思考当前状态、分析下一步应该做什么),然后执行一个工具调用,观察结果后再进行下一轮推理。这种循环式执行模式是当前主流智能体框架的基础,本文的所有实验都基于这种范式。

理解ReAct范式是理解本文实验设置的基础,论文在ReAct基础上测试了多种增强策略(如加入规划器、任务分解等),发现复杂编排反而可能降低性能。

研究动机

当前LLM智能体在企业环境中的部署面临严峻挑战,现有基准测试无法真实反映企业场景的复杂性。在工具调用评估方面,API-Bank仅有73个工具和3层平均步骤,ACEBench虽然扩展到4538个工具但只有0个数据库表和0个外键约束,完全忽略了状态依赖问题。企业专用基准如WorkArena专注ServiceNow单一平台、仅33个任务和30个工具,CRMArena聚焦Salesforce且无策略约束评估。这些基准的共同缺陷是:数据库表数量不足25个,工具数量少于50个,任务步长短且缺乏策略约束。然而真实企业环境中,智能体需要在164张相互关联的数据库表上执行操作,遵循严格的访问控制策略,并在长达34步的复杂工作流中保持状态一致性。例如在客户服务管理场景中,智能体不仅要执行多步工作流(搜索案例、检索知识库、通知客户),还必须遵循三级策略规则来标记知识库文章,并独立解析隐藏信息(如从案例记录中推断客户邮箱)。现有基准完全无法捕捉这类场景的复杂性。

本文的目标是本文的目标是构建一个高保真的企业模拟环境来评估智能体的规划能力,具体包括:构建包含8个企业领域(客户服务、人力资源、IT服务管理、邮件、日历、Teams、Drive和跨域混合任务)的评估基准,覆盖1150个专家策划的任务;设计包含164张关系数据库表和512个功能工具的沙盒环境,平均每个任务涉及24.9张表和3443行数据;实现基于SQL的结果验证机制,检查目标完成、状态完整性、权限合规和副作用;评估14个前沿模型的表现,识别系统性失败模式并提供可操作的改进方向。

与已有工作不同的是,本文的独特切入点在于同时满足三个被现有工作忽视的关键维度。第一是环境规模和保真度:EnterpriseOps-Gym的164张数据库表是现有企业基准的6-7倍,512个工具是10倍以上,平均外键密度1.7也高于所有现有基准,这意味着智能体必须处理更复杂的表间依赖关系。第二是策略约束的显式评估:不仅包含30个专门设计的不可行任务来测试拒绝行为,还在每个任务中嵌入平均5.3个验证条件,最多可达44个,直接评估智能体对访问控制、流程合规等策略的遵循能力。第三是人类专家计划的引入:这是唯一提供人工编写自然语言计划的基准,通过对比智能体在有人类计划和无人类计划条件下的表现,能够精确定位规划能力与执行能力的瓶颈差异。这种三维切入方式使得本文不仅是一个评估工具,更是对智能体能力瓶颈的诊断框架。

核心方法

EnterpriseOps-Gym的构建方法可以类比为建造一个企业级的'飞行模拟器':不是让智能体直接在真实企业系统上操作(风险太大),而是构建一个尽可能逼真的沙盒环境来测试其能力。技术路线分为四个层次。首先是领域选择,基于三个原则(行业相关性、策略复杂度多样性、领域专家可用性)选定了8个互补领域:运营类(CSM、HR、ITSM)代表企业运营骨干,协作类(Email、Calendar、Teams、Drive)代表通用生产力工具,Hybrid类要求跨域协调执行。其次是环境构建,与专业数据标注公司Turing合作,组建160人以上的团队,包括软件工程师构建环境和领域专家(SME)设计任务,创建了容器化的Docker沙盒,每次任务运行时初始化全新的数据库实例以防止状态泄漏。然后是任务设计,遵循'场景设计→真值执行→计划编写→结果验证→质量保证'的五步流水线,由领域专家设计复杂场景、手动执行并记录完整轨迹、编写SQL验证脚本,经过多轮质量审核。最后是评估框架,采用基于结果的SQL验证而非轨迹匹配,允许多条有效路径,同时区分任务完成、完整性约束和策略合规三类验证器。

本文最核心的创新是通过'计划解耦实验'精确定位了智能体的能力瓶颈。具体做法是:在标准ReAct循环基础上,引入三种增强配置——(1)自动化规划器(由Claude Sonnet 4.5生成计划)、(2)人工编写的专家计划、(3)更复杂的多智能体编排(包括规划器+执行器、规划器+分解器+子任务执行器)。关键发现是:人工计划带来14-35个百分点的提升,远超自动化规划的6-13个百分点;小模型Qwen3-4B在人工计划条件下与更大模型表现相当;而更复杂的多智能体编排不仅未能缩小差距,任务分解甚至导致CSM领域性能从16.7%下降到16.2%。这揭示了一个本质洞察:当前智能体的瓶颈是约束感知的计划生成(constraint-aware plan generation),而非工具调用本身的精确性。当规划能力被外部化(由人类提供)后,即使是小模型也能忠实执行,说明现代LLM在指令遵循和工具调用方面已有广泛能力,真正的短板在于对策略约束、前置条件和副作用的推理能力。

方法步骤详情

EnterpriseOps-Gym的评估流程包含以下关键步骤。第一步,领域与环境搭建:为每个领域创建真实的数据库模式,参考公开的企业API文档建模表结构、字段约束和工具行为,初始种子数据由SME设计,每个任务可动态扩展表和记录。环境以容器化Docker形式提供,每次运行独立初始化。第二步,任务设计:SME基于复杂度阈值(工具调用次数、验证条件数、状态依赖度、访问约束、策略冲突)设计场景,约束任务具有唯一的最终状态但允许多条有效路径,同时设计30个不可行任务(因工具不足、策略冲突或资源不可用而无法完成)。第三步,真值执行与计划编写:标注者在沙盒中手动执行每个任务,记录每步的工具调用、参数、响应和执行理由,同时编写自然语言推理计划,明确将每个动作锚定在系统约束、用户请求和可用工具上。第四步,结果验证:编写可执行的SQL验证脚本,在任务完成后检查环境最终状态,包括目标完成检查(主目标是否达成)、完整性约束检查(外键关系是否有效)、权限合规检查(是否避免了未授权操作)和副作用检查。第五步,评估执行:智能体在统一接口下运行,使用标准ReAct推理-行动循环,假设完美的工具检索器提供正确的工具集(oracle工具设置),报告三次运行的平均pass@1作为主要指标。

技术新颖性

EnterpriseOps-Gym在技术新颖性上体现在三个层面。第一,环境复杂度的量级跃升:164张数据库表和512个工具相比现有企业基准(最多25表、50工具)是一个数量级的提升,平均外键密度1.7意味着智能体必须解析更多的表间依赖关系来构建有效的工具参数。第二,首次系统性评估不可行任务拒绝行为:现有基准要么不包含不可行任务,要么不评估副作用,而本文专门设计了30个不可行场景并检查智能体是否在拒绝的同时不留副作用,这对企业安全部署至关重要。第三,计划解耦的诊断方法论:通过提供人工计划来外化规划能力,能够将性能瓶颈精确定位到'计划生成'而非'工具执行',这种诊断方法超越了单纯的性能比较,为改进方向提供了明确指引。此外,本文首次在企业基准中提供了成本-性能帕累托分析,揭示了Gemini-3-Flash在闭源模型中提供最佳性价比(31.9%性能,0.03美元/任务),DeepSeek-V3.2在开源模型中占主导(24.5%性能,0.014美元/任务),为企业部署决策提供了实用参考。

EnterpriseOps-Gym概览:有状态智能体规划与工具使用的基准
Figure 2: EnterpriseOps-Gym概览:有状态智能体规划与工具使用的基准
智能体编排架构对性能的影响
Figure 6: 智能体编排架构对性能的影响

实验结果

本文对14个前沿模型的评估揭示了多项关键发现。首先,整体表现远低于企业部署要求:最佳模型Claude Opus 4.5仅达到37.4%的平均成功率,闭源模型整体优于开源模型。在各领域中,协作类任务表现最好——Claude Sonnet 4.5在Teams达到51.0%、Drive达到52.1%,而策略密集型任务表现最差——ITSM最佳仅28.5%(Gemini-3-Flash),Hybrid跨域任务最佳30.7%(Claude Opus 4.5)。开源模型中,DeepSeek-V3.2 (High)以24.5%领先,GPT-OSS-120B (High)紧随其后达23.7%。其次,规划是主要瓶颈而非工具使用:添加干扰工具(+5、+10、+15个)对性能影响微乎其微,平均仅变化约1%,但提供人工计划带来14-35个百分点的提升。在Kimi-K2上,人工计划在CSM领域提升35.1个百分点(从7.1%到42.2%),在HR领域提升26.3个百分点。Qwen3-4B在人工计划条件下与更大模型表现相当,说明当规划被外部化后,执行能力不是瓶颈。第三,思维预算有领域特定的天花板:GPT-OSS-120B从低预算到高预算,Drive从8.6%跃升到41.0%,Calendar从8.7%到35.6%,但Email在中等预算达到峰值45.2%后回落,ITSM在1.1%→6.1%→6.1%处过早平台期。第四,不可行任务拒绝能力严重不足:最佳模型GPT-5.2 (Low)和DeepSeek-V3.2 (High)仅达到53.9%和53.8%,所有模型都远低于安全部署要求。第五,更复杂的多智能体编排未能弥补差距:规划器+执行器架构带来6-13%提升,但任务分解在CSM领域甚至导致性能从16.7%下降到16.2%,说明强顺序状态依赖会破坏分解策略。最后,性能随任务步长单调衰减:闭源模型从4步的约35%降至16步的不足20%,开源模型衰减更陡峭,Kimi K2和GPT OSS 120B在最大步长时收敛到约10%。

EnterpriseOps-Gym上智能体工具使用的性能-成本权衡
Figure 1: EnterpriseOps-Gym上智能体工具使用的性能-成本权衡
性能随规划步长单调衰减
Figure 4: 性能随规划步长单调衰减
思维预算对性能的影响
Figure 5: 思维预算对性能的影响
查看结构化数据
任务指标本文基线提升
整体平均(闭源最佳) pass@1 成功率 Claude Opus 4.5: 37.4% Gemini-3-Flash: 31.9% +5.5个百分点
整体平均(开源最佳) pass@1 成功率 DeepSeek-V3.2 (High): 24.5% GPT-OSS-120B (High): 23.7% +0.8个百分点
Teams领域 pass@1 成功率 Claude Sonnet 4.5: 51.0% Claude Opus 4.5: 50.0% +1.0个百分点
ITSM领域 pass@1 成功率 Gemini-3-Flash: 28.5% Claude Opus 4.5: 23.8% +4.7个百分点
Hybrid跨域 pass@1 成功率 Claude Opus 4.5: 30.7% Claude Sonnet 4.5: 28.1% +2.6个百分点
不可行任务拒绝 无副作用拒绝率 GPT-5.2 (Low): 53.9% GPT-5: 50.5% +3.4个百分点
人工计划增强(CSM) pass@1 提升 Kimi-K2 + 人工计划: 42.2% Kimi-K2 基线: 7.1% +35.1个百分点
自动化规划增强(CSM) pass@1 提升 Kimi-K2 + Claude计划: 19.6% Kimi-K2 基线: 7.1% +12.5个百分点

局限与改进

本文存在若干值得审视的局限性。首先,在环境保真度方面,虽然EnterpriseOps-Gym在规模上远超现有基准,但仍然是合成环境而非真实企业系统,数据库模式虽然参考了公开API文档但缺乏真实生产环境中的数据噪声、并发冲突和系统延迟等因素。其次,在评估设置上,oracle工具假设(完美检索器提供正确工具集)排除了工具发现这一重要挑战,在真实场景中智能体还需要从数百个工具中检索出相关工具,这可能进一步降低实际性能。第三,在任务设计上,虽然经过多轮质量审核,但160人团队在4个月内创建的1150个任务可能无法覆盖企业场景的全部复杂性,特别是缺乏真正的多用户并发交互和实时系统反馈。第四,在模型评估上,所有实验使用标准ReAct循环,未测试其他推理框架如Chain-of-Thought或Tree-of-Thought的组合效果;同时成本分析基于API定价,未考虑自托管部署的实际成本。最后,从失败模式分析的角度看,论文识别了四类失败模式(缺失前置查询、级联状态传播、错误ID解析、过早完成幻觉),但这些分类依赖于Claude Sonnet 4.5的自动标注,可能存在分类偏差,且未提供失败模式的定量分布数据。

独立分析的弱点

基于对论文的深入分析,我识别出以下几个关键弱点及其改进方向。第一,oracle工具设置过于理想化:实验假设完美检索器能提供正确的工具子集,但真实企业部署中工具检索本身就是挑战。改进方向是引入基于嵌入的工具检索器,在不同检索精度(如top-k召回率)下评估性能衰减程度,这将更真实地反映部署条件。第二,任务分解策略的评估不够充分:论文发现分解导致CSM性能下降,但仅测试了一种简单的'规划器+分解器+子任务执行器'架构,未探索更精细的分解策略如依赖感知的分解或动态子任务合并。改进方向是设计能够识别和保持状态依赖的任务分解算法,例如基于数据流图的分解而非简单的语义分割。第三,缺乏在线学习和错误恢复机制的评估:所有实验都是单次执行,不允许智能体在失败后重试或从中间状态恢复。在真实企业场景中,错误恢复能力至关重要,改进方向是设计包含错误注入和恢复评估的实验设置。第四,策略合规的评估过于二元化:验证器只检查最终状态是否合规,不区分'主动识别策略冲突并拒绝'和'碰巧执行正确'。改进方向是引入过程级验证,分析智能体的推理轨迹是否显式引用了策略约束。

未来方向

本文作者提出了三个明确的未来研究方向,我在此基础上补充若干延伸方向。作者指出的第一个方向是约束感知的计划生成(constraint-aware plan generation):需要开发能够在执行前显式推理策略约束、副作用依赖和前置条件结构的方法,这是解决规划瓶颈的关键。第二个方向是长时程状态管理(long-horizon state management):需要机制来维护多步工具调用之间的一致世界状态,如情景记忆或结构化状态表示,以防止随步长增加而积累的错误。第三个方向是安全拒绝和升级(safe refusal and escalation):智能体必须可靠地检测不可行或违反策略的请求并干净地拒绝,这一能力在所有评估系统中都很弱。基于本文成果,我建议以下延伸方向:(1) 自适应测试时计算分配——论文发现思维预算有领域特定的天花板,未来工作可以研究根据任务复杂度动态分配推理预算的策略;(2) 跨域知识迁移——Hybrid任务表现最差,可以探索在单域训练的策略如何迁移到跨域场景;(3) 人机协作模式——人工计划带来巨大提升,可以设计智能体在执行过程中主动请求人类澄清或确认的交互模式。

复现评估

在复现性方面,EnterpriseOps-Gym提供了较好的支持条件。作者明确表示将发布沙盒环境和评估工具,Docker容器化的设计确保了环境的可复现性,每次任务运行独立初始化数据库防止状态泄漏。数据方面,1150个任务包含完整的人工编写计划和SQL验证脚本,任务创建成本约100美元/个(总计约11.5万美元),标注团队来自专业公司Turing的160人以上团队。算力需求方面,评估14个模型的计算成本未在论文中披露,但从成本-性能分析图来看,单任务成本从0.007美元(Qwen3-235B)到0.36美元(Claude Opus 4.5)不等,完整评估集的成本需要进一步估算。复现的主要挑战在于:(1) 工具接口的完整实现可能依赖于特定的API规范,需要确认是否提供了完整的工具定义和模拟服务;(2) 验证脚本依赖于特定的数据库模式,扩展新任务需要领域专业知识;(3) 闭源模型的评估结果可能随模型版本更新而变化。总体而言,对于有ML工程经验的团队,复现基础评估流程是可行的,但扩展新领域或设计新任务需要投入显著的领域专家资源。