重新思考智能体生成测试对基于大语言模型的软件工程智能体的价值

重新思考智能体生成测试对基于大语言模型的软件工程智能体的价值（中文全译）

翻译说明：本文是 arXiv 论文 Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents（arXiv:2602.07900）的中文全译，由智测团队翻译。原作者：Zhi Chen、Zhensu Sun、Yuling Shi、Chao Peng、Xiaodong Gu、David Lo、Lingxiao Jiang。原文以 CC BY 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

arXiv:2602.07900v2 [cs.SE] 2026 年 4 月 9 日

会议：2026 年 10 月；美国华盛顿特区

作者

• Zhi Chen，新加坡管理大学（新加坡），邮箱：zhi.chen.2023@smu.edu.sg
• Zhensu Sun（通讯作者），新加坡管理大学（新加坡），邮箱：zssun@smu.edu.sg
• Yuling Shi，上海交通大学（中国上海），邮箱：yuling.shi@sjtu.edu.cn
• Chao Peng，字节跳动（中国北京），邮箱：chao.peng@acm.org
• Xiaodong Gu，上海交通大学（中国上海），邮箱：xiaodong.gu@sjtu.edu.cn
• David Lo，新加坡管理大学（新加坡），邮箱：davidlo@smu.edu.sg
• Lingxiao Jiang，新加坡管理大学（新加坡），邮箱：lxjiang@smu.edu.sg

2026

摘要

大语言模型（Large Language Model，LLM）代码智能体越来越多地通过迭代编辑代码、调用工具并验证候选补丁，来解决仓库级问题。在这些工作流中，智能体常常即兴编写测试，但这一行为的价值仍不清楚。例如，GPT-5.2 几乎不编写新测试，却能达到与排名靠前的智能体相当的表现。这引出一个核心问题：这类测试究竟是否切实提高了问题解决率，还是主要在模仿一种熟悉的软件开发实践，同时消耗交互预算？

为更好地理解智能体编写的测试所扮演的角色，我们分析了六个强模型在 SWE-bench Verified 上产生的轨迹。结果表明，编写测试很常见，但同一模型内部，已解决问题与未解决问题的测试编写频率相近。测试一旦被写出，主要充当观察性反馈通道：揭示取值的打印语句出现得远比基于断言的检查更频繁。基于这些发现，我们开展提示词干预研究：修改四个模型所使用的提示词，以增加或减少测试编写。结果表明，在本设定下，由提示词引起的智能体编写测试数量变化，并不会显著改变最终结果。综合来看，这些结果说明：当前智能体编写测试的实践，更多是在重塑过程与成本，而不是最终任务结果。

关键词：大语言模型；智能体编写的测试；智能体轨迹分析；软件开发智能体

1. 引言

代码智能体越来越多地把大语言模型（OpenAI, 2025；DeepSeek, 2025b；Chen and Jiang, 2024）与工具及交互协议结合起来，从而能够编辑真实仓库、调用工具，并尝试端到端地解决问题（Yang et al., 2024a；Örwall, 2024；Wang et al., 2024b；Gao et al., 2025b；Hong et al., 2024；Qian et al., 2024；Ehrlich et al., 2025；Xia et al., 2024）。本文中，代码智能体指与外部工具耦合、并带有迭代式“行动—观察”循环的大语言模型；脚手架（scaffold）则指环绕其外的工具接口与交互协议，它规定智能体被允许的行动与所获得的反馈。在代码智能体所需的多种能力中，测试起着关键作用：它暴露回归、验证假设，并在补丁开发过程中提供反馈回路（Zhang et al., 2024；Xia et al., 2024；Liu et al., 2024；Mu et al., 2025）。

图 1. 研究设计概览。RQ1 考察测试行为，RQ2 分析智能体编写的测试中的反馈信号，RQ3 研究测试编写干预下所观察到的结果与效率变化。

在处理仓库级任务时，智能体通常把测试当作主要的验证接口，而这些测试来自两个主要来源。第一是仓库中已有的、由人编写的测试套件，它反映开发者意图与既有项目约定（Jimenez et al., 2024；Chen and Jiang, 2025）。第二是智能体编写的测试——智能体在解题过程中写出的、原先并不存在于代码库中的新测试产物。与经过策划的人工测试不同，智能体编写的测试是在问题解决过程中即兴写出的，其可靠性取决于模型对规格的理解、领域知识，以及对目标代码库语义的把握。智能体编写的测试可能有益：它们能暴露边界情况，并为故障定位与补丁精炼提供可操作的反馈。然而，若其中嵌入了错误的假设或预言（oracle），它们也可能有害，把精力引向“通过测试”，而不是解决目标问题。此外，测试生成与执行会带来不可忽视的开销——消耗 API 调用与词元（token），并增大上下文占用——从而减少留给核心调试与打补丁的剩余预算（Kim et al., 2025）。当由此产生的信号价值较低时，这种开销可能稀释智能体的注意力，并在净效果上变得有害。

为更好地理解智能体编写的测试，我们使用 mini-SWE-agent（SWE-agent Team, 2024）对 SWE-bench Verified（OpenAI, 2024）上的智能体轨迹做定量分析。在该设定中，测试是可选的，并不由任何硬编码流程强制执行。对若干强模型而言，智能体编写测试十分普遍。例如，Claude Opus 4.5（在本设定中排名第 1，解决率 74.4%）在约 83% 的任务中至少生成一个新测试产物。相比之下，GPT-5.2 达到相当的解决率（71.8%），仅比 Claude Opus 4.5 低 2.6 个百分点，却几乎不生成新测试（仅在 0.6% 的任务中生成）。这一观察引出一个核心问题：当提示词与模型倾向促使智能体编写更多测试时，所观察到的结果是否真的变好，还是模型只是在模仿一种学来的软件开发实践，而由此产生的测试对最终补丁贡献甚微？若后者成立，那么广泛地创建并执行智能体编写的测试，可能意味着大量资源浪费：消耗交互预算，却不能在任务成功上获得有意义的收益。因此，我们认为需要一项系统性的实证研究，以理解智能体编写的测试在解决软件问题中的作用。

既有工作大多在预定义的测试目标与固定质量指标（例如单元测试、断言或问题复现测试）下评估并基准化 LLM 生成的测试，且通常相对于一个固定的目标程序或被测代码快照（Lops et al., 2025；Zhang et al., 2025b；Mündler et al., 2024；Yuan et al., 2024；Wang et al., 2025；Wang et al., 2024a；Schäfer et al., 2023）。然而，在复杂的真实世界 GitHub 问题解决中（Jimenez et al., 2024；Khandpur et al., 2025），代码库与候选补丁会随时间演化，测试的编写与使用是作为自主行为动态出现的，而不是预先指定的评估目标。高自主智能体在此类问题解决过程中编写并使用测试的内在倾向——以及由提示词引起的测试编写变化如何与所观察到的解决结果和成本相关——尚未被系统研究。这促使我们在以下三个研究问题的引导下，对智能体编写的测试做更细致的实证考察。

