门户首页
过程分析 · 方法论收口 · 第 4 讲

点 + 线：过程评估方法论与 Trajectory Linting

前三讲的所有工具——PRA、5 个 detector、step 分类——都在一条已经跑完的轨迹上做切片分析，这叫「点级」评估。 但真实软件开发是长时序的：一个任务接一个任务、一个补丁接一个补丁，loop 能不能持续推进、不破坏前序成果，是另一个维度的问题——「线级」评估。 这一页先搭出「点 + 线」的完整方法论地图（含 LoopsBench 的 25.00% 天花板警示）， 再介绍把代码 linting 范式平移到轨迹上的 Trajectory Linting：8 条机械可判的规则，在一条真实 45 步轨迹上抓出 75% 的形式问题。

生成时间：2026-09-05 · 版本 v0.2 · 生成 Agent：DeepSeek Harness (LLM: glm-5.3) · 素材：wiki/39 方法论索引 + wiki/40 Trajectory Linting · 载体：agentsoft-research-platform
← 返回入口页 前置：问题 step 分类学 延伸：Agent 测试价值悖论 下一单元：训练闭环 · 过程监督

概览

5
评估层级栈
25.00%
线级评测天花板（最强配置）
8
示例 lint 规则
75%
真实轨迹形式问题抓出率
项目说明
本卡定位「轨迹分析与过程评估」单元第 4 讲（收口）· 从工具上升到方法论地图，并给出形式化检查的前沿提案
前置知识前三讲（八阶段 / PRA / 分类学）；知道 CI 里 lint 是什么
读完会什么能画出"任务级 / 点级 / 流程级 / 线级 / 形式层"五层评估栈并说清各层职责；能读懂 LoopsBench 的 DAG 抽象与 5 个 metric；能把 8 条 trajectory lint 规则对号入座到真实轨迹 step 上
真实数据marshmallow-1359 的 45 步真实轨迹（本仓 experiments/ 可查）——8 条规则中 6 条在它身上真实命中

第一篇 · 五层评估栈：你评的到底是哪一层？

第一篇 · 方法论地图（1 张盘点表 + 1 张层级图）
讨论"Agent 可靠性"之前，先对齐层级——不同层的问题用不同层的工具，错层讨论就是鸡同鸭讲。
第 1 讲 · 1 盘点表

任务级 → 点级 → 流程级 → 线级 → 形式层

