TraceProbe — coding agent trajectory diagnostics

TraceProbe — coding agent trajectory diagnostics

核心内容

TraceProbe 关注 resolve rate 隐藏的过程证据：两个 agent 都通过测试，并不代表它们以同样稳定、经济、可审计的方式完成任务。它把轨迹规范化成九类 action taxonomy 和 deterministic effect labels，再用 Insight 发现单轨迹反模式（搜索循环、跳过验证等），用 Converge 对齐两条轨迹并比较分歧。

为什么对用户重要

用户关心的 agentic coding / llm-wiki workflow 不能只看“最后有没有产出日报/页面”。如果一次任务靠大量盲搜、重复读取和未验证假设勉强完成，它会在规模化后变成成本和可靠性问题。TraceProbe 给了一个可迁移标准：评估 agent 时要看路径质量，而不是只看终点。

机制 / 一阶原理

最终结果是低维标签；轨迹是高维因果证据。把 heterogenous trace 规范化后，才能跨模型、跨 run 比较：哪些 action 真正接近相关函数/文件，哪些只是 search loop，哪些 validation 被跳过。deterministic labels 的价值是降低 LLM judge 漂移，让评测更像工程 telemetry。

与已有 wiki 的关系

• 更新 Agent-Benchmarks：benchmark 应报告 trajectory health，而不只是 pass/fail。
• 连接 Repository-Exploration：文件级命中太粗，函数级定位和完成行为更能解释 coding-agent 成败。
• 连接 Context-Engineering：好的上下文系统应缩短到达相关上下文的路径，而不是仅提高最终答案质量。

对 Hermes / llm-wiki 的启发

每日雷达可以维护轻量“trajectory score”：是否先 orient、是否检索既有页面、是否读 primary source、是否保存 raw、是否更新 index/log、是否重建 vquery。长期看，这比单次报告长度更能说明知识库维护质量。

失败模式 / 边界

轨迹 taxonomy 可能诱导 Goodhart：agent 为了看起来路径漂亮而减少必要探索。TraceProbe 更适合作为诊断工具，而不是唯一奖励函数；对开放式研究任务，探索冗余不一定是坏事。

写入记录

• 2026-07-08 09:00 CST：基于 arXiv 摘要创建来源页，沉淀 trajectory diagnostics 对 agent benchmark 和 llm-wiki 雷达自评的意义。