Long-Insight：长程轨迹分析平台

背景：当 Agent 轨迹长到无法阅读

当我们让一个带上下文压缩的 Agent 去解决真实的软件工程任务时，它产生的执行轨迹长得超乎预期。对采样的数百条轨迹做统计后可以看到，单条轨迹的平均长度普遍是 128K 上下文窗口的几十倍——最短的一批也在 7 倍上下，最长的能到 50 倍以上。其中最重的一类任务，平均一条轨迹就有 810 万 Token，相当于 128K 窗口的 61.9 倍；采样轨迹中至少 85% 超出了任何模型的上下文窗口。

这意味着两个现实问题：

1. 人无法阅读 — 400+ 轮次的交互日志，无论多么耐心的工程师都无法逐行审阅
2. 模型也无法处理 — 即便是百万级上下文窗口，大多数轨迹仍然放不进去

而这些轨迹里恰恰藏着最值得分析的信息。要用起来，先得有一套工具能读懂这些超长轨迹在做什么。

这就是 Long-Insight 的由来。

核心思路

Long-Insight 解决两个问题：

1. 看不懂 → 将线性轨迹分解为结构化的步骤 DAG，每个步骤都有类型、摘要、父子依赖
2. 放不下 → 智能压缩轨迹，在保留因果结构的前提下减少 60–80% 的 Token

第一部分：轨迹步骤分解

设计思路

• 初始化：创建空的 JSON 文件
• 循环：逐个读取轨迹 turn → 调用 LLM 分析 → 判断"新步骤"还是"续写" → 更新步骤 DAG
• 结束：得到完整的步骤划分 JSON，包含 8 种步骤类型、因果叙述和父子依赖关系

每个步骤被分类为：任务理解、项目探索、环境准备、代码实现、测试验证、问题调试、文档记录、总结规划。

宏观分析

以一条 Sonnet 4.5 在 SWE-bench 上的轨迹为例：

虽然从宏观上看，轨迹整体呈线形结构，但仔细观察就会发现，Agent 并不是简单地"一条路走到黑"。它在不断地进行发散（信息收集）→ 收敛（总结规划）→ 试错（回滚）→ 再执行的循环。

整个轨迹可以划分为六个行为阶段：

第一阶段：环境感知与基线建立（Steps 1–24）

Agent 非常注重测试优先，花费大量精力分析 test_package.py，通过阅读测试代码来反推需求，而不是盲目猜测。

第二阶段：策略调整与重规划（Steps 25–34）

经历了步骤 28 的回滚后，Agent 没有急于再次编码，而是转入"测试发现阶段"，通过非侵入式脚本去探测项目状态。

第三阶段：基础设施建设（Steps 38–51）

在触碰核心算法前，先修复/实现底层依赖，例如 Dimension 类构造方法和工具函数 execute_decomposition_method。

第四阶段：核心算法的逐个实现（Steps 52–79）

这是轨迹中最长的一段。Agent 采用"类比克隆"策略：先攻克最难的基类 PDDP 的 fit 方法，一旦跑通，迅速复制到子类 DePDDP、IPDDP、KMPDDP、BisectingKmeans。每个实现后紧跟单元测试（TDD 模式）。

第五阶段：修复错误（Steps 80–110）

Agent 不仅修复了一个类，而是系统性地遍历所有相关类，在 fit 方法入口处统一添加输入验证逻辑。这展示了 Agent 的 全局一致性（Consistency） 意识。

第六阶段：全量回归与交付（Steps 111–120）

运行全量测试套件（57 个测试用例全过），在真实场景下验证，生成交付文档并提交。

局部结构分析

汇聚结构（Fan-in）

步骤 15（创建 TODO 和 OVERVIEW 笔记）的父亲是 [12, 13, 14] — Agent 在分别查找函数定义、类定义并验证数据加载后，将分散的信息汇聚成一份项目文档。

类似的汇聚模式：

回溯结构（Backtrace）

步骤 28（中断实施并重新审视）— Agent 执行了 git checkout 或 git reset --hard，代表对死胡同的剪枝。Agent 意识到当前路径是错误的，切断分支，退回之前的状态。

第二部分：轨迹压缩

为什么必须压缩？

不同任务类别的 Token 消耗差异巨大：

核心问题：85% 的轨迹超出上下文窗口、过长输入导致评测 LLM 性能下降、API 成本剧增。

压缩策略

核心原则：保留 Agent 决策相关的所有内容，删除系统元数据和冗余信息。

• 删除：uuid、parentUuid、timestamp、sessionId、version 等元数据；toolUseResult（Agent 不可见的系统内部记录）
• 完整保留：Agent 的思考过程、代码输出、工具调用（含代码、参数、Todo List）
• 选择性截断：用户消息截断至 200 字符、工具结果超过 200 字符时截断

压缩效果