层级评测对象本仓现状代表工具 / 来源
任务级（终态）最终 patch 是否通过 F2P/P2P✅ 完整answer_evaluator（SWE-bench harness）
点级（step 内）单个 step 的语义 / 结构正确性✅ 完整5 个 detector（第 3 讲的分类学与决策树）
流程级（run 内）整个 run 的可靠性与约束遵守✅ 完整PRA 七维 + 一票否决（第 2 讲）
线级（long-horizon）loop 在多任务 / 多 patch 上的持续性❌ 空白（论文锚点已入仓）LoopsBench（本页第二篇）
形式层（lint）trajectory 形式层静态检查⚠️ 设计提案Trajectory Linting（本页第三篇）
flowchart TB subgraph SingleRun["单次 run 的评估（前三讲）"] L3["任务级 · 终态
F2P/P2P · %Resolved"] L2["点级 · step 内
5 detector · 四分类"] L1_["流程级 · run 内
PRA 七维 + 一票否决"] L3 --- L2 --- L1_ end subgraph LongHorizon["跨 run 的评估（本讲补全）"] LOOP["线级 · loop 上
DAG 推进 · 回归义务保留
LoopsBench 5 metric"] LINT["形式层 · 静态检查
8 条机械规则 · 毫秒级
Trajectory Linting"] LOOP --- LINT end SingleRun ==>|「点+线」合并| LongHorizon
图 1 · 五层评估栈：左边三层是"一条轨迹自身有多可靠"（点），右边两层是"loop 在长时序上能不能持续推进"（线）——互补，不重叠。
关键区分：点 = 在已存在的轨迹上做事后切片分析；线 = 让 loop 跑一条 DAG 任务，过程中记录它怎么路由、怎么保留回归义务。 本仓 5 个 detector 全是后处理，而线级评测要求把"评测契约嵌入 harness"——这是范式差别，不是加个工具的事。
素材：wiki/39 §0-§1

第二篇 · 线级评测：LoopsBench 与 25% 天花板

第二篇 · 从 harness engineering 到 loop engineering（1 个抽象 + 3 机制 + 5 指标）
SWE-bench 评"单 issue 单 patch"；LoopsBench 评"一组互相依赖的开发单元能不能连续做完"。
第 2 讲 · 1 抽象 + 1 警示

dependency DAG：把任务从"一题一补丁"抬到"依赖图上的多补丁"

核心抽象
  • 每个 task 是一组可独立测试的开发单元（unit），单元之间用有据可依的前置依赖连成 DAG（4 种入边模式：sequential / structural / functional / compositional）
  • 1 个 task = 多个 patch（如一个 Django 序列任务含 209 个 unit）；而 SWE-bench 一个任务只有 1 个 patch
Flow-aware 评测运行时的 3 个机制
机制做什么防什么
拓扑门控测试发布测试沿 DAG 按层释放，多前驱节点即门防止"跳过前置直接做后置"
回归义务保留已完成 unit 的测试，永远是后续所有层的回归义务防止"做新的、坏旧的"（SWE-bench 的 P2P 只查一次，这里持续查）
双容器快照管线容器 A 写入、容器 B 裁定，快照队列隔离防止评测与执行互相污染
防作弊的关键约束："门只影响评分，不影响编辑权限"——loop 可以跨层编辑任何文件，但不能看见 ready 标识。 评测契约嵌在 harness 里，而不是事后判分：这与人机协作中的"过程治理前置"同构——好的规则要在执行路径上拦截，而不是等出事再追责。
5 个指标与关键发现
指标测什么
RR（Resolve Rate）严格终态：所有已释放测试全过的任务占比
TPR释放测试集合上的平均通过率
Depth第一次人工接管前，单段执行沿 DAG 走了多深
Reg回归义务保留能力（之前过、后来挂的比例）
Tok资源成本（输入 + 输出 token）
三个泼冷水的发现（论文 RQ1-RQ3）
  • 天花板极低：最强配置（Opus-4.7 + Claude Code + 外层续跑）RR 也只有 25.00%——长时序是 2026 年 frontier 模型的中心限制，不是"个别模型弱"
  • loop 工程差异可达 3 倍：同一模型配不同 loop，RR 从 7.84%（Ralph 循环）到 24.11%（dynamic workflows）——而当前主流评测把 loop 当固定值，这层差异完全不可见
  • 上下文刷新不消除回归压力：dynamic workflows 用 3 倍上下文预算拿到 24.11%，但每个 run 仍有 0.36 次回归事件——"忘掉历史"不等于"不欠历史的债"
素材：wiki/39 §3 LoopsBench 论文 PDF

第三篇 · Trajectory Linting：把 ESLint 的范式搬到轨迹上

第三篇 · 形式层静态检查（1 张映射表 + 8 条规则 + 1 个真实案例）
Detector 输出"有 5 个浪费步"，linter 输出"Step 23 违反 redundant-pre-edit-reads，建议合并读取"——颗粒度从计数降到行号级。
第 3 讲 · 1 映射 + 8 规则

概念映射：代码 linting → trajectory linting

Linting 概念在 trajectory 上的对应
源代码文件一条轨迹（JSONL，约 105KB）
行号Step N（第 N 轮工具调用）
AST已结构化的事件序列（system / assistant / user / result）
Lint rule单条机械可判的规则（见下表 8 条）
severity（warn / error）info / warning / error 三级
--max-warnings 0 卡 CI--max-errors 0 卡轨迹入库（流水线门票）
ESLint 报告violations[] 数组 + summary，每条带 fix_suggestion
四条硬约束（守住才有意义）：①机械可判——能从 JSONL 字段直接 parse/grep，不需要 LLM； ②只查形式不查语义——"行为模式"归 linter，"行为质量"归 detector； ③毫秒级——单条轨迹全量 lint < 100ms（detector 才是慢路径）； ④每条规则必须给出修复建议。这跟 LLM 语义判断（agent_diet_analyzer）正交——linter 看形式，detector 看语义。
8 条示例规则 + marshmallow-1359 真实命中
#规则级别触发条件45 步真实轨迹命中
1redundant-pre-edit-reads⚠️同一文件读 ≥5 次仍无编辑✅ Steps 7,9,10,12-15 连读 fields.py 7 次，Step 19 才编辑
2wasted-edit-revert⚠️编辑后 ≤3 步内删回，净效果为零✅ Step 42 加测试、Step 44 删回
3no-verify-after-edit🔴编辑后 ≥5 步无测试运行✗ 未命中（Step 19 编辑→Step 20 立即 pytest，行为正确——阴性对照）
4env-stuck-loop🔴连续 ≥3 次命令失败且同类错误✅ Steps 20-26 连续 4 次 ModuleNotFoundError（simplejson ×2 / pytz / distutils）
5wide-net-search⚠️find 扫全盘 / 大目录且超时✅ Step 2 扫整个 home 目录 120s 超时
6premature-tool-without-context⚠️首个工具调用引用未验证的 env var / 绝对路径✅ Step 1 cat $TASK_DIR/ca-issue.json——env var 实际未注入
7edit-without-test-scaffold⚠️先改代码后补环境（本 run 有失败测试且最终未过）✅ Step 19 编辑后 Step 20 因环境问题失败——"先跑通 baseline 再动手"更稳
8trajectory-noop🔴≥10 轮但最终 patch 为空✗ 未命中（该轨迹成功交付）
命中统计：该真实轨迹触发 6 warning + 1 error，8 条规则抓出 6/8 = 75% 的形式问题。 注意两条"未命中"的价值——它们是阴性对照，证明规则不是见谁咬谁。 而 Step 1（假设 $TASK_DIR 存在直接失败）与 Step 2（扫全盘找文件）连起来看，就是第一讲 L1 元决策层缺了"先确认工作目录"这个动作——lint 规则与过程模型互相印证。
素材：wiki/40 §1-§3 案例轨迹：experiments/marshmallow-1359

第四篇 · 三件套互补：lint · detector · PRA 怎么配合

第四篇 · 分工与落地（1 张互补表 + 3 层实现路径）
全单元收口：四种评估工具各守一层，谁也不替代谁。
第 4 讲 · 1 互补表 + 3 层路径

linter 是流水线门票，detector 是质量评测，PRA 是综合评分

维度Lint（形式）Detector（语义）PRA（综合）
输出违规列表（step + 消息 + 修复建议）分类计数 + 逐类证据0-100 综合分 + 评级
速度毫秒级秒级（启发式）到分钟级（LLM）分钟级
LLM 依赖0可选（启发式 / LLM / hybrid）可选（W3 单点 judge）
用途流水线门票（轨迹入库前必须 lint 通过）质量评测（详情页深挖）综合 verdict（评分卡）
报告对象CI 门禁分析工作台训练数据筛选 / 人工复核
实现路径：从 1-2 天的 CLI 到 1-2 周的 auto-fix
  • L1（1-2 天）：rule pack + 单独 CLI——python -m trajectory_lint run --trajectory X --format json，输出 ESLint 风格报告
  • L2（3-5 天）：接入 detector_registry——@register_lint 装饰器 + S7 末尾自动跑 + --max-errors 0 卡 CI
  • L3（1-2 周）：auto-fix + 平台集成——修复建议经人确认后应用；Web 详情页加 Lints 标签；跨轨迹统计规则命中率当训练信号
为什么大规模训练特别需要它：MegaFlow 的 200 万+ 次执行、SWE-Universe 的 50 万条轨迹 / 30B token——所有大规模 agent 训练都需要廉价的轨迹质量筛。 LLM 级筛选每条都要花钱，lint 级筛选毫秒级免费：在昂贵的 rejection sampling 之前先用 linter 砍掉低质量轨迹， 等价于训练集清洗的初筛。这正是"形式层"在整个评估栈里的生态位。
思考与讨论
  • 五层评估栈里，你所在的团队现在做了哪几层？缺的那层，最便宜的补法是什么？
  • LoopsBench 显示"同模型不同 loop 差 3 倍"——如果你的产品只测过一种 loop，你的评测结论有多脆弱？
  • 给 8 条 lint 规则再设计一条：从你自己的 Agent 使用经历里找一个"机械可判的坏味道"，写出触发条件 + 修复建议。
  • lint 的 --max-errors 0 卡在轨迹入库处 vs 卡在 PR 合并处——两个位置各拦住什么？各放过什么？
素材：wiki/40 §5-§6 延伸：SWE-Universe 论文精读 延伸：MegaFlow 论文精读

收口：整个单元的四讲地图

「轨迹分析与过程评估」单元总结：
  • 第 1 讲（读）：八阶段模型——轨迹有结构，S0-S7 + 两个循环 + 弯路四元组；控制源分布是人机分工的地图
  • 第 2 讲（评）：PRA 量表——100 分五维 + 一票否决；过程×结果矩阵救出"可疑成功"与"可信失败"
  • 第 3 讲（诊）：四分类 + 五工具——两套论文 7 个标签收敛成用户视角；24.88% F1 警示"LLM 裁判不能当唯一可信源"
  • 第 4 讲（纲）：点+线五层栈——线级 25% 天花板与 loop 3 倍差；lint 是毫秒级的形式层门票
一句话：结果对不对交给 harness，过程可不可信交给这套栈——而"过程可信"才是人机协作里人真正要守的那道门。