当代理实现系统时：缺陷、检测与评估严谨性的案例研究

# 当代理实现系统时：关于缺陷、检测与评估严谨性的案例研究
来源：https://arxiv.org/html/2609.01985  
\\workshoptitle  
机器学习系统  
###### 摘要  
随着大型语言模型编码代理越来越多地执行端到端工程工作而非单一功能的代码补全，我们缺乏对它们在实现真正*系统级*要求时的行为进行实证描述的能力：这些要求包括存储模式、并发与异步编排、跨进程配置正确性以及检索过滤精度权衡。本文呈现了一项LLM编码代理实现多组件数据系统（包括持久化图存储、带过滤的向量索引、异步摄取管道和实时可视化客户端）的案例研究，该系统基于一份详尽的预先存在的规范构建——存储技术、模式、实体解析算法和检索过滤策略均已事先固定；代理的自主性体现在实现过程中，在诊断和修复其在构建规范过程中引入的缺陷时，以及在与规范未明确规定的交互设计决策中。在一次延长的会话中，我们记录了五个此类缺陷，每个缺陷根据其违反的系统约束类型以及是被自动化测试捕获还是仅通过经验探测（渲染截图、计时测量）而非类型级或静态签名发现来进行分类。我们进一步在公开的多跳问答基准测试（HotpotQA，干扰项设置）上评估了该架构中指定的一项检索权衡——在排序前将候选项限制为图识别的实体集，与未过滤的语义搜索——重用基准测试的黄金证据标签作为实体识别的替代（我们在本次会话中未获得LLM访问权限来运行该识别）以及标准的信息检索召回指标，而非基准测试自身的答案准确度指标。对于k∈{1,3,5,10}，在针对包含2,994个段落的合并语料库的n=100个问题中，过滤后的召回率在k=3时达到1.0——一旦候选项被限制为黄金标题段落本身，这是预期的——而未过滤的搜索即使在k=10时也仅恢复了69%所需证据，这一差距在每个k值上都保持不变（符号检验，p<10⁻⁴）。最后，我们坦率地讨论了代理自主性成功与需要人类纠正之处的对比，包括一个声称的性能修复从未在引发该修复的回归上重新测量的实例——一个在本次自报开发循环中，没有任何机制能够捕获的未经验证的工程声明。

## 1引言  
LLM编码代理越来越多地被部署用于开放式、多文件的工程工作，而非孤立的代码补全：实现数据模型、连接异步作业队列以及调试仅在运行时显现的故障。现有的代理编码评估主要评分代理是否解决现有代码库中预定义的、有限的问题[4]，而现有的结合推理与工具使用（检索、代码执行）的代理架构则在任务成功率上进行评估[5]。这两种场景都未能捕捉到一种不同的失败模式：代理被给予一个多组件系统的详细规范，跨越多个文件和管道阶段进行端到端构建，并在过程中引入——然后不得不诊断和修复——其自身的系统级缺陷。这将相关的评估问题从“生成的函数是否通过其单元测试”转变为“代理在系统工程师实际面临约束下实施系统工程时是否表现可靠”——跨多个调用点共享模式的一致性、重复执行下幂等存储操作的正确性、无论哪个进程启动都必须一致解析的配置的可靠性，以及检索过滤中的精度权衡。当目标是明确定义的优化问题（如学习芯片布局）[6]时，ML驱动的系统设计拥有良好的记录；我们的案例研究则关注针对一个本身固定且详尽的规范的实现可靠性——代理在构建过程中是否引入并能自我纠正系统级缺陷。

我们报告一项观察性案例研究：一个LLM编码代理（Claude，通过CLI编码工具操作）针对一份详尽的预先存在的规范（第2节）端到端地实现了一个多组件数据系统——持久化、模式驱动的图存储；基于元数据的向量索引过滤；异步多阶段摄取管道；以及力导向图可视化客户端。在会话过程中，代理自身引入了五个缺陷，后来被诊断和修复，或由代理主动修复，或响应用户报告的症状。我们将此转录记录视为数据：我们将每个缺陷按其违反的系统约束（可靠性、正确性、一致性或效率）以及实际被发现的方式（自动化测试 vs. 经验/视觉探测）进行分类。然后我们评估该架构中一个指定的工程权衡——在排序前通过图识别的实体集过滤检索候选项，与未过滤的语义搜索——在公开的外部基准测试上进行量化，而非案例研究系统最初开发所针对的内部语料库。

