EnterpriseOps-Gym: Environments and Evaluations for Stateful Agentic Planning and Tool Use in Enterprise Settings

Paper: arXiv:2603.13594 Code: ServiceNow/EnterpriseOps-Gym Code reference: main @ 09593147 (2026-04-30)

1. Motivation (研究动机)

现有 Agent benchmark 很难回答一个企业部署中最关键的问题：LLM Agent 能否在有持久状态、权限规则、跨系统依赖和真实副作用的环境里稳定完成工作。许多 tool-use benchmark 把工具调用视为短序列 API matching，重点考察“会不会选对工具”或“能不能按格式调用 API”；但企业工作流更像数据库事务和业务流程编排：Agent 的一个错误写入会改变后续状态，错误 ID 会产生悬空记录，越权操作会违反组织政策，跨 Email、Calendar、Drive、ITSM、HR 等系统的依赖会让局部正确的动作组合成全局错误。

EnterpriseOps-Gym 要解决的具体问题是：构造一个可复现的企业 sandbox，让模型在真实风格的多步任务中操作工具、修改数据库，并用最终状态 verifier 判断是否真正完成目标、保持状态完整、遵守权限/流程政策、避免不良副作用。论文强调的不是一个新 Agent 算法，而是一个更接近企业真实风险的 evaluation environment：1,150 个专家构造任务、8 个企业域、512 个工具、164 张数据库表，并包含 30 个故意不可完成的任务来测试模型是否知道拒绝。

这个问题值得研究，是因为企业 Agent 的失败成本比普通问答高得多。Agent 一旦被部署为“AI worker”，它不只是生成建议，而是会创建 ticket、关闭 HR case、发邮件、更新知识库、安排会议或修改访问权限。若 benchmark 只奖励短程 tool-call accuracy，就会高估模型能力；EnterpriseOps-Gym 的价值在于把瓶颈从“能否调用工具”推向“能否在状态、政策、计划和副作用约束下可靠行动”。

Figure 1 解读：上半部分说明 benchmark 覆盖 8 个企业域，并由 domain experts 构造 sandbox、任务、ground-truth trajectory、human plan 与 SQL verifier；下半部分展示 Agent 接收系统政策和用户任务后，通过工具改变环境状态，最后由 final-state verifier 检查 goal completion、policy compliance 与 side effects。图中案例的关键失败不是“没有调用工具”，而是自动发现 KB article 后没有按政策设置正确参数，并且由于未解析 case 相关 email identifier 而无法正确通知客户。

2. Idea (核心思想)

核心洞见是：企业级 Agent 评测必须把“工具调用”提升为“状态化、政策约束的业务执行”。EnterpriseOps-Gym 不用单一平台的 UI 或静态 API question 来评估模型，而是在 Docker/MCP sandbox 中给 Agent 真实风格的数据表、工具和任务，让它产生会改变数据库状态的行动，再用 outcome-based SQL verifier 判断最终状态是否满足业务目标。

关键创新有三点。第一，任务不是模板化 API 练习，而是由 SME 和 annotator 经过 scenario design、ground-truth execution、human plan authoring、SQL verification、multi-stage QA 生成；第二，评估不是 action-sequence matching，而是允许多条有效路径，只要求最终状态、权限约束和副作用检查通过；第三，论文把 infeasible task、tool distractor、thinking budget、human/LLM plan-conditioned execution 与 multi-agent orchestration 放在同一 benchmark 中分析，从而定位瓶颈到底在 tool discovery、planning、policy compliance 还是 execution。

与 WorkArena / WorkArena++ 这类单平台企业环境相比，EnterpriseOps-Gym 的根本差异是跨域和关系状态密度：它覆盖 8 个域、512 个工具、164 张表，平均每个任务涉及 24.9 张表，Hybrid task 最高涉及 73 张表。与 ToolLLM、API-Bank、ACEBench 等通用 API benchmark 相比，它更强调持久状态、外键完整性、权限/流程政策和不可行任务拒绝，而不是短程 API 链接准确率。

3. Method (方法)

