基准框架：MCPMark（https://github.com/eval-sys/mcpmark)

一、整体介绍

本数据集基于 MCPMark 框架构建。MCPMark 是目前业界最系统的 MCP（Model Context Protocol）压力测试基准，由 NLP 领域顶级团队主导设计，旨在评估大模型在真实 MCP 工具链中的 Agent 能力。MCPMark 的权威性体现在以下几点：

• 主流厂商参与对标：Claude Opus、GPT 系列、Gemini 系列均在其榜单中参与评测，是衡量模型 Agent 能力的行业参照坐标。

• 真实工程场景：任务覆盖 Filesystem、PostgreSQL、GitHub、Playwright 四类真实工作场景，而非人造竞赛题。

• 严格的程序化验证：每个任务配套 verify.py，pass/fail 由确定性规则判定，排除主观因素。

• 多步骤工具调用链：每条 trajectory 包含完整的"思考 → 调用工具 → 观察结果 → 迭代修正"过程。本数据集在 MCPMark 框架基础上，针对MCP识别以及调用能力特征进行任务筛选与难度校准，聚焦于符合真实场景、依赖MCP且有较高难度的任务，生产出具有最高训练价值的 SFT/RL 数据。Playwright 作为浏览器交互执行载体，可支持多页面导航、信息提取与流程闭环，能够有效还原真实 Web 操作场景。作为本数据集的 MCP Server，用于训练模型在真实网页上的浏览能力，以及对页面信息的提取、整理与进一步计算分析的能力。

二、数据详情（500条）

类别

500 个任务覆盖了 22 个不同 category，任务间无明显重复：

其他：课程调度、新闻排版、软件包架构分析、Django 回滚审计、事件最小修复、版本演进分析、Wiki 数据推理、创意静态操作、后台异常分析、舞台编排、依赖桥接、官方档案过滤等

难度

任务整体聚焦于 L3 中高难度区间：

• 这是经过专家试标后筛选出的"最具训练价值"的难度区间——既对模型构成真实挑战，又不至于让模型完全无从下手。L3 任务的核心特征在于多步骤工具调用链和跨页面状态管理。模型需要在单次会话中完成"导航→提取→推理→输出"的完整闭环，任何中间步骤的失误都会导致最终验证失败。

• 例如 Wikipedia 链接链探索任务要求访问 15+ 页面并逐一核验 6 个约束条件；大规模表格导出任务需要在分页加载和数据一致性之间保持精确同步。

• 部分任务在 L3 基础上进一步拓展了更高的难度上限，表现为多轮迭代修正能力要求、多维度交叉推理、以及 Cell 级精确验证等特征。这些挑战性任务主要分布在 web_analysis 和 web_investigation 类别。

Tips:Turns：模型交互的轮数，包含最终的 answer 输出

Tool calls：模型的工具调用次数

PassRate@4

Tool calls

Turns

三、数据生产

3.1 复合型专家设计团队画像

本次数据集所有任务均由具备"人类复杂网页交互思维+工程化落地能力"的复合型技术专家设计，专家核心要求如下：

1. 专业背景：计算机/理工科相关专业，具备Web自动化、前端开发、测试开发/爬虫项目经验，或拥有复杂信息检索与多源推理分析能力；

2. 核心能力：

• 任务设计能力：将真实Web交互抽象为标准化评测任务，覆盖多级导航、跨页面提取、多条件筛选，保证任务唯一解、合理难度、交互复杂度；

• Playwright工程能力：精通DOM解析、选择器定位、多窗口/Iframe处理，能应对动态加载/事件驱动的Web场景；

• 环境搭建能力：可构建本地隔离沙箱，复现稳定的Web交互场景，完成脚本调试与问题定位；

• 验证判分能力：使用Python编写自动化校验逻辑，实现对模型输出的结构化、标准化验证。

3.2 生产流程

为保证 Playwright 评测数据的专业性、稳定性与区分度，所有任务均由专家按统一规范设计并经多轮审查，形成标准化生产流程：

3. 专家基于真实网页交互场景构建任务，严格控制难度与复杂度，确保人工可稳定完成；

4. 采用统一目录结构与标准文件配置，保障任务可追溯与系统可调度；

5. 指令仅描述目标与约束、不暴露解题路径，明确工具边界以保证评测真实；

6. 依托静态页面或可控环境搭建可复现场景，消除外部依赖与随机干扰；

