Agent-Skills-for-Context-Engineering 路由基准测试解析用 LLM-as-Router 验证 15 个 Agent Skill 的描述质量【免费下载链接】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/benchmarks/router/results-published/2026-05-15.md。这份报告回答了一个对任何 Agent 系统都至关重要的问题当 15 个技能Skill只有激活描述activation description这一个信号时前沿大模型能否把用户任务准确路由到正确的技能读完本文你将掌握该基准的完整方法论LLM-as-Router、确定性乱序、bootstrap 置信区间、四模型排行榜的解读方法、混淆矩阵定位边界技能的分析套路以及如何用仓库内的 runner 源码与脚本复现这份报告。图v2.3.0 发布资产中的 router 排行榜图对应 2026-05-19 那次全量扫描的模型 Top-1 结果可视化用于快速对比各模型的路由精度。一、这份报告回答什么问题路由阶段是技能体系的咽喉在 researcher/benchmarks/PLAN.md 的四阶段基准架构中这份报告属于Stage 2Skill Router Benchmarkv2.3.0 发布。它的核心假设是v2.2.0 起技能采用 frontmatter 中的激活场景描述activation-scenario description取代 v2.1.x 的关键字触发器后前沿模型应该能以高 Top-1 精度、极高 Top-3 精度把提示词路由到正确技能。为什么路由这么重要PLAN.md 里有一句关键判断技能描述是部署后的 Agent 决定是否加载某个技能的唯一信号。如果路由不正确其余所有基础设施都是空谈。也就是说无论技能本体写得多好只要描述写得模棱两可Agent 就不会在正确的时机加载它——路由精度是技能体系有效性链条上的第一道闸门。报告在方法论上做了一个严格的控制settingSources: []不加载任何技能文件让提示词中的描述成为唯一路由信号。这保证了测的是描述质量而不是技能正文对模型的引导。二、运行元数据一次可完全复现的受控实验报告头部完整记录了本次扫描的运行环境这也是整个仓库所有基准报告的统一溯源头元数据项值run timestamp2026-05-15T06:46:0600:00repo commitb1ca0719d225acb12e28354602209ac804ac7f56fixture sha256-168f974d930836bc9cseed1runs566 of 600 planned94.3%modelsclaude-opus-4-7, composer-2, gemini-3.1-pro, gpt-5.5reps per (prompt, model)3需要特别说明的是本次基线扫描并未跑满计划中的 600 次调用进程在第 566 次运行后退出报告注明原因未知推测为 SDK 超时或本地限流。尽管没有跑满每个模型的覆盖量依然均衡地保持在约 141 次远超统计显著性所需的最低样本量因此报告结论不受影响。这也是后续版本2026-05-15-v2、2026-05-19专门加固 runner增加断点续跑 resume 与并发控制的直接动因。测试夹具fixture是 researcher/benchmarks/router/prompts.jsonl当前版本包含 56 条人工标注的真值提示词每条记录包含prompt_id、prompt、expected_primary_skill、可选的acceptable_secondary_skills与rejected_skills、以及reason。夹具设计覆盖了五类场景见 researcher/benchmarks/router/README.md单技能正向控制每个技能 1 条共 15 条来自 v2.2.0 边界混淆清单的对抗性边界对5 组边界 × 3 个变体多个技能都可接受的组合提示词任何技能都不该匹配的负向控制如 p045计算三角形面积应能正确解析的隐蔽激活案例。三、执行摘要四个关键结论报告的执行摘要给出了四条真正有意义的发现这也是整个 Stage 2 最值得吸收的分析方法1. 四个前沿模型在 Top-1 精度上差距不超过 0.3 个百分点。Composer-2 0.888、GPT-5.5 0.886、Claude Opus 4.7 0.886、Gemini 3.1 Pro 0.886Top-3 精度从 0.921Gemini到 0.943GPT-5.5。四者的 95% bootstrap 置信区间完全重叠。结论在路由阶段模型选择不是决定因素。换句话说路由瓶颈不在谁在路由而在被路由的描述本身。2. 路由失败几乎全部集中在一个技能context-fundamentals。它 47 次中只被正确预测 12 次其余被分到context-degradation12、project-development12、context-optimization8、evaluation2、tool-design1。这个激活描述过于宽泛、与相邻技能重叠是改写优先级最高的描述。3.tool-design与project-development是真实的边界问题。48 个tool-design案例中有 12 个被路由到project-development反向也有 12/48。对称、温和但持续存在。4.evaluation与advanced-evaluation的边界问题基本解决。36 个evaluation案例中只有 3 个泄漏到advanced-evaluation49 个advanced-evaluation案例中只有 1 个反向泄漏——v2.2.0 对该边界做的加固refactor是有效的。5. 负向控制行为符合设计。像 p045计算三角形面积这类提示词只以 25% 的概率路由到预期兜底技能并在多个技能间分散没有模型错误地锁定某个不相关的领域技能。这是正确行为当没有技能强匹配时就不该有技能占主导。6. 格式合规率几乎完美。566 次调用中仅 1 次格式失败0.18%严格 JSON 路由提示词在四个模型上都稳定可用。7. 延迟差异约 3 倍。每次调用中位数毫秒数Claude 3392、GPT-5.5 3764、Composer-2 3957、Gemini 3.1 Pro 9077。Gemini 是最慢路径其余三者做路由吞吐可互换。报告给出的最明确下一步行动是重写context-fundamentals的激活描述让它对基础性提示词成为无争议的赢家、不再向相邻领域渗透预期对全模型的 Top-1 提升约 5-7 个百分点。四、方法论确定性乱序 严格 JSON bootstrap 置信区间报告的方法论设计是保证结论可信的基石逐条拆解如下提示构造每条提示词会与 15 个技能的激活描述一起呈现给每个模型技能顺序采用确定性乱序同一提示-模型对的每次复现使用不同 shuffle但给定 seed 后结果可复现。乱序是为了消除位置偏差——PLAN.md 的 Bias Mitigation 一节明确要求在 router 基准中打乱技能顺序、跨复现报告一致性。输出契约模型必须返回一个 JSON 对象包含ranking按相关性降序的技能名数组至少一个、confidence0.0-1.0、rationale一句话说明。完整模板见 researcher/benchmarks/router/routing-prompt.md其中使用{{SKILL_BLOCK}}、{{USER_PROMPT}}、{{SKILL_COUNT}}三个占位符由 runner 填充。打分口径Top-1 精度 排名第一的技能是否等于人工标注的expected_primary_skillTop-3 精度 期望技能是否出现在前三位。控制变量settingSources: []不加载任何技能进 Agent唯一信号就是提示词中的描述。统计口径置信区间为 95% bootstrap2000 次重采样。这五个要素共同保证了这份报告可复现、可对拍、可横向比较是后续每份路由报告包括 2026-05-15-v2 与 2026-05-19都沿用的标准方法论。五、分模型排行榜模型之间没有统计显著差异ModelTop-195% CITop-395% CIFormat FailuresMedian mscomposer-20.888[0.832, 0.937]0.930[0.888, 0.972]03957claude-opus-4-70.886[0.830, 0.936]0.936[0.894, 0.972]03392gpt-5.50.886[0.830, 0.936]0.943[0.901, 0.979]03764gemini-3.1-pro0.886[0.829, 0.936]0.921[0.879, 0.964]19077阅读这张表的关键点是看置信区间而非点估计四个模型的 Top-1 置信区间完全重叠因此任何某模型比另一模型更会路由的断言都不被数据支持。唯一显著的跨模型差异来自格式合规Gemini 是唯一出现格式失败的模型和延迟Gemini 中位 9077ms约为其他三者的 2.5-3 倍该规律在 v2 报告中同样出现。六、分技能混淆矩阵定位谁在抢谁的活儿混淆矩阵的行是人工标注的真值expected_primary_skill列是模型实际预测的技能只统计finished状态运行。它回答当期望是 X 时模型到底预测成了谁。Expected \ Predictedadvanced-evaluationbdi-mental-statescontext-compressioncontext-degradationcontext-fundamentalscontext-optimizationevaluationfilesystem-contextharness-engineeringhosted-agentslatent-briefingmemory-systemsmulti-agent-patternsproject-developmenttool-designadvanced-evaluation(n49)48-----1--------bdi-mental-states(n24)-24-------------context-compression(n36)--36------------context-degradation(n36)---36-----------context-fundamentals(n47)---121282------121context-optimization(n36)-----36---------evaluation(n36)3-----33--------filesystem-context(n36)-------36-------harness-engineering(n36)--------36------hosted-agents(n24)---------24-----latent-briefing(n24)----------24----memory-systems(n36)-----------36---multi-agent-patterns(n48)------------48--project-development(n48)-------------3612tool-design(n48)--------1----1235从这张矩阵能提炼出清晰的技能健康度分层零混淆的完美技能bdi-mental-states、context-compression、context-degradation、context-optimization、filesystem-context、harness-engineering、hosted-agents、latent-briefing、memory-systems、multi-agent-patterns全部 100% 正确——它们的描述与使用场景边界足够清晰。轻微泄漏evaluation3/36 泄漏到advanced-evaluationadvanced-evaluation1/49 反向泄漏。这个 v2.2.0 加固过的边界基本被验证成功。对称边界问题tool-design↔project-development双向各 12 次混淆说明两者描述在使用场景上确有重叠区。核心病灶context-fundamentals47 次仅 12 次正确25.5%同时向context-degradation、project-development、context-optimization三个方向大规模流失。它作为兜底技能的描述过于宽泛是最优先重写对象。七、最难提示词从单条失败反推描述缺陷PromptExpectedTop-1 RatePredicted Primariesp001context-fundamentals0.00context-degradationp037project-development0.00tool-designp046tool-design0.00project-developmentp048advanced-evaluation0.00evaluationp040context-fundamentals0.25context-fundamentals,context-optimizationp045context-fundamentals0.25context-fundamentals,evaluation,project-development,tool-designp047context-fundamentals0.50context-fundamentals,project-developmentp016evaluation0.75advanced-evaluation,evaluationp041tool-design0.92harness-engineering,tool-designp002context-degradation1.00context-degradation结合 prompts.jsonl 中的原文能还原每一条失败的具体成因p001解释上下文窗口为何随填充而退化、注意力机制为何让中段信息更难恢复期望context-fundamentals全部模型都给了context-degradation。p001 的acceptable_secondary_skills明确包含context-degradation说明这是一条真值标注本身就有争议的提示词——它既像基础解释又像退化诊断暴露的是context-fundamentals与context-degradation描述重叠。p037结构化输出设计为何改善下游解析期望project-development全部给了tool-design。p037 的acceptable_secondary_skills含tool-design同样是边界重叠案例。p046用一致缩进和去尾随空白重排 Python 文件负向控制期望tool-design被路由到project-development。这是一个没有技能真正匹配的泛化格式化任务其失败是预期内的负向行为而非描述缺陷。p048规划如何评估 latent-briefing 式 KV 压缩是否保持任务精度含消融与基线期望advanced-evaluation全部给了evaluation。p048 的acceptable_secondary_skills同时包含latent-briefing、evaluation、harness-engineering是一个刻意设计的多义提示词。p045给定底 12 高 7 计算三角形面积负向控制期望兜底技能context-fundamentals实际在 4 个技能间分散——这正是负向控制想要的行为。值得强调的是报告中Top-1 为 0.00 的四条提示词除 p037 外全部是真值标注含可接受次选的边界/负向案例。这说明失败并不总意味着描述质量差也可能是期望答案本身在多个合理选项之间。这也解释了为何 v2 报告2026-05-15-v2.md中 p046、p048 依然保持 0.00 而被建议重新标注。八、源码级解读runner 如何完成一次扫描报告呈现的是结果而结果的产生逻辑完整落在 runner 源码中理解它才能真正读懂报告。8.1 运行计划提示词 × 模型 × 复现 × 确定性乱序src/runRouter.ts 的main()首先加载夹具与技能描述然后调用buildRunPlan()定义于 src/common.ts生成完整运行计划对每个 prompt × model × rep 组合生成一个计划项并计算shuffleSeed hash32(promptId|modelId|rep|baseSeed)。技能顺序的乱序使用mulberry32 种子化 PRNG 的 Fisher-Yates shuffleshuffleSeeded保证不同复现不同乱序、同一复现可重现。8.2 提示渲染与严格解析renderPrompt()把模板中的三个占位符替换为实际内容技能块按乱序后的顺序编号列出1. 技能名\n 描述用户提示词填入{{USER_PROMPT}}技能数量填入{{SKILL_COUNT}}。随后调用Agent.prompt()时显式传入settingSources: []——这正是报告唯一信号是描述承诺的实现位置。模型返回后由parseRouterJson()用正则/\{[\s\S]*\}/提取 JSON 并解析ranking数组解析失败记为format_failure最多重试一次MAX_FORMAT_ATTEMPTS 2。8.3 成本闸门与断点续跑common.ts 中resolveConfig()有一个硬性安全设计不提供成本上限就拒绝运行Refusing to run without a cost cap。支持的 CLI 参数包括--dry-run、--models、--reps、--max-runs、--max-budget-usd、--seed、--fixture、--concurrency、--no-resume。每条运行记录以{promptId}-{modelId}-{rep}.json命名写入results/date-seed/目录下次扫描通过loadExistingResults()扫描已有文件实现断点续跑——这正是 v1 进程死在 566/600 后能补齐到 600/600 的机制。8.4 报告渲染器researcher/scripts/render_router_report.py 读取上述 JSON 记录产出报告中的全部表格bootstrap_ci()实现 2000 次重采样的 95% 置信区间build_confusion()按期望 × 预测构建混淆矩阵hardest_prompts()按 Top-1 率升序取前 10delta_section()在传入--baseline时追加相对基线变化章节v2 报告中的 Delta 表就由它生成。报告不是手写的而是从原始运行记录确定性生成的——这保证了每一份发布报告的每个数字都可追溯到逐条 JSON 记录。九、复现这份报告报告自带完整的复现命令这也是仓库所有基准报告的统一约定见 researcher/benchmarks/router/results-published/README.mdcd 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需要注意的复现前提API Keyrunner 只在设置了CURSOR_API_KEY时才真正执行未设置时可用--dry-run查看计划与成本预估而不产生任何调用。成本闸门必须提供--max-runs或--max-budget-usd或显式--unsafe-no-cost-cap这是 common.ts 的强制约束runRouter.ts 中单次调用成本按约 4000 in / 400 out tokens、0.012 USD 估算。模型清单--models以逗号分隔传入若运行时不指定则默认只有composer-2。原始产物每次运行的逐条 JSONprompt、model、replication、raw model output、parsed ranking保存在 gitignored 的results/目录中summary.json与报告同步生成同时向researcher/reports/router-history.jsonlgitignored追加一条历史记录用于纵向对比。十、这份报告的后续描述重写的度量闭环将这份基线报告放在整个仓库的迭代时间线里才能看到它的真正价值——它是**度量-改写-再度量闭环的起点**基线本文报告的 2026-05-15.md暴露context-fundamentals25.5% 与project-development75%、tool-design72.9% 的 Top-1 短板。修复2026-05-15-v2.md针对性地重写描述并加固 runner并发4、断点续跑后context-fundamentals提升到 48.9%23.4pp、project-development达到 100%25pp完美路由、tool-design到 80.7%7.8pp四模型中有三者在 Top-1 上提升四者 Top-3 全部提升。报告中还包含完整的Delta vs baseline章节逐模型、逐技能、逐提示词给出变化量。语料级加固验证2026-05-19.md全 15 个技能正文、机制映射、声明溯源、语料索引与激活夹具全面更新后600/600 全部可用、0 格式失败三模型 Top-1 ≥ 0.913剩余失败集中在已知的少数歧义边界p046 负向控制、p048 多义提示词、context-fundamentals兜底边界。由此形成的工程方法论是当某个技能在路由基准上失败就改写该技能的激活描述重跑扫描并与上一份报告对拍看 delta——这正是 results-published/README.md 明确建议的跟进动作。结语2026-05-15.md这份路由基准报告的价值远超一张排行榜它以可复现的严格方法论证明在 Agent-Skills-for-Context-Engineering 的 15 技能体系中路由阶段的精度瓶颈几乎全部集中在技能描述本身而非模型选择。报告给出的混淆矩阵定位边界问题 → 单条提示词反推描述缺陷 → 重写描述 → 重跑对拍的完整分析链路对任何维护技能库、工具库或多 Agent 路由系统的团队都有直接借鉴意义。如果你正在构建自己的 Agent 技能体系这份报告及其配套源码runRouter.ts、common.ts、routing-prompt.md、prompts.jsonl、render_router_report.py就是一套开箱即用的路由质量验证工作台。【免费下载链接】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），仅供参考 
长河君 · 2026/9/14 0:17:10 · 阅读 1.2k Agent-Skills-for-Context-Engineering 路由基准测试解析：用 LLM-as-Router 验证 15 个 Agent Skill 的描述质量
Agent-Skills-for-Context-Engineering 路由基准测试解析用 LLM-as-Router 验证 15 个 Agent Skill 的描述质量【免费下载链接】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/benchmarks/router/results-published/2026-05-15.md。这份报告回答了一个对任何 Agent 系统都至关重要的问题当 15 个技能Skill只有激活描述activation description这一个信号时前沿大模型能否把用户任务准确路由到正确的技能读完本文你将掌握该基准的完整方法论LLM-as-Router、确定性乱序、bootstrap 置信区间、四模型排行榜的解读方法、混淆矩阵定位边界技能的分析套路以及如何用仓库内的 runner 源码与脚本复现这份报告。图v2.3.0 发布资产中的 router 排行榜图对应 2026-05-19 那次全量扫描的模型 Top-1 结果可视化用于快速对比各模型的路由精度。一、这份报告回答什么问题路由阶段是技能体系的咽喉在 researcher/benchmarks/PLAN.md 的四阶段基准架构中这份报告属于Stage 2Skill Router Benchmarkv2.3.0 发布。它的核心假设是v2.2.0 起技能采用 frontmatter 中的激活场景描述activation-scenario description取代 v2.1.x 的关键字触发器后前沿模型应该能以高 Top-1 精度、极高 Top-3 精度把提示词路由到正确技能。为什么路由这么重要PLAN.md 里有一句关键判断技能描述是部署后的 Agent 决定是否加载某个技能的唯一信号。如果路由不正确其余所有基础设施都是空谈。也就是说无论技能本体写得多好只要描述写得模棱两可Agent 就不会在正确的时机加载它——路由精度是技能体系有效性链条上的第一道闸门。报告在方法论上做了一个严格的控制settingSources: []不加载任何技能文件让提示词中的描述成为唯一路由信号。这保证了测的是描述质量而不是技能正文对模型的引导。二、运行元数据一次可完全复现的受控实验报告头部完整记录了本次扫描的运行环境这也是整个仓库所有基准报告的统一溯源头元数据项值run timestamp2026-05-15T06:46:0600:00repo commitb1ca0719d225acb12e28354602209ac804ac7f56fixture sha256-168f974d930836bc9cseed1runs566 of 600 planned94.3%modelsclaude-opus-4-7, composer-2, gemini-3.1-pro, gpt-5.5reps per (prompt, model)3需要特别说明的是本次基线扫描并未跑满计划中的 600 次调用进程在第 566 次运行后退出报告注明原因未知推测为 SDK 超时或本地限流。尽管没有跑满每个模型的覆盖量依然均衡地保持在约 141 次远超统计显著性所需的最低样本量因此报告结论不受影响。这也是后续版本2026-05-15-v2、2026-05-19专门加固 runner增加断点续跑 resume 与并发控制的直接动因。测试夹具fixture是 researcher/benchmarks/router/prompts.jsonl当前版本包含 56 条人工标注的真值提示词每条记录包含prompt_id、prompt、expected_primary_skill、可选的acceptable_secondary_skills与rejected_skills、以及reason。夹具设计覆盖了五类场景见 researcher/benchmarks/router/README.md单技能正向控制每个技能 1 条共 15 条来自 v2.2.0 边界混淆清单的对抗性边界对5 组边界 × 3 个变体多个技能都可接受的组合提示词任何技能都不该匹配的负向控制如 p045计算三角形面积应能正确解析的隐蔽激活案例。三、执行摘要四个关键结论报告的执行摘要给出了四条真正有意义的发现这也是整个 Stage 2 最值得吸收的分析方法1. 四个前沿模型在 Top-1 精度上差距不超过 0.3 个百分点。Composer-2 0.888、GPT-5.5 0.886、Claude Opus 4.7 0.886、Gemini 3.1 Pro 0.886Top-3 精度从 0.921Gemini到 0.943GPT-5.5。四者的 95% bootstrap 置信区间完全重叠。结论在路由阶段模型选择不是决定因素。换句话说路由瓶颈不在谁在路由而在被路由的描述本身。2. 路由失败几乎全部集中在一个技能context-fundamentals。它 47 次中只被正确预测 12 次其余被分到context-degradation12、project-development12、context-optimization8、evaluation2、tool-design1。这个激活描述过于宽泛、与相邻技能重叠是改写优先级最高的描述。3.tool-design与project-development是真实的边界问题。48 个tool-design案例中有 12 个被路由到project-development反向也有 12/48。对称、温和但持续存在。4.evaluation与advanced-evaluation的边界问题基本解决。36 个evaluation案例中只有 3 个泄漏到advanced-evaluation49 个advanced-evaluation案例中只有 1 个反向泄漏——v2.2.0 对该边界做的加固refactor是有效的。5. 负向控制行为符合设计。像 p045计算三角形面积这类提示词只以 25% 的概率路由到预期兜底技能并在多个技能间分散没有模型错误地锁定某个不相关的领域技能。这是正确行为当没有技能强匹配时就不该有技能占主导。6. 格式合规率几乎完美。566 次调用中仅 1 次格式失败0.18%严格 JSON 路由提示词在四个模型上都稳定可用。7. 延迟差异约 3 倍。每次调用中位数毫秒数Claude 3392、GPT-5.5 3764、Composer-2 3957、Gemini 3.1 Pro 9077。Gemini 是最慢路径其余三者做路由吞吐可互换。报告给出的最明确下一步行动是重写context-fundamentals的激活描述让它对基础性提示词成为无争议的赢家、不再向相邻领域渗透预期对全模型的 Top-1 提升约 5-7 个百分点。四、方法论确定性乱序 严格 JSON bootstrap 置信区间报告的方法论设计是保证结论可信的基石逐条拆解如下提示构造每条提示词会与 15 个技能的激活描述一起呈现给每个模型技能顺序采用确定性乱序同一提示-模型对的每次复现使用不同 shuffle但给定 seed 后结果可复现。乱序是为了消除位置偏差——PLAN.md 的 Bias Mitigation 一节明确要求在 router 基准中打乱技能顺序、跨复现报告一致性。输出契约模型必须返回一个 JSON 对象包含ranking按相关性降序的技能名数组至少一个、confidence0.0-1.0、rationale一句话说明。完整模板见 researcher/benchmarks/router/routing-prompt.md其中使用{{SKILL_BLOCK}}、{{USER_PROMPT}}、{{SKILL_COUNT}}三个占位符由 runner 填充。打分口径Top-1 精度 排名第一的技能是否等于人工标注的expected_primary_skillTop-3 精度 期望技能是否出现在前三位。控制变量settingSources: []不加载任何技能进 Agent唯一信号就是提示词中的描述。统计口径置信区间为 95% bootstrap2000 次重采样。这五个要素共同保证了这份报告可复现、可对拍、可横向比较是后续每份路由报告包括 2026-05-15-v2 与 2026-05-19都沿用的标准方法论。五、分模型排行榜模型之间没有统计显著差异ModelTop-195% CITop-395% CIFormat FailuresMedian mscomposer-20.888[0.832, 0.937]0.930[0.888, 0.972]03957claude-opus-4-70.886[0.830, 0.936]0.936[0.894, 0.972]03392gpt-5.50.886[0.830, 0.936]0.943[0.901, 0.979]03764gemini-3.1-pro0.886[0.829, 0.936]0.921[0.879, 0.964]19077阅读这张表的关键点是看置信区间而非点估计四个模型的 Top-1 置信区间完全重叠因此任何某模型比另一模型更会路由的断言都不被数据支持。唯一显著的跨模型差异来自格式合规Gemini 是唯一出现格式失败的模型和延迟Gemini 中位 9077ms约为其他三者的 2.5-3 倍该规律在 v2 报告中同样出现。六、分技能混淆矩阵定位谁在抢谁的活儿混淆矩阵的行是人工标注的真值expected_primary_skill列是模型实际预测的技能只统计finished状态运行。它回答当期望是 X 时模型到底预测成了谁。Expected \ Predictedadvanced-evaluationbdi-mental-statescontext-compressioncontext-degradationcontext-fundamentalscontext-optimizationevaluationfilesystem-contextharness-engineeringhosted-agentslatent-briefingmemory-systemsmulti-agent-patternsproject-developmenttool-designadvanced-evaluation(n49)48-----1--------bdi-mental-states(n24)-24-------------context-compression(n36)--36------------context-degradation(n36)---36-----------context-fundamentals(n47)---121282------121context-optimization(n36)-----36---------evaluation(n36)3-----33--------filesystem-context(n36)-------36-------harness-engineering(n36)--------36------hosted-agents(n24)---------24-----latent-briefing(n24)----------24----memory-systems(n36)-----------36---multi-agent-patterns(n48)------------48--project-development(n48)-------------3612tool-design(n48)--------1----1235从这张矩阵能提炼出清晰的技能健康度分层零混淆的完美技能bdi-mental-states、context-compression、context-degradation、context-optimization、filesystem-context、harness-engineering、hosted-agents、latent-briefing、memory-systems、multi-agent-patterns全部 100% 正确——它们的描述与使用场景边界足够清晰。轻微泄漏evaluation3/36 泄漏到advanced-evaluationadvanced-evaluation1/49 反向泄漏。这个 v2.2.0 加固过的边界基本被验证成功。对称边界问题tool-design↔project-development双向各 12 次混淆说明两者描述在使用场景上确有重叠区。核心病灶context-fundamentals47 次仅 12 次正确25.5%同时向context-degradation、project-development、context-optimization三个方向大规模流失。它作为兜底技能的描述过于宽泛是最优先重写对象。七、最难提示词从单条失败反推描述缺陷PromptExpectedTop-1 RatePredicted Primariesp001context-fundamentals0.00context-degradationp037project-development0.00tool-designp046tool-design0.00project-developmentp048advanced-evaluation0.00evaluationp040context-fundamentals0.25context-fundamentals,context-optimizationp045context-fundamentals0.25context-fundamentals,evaluation,project-development,tool-designp047context-fundamentals0.50context-fundamentals,project-developmentp016evaluation0.75advanced-evaluation,evaluationp041tool-design0.92harness-engineering,tool-designp002context-degradation1.00context-degradation结合 prompts.jsonl 中的原文能还原每一条失败的具体成因p001解释上下文窗口为何随填充而退化、注意力机制为何让中段信息更难恢复期望context-fundamentals全部模型都给了context-degradation。p001 的acceptable_secondary_skills明确包含context-degradation说明这是一条真值标注本身就有争议的提示词——它既像基础解释又像退化诊断暴露的是context-fundamentals与context-degradation描述重叠。p037结构化输出设计为何改善下游解析期望project-development全部给了tool-design。p037 的acceptable_secondary_skills含tool-design同样是边界重叠案例。p046用一致缩进和去尾随空白重排 Python 文件负向控制期望tool-design被路由到project-development。这是一个没有技能真正匹配的泛化格式化任务其失败是预期内的负向行为而非描述缺陷。p048规划如何评估 latent-briefing 式 KV 压缩是否保持任务精度含消融与基线期望advanced-evaluation全部给了evaluation。p048 的acceptable_secondary_skills同时包含latent-briefing、evaluation、harness-engineering是一个刻意设计的多义提示词。p045给定底 12 高 7 计算三角形面积负向控制期望兜底技能context-fundamentals实际在 4 个技能间分散——这正是负向控制想要的行为。值得强调的是报告中Top-1 为 0.00 的四条提示词除 p037 外全部是真值标注含可接受次选的边界/负向案例。这说明失败并不总意味着描述质量差也可能是期望答案本身在多个合理选项之间。这也解释了为何 v2 报告2026-05-15-v2.md中 p046、p048 依然保持 0.00 而被建议重新标注。八、源码级解读runner 如何完成一次扫描报告呈现的是结果而结果的产生逻辑完整落在 runner 源码中理解它才能真正读懂报告。8.1 运行计划提示词 × 模型 × 复现 × 确定性乱序src/runRouter.ts 的main()首先加载夹具与技能描述然后调用buildRunPlan()定义于 src/common.ts生成完整运行计划对每个 prompt × model × rep 组合生成一个计划项并计算shuffleSeed hash32(promptId|modelId|rep|baseSeed)。技能顺序的乱序使用mulberry32 种子化 PRNG 的 Fisher-Yates shuffleshuffleSeeded保证不同复现不同乱序、同一复现可重现。8.2 提示渲染与严格解析renderPrompt()把模板中的三个占位符替换为实际内容技能块按乱序后的顺序编号列出1. 技能名\n 描述用户提示词填入{{USER_PROMPT}}技能数量填入{{SKILL_COUNT}}。随后调用Agent.prompt()时显式传入settingSources: []——这正是报告唯一信号是描述承诺的实现位置。模型返回后由parseRouterJson()用正则/\{[\s\S]*\}/提取 JSON 并解析ranking数组解析失败记为format_failure最多重试一次MAX_FORMAT_ATTEMPTS 2。8.3 成本闸门与断点续跑common.ts 中resolveConfig()有一个硬性安全设计不提供成本上限就拒绝运行Refusing to run without a cost cap。支持的 CLI 参数包括--dry-run、--models、--reps、--max-runs、--max-budget-usd、--seed、--fixture、--concurrency、--no-resume。每条运行记录以{promptId}-{modelId}-{rep}.json命名写入results/date-seed/目录下次扫描通过loadExistingResults()扫描已有文件实现断点续跑——这正是 v1 进程死在 566/600 后能补齐到 600/600 的机制。8.4 报告渲染器researcher/scripts/render_router_report.py 读取上述 JSON 记录产出报告中的全部表格bootstrap_ci()实现 2000 次重采样的 95% 置信区间build_confusion()按期望 × 预测构建混淆矩阵hardest_prompts()按 Top-1 率升序取前 10delta_section()在传入--baseline时追加相对基线变化章节v2 报告中的 Delta 表就由它生成。报告不是手写的而是从原始运行记录确定性生成的——这保证了每一份发布报告的每个数字都可追溯到逐条 JSON 记录。九、复现这份报告报告自带完整的复现命令这也是仓库所有基准报告的统一约定见 researcher/benchmarks/router/results-published/README.mdcd 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需要注意的复现前提API Keyrunner 只在设置了CURSOR_API_KEY时才真正执行未设置时可用--dry-run查看计划与成本预估而不产生任何调用。成本闸门必须提供--max-runs或--max-budget-usd或显式--unsafe-no-cost-cap这是 common.ts 的强制约束runRouter.ts 中单次调用成本按约 4000 in / 400 out tokens、0.012 USD 估算。模型清单--models以逗号分隔传入若运行时不指定则默认只有composer-2。原始产物每次运行的逐条 JSONprompt、model、replication、raw model output、parsed ranking保存在 gitignored 的results/目录中summary.json与报告同步生成同时向researcher/reports/router-history.jsonlgitignored追加一条历史记录用于纵向对比。十、这份报告的后续描述重写的度量闭环将这份基线报告放在整个仓库的迭代时间线里才能看到它的真正价值——它是**度量-改写-再度量闭环的起点**基线本文报告的 2026-05-15.md暴露context-fundamentals25.5% 与project-development75%、tool-design72.9% 的 Top-1 短板。修复2026-05-15-v2.md针对性地重写描述并加固 runner并发4、断点续跑后context-fundamentals提升到 48.9%23.4pp、project-development达到 100%25pp完美路由、tool-design到 80.7%7.8pp四模型中有三者在 Top-1 上提升四者 Top-3 全部提升。报告中还包含完整的Delta vs baseline章节逐模型、逐技能、逐提示词给出变化量。语料级加固验证2026-05-19.md全 15 个技能正文、机制映射、声明溯源、语料索引与激活夹具全面更新后600/600 全部可用、0 格式失败三模型 Top-1 ≥ 0.913剩余失败集中在已知的少数歧义边界p046 负向控制、p048 多义提示词、context-fundamentals兜底边界。由此形成的工程方法论是当某个技能在路由基准上失败就改写该技能的激活描述重跑扫描并与上一份报告对拍看 delta——这正是 results-published/README.md 明确建议的跟进动作。结语2026-05-15.md这份路由基准报告的价值远超一张排行榜它以可复现的严格方法论证明在 Agent-Skills-for-Context-Engineering 的 15 技能体系中路由阶段的精度瓶颈几乎全部集中在技能描述本身而非模型选择。报告给出的混淆矩阵定位边界问题 → 单条提示词反推描述缺陷 → 重写描述 → 重跑对拍的完整分析链路对任何维护技能库、工具库或多 Agent 路由系统的团队都有直接借鉴意义。如果你正在构建自己的 Agent 技能体系这份报告及其配套源码runRouter.ts、common.ts、routing-prompt.md、prompts.jsonl、render_router_report.py就是一套开箱即用的路由质量验证工作台。【免费下载链接】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），仅供参考