oh-my-openagent work-with-pr 技能 A/B 基准报告：量化 Agent 技能对 PR 工作流的实际价值

本文围绕 oh-my-openagent 仓库中一份真实的技能基准报告展开，完整解析 work-with-pr 技能在“有技能 / 无技能”两组条件下的 A/B 评测数据：总体通过率、逐评测拆分、关键区分性断言、唯一的“有技能”失败案例，以及耗时成本分析。读完本文，你将理解如何为 coding agent 技能设计可复现的评测集（evals）、如何判定哪些断言真正衡量技能价值（区分性断言 vs 基线断言），以及如何从基准数据中提炼下一轮迭代的改进方向。

1. 评测对象：work-with-pr 技能与其完整 PR 生命周期

本次基准评测的目标技能是 work-with-pr，它定义了从零到合并的完整 PR 生命周期：

Phase 0: Setup         → 拆分为原子 PR，每个 PR 独立分支 + worktree（可并行）
Phase 1: Implement      → 通过 ulw-loop 技能驱动实现，证据绑定的手动 QA，原子提交
Phase 2: PR Creation    → 推送，创建面向人类评审者的英文 PR，targeting dev
Phase 3: Verify Loop    → 无上限循环：CI 门禁 + Cubic 门禁，任一失败回到 Phase 1
Phase 4: Merge         → 默认 auto-merge，合并后清理 worktree

技能的核心主张包括：工作必须发生在仓库同级目录的独立 git worktree 中（主工作目录只读）；提交必须保持原子性（如 3+ 文件变更对应 2+ 提交）；验证循环无迭代上限，任何失败门禁都会把流程路由回实现阶段。这份技能正是本次基准要回答的问题——它到底带来了多少可测量的差异——的评测对象。

评测工作区位于 .agents/skills/work-with-pr-workspace/，目录结构本身就是一种可复用的评测组织方式：

work-with-pr-workspace/
├── evals/
│   └── evals.json              # 评测集定义：5 个场景的 prompt + 断言
└── iteration-1/                # 第 1 轮迭代
    ├── eval-1/ ... eval-5/      # 每个评测
    │   ├── eval_metadata.json  # 该评测的断言快照
    │   ├── with_skill/          # 有技能组
    │   │   ├── outputs/        # execution-plan / pr-description / verification-strategy / code-changes
    │   │   ├── grading.json    # 逐条断言的通过/失败 + 证据
    │   │   └── timing.json     # 耗时
    │   └── without_skill/      # 无技能组（同结构）
    ├── benchmark.json          # 汇总数据（机器可读）
    ├── benchmark.md            # 汇总报告（本文主体文档）
    └── review.html             # 可视化评审页

2. 评测集设计：5 个贴近真实任务场景

evals.json 定义了 5 个评测场景，prompt 均刻意采用贴近真实用户口吻的自然语言，覆盖新功能、bug 修复、重构、MCP 新增与正则修复五类任务：

评测	场景（prompt 要点）	断言数
happy-path-feature-config-option	为 oh-my-opencode 增加 max_background_agents 配置项（默认 5），加校验并让 background manager 遵守，创建 PR	10
bugfix-atlas-null-check	修复 atlas hook 在 boulder.json 缺少 worktree_path 字段时崩溃的 bug，以 PR 落地并确保 CI 通过	6
refactor-split-constants	将 delegate-task 的 constants 文件拆分为独立文件，保持 barrel export 向后兼容	5
new-mcp-arxiv-casual	口语化需求（"implement issue #100 ... pr it"）：新增 arxiv 论文搜索的内置 MCP	5
regex-fix-false-positive	comment-checker hook 误报含 Note: 的正常注释，放宽正则并补测试，独立分支 + PR	5

合计 31 条断言。断言设计上有两层：一层是技能特有的程序性知识（worktree 隔离、原子提交、三门禁验证循环、Cubic 检查方法、worktree 清理），另一层是基线能力（引用真实文件、PR 指向 dev、推送前跑本地检查）。这一区分在后文的“区分性分析”中成为核心方法论。每个评测还会记录 eval_metadata.json 作为该轮断言快照，保证数据与定义可对账。

值得注意的一点：SKILL.md 正文描述验证循环为“两个门禁——CI 和 Cubic”，而本轮评测断言（three-gates）要求的是“CI + review-work + Cubic 三个门禁”，且有技能组的执行计划（如 eval-1 执行计划）也确实把 review-work（5 个并行子代理评审）排为 Gate B、Cubic 排为 Gate C。从评测数据与技能文档的结构差异看，可以推断评测集在校验一个比技能文档当前版本更严格/演进阶的验证模型，这也直接体现在了后文的门禁断言结果上。

