Insights Generator：面向 LLM 智能体的系统性语料级轨迹诊断

# 洞察生成器：面向LLM代理的语料库级系统化轨迹诊断  
来源：https://arxiv.org/html/2605.21347  
联系：[email protected]  
Apaar Shanker, Kaustubh Deshpande, Jason Qin, Yash Maurya, Veronica Chatrath, Vijay S. Kalmath, Levi Lentz, Yuan (Emily) Xue  

###### 摘要  

LLM 代理的故障诊断在很大程度上仍依赖人工操作。从业者检查少量执行轨迹，形成临时假设，然后迭代。这种方式会遗漏仅在整个轨迹集合中才显现的模式，且无法扩展到生产级语料库——其中单条轨迹可能包含数万个 token。本文将**语料库级轨迹诊断**问题形式化：给定一个执行轨迹语料库，目标是生成有依据的自然语言洞察，描述跨轨迹组的系统性行为模式，每项洞察均附有支持证据。我们提出**洞察生成器 (IG)**，一个多智能体系统，通过在整个轨迹语料库中提出并测试假设来回答诊断性问题，最终生成一份基于证据的洞察报告。我们从定性和客观两个维度评估 IG，涵盖基于评分标准的报告评估以及通过实施 IG 洞察带来的下游性能提升。使用 IG 报告的人类专家将脚手架性能提升了 30.4 个百分点（相对于未修改的基线），而利用 IG 洞察的编码代理则展现出持续且稳定的增益。在多个基准测试中，IG 的**侦察-调查**架构在检测覆盖率上达到了与竞争方法相当的水平，同时领域专家认为 IG 报告在深度和证据质量方面领先。  

††footnotetext:† 工作完成于 Scale AI。  
††footnotetext:∗ 通讯作者：[email protected]  

## 1 引言  

