过程分析 · 问题分类 · 第 3 讲
问题 step 分类学：无用 · 冗余 · 低效 · 错误
一条 Agent 轨迹里不是每一步都在创造价值：读了不相关的文件、同一个命令反复执行、改完又改回去、工具调参数调错…… 怎么给这些"问题 step"一个统一的说法？这一页把两篇论文的两套分类—— AgentDiet 的 useless / redundant / expired 与 RedundancyBench 的 abnormal / duplicated / incorrect / exploratory—— 收敛成用户视角的四个大类，配上本仓 5 个分析工具的选择决策树， 并用一条真实轨迹的消融数据回答一个扎心的问题：让 LLM 当裁判判"哪步是浪费"，它判得准吗？（步级 F1 只有 24.88%）
概览
4
问题大类（用户视角）
2
论文分类体系
5
本仓分析工具
24.88%
LLM 判冗余的步级 F1 上限
| 项目 | 说明 |
|---|---|
| 本卡定位 | 「轨迹分析与过程评估」单元第 3 讲 · 学会诊断轨迹（问题视角 + 工具选择） |
| 前置知识 | 八阶段模型与弯路（trajectory-1-reading）；PRA 量表（trajectory-2-pra） |
| 读完会什么 | 拿到一条轨迹的"问题 step 清单"，能按四分类归位、说清两套论文定义的差异；面对"我想查 X 类问题"能直接选出该跑哪个工具；理解"LLM judge 不能当唯一可信源"的工程含义 |
| 真实数据 | 本仓 experiments.db 已有 49 条多方法消融洞察 + 5760 行步骤标注；本页第 4 篇用的消融案例全部可复现 |
第一篇 · 四大类：用户视角的统一入口
第 1 讲 · 1 张总表
无用 / 冗余 / 低效 / 错误：两套论文定义在四个格子里的对照
| 大类（用户视角） | AgentDiet 定义（FSE 2026） | RedundancyBench 定义（2026.05） | 关键差异 |
|---|---|---|---|
| 无用 | useless：信息根本不相关（读 5000 行文件只用 50 行；读与 bug 无关的文件） | exploratory：探索性调用，未直接贡献最终目标 | AgentDiet 看"读了不相关"；RB 看"探了但没用上"——边界模糊 |
| 冗余 | redundant：信息重复出现（编辑参数在工具结果里又重复一遍） | duplicated：与历史 step 完全一致（同工具 / 同参数 / 同输出） | AgentDiet 看"信息出现多次"；RB 看"step 整体重复"（范围更窄） |
| 低效 | expired：曾有用但已过时（view 后紧跟编辑，view 已过期） | （无直接对应；exploratory 部分 + 漫游） | "过期"视角是 AgentDiet 独有；项目里用 PRA D5 补漫游维度 |
| 错误 | （无独立类） | abnormal：tool call 失败异常；incorrect：调用与任务无关或参数错 | 错误类是 RB 独有的研究空白填补——AgentDiet 不覆盖 |
核心洞察：冗余类覆盖最完整（两篇论文都关注、工具最成熟）；错误类是 RB 独有；低效类是边界模糊区（靠 expired + 漫游两个视角拼起来）。
项目策略：不硬合并两套标签（语义边界模糊，硬合并会丢信息）——保持各工具独立输出，在 Web 端做对照展示，冲突本身是信息。
第二篇 · AgentDiet：三类浪费与滑动窗口 LLM 反思
第 2 讲 · 3 类 + 1 算法
useless / redundant / expired：从 100 条真实轨迹里提炼的浪费本体
问题背景（为什么"删浪费"值钱）
- Agent 轨迹单 issue 平均 48.4K token / 40 步，累计约 1M token
- Claude 4 Sonnet 在 OpenRouter 上 99% 的 token 是输入轨迹——越到后面，历史越长、越贵、越慢
- KV Cache 消除不了问题：仍然要计算、仍占显存与 I/O
三类浪费的定义与典型场景（论文基于 100 条 Trae Agent × Claude 4 Sonnet 实证）
| 类别 | 定义 | 典型场景 |
|---|---|---|
| useless | 信息根本不相关，可安全删除 | __pycache__ / .egg-info / make verbose 输出 / 打开 5000 行文件只读 50 行 |
| redundant | 信息重复出现，删副本不丢信息 | 编辑调用的 new_str 在工具结果里又重复一遍；之前已检索过的内容再检索一次 |
| expired | 曾有用但已过时 | grep 找根因时打开多个文件，找到后其余文件作废；view 后紧跟编辑，view 已过期 |
方法：滑动窗口 LLM Reflection（Algorithm 1）
参数: a=2 延迟步数 · b=1 上下文窗口 · θ=500 token 阈值
for s in range(a, len(steps)):
target = steps[s - a] # 延迟评估的目标步
ctx = steps[max(0, s - a - b) : s] # 它之后的上下文
waste = LLM_reflect(target, ctx) # 4 段式 prompt 判定三类浪费
if waste.tokens > theta: # 浪费量超阈值才计入
record(target, waste.category, waste.tokens)
# prompt 4 段: 高阶任务 → 输入输出格式(XML) → 三类浪费的例子 → 防信息丢失 guideline
必读论点（论文 §2.3.2）：LLM 不知道何时该做轨迹压缩——必须由外部强制反思模块触发，不能依赖 LLM 自决。
这是 AgentDiet 的架构基石：靠 Agent"自己觉得该省了"是靠不住的，省钱必须是 harness 的制度设计。
实测效果：input token ↓39.9%–59.7%，总成本 ↓21.1%–35.9%，agent 性能持平。
素材：wiki/38 §2
工程落地：agent_diet_analyzer
第三篇 · RedundancyBench：检测本身是难题
第 3 讲 · 4 类 + 1 警示
图 1 · RedundancyBench 步级 F1：最强的 Window-to-One 也只有 24.88%，部分方法差于随机猜测。红条为最佳方法。
abnormal / duplicated / incorrect / exploratory + F1 天花板
| 类别 | 定义 | 典型场景 |
|---|---|---|
| abnormal | tool call 失败（异常情况） | 网络错误 / Service unavailable |
| duplicated | tool call 与历史 step 完全一致 | 同一个 get_reservation_details() 调两次 |
| incorrect | tool call 与任务无关或参数错误 | 取消航班却查流量；未拿到 user_id 就调 user-info 工具 |
| exploratory | 探索性但未直接贡献最终目标 | 用户要 FA-1003，agent 同时查 FA-1002 和 FA-1003——查 FA-1002 算 exploratory |
标注有多贵：200 条成功轨迹 × 8000+ 步
论文的标注 pipeline：3 轮标注——3 条启发式规则自动预标注 → 6 位 AI agent 专家人工校验（每条约 1 小时） → 交叉验证 + 共识迭代。真值本身就很贵。
关键发现：3 种判定方法的步级 F1
24.88% 意味着什么（工程上最重要的一页）：
即使最强 LLM + 整条轨迹 + 反事实推理，自动检测冗余 step 的能力也远低于人类。
三条设计结论直接写进了本仓 redundancy_detector：
- LLM judge 不能作为唯一可信源——必须有启发式兜底（默认 mode=heuristic，0 LLM 成本）
- 启发式优先 + LLM 兜底 + 双写审计——LLM 判定只入 JSON 落盘（带完整 provenance），不入数据库"可信表"
- 同轨迹多方法对照——把启发式 / LLM / hybrid 的结果并排呈现，由人判断（下一篇的消融案例就是实例）
素材：wiki/38 §3
工程落地：redundancy_detector
第四篇 · 真实数据：同一条轨迹，五种判定
第 4 讲 · 1 消融 + 1 决策树
图 2 · 同一条 144 步轨迹的 5 份判定（experiments.db 实验 20 实测）：蓝=启发式冗余，红=LLM 冗余，橙=AgentDiet 浪费率。all_to_all·LLM 判 61 步冗余（abnormal 14 / duplicated 27 / exploratory 14 / incorrect 6），window_to_one·启发式只判 1 步。
图 3 · 五工具决策树：先问"要什么"，再选工具——同一条轨迹可以被多个工具同时分析，结论不一致时不仲裁、并排呈现。
案例：django__django-11133（144 步）的 5 份判定书
本仓 experiments.db 的实验 20（django__django-11133，144 步轨迹）被 5 个分析通道各判了一次——同一条轨迹，冗余率从 0.7% 到 42.4%：
怎么读这 60 倍的差距：不是"谁对谁错"，而是方法视野不同——
启发式只抓机械可判的重复（same tool / same params）；LLM 用全局语义判"这步对最终目标有没有贡献"。
结合上一篇的 24.88% F1 警示，正确的消费姿势是：两份结果都看，把分歧点当作"需要人来看一眼"的信号，而不是赌一边。
另一个案例（实验 1，sympy__sympy-21614，38 步）：AgentDiet 判浪费率 22.6%（8500/37569 字符全是 useless 类），评分 77.4 / B 级——"大部分步骤有效，但两成内容白读"是很多轨迹的常态。
工具选择决策树（按问题反向选）
flowchart TB
Q["我想分析一条轨迹里的问题 step"] --> A{"想要什么？"}
A -->|语义级浪费 解释| T1["agent_diet_analyzer
LLM reflection · useless/redundant/expired
无 LLM key 自动降级启发式"] A -->|step 级冗余 异常| T2["redundancy_detector
4 类全覆盖 · 默认 heuristic 零成本
可选 llm / hybrid 双写审计"] A -->|综合可靠性 评分| T3["agent_process_evaluator（PRA）
七维 100 分 · 一票否决
见第 2 讲"] A -->|只要数字 快| T4["trajectory_analyzer
纯启发式 7 规则 · 0 LLM 成本 · 秒级"] A -->|给每步加可读描述| T5["step_annotator
不分类 只描述 · 喂给其他工具当 context"]
LLM reflection · useless/redundant/expired
无 LLM key 自动降级启发式"] A -->|step 级冗余 异常| T2["redundancy_detector
4 类全覆盖 · 默认 heuristic 零成本
可选 llm / hybrid 双写审计"] A -->|综合可靠性 评分| T3["agent_process_evaluator（PRA）
七维 100 分 · 一票否决
见第 2 讲"] A -->|只要数字 快| T4["trajectory_analyzer
纯启发式 7 规则 · 0 LLM 成本 · 秒级"] A -->|给每步加可读描述| T5["step_annotator
不分类 只描述 · 喂给其他工具当 context"]
思考与讨论
- 图 2 里启发式与 LLM 判定差 60 倍——如果你是训练数据筛选员，用哪份结果筛轨迹？说明理由（提示：误删好步骤 vs 漏掉坏步骤，代价不对称）。
- "expired（过时）"类在 RedundancyBench 里没有对应——找一个你自己的例子：哪一步"当时有用、后来作废"？该在它作废的瞬间删掉，还是保留作审计证据？
- 为什么不把 5 个工具合并成一个"超级分析器"？说出至少两条架构理由。
素材：wiki/38 §5-§6
下一篇：点+线与 Linting
收口：从"读轨迹"到"开药方"
一页总结：问题 step 四分类（无用=读了不该读 / 冗余=做了重复的 / 低效=做了过时的 / 错误=做错了的）
统一了两篇论文的 7 个标签；压缩（AgentDiet）与检测（RedundancyBench）是两个不同的问题，一个工具的输出不能当另一个的真值；
24.88% 的 F1 天花板决定了"启发式优先 + LLM 兜底 + 双写审计"的工程姿势；真实消融数据（0.7% vs 42.4%）提醒我们：判定分歧本身就是信息。