Explyt团队打造的代码智能体评测新标准：光靠"通过/失败"根本不够用

这项由俄罗斯Explyt公司与圣彼得堡斯捷克洛夫数学研究所、圣彼得堡国立大学联合开展的研究，以预印本形式于2026年7月7日发布在arXiv平台，论文编号为arXiv:2607.06624，有兴趣深入了解的读者可以通过该编号查询完整论文。

---

一个被忽视已久的问题

每天有数以百万计的程序员在使用AI编程助手——有人用它帮忙写测试代码，有人用它重构老项目，有人用它生成文档，有人则依靠它调试复杂的线上bug。但当研究者们想要评测这些AI助手的优劣时，他们通常只问一个问题：任务完成了吗？是，还是否？

这就像评价一位外科医生，只看手术后病人有没有出院，而不管手术过程中有没有大出血、有没有多切了不该切的器官、有没有跟病人家属解释清楚病情。出院了≠好医生，同理，任务"通过"了也≠好助手。

Explyt团队正是从这个痛点出发，开发了一套名为AgentLens的评测基准。这套系统的核心理念是：评测一个AI编程助手，不能只看它最终交出的答案，而必须看完整个"工作过程"——它是怎么理解你的需求的，它调用了哪些工具、调用得对不对，它犯了错之后怎么恢复，它和你的对话体验怎么样。换句话说，AgentLens评测的是整个"轨迹"，而不仅仅是终点。

---

一、现有评测体系的根本局限

要理解为什么AgentLens值得关注，先得弄清楚现有评测方式有什么问题。

目前学界最权威的代码智能体评测基准之一叫做SWE-bench，它的做法是：从GitHub上收集真实的bug修复任务，让AI去改代码，然后跑测试，看测试通过了没有。这个思路简洁有力，但问题也很明显——它只看结果，不看过程。

麻省理工学院做过一个类比实验（虽然不是真实实验，但道理相通）：假设两个学生都通过了数学考试，但一个是靠抄答案的，另一个是靠真正理解数学推导的。考试成绩相同，但他们的能力天差地别。SWE-bench风格的评测，往往无法区分这两种情况。

更重要的是，有些任务根本没有明确的"通过/失败"标准。比如让AI帮你给整个项目写技术文档，你没法简单地说"文件生成了=任务通过"，因为真正重要的是：文档准不准确？覆盖面够不够广？写法对开发者友好吗？有没有和实际代码对齐？这些维度完全无法用一个布尔值来捕捉。

Explyt团队在日常开发自己的AI编程产品时深刻体会到了这个问题。他们需要知道的不仅是"新版本的模型能不能过基准测试"，更需要知道"新版本在哪些地方变好了、哪些地方变差了、用户用起来感觉怎么样"。现有的评测工具无法回答这些问题，于是他们决定自己造一套。

---

二、AgentLens的核心设计：评测整条"工作轨迹"

AgentLens最核心的设计理念是把"轨迹"（trajectory）作为评测的基本单位。

所谓轨迹，就是一次完整的人机对话记录，包含了所有的内容：用户发的消息、AI给出的回复、AI调用了哪些工具（比如读取文件、执行命令、修改代码）、工具调用的参数和结果、AI对代码库的所有修改记录、整个任务的最终状态，以及AI最终给用户的答复。把这一切串起来，就像一部完整的纪录片，而不只是结尾的一张截图。

为了让这个评测尽可能接近真实使用场景，AgentLens引入了"用户模拟器"——用另一个大语言模型来扮演真实用户，和被测试的AI助手进行交互。这个模拟用户有自己的个性设定，目前有三种：一种是普通的默认用户，不会主动帮助AI，只在AI明显出错时才介入；一种是友好合作的用户，会在AI犯错时给出温和的纠正建议；还有一种是带点情绪的用户，偶尔会表达不满或者语气不太好，但不会故意给AI发假信息误导它。通过这三种不同的用户个性，可以测出一个AI助手是否只能和"配合度高的用户"好好工作，还是在各种用户风格下都能稳定发挥。

关于任务从哪里来，Explyt团队采用了一套扎实的方法。他们一方面访谈了真实的程序员，让这些程序员描述自己昨天或前天做的实际工作——检查代码、修改文件、查文档、跑测试、调bug、审查改动——并特别关注这些工作者"最近经常做的任务"，把它们作为高权重的评测场景。另一方面，他们还利用了用户实际使用AI助手时留下的匿名化聊天记录，把每段对话转化为匿名的任务摘要，提取编程语言、技术栈、任务类型、应用领域等标签，然后用聚类算法找出高频使用模式，再从中挑选尚未被评测覆盖的场景补充进来。这种"访谈+真实使用数据"的双轨方式，确保了任务设计贴近开发者的日常，而非学术界闭门造车的想象。