智能体系统会产生包含推理步骤、工具调用和环境交互的长执行轨迹。调试通常由评估结果驱动——这些结果标记出失败的运行；然后从业者检查一小部分轨迹并形成假设[7 (https://arxiv.org/html/2605.21347#bib.bib2),15 (https://arxiv.org/html/2605.21347#bib.bib13)]。由于评估是针对最终任务结果定义的，它们提供的是聚合信号，而无法揭示中间行为。此外，它们也无法展现更广泛场景中的模式。因此，许多错误、效率低下和性能差异仍然难以识别[7 (https://arxiv.org/html/2605.21347#bib.bib2),11 (https://arxiv.org/html/2605.21347#bib.bib5)]。对于局限在特定输入子集、任务类型或执行上下文的失败尤其如此——这些失败单独来看并不显著到足以明显改变聚合指标。这样的模式对于标准评估是不可见的，除非从业者事先知道要去寻找它们。这些信号中的许多只有在队列层面才会显现。工具使用的系统性差异、重复出现的推理结构，以及与强或弱性能相关的模式，只有在轨迹被集体分析时才能被看到。队列比较是这种分析的一种特别强大的形式：检查沿单一受控轴（如模型变体、提示版本或任务类别）变化的轨迹组，可以隔离出该轴带来的行为差异，并提供比单纯聚合指标更强的针对性诊断信号。  

除了诊断已知的失败模式，还存在对**开放式发现**的独特需求。静默失败——那些降低可靠性但不触发显式错误信号的行为趋势——就是一个关键例子；它们很少出现在评估仪表盘中，需要群体级别的分析才能检测到。我们将此类发现称为**轨迹洞察**：有依据的自然语言陈述，描述跨轨迹组的显著模式，每条陈述都有轨迹级别的证据支持。例如，一个典型的 IG 洞察可能是：  

> 84% 的使用 Python 但结果错误的轨迹表现出“静默计算失败”：代码执行无误，但实现了错误的数学模型。交叉检查未能捕获这些错误，因为它是在错误框架内验证内部一致性，而不是挑战框架本身。在 94/112 条使用 Python 但错误的轨迹中观察到（占所有轨迹的 37.6%）；19 条交叉检查轨迹中无一检测到建模错误。  

在语料库规模上浮现轨迹洞察面临两个挑战。  

**规模和复杂性**：轨迹语料库通常超过任何单个模型的上下文窗口。单条轨迹交织着数千个 token 的推理、工具调用和环境状态。我们感兴趣的模式——静默失败、系统性低效、队列间的行为差异——是语义层面的，无法归结为关键词匹配或预定义分类[3 (https://arxiv.org/html/2605.21347#bib.bib7),13 (https://arxiv.org/html/2605.21347#bib.bib8)]。先前的工作通过单轨迹调试[27 (https://arxiv.org/html/2605.21347#bib.bib11),10 (https://arxiv.org/html/2605.21347#bib.bib12),2 (https://arxiv.org/html/2605.21347#bib.bib6),7 (https://arxiv.org/html/2605.21347#bib.bib2)]、固定失败分类下的分类[4 (https://arxiv.org/html/2605.21347#bib.bib4),11 (https://arxiv.org/html/2605.21347#bib.bib5),24 (https://arxiv.org/html/2605.21347#bib.bib17)]、基于结果的分类[16 (https://arxiv.org/html/2605.21347#bib.bib26)]，或把轨迹视为次要的以脚手架为中心的分析[9 (https://arxiv.org/html/2605.21347#bib.bib28)]来处理该问题的片段，但没有一种方法直接在轨迹语料库上执行迭代模式发现。  

**没有评估标准**：轨迹洞察是关于群体行为的自由形式断言；这样的断言是否正确、是否基于引用的证据、是否对下游从业者有用，无法简化为单一现有指标，也没有共享的方法论被提出。  

我们提出**洞察生成器 (IG)**，这是一个通过迭代的、假设驱动的聚合来处理轨迹语料库来解决第一个挑战的系统：它将一个开放式的诊断问题分解为可测试的假设，在语料库规模上验证每个假设，并综合出有证据支持的发现。我们做出以下贡献：  

- •**迭代式语料库级轨迹分析**。IG 将假设生成与语料库规模验证分离，所有轨迹访问和处理都通过一个有状态的 Python 层进行路由，从而实现了“分解-假设-验证”循环，该循环可处理超过任何单个上下文窗口的语料库。这能浮现出单次遍历和单轨迹方法遗漏的模式，如上述静默计算失败（第 2 节 (https://arxiv.org/html/2605.21347#S2)）。  
- •**洞察评估框架**。我们引入一个四场景框架，该框架改变谁进行评估（校准的 LLM 法官 vs. 人类专家）以及衡量什么（报告质量 vs. 下游脚手架影响），并将其应用于多个基准测试上的各种轨迹分析系统。排名在四个场景中一致，为比较语料库级轨迹诊断系统提供了第一个系统性基础（第 4 节 (https://arxiv.org/html/2605.21347#S4)）。  
- •**可衡量的从业者影响**。使用 IG 报告的领域专家将脚手架性能提升了 30.4 个百分点（相对于未修改的基线），几乎是次优分析系统 16.2 个百分点增益的两倍。这一差距与 IG 在自动评估中在证据深度和机制解释方面的高分一致，并证实了诊断质量直接转化为从业者有效性（第 4.2 节 (https://arxiv.org/html/2605.21347#S4.SS2)）。  

参见图标题  

图 1：洞察生成器 (IG) 系统概览。**左**：输入层提供诊断问题 QQ、轨迹语料库 C\mathcal{C} 和处理后的数据存储 S\mathcal{S}。**中**：Orchestrator 分派 Scout 智能体（H\mathcal{H}：对采样轨迹提出假设）和 Investigator 智能体（H∗\mathcal{H}^{*}：通过语料库级队列比较进行验证）。Investigator 分析 H∗\mathcal{H}^{*} 以生成发现 Fr\mathcal{F}_{r}，并将其发送给 Orchestrator。Orchestrator 随后综合并去重 Fr\mathcal{F}_{r} 以生成最终报告。**右**：输出是一份带有发现、修复、引用和流行率估计的基于证据的报告。**底**：共享工具层。算法 1 (https://arxiv.org/html/2605.21347#alg1) 形式化了分析循环。  

## 2 相关工作  

##### 单轨迹错误分析。  

大多数现有代理调试工作侧重于单个轨迹分析。许多此类方法使用反事实回放来隔离失败原因：AgentDebug[27 (https://arxiv.org/html/2605.21347#bib.bib11)] 推理可选决策点，AgenTracer[22 (https://arxiv.org/html/2605.21347#bib.bib14)] 注入程序化故障并重新执行，DoVer[10 (https://arxiv.org/html/2605.21347#bib.bib12)] 通过针对性干预回放轨迹来验证失败假设。AgentRX[2 (https://arxiv.org/html/2605.21347#bib.bib6)] 借鉴软件验证技术，从工具模式推断结构化约束，并检查代理行为是否满足这些约束。另一条补充线在预定义分类下对已知失败类型进行分类（MAST[4 (https://arxiv.org/html/2605.21347#bib.bib4)], AgentFail[11 (https://arxiv.org/html/2605.21347#bib.bib5)], Who&When[24 (https://arxiv.org/html/2605.21347#bib.bib17)]），但这种方法无法浮现分类未预见的故障模式。即使使用这些方法，每条轨迹的诊断仍然困难：TRAIL[7 (https://arxiv.org/html/2605.21347#bib.bib2)] 提供了一个全面的跨轨迹标注错误数据集，但最佳模型仅达到 11% 的联合准确率。这些以轨迹为中心的方法擅长单个修复，但会遗漏仅在代理运行语料库中出现的系统模式，而这正是我们语料库级方法所要填补的空白。  

##### 智能体洞察生成。  

最近的工作利用了基于智能体的分解技术，从代理执行轨迹中浮现洞察。Trace2Skill[16 (https://arxiv.org/html/2605.21347#bib.bib26)] 分派一个扁平并行的分析子智能体群组到批处理轨迹上以识别技能补丁，然后执行层次化整合，将单个补丁合并成一个无冲突的技能目录，供代理在推理时使用。HALO[5 (https://arxiv.org/html/2605.21347#bib.bib25)] 采用递归语言模型[21 (https://arxiv.org/html/2605.21347#bib.bib27)]，通过搜索、查看、计数和代码等工具分析轨迹，并在相关片段上递归调用自身，生成诊断报告交给下游编码代理以进行 harness 修复。相比之下，IG 的不同之处在于其智能体角色的分配和保持一个有状态的数据处理层。首先，IG 使用类型化的假设生成和验证角色，而不是扁平或递归分解，将广度（样本级模式提出）与深度（语料库级统计验证）分离。其次，IG 所有轨迹访问都通过一个结构化的 Python 数据处理层路由，因此发现反映的是语料库级分布而非单轨迹观察。  

##### 代理优化框架。  

几项近期工作将智能体改进构建为自动化优化任务。VeRO[19 (https://arxiv.org/html/2605.21347#bib.bib22)] 引入了用于“代理优化”的评估框架：一个编码代理迭代修改目标代理的实现、提示、工具和编排逻辑，并根据其在固定基准测试上的提升进行评估。AFlow[23 (https://arxiv.org/html/2605.21347#bib.bib23)] 和 ADAS[8 (https://arxiv.org/html/2605.21347#bib.bib24)] 类似地探索了基于“代理即代码”表示的自动搜索。Meta-Harness[9 (https://arxiv.org/html/2605.21347#bib.bib28)] 将整个诊断-提出循环委托给一个单一的编码代理提出者，该提出者通过文件系统读取所有先前候选的源代码、分数和执行轨迹，刻意避免单独的角色分解。这些系统将代理视为一个待改进的人工制品，目标是在特定评估集上表现更好。我们的工作是互补的：IG 不是针对固定目标优化代理，而是浮现轨迹语料库中潜藏的行为洞察，包括任何预定义目标都不会针对的模式。这些洞察随后可以在闭环中被代理优化框架使用。  

## 3 洞察生成器  

### 3.1 系统概览  

洞察生成器 (IG) 是一个多智能体分析系统，用于发现和验证大型轨迹语料库中的行为模式，而无需将原始轨迹完全加载到上下文中。该系统的动机来自代理调试中的一个实际瓶颈：手动检查少量轨迹可能足以形成假设，但不足以在规模上验证这些假设。IG 通过将假设发现与假设验证分离，并将所有分析通过一个 Python 数据处理层路由（而不是将原始轨迹内容直接传递给 LLM 上下文）来解决这一问题。智能体仅通过可调用的工具（摘要、提取、队列比较）与轨迹交互，这些工具只向模型上下文返回聚合结果。图 1 (https://arxiv.org/html/2605.21347#S1.F1) 展示了系统及其三区结构；算法 1 (https://arxiv.org/html/2605.21347#alg1) 形式化了多轮循环。  

### 3.2 任务定义  

**洞察生成器 (IG)** 任务以一个代理执行轨迹语料库 C={τ1,…,τn}\mathcal{C} = \{\tau_{1},\dots,\tau_{n}\} 作为输入，其中每条轨迹由交错的输入、推理步骤、工具调用、环境观察和输出组成。轨迹可选地包含元数据，如任务特定模型输入、结果标签、配置变体或时间戳。目标是产生一组语料库级洞察，描述 C\mathcal{C} 子集上的显著行为模式。当有标签可用时，洞察可能描述队列之间的系统性差异（例如，成功与失败）。没有标签时，任务退化为轨迹群体的无监督模式发现。所有洞察必须由轨迹级证据支持。  

### 3.3 智能体角色  

IG 包含三个智能体角色。我们使用一个**Orchestrator**，它协调分析，是唯一面向用户的智能体。它将分析目标分解，并行分派子智能体，评估各轮次发现的充分性，并综合最终报告，期间进行最少的直接轨迹检查以保留上下文容量用于协调。**Scout 智能体**使用 LLM 驱动的摘要和提取工具探索一个代表性的轨迹样本，根据发现的初始模式提出候选假设；其目标是广度，生成多样化可测试的假设，而非执行验证。**Investigator 智能体**接收一个特定假设，并在语料库规模上进行验证，使用 LLM 提取和程序化分析工具计算分布统计量，执行队列比较，并返回一个标记为“已确认”、“已反驳”或“不确定”的发现及定量证据。每个角色的系统提示在附录 A.1 (https://arxiv.org/html/2605.21347#A1.SS1) 中提供；模型选择、温度设置和上下文配置在附录 A.2 (https://arxiv.org/html/2605.21347#A1.SS2) 中。  

### 3.4 数据预处理  

所有智能体都基于一个处理后的轨迹存储