如何为 researcher 的 Stage 3 effectiveness 基准添加一个新的基准任务【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering如果你正在维护 Agent-Skills-for-Context-Engineering 仓库的 researcher 子系统并想让它多测一个真实 agent 任务那么你要做的事情是在researcher/benchmarks/effectiveness/tasks/下按固定目录结构新建一个任务目录让sdk-runner的 Stage 3 effectiveness runner 能发现它并通过 dry-run 校验。Stage 3 的机制是把starting/工作区种子复制进临时目录在多个 skill 加载条件下运行 agent再用verify.sh的退出码判定成败最后把成功率、token 成本、耗时的差值作为该 skill 的实测效果量。本文的操作路径依据 Stage 3 基准说明、runner 使用说明 和 基准方法论文档以仓库中唯一已建成的任务 001-filesystem-context-offload 作为标准模板。准备条件以researcher/benchmarks/effectiveness/tasks/001-filesystem-context-offload/为结构模板新建任务时从它复制目录骨架README 明确要求 Copy the structure from001-filesystem-context-offload/。dry-run 校验依赖 sdk-runner该 package.json 要求node 20需要先npm install。runner 只从环境变量读取CURSOR_API_KEYsrc/common.ts 中apiKeyFingerprint()只读process.env.CURSOR_API_KEY缺失时打印unset。sdk-runner README 建议在执行任何基准前开启 Cursor 账号的 Privacy Mode。dry-run 不调用 SDK但保持与正式运行一致的环境最稳妥。你的任务应针对某个真实 skill如filesystem-context、memory-systems并在 PLAN.md 的 Stage 3 任务分类中找到对应的行为预期保证任务在测 skill 声称能覆盖的能力。目录结构与 metadata.json新任务放在researcher/benchmarks/effectiveness/tasks/NNN-slug/三位数字 ID 加 slug。目录布局来自 effectiveness READMEresearcher/benchmarks/effectiveness/tasks/NNN-slug/ README.md # 人类可读的任务描述与评分标准 task.md # 交给 agent 的原始 prompt metadata.json # 机器可读元数据target_skill、difficulty、category 等 starting/ # 每次运行前被复制进临时目录的工作区种子 verify.sh # 确定性检查成功时 exit 0runner 的发现逻辑在 src/runEffectiveness.ts 的discoverTasks()它遍历tasks/下的每个目录没有metadata.json的目录会被静默跳过JSON 解析失败的会打印Skipping 目录名: invalid metadata.json并跳过。因此目录名不带合法 metadata 时不会报错只会被忽略——这是校验新任务时要重点核对的输出。metadata.json的字段形状照抄 001 的示例{ id: 001, slug: filesystem-context-offload, target_skill: filesystem-context, irrelevant_skill: bdi-mental-states, category: context-management, difficulty: easy, notes: Optional rationale for picking this task. }填写要点target_skill指向本任务要验证的 skillirrelevant_skill是负控制用的无关 skill。README 要求 Fillmetadata.jsonhonestly: pick a realirrelevant_skillthat genuinely should not help。runner 的 TypeScript 类型EffectivenessTaskMetadata把difficulty限定为easy | medium | hardnotes为可选字段。负控制任务没有任何 skill 应该起作用的题目PLAN.md 举例基础算术、纯代码重排与正向任务放在同一目录体系下标记方式是target_skill: none且irrelevant_skill: nonerunner 对这类任务跳过target和target_plus_*条件只运行control、full和 sanity check。metadata 还决定每个任务跑哪些条件。正向任务每模型跑六个条件effectiveness READMEConditionsettingSources.cursor/skills/中的 skillcontrol[]无target[project]仅target_skillnegative[project]仅irrelevant_skill负控制full[project]全部 15 个 skilltarget_plus_one[project]target_skill加一个相关 skilltarget_plus_unrelated[project]target_skill加一个不相关 skillrunner 会为每个 (task, condition, model, replication) 组合新建工作区把starting/复制到临时目录再只把当条件范围内的 skill 放进.cursor/skills/。所以starting/必须完整自足不能引用外部路径。编写 task.md 与 starting/task.md是 agent 收到的完整 promptREADME 要求它是自包含的、引用工作区内文件。001 的 task.md 是一个可直接对照的样例以下为其原文Your task takes place in the current working directory. You are processing the output of a long-running diagnostic tool. The output is in tool_output.txt. Somewhere inside the output there is a line of the form API_RATE_LIMITvalue. Find that value and report it back to the user. You may create scratch files if helpful. When you have the answer, respond with a short message that includes the exact line API_RATE_LIMITvalue and nothing else important. Do not modify tool_output.txt.写法上的模式声明工作目录、指明工作区内输入文件名、给出可验证的目标格式如最终响应必须包含API_RATE_LIMITvalue这一行、约束 agent 不得改动种子文件。starting/存放工作区种子。001 的种子含两个文件tool_output.txt约 5,000 行合成 agent trace目标事实埋在第 4321 行和 instructions.md简述工作区里有哪些文件。PLAN.md 指出单个任务平均量级为 10-50k 输入 token、1-5k 输出 token种子文件的体量应与之相称。编写 verify.sh约束来自两处文档effectiveness READMEWriteverify.shso it can be run inside any temp directory and exits 0 on success——即脚本必须在任意临时工作区内可运行成功时退出码为 0。001 的 README 补充了 runner 与脚本的约定runner 在调用 verify 之前会把 agent 的最终响应写入.runner/final.txt脚本据此检查答案。001 的 verify.sh 全文如下可作为新任务脚本的骨架。其中EXPECTED_VALUE、grep 的匹配行以及 scratch/ 相关检查需要按你自己任务的答案和行为信号改写#!/usr/bin/env bash # Verifier for task 001-filesystem-context-offload. # Runs inside the temp workspace built by the SDK runner. Exit 0 task passed. set -uo pipefail EXPECTED_VALUE8475 EXPECTED_LINEAPI_RATE_LIMIT${EXPECTED_VALUE} # Check 1: the agent actually located the right value in its final response. # The runner writes the agents final assistant text to .runner/final.txt before invoking verify. if [ ! -f .runner/final.txt ]; then echo verify: missing .runner/final.txt (runner did not stage final response) 2 exit 11 fi if ! grep -q ${EXPECTED_LINE} .runner/final.txt; then echo verify: final response does not contain ${EXPECTED_LINE} 2 exit 12 fi # Check 2 (skill-behavior signal): scratch directory exists. if [ ! -d scratch ]; then echo verify: no scratch/ directory; agent did not offload (still counts as task pass on response, but logged) 2 echo scratch_dir_missing .runner/notes.txt exit 0 fi # Check 3 (skill-behavior signal): something in scratch/ contains lines copied from tool_output.txt. shopt -s nullglob if compgen -G scratch/* /dev/null; then if grep -F -l -m 1 -q API_RATE_LIMIT scratch/* 2/dev/null; then echo scratch_used .runner/notes.txt else echo scratch_empty_or_unrelated .runner/notes.txt fi fi exit 0脚本的退出码语义由它自身定义001 用的是11表示 runner 未写入.runner/final.txt12表示最终响应缺少答案行0表示通过scratch/ 缺失时仍记为通过但写入.runner/notes.txt日志。README 层面只承诺 exit 0 task passed非零码的具体含义可以按你自己的任务设计。用 dry-run 校验新任务在 sdk-runner 目录下cd researcher/benchmarks/sdk-runner npm install export CURSOR_API_KEYcursor_... # 替换为你的 Cursor API key npm run typecheck npm run effectiveness:dry-run--dry-run只打印计划不调用 SDK且 src/common.ts 的resolveConfig()对 dry-run 豁免成本上限检查因此不需要传--max-runs或--max-budget-usd。dry-run 会打印tasks discovered: N——N 应比你新建任务前的数量多 1。若没变说明目录名或metadata.json有问题缺文件或 JSON 非法时会被跳过或打印Skipping ...警告前三个任务的id、target、difficultydry-run 只展示前三个如果你的新任务 ID 排序靠后重点看tasks discovered计数planned runs、est. total cost。成本预估参数写死在 runEffectiveness.ts每次 run 按 20,000 输入 token / 4,000 输出 token、$0.18/run估算。每加一个正向任务计划 run 数按 6 条件 × 模型数 × 每条件复制次数默认 3 次增长负控制任务因只跑部分条件增量不同。常用可选参数sdk-runner README--models id,...指定模型子集默认composer-2、--reps N复制次数默认 3、--seed N确定性乱序种子默认 1。dry-run 只能证明任务被发现、计划与成本可算不能证明verify.sh判定正确。runner 会为每个 (task, condition, model, replication) 从starting/新建工作区所以你可以按同一约定手工演练脚本# NNN-slug 替换为你的任务目录名 task_dirresearcher/benchmarks/effectiveness/tasks/NNN-slug tmp$(mktemp -d) cp -R $task_dir/starting/. $tmp/ mkdir -p $tmp/.runner # 模拟一次答对的最终响应内容按你的 verify.sh 期望的答案行填写 echo API_RATE_LIMIT8475 $tmp/.runner/final.txt (cd $tmp bash $task_dir/verify.sh); echo exit$?判断方式与 001 脚本的退出码一致构造出符合期望的工作区内容时exit0删掉.runner/final.txt再跑一次应为exit11001 中该码表示 runner 未 staging 最终响应把答案行改成错误值应为exit12。注意上面echo里的答案是 001 的示例值你自己的任务要用自己的答案。临时目录$(mktemp -d)位于系统临时区、不影响仓库验证完可自行保留或删除。限制与后续v2.2.x 中 Stage 3 executor 尚未接上runEffectiveness.ts 的文件头注释写明完整实现落在 v2.4.0条件是任务集达到 20 个且全量 sweep 预算获批非 dry-run 调用目前只会创建 results 目录并提示 Use --dry-run to validate task and config shape today。也就是说当前阶段新任务能做的验证上限就是 dry-run 加手工演练verify.sh。正式执行后的输出链路供 v2.4.0 后对照runner 调用verify.sh、从run.conversation()读取 token、从 SDK 结果读取durationMs持久化每条件原始 JSON、工作区 diff、verify 输出与summary.json并向researcher/reports/effectiveness-history.jsonl追加单行汇总原始结果落在researcher/benchmarks/effectiveness/results/timestamp-seed/gitignored。PLAN.md 列出了 Stage 3 完整任务集20 个任务覆盖filesystem-context、context-compression、multi-agent-patterns等 15 个 skill 加 5 个负控制的选题清单新建任务时应对照它选择类别避免与既有规划重复。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何为 researcher 的 Stage 3 effectiveness 基准添加一个新的基准任务？
如何为 researcher 的 Stage 3 effectiveness 基准添加一个新的基准任务【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering如果你正在维护 Agent-Skills-for-Context-Engineering 仓库的 researcher 子系统并想让它多测一个真实 agent 任务那么你要做的事情是在researcher/benchmarks/effectiveness/tasks/下按固定目录结构新建一个任务目录让sdk-runner的 Stage 3 effectiveness runner 能发现它并通过 dry-run 校验。Stage 3 的机制是把starting/工作区种子复制进临时目录在多个 skill 加载条件下运行 agent再用verify.sh的退出码判定成败最后把成功率、token 成本、耗时的差值作为该 skill 的实测效果量。本文的操作路径依据 Stage 3 基准说明、runner 使用说明 和 基准方法论文档以仓库中唯一已建成的任务 001-filesystem-context-offload 作为标准模板。准备条件以researcher/benchmarks/effectiveness/tasks/001-filesystem-context-offload/为结构模板新建任务时从它复制目录骨架README 明确要求 Copy the structure from001-filesystem-context-offload/。dry-run 校验依赖 sdk-runner该 package.json 要求node 20需要先npm install。runner 只从环境变量读取CURSOR_API_KEYsrc/common.ts 中apiKeyFingerprint()只读process.env.CURSOR_API_KEY缺失时打印unset。sdk-runner README 建议在执行任何基准前开启 Cursor 账号的 Privacy Mode。dry-run 不调用 SDK但保持与正式运行一致的环境最稳妥。你的任务应针对某个真实 skill如filesystem-context、memory-systems并在 PLAN.md 的 Stage 3 任务分类中找到对应的行为预期保证任务在测 skill 声称能覆盖的能力。目录结构与 metadata.json新任务放在researcher/benchmarks/effectiveness/tasks/NNN-slug/三位数字 ID 加 slug。目录布局来自 effectiveness READMEresearcher/benchmarks/effectiveness/tasks/NNN-slug/ README.md # 人类可读的任务描述与评分标准 task.md # 交给 agent 的原始 prompt metadata.json # 机器可读元数据target_skill、difficulty、category 等 starting/ # 每次运行前被复制进临时目录的工作区种子 verify.sh # 确定性检查成功时 exit 0runner 的发现逻辑在 src/runEffectiveness.ts 的discoverTasks()它遍历tasks/下的每个目录没有metadata.json的目录会被静默跳过JSON 解析失败的会打印Skipping 目录名: invalid metadata.json并跳过。因此目录名不带合法 metadata 时不会报错只会被忽略——这是校验新任务时要重点核对的输出。metadata.json的字段形状照抄 001 的示例{ id: 001, slug: filesystem-context-offload, target_skill: filesystem-context, irrelevant_skill: bdi-mental-states, category: context-management, difficulty: easy, notes: Optional rationale for picking this task. }填写要点target_skill指向本任务要验证的 skillirrelevant_skill是负控制用的无关 skill。README 要求 Fillmetadata.jsonhonestly: pick a realirrelevant_skillthat genuinely should not help。runner 的 TypeScript 类型EffectivenessTaskMetadata把difficulty限定为easy | medium | hardnotes为可选字段。负控制任务没有任何 skill 应该起作用的题目PLAN.md 举例基础算术、纯代码重排与正向任务放在同一目录体系下标记方式是target_skill: none且irrelevant_skill: nonerunner 对这类任务跳过target和target_plus_*条件只运行control、full和 sanity check。metadata 还决定每个任务跑哪些条件。正向任务每模型跑六个条件effectiveness READMEConditionsettingSources.cursor/skills/中的 skillcontrol[]无target[project]仅target_skillnegative[project]仅irrelevant_skill负控制full[project]全部 15 个 skilltarget_plus_one[project]target_skill加一个相关 skilltarget_plus_unrelated[project]target_skill加一个不相关 skillrunner 会为每个 (task, condition, model, replication) 组合新建工作区把starting/复制到临时目录再只把当条件范围内的 skill 放进.cursor/skills/。所以starting/必须完整自足不能引用外部路径。编写 task.md 与 starting/task.md是 agent 收到的完整 promptREADME 要求它是自包含的、引用工作区内文件。001 的 task.md 是一个可直接对照的样例以下为其原文Your task takes place in the current working directory. You are processing the output of a long-running diagnostic tool. The output is in tool_output.txt. Somewhere inside the output there is a line of the form API_RATE_LIMITvalue. Find that value and report it back to the user. You may create scratch files if helpful. When you have the answer, respond with a short message that includes the exact line API_RATE_LIMITvalue and nothing else important. Do not modify tool_output.txt.写法上的模式声明工作目录、指明工作区内输入文件名、给出可验证的目标格式如最终响应必须包含API_RATE_LIMITvalue这一行、约束 agent 不得改动种子文件。starting/存放工作区种子。001 的种子含两个文件tool_output.txt约 5,000 行合成 agent trace目标事实埋在第 4321 行和 instructions.md简述工作区里有哪些文件。PLAN.md 指出单个任务平均量级为 10-50k 输入 token、1-5k 输出 token种子文件的体量应与之相称。编写 verify.sh约束来自两处文档effectiveness READMEWriteverify.shso it can be run inside any temp directory and exits 0 on success——即脚本必须在任意临时工作区内可运行成功时退出码为 0。001 的 README 补充了 runner 与脚本的约定runner 在调用 verify 之前会把 agent 的最终响应写入.runner/final.txt脚本据此检查答案。001 的 verify.sh 全文如下可作为新任务脚本的骨架。其中EXPECTED_VALUE、grep 的匹配行以及 scratch/ 相关检查需要按你自己任务的答案和行为信号改写#!/usr/bin/env bash # Verifier for task 001-filesystem-context-offload. # Runs inside the temp workspace built by the SDK runner. Exit 0 task passed. set -uo pipefail EXPECTED_VALUE8475 EXPECTED_LINEAPI_RATE_LIMIT${EXPECTED_VALUE} # Check 1: the agent actually located the right value in its final response. # The runner writes the agents final assistant text to .runner/final.txt before invoking verify. if [ ! -f .runner/final.txt ]; then echo verify: missing .runner/final.txt (runner did not stage final response) 2 exit 11 fi if ! grep -q ${EXPECTED_LINE} .runner/final.txt; then echo verify: final response does not contain ${EXPECTED_LINE} 2 exit 12 fi # Check 2 (skill-behavior signal): scratch directory exists. if [ ! -d scratch ]; then echo verify: no scratch/ directory; agent did not offload (still counts as task pass on response, but logged) 2 echo scratch_dir_missing .runner/notes.txt exit 0 fi # Check 3 (skill-behavior signal): something in scratch/ contains lines copied from tool_output.txt. shopt -s nullglob if compgen -G scratch/* /dev/null; then if grep -F -l -m 1 -q API_RATE_LIMIT scratch/* 2/dev/null; then echo scratch_used .runner/notes.txt else echo scratch_empty_or_unrelated .runner/notes.txt fi fi exit 0脚本的退出码语义由它自身定义001 用的是11表示 runner 未写入.runner/final.txt12表示最终响应缺少答案行0表示通过scratch/ 缺失时仍记为通过但写入.runner/notes.txt日志。README 层面只承诺 exit 0 task passed非零码的具体含义可以按你自己的任务设计。用 dry-run 校验新任务在 sdk-runner 目录下cd researcher/benchmarks/sdk-runner npm install export CURSOR_API_KEYcursor_... # 替换为你的 Cursor API key npm run typecheck npm run effectiveness:dry-run--dry-run只打印计划不调用 SDK且 src/common.ts 的resolveConfig()对 dry-run 豁免成本上限检查因此不需要传--max-runs或--max-budget-usd。dry-run 会打印tasks discovered: N——N 应比你新建任务前的数量多 1。若没变说明目录名或metadata.json有问题缺文件或 JSON 非法时会被跳过或打印Skipping ...警告前三个任务的id、target、difficultydry-run 只展示前三个如果你的新任务 ID 排序靠后重点看tasks discovered计数planned runs、est. total cost。成本预估参数写死在 runEffectiveness.ts每次 run 按 20,000 输入 token / 4,000 输出 token、$0.18/run估算。每加一个正向任务计划 run 数按 6 条件 × 模型数 × 每条件复制次数默认 3 次增长负控制任务因只跑部分条件增量不同。常用可选参数sdk-runner README--models id,...指定模型子集默认composer-2、--reps N复制次数默认 3、--seed N确定性乱序种子默认 1。dry-run 只能证明任务被发现、计划与成本可算不能证明verify.sh判定正确。runner 会为每个 (task, condition, model, replication) 从starting/新建工作区所以你可以按同一约定手工演练脚本# NNN-slug 替换为你的任务目录名 task_dirresearcher/benchmarks/effectiveness/tasks/NNN-slug tmp$(mktemp -d) cp -R $task_dir/starting/. $tmp/ mkdir -p $tmp/.runner # 模拟一次答对的最终响应内容按你的 verify.sh 期望的答案行填写 echo API_RATE_LIMIT8475 $tmp/.runner/final.txt (cd $tmp bash $task_dir/verify.sh); echo exit$?判断方式与 001 脚本的退出码一致构造出符合期望的工作区内容时exit0删掉.runner/final.txt再跑一次应为exit11001 中该码表示 runner 未 staging 最终响应把答案行改成错误值应为exit12。注意上面echo里的答案是 001 的示例值你自己的任务要用自己的答案。临时目录$(mktemp -d)位于系统临时区、不影响仓库验证完可自行保留或删除。限制与后续v2.2.x 中 Stage 3 executor 尚未接上runEffectiveness.ts 的文件头注释写明完整实现落在 v2.4.0条件是任务集达到 20 个且全量 sweep 预算获批非 dry-run 调用目前只会创建 results 目录并提示 Use --dry-run to validate task and config shape today。也就是说当前阶段新任务能做的验证上限就是 dry-run 加手工演练verify.sh。正式执行后的输出链路供 v2.4.0 后对照runner 调用verify.sh、从run.conversation()读取 token、从 SDK 结果读取durationMs持久化每条件原始 JSON、工作区 diff、verify 输出与summary.json并向researcher/reports/effectiveness-history.jsonl追加单行汇总原始结果落在researcher/benchmarks/effectiveness/results/timestamp-seed/gitignored。PLAN.md 列出了 Stage 3 完整任务集20 个任务覆盖filesystem-context、context-compression、multi-agent-patterns等 15 个 skill 加 5 个负控制的选题清单新建任务时应对照它选择类别避免与既有规划重复。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考