我们明确说明本文*不是*什么：图引导的检索过滤并不新鲜——它在检索增强生成和GraphRAG文献中已有确立[2,3]。贡献在于第3节的缺陷目录；第4节的基准测试是一个可复现的说明，展示了一个指定的权衡，而非一项新的检索技术。

贡献：（1）一个包含五个系统缺陷的目录，这些缺陷在规范指导的实现过程中引入，后由实现代理诊断和修复，按约束类型和检测方法分类；（2）一项外部基准评估，包含显著性检验和k值扫描，针对该架构中一个指定的检索过滤权衡；（3）坦率讨论代理自身表现出的评估严谨性差距——声称修复却未重新测量其针对的回归——以及这对信任自主代理的自我报告工程声明意味着什么。

## 2案例研究系统与方法论  
目标系统是一个多组件数据管道，与系统评估相关的有四个部分，独立于其应用领域：（i）一个图存储（嵌入式关系数据库、全文模糊查找、递归多跳遍历查询、预写日志并发性），与先前的异构图部署属于同一图系统家族[7]；（ii）一个带基于元数据的候选项过滤的向量索引；（iii）一个异步摄取管道（多阶段提取/解析/嵌入/链接，通过任务队列编排），要求在重复执行下是幂等的，这与为图数据库整体解决的摄取可扩展性问题相同[9]；以及（iv）一个力导向图渲染客户端，与先前的可解释性工具属于同一图形可视化领域[8]。

一份预先存在的设计文档固定了存储技术、模式、实体解析算法和第4节评估的检索过滤策略；留给代理的是实现本身、它引入的缺陷（第3节）以及超出强制技术选择的交互设计细节。本文的方法论是观察性的：我们记录每个缺陷，附有直接可归因的代码差异和在开发或后续使用中显现的可观察症状、导致其根本原因的诊断路径以及修复方案，仅利用会话中已产生的工件（代码差异、测试输出、截图、计时），而非预先决定的协议。

## 3观察到的缺陷，按系统约束分类  
表1（https://arxiv.org/html/2609.01985#S3.T1）总结了五个缺陷，跨越四个系统约束；两个实例同属正确性类别，但表现于不同层面（存储层幂等性 vs. 渲染时视觉输出）。我们在下面讨论最具启发性的两个。

表 1：实现过程中引入和修复的缺陷，按每个缺陷违反的约束以及实际被检测的方式分类。**一致性缺陷，跨调用点重复出现**。图遍历组件在扩展节点邻域时仅遵循出边，而一个为同一节点收集边的单独函数则返回双向边。结果：一条边的端点节点可能从未包含在传递给下游消费者的节点集中。这对于类型系统和现有测试套件（它们断言返回的边，而非节点/边的一致性不变量）是不可见的，仅在不相关的客户端（一个力导向渲染库）中表现为运行时崩溃，原因是其节点数组中缺少链接的端点节点。在明确该不变量并直接测试之前，这种模式在第二个调用点（暴露相同操作的HTTP端点）被独立地重新引入。**渲染正确性缺陷，仅通过视觉捕获**。画布标签大小设为max(c, b/s)，其中b为屏幕常数，s为当前缩放级别，c为下限，旨在实现缩放不变的文字大小。下限破坏了预期的抵消：一旦s超过b/c，下限值会在渲染时再次乘以缩放变换，产生充满屏幕的文字。任何静态检查都无法捕获此问题：它纯粹是运行时视觉效果，没有渲染一帧并测量像素之外的失败断言。它仅在其他不相关的交互测试中通过自动截图对比被发现。

## 4指定的检索权衡：外部基准评估  
案例研究架构精确规定了一项检索权衡，足以进行外部基准测试：在排序前将向量检索候选项限制为图识别的实体集（*过滤*），vs. 仅通过嵌入相似度对整个语料库进行排序（*未过滤*，标准RAG设置[2]）——过滤利用结构信息缩小搜索空间，符合图增强检索的精神[3]，代价是依赖于正确的上游实体识别。