研究问题与概览。

针对这一空白，我们研究智能体编写的测试在 GitHub 问题解决中的作用。图 1 概括了我们的研究设计，它把问题分解为三个互补的研究问题。RQ1 刻画智能体在轻量脚手架下的测试行为——在该脚手架中编写测试是可选的：智能体是否编写测试、何时引入测试，以及执行测试的强度如何。RQ2 从行为转向测试内容，考察智能体编写的测试在执行时实际发出何种反馈信号（断言相对于揭示取值的打印）、它们使用何种断言类型，以及这些揭示取值的打印通常检查哪类运行时信息。RQ3 考察所观察到的结果与效率变化：通过修订提示词来鼓励或抑制编写新测试，我们度量测试编写行为的改变如何伴随着任务解决结果与效率成本（API 调用与词元）的变化。

发现摘要。

跨模型来看，智能体编写的测试最好被理解为一种依赖模型的过程风格，而不是成功的可靠驱动因素。RQ1 表明，编写测试很普遍，但与成功仅有弱对齐。RQ2 表明，智能体编写的测试主要充当观察性反馈通道，揭示取值的打印压倒基于断言的检查。RQ3 表明，由提示词引起的测试编写变化，对多数任务的任务结果只有很小的观察效应，但可能实质性地改变效率。

本文贡献可概括如下：

• 对代码智能体所编写测试的行为分析。 我们刻画基础 LLM 智能体编写测试的行为，包括它们是否创建新测试产物、此类测试创建发生在轨迹中的何时，以及这些测试如何被执行。结果表明，测试编写与执行强度在很大程度上是依赖模型的过程风格，并且只与任务成功弱对齐（例如，一些高性能模型在几乎不编写测试的情况下解决了大量任务）。
• 覆盖断言与揭示取值打印的反馈信号分析。 我们把面向验证的断言与观察性输出区分开，并引入基于规则的抽象语法树（AST）分析，把断言映射为四类、把揭示取值的打印映射为三个粗粒度类别。我们发现，测试在很大程度上承担观察角色：揭示取值的打印数量持续多于断言；这些打印以取值／内容检查以及异常／状态信号为主；断言的使用则以局部性质检查与精确取值检查为主。
• 关于所观察结果与效率的提示词干预研究。 通过受控的提示词干预——要么鼓励、要么抑制编写新测试文件——我们在同一智能体脚手架下，研究测试编写线索的变化如何与所观察到的任务成功及交互效率相关。我们表明，测试编写状态的大幅翻转，在多数任务上只伴随着解决结果的很小观察变化，而效率变化可以很大。诱导编写测试可能增加词元与交互开销而不提高成功率；抑制测试则带来大幅成本下降，成功率仅有适度下降。

2. 方法

本节介绍本研究的方法，包括基准、所研究的智能体与大语言模型、智能体编写测试的抽取，以及实现细节。本研究由三个研究问题引导：

• RQ1：在轻量智能体脚手架下会出现何种测试行为？
• RQ2：智能体编写的测试提供何种反馈信号？
• RQ3：提示模型编写测试如何改变所观察的结果与成本？

2.1. 基准

我们使用 SWE-bench Verified 作为基准。原始 SWE-bench 基准由取自 12 个开源 Python 仓库的已解决 GitHub 问题构建而成（Jimenez et al., 2024）。SWE-bench Verified 是一个包含 500 个实例的子集，由 OpenAI 牵头、并与 SWE-bench 作者合作的人工筛选工作之后发布（OpenAI, 2024）。每个实例提供一个 GitHub 问题、一份固定的仓库快照，以及官方评估框架。我们在由此产生的轨迹中分析智能体编写的测试产物。

2.2. 智能体及其大语言模型

尽管许多近期基于 LLM 的智能体纳入了经过策划的测试组件，例如专门的验证模块、专用的测试规划阶段，或多智能体协同（Liu et al., 2024；Zhang et al., 2024；Ruan et al., 2024；Cognition Labs, 2024），这些框架会把模型的内在倾向与脚手架所诱导的约束混在一起。为更好地隔离基础模型行为，我们采用 mini-SWE-agent（SWE-bench Team, 2024；SWE-agent Team, 2024）。它提供一个轻量的智能体工作循环，并限制在标准 bash 接口之内：智能体仅通过 bash 工具与仓库交互，在 bash shell 中执行命令（例如运行 python），并使用标准命令行工具检查与修改文件。模型可以即兴创建可执行的 Python 测试文件，并经由 bash 将其作为工作流的一部分运行。关键在于，尽管 mini-SWE-agent 的默认提示词包含一句简短的自然语言建议，例如“Test edge cases to ensure your fix is robust”（测试边界情况，以确保你的修复足够稳健），该指令只是建议性的：它并不引入任何测试专用函数、专用测试工具，或硬编码的工作流组件（例如测试规划器、结构化测试模块，或强制的测试执行阶段）。因此，在我们的设定中，测试在运行时仍是可选的：模型可以遵循、推迟或忽略该建议，而是否测试、何时测试以及如何测试，仍由模型决定。相应地，任何被观察到的行为（例如创建或运行测试产物）都可以被解释为模型原生的行为。

我们选择一组多样化的强 LLM，以在 mini-SWE-agent 下捕捉异质的智能体测试编写行为。模型选择上，我们使用 SWE-bench Bash Only 排行榜，截止日期为 2025-12-11。[^1] 我们识别排名前六的模型家族（而不是前若干条目，因为一个家族可能以多个变体出现在排行榜上）。对每个家族，我们以其排名最高的模型作为代表：

• claude-opus-4.5（Anthropic, 2025）（74.4%）
• gemini-3-pro-preview（Google Cloud, 2025）（74.2%）
• gpt-5.2（OpenAI, 2025）（71.8%）
• kimi-k2-thinking（Moonshot AI, 2025）（63.4%）
• minimax-m2（MiniMax, 2025）（61.0%）
• deepseek-v3.2-reasoner（DeepSeek, 2025a）（60.0%）

在本文其余部分，我们将这些模型分别称为 Claude Opus 4.5、Gemini 3 Pro、GPT-5.2、Kimi K2 Thinking、MiniMax M2 与 DeepSeek v3.2 Reasoner。在表格与图中，为节省篇幅，我们进一步把 Claude Opus 4.5、Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner 简写为 Claude 4.5、Kimi K2-T 与 DeepSeek v3.2-R。在每一种情况下，简写形式仍能唯一标识本研究中所评估的官方模型版本，而不会与另一模型发布产生歧义。