3.1 Overall framework：从任务构造到 final-state verification

EnterpriseOps-Gym 的整体框架可以理解为四层：任务层、环境层、Agent execution 层和验证层。任务层给出 user prompt、system policy、可用工具集合、数据库初始状态、human-authored plan 和 verifier；环境层提供容器化 MCP server、领域数据库和工具执行接口；Agent execution 层使用 ReAct 或 plan-conditioned ReAct 与工具交互；验证层在执行结束后运行 SQL / response / tool-execution verifier，判定最终状态是否满足目标和约束。

直觉上，这个设计把 Agent 放进一个“低风险的企业数据库副本”。模型不能靠输出一句看似合理的答案得分，因为所有重要状态都要落到数据库里；它也不能只完成主目标，因为 verifier 会检查外键、权限、状态转移和副作用。这使 benchmark 对企业场景中最常见的失败更敏感：未查 prerequisites 就创建记录、用未验证 ID 调工具、漏掉政策要求的级联动作、在任务不可行时仍然乱写状态。

3.2 Domain 与 sandbox construction

论文选择域时遵循三个原则：真实企业相关性、政策复杂度/数据敏感度多样性、以及是否能找到 SME 生成和验证真实任务。最终 8 个域分成两组：CSM、HR、ITSM 代表企业运营骨干，政策重、数据敏感、错误有高代价；Email、Calendar、Teams、Drive 代表所有企业都会用到的协作基础设施；Hybrid 则要求跨域编排，在多个系统之间保持上下文和数据完整性。

Sandbox 由专业 annotation vendor 与超过 160 名 contributors 参与构建，每个域平均约 20 名 annotators 和 6 名 reviewers。环境是 fully containerized Docker setup，包含领域数据库、API 和 MCP 工具执行层。SME 参考公开 API 文档、产品数据模型和企业使用方式，建模真实表结构、字段约束与工具行为；annotator 在任务构造过程中会按任务需要扩展表、schema、record 和工具。最终环境包含 164 张 unique tables，平均 foreign key degree 为 1.7，每个任务平均涉及 3,443 行数据库记录，数据重的 CSM 可超过 10,000 行。

Figure 2 解读：该图展示 1,150 个任务在 8 个企业域中的分布。它的用途不是证明某个域最多，而是说明 benchmark 同时覆盖“平台协作任务”和“高政策约束运营任务”；后者（CSM/HR/ITSM）在结果中也正是模型最容易失败的区域。

3.3 Task construction pipeline：scenario、trajectory、plan、verifier、QA

每个任务由一个严格 pipeline 产生。

• Scenario Design：annotator 设计多步任务，明确工具调用数量、verification condition、状态依赖、访问约束和政策冲突。任务被约束为有唯一最终状态，但允许多条有效执行路径。论文还专门设计 30 个 infeasible tasks，原因包括工具不足、显式政策冲突或资源不可用。
• Ground Truth Execution and Plan Authoring：annotator 在 sandbox 中手动执行任务，记录每次 tool call 的参数、返回值和执行理由，并写出 natural-language reasoning plan。这个 plan 不只是操作清单，还要引用 system prompt 中的政策，解释为什么某些动作必须先做、哪些约束优先级更高。
• Outcome-based Verification：annotator 写 SQL verification scripts 检查最终状态，而不是要求模型复现同一条 trajectory。verifier 覆盖目标完成、foreign-key / state integrity、permission compliance、process compliance 和 side effects。
• Quality Assurance：先用 GPT-5、Gemini、Claude 等模型 stress-test draft tasks，暴露任务定义错误、缺工具、无效数据库、access-control conflict 和过于简单的推理路径；再由 human reviewers 检查语法、工具逻辑、trajectory 正确性、prompt 清晰度与 verifier 覆盖。

3.4 Task / environment statistics

EnterpriseOps-Gym 规模和复杂度如下：