---

三、五个维度，打出立体的评分

AgentLens会从五个不同角度来评价每一条轨迹，这五个角度分别捕捉了不同类型的"好"与"坏"。

第一个维度叫做"最终结果"（ENDRESULT），专门看AI最终交出的成果——它完成了多少用户要求的工作？产出的内容对用户有没有实际用处？这个维度关注的是终点的质量，但只是五个维度之一。

第二个维度叫做"指令遵循"（INSTRUCTIONCOMPLIANCE），独立于结果之外评估AI有没有按照用户的要求来做事。用户说"先查清楚再动手"，AI有没有遵守？用户规定了特定的格式，AI有没有照做？用户要求分步骤汇报进度，AI有没有做到？这个维度捕捉的是"按用户要求做事"的能力，和最终质量无关——一个AI可以做出很好的结果，但如果完全不按用户的规矩来，那在协作中也会让人头疼。

第三个维度叫做"行为陷阱"（PITFALLS），专门找那些可以改正的坏习惯。比如工具调用乱用、陷入无意义的死循环、还没完成就宣布任务结束、忘了验证自己的改动有没有生效、工作流程不稳定容易崩溃等等。这个维度捕捉的是"过程中的自我破坏"。

第四个维度叫做"交互愉悦感"（PLEASANTNESS），看的是和这个AI一起工作的体验好不好。它的回复清晰吗？会不会总发一大堆没用的废话？有没有自信但准确地汇报工作进展？整个对话过程感觉高效流畅还是磕磕绊绊？

第五个维度叫做"工具调用质量"（TOOLCALLS），专门评估AI在调用各种工具时的表现。工具选得对不对？参数填得准不准？工具出错时能不能优雅恢复？有没有频繁调用没有意义的工具浪费时间？

这五个维度加在一起，能够区分出四种本质不同的"糟糕AI"：第一种最终结果差但过程还算规范；第二种结果不错但完全不按用户要求来；第三种表面回答得像模像样，但工具调用一塌糊涂；第四种技术能力没问题，但和它一起工作让人心情极差。如果只看一个总分，这四种AI可能得分接近，但问题的根源完全不同，需要不同的改进方案。

---

四、LLM担任裁判：靠谱吗？

读到这里，很多人可能会有一个疑问：用AI来评价AI，这不是既当运动员又当裁判吗？可信度有多高？

Explyt团队对这个问题给出了坦率而务实的回答。他们承认，用人工标注来评价这种长篇代码交互记录，实际上并不像人们想象的那么可靠——每条记录都很长，评分标准很复杂，标注者看久了容易出错，不同标注者之间的意见分歧也很大。他们做了一些内部预实验，发现LLM裁判和人工标注者之间的一致性，并不低于两个人工标注者之间的一致性。这个结论和学界的其他研究（比如MT-Bench和Chatbot Arena的工作）方向一致——强力的LLM裁判在开放式任务评估中可以达到接近人类水平的判断质量。

当然，这并不意味着LLM裁判是完美的。团队明确指出，他们目前的人机一致性验证还是初步的、规模较小的，正式的大规模一致性研究留待未来完成。这是一个诚实的承认，而不是掩盖。

为了让裁判的工作更有说服力，AgentLens要求每个裁判在给出评分的同时，必须写出文字评审——它看到了哪些证据、为什么给这个分数、具体是哪里出了问题。这些文字评审里会标注类似"[R3]"、"[R10]"的编号，指向轨迹中的具体位置，开发者可以直接跳到那个地方查看原始记录。这样一来，评分不再是一个从天而降的黑盒数字，而是有迹可循、可以复核的。

---

五、正式验证：给主观评审装上"客观锚点"

除了LLM裁判的主观评审，AgentLens还保留了一套传统的"形式化验证"机制，作为客观的补充。

形式化验证的思路是：对于那些有明确客观标准的任务，直接用程序来检查。AgentLens目前支持多种类型的自动检查，覆盖了编程项目中常见的核心场景。