2.3. 智能体编写测试的数据抽取

在本研究中，智能体编写的测试是智能体在任务求解过程中使用 bash 工具写出的测试文件。我们从任务轨迹中抽取这些测试。轨迹是问题解决期间记录的、按时间排序的交互日志，其中包括智能体的中间推理、具体行动（例如 bash 命令）以及由此产生的观察。为找到轨迹中写出的测试文件，我们扫描所记录的 bash 行动中的文件写入操作，这里最常见的是 here-doc 写入，例如 cat <<’EOF’ > path/to/file.py …EOF。然后我们只保留路径符合常见 Python 测试命名模式的文件，包括文件名以 test_ 开头，或以 _test.py 或 tests.py 结尾（pytest developers, 2026）。

2.4. 实现细节

我们使用官方 mini-SWE-agent 代码库运行全部实验。所有任务在一台 Linux 服务器（Ubuntu 22.04.5）上执行，配置为 AMD Ryzen Threadripper PRO 7975WX CPU（32 核／64 线程）、251 GiB 内存。模型推理方面，我们通过官方提供商 API 与 OpenRouter API 的组合访问 LLM。评估方面，我们使用官方 SWE-bench 的 sb-cli 工具，在基准框架下为每个提交的补丁打分。本文报告的全部实验中，LLM API 总成本约为 1600 美元。

3. RQ1：在轻量智能体脚手架下会出现何种测试行为？

动机。

在测试可选的高自主设定中，智能体在问题解决过程中可能编写测试，也可能不编写。RQ1 为这些涌现出的测试行为建立描述性基线——智能体编写何种测试、何时引入它们，以及运行它们的强度如何。该基线（i）澄清在本设定中“测试”看起来是什么样，（ii）为后续研究问题提供有依据的行为变量。

实验设计。

RQ1 以已解决轨迹相对于未解决轨迹作为比较视角，以刻画测试相关行为中的系统性差异。我们强调，这些按结果分层的比较并非意在就任务成功建立因果关系；相反，它们作为诊断工具，用来显现成功与不成功解题过程之间在测试实践上的一致差异。RQ1 报告测试导向行为的三个互补方面的描述性汇总：

• 频率（RQ1.1）：智能体是否编写测试，以及编写多少。
• 时机（RQ1.2）：测试编写发生在问题解决过程中的何时。
• 执行（RQ1.3）：测试被运行的强度如何，以及其结果如何。

3.1. RQ1.1 频率：智能体是否编写测试产物？

目标与度量。

我们考察基础 LLM 在轻量脚手架下是否编写测试产物。对每个任务，我们记录（i）智能体是否至少写出一个测试产物，以及（ii）若是，它写出多少个互不相同的测试产物。我们分别报告已解决任务与未解决任务的结果。

表 1. 按执行结果划分的各模型测试编写率

注。“含测试的任务”报告每个结果划分内的计数与百分比。“平均测试数”仅在至少写出一个测试产物的任务上计算。

结果。

表 1 表明，对大多数模型而言编写测试很常见，但对 GPT-5.2 并非如此。一些模型几乎在每个任务中都编写测试（例如 MiniMax M2 与 Kimi K2 Thinking）。相比之下，GPT-5.2 几乎从不编写测试（500 个任务中仅 3 个）。在同一模型内部，已解决任务与未解决任务通常具有相近的测试编写率。当测试被写出时，未解决任务写出的互不相同测试产物数量，常常不少于、甚至多于已解决任务。这可能反映更难的任务会触发更多试错。

RQ1.1 测试编写：关键模式

在这一高自主设定中，对大多数模型而言编写测试很常见，但 GPT-5.2 是一个明显的离群点，测试编写接近于零。

3.2. RQ1.2 时机：运行过程中测试何时被写出？

目标与度量。

除测试是否被写出之外（RQ1.1），我们考察测试编写发生在任务执行过程中的何时。在一个很窄的窗口内编写测试，看起来像短暂的“检查阶段”；而贯穿整个任务编写测试，则看起来像迭代调试。本小节是描述性的，并不声称有效性。我们只分析至少写出一个测试产物的任务，从而使时机指标有定义。由于 GPT-5.2 仅在 3 个任务中编写测试（RQ1.1），我们在 RQ1.2 中省略其分模型时机汇总，以避免不稳定的估计。我们在后续要求“存在测试编写的任务”的分析中也同样排除它。我们使用任务内的三个归一化位置：首次编写测试的位置、末次编写测试的位置，以及二者的跨度：

$$ t_{\text{first}}=\frac{\min(S_{\text{write}})}{N_{\text{steps}}},\quad t_{\text{last}}=\frac{\max(S_{\text{write}})}{N_{\text{steps}}} $$

$$ s_{\text{write}}=t_{\text{last}}-t_{\text{first}}=\frac{\max(S_{\text{write}})-\min(S_{\text{write}})}{N_{\text{steps}}} $$

其中，$S_{\text{write}}$ 是智能体写出测试产物的步骤索引集合，$N_{\text{steps}}$ 是该任务中交互步骤的总数。$t_{\text{first}}$ 与 $t_{\text{last}}$ 是 $[0,1]$ 内的归一化位置。较小的值意味着智能体在任务中更早编写测试；较大的值意味着更晚。跨度 $s_{\text{write}}\in[0,1]$ 度量测试编写在任务中分散的程度。较大的值意味着测试编写更分散；较小的值意味着更集中的窗口。

表 2. 各模型测试编写事件的时机

注。“按任务宏平均”是指在含测试的任务上取平均。星号标记同一模型内已解决与未解决之间的显著差异（双侧 Mann–Whitney U 检验：\* $p<0.05$，\\ $p<0.01$，\\\* $p<0.001$）。

结果。

表 2 汇总了写出测试的任务上的测试编写位置。跨全部模型，平均首次测试编写位置在已解决任务上为 0.40，在未解决任务上为 0.37。平均末次测试编写位置在已解决任务上为 0.78，在未解决任务上为 0.80。模型在何时开始编写测试上存在差异。例如，Gemini 3 Pro 开始得更晚（0.53–0.55），而 MiniMax M2 与 Claude Opus 4.5 开始得更早（0.29–0.35）。大多数模型在任务较晚阶段结束测试编写（末次位置大约在 0.75–0.86）。模型在测试编写的分散程度上也有差异。Gemini 3 Pro 的跨度较短（0.14–0.15）。MiniMax M2 的跨度更宽（0.51–0.56），Claude Opus 4.5 也相对较宽（0.41–0.48）。Kimi K2 Thinking 在已解决与未解决任务之间几乎相同（0.40–0.82；跨度 0.42）。总体而言，未解决任务的平均跨度略大于已解决任务（0.43 对 0.38）。