3. 总体结果：通过率 +45.2%，耗时 +12%

汇总报告 benchmark.md 的核心结论如下：

Metric	With Skill	Without Skill	Delta
Pass Rate	96.8% (30/31)	51.6% (16/31)	+45.2%
Mean Duration	340.2s	303.0s	+37.2s
Duration Stddev	169.3s	77.8s	+91.5s

解读：有技能组在 31 条断言中通过 30 条，无技能组仅 16 条；而平均耗时只增加约 12%（37.2s）。耗时标准差则从 77.8s 扩大到 169.3s，说明技能引入了更多样化的执行路径（复杂任务上花时间更多，简单任务上不拖慢）。

4. 逐评测拆分：差异集中在哪些任务上

Eval	With Skill	Without Skill	Delta	With 耗时	Without 耗时
happy-path-feature-config-option	100% (10/10)	40% (4/10)	+60%	292s	365s
bugfix-atlas-null-check	100% (6/6)	67% (4/6)	+33%	506s	325s
refactor-split-constants	100% (5/5)	40% (2/5)	+60%	181s	229s
new-mcp-arxiv-casual	100% (5/5)	60% (3/5)	+40%	152s	197s
regex-fix-false-positive	80% (4/5)	60% (3/5)	+20%	570s	399s

两个值得注意的模式（数据来自 benchmark.json）：

• 简单任务上技能组反而更快：eval-1（292s vs 365s）、eval-3（181s vs 229s）、eval-4（152s vs 197s）中，有技能组耗时更短。这与分析师注记一致——平均耗时增加主要由 eval-2（bug 修复）和 eval-5（正则修复）驱动，技能的深度验证规划在“修复类”任务上增加了开销。
• 唯一未拿满分的评测是 eval-5：有技能组 4/5，失败的正是“最小变更”断言，详见第 7 节。

5. 关键区分性断言：哪些检查项真正衡量了技能价值

benchmark.md 列出的 Key Discriminators（有技能 vs 无技能）：

断言	With Skill	Without Skill	结论
three-gates（CI + review-work + Cubic）	5/5	0/5	最强信号
worktree-isolation	5/5	1/5	接近最强
atomic-commits	2/2	0/2	中等区分力
cubic-check-method	1/1	0/1	小样本但方向明确

three-gates 是决定性证据：无技能组的 agent 从未听说过 review-work 与 Cubic 门禁。benchmark.json 中的 failed_assertions 给出了逐条失败原因，例如 eval-1 无技能组：

• “Verification loop includes all 3 gates” → 失败原因：Only mentions CI pipeline in step 6. No review-work or Cubic.
• “Gates are checked in order” → 失败原因：No gate ordering - only CI mentioned
• “Cubic check uses gh api to check cubic-dev-ai[bot] reviews” → 失败原因：No mention of Cubic at all

这类门禁知识（如何订阅 CI 完成、如何用 gh api 检查 cubic-dev-ai[bot] 评论中的 “No issues found”、Cubic 配额耗尽时如何记为 SKIPPED）在 SKILL.md 的 Phase 3 中有完整脚本化定义——它们是无法从代码库本身推断出来的流程性知识，这正是技能价值最密集的区域。

worktree-isolation（5/5 vs 1/5）：无技能组中 4/5 的运行直接用了 git checkout -b 而没有 worktree 隔离（失败原因：Uses git checkout -b, no worktree isolation）；唯一通过的是 eval-4，分析师注记指出该运行独立地选择了 worktree，说明部分 agent 本身具备 worktree 模式知识，但技能让这一行为变得一致而非碰运气。对照 SKILL.md 的 Phase 0：worktree 必须建在仓库同级目录（../${REPO_NAME}-wt/${BRANCH_NAME}），避免嵌套仓库问题并让“一个 PR 一个 worktree”的并行成为低成本操作。

atomic-commits（2/2 vs 0/2）：无技能组的 agent 即使面对多文件重构也默认用单个提交（eval-3 失败原因：Single atomic commit）；而有技能组按 SKILL.md 的提交策略执行（3+ 文件 → 2+ 提交，5+ 文件 → 3+ 提交）。从 eval-1 的 grading.json 可以看到证据绑定方式：atomic-commits 通过的证据是 2 commits: schema+tests, then concurrency+manager——评分不是看“是否说了原子提交”，而是核对执行计划里的实际提交拆分。

6. 非区分性断言：基线能力不衡量技能价值

