deepagents 上下文检索评测任务深度解析以 cb-cloud-67 多跳链条题为例【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本文以 deepagents 仓库中 Harbor 评测数据集context-retrieval-evals的典型任务cb-cloud-67为解剖样本完整拆解多跳链条推理multi_hop_chain类上下文检索评测题的构成任务指令、元数据、沙箱环境、10 文件语料、标准答案与生成管线并带你走通从原始语料到最终答案的完整推理链路。读完本文你既能看懂这一类评测题的设计意图与判分机制也能掌握如何在本仓库中定位、复现乃至自行生成同类上下文检索评测任务。一、任务指令一段被刻意压缩的评测提示词cb-cloud-67的任务指令保存在 libs/evals/datasets/context-retrieval-evals/cb-cloud-67/instruction.md全文如下Who has more credit cards: the person with the highest salary among those with the same blood type as the owner of pet Frederick, OR the person with the highest salary among those with the same blood type as the owner of pet Tommy?Use only the files under/app/files. Write your final answer (and nothing else) to/app/answer.txt.虽然正文只有两句话但它完整定义了一类上下文检索评测的核心契约问题本体一个需要跨文件检索、连接join并聚合aggregate才能回答的复合问句数据约束Use only the files under /app/files——Agent 只能使用沙箱内挂载的语料文件禁止也无需依赖外部知识输出约束Write your final answer (and nothing else) to /app/answer.txt——最终答案必须以纯文本形式写入指定文件不允许附加解释或推理过程。这两条约束是该评测体系可自动化的根基前者保证评测环境是封闭自洽的后者保证答案可以通过统一的答案通道answer channel被验证器读取。二、元数据解读task.toml 里的评测设计意图每个评测任务的元数据记录在 task.tomlcb-cloud-67 的关键字段如下version 1.3 [metadata] source contextbench # 任务来源Context-Bench 合成数据集 suite cloud # 语料套件filesystem-cloud difficulty hard # 权威难度分层校准后的实测分层 source_difficulty hard # 来源难度标签保留溯源 question_type multi_hop_chain # 问题类型多跳链条推理 [environment] network_mode allowlist allowed_hosts [astral.sh, *.astral.sh, github.com, ...]几个值得注意的设计点source contextbench表明任务源自 Letta letta-evals 的 Context-Benchfilesystem_cloud套件任务目录由本仓库的适配器从filesystem_cloud.jsonl按行索引生成详见后文第五节。difficulty与source_difficulty分离是刻意的生成时两者都先写为来源标签校准后difficulty会被覆盖为实测分层而source_difficulty保留原始标签用于溯源。这一逻辑由 adapter.py 中的stamp_calibrated_tiers实现。网络模式是allowlist白名单而非禁网Agent 需要在沙箱内引导自己的运行时拉包、调用所选模型的 API因此必须放行包镜像与模型提供商域名但任意网页仍被阻止从根本上杜绝上网搜答案这类作弊路径。列表中的域名覆盖了评测工作流可选的各家模型 API 端点OpenAI、Anthropic、OpenRouter、Groq、NVIDIA、xAI、Google 等只放行 API 端点、绝不放行答案来源。三、沙箱环境Dockerfile 与 6.4 万行语料库任务环境由 environment/Dockerfile 定义FROM 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/设计要点curl 与 ca-certificates 在镜像构建阶段预装构建期有网络这样运行时引导不再需要apt沙箱内的所有出网流量都能收敛为 HTTPS 并受任务白名单管控随后整个语料目录被复制到/app/files/即指令中 Agent 唯一的知识来源。cb-cloud-67 与同套件其他任务一样挂载的是完整语料10 个文本文件、合计 64,657 行而不是与问题相关的子集——这正是上下文检索评测的核心考验Agent 无法预判哪些文件相关必须自己检索、连接与聚合。10 个文件及其行数语料唯一副本位于 vendor/files文件行数记录格式要点people.txt1,500### Judy Bender (ID: pers-0435) DOB/Email/Phonepets.txt5,742### pet-0776 (owner: pers-0413) name/species/breedcredit_cards.txt8,869### card-0001 (owner: pers-0001) provider/number/expire/cvcemployments.txt4,176### emp-0460 (owner: pers-0435) employer/job_title/salary/currencymedical_records.txt1,530### med-0218 (owner: pers-0435) ssn/blood_type/conditionaddresses.txt/bank_accounts.txt/insurance_policies.txt/internet_accounts.txt/vehicles.txt其余同风格分块记录每条记录都是一个###标题块 若干key: value字段行的规整文本格式跨文件通过pers-XXXX主键owner 字段互相连接这为 Agent 提供了解析与 join 的稳定线索。四、从语料到答案cb-cloud-67 的标准推理链路题目问Frederick 宠物主人的血型相同者中薪水最高的人与 Tommy 宠物主人的血型相同者中薪水最高的人谁拥有的信用卡更多这是一个典型的四跳链条定位宠物主人在 pets.txt 中查名字——name: Tommy位于第 4497 行pet-0750owner: pers-0403name: Frederick位于第 4653 行pet-0776owner: pers-0413。映射到人在 people.txt 中pers-0403 是 Debra Levine第 1207 行pers-0413 是 Paul Miller第 1237 行。查血型在 medical_records.txt 中med-0202owner: pers-0403血型为O-med-0209owner: pers-0413血型为A-。按血型分组取最高薪在 employments.txt 中聚合薪水——A- 组最高薪为 Judy Benderpers-0435emp-0460 记录薪水249,385.22O- 组最高薪为 James Smithpers-0209emp-0215 记录薪水249,429.35。比对信用卡数量在 credit_cards.txt 中计数——Judy Bender 名下4 张James Smith 名下3 张。因此答案是Judy Bender4 3。这一结论与两份官方标准答案完全吻合解法脚本 solution/solve.sh 直接printf %s\n Judy Bender /app/answer.txt测试用例 tests/case.json 记录ground_truth为Judy Bender。值得注意问题设计者刻意让两组最高薪者薪水极为接近249,385.22 vs 249,429.35迫使 Agent 不能靠猜或取个大概必须精确检索、精确 join、精确聚合再对信用卡数量做最终比较——这就是hard难度在问题层面的体现。五、生成管线适配器如何长出一个任务目录cb-cloud-67 并非手写产物而是由 Context-Bench 适配器从单条 JSONL 记录程序化生成。入口为 libs/evals/harbor_adapters/contextbench/main.py核心逻辑在 libs/evals/harbor_adapters/contextbench/adapter.pyparse_task_id将cb-cloud-67解析为(suitecloud, line_index67)即指向 vendored filesystem_cloud.jsonl 的第 67 行0 起计数——该行正是本题的问题与标准答案generate_task做四件事把完整语料复制到environment/files/、依据记录中的input/ground_truth写出instruction.md与solution/solve.sh、生成 Dockerfile 与.dockerignore、写入tests/case.json与task.tomlpopulate_corpus负责把全任务共用、git-ignored的两类文件从单一副本还原到每个任务目录environment/files/语料与tests/{test.sh, judge.py, rubric.txt}验证器每个任务只有tests/case.json问题 答案是被提交的独有文件stamp_calibrated_tiers依据 calibration.json 将校准后的难度写回各任务task.toml。adapter.py还做了严格的安全性防护task_id必须是单个路径组件防目录逃逸、--populate只处理数据集目录的直接子任务、校准层级仅接受easy/medium/hard三值。六、判分机制为什么不是字符串相等评测答案不是简单的比对而是忠实复刻上游 Letta model_judge 的 LLM 判分。验证器入口 templates/test.sh 只有一行——调用 templates/judge.py 并把分数写入/logs/verifier/reward.txt。judge.py 的关键行为读取tests/case.json中的{input, ground_truth}与 vendored rubric.txt把{input}/{ground_truth}/{submission}用string.Formatter().vformat替换进 rubric 提示词调用 Chat Completions 并强制json_schema响应格式{score ∈ [0,1], rationale}温度规则judge 模型若匹配o1/o3/gpt-5前缀则用 1.0否则 0.0——因为这些推理模型在 API 上拒绝 0.0 温度会 400上游正是因此把它们抬到 1.0最终score clamp(score, 0.0, 1.0)任何异常按上游惯例计 0.0judge 调用失败会重试最多 5 次评判模型来自环境变量JUDGE_MODELS默认回退gpt-5.6-luna密钥经OPENAI_API_KEY/OPENAI_BASE_URL注入绝不硬编码。rubric.txt 明确了宽容规则数字格式等价$145,315.33145315.33、数字单词等价two dogs2、人名大小写不敏感、只要最终答案中出现期望人名即判对、中途推理有误但最终答案正确仍判 1.0、只允许 0.0/0.5/1.0 三档且 0.5 仅限明确拒绝回答。这套规则意味着即使 Agent 的回答措辞与Judy Bender不完全一致只要语义等价就能得分。七、数据集全局30 任务与难度分层cb-cloud-67 属于 libs/evals/datasets/context-retrieval-evals 这个 Harbor 数据集其 README 记录了关键事实该数据集包含30 个上下文检索任务全部源自 Context-Benchcloud套件合成的人物/车辆/宠物/账户记录由harbor_adapters/contextbench从 100 条filesystem_cloud.jsonl记录中采样生成cb-cloud-i对应第i条记录0 起难度分层源自对全部 100 个源任务的配对六轮实测gpt-5.6-terra 与 gpt-5.6-luna抽样保留了整体分布全量 Terra 85.0% / Luna 92.0%抽样 30 个任务为 85.0% / 92.2%任务表显示cb-cloud-67的 source tier 为hard、问题类型multi_hop_chain配对实测中 Terra pass6 为 5/6、Luna 为 6/6calibration.json 机器可读地记录了每任务的 pass1 与 tier其中 cb-cloud-67 为pass_at_bare 0.8333、luna_pass_at_bare 1.0、n 6、tier hard——可见即便对强模型多跳链条也不是 100% 稳定通过的题这正是其评测价值所在。八、本地复现与运行语料与验证器是单一来源设计被 git-ignore因此本地运行前需要先 populate。数据集的 README 给出了两条命令# 1) 从单一副本还原每个任务的语料与验证器文件 uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals # 2) 用 Harbor 运行该数据集 uv run harbor run --path datasets/context-retrieval-evals ...--populate会扫描数据集目录下所有source contextbench的任务目录把 vendored 语料复制到各任务的environment/files/并把templates/test.sh、templates/judge.py、vendor/rubric.txt复制到各任务tests/随后 Harbor 即可构建任务镜像并执行评测。CI 会在构建任务镜像前自动执行--populate本地手动复现时也需遵循同一顺序。九、对 Agent 开发者的启示透过 cb-cloud-67 这面镜子可以提炼出上下文检索评测与 Agent 工程的三点经验评测要检索后推理而非喂相关片段完整语料 封闭白名单网络逼出真实的文件系统检索、跨文件 join 与聚合能力这类题能稳定区分碰运气与真检索答案通道与判分器分离/app/answer.txt作为唯一答案通道LLM rubric 判分容忍措辞变体二者配合使评测既严格又公平单一来源 程序化生成语料、验证器、Dockerfile、task.toml 全部由适配器从 JSONL 记录生成并集中维护30 个任务得以零漂移地保持结构一致——如果你想扩充自己的上下文检索评测集完全可以仿照 adapter.py 的生成模式把新问题与答案写进 JSONL 后一键成题。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