RQ1.2 测试编写时机：关键模式

测试编写通常结束得很晚，而其开始时间与跨度主要依赖模型；未解决任务只是略微更分散。

3.3. RQ1.3 执行：智能体编写的测试被执行的强度如何，过程结果又如何？

目标与度量。

RQ1.3 描述智能体在写出测试之后如何执行它们。我们度量（i）测试被执行的频率，（ii）相对于已写出测试产物数量，测试被重跑的频率，以及（iii）执行在过程层面失败的频率。若一次执行以非零返回码结束，我们将其视为失败（否则视为成功）。这捕捉的是与环境交互期间的执行摩擦，而不是补丁正确性。

对每个任务 $t$，令 $E_t$ 为测试执行次数，$A_t$ 为智能体编写的测试产物数量，$F_t$ 为返回码非零的执行次数。我们报告三个任务级指标：ExecCount（$E_t$），即每任务的测试执行次数；ExecPerTest（$E_t/A_t$），即每个已写出测试产物的执行次数（重跑强度）；以及 FailRate（$F_t/E_t$），即失败执行所占比例。我们对每个指标报告按任务宏平均的均值。

表 3. 智能体编写测试的任务级执行投入与过程级结果

注。任务数：存在测试编写的任务；其余数值均为按任务宏平均的均值。星号标记同一模型内已解决与未解决之间的显著差异（双侧 Mann–Whitney U 检验：\* $p<0.05$，\\ $p<0.01$，\\\* $p<0.001$）。

结果。

表 3 汇总了写出测试的任务上的执行投入与过程级结果。跨全部模型，未解决任务执行测试的次数多于已解决任务（平均 ExecCount：6.52 对 4.89）。它们相对于每个已写出测试产物的重跑次数也更多（平均 ExecPerTest：1.70 对 1.46）。Mann–Whitney U 检验表明，这些汇总层面的已解决与未解决差异，对 ExecCount 与 ExecPerTest 在统计上显著，但对 FailRate 不显著。在模型层面，显著差异主要出现在 Claude Opus 4.5（未解决任务的 ExecCount 更高）与 MiniMax M2（未解决任务的 ExecCount 与 ExecPerTest 更高）。未解决任务的 FailRate 略高（21.05% 对 19.68%），但这一汇总差异在统计上不显著。模型在执行强度上差异很大。Gemini 3 Pro 运行测试最少（ExecCount $\approx$ 2.7–2.8）。MiniMax M2 运行测试最多，尤其是未解决任务（ExecCount 9.70；ExecPerTest 2.09）。FailRate 也因模型而异。Claude Opus 4.5 与 Gemini 3 Pro 的 FailRate 较低（约 7–12%），而 DeepSeek v3.2 Reasoner、Kimi K2 Thinking 与 MiniMax M2 较高（约 21–30%）。

RQ1.3 测试执行：关键模式

对写出测试的任务而言，未解决运行更密集地执行它们，且这些汇总差异在统计上显著；而过程级执行失败主要随模型而变化。

3.4. RQ1 小结

RQ1 表明，智能体编写的测试更应被理解为一种依赖模型的过程行为，而不是最终成功的简单标记。这进而为 RQ2 提出一个更有信息量的问题：当这些测试确实出现时，它们实际上提供了何种反馈？

4. RQ2：智能体编写的测试提供何种反馈信号？

动机。

在测试可选的高自主设定中，测试可能因其执行时发出的反馈而扮演不同角色。RQ1 把测试视为轨迹中的事件——智能体是否编写它们、它们何时出现，以及它们被运行的频率。RQ2 转向这些测试的内容：它们在执行期间产生的反馈。我们通过智能体编写测试中两种常见信号来捕捉这一反馈：断言（条件被违反时失败）与揭示取值的打印（暴露运行时取值）。这一视角澄清了智能体在解决 GitHub 问题时把测试用于什么。

实验设计。

RQ2 以至少写出一个测试产物的任务为条件，并报告测试反馈三个方面的描述性汇总：

• 信号计数（RQ2.1）：智能体编写测试中的断言数量相对于揭示取值的打印数量。
• 断言类型（RQ2.2）：智能体编写测试中出现何种断言，采用四类划分。
• 打印类型（RQ2.3）：揭示取值的打印通常检查什么，采用三类划分。

RQ2.1 停留在任务层面，度量智能体编写的测试总体上发出多少反馈。RQ2.2 与 RQ2.3 随后进入语句层面，分别对断言语句与揭示取值的打印语句进行分类。

4.1. RQ2.1 任务级反馈信号量：智能体编写的测试编码了多少反馈？

目标与度量。

以包含智能体编写测试产物的任务为条件，我们量化这些产物中编码了多少条反馈语句。我们区分两类信号：（i）验证信号（$A$），即规定显式检查的 assert 语句；（ii）观察信号（$P$），即暴露运行时取值或计算表达式的、揭示取值的打印语句。为确保 $P$（打印）反映的是观察性反馈，我们排除只输出固定字符串的纯字面量打印（例如 print("here")），只计数暴露运行时取值、表达式或执行结果的打印（例如 print(obj.attr)）。对每个带有测试产物集合 $\mathcal{A}_t$ 的任务 $t$，以及对信号类型 $S\in\{A,P\}$，令 $n^{S}_{t,a}$ 为产物 $a\in\mathcal{A}_t$ 中类型 $S$ 的信号语句数量。我们定义任务级信号总量：

$$ N^{S}_{t}=\sum_{a\in\mathcal{A}_{t}}n^{S}_{t,a},\qquad N^{\mathrm{total}}_{t}=N^{A}_{t}+N^{P}_{t}. $$

我们报告各模型在已解决任务与未解决任务上分别计算的、$N^{A}_{t}$（断言计数）、$N^{P}_{t}$（揭示取值的打印计数）与 $N^{\mathrm{total}}_{t}$（总体信号计数）的按任务宏平均均值。

表 4. 编码在智能体编写测试中的任务级反馈信号量

注。按任务宏平均的均值在含测试的任务上计算。断言计数 assert 语句；打印计数揭示取值的打印。$\bar{N}^{\mathrm{total}}=\bar{N}^{A}+\bar{N}^{P}$。

图 2. 各模型智能体编写测试中反馈信号的构成。

结果。

表 4 表明，当存在智能体编写的测试时，每个任务可以包含相当数量的反馈语句。如图 2 所示，反馈以观察性为主：对每个模型，揭示取值的打印在每任务宏平均计数上都超过断言。信号量也随模型显著变化，从 Gemini 3 Pro 较低的总量，到 MiniMax M2 高得多的总量。跨模型来看，未解决任务往往显示出略高的信号总量，主要由更多的揭示取值打印驱动，而断言计数相对稳定。