Item	Value	含义
Tasks	1,150	专家构造企业任务
Infeasible tasks	30	测试模型是否能拒绝不可完成请求并避免副作用
Domains	8	Teams, CSM, Email, ITSM, Calendar, HR, Drive, Hybrid
Tools	512	各域 toolset 范围从 Calendar 的 37 到 ITSM 的 93
Human trajectory length	平均 9.15 steps	Email 平均 6.2，CSM 平均 12.1，HR 最长可达 34
Verification conditions	平均 5.3 / task	最复杂任务需要满足 44 个条件
Database tables	164	每任务平均涉及 24.9 张表，Hybrid 最高 73
Rows per task	平均 3,443	CSM 等数据重领域可超过 10,000
Mean FK degree	1.7	Calendar 约 1.1，HR 约 2.4

Figure 3 解读：该图按域展示 human trajectory 所需 tool-execution steps 的分布。Email 和 Calendar 的任务长度较短、分布更集中；CSM 和 HR 更长且 heavy-tailed；Hybrid 与 ITSM 方差较大。这解释了为什么同一个模型在 collaboration 域能达到 51–52%，但在 ITSM/Hybrid 这类长程和跨域任务上明显下降。

3.5 Execution model：ReAct、plan-conditioned ReAct 与 decomposition

论文默认使用 oracle-tool setting：假设 perfect retriever 已经把正确工具集给到模型，从而把评估重点放在 planning 与 execution，而不是 tool discovery。released code 中 evaluate.py 将 orchestrator 映射到三类实现：react、planner_react、decomposing。

• react 是标准 Reason-Act-Observe loop：把 system prompt 和 user prompt 放进消息，模型每轮选择 tool calls，执行结果再作为 ToolMessage 反馈，直到模型停止调用工具或达到 max_iterations。
• planner_react 先让 planner LLM 根据 system policy、user task 和 available tools 生成 plan，再把该 plan 注入 executor 的 user prompt，让 executor 执行 ReAct。
• decomposing 进一步把任务拆成 subtasks，并为每个 subtask 调用 subagent/ReAct loop；论文发现这不一定更好，因为企业任务有强顺序状态依赖，错误 decomposition 会破坏全局 state progression。

Pseudocode: benchmark evaluation flow

def evaluate_domain(dataset, llm_config, domain, mode, orchestrator_cls, output_folder):
    results = []
    for sample in dataset.filter(lambda x: x["domain"] == domain):
        if skip_sample(sample, mode):
            continue
 
        config = load_config(sample["config_json"])
        executor = BenchmarkExecutor(
            config=config,
            llm_config=llm_config,
            orchestrator_class=orchestrator_cls,
            config_path=sample["config_path"],
        )
        result = await executor.execute_benchmark()
        results.append(result)
        write_json(output_folder, sample["task_id"], result)
    return results

Pseudocode: ReAct execution loop

async def react_execute(config, llm_client, available_tools, execute_tool_call, max_iterations):
    messages = [SystemMessage(config.system_prompt), HumanMessage(config.user_prompt)]
    conversation_flow, tools_used, tool_results = [], [], []
 
    for _ in range(max_iterations):
        response = await llm_client.invoke_with_tools(messages, available_tools)
        messages.append(response)
        conversation_flow.append({
            "type": "ai_message",
            "content": response.content,
            "tool_calls": response.tool_calls or [],
            "usage_metadata": getattr(response, "usage_metadata", {}),
        })
 
        if not response.tool_calls:
            break
 
        for call in response.tool_calls:
            exec_result = await execute_tool_call(call["name"], call["args"])
            tool_message = ToolMessage(
                content=json.dumps(exec_result["result"]),
                tool_call_id=call["id"],
            )
            messages.append(tool_message)
            tools_used.append(call["name"])
            tool_results.append(exec_result)
 
    return {
        "conversation_flow": conversation_flow,
        "tools_used": tools_used,
        "tool_results": tool_results,
        "final_response": messages[-1].content if messages else "",
    }

Pseudocode: planner-conditioned execution

