deepagents 上下文检索评测任务精读cb-cloud-62 多跳链式推理的实战拆解【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents导读本文聚焦 deepagents 仓库中context-retrieval-evals数据集的一个典型任务cb-cloud-62从 instruction.md 的原始问题出发完整剖析其问题结构、目录布局、沙箱环境、评分机制与生成管线。读完本文你将理解 multi_hop_chain多跳链式推理评测任务是如何设计的以及 Agent 需要具备怎样的检索与推理能力才能在该类任务上得分。一、任务全貌cb-cloud-62 在数据集中的定位cb-cloud-62是 deepagents 仓库context-retrieval-evals数据集中的 30 个任务之一。该数据集的定位按 README.md 的描述是extract and reason over information spread across a multi-file corpus——让 Agent 在跨多文件语料中抽取信息并完成推理。它的关键设计在于每个任务都提供完整语料10 个文件Agent 无法预判哪些文件有用必须自己去检索、关联和聚合。cb-cloud-62在 README 的任务总表 中登记的信息为任务难度档位Terra pass6Luna pass6问题类型cb-cloud-62hard5/66/6multi_hop_chain它被标记为hard 难度问题类型为multi_hop_chain多跳链式推理。任务目录cb-cloud-62的完整结构如下libs/evals/datasets/context-retrieval-evals/cb-cloud-62/ ├── environment/ │ └── Dockerfile # 沙箱镜像python:3.12-slim curl ├── solution/ │ └── solve.sh # 参考答案脚本写入 /app/answer.txt ├── tests/ │ └── case.json # 唯一提交的任务数据问题 标准答案 ├── instruction.md # 给 Agent 的任务说明问题 输出契约 └── task.toml # Harbor 任务清单元数据 网络白名单其中instruction.md是 Agent 实际读到的任务说明其原文仅有两条指令Who has more insurance policies: the person with the highest salary among residents of the same state as the owner of the vehicle with license plate LMF 674, OR the person with the highest salary among residents of the same state as the owner of the vehicle with license plate HPG 599? Use only the files under /app/files. Write your final answer (and nothing else) to /app/answer.txt.这两条指令构成了任务的全部契约第一段是问题第二段是行为约束。约束明确了两点数据来源只能限定在/app/files目录最终答案必须以唯一内容的形式写入/app/answer.txt不允许任何多余输出。二、问题拆解multi_hop_chain 的推理链路cb-cloud-62的问题是一个典型的链式对比题。把它拆开推理链包含以下跳步定位车牌在语料中查找牌照号为LMF 674和HPG 599的两辆车跳转到车主读取这两辆车分别对应的车主身份跳转到州确定两位车主各自所在的州跳转到居民分别找到这两个州的居民集合跳转到薪资在每个州的居民中找出薪资最高的人聚合对比比较这两位高薪人士各自持有的保险单数量回答谁更多。这就是 multi_hop_chain多跳链的含义——从车牌出发经过车主、州、居民、薪资、保险单五层关联最终落到一个二元比较上。答案记录在 tests/case.json 中{input: Who has more insurance policies: the person with the highest salary among residents of the same state as the owner of the vehicle with license plate LMF 674, OR the person with the highest salary among residents of the same state as the owner of the vehicle with license plate HPG 599?, ground_truth: Steven Martin}标准答案是Steven Martin。这类问题的难点不在于单步查找而在于全量语料无提示Agent 拿到的 10 个文件是完整语料没有任何标记指明哪个文件存车牌、哪个存保险单必须靠文件名/内容推断字段分布未知人、车、宠物、账户等记录分散在不同文件跨文件 join 依赖 Agent 自主发现关联键比较粒度细微不是某人的保险单数是多少而是两个州各自最高薪者的保单数谁更多需要先排序再比较答案极简最终答案只是一个名字任何多余内容都会干扰评分详见第四节。从源码看question_type字段由 Context-Bench 源记录中的agent_args.extra.question_type直接写入 task.toml见 adapter.py这说明multi_hop_chain是上游数据标注的类别并非仓库事后贴的标签。三、沙箱环境Dockerfile、语料库与网络白名单3.1 沙箱镜像任务在隔离的 Docker 沙箱中运行镜像定义见 environment/DockerfileFROM python:3.12-slim # Pre-install curl at build time (the build phase has network) so the # in-sandbox agents runtime bootstrap skips apt; runtime egress is then # all-HTTPS via the tasks network allowlist. RUN apt-get update \ apt-get install -y --no-install-recommends curl ca-certificates \ rm -rf /var/lib/apt/lists/* COPY files/ /app/files/两个细节值得注意基础镜像是python:3.12-slim并在构建阶段预装curl和ca-certificates。注释明确指出这是为了让沙箱内 Agent 的运行时引导过程跳过apt使运行期的网络出口全部走 HTTPS从而受网络白名单约束语料通过COPY files/ /app/files/挂载到 Agent 唯一可用的数据目录/app/files与instruction.md中Use only the files under/app/files的约束一一对应。3.2 语料库完整交付、git-ignored按照 README.md 的说明每个任务都完整交付10 个文件、约 64.7K 行的语料Context-Benchcloud套件的合成数据内容为人/车/宠物/账户记录。语料不在仓库中提交而是单源保存在harbor_adapters/contextbench/vendor/files/运行前通过--populate恢复进每个任务的environment/files/。这种全量语料 不提交的设计刻意排除了根据文件列表猜答案的可能性Agent 面对的是和真实世界一样的、未标注重要性的文件集合。3.3 网络白名单task.toml 的[environment]段声明了网络策略[environment] network_mode allowlist allowed_hosts [astral.sh, *.astral.sh, github.com, *.githubusercontent.com, pypi.org, *.pythonhosted.org, api.smith.langchain.com, api.anthropic.com, api.openai.com, generativelanguage.googleapis.com, openrouter.ai, *.baseten.co, api.fireworks.ai, ollama.com, api.groq.com, integrate.api.nvidia.com, api.x.ai]network_mode allowlist意味着并非断网而是只放行白名单内的主机。从 adapter.py 的注释可以确认设计意图放行的主机分为两类包镜像astral.sh、pypi.org 等供 Agent 安装依赖与模型提供方 APIanthropic、openai、groq 等供 Agent 调模型任意公网访问被阻断因此 Agent 无法通过外部搜索引擎或网页查答案答案检索被强制限定在/app/files内api.smith.langchain.com用于 LangSmith 追踪保证评测过程可观测。四、答案通道与评分机制4.1 输出契约与参考答案任务的输出契约异常严格最终答案且仅答案写入/app/answer.txt。仓库为每个任务提供了参考答案脚本 solution/solve.sh#!/bin/sh set -eu printf %s\n Steven Martin /app/answer.txt该脚本由生成器从case.json的标准答案直接写出见 adapter.py其作用既是 CI 的对照基准也明确了唯一内容的格式——一行、无前后缀、无解释。4.2 LLM 评判model_judge而非字符串比对任务评分不采用字符串相等而是复刻上游 Letta letta-evals 的model_judge用 LLM 对照 vendor/rubric.txt 打分对措辞、姓名格式、数字表达有一定容忍度。评分链路由三个任务不变的模板文件驱动它们与语料一样是 git-ignored、单源提交见 README.mdtemplates/test.sh执行入口直接调用python3 /tests/judge.pytemplates/judge.pyLLM 评判实现关键行为如下用string.Formatter().vformat将 rubric 中的{input}、{ground_truth}、{submission}三个占位符替换为case.json的问题/标准答案和/app/answer.txt的 Agent 输出通过 Chat Completions 以json_schema响应格式要求模型返回{score: float in [0,1], rationale}温度规则judge 模型命中o1/o3/gpt-5前缀时使用 temperature 1.0推理模型拒绝 0.0其余模型为 0.0容错score clamp(score, 0.0, 1.0)judge 调用失败重试 5 次最终仍失败则记 0.0分数写入/logs/verifier/reward.txt作为 Harbor 采集的 rewardjudge 模型来自 harness 注入的环境变量JUDGE_MODELS默认gpt-5.6-luna密钥走OPENAI_API_KEY/OPENAI_BASE_URL不硬编码。对 Agent 而言这套评分的实际含义是输出与Steven Martin语义一致即可得分例如拼写略有出入、带不带 Mr. 前缀等但完全不相关的内容会得到低分且/app/answer.txt缺失直接记 0.0。五、任务生成与复现adapter 与 CLIcb-cloud-62不是手写的而是由 harbor_adapters/contextbench 从 Context-Bench 的filesystem_cloud.jsonl100 条记录按行索引生成的——任务cb-cloud-62对应第 62 条记录0 基。任务 ID 必须匹配cb-suite-i正则见 adapter.py。5.1 生成逻辑adapter.py 的 generate_task 一次生成任务的全部产物将vendor/files/下的全部语料复制到environment/files/由记录的input字段生成instruction.md问题 固定的/app/files、/app/answer.txt约束由ground_truth字段生成solution/solve.sh生成task.toml其中difficulty、source_difficulty、question_type均取自上游记录生成tests/case.json问题 标准答案并复制三份评分模板。值得注意的是 populate_corpus由于语料和评分模板对每个任务都完全相同它们被设计为单源 git-ignored在本地运行前需要用一条命令恢复uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals之后即可用 Harbor 运行整个数据集CI 的harbor.yml会在构建任务镜像前自动执行--populateuv run harbor run --path datasets/context-retrieval-evals ...5.2 CLI 的三种模式main.py 提供的 CLI 支持三种互斥模式--task-ids cb-cloud-62按 ID 生成单个任务可多个也可用--limit N生成前 N 个--populate DATASET_DIR恢复每个任务的语料与评分模板运行前必做--stamp-tiers DATASET_DIR --calibration CALIBRATION_JSON用 calibration.json 中校准后的难度档位覆写各任务的difficulty同时保留source_difficulty作为来源溯源见 stamp_calibrated_tiers。对cb-cloud-62而言difficulty hard与source_difficulty hard当前一致即上游标注与校准结果相同。六、难度校准与模型基线据 README.md 记录30 个任务是依据 gpt-5.6-terra 与 gpt-5.6-luna 两模型对全部 100 个源任务各 6 次 rollout 的配对结果抽取的代表性样本难度档位继承自 Context-Bench 源分层2 easy · 10 medium · 18 hard并非按模型表现事后贴的标签。对cb-cloud-62这一档README 登记的 pass6 基线为Terra 5/6、Luna 6/6两个模型都曾在 6 次尝试中至少答对 5 次说明该任务对强模型可解但非必对——这正是 hard 档 multi_hop_chain 的定位。calibration.json以机器可读形式记录了源运行、聚合总数与每个任务的双模型结果。七、对 Agent 设计者的实战启示从cb-cloud-62这一个任务可以提炼出评测该类能力的若干通用要点检索必须先定位、后推理面对未标注重要性的全量语料Agent 应先建立车牌→车主→州→居民→薪资→保单的检索计划而不是顺序扫全文件跨文件 join 是核心竞争力多跳链的核心考验是能否识别文件间的关联键如车牌号、人名、州名并把分散记录连接起来严格遵循输出契约/app/answer.txt只写答案本体。虽然 LLM judge 对措辞有容忍度但多写解释会稀释答案语义、影响 score任何 judge 调用失败或文件缺失都会直接落到 0.0善用任务元数据task.toml中的question_type multi_hop_chain与难度档位见 dataset.toml 的配置方式可帮助评测方分析模型的失败模式也可用于按类型构建专项评测集。若要在本地深入验证上述结论可依次阅读 instruction.md任务原文、case.json标准答案、adapter.py生成逻辑与 judge.py评分实现再执行--populate后运行 Harbor即可完整复现该任务的评测闭环。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考