RQ2.1 测试信号量：关键结论

当智能体编写测试时，反馈大多是观察性的：揭示取值的打印数量持续多于断言，尽管信号总量仍随模型显著变化。

4.2. RQ2.2 断言分类：断言编码了何种验证？

目标与度量。

RQ2.1 计数智能体编写测试中出现多少条 assert 语句，但仅有计数并不能告诉我们这些断言检查什么。断言可以强制不同类型的检查——例如基本前置条件（如非 None 或类型检查），相对于针对期望取值或结构的检查。因此，模型之间的差异可能不仅在于它们断言的频率，也在于它们写出何种形式的检查。RQ2.2 把 assert 语句描述性地分解为四个断言类别：

• C1 健全性检查（sanity checks）。 断言只检查存在性或类型，而不约束期望行为。示例：assert x is not None。
• C2 性质检查（property checks）。 断言检查某个取值或对象的性质（例如成员关系或有效性），而不固定一个精确输出。示例：assert hasattr(obj, "attr")。
• C3 关系检查（relational checks）。 断言强制某种约束，例如范围、界限，或取值之间的关系。示例：assert 0 <= score <= 1。该类别也包括期望特定异常的检查，因为它们把允许的行为约束为“必须以类型 $E$ 的异常失败”，而不是匹配单一具体输出。
• C4 精确检查（exact checks）。 断言检查精确取值或深层结构相等。示例：assert output == expected_output。

为识别并分类断言，我们在 Python AST 上实现一个基于规则的分类器，并把每条断言映射到恰好一个类别。该分类器同时覆盖原生 assert 语句（例如 assert a == b）与框架提供的断言调用（例如 unittest 中的 self.assertEqual(a, b)）。具体而言，对每个测试产物，我们把代码解析为 AST，并从以下来源抽取断言事件：（i）原生 assert <expr> 语句；（ii）对框架断言 API 的调用。有些 assert 语句在一行中用布尔运算符包含多项检查（例如 assert a > 0 and b == 1）。在该例中，a > 0 是约束检查（C3），b == 1 是精确检查（C4）。对此类复合 assert 语句，我们把表达式分解为原子检查，并按从 C1 到 C4 的序取最高类别，从而赋予单一类别，因为语句中最具体的检查最能反映该断言试图强制的内容。因此，assert a > 0 and b == 1 被标为 C4。

表 5. 按模型划分的断言类别分布。计数与百分比在每个模型所写的全部断言语句上计算。

注。C1–C4 表示由检查形式所定义的四个断言类别（健全性、性质、关系／近似，以及精确输出）。百分比在每个模型内部、相对于该模型的断言总数计算。

结果。

表 5 表明，各模型的断言类别分布大体相似。在全部五个模型中，大多数断言落入 C2 性质与 C4 精确，而 C3 关系始终不常见。对四个模型（Claude Opus 4.5、Gemini 3 Pro、Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner），C4 精确约占断言的 41–43%（40.85–42.91%），C2 性质约占 34–41%（33.62–41.25%）。MiniMax M2 遵循相同的总体形状，但分配给 C4 精确的份额更小（34.52%），分配给 C1 健全性（19.83%）与 C2 性质（41.42%）的份额更大。跨全部模型，C3 关系很少见（2.98–7.86%），比例最高的是 Gemini 3 Pro（7.86%）。这种稀缺表明，智能体更常退回到局部性质检查（C2）或精确期望输出（C4），而关系或近似约束可能更难规定，在模型所模仿的测试模式中也不那么常见。我们把这些分布视为对智能体编写测试中出现哪些断言形式的描述，而不是正确性或对任务解决之影响的证据。

RQ2.2 断言分类：关键结论

跨模型来看，断言以性质检查与精确取值检查为主，而关系或范围式约束仍然不常见。

4.3. RQ2.3 打印分类：揭示取值的打印通常检查什么？

目标与度量。

由于揭示取值的打印在数量上大幅超过断言，我们进一步检查这些打印在实践中暴露什么。这有助于澄清智能体编写的测试主要是用于检查取值、检查结构摘要，还是呈现执行状态，从而细化我们把测试视为观察性调试工具的解释。我们把揭示取值的打印分为三类：

• P1 取值／内容检查。 打印检查一个具体的运行时取值或内容，例如返回的输出、中间结果、对象字段，或生成字符串的一部分。当打印意在揭示程序产生了什么，而不是结构摘要或错误／状态信号时，使用该类别；例如 print(add(1, 2))。
• P2 结构摘要检查。 打印报告一个聚合的结构摘要，例如长度、大小、形状、条目数量或是否为空。该类别保留给那些概括“有多少数据”或“它具有何种结构”、而不是展示内容本身的打印；例如 print(len(items))。
• P3 异常／执行状态信号。 打印呈现异常、错误消息，或粗粒度的执行状态指示，例如成功／失败标志。当打印主要表明执行期间发生了什么，而不是程序计算出的内容时，使用该类别；例如 except Exception as exc: print(exc)。

我们在 Python AST 上实现一个基于规则的分类器。对每个可解析的测试产物，我们抽取揭示取值的 print(...) 调用，排除纯字面量或仅用于格式化的打印，并使用确定性的类别规则把每条打印指派到上述三类之一。

表 6. 按模型划分的揭示取值打印的类别分布

结果。

表 6 显示出跨模型稳定的模式。对每个模型，P1 取值／内容检查都占主导（69.67–77.48%），表明大多数打印被用来检查具体输出、中间取值或对象内容。P3 异常／执行状态信号构成第二大类别（19.06–25.00%），而 P2 结构摘要检查相对不常见（3.46–6.56%）。总体而言，揭示取值的打印主要用于检查运行时取值与粗粒度执行结果，而不是编码强的通过／失败判据，这强化了我们把智能体编写的测试解释为观察性调试工具的看法。

RQ2.3 打印分类：关键结论

跨模型来看，大多数揭示取值的打印用于取值／内容检查，异常／执行状态信号以较大差距位居第二。结构摘要少得多，这强化了如下判断：这些打印主要作为观察性调试探针，而不是强正确性预言。

4.4. RQ2 小结

RQ2 表明，智能体编写的测试主要作为观察性反馈通道发挥作用：揭示取值的打印占主导，而确实出现的断言集中在局部性质检查与精确取值检查。这自然引出下一个问题：这些智能体编写的测试是否切实影响任务解决？

5. RQ3：提示编写测试如何改变所观察的结果与成本？

动机。

