deepagents 上下文检索评估任务 cb-cloud-65 深度拆解多实体比较型检索的沙箱实战【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本篇技术指南以libs/evals/datasets/context-retrieval-evals/cb-cloud-65任务为样本完整讲解 deepagents 项目上下文检索评估context-retrieval evals的单任务结构从指令、语料、沙箱环境到评分器的全部组成并给出本地生成与运行评估集的方法。读完本文你将掌握这类整库下发、多文件关联检索评估任务的推理链路与实现原理可直接复现该任务的本地评估流程。任务概述一题读懂整类评估cb-cloud-65是 deepagents 仓库中上下文检索评估数据集的一个单任务目录属于 30 个任务的context-retrieval-evals数据集见 数据集 README。它的定位非常明确评估 Agent 在不知道哪些文件有用的前提下从多文件语料中检索、关联、聚合信息并回答问题的能力。该任务的完整指令只有两句话出自 instruction.mdWho has more insurance policies: the person with the highest salary among residents of the same state as the owner of pet Wesley, or the person with the highest salary among residents of the same state as the owner of pet Dominique?Use only the files under/app/files. Write your final answer (and nothing else) to/app/answer.txt.指令本身同时给出了两条硬约束数据边界只能使用/app/files目录下的文件禁止访问外部数据源输出协议最终答案且只能有最终答案写入/app/answer.txt。这个答案通道约定是整个 deepagents 评估框架的标准接口Agent 的最后一步动作就是把答案落到沙箱内的固定路径评分器随后读取该文件进行打分。单任务目录结构四个组成部分cb-cloud-65目录由四部分组成每个部分承担一个职责libs/evals/datasets/context-retrieval-evals/cb-cloud-65/ ├── environment/ │ └── Dockerfile # 沙箱镜像定义 ├── solution/ │ └── solve.sh # 参考答案脚本ground truth 落地 ├── tests/ │ └── case.json # 每任务独有问题 标准答案 ├── instruction.md # 下发给 Agent 的任务指令 └── task.toml # 任务元数据与网络策略task.toml任务元数据与网络策略task.toml 记录了该任务的来源、难度分级与沙箱网络策略version 1.3 [metadata] source contextbench suite cloud difficulty hard source_difficulty hard question_type multi_entity_comparison [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]关键字段解读source contextbench任务派生自 Context-Benchcloud套件的合成人物/宠物/车辆/账户记录数据difficulty与source_difficulty从源码看adapter.py生成时两者均写为 Context-Bench 原始难度标签hard而difficulty会在校准后被覆盖为实测难度source_difficulty保留来源标签用于溯源question_type multi_entity_comparison标识题型为多实体比较network_mode allowlist不是禁网而是白名单制。从生成器的注释可以看出Agent 需要在沙箱内自举拉取依赖包、调用所选模型的 API因此必须允许访问包镜像与模型服务商但任意 Web 仍被拦截防止通过外网直接查到答案。网络访问经由 LangSmith 的出口代理强制实施。Dockerfile最小化沙箱镜像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避免 Agent 在运行时触发apt从而保证沙箱运行期的所有出口流量都是 HTTPS 且受白名单约束COPY files/ /app/files/将整份语料拷入沙箱。tests/case.json唯一每任务独有文件case.json 是任务的问题与标准答案{input: Who has more insurance policies: the person with the highest salary among residents of the same state as the owner of pet Wesley, or the person with the highest salary among residents of the same state as the owner of pet Dominique?, ground_truth: Emily Schmidt}solution/solve.sh参考答案solution/solve.sh 给出了标准答案的落地方式#!/bin/sh set -eu printf %s\n Emily Schmidt /app/answer.txt本题的标准答案是Emily Schmidt。语料设计整库下发拒绝题目泄漏该数据集最核心的设计决策是每个任务都把完整语料10 个文件一次性下发给 Agent见 数据集 README 的说明因此 Agent 无法从文件数量/文件名推测哪些文件与题目相关必须真正执行检索—关联—聚合的完整链路。语料来自libs/evals/harbor_adapters/contextbench/vendor/files/共 10 个合成数据文件文件内容people.txt人物档案1500 条含 ID、姓名、出生日期等pets.txt宠物记录含主人 pers-ID 外键vehicles.txt车辆记录addresses.txt地址含所在州 stateemployments.txt雇佣记录含薪资 salary、职位insurance_policies.txt保险保单每人可能有多张bank_accounts.txt/credit_cards.txt银行账户 / 信用卡internet_accounts.txt网络账户medical_records.txt医疗记录以宠物文件为例记录格式为块状文本通过pers-XXXX外键与人物表关联### pet-0511 (owner: pers-XXXX) pet_id: pet-0511 name: Wesley species: Dog breed: PurebredWesley与Dominique正是出现在pets.txt中、以name:字段标识的宠物名。整份语料合计约 6.4 万行分散在 10 个文件中这决定了 Agent 无法一次性把所有内容塞进上下文必须依赖工具进行定向检索。问题拆解一条四级推理链cb-cloud-65的题型是multi_entity_comparison多实体比较。题目问的是Wesley 的主人所在州中薪资最高的人与Dominique 的主人所在州中薪资最高的人谁的保单更多从 vendored 记录第 66 行即 cb-cloud-65 对应的 0-based 索引 65可以看到该任务声明的必需文件集合pets.txt、people.txt、addresses.txt、employments.txt、insurance_policies.txt。推理链需要跨这 5 个文件完成宠物 → 主人在pets.txt中查找名为 Wesley / Dominique 的宠物读取其(owner: pers-XXXX)外键主人 → 州以pers-XXXX在addresses.txt中查该主人的居住州state同州居民 → 薪资最高者在employments.txt中聚合该州所有居民的薪资找出各自州内的薪资最高者保单数量比较在insurance_policies.txt中分别统计两人的保单数量输出保单更多的那个人的姓名。四个步骤中第 3 步是最容易出错的环节Agent 必须正确理解same state as the owner与主人同州这一限定在整州范围内聚合而非只查主人本人且两组的查询必须一致、可比较。这也解释了为什么cb-cloud-65的校准通过率明显偏低见下文难度校准比较型问题的中间任何一跳出错都会导致最终答案错误。评分机制Letta model_judge 兼容评审而非字符串比对这个数据集的评分不是标准答案的字符串相等比对而是忠实复刻上游 Letta letta-evals 的model_judgeLLM 评审见 judge.py 的文件头注释与 adapter.py 中的说明。评审流程评分器judge.py的工作流程如下读取/tests/case.json问题 标准答案、/tests/rubric.txt评审提示词、/app/answer.txtAgent 提交的答案用string.Formatter().vformat将{input}、{ground_truth}、{submission}三个占位符替换进 rubric 提示词无系统提示、无包装通过 Chat Completions 调用评审模型强制json_schema响应格式{score: float in [0,1], rationale}对 score 做clamp(0.0, 1.0)任何异常都按 0.0 处理与上游一致。评审温度规则上游对推理型评审模型有特殊温度处理judge.py 中忠实保留了该规则def _temperature(model: str) - float: Upstream rule: reasoning judges (o1/o3/gpt-5) reject 0.0, so use 1.0. if model.startswith((o1, o3)) or gpt-5 in model.lower(): return 1.0 return 0.0原因是 o1/o3/gpt-5 这类推理模型会在 API 层面拒绝 temperature0.0 的请求会返回 400所以上游对它们使用 1.0其余模型用 0.0。评审模型来自 harness 注入的环境变量JUDGE_MODELS默认gpt-5.6-luna凭据来自OPENAI_API_KEY、OPENAI_BASE_URL代码中不硬编码任何密钥。评分标准vendored rubric.txt 定义了 0.0 / 0.5 / 1.0 三档1.0正确最终答案与预期一致。数字格式等价$145,315.33145315.33、数字单词等价2 dogstwo dogs2、人名大小写不敏感、轻微措辞差异可接受、单位可隐含且若期望答案是人名响应中出现该名字即视为正确0.5仅限拒绝作答Agent 明确拒绝回答如 I cannot help with that仅适用于明确拒答不适用于尝试后失败0.0错误答案不同、声称找不到但答案存在、只给出缺失关键值的部分答案、给出多个答案且未明确哪个是最终答案。评审只关注最终答案中间推理有误但最终答对仍给 1.0中间推理正确但最终答错给 0.0。验证器调用验证器由 test.sh 驱动它只有两行——调用judge.py由 judge 自行把分数写入/logs/verifier/reward.txt#!/bin/sh set -eu # Faithful Letta model_judge grader; writes /logs/verifier/reward.txt itself. python3 /tests/judge.py单源化Single-sourcing哪些文件被提交哪些被生成这是一个重要的工程细节见 数据集 README 的说明语料与验证器文件在所有任务间完全一致因此被单源化存放并 git-ignore而不是在每个任务目录里重复提交语料唯一副本在libs/evals/harbor_adapters/contextbench/vendor/files/通过populate_corpus恢复进每个任务的environment/files/不变的验证器文件tests/{test.sh, judge.py, rubric.txt}唯一副本在templates/与vendor/rubric.txt每任务唯一提交的文件只有tests/case.json问题 标准答案。本地生成与运行评估集数据集生成逻辑在 adapter.py 与 CLI 驱动 main.py 中。任务 ID 的解析规则是cb-suite-i其中i是filesystem_cloud.jsonl中记录的 0-based 行索引因此cb-cloud-65对应第 66 行记录。生成指定任务uv run python -m harbor_adapters.contextbench.main \ --output-dir datasets/context-retrieval-evals \ --task-ids cb-cloud-65支持--limit N批量生成前 N 个任务也支持--task-ids一次传入多个 ID。生成器会校验任务 ID 格式必须是单一目录名防止路径逃逸并从单源副本拷贝语料、写出 Dockerfile、instruction.md、solve.sh、case.json 与 task.toml。本地运行先 populate 再 run由于语料和验证器是 git-ignore 的运行前必须先恢复uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals uv run harbor run --path datasets/context-retrieval-evals ...第一条命令把单源语料和验证器文件铺回每个任务的environment/files/与tests/CIharbor.yml在构建任务镜像前会自动执行--populate。dataset.tomllibs/evals/datasets/context-retrieval-evals/dataset.toml说明该数据集未发布到 registry任务通过扫描任务目录发现无需逐任务清单。难度标注回写--stamp-tiers配合--calibration可以把校准后的实测难度写回每个任务的task.tomluv run python -m harbor_adapters.contextbench.main \ --stamp-tiers datasets/context-retrieval-evals \ --calibration datasets/context-retrieval-evals/calibration.json该命令只覆盖difficulty行保留source_difficulty作为溯源依据见 adapter.py。难度校准cb-cloud-65 到底有多难30 个任务是从全部 100 个源任务中选出的代表性样本选取依据是 gpt-5.6-terra 与 gpt-5.6-luna 各 6 次 rollouts 的配对结果记录在 calibration.json。cb-cloud-65在样本中的记录为source_difficulty hard、tier hardterra_pass_at_bare 0.56 次中通过 3 次、luna_pass_at_bare 0.83336 次中通过 5 次。在整个 30 任务样本表中数据集 README 的 30 任务表格它是 Terra 通过率最低的几个任务之一3/6说明这道多实体比较题即使对较强的模型也构成挑战是衡量 Agent 上下文检索与跨文件聚合能力的有效试金石。需要说明的是difficulty字段是 Context-Bench 原始难度分层2 easy · 10 medium · 18 hard并非模型性能的后验标签配对结果仅作为样本选择的证据而非榜单排序目标。Agent 实战要点如何在此类任务上拿满分综合任务设计与评分规则要在cb-cloud-65这类任务上稳定拿到 1.0关键在以下几点严格遵守答案通道协议最终答案必须是/app/answer.txt中的唯一内容。评分器只读该文件若文件不存在直接记 0.0见 judge.py。不要在答案中附加解释或我觉得是……之类的多答案因为给出多个答案且未明确最终答案会被判 0.0。工具化定向检索而非整库灌输语料约 6.4 万行一次性读入上下文既不现实也不必要。正确做法是先用 grep 类工具在pets.txt中按name: Wesley/name: Dominique精确定位再沿外键逐表跳转。把州这个限定词做进查询第 3 步同州居民中薪资最高的人要求 Agent 在整州范围内聚合employments.txt再与addresses.txt联表这是最常见的翻车点。两组的查询逻辑必须完全对称否则比较失去意义。最终答案只要人名评分规则规定期望答案是人名时响应中出现该名字即算正确因此即使推理过程中有中间错误只要最终落在正确答案Emily Schmidt上也能得 1.0——这与只看最终答案的评审原则一致。网络白名单不会帮你偷懒任务允许访问模型 API 与包镜像但任意 Web 被拦截答案无法从外部获取所有信息都必须来自/app/files。小结cb-cloud-65虽然只是一个单任务目录但它浓缩了 deepagents 上下文检索评估的完整设计哲学整库下发杜绝题目泄漏、外键文本格式强制跨文件检索、LLM 评审而非字符串比对容忍表达差异、单源化工程避免重复维护。无论是想理解该数据集还是为 Agent 排查此类检索任务的失败模式数据集 README 与 contextbench 适配器 都是最直接的入口。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 deepagents 上下文检索评估任务 cb-cloud-65 深度拆解：多实体比较型检索的沙箱实战
deepagents 上下文检索评估任务 cb-cloud-65 深度拆解多实体比较型检索的沙箱实战【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本篇技术指南以libs/evals/datasets/context-retrieval-evals/cb-cloud-65任务为样本完整讲解 deepagents 项目上下文检索评估context-retrieval evals的单任务结构从指令、语料、沙箱环境到评分器的全部组成并给出本地生成与运行评估集的方法。读完本文你将掌握这类整库下发、多文件关联检索评估任务的推理链路与实现原理可直接复现该任务的本地评估流程。任务概述一题读懂整类评估cb-cloud-65是 deepagents 仓库中上下文检索评估数据集的一个单任务目录属于 30 个任务的context-retrieval-evals数据集见 数据集 README。它的定位非常明确评估 Agent 在不知道哪些文件有用的前提下从多文件语料中检索、关联、聚合信息并回答问题的能力。该任务的完整指令只有两句话出自 instruction.mdWho has more insurance policies: the person with the highest salary among residents of the same state as the owner of pet Wesley, or the person with the highest salary among residents of the same state as the owner of pet Dominique?Use only the files under/app/files. Write your final answer (and nothing else) to/app/answer.txt.指令本身同时给出了两条硬约束数据边界只能使用/app/files目录下的文件禁止访问外部数据源输出协议最终答案且只能有最终答案写入/app/answer.txt。这个答案通道约定是整个 deepagents 评估框架的标准接口Agent 的最后一步动作就是把答案落到沙箱内的固定路径评分器随后读取该文件进行打分。单任务目录结构四个组成部分cb-cloud-65目录由四部分组成每个部分承担一个职责libs/evals/datasets/context-retrieval-evals/cb-cloud-65/ ├── environment/ │ └── Dockerfile # 沙箱镜像定义 ├── solution/ │ └── solve.sh # 参考答案脚本ground truth 落地 ├── tests/ │ └── case.json # 每任务独有问题 标准答案 ├── instruction.md # 下发给 Agent 的任务指令 └── task.toml # 任务元数据与网络策略task.toml任务元数据与网络策略task.toml 记录了该任务的来源、难度分级与沙箱网络策略version 1.3 [metadata] source contextbench suite cloud difficulty hard source_difficulty hard question_type multi_entity_comparison [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]关键字段解读source contextbench任务派生自 Context-Benchcloud套件的合成人物/宠物/车辆/账户记录数据difficulty与source_difficulty从源码看adapter.py生成时两者均写为 Context-Bench 原始难度标签hard而difficulty会在校准后被覆盖为实测难度source_difficulty保留来源标签用于溯源question_type multi_entity_comparison标识题型为多实体比较network_mode allowlist不是禁网而是白名单制。从生成器的注释可以看出Agent 需要在沙箱内自举拉取依赖包、调用所选模型的 API因此必须允许访问包镜像与模型服务商但任意 Web 仍被拦截防止通过外网直接查到答案。网络访问经由 LangSmith 的出口代理强制实施。Dockerfile最小化沙箱镜像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避免 Agent 在运行时触发apt从而保证沙箱运行期的所有出口流量都是 HTTPS 且受白名单约束COPY files/ /app/files/将整份语料拷入沙箱。tests/case.json唯一每任务独有文件case.json 是任务的问题与标准答案{input: Who has more insurance policies: the person with the highest salary among residents of the same state as the owner of pet Wesley, or the person with the highest salary among residents of the same state as the owner of pet Dominique?, ground_truth: Emily Schmidt}solution/solve.sh参考答案solution/solve.sh 给出了标准答案的落地方式#!/bin/sh set -eu printf %s\n Emily Schmidt /app/answer.txt本题的标准答案是Emily Schmidt。语料设计整库下发拒绝题目泄漏该数据集最核心的设计决策是每个任务都把完整语料10 个文件一次性下发给 Agent见 数据集 README 的说明因此 Agent 无法从文件数量/文件名推测哪些文件与题目相关必须真正执行检索—关联—聚合的完整链路。语料来自libs/evals/harbor_adapters/contextbench/vendor/files/共 10 个合成数据文件文件内容people.txt人物档案1500 条含 ID、姓名、出生日期等pets.txt宠物记录含主人 pers-ID 外键vehicles.txt车辆记录addresses.txt地址含所在州 stateemployments.txt雇佣记录含薪资 salary、职位insurance_policies.txt保险保单每人可能有多张bank_accounts.txt/credit_cards.txt银行账户 / 信用卡internet_accounts.txt网络账户medical_records.txt医疗记录以宠物文件为例记录格式为块状文本通过pers-XXXX外键与人物表关联### pet-0511 (owner: pers-XXXX) pet_id: pet-0511 name: Wesley species: Dog breed: PurebredWesley与Dominique正是出现在pets.txt中、以name:字段标识的宠物名。整份语料合计约 6.4 万行分散在 10 个文件中这决定了 Agent 无法一次性把所有内容塞进上下文必须依赖工具进行定向检索。问题拆解一条四级推理链cb-cloud-65的题型是multi_entity_comparison多实体比较。题目问的是Wesley 的主人所在州中薪资最高的人与Dominique 的主人所在州中薪资最高的人谁的保单更多从 vendored 记录第 66 行即 cb-cloud-65 对应的 0-based 索引 65可以看到该任务声明的必需文件集合pets.txt、people.txt、addresses.txt、employments.txt、insurance_policies.txt。推理链需要跨这 5 个文件完成宠物 → 主人在pets.txt中查找名为 Wesley / Dominique 的宠物读取其(owner: pers-XXXX)外键主人 → 州以pers-XXXX在addresses.txt中查该主人的居住州state同州居民 → 薪资最高者在employments.txt中聚合该州所有居民的薪资找出各自州内的薪资最高者保单数量比较在insurance_policies.txt中分别统计两人的保单数量输出保单更多的那个人的姓名。四个步骤中第 3 步是最容易出错的环节Agent 必须正确理解same state as the owner与主人同州这一限定在整州范围内聚合而非只查主人本人且两组的查询必须一致、可比较。这也解释了为什么cb-cloud-65的校准通过率明显偏低见下文难度校准比较型问题的中间任何一跳出错都会导致最终答案错误。评分机制Letta model_judge 兼容评审而非字符串比对这个数据集的评分不是标准答案的字符串相等比对而是忠实复刻上游 Letta letta-evals 的model_judgeLLM 评审见 judge.py 的文件头注释与 adapter.py 中的说明。评审流程评分器judge.py的工作流程如下读取/tests/case.json问题 标准答案、/tests/rubric.txt评审提示词、/app/answer.txtAgent 提交的答案用string.Formatter().vformat将{input}、{ground_truth}、{submission}三个占位符替换进 rubric 提示词无系统提示、无包装通过 Chat Completions 调用评审模型强制json_schema响应格式{score: float in [0,1], rationale}对 score 做clamp(0.0, 1.0)任何异常都按 0.0 处理与上游一致。评审温度规则上游对推理型评审模型有特殊温度处理judge.py 中忠实保留了该规则def _temperature(model: str) - float: Upstream rule: reasoning judges (o1/o3/gpt-5) reject 0.0, so use 1.0. if model.startswith((o1, o3)) or gpt-5 in model.lower(): return 1.0 return 0.0原因是 o1/o3/gpt-5 这类推理模型会在 API 层面拒绝 temperature0.0 的请求会返回 400所以上游对它们使用 1.0其余模型用 0.0。评审模型来自 harness 注入的环境变量JUDGE_MODELS默认gpt-5.6-luna凭据来自OPENAI_API_KEY、OPENAI_BASE_URL代码中不硬编码任何密钥。评分标准vendored rubric.txt 定义了 0.0 / 0.5 / 1.0 三档1.0正确最终答案与预期一致。数字格式等价$145,315.33145315.33、数字单词等价2 dogstwo dogs2、人名大小写不敏感、轻微措辞差异可接受、单位可隐含且若期望答案是人名响应中出现该名字即视为正确0.5仅限拒绝作答Agent 明确拒绝回答如 I cannot help with that仅适用于明确拒答不适用于尝试后失败0.0错误答案不同、声称找不到但答案存在、只给出缺失关键值的部分答案、给出多个答案且未明确哪个是最终答案。评审只关注最终答案中间推理有误但最终答对仍给 1.0中间推理正确但最终答错给 0.0。验证器调用验证器由 test.sh 驱动它只有两行——调用judge.py由 judge 自行把分数写入/logs/verifier/reward.txt#!/bin/sh set -eu # Faithful Letta model_judge grader; writes /logs/verifier/reward.txt itself. python3 /tests/judge.py单源化Single-sourcing哪些文件被提交哪些被生成这是一个重要的工程细节见 数据集 README 的说明语料与验证器文件在所有任务间完全一致因此被单源化存放并 git-ignore而不是在每个任务目录里重复提交语料唯一副本在libs/evals/harbor_adapters/contextbench/vendor/files/通过populate_corpus恢复进每个任务的environment/files/不变的验证器文件tests/{test.sh, judge.py, rubric.txt}唯一副本在templates/与vendor/rubric.txt每任务唯一提交的文件只有tests/case.json问题 标准答案。本地生成与运行评估集数据集生成逻辑在 adapter.py 与 CLI 驱动 main.py 中。任务 ID 的解析规则是cb-suite-i其中i是filesystem_cloud.jsonl中记录的 0-based 行索引因此cb-cloud-65对应第 66 行记录。生成指定任务uv run python -m harbor_adapters.contextbench.main \ --output-dir datasets/context-retrieval-evals \ --task-ids cb-cloud-65支持--limit N批量生成前 N 个任务也支持--task-ids一次传入多个 ID。生成器会校验任务 ID 格式必须是单一目录名防止路径逃逸并从单源副本拷贝语料、写出 Dockerfile、instruction.md、solve.sh、case.json 与 task.toml。本地运行先 populate 再 run由于语料和验证器是 git-ignore 的运行前必须先恢复uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals uv run harbor run --path datasets/context-retrieval-evals ...第一条命令把单源语料和验证器文件铺回每个任务的environment/files/与tests/CIharbor.yml在构建任务镜像前会自动执行--populate。dataset.tomllibs/evals/datasets/context-retrieval-evals/dataset.toml说明该数据集未发布到 registry任务通过扫描任务目录发现无需逐任务清单。难度标注回写--stamp-tiers配合--calibration可以把校准后的实测难度写回每个任务的task.tomluv run python -m harbor_adapters.contextbench.main \ --stamp-tiers datasets/context-retrieval-evals \ --calibration datasets/context-retrieval-evals/calibration.json该命令只覆盖difficulty行保留source_difficulty作为溯源依据见 adapter.py。难度校准cb-cloud-65 到底有多难30 个任务是从全部 100 个源任务中选出的代表性样本选取依据是 gpt-5.6-terra 与 gpt-5.6-luna 各 6 次 rollouts 的配对结果记录在 calibration.json。cb-cloud-65在样本中的记录为source_difficulty hard、tier hardterra_pass_at_bare 0.56 次中通过 3 次、luna_pass_at_bare 0.83336 次中通过 5 次。在整个 30 任务样本表中数据集 README 的 30 任务表格它是 Terra 通过率最低的几个任务之一3/6说明这道多实体比较题即使对较强的模型也构成挑战是衡量 Agent 上下文检索与跨文件聚合能力的有效试金石。需要说明的是difficulty字段是 Context-Bench 原始难度分层2 easy · 10 medium · 18 hard并非模型性能的后验标签配对结果仅作为样本选择的证据而非榜单排序目标。Agent 实战要点如何在此类任务上拿满分综合任务设计与评分规则要在cb-cloud-65这类任务上稳定拿到 1.0关键在以下几点严格遵守答案通道协议最终答案必须是/app/answer.txt中的唯一内容。评分器只读该文件若文件不存在直接记 0.0见 judge.py。不要在答案中附加解释或我觉得是……之类的多答案因为给出多个答案且未明确最终答案会被判 0.0。工具化定向检索而非整库灌输语料约 6.4 万行一次性读入上下文既不现实也不必要。正确做法是先用 grep 类工具在pets.txt中按name: Wesley/name: Dominique精确定位再沿外键逐表跳转。把州这个限定词做进查询第 3 步同州居民中薪资最高的人要求 Agent 在整州范围内聚合employments.txt再与addresses.txt联表这是最常见的翻车点。两组的查询逻辑必须完全对称否则比较失去意义。最终答案只要人名评分规则规定期望答案是人名时响应中出现该名字即算正确因此即使推理过程中有中间错误只要最终落在正确答案Emily Schmidt上也能得 1.0——这与只看最终答案的评审原则一致。网络白名单不会帮你偷懒任务允许访问模型 API 与包镜像但任意 Web 被拦截答案无法从外部获取所有信息都必须来自/app/files。小结cb-cloud-65虽然只是一个单任务目录但它浓缩了 deepagents 上下文检索评估的完整设计哲学整库下发杜绝题目泄漏、外键文本格式强制跨文件检索、LLM 评审而非字符串比对容忍表达差异、单源化工程避免重复维护。无论是想理解该数据集还是为 Agent 排查此类检索任务的失败模式数据集 README 与 contextbench 适配器 都是最直接的入口。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考