Agent 技能路由基准测试Agent-Skills-for-Context-Engineering 的 Router Benchmark 实战与源码解析【免费下载链接】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本文档以仓库中 researcher/benchmarks/router/results-published/2026-05-19.md 这份 2026-05-19 路由器基准测试报告为主体系统讲解该仓库如何用 LLM-as-Router 的方法检验 15 个 Agent Skill 的激活描述activation description能否把用户任务准确路由到正确技能。读完本文你将掌握 Stage 2 Router Benchmark 的完整方法论、600 次运行的结果解读方法排行榜、混淆矩阵、最难 prompt、以及如何在本地用 SDK Runner 精确复现这套测试。一、这份报告在测什么从描述能不能被读懂验证技能门面这份 2026-05-19 报告是仓库四级基准计划见 researcher/benchmarks/PLAN.md中Stage 2v2.3.0的一次正式结果发布。Stage 2 的核心假设Hypothesis是v2.2.0 frontmatter 中的激活场景描述activation-scenario descriptions取代了 v2.1.x 的关键字触发应当能让前沿模型把用户 prompt 路由到正确的技能达到高 top-1 准确率和很高的 top-3 准确率。为什么这很重要正如 PLAN.md 所写Skill descriptions are the only signal a deployed agent uses to decide whether to load a skill. If they dont route correctly, the rest of the harness is academic.技能描述是已部署 Agent 决定是否加载某技能的唯一信号。如果路由不正确其余的一切都只是纸上谈兵。本轮 sweep 的特殊任务在于它验证的是**语料库级加固corpus-wide hardening**之后的效果——15 个技能的正文、机制映射、声明溯源记录claim provenance、语料库索引条目和激活 fixtures 全部更新后路由没有出现大面积崩塌。关键运行元数据报告中逐项给出便于精确复现与对比元数据值运行时间戳2026-05-19T05:52:52Z仓库 commit272702e0bb1ff4f78d45fb7253da872da170d458fixture sha256-168f974d930836bc9cseed1runs600modelsclaude-opus-4-7, composer-2, gemini-3.1-pro, gpt-5.5reps per (prompt, model)3二、方法论只有描述是信号的纯路由实验报告的方法论部分非常严谨也是理解后续所有数据的前提fixture 是人工标注的 ground-truth prompt 集合。每条记录形如{prompt_id, prompt, expected_primary_skill, acceptable_secondary_skills, rejected_skills, reason}存放在 researcher/benchmarks/router/prompts.jsonl。初始 50 条 prompt 覆盖五类场景详见 researcher/benchmarks/router/README.md单技能正向控制每个技能 1 条共 15 条来自 v2.2.0 边界混淆清单的对抗性边界对5 对 × 3 变体 15 条多技能均合理的组合型 prompt10 条任何技能都不应匹配的负向控制5 条应当仍能解析的微妙激活案例5 条。每条 prompt 与 15 个技能的激活描述一同呈现给模型技能顺序按 seed 确定性洗牌每个复制品 shuffle 不同。洗牌由 common.ts 中的shuffleSeeded实现——基于 mulberry32 种子 PRNG 的确定性 Fisher-Yates 洗牌保证同一 seed 下可复现同时用于缓解位置偏差position bias详见 PLAN.md 的 Bias Mitigation 一节。模型必须返回严格 JSON 的排名列表模板见 researcher/benchmarks/router/routing-prompt.md占位符为{{SKILL_BLOCK}}、{{USER_PROMPT}}、{{SKILL_COUNT}}JSON 结构要求ranking、confidence、rationale三个字段。关键设计settingSources: []。运行时代码在 runRouter.ts 中调用Agent.prompt(filled, { apiKey, model: { id }, local: { cwd: REPO_ROOT, settingSources: [] } })——任何技能都没有被加载进 Agent唯一的路由信号就是 prompt 里的描述文本。这是验证描述质量而非技能正文质量的关键隔离。评分top-1 准确率 排第一的技能是否等于人工标注的expected_primary_skilltop-3 准确率 期望技能是否出现在前三位。置信区间为95% bootstrap2000 次重采样渲染脚本 render_router_report.py 的bootstrap_ci实现。三、执行结果600/600 可用零格式失败3.1 执行摘要的四个结论报告的执行摘要给出了四个可验证的结论600/600 可用记录0 格式失败第一遍跑出了零星的空输出/格式失败 SDK 结果这些记录通过 runner 的resume 路径loadExistingResults按promptId-modelId-rep.json文件名去重续跑重跑后全部成功。runner 现在对瞬时格式失败自动重试一次MAX_FORMAT_ATTEMPTS 2见 runRouter.ts。语料库级改动没有带来大范围路由崩塌三个模型 top-1 保持在 0.913 及以上Claude Opus 4.7 较低0.840但其剩余 miss 集中在与上一份报告相同的已知模糊边界上。新加固的技能路由干净bdi-mental-states、hosted-agents、latent-briefing、memory-systems、multi-agent-patterns在本轮全部满分。剩余失败高度集中且已被理解p046是一个没有任何真正匹配技能的负向控制 Python 格式化任务p048是一个真正模糊的 advanced-evaluation/evaluation/latent-briefing 混合 promptcontext-fundamentals仍是最弱的兜底边界。3.2 与上一轮对比的总体结论与 2026-05-15-v2.md 相比实质结论未变描述-基准测试的迭代闭环description-benchmark loop是有效的语料库级正文/元数据加固没有引入广泛的路由回归。报告明确指出下一笔基准投入应是 Stage 3 有效性测试加载完整技能正文。四、逐模型排行榜0.84–0.92 的 top-1 区间ModelTop-195% CITop-395% CIFormat FailuresMedian msgemini-3.1-pro0.920[0.873, 0.960]0.933[0.893, 0.973]08631composer-20.913[0.867, 0.953]0.947[0.907, 0.980]03004gpt-5.50.913[0.867, 0.953]0.973[0.947, 0.993]04050claude-opus-4-70.840[0.780, 0.893]0.933[0.893, 0.973]03178从源码可以验证这套表格是自动渲染而非手写的render_router_report.py 的render()按 top-1 降序排序输出 leaderboard置信区间来自bootstrap_ci2000 次重采样、2.5%/97.5% 分位median ms 来自summarize_per_model。这也意味着只要你有原始 per-run JSON就可以随时复现这张表。几点读表要点top-3 显著高于 top-1多数模型 0.93说明即使首选技能选错期望技能几乎总在前三——路由失败多为边界相邻技能而非完全跑偏。Claude Opus 4.7 的 0.840 是四者中最低但其 CI [0.780, 0.893] 与其余模型有部分重叠且其 miss 全部落在已知模糊边界。延迟差异明显gemini-3.1-pro 中位数 8631ms约为其余模型的 2–3 倍上一轮2026-05-15-v2也观察到同样模式9130ms vs 3269–4201ms。五、逐技能混淆矩阵谁和谁打架混淆矩阵的行是 ground-truth 的expected_primary_skill列是模型实际预测的结果只统计finished运行Expected \ Predictedadvanced-evaluationbdi-mental-statescontext-compressioncontext-degradationcontext-fundamentalscontext-optimizationevaluationfilesystem-contextharness-engineeringhosted-agentslatent-briefingmemory-systemsmulti-agent-patternsproject-developmenttool-designadvanced-evaluation(n60)48-----10---2----bdi-mental-states(n24)-24-------------context-compression(n36)-234------------context-degradation(n36)---36-----------context-fundamentals(n42)---5196-------12-context-optimization(n36)-----36---------evaluation(n36)4-----32--------filesystem-context(n48)-------48-------harness-engineering(n36)--------36------hosted-agents(n24)---------24-----latent-briefing(n24)----------24----memory-systems(n36)-----------36---multi-agent-patterns(n48)------------48--project-development(n48)-------------48-tool-design(n57)----1--4-----745解读要点7 个技能满分对角线 nbdi-mental-states、context-degradation、context-optimization、filesystem-context、harness-engineering、hosted-agents、latent-briefing、memory-systems、multi-agent-patterns、project-development——其中报告特别点名bdi-mental-states、hosted-agents、latent-briefing、memory-systems、multi-agent-patterns为新加固后路由干净。context-fundamentals是最弱边界42 次期望中只有 19 次被正确预测12 次跑到project-development、6 次到context-optimization、5 次到context-degradation。这与上一轮2026-05-15-v2中14 次混淆到 project-development的模式一致说明它是团队已认知的兜底 catch-all 技能。advanced-evaluation与evaluation是经典边界对60 次中 10 次被预测为evaluation反过来evaluation也有 4 次被预测为advanced-evaluation。这正是 v2.2.0 边界混淆清单里被重点设计的对抗对之一对应 prompt p012/p017 vs p016/p033。tool-design有 7 次跑到project-development、4 次到filesystem-context描述里工具契约/整合与管线开发/文件化上下文的边界仍有提升空间。矩阵的生成逻辑同样在 render_router_report.py 的build_confusion中只统计status finished的记录按expected → predicted计数对角线加粗。六、最难 Prompt失败是设计出来的可控失败报告给出按 top-1 率升序排列的 10 个最难 promptPromptExpectedTop-1 RatePredicted Primariesp046tool-design0.00filesystem-context,project-developmentp048advanced-evaluation0.00evaluation,latent-briefingp047context-fundamentals0.17context-fundamentals,project-developmentp045context-fundamentals0.33context-fundamentals,project-developmentp040context-fundamentals0.50context-fundamentals,context-optimizationp001context-fundamentals0.58context-degradation,context-fundamentalsp016evaluation0.67advanced-evaluation,evaluationp041tool-design0.75context-fundamentals,project-development,tool-designp030context-compression0.83bdi-mental-states,context-compressionp002context-degradation1.00context-degradation结合 prompts.jsonl 原文逐条理解p046Reformat this Python file with consistent indentation and remove trailing whitespace. 这是一个负向控制rejected_skills明确排除了 latent-briefing/bdi-mental-states/memory-systems本身没有真正的匹配技能fixture 把tool-design标为最接近的通用工具任务。0.00 的 top-1 是预期中的、可接受的失败。p048Plan how to evaluate whether my latent-briefing-style KV compaction actually preserves task accuracy. 设计上就是 triple-ambiguousacceptable_secondary_skills同时给了 latent-briefing、evaluation、harness-engineering。模型在evaluation和latent-briefing之间摇摆是合理的。上一轮2026-05-15-v2同样 0.00报告建议考虑重新标注。p045/p047都是负向控制Compute the area of a triangle、Translate this English paragraph to French没有技能真正适合fixture 把兜底的context-fundamentals标为 expected。模型倾向于选project-development——从路由角度这不算错误行为只是 fixture 标注有讨论空间上一轮 p047 甚至因此 -33pp 回归。p001Explain why context windows degrade as they fill, and how attention mechanics make middle-of-context information less recoverable. 期望是context-fundamentalsreason 明确说基础性解释归 context-fundamentals但也允许context-degradation作为次选。0.58 的 top-1 与foundation vs 诊断的边界直接相关。要点这些最难 prompt多数是刻意设计的负向控制或模糊边界失败模式集中且可解释并非描述质量的整体性崩塌——这本身就是基准测试有效性的证明。七、从源码看 runner 的执行细节与成本闸门runRouter.ts 完整实现了报告描述的全部流程几个值得展开的实现细节确定性运行计划buildRunPlan对每个 (prompt, model, rep) 生成一个条目shuffleSeed hash32(promptId|modelId|rep|baseSeed)——同一 seed 下任何人重跑都得到完全相同的洗牌序列这是可复现的根基。严格 JSON 解析与格式失败惩罚parseRouterJson用/\{[\s\S]*\}/提取最外层 JSON 对象解析失败则记录为format_failure不给坏输出奖励并且MAX_FORMAT_ATTEMPTS 2时只自动重试一次。本轮 0 格式失败正是重试 resume两条机制共同作用的结果。成本闸门resolveConfig强制要求--max-runs或--max-budget-usd或--unsafe-no-cost-cap或--dry-run四者之一否则直接拒绝运行assertBudget在调用任何 Agent 前用估算ESTIMATED_TOKENS_INPUT4000、ESTIMATED_TOKENS_OUTPUT400、ESTIMATED_USD_PER_RUN0.012做 fail-fast 预算校验。完整 CLI 参数表来自parseCliFlags--dry-run只打印计划与成本预测不发 SDK 调用--models a,b,c限定模型子集默认composer-2--reps N每 (prompt, model) 的复制次数默认 3--seed N随机种子默认 1--max-runs NAgent 调用硬上限--max-budget-usd N估算成本上限--concurrency N并发度2026-05-15-v2 报告显示 concurrency4 把墙钟时间从 ~60 分钟压到 ~15 分钟--fixture path自定义 fixture--no-resume忽略已有结果强制重跑。产物持久化每个 per-run 结果写入researcher/benchmarks/router/results/date-seed/下的promptId-modelId-rep.json含 raw_text、parsed ranking、duration_ms 等summary.json汇总各模型 top-1/top-3/格式失败率并 append 一行到 researcher/reports/router-history.jsonlgitignored用于纵向回归追踪。模型不可用时的容错CursorAgentError被捕获后记录为model_unavailable而非中断整个 sweep运行继续。另外值得注意runner 从 researcher/corpus/index.json 读取技能清单再通过extractDescription解析每个skills/name/SKILL.md的 frontmatterdescription字段作为路由信号——这也解释了为什么该基准直接服务于激活描述质量这一目标。八、如何精确复现本轮 600 次运行报告给出可直接执行的复现命令完整命令链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 ../../scripts/render_router_report.py \ --results ../router/results/date-seed \ --fixture ../router/prompts.jsonl \ --output ../router/results-published/date.md执行要点与前置条件前置条件Node.js 环境、在researcher/benchmarks/sdk-runner下npm install依赖cursor/sdk、CURSOR_API_KEY环境变量。runner 在 key 未设置或 SDK 未安装时会明确报错拒绝运行见 runRouter.ts。先干跑再看预算正式花钱前建议先执行npm run router:dry-run对应 README 中的快捷命令见 researcher/benchmarks/router/README.md它会打印计划条目数、估算 token、最坏情况 SDK 调用数plan.length × MAX_FORMAT_ATTEMPTS与估算总成本不产生任何 SDK 调用。fixture 校验报告头部的fixture sha256-16: 8f974d930836bc9c由fixtureSha对 prompts.jsonl 计算 sha256 前 16 位得到重跑时若 fixture 未变这个值应一致可作为输入一致性检查。关于 seed1 与 reps3seed 决定洗牌序列与计划顺序reps3 是 PLAN.md 要求的最低复制次数用于方差估计。改变任一参数都会得到不同但同样有效的结果。报告渲染render_router_report.py支持--baseline dir --baseline-label text生成 Delta vs baseline 对比章节——这正是 2026-05-15-v2 报告 delta 部分的生成方式也是 README 建议的改描述 → 重跑 → 对比 delta闭环的落地工具。适用前提与限制依据 PLAN.md What This Plan Does Not Solvetoken 级成本核算依赖 SDKconversation()暴露的数据缺失时以墙钟时间与请求数为代理Cursor 模型目录随时间变化跨版本比较需谨慎真实部署效果不等于基准上限本文所有数字仅代表该 seed/fixture/commit 条件下的路由能力。九、从 2026-05-19 往回看描述迭代闭环确实有效虽然 2026-05-19 报告本身未包含 delta 章节但对比上一份 2026-05-15-v2.md 可以看清这套基准的演进价值基线2026-05-15566/600 完成runner 中途死亡v2 硬化 runner 后 600/600concurrency4 把墙钟从 ~60 分钟降到 ~15 分钟。定向描述重写带来最大单技能提升context-fundamentalstop-1 从 0.255 → 0.48923.4ppproject-development从 0.750 → 1.00025pp满分。本轮05-19在此基础上验证了语料库级加固没有引入广泛回归三模型 ≥0.913新加固的五技能全满分剩余失败集中在两个已知负向控制/模糊 prompt 与context-fundamentals兜底边界上。结论与仓库 READMEresearcher/benchmarks/router/README.md的建议一致当基准暴露路由失败时正确动作是修改失败技能的激活描述、重跑、再用 delta 对比证明改善——2026-05-19 证明这个闭环在语料库大规模改动后依然稳健。十、读这份报告的正确姿势四个问题按顺序回答PLAN.md 的 How To Read Results 给出了一套四问框架任何一轮基准结果都应按顺序回答harness 是否通过确定性闸门Stage 0 1必须恒通过描述能否路由到正确技能Stage 2本报告回答的问题逐模型看 top-1/top-3技能是否真的有效Stage 3下一投资方向——加载完整技能正文的有效性测试仓库已有一个样例任务 001-filesystem-context-offload技能能否组合Stage 4未来在任何更早阶段失败的技能不需要等到更晚阶段才被证明应该移除或返工——这正是把基准按阶段分层、把路由准确性放在有效性之前验证的设计意图。【免费下载链接】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），仅供参考