Deep Agents 企业深度研究评测DRBench App 模式评估数据集全解析【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本仓库GitHub_Trending/de/deepagents以Deep Agents为核心其中 libs/evals/datasets/drbench-evals/README.md 系统讲解了一套从 ServiceNow 开源基准 DRBench 派生的企业级深度研究deep-research评测数据集。该数据集属于统一评测工作流unified evals workflow中的research类别采用App 模式评测任务不给 Agent 提供本地文件而是让它通过网络真实访问 Nextcloud、Mattermost、Roundcube/IMAP、文件浏览器等四套运行中的应用并结合开放互联网搜索产出一篇带引用的研究报告。读完本文你将掌握这套数据集的运行配置、双容器运行时形态、两套凭据体制、四项上游评分指标与调和均值聚合逻辑以及从零构建、校验和维护 100 个评测任务的完整命令链。一、数据集概览企业深度研究评测要解决什么问题DRBench 评测数据集包含 100 个 Harbor 评测任务由 harbor_adapters/drbench/adapter.py 从 ServiceNow 的 DRBench论文见 arXiv 2510.00172即enterprise deep-research benchmark自动生成。每个任务向 Agent 提供三样东西公司档案company profile行业、总部、规模、营收、市场地位等结构化背景人物角色persona一个具体岗位身份例如某公司的合规专员开放式研究问题dr_question一个开放式的深度研究提问。问题的答案被刻意拆分成两部分一部分埋在公司自己的系统里由运行中的应用提供服务另一部分是开放互联网上才存在的公开信息。Agent 的任务是写出一篇带引用的研究报告/app/report.md由评测器verifier按基准的 ground-truth 洞察回收率、干扰项规避、引用支撑度、报告质量四个维度打分。从源码结构可以确认该数据集的归属与定位dataset.toml 声明数据集名为langchain-ai/drbench-evals不发布到任何 registry任务靠扫描目录发现README 则明确指出这是统一评测工作流的research类别且是opt-in选择性启用的类别。二、运行配置四个必填项与两个不可商量的约束README 给出了一份最小可运行的配置片段categories: research sandbox_env: docker # required — see below runner_label: ubuntu-24.04-arm # required — see below profile: full include_tasks: DR0001 # a single task, for a smoke test concurrency: 1其中有两项设置是不可选的runner_label: ubuntu-24.04-arm必须为 arm64 运行器上游发布的每个任务的镜像只有 arm64 架构上游说明 amd64 images are coming soon。这一点在 adapter.py 中有明确注释镜像发布在ghcr.io/mmunozm/drbench-services下仅 arm64。配套的 docker-compose.yaml.tmpl 特意不设置platform:覆盖上游发布的是单条目 arm64 OCI index让 Docker 自行匹配宿主架构时amd64 运行器会在拉取阶段立即报no matching manifest for linux/amd64失败而强制固定linux/arm64则会迫使 qemu 模拟慢到足以超时并且一旦上游后续发布 amd64 镜像还会继续强制模拟。所以保持不覆盖让架构匹配失败快速失败。sandbox_env: docker必须运行器的架构只有在下述前提下才有意义——容器直接跑在运行器上。如果使用默认的 LangSmith 沙箱容器会运行在运行器之外标签就不会生效。此外profile: lite对单任务不适用lite 配置会把include_tasks与冻结的 lite 任务列表求交集因此单任务冒烟测试必须使用profile: full。从 vendor/README.md 可以看到lite 列表对应的是论文中名为MinEval的 15 任务子集subsets/minival.jsonl由.github/scripts/evals/lite_tasks.py固定并有测试断言两者一致。三、运行时形态一任务双服务 五类应用端点每个评测任务在 compose 层面对应两个服务Service作用mainHarbor 安装并运行 Agent 的地方不持有任何任务数据。评测器verifier也在这里之外单独运行见评分一节drbench上游按任务发布的镜像按 digest 固定版本。镜像自带 supervisord任务文档已预加载main服务镜像基于python:3.12-slim在 main.Dockerfile 中预装了curl、poppler-utilspdftotext 兜底以及 openpyxl/pypdf/python-docx/python-pptx 等文档解析库——这些正是把二进制文档转成文本所必需的。Agent 通过 compose 服务名drbench访问应用五类端点的完整访问方式如下应用端点访问方式Nextcloudhttp://drbench:8081HTTP Basic 认证WebDAVPROPFIND /remote.php/dav/files/user/Mattermosthttp://drbench:8082POST /api/v4/users/login→ 响应Token头中取得令牌Roundcubehttp://drbench:8085HTTPIMAPdrbench:1143Pythonimaplib文件浏览器http://drbench:8090HTTP健康检查http://drbench:8099/health仅当所有服务就绪时返回 200这些端点常量可以在 adapter.py 的_APP_ENDPOINTS字典中逐一对应nextcloud、mattermost、email、file_system四种README 表格中的 Roundcube 是对邮件 Web 界面的补充说明。宿主统一是 compose 服务名drbench因此 DNS 直接解析无需发布端口。main容器内部Agent 拥有以下工具与能力curl访问应用栈的全部网络传输手段extract-text文档是 PDF/DOCX/XLSX/PPTX/JSONL下载到的都是二进制需用它转文本main.Dockerfile 将该命令指向系统 Python 解释器避免与 Harbor 自建 uv venv 冲突imaplib读取 IMAP 邮箱web_searchTavily 驱动的联网搜索工作流只对本类别转发TAVILY_API_KEY。网络模式为network_mode public原因在生成出的 task.toml 模板 有详细注释613 条 gold insights 中有 45 条是external_fact类型只存在于开放互联网所以不能用出站白名单同时也避开了 Harbor 的 egress sidecar 将全部服务塞进单一网络命名空间、导致端口冲突和 UDP DNS 失效的问题。3.1 为什么必须是双服务Agent 的容器被刻意保持为空。原因在于上游镜像中包含/drbench/task/env.json其中按文档粒度携带qa_type字段——即每个文件是 insight 还是 distractor的显式标签。如果 Agent 有文件系统访问权限就能读到这个文件直接跳过研究。虽然 ground trutheval.json不在镜像里不算完整答案泄漏但足以摧毁干扰项distractor设计的有效性。双服务方案通过结构性隔离而非事后删除来解决把携带该文件的上游镜像放到一个 Agent 无法访问文件系统的独立服务里。这一设计在 docker-compose.yaml.tmpl 与 adapter.py 的模块说明中都有印证。3.2 就绪检查compose 等待 ≠ 应用可用compose up --wait只等待容器处于running状态而上游镜像没有声明HEALTHCHECK所以它会远早于应用真正可用就返回。真正的就绪门控是生成出的 task.toml 里的[environment].healthcheck配置adapter.py[environment.healthcheck] command curl -fsS http://drbench:8099/health /dev/null start_period_sec 300.0 start_interval_sec 5.0 interval_sec 10.0 timeout_sec 15.0 retries 5Harbor 会在main中安装 Agent 之前先轮询/health直至 200——这就是整个运行流水线的真实就绪门槛。四、凭据两种体制persona 与 default使用哪套登录凭据取决于任务本身这是上游的设计而非本仓库的选择。task.toml 的[metadata]中会记录每个任务所属的体制credential_regime体制任务数登录方式persona15使用 persona 的用户名 固定密码my_drbench_pwd。例如 DR0001 的文档位于 Nextcloud 的emily.patel用户下default85各应用的内置登录Nextcloud 与文件浏览器admin/admin_pwdMattermostadmindrbench.com/mm_admin_pwd邮件current.user/current_user_pwd这 85 个任务之所以走 default 体制是因为它们 persona 的password在上游为nullDRBench 的凭据覆盖逻辑提前返回于是每个应用保留自己的内置登录。该结论经解包已发布镜像验证DR0016 的文档位于 Nextcloud 的admin用户下其邮箱是current.user而非 persona。判定逻辑在 adapter.py 的credential_regime()函数中persona 携带非空字符串密码即为persona体制否则为defaultapp_credentials()则负责按体制返回真正可用的逐应用登录。_APP_DEFAULT_CREDENTIALS字典同文件 L92-L97完整列出了 default 体制的四套内置凭据。值得注意的设计细节这些是合成登录烘焙在公开镜像里不是机密。它们通过环境变量注入DRBENCH_APP_USER/DRBENCH_APP_PASS而非写进instruction.md原因有二见 adapter.py一是在 100 个提交的 prompt 里反复出现字面量-u user:password会触发密钥扫描器的误报二是环境变量间接层让每个值集中在每个任务一张清晰标注的表格里。五、评分复用上游指标 论文调和均值tests/judge.py生成时复制到每个任务的tests/目录调用的是上游自己的指标在 verifier 镜像中安装固定 commit 的drbench包然后把报告交给drbench.score_report.score_report。声明抽取、引用归一化、chunk 检索、所有判定 prompt 全部是上游代码不是重新实现——该文件头部注释明确指出此前重新实现版本约 900 行且由于通过 WebDAV 从存活应用栈解析文档根本无法解析邮件和聊天引用。5.1 四项指标指标上游类说明insights_recallQASimilarityV2报告可推导出的 gold insights 比例distractor_recallDistractorRecall越高越差——报告吞下了植入的干扰材料factualityCitationFactuality逐条引用判定解析引用来源、分块、按 embedding 相似度排序、判定report_qualityReportQuality五条标准各打 1–10 分取平均后除以 105.2 调和均值聚合与唯一偏差核心reward是insights_recall、1 − distractor_recall、factuality、report_quality四者的调和均值。这正是论文arXiv 2510.00172 表 2Insight Recall, Factuality, Distractor Avoidance, Report Quality, Harmonic Mean自己的聚合公式论文同样把 distractor avoidance 定义为1 − distractor recall。上游发布代码只计算四项指标而不计算均值所以均值组合发生在 judge.py 的composite()函数中。与论文的唯一偏差是每个分量加 0.01 下限EPSILON这样单个 0 分会把总分砸到接近零但不会抹掉全部排名信号。reward.json会同时写出全部四个分量/logs/verifier/drbench_metrics.json则携带完整明细judge 模型、embedding 模型、upstream 原始分数、每个 gold insight 的逐条判定等——诊断低分时优先读它。_zero_rewards()同文件 L545-L561还有一个细节报告缺失时distractor_avoidance记 1.0 而非 0.0因为避免率定义为1 − distractor_recall不存在的报告没有召回任何干扰项若把它也清零会破坏恒等式导致聚合时两个分量之和不等于实际产生 reward 的 trial 占比。5.3 评测器运行在独立环境中task.toml 声明[verifier].environment_mode separateadapter.pyHarbor 从tests/目录构建第二个镜像且只在 Agent 环境拆除之后才启动。这正是安全安装drbench包的前提该包以 package data 形式同时携带 goldeval.json和整个文档语料库两者在 Agent 运行期间绝不能存在。verifier 环境的镜像由 verifier.Dockerfile 定义它从/opt/drbench以editable 模式安装固定 commit 的上游包wheel 安装会漏掉drbench/prompts/下的运行期判定 prompt并在构建期用探针校验语料库与 prompt 文件完整。两个随之而来的结论tests/case.json不含任何答案。它只有任务 id 和上游 commit见 adapter.py评测器从已安装包中查 ground truth。任务目录中唯一含 gold insights 的是solution/solve.sh——它是 oracle只由 Harbor 的OracleAgent上传。评测器从不触碰应用栈。被引用的文档直接从语料库解析因此邮件、聊天、文件浏览器、Nextcloud 的引用都退化为普通文件解析。早期版本通过 WebDAV 重新抓取导致邮件和聊天引用完全无法解析。verifier 环境还包含若干安全与健壮性补丁均以运行时 monkey-patch 方式安装judge.pyURL 抓取守卫引用 URL 来自 Agent 的报告属不可信输入。_install_url_fetch_guard在requests.Session.send/request层面拒绝私有/回环/链路本地地址防 SSRF 指向云元数据限制重定向跳数≤5并强制 30 秒超时parse_website捕获异常返回 None使不可抓取的引用变成不支持的主张而不是让整个任务死亡Embedding 批量切分_install_embedding_batching把单次请求的 embedding 文本按约 20 万 token 预算分批避免近二进制文本把 token 数撑爆 API 上限导致 factuality 直接失败判定采样上限OpenRouter 路线的推理模型判定输出上限提升到 32,000 token上游 1000 token 默认会截断推理模型的 verdict同时捕获的逐条判定内容被限制在 32 条 × 600 字符防止超长报告膨胀 CI 产物指标明细捕获_install_metric_detail_capture截获score_report内部计算后丢弃的逐 insight verdictjustification、predicted_insight、confidence用来区分真零分与判定解析失败。5.4 引用必须可解析评分会把每条引用解析回来源解析不了的引用一律算作不支持无论主张多准确。因此instruction.md规定了精确的引用形式见 adapter.py 生成的指令文本文档——文件名如food-safety-compliance.pdf网页——完整 URL邮件——RoundCube-发送者地址-接收者地址-主题如RoundCube-david.leeexample.com-emily.patelexample.com-Re: Q2 Compliance Update聊天消息——MatterMost-频道-团队-用户。发送者地址和主题都是逐字符精确匹配显示名无法解析——上游normalize_email_citation的所有模式都要求包含。六、构建数据集不提交任务目录全部按 commit 生成没有任何任务目录被提交进仓库。全部 100 个任务都由 harbor_adapters/drbench/adapter.py 从固定 commitUPSTREAM_SHA 0d699ecf6aa96b1de378595b432e9b16a82f0ed9的上游配置生成。因此该目录在构建前只包含README.md、dataset.toml和.gitignore。构建命令cd libs/evals make dataset # python -m harbor_adapters.drbench.main --populate datasets/drbench-evalsmake dataset在 Makefile 中展开为uv run python -m harbor_adapters.drbench.main --populate datasets/drbench-evals。生成过程的关键实现事实blobless depth-1 sparse checkout只拉取每个任务的 5 个配置文件约 2.4 MiB跳过drbench/data/tasks/*/files/约 69 MiB 文档语料——App 模式下上游按任务镜像本身就提供文档不需要本地语料adapter.py 的_SPARSE_PATTERNS整个构建约两秒缓存于harbor_adapters/drbench/.upstream/下可用环境变量DRBENCH_UPSTREAM_DIR覆盖共享CI 在每个 research shard 运行harbor run --path之前执行同一命令prep 任务在枚举任务做 shard 前执行它。为什么生成而非提交两个原因solution/solve.sh是基准的答案密钥gold insights不应放进公开仓库1100 个文件只是某个 commit hash 的纯函数放进 diff 毫无价值。确定性验证make dataset-check构建两次并 diff证明生成是确定性的——既然输出不再能在 PR 中评审这就是 CI 验证生成的方式。另外make dataset-check还会调用--check-labels与--check-subsetsMakefile 第 127-128 行校验 vendored 的标签记录与子集文件与固定上游 commit 逐字节一致。上游重新发布镜像后重新固定镜像 digest这是唯一与 registry 交互的步骤python -m harbor_adapters.drbench.main --refresh-digestsCLI 的完整能力见 main.py--task-ids/--limit/--all按 id 生成指定任务可用于冒烟测试单任务--populate全量铺设--refresh-digests/--refresh-labels刷新 digest 与标签--check-labels/--check-subsets只读校验这些模式互斥读操作永远不会和写操作混用。6.1 vendored 内容与归属libs/evals/harbor_adapters/drbench/vendor/README.md 说明了哪些被 vendored、固定了哪个上游 commit、以及归属上游配置文件不 vendored生成时从固定 commit 拉取commit hash 本身就是内容的哈希固定效果与提交一份拷贝完全一致subsets/{minival,val,sanity}.jsonl上游自己的任务子集原样复制。minival.jsonl是论文中 MinEval 的 15 任务集论文只命名未列 id此文件是唯一权威清单val.jsonl列出全部 100 个计分任务是available_task_ids()的数据来源让--all和 prep 阶段在无网络、无任务目录的情况下解析任务列表task_labels.json每个任务的difficulty、industry、domain使 full profile 的 30 任务抽样可验证为 100 任务的比例抽样6/7/17 对 20/23/57image_digests.json每个任务的上游镜像解析为不可变的sha256:digest。镜像名本身可推导上游按任务 id 打 tag真正需要 vendored 的是 digest——因为上游 tag 可变、位于个人命名空间、且不发布任何版本 tagre-push 会在本仓库无改动的情况下悄悄改变评测结果。七、运维注意磁盘、digest 与架构README 在最后给出四条实战经验均有源码佐证磁盘是硬约束单个任务镜像压缩约 1.22 GiB解压后约 3–4 GiB而运行器只有约 14 GB。各任务镜像几乎不共享层DR0001 与:latest只共享约 158 MiB因为它基于更早的 base 提交且 Harbor 从不清理——down --rmi local也会留下已拉取的镜像。因此应concurrency: 1并在 trials 之间清理横向扩展 shard 优于纵向堆叠深度。镜像按 digest 固定vendor/image_digests.json上游 tag 可变、位于个人命名空间、且完全不发布版本 tagdigest 是唯一可靠的固定手段。force_build在 docker 沙箱上几乎无效它只影响同时声明docker_image和 Dockerfile 的任务把拉镜像切换为构建 Dockerfile对 DRBench 这种纯镜像任务没有实际作用。这是唯一不运行在 amd64 LangSmith 沙箱上的类别因此其分数与其他类别不具备硬件可比性——但这不影响把它当作一个绝对意义上的 DRBench 分数来解读。八、与统一评测工作流的衔接作为research类别DRBench 数据集与仓库中其他评测如context-retrieval类别共享 Harbor 评测框架数据集不发布 registry由 dataset.toml 声明元数据、按目录扫描发现任务运行入口统一为harbor run --path libs/evals/datasets/drbench-evals ...。与其余类别相比本数据集在三个维度上独树一帜任务介质不同其余类别把文档放在磁盘/对象存储本类别让文档跑在真实应用里Agent 必须走网络协议出网策略不同network_mode public含external_fact型 gold insights 与 verifier 的判定 API 调用都需要公网出口verifier 结构不同独立环境 独立镜像 上游包内语料从根上杜绝 ground truth 泄漏。如果你需要在生产环境中复现企业级深度研究评测可以按本文第五节的方式直接复用make datasetharbor run的命令链如果要诊断某个任务的低分优先查看/logs/verifier/drbench_metrics.json的metric_detail逐 insight 判定、unfetchable_citations抓取失败的引用与scoring_package_versions可能改变分数的依赖版本这三项共同决定了报告确实差与评测链路出了问题之间的分野。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
