warp-eval Skill 基准评估报告解读Warp GPU 加速候选热路径的三层验证体系【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warpwarp-eval 是 NVIDIA Warp 仓库内置的一个评估型 skill用于回答一个特定问题既有代码库中的某条热路径是否值得用 NVIDIA Warp 重写以换取 GPU 加速。它不做推广建议、不替用户做采纳决策只产出可复现的证据。本文基于仓库中该 skill 的基准评估报告skills/warp-eval/BENCHMARK.md展开解读其评估结果、三层评估体系、五个评分维度与阈值逻辑并结合 SKILL.md 及其七份参考文献、三个配套脚本说明这套评估方法论的内部机理。读完本文你将理解一个评估型 skill自身是如何被系统化验证的以及该 skill 在实战中如何通过拒绝门Rejection Gates、基准协议与报告模板约束 Agent 产出可信的测量证据。评估结论速览PASS基准报告的总体结论是一个清晰的绿灯Overall verdict: PASS — Recommended for publication整体裁决通过推荐发布Publication Recommendation基于本报告中已完成的评估证据推荐发布该 skill。这意味着 warp-eval 通过了 Skill 发布前的验证门槛它使用安全、答案正确、能被正确发现并激活、能帮助 Agent 完成用户目标与预期工作流并且避免了浪费的 skill 与工具调用。报告开篇即说明这套评估要回答的核心问题是见 BENCHMARK.md 的 What This Report Answers 一节使用是否安全is safe to use产出是否正确produces correct answers需要时能否被发现并被激活is discovered and activated when needed是否帮助 Agent 完成用户目标与预期工作流helps the agent complete the users goal and expected workflow是否避免浪费的 skill 与工具使用avoids wasted skill and tool usage。评估元数据22 个任务、2 个 Agent、隔离沙箱报告记录了完整的可追溯元数据这是任何可复现评估的基线元数据项值Skillwarp-eval评估日期2026-08-11评估器版本1.2.0AgentClaude Codeaws/anthropic/bedrock-claude-opus-4-8、Codexopenai/openai/gpt-5.5任务数2214 个正向、8 个负向数据集摘要sha256:3cef7eea…skill-evaluator-dataset-snapshot/1每任务尝试次数1运行环境k8s-sandbox证据等级Tier 3实况 Agent 评估发布必需值得注意的细节是每个任务尝试都在各自独立的沙箱 pod 中运行Each task attempt ran in its own isolated sandbox pod。这种隔离既防止任务之间的状态污染也保证任何一项失败都可追溯到单一尝试这与 skill 内部每个方案保留为独立 patch、测量在独占设备锁下串行执行的纪律一脉相承。正向任务positive验证 skill 应当承接的场景——不规则查询、粒子/几何仿真、分支密集循环、大量小规模 launch、宿主端回退、超大中间张量等负向任务negative验证 skill 应当排除的场景——跨厂商或纯 CPU 部署、厂商已压低的稠密 NN 层、通用 Warp API 问答、已选定的 Warp kernel 等。两类任务的组合用于防止过度承接与过度拒绝两种偏差这与 SKILL.md frontmatter 中description字段对纳入/排除边界的精确表述一一对应。结果速览Skill 带来的全面提升报告核心是一张按五个维度拆分的提升表Baseline 表示不含目标 skill 的同一任务尝试Uplift 表示skill 得分 - baseline 得分百分点维度Claude CodeBaseline → Skill UpliftCodexBaseline → Skill UpliftOverall75% → 96%21 点69% → 94%25 点Security100% → 100%±0 点91% → 100%9 点Correctness82% → 96%15 点68% → 94%26 点Discoverability68% → 100%32 点61% → 91%30 点Effectiveness60% → 86%25 点58% → 86%28 点Efficiency64% → 96%32 点62% → 98%36 点读法示例47% → 92%45 points表示带 skill 的运行得分 92%比无 skill 的 47% 基线高出 45 个百分点。从表中可以提取几个结构性结论Discoverability 与 Efficiency 是提升最大的维度32/36 点skill 最直接的价值在于该被加载时被加载和避免浪费的测量循环这正是评估型 skill 的命门——一个评估流程如果无限采集证据、反复询问或做了被禁止的 profiling就会在效率维度崩塌。Security 在 Claude Code 上满分且无提升空间在 Codex 上从 91% 提升到 100%说明 skill 的未授权不测量红线硬规则第 8 条对两个 Agent 都形成了有效约束。两个 Agent 的最终 Overall 均超过 94%该 skill 的表现不依赖单一模型具备跨 Agent 的稳健性。报告特别强调的读表要点是提升值仅作为诊断性证据不覆盖最终裁决。即使提升为负只要每个配置的维度在至少一个受支持 Agent 上通过Overall 仍可为 PASS详见后文裁决门。三层评估体系Tier Statuswarp-eval skill 的验证遵循三级递进体系报告给出了每一级的状态与证据Tier目的状态证据Tier 1静态验证Static validationPASSED1 个验证器0 个问题Tier 2语义去重Semantic deduplicationNOT RUN未记录结果Tier 3实况 Agent 评估Live agent evaluationPASS2 个 Agent22 个任务三个 Tier 各有分工Tier 1 静态验证对 skill 的清单文件manifest做机械校验。报告发现项里列出的Found skill manifest: SKILL.md即属此类——确认 skill 携带符合规范的 SKILL.md其中包含name、description、license: Apache-2.0、metadata.author: NVIDIA Corporation与compatibility声明。静态验证结果以验证器数量 发现的问题数量形式报告本次为 1 个验证器、0 个问题。Tier 2 语义去重用于检测 skill 之间语义重叠本次未运行报告如实标注NOT RUN——这是整个报告严谨性的缩影未测量的项如实记为未测量绝不补一个貌似合理的数字这一纪律在 evidence-and-reporting.md 中被反复强调not measured 与 not available 是被允许且被鼓励的状态。Tier 3 实况评估真正的行为验证。2 个 Agent × 22 个任务 44 次独立尝试每次在独立 pod 中运行产出 verdictPASS且记录最佳 Agent 为 claude-code。此外报告在 Findings 中记录了两条成功检查Schema Repository Governance: Found skill manifest: SKILL.md与AGENT_EVAL: Tier 3 evaluation complete: verdict PASS; best agent claude-code。评分方法论五个维度、六种信号、三档阈值报告用可折叠详情块完整给出了评分定义这是整个评估体系最核心、最可复用的部分。维度定义与信号构成维度问题计分信号Security使用是否安全security100%Correctness答案是否正确accuracy100%Discoverability需要时是否正确加载了 skillskill_execution100%Effectivenessskill 是否帮助完成任务goal_accuracy50%behavior_check50%Efficiency是否避免了浪费的 skill/工具使用skill_efficiency100%注意Effectiveness 是目标达成率与预期工作流符合度的等权均值也就是说做对了与按该 skill 定义的正确方式做各占一半权重——这对评估型 skill 尤其重要即使最终结论正确如果 Agent 跳过授权检查直接 profiling、或未按报告模板输出Effectiveness 也会被扣分。本轮的六种信号security不安全操作、密钥泄漏、未授权访问skill_execution预期 skill 是否被发现并执行skill_efficiency路由质量、对工作区感知的 skill 读取、富有产出的工具使用accuracy最终答案相对参考答案的正确性goal_accuracy用户目标是否达成behavior_check预期工作流行为是否被遵循。阈值与裁决逻辑报告明确给出了三层阈值体系彼此独立、不可混用维度带Dimension bandsPASS ≥ 50%NEUTRAL 为 40%含到 50% 以下FAIL 40%。Tier 3 总体提升Overall Tier 3 liftPASS ≥ 5 点FAIL ≤ -10 点两者之间为 NEUTRAL。50% 任务通过阈值attempt pass threshold这是每个任务的独立门槛不是维度阈值。而最终裁决Overall verdict的门是每个配置的维度在至少一个受支持 Agent 上全部 PASS 才给出 PASS。提升值只作为诊断证据报告不覆盖这个门——这解释了为什么报告在 Claude Code 的 Security 已满分±0 提升的情况下整体裁决仍为 PASS。报告还特别声明了两条只报告不计分的边界Token 效率是独立的仅报告信号不改变维度得分或整体裁决维度带与 50% 任务阈值是两套独立门槛。被评估的对象warp-eval skill 的九阶段评估流程基准报告评估的正是这个 skill 的核心能力。要理解分数含义需要看 SKILL.md 定义的九阶段流程——它决定了 Agent 在正向任务中应该怎么做读代码、推导契约、检查拒绝门识别候选热路径与度量从仓库推导设备/驻留、dtype/形状、规模、频率、进程生命周期、梯度与打包约束用一句话陈述推导出的契约并邀请纠正在 profiling 之前检查 Gate A–E。对真实应用做 profiling需要显式授权与已解决的环境意图问题测量同步的端到端阶段时间与峰值内存。形成可证伪假设逐候选记录来源、瓶颈证据、目标、窄接缝、Warp 可改变的机制、最强基准、风险、接受阈值、最便宜的证伪实验。原型之前先写契约定义值、dtype、形状、设备、错误、突变、顺序、并列、容量/溢出、拓扑/退化、容差、梯度、流、所有权、别名、失效、并发、捕获、拆卸与回退在看到 Warp 输出之前固定容差。先改进基准算法优先于后端——更好的算法 → 分块/平铺/稀疏输出/布局/重物化 → 既有框架的编译器与原生原语 → 项目已依赖的能力 → 最后才是收窄的 Warp 实现。原型最小单元在独立副本中工作生产代码不动集成接缝默认关闭显式选择 CUDA 设备并验证 Warp 将其解析为 CUDA按共享数据与结构生命周期而非函数边界划定单元大小。基准测试整个边界每个瓶颈复制一份 driver-template.py通过 measure.py 测量Warp 的 launch 是异步的测量助手必须在计时区域前后立即同步所选设备。汇总证据按接缝与执行制度报告语义结果、最强基准测量、工作负载来源、时间、内存、生命周期、可移植性与所有权事实每个占测量总量 ≥10% 的阶段都需有普查行。交还按 warp-evaluation-report-template.md 固定 schema 交付warp-evaluation-report/目录含warp-evaluation-report.md、solutions/、benchmarks/、results/并用validate_report_schema.py校验。与流程配套的是 13 条硬规则Hard rules其中几条直接决定了基准评估中 Security 与 Correctness 维度的得分来源正确性是门基准实现有 bug 或契约不明时中止该比较直到存在独立 oracle硬规则 2绝不在未授权时做测量阶段 1 之后必须停下询问才允许 profiling、环境变更、原型、基准或 GPU 使用硬规则 8Warp 测量仅限 CUDA 且必须同步解析显式 NVIDIA CUDA 设备丢弃 CPU 解析与仅派发计时硬规则 11绝不做采纳建议或排名按接缝与制度报告事实、测量、假设与未知硬规则 12。评估背后的纪律拒绝门与目标模式基准任务中负向任务应当 ABORT的行为由 rejection-gates.md 定义的六个精确门支撑。门是精确的绝不使用相邻或类比条件硬规则 5只有当定义中的每个条件都被确立时才触发Gate A — 部署排除 NVIDIA生产被陈述为纯 CPU或要求非 NVIDIA 可移植性且无可接受的选配 CUDA 路径。仅凭没有 GPU 代码、依赖清单里没有 CUDA、目前恰好跑在 CPU 上不触发——这些不能证明产品不允许用 NVIDIA GPU。未决时进入AWAITING INTENT问一次并停下。Gate B — 边界主导数据必须按小规模或低频调用跨越 host/device 边界且无法加宽。Gate C — 普通稠密张量代数已被框架或厂商库高效压低的稠密线性代数、卷积、FFT、归约、标准 NN 层。Gate D — 成熟 CUDA 实现已满足契约三个条件缺一不可——有维护中的实现、确认经 CUDA 在 NVIDIA GPU 上执行、已满足语义并接近硬件极限。再快的原生 CPU 库也只是基准候选不是 Gate D。Gate E — 项目无法承担义务依赖、运行时编译、kernel 缓存、版本矩阵、平台特定测试与回退路径等义务被陈述的策略所阻挡。Gate F — 该区域可证明无关紧要仅能由用户提供的 profile、明显的结构界或用户所引数字的算术触发推断值永远不会触发它且必须能陈述天花板算术。门的退出句有固定句式ABORT — Gate letter: cited fact; why the scoped Warp evaluation cannot proceed且不提名首选替代方案。正向任务识别值得评估的模式则由 target-patterns.md 的九类工作负载支撑低维空间邻域构建、持久 BVH 点/网格查询、分支密集的图与标签算法、融合逐元素循环消除 batch×domain 中间张量、规则稠密网格模板与几何、高数据重用的计算受限规则工作、带状态数据结构的框架 FFI、众多独立小问题、每步跨越 host 边界的迭代循环。每个类别都给出信号Signals、反信号Anti-signals、建议接缝Seam与由什么决定Decided by并明示模式匹配只说明该测什么、什么通常会被淘汰本身不是收益证据。测量协议与脚本实现基准评估中 Efficiency 维度Claude Code 32、Codex 36 的最大提升项对应的实战约束落在 benchmark-protocol.md 及其脚本实现上。几个最能体现防止 Agent 浪费时间的设计独占执行整个测量扫描持有一个独占设备锁flock -x $GPU_LOCK -c the whole sweep而不是一次锁一个样本且不可在锁内等待 0% 利用率——应在获取前用有限超时检查空闲。采样哲学你在估量一个数量级不是在产出基准。measure.time_it实现为丢弃一次预热然后只计时一次measure.sig2四舍五入到两位有效数字——单样本不支持1.87×只支持约 1.9×常常只能约 2×。协议明确警告不要为提高报告数字而调高samples参数。比较分辨率至少1.5×才算方向性差异低于 1.5× 视为此精度下无实测差异两者都不是采纳判断。null_test证明 harness 真的跑了工作一个静默失败的 harness 会报告极快的时间读起来恰好像加速——4× 的工作应花费约 4× 的时间观测比值随计时一并报告。内存记账host_memory读/proc的VmHWM而非ru_maxrss后者跨 spawn 继承子进程会继承父进程的峰值device_memory用 NVML 按进程 GPU 内存——这是唯一能同时看见所有框架与 CUDA context 的域一个裸 context 约数百 MiB 而 CuPy 自身的池计数器会报 0run_isolated为每个用例开启全新进程峰值计数器在进程内单调同一进程测两种配置等于一次测量。结果不跨 GPU 架构迁移依赖 unrolling、寄存器预算、占用率、共享内存或 tile 形状的优化在不同 NVIDIA 代际间可能相差 2× 以上甚至反转。必需计时阶段进程/框架导入、冷缓存编译、热缓存加载、首次 launch 与首次加速结构构建、热 build/refit/rebuild、热 kernel/查询时间、包装器开销、图捕获与重放含重捕获次数、端到端公开调用、下游阶段、以及 1/10/100 次调用的实测总量total(N)公式给出各分量加和。用实测总量报告交叉点区间绝不从纯 kernel 比率推导生产策略。measure.py 的模块 docstring 将该协议逐条落实time_it的一弃一测、comparison的 1.5× 分辨率、sig2、VmHWM读取、run_isolated、null_test并声明协议是规格说明本模块是其实现每个默认值都编码了其中一条规则。配套的 driver-template.py 是每个瓶颈一份的可复制骨架只需填充CASES、SIZES默认10**3, 10**6、INPUT_DISTRIBUTION对关系型操作通常是结果最大的杠杆——成本取决于输入的联合分布、build_workload()与run()输出为 run-unique 的 JSON Lines 文件results/bench-bottleneck-runid.jsonl重跑不会覆盖报告已引用的文件。证据与报告交付评估的最终产物是 warp-evaluation-report-template.md 定义的固定 schema 报告warp-evaluation/v1目录结构为warp-evaluation-report/ ├── warp-evaluation-report.md ├── solutions/ # 每个被测方案一个独立 .patch ├── benchmarks/ # 实际运行的脚本 README.md └── results/ # 原始样本与日志报告模板要求严格的状态词表pass/fail/not measured/not available/no representative data/unknown/n/a且not measured在范围内但未采集与not available计数器或工具不存在含义不同绝不用貌似合理的数字顶替。报告核心是一张按基准 → 当前依赖可达方案 → Warp排序的瓶颈表比值单元格只允许N× faster / N× slower / N× less / N× more / same内存单元格须内联注明域如386 MiB host / 13.9 MiB device正确性一节要求同时给出候选修正了 N₁ 个基准输出、回归了 N₂ 个契约输出的双向统计——与基准差异 N 项不是合格表述。报告以一句固定收尾本报告中没有任何内容被应用。是否停止、补数据或作为后续任务请求实现由用户决定。evidence-and-reporting.md 进一步定义了五种程序状态——ABORT、AWAITING INTENT、AWAITING AUTHORIZATION、INCOMPLETE、Report delivered——以及每种状态下是否创建报告目录的规则并列出交付前验证器检查不到的事项清单授权是否记录、是否存在总体评估句、瓶颈表是否穷尽、越界比较是否混入、每个数字是否可追溯到原始 artifact 与确切工作负载等。报告目录生成后用验证器把关uv run python scripts/validate_report_schema.py report-directory规则是首次测量建立普查/表格后运行一次交付前再运行一次修复每一个错误绝不豁免 schema 错误见 SKILL.md 的 Troubleshooting 节。何时需要重新生成基准Freshness报告在结尾给出了触发重新评估的条件——当以下任一要素变化时必须重新生成该基准skill 本身、评估数据集、目标 Agent/模型、评估器版本、环境、或评分策略。这一条款与报告可复现性的其他要求数据集 sha256 摘要、独立沙箱、run-unique 原始文件名共同保证了任何一次 PASS 结论都只对当时的 skill 当时的评估配置有效。小结warp-eval 的基准评估报告展示了一个发布级 skill 应有的验证深度三层递进评估静态验证 → 语义去重 → 实况 Agent 评估、五维评分与三档独立阈值、严格的证据状态词表、以及跨两个不同 Agent 的一致性表现Overall 96%/94%。更值得借鉴的是其评估方法论——提升值仅作诊断、维度门决定裁决、未测量即如实标记、单样本只支持数量级结论——这些纪律既约束了被评估的 skill本身也是任何性能对比实验应遵循的准则。若要在自己的项目中复现或扩展这套验证可直接研读 SKILL.md 的九阶段流程与十三硬规则以 rejection-gates.md 定义精确的排除边界并用 benchmark-protocol.md 与 measure.py 保证测量可复现、可比较。【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 warp-eval Skill 基准评估报告解读：Warp GPU 加速候选热路径的三层验证体系
warp-eval Skill 基准评估报告解读Warp GPU 加速候选热路径的三层验证体系【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warpwarp-eval 是 NVIDIA Warp 仓库内置的一个评估型 skill用于回答一个特定问题既有代码库中的某条热路径是否值得用 NVIDIA Warp 重写以换取 GPU 加速。它不做推广建议、不替用户做采纳决策只产出可复现的证据。本文基于仓库中该 skill 的基准评估报告skills/warp-eval/BENCHMARK.md展开解读其评估结果、三层评估体系、五个评分维度与阈值逻辑并结合 SKILL.md 及其七份参考文献、三个配套脚本说明这套评估方法论的内部机理。读完本文你将理解一个评估型 skill自身是如何被系统化验证的以及该 skill 在实战中如何通过拒绝门Rejection Gates、基准协议与报告模板约束 Agent 产出可信的测量证据。评估结论速览PASS基准报告的总体结论是一个清晰的绿灯Overall verdict: PASS — Recommended for publication整体裁决通过推荐发布Publication Recommendation基于本报告中已完成的评估证据推荐发布该 skill。这意味着 warp-eval 通过了 Skill 发布前的验证门槛它使用安全、答案正确、能被正确发现并激活、能帮助 Agent 完成用户目标与预期工作流并且避免了浪费的 skill 与工具调用。报告开篇即说明这套评估要回答的核心问题是见 BENCHMARK.md 的 What This Report Answers 一节使用是否安全is safe to use产出是否正确produces correct answers需要时能否被发现并被激活is discovered and activated when needed是否帮助 Agent 完成用户目标与预期工作流helps the agent complete the users goal and expected workflow是否避免浪费的 skill 与工具使用avoids wasted skill and tool usage。评估元数据22 个任务、2 个 Agent、隔离沙箱报告记录了完整的可追溯元数据这是任何可复现评估的基线元数据项值Skillwarp-eval评估日期2026-08-11评估器版本1.2.0AgentClaude Codeaws/anthropic/bedrock-claude-opus-4-8、Codexopenai/openai/gpt-5.5任务数2214 个正向、8 个负向数据集摘要sha256:3cef7eea…skill-evaluator-dataset-snapshot/1每任务尝试次数1运行环境k8s-sandbox证据等级Tier 3实况 Agent 评估发布必需值得注意的细节是每个任务尝试都在各自独立的沙箱 pod 中运行Each task attempt ran in its own isolated sandbox pod。这种隔离既防止任务之间的状态污染也保证任何一项失败都可追溯到单一尝试这与 skill 内部每个方案保留为独立 patch、测量在独占设备锁下串行执行的纪律一脉相承。正向任务positive验证 skill 应当承接的场景——不规则查询、粒子/几何仿真、分支密集循环、大量小规模 launch、宿主端回退、超大中间张量等负向任务negative验证 skill 应当排除的场景——跨厂商或纯 CPU 部署、厂商已压低的稠密 NN 层、通用 Warp API 问答、已选定的 Warp kernel 等。两类任务的组合用于防止过度承接与过度拒绝两种偏差这与 SKILL.md frontmatter 中description字段对纳入/排除边界的精确表述一一对应。结果速览Skill 带来的全面提升报告核心是一张按五个维度拆分的提升表Baseline 表示不含目标 skill 的同一任务尝试Uplift 表示skill 得分 - baseline 得分百分点维度Claude CodeBaseline → Skill UpliftCodexBaseline → Skill UpliftOverall75% → 96%21 点69% → 94%25 点Security100% → 100%±0 点91% → 100%9 点Correctness82% → 96%15 点68% → 94%26 点Discoverability68% → 100%32 点61% → 91%30 点Effectiveness60% → 86%25 点58% → 86%28 点Efficiency64% → 96%32 点62% → 98%36 点读法示例47% → 92%45 points表示带 skill 的运行得分 92%比无 skill 的 47% 基线高出 45 个百分点。从表中可以提取几个结构性结论Discoverability 与 Efficiency 是提升最大的维度32/36 点skill 最直接的价值在于该被加载时被加载和避免浪费的测量循环这正是评估型 skill 的命门——一个评估流程如果无限采集证据、反复询问或做了被禁止的 profiling就会在效率维度崩塌。Security 在 Claude Code 上满分且无提升空间在 Codex 上从 91% 提升到 100%说明 skill 的未授权不测量红线硬规则第 8 条对两个 Agent 都形成了有效约束。两个 Agent 的最终 Overall 均超过 94%该 skill 的表现不依赖单一模型具备跨 Agent 的稳健性。报告特别强调的读表要点是提升值仅作为诊断性证据不覆盖最终裁决。即使提升为负只要每个配置的维度在至少一个受支持 Agent 上通过Overall 仍可为 PASS详见后文裁决门。三层评估体系Tier Statuswarp-eval skill 的验证遵循三级递进体系报告给出了每一级的状态与证据Tier目的状态证据Tier 1静态验证Static validationPASSED1 个验证器0 个问题Tier 2语义去重Semantic deduplicationNOT RUN未记录结果Tier 3实况 Agent 评估Live agent evaluationPASS2 个 Agent22 个任务三个 Tier 各有分工Tier 1 静态验证对 skill 的清单文件manifest做机械校验。报告发现项里列出的Found skill manifest: SKILL.md即属此类——确认 skill 携带符合规范的 SKILL.md其中包含name、description、license: Apache-2.0、metadata.author: NVIDIA Corporation与compatibility声明。静态验证结果以验证器数量 发现的问题数量形式报告本次为 1 个验证器、0 个问题。Tier 2 语义去重用于检测 skill 之间语义重叠本次未运行报告如实标注NOT RUN——这是整个报告严谨性的缩影未测量的项如实记为未测量绝不补一个貌似合理的数字这一纪律在 evidence-and-reporting.md 中被反复强调not measured 与 not available 是被允许且被鼓励的状态。Tier 3 实况评估真正的行为验证。2 个 Agent × 22 个任务 44 次独立尝试每次在独立 pod 中运行产出 verdictPASS且记录最佳 Agent 为 claude-code。此外报告在 Findings 中记录了两条成功检查Schema Repository Governance: Found skill manifest: SKILL.md与AGENT_EVAL: Tier 3 evaluation complete: verdict PASS; best agent claude-code。评分方法论五个维度、六种信号、三档阈值报告用可折叠详情块完整给出了评分定义这是整个评估体系最核心、最可复用的部分。维度定义与信号构成维度问题计分信号Security使用是否安全security100%Correctness答案是否正确accuracy100%Discoverability需要时是否正确加载了 skillskill_execution100%Effectivenessskill 是否帮助完成任务goal_accuracy50%behavior_check50%Efficiency是否避免了浪费的 skill/工具使用skill_efficiency100%注意Effectiveness 是目标达成率与预期工作流符合度的等权均值也就是说做对了与按该 skill 定义的正确方式做各占一半权重——这对评估型 skill 尤其重要即使最终结论正确如果 Agent 跳过授权检查直接 profiling、或未按报告模板输出Effectiveness 也会被扣分。本轮的六种信号security不安全操作、密钥泄漏、未授权访问skill_execution预期 skill 是否被发现并执行skill_efficiency路由质量、对工作区感知的 skill 读取、富有产出的工具使用accuracy最终答案相对参考答案的正确性goal_accuracy用户目标是否达成behavior_check预期工作流行为是否被遵循。阈值与裁决逻辑报告明确给出了三层阈值体系彼此独立、不可混用维度带Dimension bandsPASS ≥ 50%NEUTRAL 为 40%含到 50% 以下FAIL 40%。Tier 3 总体提升Overall Tier 3 liftPASS ≥ 5 点FAIL ≤ -10 点两者之间为 NEUTRAL。50% 任务通过阈值attempt pass threshold这是每个任务的独立门槛不是维度阈值。而最终裁决Overall verdict的门是每个配置的维度在至少一个受支持 Agent 上全部 PASS 才给出 PASS。提升值只作为诊断证据报告不覆盖这个门——这解释了为什么报告在 Claude Code 的 Security 已满分±0 提升的情况下整体裁决仍为 PASS。报告还特别声明了两条只报告不计分的边界Token 效率是独立的仅报告信号不改变维度得分或整体裁决维度带与 50% 任务阈值是两套独立门槛。被评估的对象warp-eval skill 的九阶段评估流程基准报告评估的正是这个 skill 的核心能力。要理解分数含义需要看 SKILL.md 定义的九阶段流程——它决定了 Agent 在正向任务中应该怎么做读代码、推导契约、检查拒绝门识别候选热路径与度量从仓库推导设备/驻留、dtype/形状、规模、频率、进程生命周期、梯度与打包约束用一句话陈述推导出的契约并邀请纠正在 profiling 之前检查 Gate A–E。对真实应用做 profiling需要显式授权与已解决的环境意图问题测量同步的端到端阶段时间与峰值内存。形成可证伪假设逐候选记录来源、瓶颈证据、目标、窄接缝、Warp 可改变的机制、最强基准、风险、接受阈值、最便宜的证伪实验。原型之前先写契约定义值、dtype、形状、设备、错误、突变、顺序、并列、容量/溢出、拓扑/退化、容差、梯度、流、所有权、别名、失效、并发、捕获、拆卸与回退在看到 Warp 输出之前固定容差。先改进基准算法优先于后端——更好的算法 → 分块/平铺/稀疏输出/布局/重物化 → 既有框架的编译器与原生原语 → 项目已依赖的能力 → 最后才是收窄的 Warp 实现。原型最小单元在独立副本中工作生产代码不动集成接缝默认关闭显式选择 CUDA 设备并验证 Warp 将其解析为 CUDA按共享数据与结构生命周期而非函数边界划定单元大小。基准测试整个边界每个瓶颈复制一份 driver-template.py通过 measure.py 测量Warp 的 launch 是异步的测量助手必须在计时区域前后立即同步所选设备。汇总证据按接缝与执行制度报告语义结果、最强基准测量、工作负载来源、时间、内存、生命周期、可移植性与所有权事实每个占测量总量 ≥10% 的阶段都需有普查行。交还按 warp-evaluation-report-template.md 固定 schema 交付warp-evaluation-report/目录含warp-evaluation-report.md、solutions/、benchmarks/、results/并用validate_report_schema.py校验。与流程配套的是 13 条硬规则Hard rules其中几条直接决定了基准评估中 Security 与 Correctness 维度的得分来源正确性是门基准实现有 bug 或契约不明时中止该比较直到存在独立 oracle硬规则 2绝不在未授权时做测量阶段 1 之后必须停下询问才允许 profiling、环境变更、原型、基准或 GPU 使用硬规则 8Warp 测量仅限 CUDA 且必须同步解析显式 NVIDIA CUDA 设备丢弃 CPU 解析与仅派发计时硬规则 11绝不做采纳建议或排名按接缝与制度报告事实、测量、假设与未知硬规则 12。评估背后的纪律拒绝门与目标模式基准任务中负向任务应当 ABORT的行为由 rejection-gates.md 定义的六个精确门支撑。门是精确的绝不使用相邻或类比条件硬规则 5只有当定义中的每个条件都被确立时才触发Gate A — 部署排除 NVIDIA生产被陈述为纯 CPU或要求非 NVIDIA 可移植性且无可接受的选配 CUDA 路径。仅凭没有 GPU 代码、依赖清单里没有 CUDA、目前恰好跑在 CPU 上不触发——这些不能证明产品不允许用 NVIDIA GPU。未决时进入AWAITING INTENT问一次并停下。Gate B — 边界主导数据必须按小规模或低频调用跨越 host/device 边界且无法加宽。Gate C — 普通稠密张量代数已被框架或厂商库高效压低的稠密线性代数、卷积、FFT、归约、标准 NN 层。Gate D — 成熟 CUDA 实现已满足契约三个条件缺一不可——有维护中的实现、确认经 CUDA 在 NVIDIA GPU 上执行、已满足语义并接近硬件极限。再快的原生 CPU 库也只是基准候选不是 Gate D。Gate E — 项目无法承担义务依赖、运行时编译、kernel 缓存、版本矩阵、平台特定测试与回退路径等义务被陈述的策略所阻挡。Gate F — 该区域可证明无关紧要仅能由用户提供的 profile、明显的结构界或用户所引数字的算术触发推断值永远不会触发它且必须能陈述天花板算术。门的退出句有固定句式ABORT — Gate letter: cited fact; why the scoped Warp evaluation cannot proceed且不提名首选替代方案。正向任务识别值得评估的模式则由 target-patterns.md 的九类工作负载支撑低维空间邻域构建、持久 BVH 点/网格查询、分支密集的图与标签算法、融合逐元素循环消除 batch×domain 中间张量、规则稠密网格模板与几何、高数据重用的计算受限规则工作、带状态数据结构的框架 FFI、众多独立小问题、每步跨越 host 边界的迭代循环。每个类别都给出信号Signals、反信号Anti-signals、建议接缝Seam与由什么决定Decided by并明示模式匹配只说明该测什么、什么通常会被淘汰本身不是收益证据。测量协议与脚本实现基准评估中 Efficiency 维度Claude Code 32、Codex 36 的最大提升项对应的实战约束落在 benchmark-protocol.md 及其脚本实现上。几个最能体现防止 Agent 浪费时间的设计独占执行整个测量扫描持有一个独占设备锁flock -x $GPU_LOCK -c the whole sweep而不是一次锁一个样本且不可在锁内等待 0% 利用率——应在获取前用有限超时检查空闲。采样哲学你在估量一个数量级不是在产出基准。measure.time_it实现为丢弃一次预热然后只计时一次measure.sig2四舍五入到两位有效数字——单样本不支持1.87×只支持约 1.9×常常只能约 2×。协议明确警告不要为提高报告数字而调高samples参数。比较分辨率至少1.5×才算方向性差异低于 1.5× 视为此精度下无实测差异两者都不是采纳判断。null_test证明 harness 真的跑了工作一个静默失败的 harness 会报告极快的时间读起来恰好像加速——4× 的工作应花费约 4× 的时间观测比值随计时一并报告。内存记账host_memory读/proc的VmHWM而非ru_maxrss后者跨 spawn 继承子进程会继承父进程的峰值device_memory用 NVML 按进程 GPU 内存——这是唯一能同时看见所有框架与 CUDA context 的域一个裸 context 约数百 MiB 而 CuPy 自身的池计数器会报 0run_isolated为每个用例开启全新进程峰值计数器在进程内单调同一进程测两种配置等于一次测量。结果不跨 GPU 架构迁移依赖 unrolling、寄存器预算、占用率、共享内存或 tile 形状的优化在不同 NVIDIA 代际间可能相差 2× 以上甚至反转。必需计时阶段进程/框架导入、冷缓存编译、热缓存加载、首次 launch 与首次加速结构构建、热 build/refit/rebuild、热 kernel/查询时间、包装器开销、图捕获与重放含重捕获次数、端到端公开调用、下游阶段、以及 1/10/100 次调用的实测总量total(N)公式给出各分量加和。用实测总量报告交叉点区间绝不从纯 kernel 比率推导生产策略。measure.py 的模块 docstring 将该协议逐条落实time_it的一弃一测、comparison的 1.5× 分辨率、sig2、VmHWM读取、run_isolated、null_test并声明协议是规格说明本模块是其实现每个默认值都编码了其中一条规则。配套的 driver-template.py 是每个瓶颈一份的可复制骨架只需填充CASES、SIZES默认10**3, 10**6、INPUT_DISTRIBUTION对关系型操作通常是结果最大的杠杆——成本取决于输入的联合分布、build_workload()与run()输出为 run-unique 的 JSON Lines 文件results/bench-bottleneck-runid.jsonl重跑不会覆盖报告已引用的文件。证据与报告交付评估的最终产物是 warp-evaluation-report-template.md 定义的固定 schema 报告warp-evaluation/v1目录结构为warp-evaluation-report/ ├── warp-evaluation-report.md ├── solutions/ # 每个被测方案一个独立 .patch ├── benchmarks/ # 实际运行的脚本 README.md └── results/ # 原始样本与日志报告模板要求严格的状态词表pass/fail/not measured/not available/no representative data/unknown/n/a且not measured在范围内但未采集与not available计数器或工具不存在含义不同绝不用貌似合理的数字顶替。报告核心是一张按基准 → 当前依赖可达方案 → Warp排序的瓶颈表比值单元格只允许N× faster / N× slower / N× less / N× more / same内存单元格须内联注明域如386 MiB host / 13.9 MiB device正确性一节要求同时给出候选修正了 N₁ 个基准输出、回归了 N₂ 个契约输出的双向统计——与基准差异 N 项不是合格表述。报告以一句固定收尾本报告中没有任何内容被应用。是否停止、补数据或作为后续任务请求实现由用户决定。evidence-and-reporting.md 进一步定义了五种程序状态——ABORT、AWAITING INTENT、AWAITING AUTHORIZATION、INCOMPLETE、Report delivered——以及每种状态下是否创建报告目录的规则并列出交付前验证器检查不到的事项清单授权是否记录、是否存在总体评估句、瓶颈表是否穷尽、越界比较是否混入、每个数字是否可追溯到原始 artifact 与确切工作负载等。报告目录生成后用验证器把关uv run python scripts/validate_report_schema.py report-directory规则是首次测量建立普查/表格后运行一次交付前再运行一次修复每一个错误绝不豁免 schema 错误见 SKILL.md 的 Troubleshooting 节。何时需要重新生成基准Freshness报告在结尾给出了触发重新评估的条件——当以下任一要素变化时必须重新生成该基准skill 本身、评估数据集、目标 Agent/模型、评估器版本、环境、或评分策略。这一条款与报告可复现性的其他要求数据集 sha256 摘要、独立沙箱、run-unique 原始文件名共同保证了任何一次 PASS 结论都只对当时的 skill 当时的评估配置有效。小结warp-eval 的基准评估报告展示了一个发布级 skill 应有的验证深度三层递进评估静态验证 → 语义去重 → 实况 Agent 评估、五维评分与三档独立阈值、严格的证据状态词表、以及跨两个不同 Agent 的一致性表现Overall 96%/94%。更值得借鉴的是其评估方法论——提升值仅作诊断、维度门决定裁决、未测量即如实标记、单样本只支持数量级结论——这些纪律既约束了被评估的 skill本身也是任何性能对比实验应遵循的准则。若要在自己的项目中复现或扩展这套验证可直接研读 SKILL.md 的九阶段流程与十三硬规则以 rejection-gates.md 定义精确的排除边界并用 benchmark-protocol.md 与 measure.py 保证测量可复现、可比较。【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考