Deep Agents 上下文检索评测任务 cb-cloud-79 全解析多跳推理、沙箱约束与 LLM 判定机制【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本文以 deepagents 仓库中libs/evals/datasets/context-retrieval-evals/cb-cloud-79/评测任务为对象完整拆解其instruction.md所定义的多跳multi-hop上下文检索问题并结合该任务目录下的task.toml、environment/Dockerfile、solution/solve.sh、tests/case.json以及 Harbor 适配器源码还原一条问题定义 → 语料供给 → 沙箱约束 → 答案通道 → LLM 评分的完整评测链路。读完本文你将理解这类深度智能体Deep Agent评测任务的文件结构、网络白名单设计、答案写入与判定机制并掌握如何在本地复现与运行这类任务。一、任务本体instruction.md 让 Agent 做什么cb-cloud-79/instruction.md是任务的唯一指令入口全文由一段多跳问题与两条输出约束组成原样如下Who owns more vehicles: the person with the most insurance policies among residents of the same state as the owner of pet Mackenzie (using highest total bank balance as a tiebreaker if tied for most insurance policies), OR the person with the most insurance policies among residents of the same state as the owner of pet Jose (using the same tiebreaker)?Use only the files under/app/files. Write your final answer (and nothing else) to/app/answer.txt.这个问题不是一次查表就能回答的而是典型的multi_hop_chain多跳链式推理。要把问题拆解开Agent 至少需要完成以下逻辑链定位宠物记录找到名为Mackenzie的宠物及其主人owner从人物记录中确定该主人所在州state在该州的全部居民中找出保险单insurance policies数量最多的人若并列则以总银行存款total bank balance最高作为决胜条件得到候选人 A对宠物Jose重复上述 13 步得到候选人 B比较候选人 A 与 B 各自拥有的车辆vehicles数量输出拥有更多车辆者的姓名。任务的黄金答案ground truth记录在tests/case.json中即Tiffany Johnson。从答案反推Tiffany Johnson 是候选人 AMackenzie 主人所在州中保单最多、存款决胜最高者且其车辆数超过候选人 B。这种先按州圈定人群 → 聚合保单数 → 存款决胜 → 再跨实体比较车辆数的问题设计正是 Context-Bench 云套件cloud suite中 hard 难度多跳题的标准形态。二、任务目录结构与数据流cb-cloud-79是一个自包含self-contained的 Harbor 评测任务目录其结构与每个文件的分工如下路径作用instruction.md面向 Agent 的唯一任务指令问题 输出约束task.toml任务元数据与沙箱网络配置Harbor 读取environment/Dockerfile沙箱镜像构建预装 curl、将语料拷入/app/files/environment/files/完整语料库10 个文件、约 6.47 万行git 忽略、由 populate 恢复solution/solve.sh参考解答脚本向/app/answer.txt写入黄金答案tests/case.json唯一提交到仓库的按任务差异化文件问题 黄金答案tests/{test.sh,judge.py,rubric.txt}判定器三件套所有任务字节级相同git 忽略、单源化整体数据流是Harbor 按task.toml构建沙箱镜像 → 启动 Agent 并注入instruction.md→ Agent 只允许读取/app/files/下的语料 → Agent 将唯一答案写入/app/answer.txt→ Harbor 执行tests/test.sh内部调用tests/judge.py→ 判定器调用 LLM judge 打分结果写入/logs/verifier/reward.txt。值得强调的是语料供给策略任务把完整语料10 个文件整体交给 Agent而不是只给相关文件。这样 Agent 无法通过文件存在性推断哪些文件重要必须真正执行检索retrieval、跨文件连接join与聚合aggregate这正是该数据集命名为 context-retrieval-evals 的原因见 数据集 README。三、沙箱与网络约束只能读/app/files只能写/app/answer.txtinstruction.md中Use only the files under/app/files与Write your final answer (and nothing else) to/app/answer.txt不是建议而是由环境设计与判定机制共同强制的沙箱约束。3.1 镜像构建environment/Dockerfileenvironment/Dockerfile基于python:3.12-slim关键点在于把网络相关操作前移到构建期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 证书在构建期装好运行时引导bootstrap就不需要再走 apt运行期出口流量被限制为任务网络白名单内的 HTTPS 请求。COPY files/ /app/files/把语料库以只读形式交付到/app/files/Agent 只能在此目录内搜索。3.2 网络白名单task.toml的[environment]task.toml的元数据与网络配置如下版本1.3version 1.3 [metadata] source contextbench suite cloud difficulty hard source_difficulty hard question_type multi_hop_chain [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 中_write_task_files的说明明确指出Agent 在沙箱内运行必须能访问包镜像pypi.org、*.pythonhosted.org、astral.sh等以安装依赖也必须能访问所选模型的 API 以完成引导和推理但任意网页访问仍被阻断从而防止 Agent 通过搜索直接查答案。模型提供方域名覆盖了计分卡工作流可选的全部 providerapi.anthropic.com、api.openai.com、generativelanguage.googleapis.com、openrouter.ai、api.fireworks.ai、ollama.com、api.groq.com、integrate.api.nvidia.com、api.x.ai等且只放行 API 端点永远不放行答案来源站点。difficulty hard与source_difficulty hard前者是权威难度档位可能被校准过程覆写后者保留 Context-Bench 原始标注以做溯源question_type multi_hop_chain标记问题类型。四、答案通道与判定机制不是字符串比对而是 LLM 判分4.1 黄金答案与参考解答tests/case.json是每个任务唯一提交到仓库的按任务差异化文件内容为{input: 问题全文, ground_truth: Tiffany Johnson}。solution/solve.sh是参考解答#!/bin/sh set -eu printf %s\n Tiffany Johnson /app/answer.txt它演示了答案通道的正确用法将唯一答案无任何多余输出写入/app/answer.txt。4.2 判定三件套与 LLM judge数据集 README 明确说明评分不是字符串相等比对而是复刻上游 Letta letta-evals 的 LLMmodel_judge方案——用rubric.txt措辞/姓名/数字容错对 Agent 的答案进行 0.0 / 0.5 / 1.0 三档打分。tests/test.sh极简仅负责调用判定器#!/bin/sh set -eu # Faithful Letta model_judge grader; writes /logs/verifier/reward.txt itself. python3 /tests/judge.pytests/judge.py是在沙箱内对上游RubricGrader的重实现其核心行为见 judge.py 源码与模块 docstring包括输入与输出从/tests/case.json读问题与黄金答案、从/tests/rubric.txt读评分规则、从/app/answer.txt读 Agent 提交最终把分数写入/logs/verifier/reward.txt并打印rewardscore。提示词构造用string.Formatter().vformat将 rubric 模板中的{input}、{ground_truth}、{submission}三个占位符替换为实际值不加 system prompt、不做包裹与上游一致。结构化输出通过 Chat Completions 的response_format: json_schema要求 judge 返回{score: float ∈ [0,1], rationale: str}随后score clamp(score, 0.0, 1.0)兜底。温度规则与上游完全一致——judge 模型若匹配o1/o3/gpt-5推理模型API 拒绝 temperature0.0传 0.0 会 400则用 1.0其他模型用 0.0。模型与环境注入judge 模型取JUDGE_MODELS环境变量Harbor 判定环境注入缺省回退gpt-5.6-luna端点与密钥来自OPENAI_BASE_URL/OPENAI_API_KEY均不硬编码。容错最多重试 5 次任何异常最终按上游语义记为 0.0 分HTTP 错误会透出 API 返回的详细原因便于排查如不支持的 temperature这类 400。这一机制意味着 Agent 答案只要语义正确人名、措辞、数字可容错即使与ground_truth的字符串不完全一致也能获得满分这也解释了为什么case.json中的ground_truth只是参考答案而非判分依据。五、从 Context-Bench 源数据到 Harbor 任务适配器全链路cb-cloud-79不是手写的而是由harbor_adapters/contextbench适配器从 Context-Bench 云套件自动生成的。理解生成逻辑有助于你判断这类任务的可信度与可复现性。5.1 记录定位与任务生成任务 ID 形如cb-suite-i其中i是filesystem_suite.jsonl中的零基行号见 adapter.py 的parse_task_id。cb-cloud-79即对应filesystem_cloud.jsonl的第 79 条记录100 条记录中的一条。generate_task从记录中取出agent_args、input问题与ground_truth答案然后把vendor/files/下全部*.txt语料拷入任务目录写出带统一约束模板的instruction.md用shlex.quote安全地生成写入答案的solution/solve.sh写入带网络白名单的task.toml最后生成tests/case.json并铺设判定器三件套。5.2 单源化single-sourced设计这是该数据集最重要的工程实践README 称之为Corpus and verifier are single-sourced语料单源约 6.47 万行的完整语料只在harbor_adapters/contextbench/vendor/files/保存一份通过 populate 恢复进每个任务的environment/files/因此每个任务的语料字节级一致且被 git 忽略。判定器单源tests/{test.sh,judge.py,rubric.txt}对 30 个任务完全一致只保存在templates/与vendor/rubric.txt同样 git 忽略并按需恢复。仅差异化文件入库每个任务提交到仓库的只有tests/case.json问题 黄金答案以及任务元数据。由于存在 git 忽略文件在本地运行前必须先执行 populate把语料与判定器恢复出来。README 给出的标准流程是uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals uv run harbor run --path datasets/context-retrieval-evals ...CIharbor.yml会在构建任务镜像前自动执行--populate。5.3 难度校准populate_corpus负责恢复上述忽略文件stamp_calibrated_tiers则读取calibration.json把任务task.toml中的difficulty覆写为校准后的权威档位同时保留source_difficulty用于溯源。因此 cb-cloud-79 最终呈现的difficulty hard既有 Context-Bench 源标注支撑也经过了模型实测结果的选择性校验。六、难度定位与任务表现cb-cloud-79 在 30 个任务中的位置context-retrieval-evals共含 30 个任务是从 Context-Bench 云套件 100 条记录中选取的代表性样本保留全量语料的难度分布。README 明确说明难度档位划分基于gpt-5.6-terra与gpt-5.6-luna各 6 次 rollout 的配对结果全量 100 任务Terra 510/60085.0%、Luna 552/60092.0%所选 30 任务为 153/18085.0%与 166/18092.2%比例保持。档位构成2 easy · 10 medium · 18 hard。cb-cloud-79 属于 hard 档、multi_hop_chain类型配对结果中Terra pass6 3/6、Luna pass6 6/6——Terra 恰好在该任务上暴露了多跳链式推理的薄弱点而 Luna 全过是所选样本中区分度最高的任务之一。calibration.json是机器可读的校准记录保存源运行、聚合总数及每个任务的 Terra/Luna 结果pass_at_bare为兼容既有适配器保留 Terra 通过率。这些数字是选择证据selection evidence而非目标排行榜排序引用时需注意语境。七、把 cb-cloud-79 当作模板如何阅读与扩展同类任务如果你要理解或新增类似的上下文检索评测任务可以以 cb-cloud-79 为最小完整样例一份instruction.md问题 约束、一份task.toml元数据 网络白名单、一份environment/Dockerfile语料挂载 运行时最小依赖、一份solution/solve.sh黄金答案通道、一份tests/case.json差异化输入再加上由templates/单源铺设的判定器。语料与判定器不必每个任务重复维护这正是适配器populate_corpus存在的意义。从评测方法论角度cb-cloud-79 传递了几个关键设计信号全语料交付不给 Agent 任何该读哪些文件的提示检索能力本身就是被测对象多跳 决胜条件问题需要跨宠物/人物/保险/银行/车辆多类记录聚合比较单一文件内无法直接回答网络白名单而非断网允许访问包镜像与模型 API保证 Agent 能活着完成任务但阻断答案查找通道LLM 判分而非字符串比对容忍措辞与格式差异测的是推理正确性而不是格式化输出能力单源化 校准语料与判定器只维护一份难度档位以实测数据校准并保留源标注溯源。八、小结cb-cloud-79/instruction.md看似只有一段问题与两条约束但它背后是一条完整的评测工程链路Context-Bench 云套件源数据经 contextbench 适配器 自动生成自包含任务task.toml通过网络白名单约束 Agent 只能访问包镜像与模型 APIenvironment/Dockerfile将完整语料挂载进/app/files/tests/judge.py以 LLM 判分器rubric 模板、json_schema 输出、推理模型温度规则、5 次重试容错替代字符串比对最终把 Agent 的多跳检索与推理质量量化为 0.0 / 0.5 / 1.0 三档分数。对于想要构建或评估深度智能体检索能力的团队这份任务既是一个可运行的 benchmark 样例也是一份评测工程设计范本。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Deep Agents 上下文检索评测任务 cb-cloud-79 全解析：多跳推理、沙箱约束与 LLM 判定机制
Deep Agents 上下文检索评测任务 cb-cloud-79 全解析多跳推理、沙箱约束与 LLM 判定机制【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents本文以 deepagents 仓库中libs/evals/datasets/context-retrieval-evals/cb-cloud-79/评测任务为对象完整拆解其instruction.md所定义的多跳multi-hop上下文检索问题并结合该任务目录下的task.toml、environment/Dockerfile、solution/solve.sh、tests/case.json以及 Harbor 适配器源码还原一条问题定义 → 语料供给 → 沙箱约束 → 答案通道 → LLM 评分的完整评测链路。读完本文你将理解这类深度智能体Deep Agent评测任务的文件结构、网络白名单设计、答案写入与判定机制并掌握如何在本地复现与运行这类任务。一、任务本体instruction.md 让 Agent 做什么cb-cloud-79/instruction.md是任务的唯一指令入口全文由一段多跳问题与两条输出约束组成原样如下Who owns more vehicles: the person with the most insurance policies among residents of the same state as the owner of pet Mackenzie (using highest total bank balance as a tiebreaker if tied for most insurance policies), OR the person with the most insurance policies among residents of the same state as the owner of pet Jose (using the same tiebreaker)?Use only the files under/app/files. Write your final answer (and nothing else) to/app/answer.txt.这个问题不是一次查表就能回答的而是典型的multi_hop_chain多跳链式推理。要把问题拆解开Agent 至少需要完成以下逻辑链定位宠物记录找到名为Mackenzie的宠物及其主人owner从人物记录中确定该主人所在州state在该州的全部居民中找出保险单insurance policies数量最多的人若并列则以总银行存款total bank balance最高作为决胜条件得到候选人 A对宠物Jose重复上述 13 步得到候选人 B比较候选人 A 与 B 各自拥有的车辆vehicles数量输出拥有更多车辆者的姓名。任务的黄金答案ground truth记录在tests/case.json中即Tiffany Johnson。从答案反推Tiffany Johnson 是候选人 AMackenzie 主人所在州中保单最多、存款决胜最高者且其车辆数超过候选人 B。这种先按州圈定人群 → 聚合保单数 → 存款决胜 → 再跨实体比较车辆数的问题设计正是 Context-Bench 云套件cloud suite中 hard 难度多跳题的标准形态。二、任务目录结构与数据流cb-cloud-79是一个自包含self-contained的 Harbor 评测任务目录其结构与每个文件的分工如下路径作用instruction.md面向 Agent 的唯一任务指令问题 输出约束task.toml任务元数据与沙箱网络配置Harbor 读取environment/Dockerfile沙箱镜像构建预装 curl、将语料拷入/app/files/environment/files/完整语料库10 个文件、约 6.47 万行git 忽略、由 populate 恢复solution/solve.sh参考解答脚本向/app/answer.txt写入黄金答案tests/case.json唯一提交到仓库的按任务差异化文件问题 黄金答案tests/{test.sh,judge.py,rubric.txt}判定器三件套所有任务字节级相同git 忽略、单源化整体数据流是Harbor 按task.toml构建沙箱镜像 → 启动 Agent 并注入instruction.md→ Agent 只允许读取/app/files/下的语料 → Agent 将唯一答案写入/app/answer.txt→ Harbor 执行tests/test.sh内部调用tests/judge.py→ 判定器调用 LLM judge 打分结果写入/logs/verifier/reward.txt。值得强调的是语料供给策略任务把完整语料10 个文件整体交给 Agent而不是只给相关文件。这样 Agent 无法通过文件存在性推断哪些文件重要必须真正执行检索retrieval、跨文件连接join与聚合aggregate这正是该数据集命名为 context-retrieval-evals 的原因见 数据集 README。三、沙箱与网络约束只能读/app/files只能写/app/answer.txtinstruction.md中Use only the files under/app/files与Write your final answer (and nothing else) to/app/answer.txt不是建议而是由环境设计与判定机制共同强制的沙箱约束。3.1 镜像构建environment/Dockerfileenvironment/Dockerfile基于python:3.12-slim关键点在于把网络相关操作前移到构建期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 证书在构建期装好运行时引导bootstrap就不需要再走 apt运行期出口流量被限制为任务网络白名单内的 HTTPS 请求。COPY files/ /app/files/把语料库以只读形式交付到/app/files/Agent 只能在此目录内搜索。3.2 网络白名单task.toml的[environment]task.toml的元数据与网络配置如下版本1.3version 1.3 [metadata] source contextbench suite cloud difficulty hard source_difficulty hard question_type multi_hop_chain [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 中_write_task_files的说明明确指出Agent 在沙箱内运行必须能访问包镜像pypi.org、*.pythonhosted.org、astral.sh等以安装依赖也必须能访问所选模型的 API 以完成引导和推理但任意网页访问仍被阻断从而防止 Agent 通过搜索直接查答案。模型提供方域名覆盖了计分卡工作流可选的全部 providerapi.anthropic.com、api.openai.com、generativelanguage.googleapis.com、openrouter.ai、api.fireworks.ai、ollama.com、api.groq.com、integrate.api.nvidia.com、api.x.ai等且只放行 API 端点永远不放行答案来源站点。difficulty hard与source_difficulty hard前者是权威难度档位可能被校准过程覆写后者保留 Context-Bench 原始标注以做溯源question_type multi_hop_chain标记问题类型。四、答案通道与判定机制不是字符串比对而是 LLM 判分4.1 黄金答案与参考解答tests/case.json是每个任务唯一提交到仓库的按任务差异化文件内容为{input: 问题全文, ground_truth: Tiffany Johnson}。solution/solve.sh是参考解答#!/bin/sh set -eu printf %s\n Tiffany Johnson /app/answer.txt它演示了答案通道的正确用法将唯一答案无任何多余输出写入/app/answer.txt。4.2 判定三件套与 LLM judge数据集 README 明确说明评分不是字符串相等比对而是复刻上游 Letta letta-evals 的 LLMmodel_judge方案——用rubric.txt措辞/姓名/数字容错对 Agent 的答案进行 0.0 / 0.5 / 1.0 三档打分。tests/test.sh极简仅负责调用判定器#!/bin/sh set -eu # Faithful Letta model_judge grader; writes /logs/verifier/reward.txt itself. python3 /tests/judge.pytests/judge.py是在沙箱内对上游RubricGrader的重实现其核心行为见 judge.py 源码与模块 docstring包括输入与输出从/tests/case.json读问题与黄金答案、从/tests/rubric.txt读评分规则、从/app/answer.txt读 Agent 提交最终把分数写入/logs/verifier/reward.txt并打印rewardscore。提示词构造用string.Formatter().vformat将 rubric 模板中的{input}、{ground_truth}、{submission}三个占位符替换为实际值不加 system prompt、不做包裹与上游一致。结构化输出通过 Chat Completions 的response_format: json_schema要求 judge 返回{score: float ∈ [0,1], rationale: str}随后score clamp(score, 0.0, 1.0)兜底。温度规则与上游完全一致——judge 模型若匹配o1/o3/gpt-5推理模型API 拒绝 temperature0.0传 0.0 会 400则用 1.0其他模型用 0.0。模型与环境注入judge 模型取JUDGE_MODELS环境变量Harbor 判定环境注入缺省回退gpt-5.6-luna端点与密钥来自OPENAI_BASE_URL/OPENAI_API_KEY均不硬编码。容错最多重试 5 次任何异常最终按上游语义记为 0.0 分HTTP 错误会透出 API 返回的详细原因便于排查如不支持的 temperature这类 400。这一机制意味着 Agent 答案只要语义正确人名、措辞、数字可容错即使与ground_truth的字符串不完全一致也能获得满分这也解释了为什么case.json中的ground_truth只是参考答案而非判分依据。五、从 Context-Bench 源数据到 Harbor 任务适配器全链路cb-cloud-79不是手写的而是由harbor_adapters/contextbench适配器从 Context-Bench 云套件自动生成的。理解生成逻辑有助于你判断这类任务的可信度与可复现性。5.1 记录定位与任务生成任务 ID 形如cb-suite-i其中i是filesystem_suite.jsonl中的零基行号见 adapter.py 的parse_task_id。cb-cloud-79即对应filesystem_cloud.jsonl的第 79 条记录100 条记录中的一条。generate_task从记录中取出agent_args、input问题与ground_truth答案然后把vendor/files/下全部*.txt语料拷入任务目录写出带统一约束模板的instruction.md用shlex.quote安全地生成写入答案的solution/solve.sh写入带网络白名单的task.toml最后生成tests/case.json并铺设判定器三件套。5.2 单源化single-sourced设计这是该数据集最重要的工程实践README 称之为Corpus and verifier are single-sourced语料单源约 6.47 万行的完整语料只在harbor_adapters/contextbench/vendor/files/保存一份通过 populate 恢复进每个任务的environment/files/因此每个任务的语料字节级一致且被 git 忽略。判定器单源tests/{test.sh,judge.py,rubric.txt}对 30 个任务完全一致只保存在templates/与vendor/rubric.txt同样 git 忽略并按需恢复。仅差异化文件入库每个任务提交到仓库的只有tests/case.json问题 黄金答案以及任务元数据。由于存在 git 忽略文件在本地运行前必须先执行 populate把语料与判定器恢复出来。README 给出的标准流程是uv run python -m harbor_adapters.contextbench.main --populate datasets/context-retrieval-evals uv run harbor run --path datasets/context-retrieval-evals ...CIharbor.yml会在构建任务镜像前自动执行--populate。5.3 难度校准populate_corpus负责恢复上述忽略文件stamp_calibrated_tiers则读取calibration.json把任务task.toml中的difficulty覆写为校准后的权威档位同时保留source_difficulty用于溯源。因此 cb-cloud-79 最终呈现的difficulty hard既有 Context-Bench 源标注支撑也经过了模型实测结果的选择性校验。六、难度定位与任务表现cb-cloud-79 在 30 个任务中的位置context-retrieval-evals共含 30 个任务是从 Context-Bench 云套件 100 条记录中选取的代表性样本保留全量语料的难度分布。README 明确说明难度档位划分基于gpt-5.6-terra与gpt-5.6-luna各 6 次 rollout 的配对结果全量 100 任务Terra 510/60085.0%、Luna 552/60092.0%所选 30 任务为 153/18085.0%与 166/18092.2%比例保持。档位构成2 easy · 10 medium · 18 hard。cb-cloud-79 属于 hard 档、multi_hop_chain类型配对结果中Terra pass6 3/6、Luna pass6 6/6——Terra 恰好在该任务上暴露了多跳链式推理的薄弱点而 Luna 全过是所选样本中区分度最高的任务之一。calibration.json是机器可读的校准记录保存源运行、聚合总数及每个任务的 Terra/Luna 结果pass_at_bare为兼容既有适配器保留 Terra 通过率。这些数字是选择证据selection evidence而非目标排行榜排序引用时需注意语境。七、把 cb-cloud-79 当作模板如何阅读与扩展同类任务如果你要理解或新增类似的上下文检索评测任务可以以 cb-cloud-79 为最小完整样例一份instruction.md问题 约束、一份task.toml元数据 网络白名单、一份environment/Dockerfile语料挂载 运行时最小依赖、一份solution/solve.sh黄金答案通道、一份tests/case.json差异化输入再加上由templates/单源铺设的判定器。语料与判定器不必每个任务重复维护这正是适配器populate_corpus存在的意义。从评测方法论角度cb-cloud-79 传递了几个关键设计信号全语料交付不给 Agent 任何该读哪些文件的提示检索能力本身就是被测对象多跳 决胜条件问题需要跨宠物/人物/保险/银行/车辆多类记录聚合比较单一文件内无法直接回答网络白名单而非断网允许访问包镜像与模型 API保证 Agent 能活着完成任务但阻断答案查找通道LLM 判分而非字符串比对容忍措辞与格式差异测的是推理正确性而不是格式化输出能力单源化 校准语料与判定器只维护一份难度档位以实测数据校准并保留源标注溯源。八、小结cb-cloud-79/instruction.md看似只有一段问题与两条约束但它背后是一条完整的评测工程链路Context-Bench 云套件源数据经 contextbench 适配器 自动生成自包含任务task.toml通过网络白名单约束 Agent 只能访问包镜像与模型 APIenvironment/Dockerfile将完整语料挂载进/app/files/tests/judge.py以 LLM 判分器rubric 模板、json_schema 输出、推理模型温度规则、5 次重试容错替代字符串比对最终把 Agent 的多跳检索与推理质量量化为 0.0 / 0.5 / 1.0 三档分数。对于想要构建或评估深度智能体检索能力的团队这份任务既是一个可运行的 benchmark 样例也是一份评测工程设计范本。【免费下载链接】deepagentsThe batteries-included agent harness.项目地址: https://gitcode.com/GitHub_Trending/de/deepagents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考