benchmark.md 的 Non-Discriminating Assertions：

• References actual files：两组均通过
• PR targets dev：两组均通过
• Runs local checks before pushing：两组均通过

这些断言在两组条件下都通过，说明它们验证的是基线 agent 能力（会读代码库、知道目标分支、会跑本地检查），而不是技能带来的增量。分析师注记的建议是：在后续迭代中考虑移除或降低这些断言的权重——否则它们会稀释整体通过率信号，掩盖真正有区分力的检查项。这是评测集设计中通用且容易被忽视的一点：断言集应该优先保留“只有读了技能才会通过”的项目。

7. 唯一的“有技能”失败：修复类任务的过度工程倾向

eval-5（正则误报修复）中，有技能组唯一失败的断言是 minimal-change：“Only modifies regex and adds tests — no unrelated changes”。失败原因（benchmark.json）：

Also proposes config schema change (exclude_patterns) and Go binary update — goes beyond minimal fix

即：一个本应“放宽正则 + 补测试”的最小修复，被技能引导的 agent 扩展成了配置 schema 变更与 Go 二进制更新的组合方案。benchmark.md 的定性结论是：The skill may encourage over-engineering in fix scenarios.（技能可能在修复类场景中鼓励过度工程）。这并非偶然——SKILL.md 的实现阶段强调“每条成功标准都要有证据绑定的手动 QA”，这种“做足”的倾向在功能开发上是资产，在最小修复上却成了负债。分析师注记给出的迭代 2 方向是：为 fix 类任务增加显式的 “stay minimal” 指导。

这构成了一个有参考价值的结论：技能收益不是无条件的。对新功能/重构类任务，技能把通过率拉到 100%；对最小修复类任务，技能组（80%）与无技能组（60%）的差距缩到 +20%，且引入了过度工程风险。

8. 分析师完整注记（Analyst Notes 全量继承）

benchmark.md 与 benchmark.json 的 analyst_observations 给出的完整分析结论：

1. 技能的主要价值在于程序性知识（验证门禁、worktree 工作流）——这些是 agent 无法仅从代码库推断出来的。
2. 耗时成本温和：平均 +12%（340s vs 303s），相对 +45% 的通过率提升可以接受。
3. 迭代 2 建议：增加“fix 类任务保持最小变更”的显式指导。
4. 耗时差异的驱动因素：with-skill 更慢主要由 eval-2 与 eval-5 驱动（技能的深度验证规划在修复类任务上增加开销）；eval-1 与 eval-3/4 中 with-skill 实际更快。
5. 方差差异：without-skill 标准差更低（78s vs 169s），说明技能引入了随任务复杂度变化的更多样执行路径。
6. 非区分断言处理：References actual files、PR targets dev、Runs local checks 两组都通过，应移除或降权。
7. 原子提交区分力中等：2/2 vs 0/2；无技能 agent 默认单提交，即使面对多文件重构。

9. 方法论小结：如何复现一份技能基准

从本轮工作区的组织方式，可以提炼出一套可复用的 agent 技能基准方法：

1. 定义评测集（evals.json）：每个场景包含自然语言 prompt、期望产出描述与断言列表；断言混合“技能特有知识”与“基线能力”两类，以便事后区分区分力。
2. 双条件运行：同一 prompt 分别在 with_skill 与 without_skill 条件下运行，产物（执行计划、PR 描述、验证策略、代码变更说明）落盘到 outputs/，耗时记录到 timing.json。
3. 证据绑定评分：grading.json 对每条断言记录 passed 与具体证据（如 Uses ../omo-wt/feat-max-background-agents），而非主观打分。
4. 汇总 + 区分性分析：benchmark.json/md 给出总体与逐评测指标，并单列“关键区分断言”“非区分断言”“唯一反向失败”三块，把数据转化为迭代决策。
5. 迭代闭环：本轮结论（fix 类任务过度工程）直接指向下一轮技能文案修改，形成“评测 → 定位失败模式 → 修改技能 → 重新评测”的循环。

这份基准的适用范围需要说明：它是针对 work-with-pr 技能在本仓库工作流（dev 分支 + CI + Cubic 机器人评审 + worktree 约定）下的第 1 轮（iteration-1）测量，5 个场景、单轮迭代，样本量有限；结论应理解为该评测集上的方向性证据，而非普适性的技能优劣判定。但对任何需要为 coding agent 编写/优化技能（skill）prompt 的团队，这套“断言区分度 + 证据绑定评分 + 耗时成本”的度量框架是可以直接借鉴的。