在 RQ1 中，我们发现在这一高自主设定下，智能体编写的测试与最终任务成功之间只有弱对齐。例如，GPT-5.2 几乎从不编写新测试产物（500 个任务中的 3 个，占 0.6%），但仍解决了 71.8% 的任务。相比之下，Claude Opus 4.5 在约 83% 的任务中至少写出一个新测试产物，但其解决率只高出 2.6 个百分点（74.4%）。RQ2 进一步表明，当测试被写出时，大多数反馈来自揭示取值的打印，而不是基于断言的检查。这些发现提出一个直接问题：当提示词改变智能体是否编写测试时，本设定中所观察到的任务结果与成本如何变化？

实验设计。

RQ3 回答两个问题：

• RQ3.1（结果变化）：若我们鼓励或抑制智能体编写测试，所观察到的任务解决结果如何变化？
• RQ3.2（效率变化）：若我们鼓励或抑制智能体编写测试，API 调用与词元用量如何变化？

模型选择。

为探究在同一脚手架下，提示编写测试如何改变所观察的行为，我们设计两项互补的干预实验：（i）鼓励智能体编写测试；（ii）抑制智能体编写新测试文件。我们根据 RQ1（表 1）中观察到的基线测试编写率来为每种设定选择模型，该比率定义为智能体写出测试产物的任务所占比例。

对于鼓励编写测试的设定，我们聚焦于低测试编写模型与中等测试编写模型，从而存在有意义的上调空间来增加测试创建。我们不把已经高度依赖测试的模型纳入该设定，因为它们的基线测试编写率几乎没有有意义的上移空间。具体而言，我们纳入 GPT-5.2（0.6%），它是 RQ1 中测试创建接近于零的极端低测试编写模型。我们也纳入 Gemini 3 Pro（61.1%），这是一个中等测试编写模型，其基线测试创建已经相当可观，但仍留有进一步增加的空间。

对于抑制编写测试的设定，我们从在 RQ1 中于绝大多数任务上编写测试的高测试编写模型出发：四个模型表现出持续较高的测试编写率（83.0%–98.6%；表 1）。由于预算限制，我们从该组中选择两个代表：Kimi K2 Thinking（97.4%）与 DeepSeek v3.2 Reasoner（89.2%）。

具体而言，我们从原始 mini-SWE-agent 提示词出发，做小而有针对性的提示词编辑，形成两个变体：

• 鼓励编写测试：对 GPT-5.2 与 Gemini 3 Pro，我们追加提示指令，要求至少编写一个可运行的新测试文件（文件名以 test_ 开头或以 _test.py 结尾），并与仓库中已有测试分开。
• 抑制编写测试：对 Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner，我们移除 mini-SWE-agent 中默认的测试相关提示线索，并追加提示指令，要求不要编写任何新的测试文件或脚本。

原始提示词与两个修订变体的准确文本包含在 experiment_prompts 文件夹中。[^2] 我们把每个修订提示词与其基线比较，以度量提示词的改变如何伴随着测试编写、结果与成本的变化。

5.1. RQ3.1 鼓励或抑制测试编写如何改变所观察的任务结果？

目标与度量。

为回答鼓励或抑制测试编写如何改变所观察的任务结果，对每个模型，我们在两种条件下比较每个任务：基线运行（使用标准 mini-SWE-agent 提示词）与干预运行（使用我们修订后的提示词）。具体而言，我们记录两个特征：该次运行是否至少创建一个新测试产物（无测试相对于有测试），以及补丁是否成功解决问题（失败相对于成功）。然后，我们分析这两个特征从基线运行到干预运行如何变化。这分别对测试编写与任务结果产生四个可能的转移组：测试编写为无测试→无测试、无测试→有测试、有测试→无测试、有测试→有测试；任务结果为失败→成功、成功→失败、稳定成功与稳定失败。为评估干预是否改变同一任务集合上的结果比率，我们进行精确 McNemar 检验，它检查失败→成功与成功→失败是否以有意义的不同数量出现。为可视化这些转移之间的关系，我们用转移矩阵表示结果。在该矩阵中，行表示测试编写行为的变化，列表示任务结果的变化。这一结构使我们能够定位在每种提示条件下结果变化出现在何处。例如，无测试→有测试与失败→成功的交叉，代表鼓励编写测试与从基线到干预的改进同时出现的任务。

表 7. 测试编写状态翻转与结果转移

鼓励编写测试

模型：GPT-5.2（$p=1.000$）。目标变化列 $\Delta$ 322（64.4%）。

模型：Gemini 3 Pro（$p=0.522$）。目标变化列 $\Delta$ 185（37%）。

抑制编写测试

模型：Kimi K2-T（$p=0.228$）。目标变化列 $\Delta$ 342（68.4%）。

模型：DeepSeek v3.2-R（$p=0.435$）。目标变化列 $\Delta$ 376（75.2%）。

注。测试状态由该次运行是否至少写出一个测试产物来定义（“有测试”表示写出至少一个，“无测试”表示一个也未写出）。列表示基线→干预的测试状态转移；行表示基线→干预的结果转移（失败／成功）。高亮列表示预期的测试状态变化（绿色：鼓励条件下的无测试→有测试；红色：抑制条件下的有测试→无测试）；$\Delta$ 报告该预期变化列中的任务数（及百分比）。成功数净变化按列计算为（失败→成功的数量）减去（成功→失败的数量）。模型级 $p$ 值报告精确 McNemar 检验。

图 3. 发生预期测试状态变化的任务上的结果转移分布。

结果。

我们的提示词干预大幅改变了模型是否编写测试产物，但这些转移很少转化为结果变化。如表 7 所示，鼓励编写测试的提示词翻转了低测试编写模型 GPT-5.2 与中等测试编写模型 Gemini 3 Pro 的测试状态：分别有 64.4% 与 37.0% 的任务从无测试转移到有测试。反过来，抑制编写测试的提示词大规模移除了高测试编写模型 Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner 的测试，使 68.4% 与 75.2% 的任务从有测试转移到无测试。

尽管测试状态有这些大幅转移，解决结果大体稳定。图 3 表明，跨模型平均而言，83.2% 的任务在干预后保持相同的最终解决结果。表 7 进一步表明，即便测试状态翻转，成功率也只略有变化。精确 McNemar 检验强化了这一描述性图景：四个模型中没有一个显示出统计显著的基线相对于干预的结果转移（全部 $p>0.05$）。例如，对 DeepSeek v3.2 Reasoner，抑制测试编写在 376 个任务中移除了测试，但已解决任务只净减少 20 个，相对于行为转移而言这是一个小变化。总体而言，在本设定中，改变模型编写测试产物的频率，看起来是撬动任务结果的一个弱杠杆。

#### 5.1.1. 探索测试可能有帮助的问题类型