仓库状态检查可以验证AI是否只修改了被允许修改的文件（没有越界动了不该动的东西），以及AI是否真的修改了应该修改的目标文件，还可以逐行对比最终文件和标准答案文件，看看结果是否一致。正则表达式检查则可以在对话记录、工具调用参数、Java源文件中搜索特定的文本模式，验证AI有没有做某件特定的事情。测试执行验证可以通过Maven或Gradle运行项目测试套件，检查测试的通过/失败/跳过情况，甚至可以测量修改后代码的测试覆盖率是否达到要求。命令输出检查可以执行任意构建任务并验证输出是否符合预期。静态分析验证则可以调用IDE的静态分析工具，检查代码是否有编译错误或警告。

每个任务场景可以配置一个或多个验证器，只有当所有验证器都通过时，才算形式化验证通过。形式化验证的价值在于它能捕捉一些LLM裁判容易忽略的细节，同时也能防止AI通过讨好裁判来骗分——毕竟代码跑不过测试这件事是骗不过去的。但形式化验证也有它的局限：它看不到交互质量，看不到指令遵循情况，也看不到AI是不是用了很糟糕但恰好蒙对结果的方式解决问题。所以两套机制互补使用，比单独依赖任何一套都更可靠。

---

六、质量指数与指标独立性的发现

AgentLens会把六个维度（五个LLM裁判维度加一个形式化验证）的得分做简单平均，得出一个综合质量指数（Quality Index，简称QI）。团队在15个不同AI系统上计算了各维度之间的相关性，发现了一个很有意思的现象。

当看"原始分数"时，所有维度都正相关——这不奇怪，强的模型在所有方面都倾向于得高分。但当用每个维度的得分除以质量指数，去掉"整体强弱"这个共同因素之后，各维度的相关性就大幅降低了，甚至出现了负相关。

最引人注目的两对负相关是：最终结果和工具调用（相关系数-0.66）以及形式化验证和交互愉悦感（相关系数-0.74）。用人话来说：有些AI系统特别擅长漂亮地完成最终任务，但工具使用凌乱；有些AI形式化测试通过率很高，但用起来体验很差。这说明这五个维度确实在测量不同的东西，而不是同一个能力的不同说法。如果只报告一个总分，这些重要的区别就会被掩盖掉。

---

七、并排比较：找出两个AI之间的真正差距

除了对单个AI系统的评估，AgentLens还支持"并排比较"（side-by-side review）——把两个AI系统处理同一个任务的轨迹放在一起，让裁判逐维度判断谁更好、好在哪里、好多少。

并排比较的裁判不是从零开始重新评估，而是以两份已经完成的单体评审为主要依据，只在需要核实细节时才回去查原始轨迹。这样做一方面提高了效率，另一方面也减少了裁判因为看顺序不同而产生偏见的风险。

为了验证这种比较是否可靠，团队做了两个测试。一个是调换顺序测试——把A和B的顺序调换，看裁判的判断会不会翻转。结果显示，无论哪种顺序，裁判对谁更好的判断方向保持一致，只是强弱程度略有变化，顺序敏感性很小。另一个是自我偏好测试——用GPT-5.5作为裁判评估GPT-5.5和Claude Sonnet 4.6，再换Claude Sonnet 4.6作为裁判评估同样的对比。结果发现，在23%的任务-维度组合中两个裁判的判断不同，其中18%是各裁判偏向自家模型，5%是各裁判偏向对方。自我偏好现象最集中在"交互愉悦感"这个最主观的维度，而在其他维度上影响较小。团队将这个发现作为一个使用注意事项来处理：在比较非常接近的前沿模型时，裁判选择会影响结论的强度，但不会根本上改变谁赢谁输的结论。

---

八、真实评测结果：数字背后的故事

AgentLens发布了一份基于32条轨迹的评测排行榜，涵盖了17个AI系统配置（使用两套运行框架：Explyt自家的AI Agent和Claude Code），测试的模型包括Claude Opus 4.7、GPT-5.5、Claude Sonnet 4.6、Gemini 3.1 Pro Preview、DeepSeek V4系列等当前主流前沿模型。

排行榜顶端是运行在Explyt自家框架上的Claude Opus 4.7，综合质量指数81.5，在最终结果维度高达94分。排在其后的是通过Claude Code框架运行的同款模型（76.2分），接下来依次是GPT-5.5（73.0分）、Sonnet 4.6（70.2分）等。排名垫底的是Kimi K2.6（28.1分），但这个低分背后藏着一个重要故事，稍后细说。

这份排行榜本身有趣，但团队反复强调：排行榜是AgentLens产出的最不有趣的部分。真正有价值的，是每个模型附带的文字评审报告。

