Agent-Skills-for-Context-Engineering 基准评测体系全解：从确定性防作弊到技能有效性验证-北京尧图网络

Agent-Skills-for-Context-Engineering 基准评测体系全解从确定性防作弊到技能有效性验证【免费下载链接】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是一套面向上下文工程Context Engineering、多智能体架构与生产级 Agent 系统的技能Skill集合。为了让这套技能体系可被证明有效而非看起来有效仓库在researcher/benchmarks/下构建了一套分层基准评测体系先用零成本的确定性结构检查守住质量底线再用真实 LLM 验证技能描述能否把任务路由到正确技能最终用真实 Agent 任务测量技能加载带来的效果增量。本文以 researcher/benchmarks/README.md 为核心骨架结合 researcher/benchmarks/PLAN.md、各阶段子文档与 SDK 运行器源码完整还原这套评测体系的架构、方法论、运行方式与已发布结果读完即可理解如何严谨地评测一套 Agent 技能库并可直接在本仓库中复现路由基准的完整流程。评测体系的定位让研究到技能的生产管道难以被游戏researcher/benchmarks/README.md用三句话定义了整套体系的灵魂评测对象是研究到技能research-to-skill生产管道即 researcher 目录下的自治研究闭环而非通用 Agent 能力确定性检查永远先行Deterministic checks always run first基于模型的评审model-judged evaluation只能作为补充性证据advisory evidence绝不允许覆盖确定性失败——这条原则保证了评测结果不会被 LLM 评委的主观性污染结果可以纵向追踪每次基准运行可追加一行到 researcher/reports/benchmark-history.jsonl用于长期回归检测。围绕这三条researcher/benchmarks/下分四层实现了完整的评测架构researcher/benchmarks/ ├── PLAN.md # 四阶段评测总体计划与方法论 ├── scenarios/adversarial.jsonl # 七个对抗性作弊场景Stage 0 ├── effectiveness/ # Stage 3技能有效性评测 │ ├── README.md │ └── tasks/001-filesystem-context-offload/ # 第一个真实任务模板 ├── router/ # Stage 2技能路由基准 │ ├── README.md │ ├── prompts.jsonl # 地面真值 prompt 集 │ ├── routing-prompt.md # 路由提示模板 │ └── results-published/ # 已发布结果2026-05-15 基线修复后 ├── sdk-runner/ # Cursor SDK 执行层 │ ├── src/common.ts # 共享工具预算、种子、并发、解析 │ ├── src/runRouter.ts # Stage 2 运行器 │ └── src/runEffectiveness.ts # Stage 3 运行器脚手架 └── goldens/adversarial-goldens.json四阶段架构从零成本防作弊到跨技能组合researcher/benchmarks/PLAN.md将整套体系划分为四个递进阶段每一阶段回答How To Read Results中更靠前的一个问题阶段版本测量内容成本状态0v2.2.0管道对游戏化的抵抗力、结构有效性$0已完成1v2.3.0逐技能健康度确定性指标$0已完成语料库聚合 0.81415 个技能中 2 个被标记2v2.3.0技能路由准确率LLM 作路由器Cursor 积分每次全量扫描约 $7已完成基线与修复后 delta 已发布3v2.4.0技能在真实 Agent 任务上的有效性Cursor 积分更高已搭脚手架已构建 1 个任务4v2.5.0跨技能组合Cursor 积分未来规划阅读顺序即验证逻辑任何在较早阶段失败的技能都无需等到后续阶段就有理由被移除或重做。Stage 0/1 是确定性闸门Stage 2 验证描述能否路由Stage 3 验证技能是否真的有用Stage 4 验证技能组合是否协同。Stage 0对抗性作弊场景Stage 0 是管道自身的红队测试researcher/benchmarks/scenarios/adversarial.jsonl 定义了七个对抗场景覆盖语义新颖性用不同措辞复述已接受的机制、来源质量可信作者发表无实现机制的泛泛建议、溯源完整性引用自部分失败检索的证据、评分数学weighted_total 计算错误、技能质量冗长但无行为变化、管道完整性提案修改用于批准自身的 rubric等。每个场景都标注了应触发的确定性闸门如novelty_human_review_or_duplicate、content_reject、run_readiness_fail用于验证校验脚本确实会拦截这些作弊模式。适用于每一阶段的方法论原则PLAN.md明确声明这些原则对所有阶段生效这也是整套体系区别于跑几个 prompt 看效果的关键可复现性Reproducibility每次运行由冻结的配置描述模型 ID、种子、fixture 修订版本、仓库 commit SHA原始输出transcript、judge JSON、工作区 diff随运行记录持久化每次运行向历史 JSONL 追加一行包含配置哈希与原始产物指针--seed/--configCLI 参数允许第三方精确复现。统计纪律Statistical Discipline每个条件至少 3 次重复replication用 bootstrap 95% 置信区间报告效应量而非点估计尽可能做配对比较同一任务不同条件用 Wilcoxon 符号秩检验样本量不足的运行必须标记为 preliminary。偏差缓解Bias Mitigation路由器基准中打乱技能顺序对抗位置偏差评审模型与被评审模型必须来自不同家族对抗自我偏好配对评分加入长度归一化与更短者胜规则对抗长度偏差任务集包含负向对照技能本不应有帮助的任务以测量假阳性率。消融Ablations逐技能其他不变有无该技能、留一法每次移除一个技能、顺序不同顺序加载技能子集。披露Disclosure所有 prompt 发布在researcher/benchmarks/stage/所有地面真值以 fixture 发布所有评分代码发布在researcher/scripts/原始运行输出脱敏后提交到仓库。Stage 1确定性技能健康度$0永不失败的底线Stage 1 是便宜且无争议的底板对每个skills/name/SKILL.md做确定性结构评分在用户注意到之前捕获漂移、缺失章节、过期声明与未明确说明的注意事项。核心指标见 PLAN.mdline_count不得超过 500 行超出即失败frontmatter_valid名称与目录匹配、描述存在、描述为第三人称、描述长度不超过 1024 字符required_sections必须包含 When to Activate、Core Concepts、Practical Guidance、Gotchas、Integration、Referencesgotcha_countGotchas 章节编号条目数目标 ≥ 3code_example_count围栏代码块数量internal_links_resolved所有指向其他技能 SKILL.md 的链接必须解析到真实文件external_link_count仅记录存在性可达性检查为可选的--check-urls需要网络claim_coverage数字声明匹配\b\d(\.\d)?%\b、\b\dx\b、基准名称等中被claim_id引用到 researcher/claims/index.jsonl 的比例mechanism_coverage/activation_case_coverage分别统计 researcher/mechanisms/registry.jsonl 与 researcher/fixtures/activation-cases.jsonl 中归属该技能的条目数。加权聚合评分权重被调校为尽早暴露漂移0.20 * normalize(required_sections) 0.15 * normalize(gotcha_count, target3) 0.10 * normalize(code_example_count, target2) 0.15 * normalize(internal_links_resolved) 0.10 * normalize(activation_case_coverage) 0.15 * normalize(claim_coverage) 0.10 * normalize(mechanism_coverage) 0.05 * binary(frontmatter_valid)得分低于 0.75 的技能会在每日快照中被标记。输出写入 researcher/reports/skill-health.json由 researcher/scripts/skill_health.py 重新生成趋势记录写入skill-health-history.jsonl由 researcher/scripts/loop_daily.py 写入。Stage 2技能路由基准——验证描述就是全部信号Stage 2 是第一个真正调用模型的基准。它测试一个关键假设部署后的 Agent 决定是否加载某个技能时唯一信号就是该技能 frontmatter 中的激活场景描述v2.2.0 用激活场景描述取代了 v2.1.x 的关键字触发。如果描述无法把任务路由到正确技能其余所有管道工作都是空谈。过程与数据流Fixtureresearcher/benchmarks/router/prompts.jsonl每行{prompt_id, prompt, expected_primary_skill, acceptable_secondary_skills, rejected_skills, reason}。首批 50 条计划扩展到 100 条构成每技能一个的单技能正向对照15 条、v2.2.0 边界混淆对5 对 × 3 变体 15 条、多技能可接受组合10 条、无技能应适配的负向对照5 条、应正确解析的微妙激活案例5 条。路由提示模板researcher/benchmarks/router/routing-prompt.md使用{{SKILL_BLOCK}}、{{USER_PROMPT}}、{{SKILL_COUNT}}三个占位符要求模型只返回一个严格 JSON 对象ranking技能名从最相关到最不相关排序的数组、confidence0.0~1.0、rationale一句话解释。运行器researcher/benchmarks/sdk-runner/src/runRouter.ts。对每个 (prompt, model, replication)用确定性种子打乱技能顺序shuffleSeeded基于 mulberry32 PRNG调用Agent.prompt(routingPrompt, { settingSources: [], model: { id }, local: { cwd } })其中settingSources: []确保路由 Agent 没有加载任何技能prompt 中的描述是唯一信号解析 JSON 失败则记录为format_failure不奖励坏输出最多重试 2 次MAX_FORMAT_ATTEMPTS与地面真值比对记录 top-1 与 top-3 准确率。模型composer-2、claude-opus-4-7、gpt-5.5、gemini-3.1-pro。模型列表在运行时来自Cursor.models.list()不可用的模型记录为model_unavailable后继续运行。重复每 (prompt, model) 3 次100 × 4 × 3 每次全量 1200 次调用。运行器内置成本分析路由提示约 3-5k 输入 token、约 500 输出 token按 Cursor 积分计每次全量低于 $5按不利的零售价估算约 $5-15。代码中的预估常量ESTIMATED_TOKENS_INPUT4000、ESTIMATED_TOKENS_OUTPUT400、ESTIMATED_USD_PER_RUN0.012与之一致。已发布结果v2.3.02026-05-15 第二轮完整报告见 researcher/benchmarks/router/results-published/2026-05-15-v2.md600/600 运行仓库 commit358c36bseed1concurrency4墙钟时间约 15 分钟 vs 顺序执行的约 60 分钟。核心结论4 个模型中有 3 个 top-1 提升Composer-2 0.888→0.913、GPT-5.5 0.886→0.913、Gemini 3.1 Pro 0.886→0.925Claude Opus 4.7 0.886→0.867 但 top-3 提升 1.7pp基本是噪声。全部 4 个模型 top-3 提升Composer-2 0.930→0.973。定向描述重写效果显著context-fundamentalstop-1 从 0.255 提升到 0.48923.4pp单技能最大提升project-development从 0.750 提升到 1.00025pp达到完美路由tool-design从 0.729 提升到 0.807。此前最难的 prompt 基本修复p001解释为什么上下文窗口会退化top-1 从 0.00 升到 0.83p037 从 0.00 升到 1.00。一个表面回归实为伪影advanced-evaluation看似从 0.980 掉到 0.797但基线仅完成 49/60 次运行v1 运行器在 566/600 时中途死掉新运行完成全部 60 次且新增运行集中在真正有歧义的 p048规划带消融与基线的 KV 压缩评测其绝对正确数 48基线vs 47新基本持平。剩余失败模式集中context-fundamentals仍有 14 次误路由到project-developmentp046/p048 全部模型 top-1 为 0属于真正有歧义的 prompt应考虑重新标注p047翻译任务负向对照的期望主技能本身有争议。方法学笔记格式合规率 597/60099.5%3 次格式失败全部来自 GeminiGemini 中位延迟 9130ms约为其他模型的 2.5-3 倍。下图为该轮结果的 Leaderboard 与技能路由增益可视化来自 v2.3.0 release 资产Stage 3技能有效性基准——证明技能真的有用Stage 3 是头号结果加载相关技能应改善结果质量、token 效率或两者加载无关技能应无效果或仅有轻微噪声。详细方法见 researcher/benchmarks/effectiveness/README.md。任务布局与地面真值每个任务是一个目录researcher/benchmarks/effectiveness/tasks/NNN-slug/tasks/001-filesystem-context-offload/ README.md # 人类可读的任务描述与评分标准 task.md # 给 Agent 的确切 prompt metadata.json # 机器可读元数据target_skill, difficulty, category starting/ # 每次运行前复制到临时目录的工作区种子 verify.sh # 确定性检查成功返回 exit 0metadata.json 的结构id、slug、target_skill、irrelevant_skill、category、difficulty、notes保证了机器可读的地面真值——irrelevant_skill必须是一个真正不应该有帮助的技能如 filesystem-context 任务的负向对照选bdi-mental-states。六条件实验设计每个任务 × 每个模型运行六个条件条件settingSources.cursor/skills/中的技能control[]无不加载任何技能target[project]仅target_skillnegative[project]仅irrelevant_skill负向对照full[project]全部 15 个技能target_plus_one[project]目标技能一个相关技能target_plus_unrelated[project]目标技能一个无关技能交互对照运行器按 (task, condition, model, replication) 为每个组合从starting/构建全新工作区只把范围内的技能复制进.cursor/skills/。负向对照任务无技能应有帮助设置target_skill: none与irrelevant_skill: none运行器只跑control、full与一个健全性检查。首个任务示例001-filesystem-context-offload该任务的假设是装备了filesystem-context技能的 Agent 会把约 5000 行的模拟工具输出starting/tool_output.txt卸载到scratch/下的文件再用 grep 行范围读取做定点检索从而显著降低 token 消耗而控制组无技能倾向把完整负载塞回上下文。task.md 要求 Agent 从输出中找到API_RATE_LIMITvalue这行埋在第 4321 行真实值为 8475并简短报告。verify.sh 的三重检查体现了确定性闸门哲学检查 1 是硬性通过条件最终回复必须包含API_RATE_LIMIT8475由运行器先把最终回复暂存到.runner/final.txt检查 2/3 是技能行为信号scratch/目录是否存在、其中是否有从tool_output.txt复制的行不通过只写.runner/notes.txt记录scratch_dir_missing或scratch_empty_or_unrelated不判定失败——因为 token 成本与墙钟时间才是效应量成功率的差异则由检查 1 捕获。所有运行都会持久化每条件的原始结果 JSON、工作区 diff、verify 输出聚合结果以单行追加到 researcher/reports/effectiveness-history.jsonl。规模与报告初始任务集规划 20 个覆盖 filesystem-context、context-compression、multi-agent-patterns、memory-systems、tool-design、evaluation、advanced-evaluation、harness-engineering、context-degradation、context-optimization、latent-briefing、bdi-mental-states、hosted-agents、project-development、context-fundamentals外加 5 个负向对照基础算术、纯代码重格式化等。全量扫描规模20 任务 × 6 条件 × 4 模型 × 3 重复 1440 次 Agent 运行估算成本 $50-200。报告维度包括逐技能效应量成功率 delta、token 成本 delta、时长 delta、带 95% CI 的效应图、负向对照验证无关技能效应量应接近零否则测试有偏、逐模型 Leaderboard。Stage 4跨技能组合v2.5.0 规划组合是精选技能集合相比单技能可能增值或毁值的地方。Stage 4 测试两个技能同时加载是产生加性、协同还是冲突的指导集成章节是否准确技能 A 提到技能 B 时同时加载是否真的能组合技能在上下文中的出现顺序是否有影响。它被推迟到 v2.5.0因为需要 Stage 3 的基础设施与专门针对交互设计的任务目前仅在PLAN.md中作了草图式规划。SDK 集成细节为什么选择 Cursor SDK 作为执行层settingSources 与技能加载控制settingSources是整套评测体系最关键的机制PLAN.md 明确给出了四种取值及用途settingSources: []默认不加载磁盘上的设置Agent 无技能。用作控制条件以及路由基准要求描述是唯一信号settingSources: [project]从 cwd 加载.cursor/用于通过向受控工作区复制技能来实现只加载特定技能settingSources: [project, plugins]额外加载插件技能对基准评测用处不大settingSources: all加载包括用户与团队设置在内的一切基准中禁用——会泄漏调用者环境。Stage 3 中每个任务工作区按条件新鲜构建把starting/复制到临时目录再按条件把技能放进.cursor/skills/。依赖的 SDK 结果结构运行器依赖RunResultid、status、result、model、durationMs、git与run.conversation(): PromiseConversationTurn[]获取逐轮 transcripttoken 计数来自会话事件精确 schema 取决于 SDK 版本运行器做了抽象。安全与成本门槛隐私模式运行基准的 Cursor 账户启用 Privacy Mode评测数据不进入训练显式 API KeyapiKey总是显式传入绝不依赖环境变量杜绝跨租户事故自动释放每个 Agent 使用await using语法确保自动析构限流处理429 时按指数退避 1s/2s/4s/8s/16s成本闸门--max-runsAgent 调用总数硬上限、--max-budget-usd估算成本上限超限快速失败、--dry-run只打印计划不调用、--models开发期只跑单个模型。每个运行器在任何 Agent 调用前都会打印成本预估。这些约束在 common.ts 中落地为纯函数parseCliFlags/resolveConfig无成本上限且非 dry-run 时拒绝运行、assertBudget计划规模超过--max-runs或预估成本超过--max-budget-usd即抛错、forecastCost、shuffleSeeded种子化 Fisher-Yates mulberry32 PRNG保证可复现、resultFileName${promptId}-${modelId}-${rep}.json的单一来源写入与恢复扫描共用防止两者漂移、runConcurrently有界并发执行器。注意运行器强制要求CURSOR_API_KEY已导出否则拒绝执行。运行方式复现路由基准全流程路由基准Stage 2的完整运行命令来自 researcher/benchmarks/router/README.md 与已发布报告的可复现章节cd researcher/benchmarks/sdk-runner npm install npm run router:dry-run # 查看计划与成本预估 export CURSOR_API_KEYyour-key npm run router:run -- --max-budget-usd 5 # 执行带成本上限复现已发布结果600 次运行4 模型 × 3 重复cd researcher/benchmarks/sdk-runner npm install export CURSOR_API_KEYyour-key node --experimental-strip-types src/runRouter.ts --models claude-opus-4-7,composer-2,gemini-3.1-pro,gpt-5.5 --reps 3 --seed 1 --max-budget-usd 15 python3 researcher/scripts/render_router_report.py \ --results researcher/benchmarks/router/results/date-seed \ --fixture researcher/benchmarks/router/prompts.jsonl \ --output researcher/benchmarks/router/results-published/date.md运行器支持断点续跑默认启用--no-resume关闭按resultFileName扫描已有结果跳过已完成项因此被中断的扫描可以精确接续。每次运行把摘要追加到 researcher/reports/router-history.jsonl含模型、fixture 修订、repo SHA、准确率原始逐运行 JSON 保留在 gitignored 的results/date-seed/目录。Stage 3 运行器目前是脚手架形态v2.2.x但已可用npm run effectiveness:dry-run校验任务与配置形态新增任务时按 effectiveness/README.md 的六步流程复制001-filesystem-context-offload模板即可。如何阅读结果与已知局限PLAN.md的 How To Read Results 给出了按顺序回答的四个问题管道是否通过确定性闸门始终要求Stage 0 1描述能否路由到正确技能Stage 2逐模型技能是否真的帮助Stage 3逐技能 × 模型 × 任务技能是否可组合Stage 4未来任何在较早阶段失败的技能无需等到后续阶段即可判定需要移除或重做。与此同时PLAN.md也诚实地列出了体系不解决的问题token 逐任务核算依赖 SDK 暴露的逐轮数据若conversation()不含 token 计数则退化为墙钟与请求数代理Cursor 模型目录随时间不稳定跨版本对比需谨慎用户策划的任务集规模小公共可信度要求扩充到 100 任务或与现有公共基准对齐真实部署环境与基准条件不同这里的效应量是上界而非保证。这种确定性闸门优先、模型评审为辅、完整披露方法学、效应量标注为初步结果的做法正是评测一套 Agent 技能库时值得复用的工程范式。【免费下载链接】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），仅供参考

Agent-Skills-for-Context-Engineering 基准评测体系全解：从确定性防作弊到技能有效性验证

相关推荐

Vue开发工具链：Volar+Prettier+ESLint配置实战

电商运营三大隐性成本解析与管控策略

Renovate Forgejo Tags 数据源全解析：从 Git 标签到自动化依赖更新

更多资讯

LifeOS 品牌重命名工程解析：RenamePlan 分波次策略、RenameMap.json 映射表与切日运行手册

支线任务设计原理与工程实践指南

MATLAB OCR实战：从图像预处理到批量识别与JSON输出

电脑卡顿的底层逻辑：CPU、内存与硬盘如何协作与排查

Django+Vue视频点播系统实战：HLS转码与全栈联调

DeviceNet从站转SPI网关的硬件与协议深度调试指南

今日更新

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？