作为探索性后续，我们进一步询问：测试是否对某些类型的 GitHub 问题更有帮助。为获得一个初步的粗信号，在鼓励测试的提示词下，我们考察 GPT-5.2 与 Gemini 3 Pro 中从无测试→有测试、并且同时从失败→成功的任务（分别为 18 个与 9 个问题）。在抑制测试的提示词下，我们考察 Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner 中从有测试→无测试、并且同时从成功→失败的任务（分别为 42 个与 49 个问题）。若同一问题出现在两类之中，我们将其视为测试的存在可能重要的候选情形。

结果。

我们发现 8 个问题同时出现在两类之中：astropy-13236；django-11790、django-13401、django-13512 与 django-14493；pylint-7080；scikit-learn-14629；以及 sympy-21612。我们人工阅读了这 8 个问题的问题陈述，并使用 GPT-5.4 帮助概括反复出现的主题。这一探索性检视提示出三个反复出现的性质：它们大多是小到中等规模的正确性缺陷，常常涉及明确的复现条件或边界情况触发器，并且经常需要检查精确的期望行为或语义。

这些观察必然是有限的。SWE-bench Verified 总共包含 500 个任务，该基准不提供官方的问题分类体系，而我们的跨类别重叠只包含 8 个实例。因此，我们把本小节呈现为超出主要干预结果的一个探索性步骤，意在显现看似对测试敏感的候选，而不是确立确定性的问题类别。基于更广分类体系的分析留待未来工作。

RQ3.1：结果相对于测试状态变化

提示词干预可以大规模翻转测试编写状态，但大多数任务保持相同的最终结果。因此，即便是被诱导或被抑制的测试编写大幅转移，在本设定中看起来也只是撬动任务解决的弱杠杆。

5.2. RQ3.2 API 调用与词元用量如何变化？

目标与度量。

我们进一步基于 RQ3.1 中生成的轨迹分析以下三个指标：（i）每任务平均 API 调用次数；（ii）每任务平均输入词元数；（iii）每任务平均输出词元数。对每个模型与每个指标，我们在相同的 500 个任务上比较干预运行与基线运行。为量化所观察到的效率变化在方向上是否稳健，我们额外计算双侧 Wilcoxon 符号秩检验，以及任务级差值（条件 − 基线）的 95% 配对自助法置信区间。

表 8. 基线相对于鼓励测试／抑制测试条件下的 API 调用与词元用量

注。变化按（条件 − 基线）计算。鼓励测试应用于 GPT-5.2 与 Gemini 3 Pro；抑制测试应用于 Kimi K2-T 与 DeepSeek v3.2-R。\\\* $p<0.001$，来自配对 Wilcoxon 符号秩检验；配对自助法置信区间在正文中汇总。

结果。

表 8 表明，这些干预对解决率只有边际影响，但可以明显重塑效率。在鼓励编写测试之下，低测试编写模型 GPT-5.2 承担更高开销（API 调用 +5.5%；输出词元 +19.8%），而解决率没有任何增益。配对分析支持全部三个指标上的这一增加：API 调用每任务增加 +1.08（95% 置信区间 [0.39, 1.75]，Wilcoxon $p<0.001$），输入词元增加 +21,907（[3,954, 39,598]，$p<0.001$），输出词元增加 +4,866（[3,041, 6,704]，$p<0.001$）。相比之下，中等测试编写模型 Gemini 3 Pro 总体变化很小，其在 API 调用、输入词元或输出词元上的配对差异均未达到常规显著性（全部 95% 置信区间跨过零）。最显著的转移出现在高测试编写模型 Kimi K2 Thinking 与 DeepSeek v3.2 Reasoner 的抑制编写测试条件下：输入词元分别下降 49.0% 与 32.9%，并且 Kimi K2 Thinking 的 API 调用也减少 35.4%。这些下降在配对分析中方向稳健：对两个模型，三个均值差均为负，全部 95% 自助法置信区间都不包含零，并且全部 Wilcoxon 检验给出 $p<0.001$。因此，这些配对结果加强了如下解释：在这两个高测试编写模型中，抑制测试编写带来可观的效率节省；而鼓励测试编写所产生的成本效应依赖模型，并且稳定得多。

RQ3.2：成本变化大于结果变化

改变智能体是否编写测试，对效率的影响远大于对任务解决的影响。配对 Wilcoxon 检验与自助法置信区间支持抑制设定下的大幅节省；而鼓励设定下的效应对 GPT-5.2 是稳健的，对 Gemini 3 Pro 则很小且在统计上不清晰。

RQ3 小结。

总体而言，改变智能体编写测试的数量会强烈重塑资源使用，但对最终补丁是否解决问题只有有限的杠杆。在这一高自主设定中，更多测试并不意味着更多解决；但它们可能施加可观的交互开销。

6. 讨论与未来工作

6.1. 启示

我们的结果提示三点实践启示。对实践者而言，目标不应只是让智能体编写更多测试，而应使测试更有针对性、并且对预算有意识。一种轻量做法是把可复用的测试行为打包为聚焦的 Claude Code 子智能体／技能（Anthropic, 2026b；Anthropic, 2026a），例如生成一个最小回归测试、通过把打印转换为断言来加强薄弱的预言，或只运行最小的相关测试切片。分别记录测试编写、测试运行与失败分析的成本也很有用，以便团队看到额外的测试相关交互何时不再增加价值。对研究者而言，主要启示是把测试作为过程干预来研究，而不仅仅作为最终成功率的差异。除报告结果转移之外，未来研究应追踪验证预算花费在测试编写、测试执行、失败检查与补丁修订上的何处。实践中，这可以用可观测性工具完成，例如 LangSmith 追踪（LangChain, 2026），从而更容易追问测试何时有帮助、何种反馈有用，以及更便宜的验证行为何时可能已经足够。

对基准使用者与维护者而言，我们的研究指向一个更窄的度量关切。在其 2026 年 2 月 23 日的文章《Why SWE-bench Verified no longer measures frontier coding capabilities》（为何 SWE-bench Verified 不再衡量前沿编码能力）中，OpenAI 认为 SWE-bench Verified 已变得更难解释，因为污染与残留的基准设计问题削弱了最终分数的含义（OpenAI, 2026）。我们并不直接评估那些基准层面的主张，也不检验污染或训练数据效应。我们的证据支持一个更有限的观点：即便最终解决率变化很小，智能体在编写测试的频率、花费的验证预算，以及其软件工程行为如何展开上，仍可能差异很大。这表明，SWE-bench Verified 上的最终解决率作为智能体行为的独立度量过于粗糙，最好与对过程敏感的指标一并解释。

6.2. 未来工作