以Gemini 3.1 Pro Preview为例，它的综合得分54.5，低于同期发布的多个模型，但原因不是代码能力差。评审报告明确指出，问题出在"智能体循环的可靠性"上：它会跳过用户要求的步骤、在未得到确认时就擅自开始修改代码、声称测试已通过但实际上构建失败了、陷入补丁-撤销的循环、用大范围的sed命令批量替换代码导致代码损坏。这些问题与代码生成能力无关，而是"能不能稳定地作为一个代理完成多步骤工作流"的能力问题。这一区分对开发者来说非常有价值：模型底层能力强，但智能体框架适配有问题，这是一个可以针对性改进的方向。

DeepSeek V4 Pro和DeepSeek V4 Flash的对比同样揭示了有趣的权衡。两者综合得分相差不到1分（64.1对64.8），但原因截然不同。Pro版本更"守规矩"，在步骤控制、格式要求、文件边界限制方面遵守得更好；Flash版本则更"会做事"，通过放宽这些约束来完成更多实质工作，而且吞吐速度是Pro版本的两倍多，在固定时间预算内能完成更多任务。相同的总分，完全不同的工作风格。

---

九、两个让人印象深刻的"评分陷阱"案例

AgentLens的设计者特别提到了两个案例，说明文字评审能捕捉到纯数字完全无法捕捉的信息。

第一个案例是Kimi K2.6的低分真相。这个模型在排行榜上得了28.1分，赫然垫底，很容易让人得出"这是个很弱的模型"的结论。但工具调用维度的评审报告却给出了完全不同的解释：在21条评审记录中，有20条报告了工具参数的格式错误，其中17条描述的是同一种错误——把工具参数包在一个多余的JSON层级里（类似于写成了`{"": {...}}`这样的格式）。这是OpenRouter（一个第三方API服务商）这边的工具参数解析bug，不是模型自身的推理能力问题。更能说明问题的是：一旦工具参数格式变正确，模型实际上能够成功调用工具完成任务。低分是环境bug造成的，不是智能水平低。如果只看总分，会得出完全错误的结论。

第二个案例是一次"看起来还好，实际上出了大问题"的版本回退测试。在Explyt的夜间评测流水线中，有一次新版本的AI助手因为并行工具调用出现了竞争条件（一种多线程编程中的经典问题，多个操作同时访问同一数据时可能出错），留下了`ConcurrentModificationException`的崩溃记录。但最终给用户的答复看起来还算正常，如果只看最终结果，很难发现这个问题。AgentLens的"行为陷阱"维度评审在并排比较中直接找到了这个崩溃点，并写道："最值得关注的调试证据是Agent 2在[C5]位置发生的显式ConcurrentModificationException崩溃……"这让开发者能够立刻定位到是并发工具调用的框架bug，而不是模糊地感知到"新版本好像变差了一点"。

---

十、夜间自动评测：评测流水线的工程实践

AgentLens不只是一个学术评测工具，它被直接接入了Explyt的日常开发工作流程。

具体来说，每天夜里会自动触发一次评测流程：把当天的候选版本在所有32个任务场景上跑一遍，收集轨迹数据，跑形式化验证，跑LLM裁判打分，生成评审报告，然后与"基准版本"做并排比较，检测是否有显著的性能退步。如果发现退步，系统会自动通知维护团队。

这个流水线支持手动触发（用于特定功能评估或实验对比）和定时自动触发（夜间例行检查）两种模式。每次评测产出的所有原始数据、中间结果、最终报告都存入实验追踪系统，方便历史对比。

在稳定性方面，团队用同一个模型配置（GLM-5.1自托管版）重复跑了五次，得到的质量指数均值为67.28，标准差只有0.94，说明评测结果相当稳定。进一步分析发现，这0.94的波动里有60.5%来自形式化验证的随机性（某些边界任务有时过有时不过），18.1%来自"行为陷阱"维度，16.2%来自"最终结果"维度，LLM裁判本身的随机性反而是最小的变动源。

---

十一、与公开基准的相关性：AgentLens测的是什么

团队还做了一个有趣的对比分析：把AgentLens的质量指数和Artificial Analysis平台上的11个主流评测基准的得分进行斯皮尔曼秩相关分析，看看AgentLens和这些基准到底在多大程度上测的是同一回事。

结果显示，AgentLens的质量指数与APEX-Agents-AA这个智能体专项基准的相关性最高（相关系数0.82），与另一个智能体评测GDPval-AA也有中等相关（0.59）。但与那些偏向推理能力或指令遵循的基准，如IFBench，相关系数是-0.41，与τ?-Bench Telecom的相关系数是-0.25，都是负相关。