7. 验证脚本采用 All-or-Nothing 判分策略，结合结构化解析与多维校验保障公平可靠；

8. 最终经多轮人工与模型测试审查后，发布标准化评测任务。

3.3 质量控制流程

为确保 Playwright 评测数据集具备高可靠性、低噪声与良好区分度，项目建立全流程质量控制机制，对任务从产出到入库进行严格管控：

1. 任务先经集中存储、版本管理与自动化格式校验，再通过 Claude Code 完成静态代码机审，随后与题库比对相似度以保障丰富性；

2. 进入人工复审与难度校准阶段：

• 一致性：description.md、meta.json 与 verify.py 在任务目标、执行路径与判分标准上严格对齐；

• 边界覆盖：覆盖空结果、多解、格式差异及页面异常等情况，避免误判与漏判；

• 可解性：每道题目均由两名审核员进行网页实际访问验证。通过双重人工校验，确保任务路径闭环、数据表现稳定，并产出唯一确定的标准答案。我们设计了难度筛选与返修机制：对于在基准模型 Qwen3.5-Plus 上 pass@4 > 50% 的题目，判定为难度偏低，统一进入返修流程，指导专家进行题目难度调整与优化，确保任务具备充分的区分度与挑战性。在此基础上，引入基于模型的难度量化评估：

• 成功率（pass@4）：用于判断任务是否过易或不可解；

• 交互指标（turns / tool calls）：用于评估任务链路复杂度与探索空间，识别路径过短或异常循环等问题。通过"人工复审 + 模型验证"的联合校准机制，审核员从结果与过程两个维度对任务进行严格把控，确保数据在可解性、稳定性与复杂度上的一致标准，保障整体评测的专业性与可靠性。

3. 经真实环境可解性验证，未通过的任务退回专家修订形成闭环，通过后入库发布标准化评测数据集。

四、Sample Data

宁德时代股份回购金额查询

ApacheJMeter_core 依赖版本对比

药品审批多轮合规核验

NASA 任务巡航时间排名与重力辅助分析

arXiv 高引用 NLP 论文发现

五、cases 说明

Gemini turns 和 tool calls 异常突出

1) 环境配置与工具链正常，不是基础设施问题

从运行日志看，Playwright 相关依赖已正确安装并可用，且工具集完整加载（browser_install / browser_navigate / browser_run_code 等核心工具均可调用），无报错。同时，同批次存在可通过样本（如 59 turns 完成），因此可以判定瓶颈来自模型自身的调用策略，而非任务本身不合理或环境不可运行。

2) 失败主要由模型过度调用导致（snapshot / run_code 过多），触发 100 turn 上限

失败样本的共性不是"执行中断"，而是"执行过度"：模型在已获得部分有效信息后，仍持续进行高频、低增益的 snapshot 与 run_code 调用，且多次调用在目标与代码结构上高度重复，导致对话轮次和工具调用数同步拉满（典型为 100 turns / 100 tool calls）。这类轨迹反映的是策略不收敛：模型没有及时从"探索阶段"切换到"答案收敛阶段"，最终在规则上触发 Max turns (100) exceeded。因此，问题本质是模型执行策略偏离，而非任务本身不合理或环境不可运行。

GPT-5.4成功率分析

GPT 在执行复杂任务时，因理解不充分或路径规划失误而中途放弃，主要体现在以下几个方面：

4. 任务理解不充分导致早停：GPT 未能准确把握任务的整体结构与最终目标，对关键约束条件或隐含要求理解不完整。在执行过程中，一旦发现当前操作路径与预期结果出现偏差，往往倾向于直接停止，而不是进行回溯、修正策略或重新规划执行路径，表现出较弱的自纠错能力。

5. 低估任务复杂度与资源分配不足：GPT 容易对任务难度产生误判，未能合理预估所需的交互轮数与信息获取成本，导致在执行过程中因轮数限制或上下文不足而被迫终止。同时，其信息获取与验证流程往往不完整，缺乏多步验证与冗余检查机制，使任务在尚未充分收敛时提前结束。

6. 线性执行思维限制任务完成度：GPT 通常将复杂任务建模为强依赖的线性流程，对步骤之间的依赖关系过于刚性。一旦某一关键步骤失败，便倾向于判定整体任务不可继续执行，而缺乏将任务拆解为多个相对独立子任务的能力，也较少进行并行路径探索或备选方案尝试，最终导致任务提前终止。