我们的结果引出两个未来方向。在非平稳代码状态下评估即兴测试质量。 传统测试质量指标（例如覆盖率、变异分数、故障揭示）假定被测系统有固定快照，并且执行可复现（Yu et al., 2023；Ryan et al., 2024；Shin et al., 2024；Bhatia et al., 2024；Yang et al., 2024b；Molinelli et al., 2025；Harman et al., 2025）。在智能体式开发中，测试是针对中间仓库版本编写并运行的，而这些版本后来可能被覆盖，从而使归因与可复现性变得复杂。因此，未来工作应发展在执行时进行的插桩与指标，使它们对短暂的中间产物仍然有意义。自演化的测试生成策略。 一个有前景的方向是自演化（Robeyns et al., 2025；Zhang et al., 2025a；Xia et al., 2025；Hu et al., 2025）的测试策略：智能体根据环境反馈与失败模式修订自己的测试提示词或策略，而不是遵循静态的手写提示词（Gao et al., 2025a）。未来工作可以在成本与安全约束下把这形式化为闭环优化，并在匹配的预算与受控脚手架下比较人工指定的策略与自适应策略。

6.3. 效度威胁

内部效度。 智能体运行可能因随机解码以及工具／环境的非确定性而变化，这可能同时影响测试行为与解决结果。此外，成功—失败比较可能反映任务难度或交互长度上的差异（例如调试时长），而不仅仅是测试。我们通过以下方式缓解这些关切：把观察结果视为描述性的；只使用提示词干预并保持智能体设置固定；以及报告任务级结果转移，而不仅仅是汇总的解决率差值。

外部效度。 我们的发现基于轻量脚手架下的 SWE-bench，以及一组特定的模型与提供商；绝对幅度在其他基准、编程语言、工具链（例如强制的持续集成）或未来模型版本下可能不同。为支持迁移，我们聚焦于在类似智能体设定中可能反复出现的模式（例如测试风格上巨大的跨模型差异、以观察为主的反馈，以及在测试创建大幅转移下有限的结果敏感性），并提供精确的度量定义与干预提示词以供复现。

数据构建效度。 度量依赖于显式的操作定义与自动抽取。测试采用通过新创建的、类似测试的文件来检测；反馈信号通过针对断言与承载取值的打印的确定性 AST 规则来抽取，其中包括常见的辅助风格断言 API，以及对断言形式的分层分类体系。这些流程可能遗漏非常规的测试产物、项目特定的辅助函数，或边界情形的语法模式。我们通过 AST 解析、对承载取值打印的保守计数规则，以及确定性的抽取与分类来减少构建误差；尽管如此，结果仍应相对于这些定义来解释。

7. 相关工作

对 LLM 生成测试的评估。

既有工作在预定义目标下评估 LLM 生成的测试产物，最常见的是单元测试与断言，途径包括关于测试套件质量以及模型／提示词改进的系统与实证研究（Lops et al., 2025；Yuan et al., 2024；Schäfer et al., 2023；Li et al., 2025；Yang et al., 2025），也包括有针对性的预言生成，例如断言（Zhang et al., 2025b）。近期综述进一步系统化这一领域，总结需求产物如何被翻译为测试，以及用于评判所生成测试的质量准则（Yang et al., 2025）。作为对学术评估的补充，工业研究报道了闭环流水线，把基于 LLM 的测试生成与变异引导的反馈结合起来，以引导或精炼所生成的测试，使其具有更强的故障揭示能力（Harman et al., 2025）。这些研究通常用固定质量指标（例如覆盖率、基于变异的充分性代理、故障揭示）在固定的目标程序或代码快照上为输出打分。基准同样把测试塑造为带有固定任务与协议的独立目标（例如 TestEval（Wang et al., 2025）、SWT-bench（Mündler et al., 2024））。相比之下，我们的研究聚焦于在高自主、多步骤地解决真实世界 GitHub 问题的过程中动态涌现的智能体编写测试，其间代码库与候选补丁随时间演化。我们把测试编写与执行视为一种涌现的过程行为，并刻画这些测试所编码的信号，以及这些行为如何与解决结果相关。

软件智能体的轨迹分析。

近期工作超越最终补丁与二元的成功／失败，转而分析基于 LLM 的智能体的中间推理与执行轨迹。已有研究考察了区分成功运行与失败运行的行动—观察模式（Bouzenia and Pradel, 2025），比较了不同智能体的轨迹长度与故障定位准确率（Majgaonkar et al., 2026），并提出工作流分类体系，把智能体行为分解为定位、打补丁以及与测试相关的步骤等阶段（Ceka et al., 2025）。另一些工作进行系统性失败分析，识别诊断错误与无产出循环等根因（Liu et al., 2025）；而面向过程的研究进一步表明，智能体在问题解决期间常常遭遇反复出现的执行错误，从而促使人们为稳健性引入轻量检查与恢复组件（Chen et al., 2026）。总体而言，现有轨迹分析强调行动序列、结果分离与错误分类，但很少考察智能体是否以及如何自主决定去测试。我们的工作通过刻画涌现的测试行为，以及智能体编写的测试在问题解决期间所提供的反馈，来填补这一空白。

8. 结论

本文重新审视了一个常见直觉：在编写与运行测试并未在提示词中规定的高自主设定下，对基于 LLM 的软件智能体而言“测试有帮助”。跨越我们的三个研究问题，智能体编写的测试更应被理解为一种依赖模型的过程风格，而不是成功的可靠驱动因素：编写测试的倾向在模型之间差异悬殊；测试反馈以揭示取值的打印而不是断言为主；并且仅改变提示词中的测试编写线索，通常对所观察的任务结果影响很小，即便它们大幅改变了效率。总体而言，这些发现表明，在本设定中，智能体编写的测试往往更像一种习惯性的软件开发例程，而不是可靠的验证来源。更多智能体编写的测试并不意味着更多解决；它们更可靠地改变的是过程足迹——API 调用、词元用量与交互模式。因此，要提高测试对代码智能体的价值，可能需要更好的预言与更可操作的验证信号，而不是简单地诱导智能体编写更多测试。

9. 数据可用性

我们提供一个匿名的 Zenodo 复现包，其中包含本研究所用的数据集、原始轨迹、提示词文件与分析脚本。DOI：https://doi.org/10.5281/zenodo.19251470

[^1]: https://www.swebench.com/ 。我们识别排名前六的模型家族，而不是排名靠前的单个条目，因为一个家族可能以多个变体出现在排行榜上。

[^2]: 具体文件为 mini_swe_agent_original_prompt.yaml、encourage_write_tests_prompt.yaml 与 discourage_write_tests_prompt.yaml。

署名与许可

• 原文：Zhi Chen, Zhensu Sun, Yuling Shi, Chao Peng, Xiaodong Gu, David Lo, Lingxiao Jiang. Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents. arXiv:2602.07900
• 许可：原文以 CC BY 4.0 许可发布（https://creativecommons.org/licenses/by/4.0/）。
• 译者：智测团队