这个负相关很有意思：它意味着某些在"指令遵循"类评测上表现出色的模型，在AgentLens的IDE真实编程任务上表现反而偏弱，反之亦然。团队分析认为，这是因为有些模型被大量针对评测风格的数据优化过，在标准化考试题上表现出色，但面对长时程、多步骤、需要稳定使用工具的真实开发场景时就露馅了。

从具体模型来看，Gemini 3.1 Pro Preview在综合智能排名中比AgentLens排名高出近4个名次，Mimo V2.5 Pro高出近5个名次——这两个模型在传统评测上的排名虚高。而Claude Opus 4.7和Claude Sonnet 4.6则相反，在AgentLens上的排名比综合智能排名高出3到4个名次，说明它们在真实编程任务中的表现比其他评测数据显示的要好。

---

十二、诚实的局限性说明

AgentLens并不是一套万能的评测系统，团队对此保持了清醒的认识，并在论文中坦率地列出了多个局限。

在任务覆盖方面，目前发布的任务集只包含Java语言的编程场景，共16个场景（配合2个用户性格，共32条轨迹），覆盖范围有限，评测的是特定类型的编程工作，而不是通用智能。在评测成本方面，跑一次Opus 4.7模型的完整评测可能花费超过100美元，不是所有团队都能承担的日常开销。在提供商依赖方面，部分模型通过第三方API（如OpenRouter）运行，网络延迟、路由、模型版本都不在研究者的控制之内，DeepSeek V4 Pro和Flash的吞吐速度差异就有一部分是服务条件造成的，不完全是模型能力的差异。在潜在偏差方面，因为AgentLens最初是围绕Explyt自己的AI助手工具设计的，某些任务设计和框架假设可能对Explyt的系统更友好，虽然已经通过开源和完整评审报告来缓解这个问题，但外部中立验证还需要更多时间。LLM裁判的人机一致性研究也只是初步验证，正式的大规模验证研究还需要继续。

---

结语：一个更诚实的评测

归根结底，AgentLens试图回答的是一个非常简单的问题：这个AI编程助手，我每天用着会舒服吗？它能可靠地帮我完成工作吗？它在出问题时能优雅地处理吗？

这些问题对真实用户来说是最重要的，但过去的评测体系基本上忽略了它们。AgentLens的思路是把每一次人机交互都当成一部可以反复审查的纪录片，从五个不同的角度把它看透，然后不只告诉你"通过了还是没通过"，而是告诉你"它在哪里好、在哪里差、为什么差、下一步应该怎么改"。

对于真正在做AI编程产品的团队来说，这种评测带来的价值是实实在在的：发现了一个并发bug，定位了一个API服务商的工具解析问题，找到了两个评分相近但风格截然不同的模型之间的真正区别。

如果你对这套评测系统的技术细节感兴趣，可以在arXiv上通过编号2607.06624找到完整论文，团队也在GitHub上开源了全部评测代码，地址是github.com/agent-lens/agent-lens-bench。

---

Q&A

Q1：AgentLens评测框架和SWE-bench这类传统代码评测基准的核心区别是什么？

A：传统评测基准如SWE-bench只看任务的最终结果是否通过，给出一个通过/失败的二元判断。AgentLens则把整条人机交互轨迹作为评测对象，从最终结果、指令遵循、行为陷阱、交互愉悦感、工具调用质量五个维度分别打分，并要求裁判为每个评分提供有据可查的文字评审，能够区分"为什么失败"和"哪里做得好"，而不只是告诉你一个成绩。

Q2：AgentLens中的LLM裁判打分可信度怎么保证？

A：团队进行了两方面验证。一是内部预实验显示LLM裁判和人工标注者的一致性不低于人工标注者相互之间的一致性；二是要求裁判在评分时必须提供引用具体轨迹位置的文字评审，使评分可追溯而非黑盒。此外还做了顺序互换测试和自我偏好测试，确认顺序效应较小，自我偏好现象主要集中在最主观的"交互愉悦感"维度。正式的大规模人机一致性验证研究还在进行中。

Q3：Kimi K2.6在AgentLens评测中为什么得了最低分？

A：Kimi K2.6的低分（28.1分）主要是由OpenRouter这个第三方API服务商的工具参数解析bug造成的，而不是模型自身推理能力的问题。评审报告发现，21条记录中有20条存在相同的JSON参数格式错误，一旦格式正确，模型实际上能够成功完成工具调用并推进任务。这个案例正好说明了AgentLens文字评审的价值：只看总分会得出"这是弱模型"的错误结论，而读评审报告才能找到真正的原因。