PinchBench 是一套用真实任务评测 LLM 模型作为 OpenClaw 编码 Agent 的基准测试系统。跑完一轮后，很多人只瞄一眼总分就关掉了终端——但 PinchBench 结果分析的真正价值藏在三个地方：结果 JSON、Transcript 日志和综合得分算法。这篇文章用尽量少的代码，带你逐字段读懂它们，并亲自动手算一遍综合得分。

一、跑完一次基准测试，你会得到什么

执行 scripts/run.sh 后，产物默认落在results/目录（可用--output-dir指定），主要两类文件：

两个小细节值得知道：

• 增量写入：基准测试每完成一个任务就会重写一次结果 JSON，并带上"in_progress": true、completed_tasks和total_tasks字段（见 scripts/benchmark.py），所以你可以边跑边打开文件看进度。
• run_id 与 model_slug：run_id是 4 位递增编号（0001、0002…），model_slug是模型 ID 把/和.替换成-后的形式。

二、结果 JSON 逐字段拆解

最终 JSON 由 scripts/benchmark.py 生成，顶层字段如下：

tasks[]中每条任务记录包含：

💡 每个任务的满分是1.0，grading.mean就是该任务的平均得分。LLM 评委被要求"严格打分"：普通合格表现约 0.6~0.7，1.0 只留给真正出色的完成（评分提示词见 scripts/lib_grading.py）。

三、Transcript 日志：还原 Agent 的每一步操作

Transcript 是 JSONL 文件——每行一个事件，绝大多数行形如：

{"type": "message", "message": {"role": "assistant", "content": [...]}}

读懂它只需要掌握三种角色（role）：

Token 用量也是从这份日志里来的：_extract_usage_from_transcript() 遍历所有assistant消息，累加input_tokens、output_tokens、缓存读写 token、cost_usd和request_count——这就是结果 JSON 里usage字段的来源。

多会话任务（multi-session）更讲究一点：带new_session: true的每一步会在开始前把上一段会话归档成{task_id}_session{i}.jsonl（见 scripts/lib_agent.py），最后再按顺序合并，保证评委能看到完整历史。

下面这张"皱巴巴的收据"就是真实任务素材——task_image_identification 会把它复制进 Agent 的工作区，让模型判断图片内容：

排查"为什么这个任务得分低"时，Transcript 是最好的证据链：先找toolCall看动作，再看toolResult看结果，最后对照grading.notes看评委扣分理由。

四、综合得分是怎么算出来的

4.1 单任务：三种评分方式

任务文件的grading_type决定评分路径（见 scripts/lib_grading.py）：

• automated：执行任务文件里的 Python 检查函数，检查工作区产物和 Transcript，各准则 0~1 分后取平均；
• llm_judge：把 Transcript 摘要 + 评分细则（rubric）+ 工作区文件交给评委模型，输出{"scores": {...}, "total": 0.x, "notes": "..."}；
• hybrid：两者按grading_weights加权平均。

4.2 分类得分与总分

_compute_category_scores() 的算法非常直观：

1. 每个分类：pct = 该分类得分总和 / 任务数 × 100（因为每任务满分 1.0）；
2. 总分：overall_pct = 所有任务得分之和 / 任务总数 × 100；
3. 终端摘要还会用颜色标记：🟢 ≥ 90%、🟡 ≥ 70%、🔴 < 70%（见 scripts/benchmark.py）。

比如你跑了 53 个任务共得 38.6 分，总分就是38.6 / 53 × 100 ≈ 72.8%，与 README.md 中 Leaderboard 的口径一致。

4.3 效率指标：得分之外还要看"花了多少"

_compute_efficiency_summary() 汇总所有任务的usage，产出几个实用的对比指标：

举个例子：模型 A 总分 40、花费 800 万 token，则score_per_1k_tokens = 40 ÷ 8000 = 0.005；模型 B 总分 39、花费 500 万 token，得分为0.0078——虽然 B 的绝对分略低，但性价比更高。选模型时这两个维度要结合着看。

4.4 两道"防翻车"保险

• sanity 快速失败：task_sanity得 0 分且 Transcript 存在时，整个运行直接中止（exit code 3），避免浪费一整轮 API 费用；
• Judge 缓存：相同任务 + Transcript + rubric + 工作区内容会命中缓存（results/.judge_cache/），重复运行不再重复付费。

五、上手实战：三步读懂你的第一次结果

1. 打开结果 JSON：先扫category_scores，找到最弱的分类（🔴 那几行），这决定了你下一步该看哪些任务；
2. 钻进 Transcript：挑一个低分任务，到results/{run_id}_transcripts/找对应.jsonl，按toolCall→toolResult的顺序回放 Agent 的操作，判断是"没做对"还是"做了但没检查到位"；
3. 对照效率指标：回到efficiency.per_task，看低分任务是否同时烧了最多的 token——分数低、消耗高，才是真正需要优先优化的场景。

想深入细节时，这几个文件是最佳入口：任务格式规范 tasks/TASK_TEMPLATE.md、任务清单 tasks/manifest.yaml、评分引擎 scripts/lib_grading.py 与执行层 scripts/lib_agent.py。读懂了结果 JSON、Transcript 和得分公式，你就完成了 PinchBench 结果分析的基本功——剩下的，就是拿它选出一个既聪明又省钱的模型了 🦀