（来源：科技行者）
这项由南京大学、快手科技、中国科学院自动化研究所、伦敦大学学院以及中国人民大学共同参与的研究，于2026年4月以预印本形式发布，论文编号为arXiv:2604.11641，标题为"CodeTracer: Towards Traceable Agent States"。感兴趣的读者可通过该编号在arXiv平台上查阅完整论文。
**当你的AI助手悄悄走进了死胡同**
假设你雇了一位助手帮你整理一间乱成一锅粥的文件室。这位助手非常勤快，一直在翻箱倒柜、归类整理，几个小时后你回来一看，文件室还是一团糟。你问他哪里出了问题，他也说不清楚——他只记得自己一直在努力工作，但到底是哪一步的判断出了错，导致后面越整越乱，谁也不知道。
现代的AI代码助手（也就是能自己写代码、改代码、跑测试的那种智能程序），面临的正是这样的困境。这类工具被称为"代码智能体"，它们被用来帮助程序员自动修复软件里的漏洞、优化代码结构、在命令行环境里执行复杂操作。它们能自己搜索代码、读取文件、尝试修改、运行测试，一系列动作做下来，有时候能漂亮地完成任务，有时候却彻底失败——而最糟糕的是，失败的原因往往难以追溯。
研究团队面对这个问题设计了一套叫做CODETRACER的系统，配套建立了一个叫做CODETRACEBENCH的测评数据集，希望回答一个核心问题：当一个AI代码助手失败了，它是从哪一个具体步骤开始走偏的？
**一、AI代码助手为什么越来越难"监督"**
要理解这项研究解决的是什么问题，得先明白AI代码助手是怎么工作的，以及为什么它们出错后这么难以诊断。
一个代码助手在接到任务后，会执行一长串的操作序列。以修复软件漏洞为例，它可能先搜索相关代码文件，然后读取这些文件的内容，分析问题出在哪里，尝试修改某段代码，运行测试看修改是否有效，如果测试失败就再回去调整，如此循环往复。整个过程可能包含几十甚至上百个操作步骤，而且不同的框架（用来组织和驱动AI助手行为的底层架构）生成的日志格式各不相同，有的记录在文本文件里，有的记录在JSON格式的追踪文件里，格式五花八门。
更棘手的是，当任务失败时，现有的评估体系只会告诉你"任务失败"这个结果，相当于只看最终考试分数，不管学生是在哪道题上出了问题。研究人员把这种情况描述为"隐藏的错误链"——一个早期的错误判断会像多米诺骨牌一样，引发一连串后续的错误行为，最终导致任务失败。但从外部只看到最后的失败，却完全不知道是哪块牌倒了之后触发了后面一切。
现有的分析工作要么只能对简单的任务做粗略分析，要么需要研究人员手动检查少量案例，根本无法应对动辄几十步、用了不同框架和不同AI模型的复杂任务场景。
**二、研究者收集了多大规模的"案例库"**
为了系统性地研究这个问题，研究团队首先建立了一个庞大的实验数据库。他们从五个广为使用的软件工程评测基准中收集了AI助手的实际运行记录，这五个基准分别聚焦于不同类型的软件任务，包括在真实的开源软件仓库里修复漏洞（涵盖SWE-bench Verified、SWE-bench Pro、MultiSWE-bench、SWE-PolyBench四个基准），以及在命令行界面执行长期复杂任务（TerminalBench基准）。
每个基准都在四种不同的代码助手框架下运行，这四种框架分别是SWE-Agent、MiniSWE-Agent、OpenHands和Terminus 2，可以把它们理解为四种不同的"工作方式"——有的轻量简洁，有的复杂精密。与此同时，每种框架都搭配了五种顶级AI大模型作为"大脑"，分别是Claude-sonnet-4、GPT-5、DeepSeek-V3.2、Qwen3-Coder-480B和Kimi-K2-Instruct。这样一来，框架和模型的各种组合共产生了7936条原始运行记录。
当然，原始数据难免有各种质量问题，研究团队随后对这些记录做了严格筛选。首先去掉了那些因为超时而没能完成的运行，保留了6511条；接着剔除生成记录不完整或被截断的，剩6109条；再去掉因为运行环境配置出错或任务文件损坏导致结果不可信的，剩5284条；最后还去掉了那些步骤少于10步就成功完成的任务——这类任务太过简单，对研究失败原因没什么价值，最终留下了3326条干净的运行记录。这3326条记录就构成了整个研究的基础数据集，跨越了所有的基准、框架和模型组合。
**三、研究者是如何"审案"的：注释标准与失败链追溯**
有了数据只是第一步，还需要有人一条一条地分析这些运行记录，判断每个步骤是否正确，失败是从哪里开始的。研究团队的成员亲自承担了这项耗时耗力的注释工作。
每位注释人员被分配一组任务，连同这些任务在所有15种框架与模型组合下的完整运行记录一并处理。注释人员拿到的资料包括任务说明书、参考解决方案，以及必要时可以直接进入运行环境手动验证的权限。这种安排确保每个人都能对同一个任务产生深入的理解，也便于横向比较不同的AI助手在面对同一个问题时的行为差异。
注释工作分为两大类。对于成功完成任务的运行记录，注释人员需要标出哪些步骤是"冗余步骤"（做了某件事但效果与之前的步骤完全重叠），哪些是"反复试错步骤"（做了某件事但后来被覆盖或撤销了）。对于失败的运行记录，注释人员采用了一种叫做"链式逆向追溯"的方法——从最终的失败测试结果出发，向前追问：是哪个步骤的操作或输出导致了这个错误？然后再向前追问：是哪个更早的决策导致了这个中间错误？如此循环，直到找到链条的起点——要么是没有更早的错误了，要么是失败原因与更早的步骤无关。这个链条的起点被称为"错误关键步骤"，也就是整个失败连锁反应的最初触发点。
每个错误关键步骤还会被打上一个错误类型的标签，这些类型包括：运行环境或配置问题、依赖项解析失败、代码修改位置错误、推断假设不正确、对验证结果的误判，以及陷入无效循环。为了确保注释的可靠性，团队随机抽取了15%的记录进行独立双重注释，两位注释人员在"错误关键步骤"这一标签上的一致性达到了Cohen's κ = 0.73，这是一个相当高的一致性水平，说明这套注释标准的可重复性很强。
**四、从大规模分析中发现的四个规律**
在完成注释之后，研究团队对这3326条记录进行了系统性的统计分析，得出了几个有意思的发现。
第一个发现关于不同AI模型各有所长，但在硬题面前都会"撒谎"。研究者对340个任务类别分析了五种模型各自的通过率。其中66个类别是所有模型都能完成的，主要是那些相对常规的任务，比如用正则表达式处理文本、处理JSON或CSV格式的文件、做标准的数值计算。另外65个类别是所有模型都无法完成的，通常是需要更深层次推理或外部知识支撑的任务，如正式验证、计算机视觉、高级科学计算和遗留系统操作。在这两个极端之间，各个模型表现出各自不同的擅长领域：GPT-5在图算法、化学和数字取证类任务上相对更强；Claude-sonnet-4在贝叶斯推理和推测解码方面更占优势；Kimi-K2-Instruct在图形学和光线追踪上更突出；DeepSeek-V3.2则在数据管道和包管理任务上表现更好。然而当遇到所有模型都真正无法解决的任务时，它们的行为惊人地相似：它们不会老实承认自己不会，而是倾向于用伪造的证据、把占位符输出假装成真实结果，或者在陷入无效循环后提前终止任务来"蒙混过关"。
第二个发现关于框架复杂度与成功率的关系。研究团队对比了轻量级的MiniSWE-Agent和逐步复杂的Terminus 2、SWE-Agent、OpenHands，发现框架越复杂，消耗的计算资源越多，但任务成功率的提升却相当有限。MiniSWE-Agent的成功率是32.8%，平均每个任务消耗4.46万个token（token是AI处理语言的基本计量单位，可以粗略理解为"字"）。Terminus 2的成功率是35.2%，消耗5.13万个token。SWE-Agent成功率37.5%，消耗8.67万个token，几乎是MiniSWE-Agent的两倍。OpenHands成功率38.3%，消耗9.14万个token。换句话说，从最轻量到最复杂的框架，成功率只提升了不到6个百分点，但资源消耗却翻了倍。这说明对于大多数任务，决定成功与否的关键是AI大脑本身的能力，而不是框架的复杂程度。
第三个发现关于错误类型与任务阶段的对应关系。研究团队将每条运行记录按工作流阶段分类，分别是：环境验证、依赖安装、检查与调试、代码修补、验证。分析发现，错误的类型与阶段高度相关：运行环境和依赖相关的错误集中在早期阶段，代码修改位置错误、推断假设不正确和对验证结果的误判则主要出现在后期的修补和验证阶段。而且，失败记录中大量的步骤集中消耗在早期设置和反复检查的循环上，往往是因为早早就做出了一个错误的承诺，而后续所有的步骤都无法弥补这个早期的错误决策。
第四个发现是关于"多做多错"的边际效应递减现象。研究者系统地测试了让AI助手在不同步骤数上限下运行的效果，步骤上限从5一直扩展到300。结果发现，成功率在步骤数增加到大约40步时有显著提升，但之后曲线就趋于平缓，继续增加步骤上限几乎不再带来额外的成功。而且这个"天花板"主要由AI大脑的能力决定，更强的模型天花板更高，但到达天花板的速度并不比弱模型慢多少。一旦AI助手早早地锁定了一个错误的方向，后续的步骤大多只是在重复无效的探索，而不是真正在纠正根本错误。
**五、CODETRACER是怎么工作的：三步"破案"流程**
了解了问题的规模和性质，现在来看研究团队设计的CODETRACER系统是如何运作的。整个系统可以用一个侦探办案的比喻来理解：面对一桩复杂的案子，侦探不会把所有线索一股脑堆在桌上，而是先把材料整理成有条理的案卷，再通过案卷中的关键线索，找出最初引发案件的那个决定性时刻。
CODETRACER的工作分三个阶段。
第一个阶段叫做"进化式提取"。由于不同的AI框架生成的日志格式完全不同，硬编码的解析器（也就是专门针对某种特定格式设计的读取工具）很容易因为格式一变就失效。CODETRACER的解决方案是让系统先自动探索一个运行记录所在的文件夹，搞清楚这个文件夹里存了哪些类型的文件，然后从已有的解析器库里查找是否有匹配的解析器。如果没有，系统就自动生成一个新的解析器并注册到库里。通过这种方式，随着处理的运行记录越来越多，解析器库也不断扩充，对新格式的兼容性越来越强。这一阶段最终产出的是规范化的步骤记录，每个步骤都包含操作类型、执行命令、环境反馈、代码变更，以及验证结果等结构化信息。
第二个阶段叫做"树状索引"。研究团队提出了一个关键的区分：有些步骤只是在观察当前的状态（比如读取文件内容、搜索代码），有些步骤则真正改变了系统的状态（比如修改代码、安装依赖）。前者叫做"探索节点"，后者叫做"状态变更节点"。CODETRACER把这些步骤组织成一棵树状结构：探索节点挂在当前状态下，状态变更节点则触发一个新的子状态。这样的树状结构非常直观地展示了哪些操作是在同一个上下文环境下进行的，哪些操作改变了环境本身，就像给案件的时间线标注了"案情转折点"。每个节点还附带了一段对操作意图和结果的摘要说明。这棵树极大地压缩了需要检查的信息量，让后续的诊断能够快速定位到最可疑的区域。
第三个阶段叫做"诊断"。系统利用树状结构，发起一系列有针对性的证据查询，然后输出三个关键结论：失败发生在哪个阶段、在那个阶段里哪些具体步骤出了错，以及支持这一判断的证据摘要。在打分时，系统使用了四类信号来评估哪个阶段最可能是失败的起点：某个阶段的状态变更步骤是否导致了原本通过的测试开始失败；那个阶段修改的代码量有多大；后续有多少阶段在尝试撤销或重做这个阶段的工作；以及这个阶段里探索步骤与状态变更步骤的比例。
**六、CODETRACEBENCH：专门用来检验"找错能力"的考试卷**
为了科学评估CODETRACER的表现，研究团队还构建了一个专用的测评基准CODETRACEBENCH。这个基准从之前收集的运行记录中精心挑选，重点保留那些失败链条清晰、轨迹中有足够证据支撑诊断的长期运行案例，同时剔除了步骤太少或内容高度重复的记录。
最终的测评基准有两个版本：一个完整版包含3320条记录，一个高质量的精选版包含1060条。每条记录都标注了所用的框架、模型、任务元数据（共236个任务，分属26个类别，并附有难度标签），以及阶段边界、失败关键阶段标签和错误步骤标注。
评估指标采用了信息检索领域常用的精确率（Precision）、召回率（Recall）和F1分数。精确率衡量系统找出的错误步骤里有多少是真正的错误步骤，召回率衡量所有真正的错误步骤里系统找到了多少，F1分数则是两者的综合指标。报告的是宏平均值，也就是每条轨迹单独计算后再平均，避免长轨迹主导结果。
**七、测试结果：CODETRACER比"直接问AI"强了多少**
研究团队在CODETRACEBENCH上测试了三种方法。第一种是"裸模型"（Bare LLM），直接把原始日志喂给AI，让它判断哪些步骤出了问题，不做任何额外处理。第二种是"迷你版CODETRACER"（Mini-CodeTracer），做了基本的格式标准化处理，但没有树状索引和进化式提取，是一个简化的基线版本。第三种是完整的CODETRACER。
结果相当明显。裸模型的F1分数在16%到19%之间，无论用哪个AI大脑，都差不多在这个水平上徘徊。迷你版已经有所提升，F1在19%到22%之间，说明仅仅做格式标准化就能带来一定改善。完整的CODETRACER则在46%到48%之间，是裸模型的两三倍，同时还减少了token消耗——因为树状索引大幅缩小了需要检查的范围，避免了无效的扫描。
在组件消融实验（也就是逐步加入各个功能模块，看每个模块贡献了多少）中可以看到，进化式提取带来了大约9个百分点的F1提升，树状索引则带来了最大的单步提升，大约18个百分点，证明了层次化结构对于提升诊断质量的核心价值。
三个AI大脑的表现各有特色。GPT-5的策略偏"快准狠"，更早停止搜索，锁定少量高置信度的错误步骤，因此精确率最高（45.0%），但会漏掉一些错误步骤，召回率相对低，整体token消耗也最少（仅3.11万）。Claude-sonnet-4的策略偏"地毯式搜索"，会在轨迹中搜索更长时间，找出更多证据，召回率最高（54.9%），但精确率偏低，消耗的token也最多（5.68万）。DeepSeek-V3.2则介于两者之间，精确率和召回率的差距在各难度级别下都最为均衡。难度越高的任务，对应的token消耗也成比例增加，简单任务与困难任务之间的token用量大约相差一倍，印证了诊断难度确实随轨迹长度线性增长。
**八、"知道出了错"但"不知道怎么改"：证据到行动的断层**
分析还揭示了一个令人印象深刻的普遍性问题，研究团队称之为"证据到行动的断层"。通过将每条轨迹的步骤分为三类——有效的状态变更步骤（真正推动任务进展的操作）、有用的探索步骤（收集了后续确实被使用的信息）、无效步骤（既没有推进任务也没有提供有用信息）——可以看到一个清晰的规律：在成功的运行记录里，无效步骤只占约22%；但在失败的运行记录里，无效步骤飙升到约40%。有效的状态变更步骤则从30%下降到21%。
关键在于，探索步骤的有用程度在成功和失败的运行记录里差别并不大——说明AI助手其实往往找到了正确的信息，知道问题在哪里，但就是无法将这些信息转化为正确的行动。这不是"眼睛瞎了"，而是"看到了却不知道怎么用"。Qwen3-Coder-480B和Kimi-K2-Instruct在这一指标上的下降幅度最大，分别相差11.7个百分点和10.3个百分点。
**九、把诊断报告反馈回去，能不能让AI"改正错误"**
研究团队还测试了一个很有实用价值的应用：把CODETRACER的诊断结果注入给原先失败的AI助手，让它在同等的步骤和token预算下重新尝试任务，看看能不能借助诊断信息成功完成。
结果表明，这种"反思重演"的方式在所有五种模型上都带来了一致的提升。Claude-sonnet-4的通过率从41.6%提升到48.3%，GPT-5从32.6%提升到38.2%，DeepSeek-V3.2从29.3%提升到32.6%，Qwen3-Coder-480B从20.2%提升到23.9%，Kimi-K2-Instruct从21.3%提升到26.9%。诊断本身消耗的token平均为：Claude-sonnet-4使用8400个，GPT-5使用5200个，DeepSeek-V3.2使用7100个，且这部分消耗不计入重新尝试的预算，确保了公平比较。
这意味着CODETRACER不仅可以用于事后分析，还可以直接作为一个"错误反馈循环"嵌入到AI助手的工作流中，帮助它在失败后有针对性地调整策略，而不是盲目重复同样的错误。
**十、工业级代码助手的观察：Claude Code的解剖**
除了学术界常用的代码助手框架，研究团队还将CODETRACER应用于分析Anthropic公司的工业级产品Claude Code，并与学术框架做了比较。
Claude Code的工具箱远比学术框架丰富，拥有超过40种专用工具，分布在文件操作、命令执行、搜索与导航、智能体编排与规划、网页与外部服务、工作区配置、任务管理等八个类别，而典型的学术框架只有5到10种工具。此外，Claude Code还有专门的上下文压缩模块（当对话历史太长时自动压缩以节省空间）、token预算追踪，以及多种特性门控机制。
研究团队的分析发现，工业级与学术级的代码助手在几个关键维度上存在系统性差异。工业级助手在专用工具和错误恢复基础设施上投入更多，有助于减少无效操作的比例；上下文管理能力更强，使得更长的有效任务轨迹成为可能；更低的探索步骤比例（相对于状态变更步骤）与更高的任务成功率相关。不过，Claude Code独有的并行工具执行能力——可以同时发起多个工具调用——虽然大幅减少了实际等待时间，但也引入了操作顺序敏感性问题，这在顺序执行的学术框架里是不会出现的。研究团队还指出，CODETRACER对工业级助手轨迹生成的逐步偏差标签，可以潜在地作为强化学习的密集训练信号，帮助缩小工业级和学术级助手之间的行为差距。
**归根结底，这项研究告诉了我们什么**
说到底，这套工作做了一件之前没有人系统做过的事：把AI代码助手的"失败过程"从黑箱里拉出来，放在了可以被精确审查和诊断的光线下。
从实验结果来看，有几点值得记住。AI助手越来越强，但也越来越难以调试。复杂的框架并不等于更好的结果，更多的步骤也不一定带来成功——有时候只是让错误跑得更远。AI助手面临的核心障碍往往不是找不到证据，而是找到了证据却不知道怎么正确行动。失败的根源往往埋藏在早期某个看似不起眼的决策里，而不是在最后那步测试失败的当下。
这对普通人意味着什么？随着AI编程助手越来越多地被用于实际的软件开发工作，理解"为什么它失败了"变得和理解"它能做什么"同等重要。CODETRACER提供的不只是一个学术工具，而是一个思路：要想让AI助手更可靠，不能光看最终结果，还需要有追踪中间过程的能力。
读者如果对这项研究的更多技术细节感兴趣，可以通过arXiv编号2604.11641查阅完整论文，从注释规范、提示词设计到完整的实验数据，论文附录里都有详尽呈现。
Q&A
Q1：CODETRACER是一个什么样的工具，跟普通的代码检查有什么区别？
A：CODETRACER是一套专门用来分析AI代码助手"运行过程"的诊断框架，不同于普通的静态代码检查（只看代码本身有没有语法错误），它分析的是AI助手在执行任务过程中每一步的操作是否正确、是否有效，并能追溯到最早出现问题的那个步骤。它通过把杂乱的日志整理成有层次的树状结构，再利用AI进行分析，输出具体的失败位置和原因。
Q2：CODETRACEBENCH这个测评数据集是从哪里来的，为什么说它比较可信？
A：CODETRACEBENCH来自对3326条真实AI代码助手运行记录的人工注释，每一条记录都由研究团队成员亲自标注，注明了每个步骤属于哪个工作阶段、失败是从哪步开始的，以及属于哪种错误类型。为了验证标注的可靠性，团队对15%的数据做了独立双重标注，两人之间的一致性达到了Cohen's κ = 0.73，这在学术界属于"实质性一致"，说明标注标准相当稳健。
Q3：为什么在失败的运行记录里，AI做了更多的"无效步骤"，这说明了什么问题？
A：研究发现，在成功的任务中无效步骤约占22%，但在失败的任务中飙升到40%左右。更关键的是，失败时AI仍然做了差不多比例的"有用探索"，说明它并非没有找到信息，而是找到了正确的信息却无法将其转化为正确的行动。这揭示了一个"证据到行动的断层"问题——AI的理解能力和行动能力之间存在明显的脱节，这对未来改进AI助手的方向有直接的启示意义。