我们在HotpotQA（干扰项设置）[1]上评估这一决策，这是一个公开的多跳问答基准测试，其干扰段落专门构建为与黄金证据在词汇上相似，使其成为对此权衡的天然压力测试。我们强调*这项评估不是*什么：我们不复现HotpotQA自身的基准任务或其已发布的答案EM/F1和支撑事实EM/F1指标，我们的数字与该数据集的任何排行榜条目都不可比。我们仅重用其原始段落和黄金支撑事实标签作为更窄、标准信息检索问题的依据：给定一个固定语料库和一个固定嵌入器，将候选项限制为已知相关实体集是否会改变检索器是否呈现黄金证据段落？

我们将300个随机抽样验证问题（共2,994个段落）的上下文段落合并到一个共享语料库中，使用每个段落的维基百科文章标题作为其实体标识符（无需LLM提取：HotpotQA段落构造上是单实体的）。这300个问题中的前100个作为我们的评估集，因此每个评估问题的干扰压力来自完整的2,994段落库，而非仅其自身的10个上下文段落。对于每个评估问题，我们比较*未过滤*条件（基于整个语料库余弦相似度的前k个最近段落）和*过滤*条件（候选项限制为标题在问题黄金支撑事实标题集中的段落——作为正确功能的上游实体识别阶段的替代——然后在该限制集内按相似度排序）。

我们报告k∈{1,3,5,10}时的召回率@k，基于HotpotQA标注的支撑事实段落（表2 https://arxiv.org/html/2609.01985#S4.T2），即恢复*两个*黄金段落的问题比例（精确匹配），以及配对问题级召回差异的双侧精确符号检验。我们在本次会话中没有LLM访问权限来运行完整的实体识别阶段；黄金标题替代隔离了检索过滤决策本身，与实体识别质量清晰分离，我们指出这是将这些数字推广到全自动管道的主要威胁。

k=1 k=3 k=5 k=10  
平均召回率@k，未过滤 0.420 0.685 0.765 0.845  
平均召回率@k，过滤 0.500 1.000 1.000 1.000  
精确匹配，未过滤 0.000 0.410 0.540 0.690  
精确匹配，过滤 0.000 1.000 1.000 1.000  
符号检验 p（配对，按问题） 3×10⁻⁵ 3×10⁻¹⁸ 3×10⁻¹⁴ 9×10⁻¹⁰  
表 2：检索证据恢复，n=100 HotpotQA验证问题，包含2,994个段落的合并语料库（解释见正文）。表2中的两个结果具有信息量；其余几乎从设计上同义反复得出：过滤后的候选项池恰好是两个黄金标题段落，根据构造它们始终存在于语料库中，因此任何k≥2都能恢复它们，无论排序质量如何。*非*由构造保证的结果是（a）过滤后召回率@1=0.500，其中2段落池内的排序仍然重要，以及（b）未过滤条件的不足，即使更大的预算也未能弥补：精确匹配在k=10时仅达到69%——是过滤条件已达到100%的k=5结果的两倍预算——并且每个符号检验都拒绝无配对差异的原假设，p<10⁻⁴。这种持续的未过滤不足，而非过滤上限，才是发现：主题相似但错误实体的证据在纯相似度排序下挤出了正确证据，而更多检索预算也无法修复它。

## 5讨论  
自主成功 vs. 需要纠正之处。在五个缺陷中，有两个代理从单一症状诊断出根本原因并应用了结构性修复而非局部补丁——集中化配置路径解析，以及在识别出第二个调用点的相同模式后泛化了端点回填修复。一个相关但未编目的问题（超出表1的五个缺陷）展示了相反模式：可视化客户端的初始设计在每次点击时都重新获取和重新渲染；一个人仅通过交互测试捕获了这一点，因为每个操作局部正确，而故障是涌现的。

**评估严谨性差距**。表1中的并发修复是由一个18块文档的242秒延迟引发的。在并行化受影响阶段后，代理仅在较小文档上验证了修复，报告其有效，但未在引发该修复的回归上重新测量延迟——这是一个在本次自报开发循环中没有任何机制能够捕获的未经验证的工程声明。