async def planner_react_execute(system_prompt, user_prompt, tools, planner_llm, executor):
    planning_prompt = render_planner_prompt(
        system_policy=system_prompt,
        user_task=user_prompt,
        tools=tools,
        required_fields=[
            "intent analysis",
            "relevant policies",
            "risk assessment",
            "execution strategy",
        ],
    )
    plan = (await planner_llm.ainvoke([HumanMessage(planning_prompt)])).content
 
    executor.config.user_prompt = (
        f"{user_prompt}\n\n"
        f"# Strategic execution plan\n{plan}\n\n"
        "Follow this plan, but system policy remains highest priority."
    )
    result = await executor.execute()
    result["metadata"] = {"generated_plan": plan}
    return result

Pseudocode: verifier execution

async def run_verifiers(verifiers, model_response, database_id, mcp_clients, judge_llm):
    engine = VerifierEngine(mcp_clients=mcp_clients, llm_client=judge_llm)
    verifier_results = []
 
    for verifier in verifiers:
        if verifier.verifier_type == "database_state":
            sql = verifier.validation_config["query"]
            actual = await engine.execute_sql(sql, database_id, verifier.gym_name)
            passed = compare_values(
                actual,
                verifier.validation_config["expected_value"],
                verifier.validation_config.get("comparison_type", "equals"),
            )
        elif verifier.verifier_type == "response_check":
            sql_result = await engine.execute_sql(
                verifier.validation_config["sql_query"], database_id, verifier.gym_name
            )
            score = await judge_llm_compare(
                response=model_response,
                sql_result=sql_result,
                rubric=verifier.validation_config["comparison_prompt"],
            )
            passed = score >= verifier.validation_config.get("minimum_comparison_value", 7)
        else:
            passed = await check_tool_execution(verifier, model_response)
 
        verifier_results.append({"verifier": verifier.name, "passed": passed})
 
    return verifier_results

3.6 Outcome-based metrics as formalization

论文没有提出训练 loss；它是 benchmark / evaluation paper。核心评分可写成最终状态 verifier 的逻辑合取： $\mathrm{success}(x)=1\left[{\bigwedge }_{j=1}^{m_x}{v}_j(s_T,r_T)=1\right]$ 其中 $x$ 是任务，$s_T$ 是工具执行后的最终数据库状态，$r_T$ 是最终模型响应，$v_j$ 是 SME 写的 SQL / response / tool-execution verifier。主要指标是三次运行平均的 pass@1： $Pass@1=\frac{1}{N}{\sum }_{i=1}^N\mathrm{success}(x_i)$ 论文还报告 verifier-level pass rate，但明确指出它可能误导：模型可能通过一些简单 verifier，却在核心业务逻辑、系统政策或副作用检查上失败。因此主要结论都以“所有 verifier 均通过”的 task-level pass@1 为准。

3.7 Released code mapping and implementation notes

Code reference: main @ 09593147 (2026-04-30) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Benchmark runner / single-domain evaluation	evaluate.py	ORCHESTRATOR_MAP, load_config, execute_sample, CLI args
End-to-end executor	benchmark/executor.py	BenchmarkExecutor.initialize, execute_benchmark, MCP client setup, verifier execution
ReAct baseline	orchestrators/react.py	ReactOrchestrator.execute
Planner + executor baseline	orchestrators/planner_react.py	SimplePlanGenerator, PlannerReactOrchestrator.execute
Decomposition orchestration	orchestrators/decomposing_planner.py	subtask decomposition / subtask executor state management
SQL / response / tool verifier	benchmark/verifier.py	VerifierEngine.execute_verifier, _execute_database_state_verifier, _execute_response_check_verifier
MCP tool/database interface	benchmark/mcp_client.py	MCPClient, create_database_from_file, delete_database
Scoring result folders	compute_score.py	get_score, process_mode
Ray experiment templates	conf.example/ray/*.json	modes oracle, plus_5_tools, plus_10_tools, plus_15_tools; example num_runs=1

论文公式与 released code 实现差异：没有发现数学公式层面的直接冲突；但 released repo 只提供 example config，conf.example/ray/experiment.json 中 num_runs=1，而论文实验指标说明报告的是三次运行平均 pass@1。因此笔记中的实验结果以论文表格为准，不把 example config 当作论文复现实验的精确启动配置。另一个实现口径是 hybrid：README 要求 hybrid 用 direct evaluation，conf.example/ray/domain_conf.json 只列出七个单域 MCP endpoints，说明 cross-domain/hybrid 运行依赖额外组合配置，而不是单一 hybrid endpoint。

4. Experimental Setup (实验设置)

4.1 Dataset and scale

实验数据就是 EnterpriseOps-Gym 本身：1,150 个专家构造任务，覆盖 Teams、CSM、Email、ITSM、Calendar、HR、Drive、Hybrid 八个域；包含 30 个 infeasible tasks；动作空间有 512 个 unique tools；数据库环境包含 164 张 unique tables；human trajectory 平均 9.15 steps，每任务平均 5.3 个 verification conditions。任务由 SME 和 annotator 经过约四个月流程构造，每个任务的 scenario、ground-truth trajectory、human plan 和 SQL verifier 都经过自动 stress-test 与人工 QA。

4.2 Baselines

论文评测 closed-source 与 open-source/open-weight 模型。Closed-source 包括 Claude Opus 4.5、Claude Sonnet 4.5、GPT-5.2 High/Low、GPT-5、GPT-5-Mini、Gemini-3-Pro、Gemini-3-Flash、Gemini-2.5-Pro。Open-source/open-weight 包括 DeepSeek-V3.2 High/Medium、GPT-OSS-120B High、Kimi-K2-Thinking、Qwen3-30B Think、Qwen3-235B Inst.、Qwen3-4B Think。

系统层面的 baseline 包括：standard ReAct；oracle-tool mode；额外加入 +5/+10/+15 distractor tools 的 tool-overload ablation；GPT-OSS-120B 的 low/medium/high thinking-budget ablation；Planner+Executor；Planner+Decompose+Subtask Executor；Oracle Human Plan + Executor；以及针对较弱模型的 Claude Plan / Human Plan conditioned execution。

4.3 Metrics

主指标是 pass@1 task completion rate：只有当任务所有需求和所有约束 verifier 都通过时，得分才是 1。论文报告三次运行平均 pass@1。辅助指标是 verifier-level pass rate，用于分析 verifier 类型或局部条件的通过情况；但作者明确认为它不适合作为主指标，因为模型可能通过 trivial verifier 却没有真正完成业务目标或政策约束。Infeasible task 分数要求模型正确拒绝不可满足请求，并且不留下系统副作用。

4.4 Evaluation config and reproducibility details

Released repo 的可见运行方式是 Docker/MCP + Hugging Face dataset + Python evaluator。README 的 direct 命令使用 python evaluate.py --hf_dataset ServiceNow-AI/EnterpriseOps-Gym --domain <domain> --mode oracle --llm_config conf/llm/<model>.json --output_folder results/... --orchestrator react --concurrency 4 --num_runs 1；hybrid 示例把 concurrency 降为 2。Ray template conf.example/ray/experiment.json 支持 modes oracle, plus_5_tools, plus_10_tools, plus_15_tools，orchestrator 默认为 react，conf.example/ray/llm_concurrency.json 示例给单模型 concurrency 4。

论文未详细说明底层硬件，因为主要评测通过 API / model endpoints 运行；成本分析按每任务 token/API cost 估算。训练配置也不适用：本文不是训练新模型，而是发布 benchmark 和评估框架。可复现依赖包括 Python >=3.11、datasets、ray、langchain、httpx、各模型 provider SDK，以及每个 domain 的 Docker MCP server；README 列出的默认端口包括 CSM 8001、Teams 8002、Calendar 8003、Email 8004、ITSM 8006、HR 8008、Drive 8009。

5. Experimental Results (实验结果)

5.1 Main benchmark results

主表显示所有模型都远未达到可靠企业部署水平：最佳 Claude Opus 4.5 平均只有 37.4%，第二名 Gemini-3-Flash 为 31.9%，最强 open-source/open-weight DeepSeek-V3.2 High 为 24.5%。不同域差异很大：Email、Teams、Drive 的最好结果可达 51–52%，但 ITSM 最好只有 28.5%，Hybrid 最好只有 30.7%，说明政策/流程密集和跨域状态依赖是核心难点。

Model	Teams	CSM	Email	ITSM	Calendar	HR	Drive	Hybrid	Infeas.	Avg.
Claude Opus 4.5	50.0	34.2	51.9	23.8	43.2	32.1	49.5	30.7	50.0	37.4
Gemini-3-Flash	47.3	35.0	44.3	28.5	30.5	12.6	49.7	24.2	38.5	31.9
GPT-5.2 (High)	31.0	34.8	51.0	21.7	38.5	25.0	40.0	22.2	50.0	31.8
Claude Sonnet 4.5	51.0	16.7	51.3	17.6	34.6	21.6	52.1	28.1	46.2	30.9
GPT-5	26.3	36.4	49.0	18.9	41.3	17.9	34.0	23.5	50.5	29.8
Gemini-3-Pro	43.0	27.7	33.6	22.2	28.8	12.5	46.7	22.9	50.0	28.0
GPT-5.2 (Low)	25.0	21.2	43.3	6.7	28.9	13.0	26.7	20.9	53.9	21.9
GPT-5-Mini	25.7	15.8	47.4	8.9	28.8	10.7	23.8	22.5	47.4	21.3
Gemini-2.5-Pro	39.3	11.6	31.1	13.9	12.5	4.9	27.0	19.6	34.7	18.2
DeepSeek-V3.2 (High)	37.0	14.1	47.1	16.1	21.2	16.3	35.2	22.9	53.8	24.5
GPT-OSS-120B (High)	32.0	16.3	42.3	6.1	35.6	16.3	41.0	19.6	50.0	23.7
DeepSeek-V3.2 (Medium)	35.7	15.4	45.8	9.6	21.5	15.0	27.6	22.9	40.0	22.3
Kimi-K2-Thinking	30.0	7.1	51.0	12.2	15.4	8.2	39.6	15.7	30.5	19.5
Qwen3-30B (Think)	22.0	5.4	51.9	6.7	18.3	7.6	25.7	15.7	36.8	16.8
Qwen3-235B (Inst.)	28.0	4.7	38.1	9.3	15.7	7.8	23.8	17.7	30.5	16.1
Qwen3-4B (Think)	24.0	3.8	38.4	5.6	5.8	7.1	21.9	15.8	31.6	13.7

5.2 Horizon, thinking budget, and tool overload

Figure 4 解读：模型成功率随 human trajectory horizon 增长而下降。Closed-source 组均值从约 4 steps 的 35% 附近降到 16 steps 时低于 20%；open-source/open-weight 组下降更陡，Kimi K2 和 GPT-OSS-120B 等在最长 horizon 附近接近 10%。这说明 EnterpriseOps-Gym 的难点不是单步工具格式，而是长程序列中的错误累积和状态保持。

Figure 5 解读：GPT-OSS-120B 的 thinking budget 从 low 到 high 通常能提升任务完成率，复杂域在 low budget 下几乎无法工作，例如 CSM 1.1%、ITSM 1.1%、HR 0.0%。提升到 high budget 后，Drive 从 8.6% 到 41.0%，Calendar 从 8.7% 到 35.6%，Teams 从 4.0% 到 32.0%。但增长并非总是单调：Email 在 medium budget 达到 45.2% 后略降，ITSM 在 6.1% 附近早早 plateau，说明更多 test-time compute 不能替代缺失的约束推理能力。

Tool overload ablation 使用 Claude Sonnet 4.5，在 oracle toolset 上加入 +5/+10/+15 个由 Claude 检索出的相似 distractor tools。结果平均 completion rate 反而轻微增加约 1.0%，分别为 +0.07%、+2.35%、+0.64%，代价主要是输出 token 增加 4–9%。这支持论文的核心结论：当前瓶颈不是工具发现，而是计划、状态和政策约束。

5.3 Planning is the bottleneck

Figure 6 解读：Planner+Executor 通常优于单纯 ReAct；但 Planner+Decompose+Subtask Executor 并没有稳定提升，在 CSM 中甚至低于 base ReAct（16.2% vs. 16.7%）。这说明企业任务的子任务并不独立，许多动作依赖前序数据库状态和政策判断，强行 decomposition 可能打断必要的顺序推理。

计划条件实验进一步证实瓶颈在 planning。Claude-generated plan（CP）能给较弱模型带来 5–13 个百分点提升；human plan（HP）提升更大，达到 14–35 个百分点。

Model	Plan	CSM	ITSM	HR
Kimi-K2	CP	19.6 (+12.5)	18.1 (+5.9)	17.2 (+9.0)
Kimi-K2	HP	42.2 (+35.1)	29.1 (+16.9)	34.5 (+26.3)
Qwen3-30B	CP	15.2 (+9.8)	11.7 (+5.0)	17.9 (+10.3)
Qwen3-30B	HP	33.9 (+28.5)	20.9 (+14.2)	33.2 (+25.6)
Qwen3-4B	CP	16.8 (+13.0)	12.2 (+6.6)	19.6 (+12.5)
Qwen3-4B	HP	37.16 (+33.4)	23.3 (+17.7)	36.4 (+29.3)

5.4 Cost-performance frontier

Figure 7 解读：Claude Opus 4.5 是最高绝对性能点，37.4% 成功率但约 0.36 USD/task；Gemini-3-Flash 是 closed-source 中较好的性价比点，31.9% 且约 0.03 USD/task，比 GPT-5（29.8%, 0.16 USD）和 Claude Sonnet 4.5（30.9%, 0.26 USD）便宜 80–90%。Open-source/open-weight 中 DeepSeek-V3.2 High 为 24.5%、0.014 USD/task，GPT-OSS-120B High 为 23.7%、0.015 USD/task；Qwen3-235B Inst. 最便宜，0.007 USD/task，但平均只有 16.1%。

5.5 Failure modes and limitations

论文把失败模式归纳为四类：Missing Prerequisite Lookup（未先查询必要前置对象就创建记录，导致 broken foreign-key links）、Cascading State Propagation（某状态转移后漏掉政策要求的后续动作）、Incorrect ID Resolution（未通过工具解析正确 ID 就传入 tool call）、Premature Completion Hallucination（未执行完所有必要步骤就宣布完成）。这些失败都指向同一个问题：模型通常会“看起来会用工具”，但不能可靠维护业务状态机。

Verifier 类型分析显示，模型在 Permission and Process Compliance 上最弱：ITSM 的 policy compliance 只有 30.0，CSM 为 45.5，HR 为 50.4；相比之下许多域的 task completion 或 integrity score 更高。例如 Teams task completion 82.3、integrity 90.0、policy compliance 81.3；Drive integrity 87.8，但 policy compliance 66.7。最危险的是 infeasible task：最佳模型也只有 53.9% 能正确拒绝并避免副作用，距离无人监督企业部署仍很远。

Domain	Task Completion samples / score	Integrity samples / score	Policy samples / score
Teams	100 / 82.3	20 / 90.0	8 / 81.3
CSM	183 / 58.3	30 / 70.0	120 / 45.5
Email	103 / 70.9	17 / 76.5	12 / 79.2
ITSM	176 / 53.7	30 / 50.6	70 / 30.0
Calendar	104 / 71.5	8 / 62.5	19 / 76.1
HR	182 / 63.2	47 / 56.0	94 / 50.4
Drive	105 / 75.1	26 / 87.8	6 / 66.7
Hybrid	152 / 60.0	23 / 72.5	18 / 61.1

作者在 impact statement 中也指出潜在限制：如果系统只针对 benchmark 优化，可能 overfit 特定任务模式或 verifier；更强自动化也会带来对 AI 系统过度依赖的风险；大模型 agentic evaluation 本身有计算成本和环境影响。总体结论是，EnterpriseOps-Gym 证明当前 frontier agents 即使在 oracle tool access 下仍不适合自治企业部署，下一步提升重点应是 constraint-aware planning、policy-grounded execution 和安全拒绝，而不仅是扩大工具检索或增加 orchestration 层数。