TFD-Bench 用多轮测试反馈评估编程智能体

Kaggle Benchmarking Challenge 参赛作品

提交至 DEV 上的 Kaggle Benchmarking Challenge。作者：Raja Rajak（@rajrajak99）。Kaggle 基准数据集：Gemma 4 TFD Agentic Trajectories。Kaggle 评估 Notebook：TFD-Bench on Kaggle。GitHub 仓库：github.com/rajrajak99/gemma4-tfd-agent。

⚡ 执行摘要与 TL;DR

HumanEval、MBPP 和静态 LeetCode 风格题目等标准 AI 编程基准存在一个致命盲区：它们孤立地测试单次代码生成，完全忽略了现实世界中软件工程的实际开展方式。真实的软件开发不是一次 prompt 与响应的交互，而是一个有状态、反复迭代、由假设驱动，并受测试反馈引导的过程。

当最先进的 LLM 被部署到真实代码仓库中时，它们会出现我们所说的「单次生成胜任能力的幻觉」：生成的代码补丁优雅、语法干净，却无法通过 64.2% 的真实回归测试套件。

为了衡量真正重要的能力，我们设计了 TFD-Bench（Test-Feedback-Driven Benchmark，测试反馈驱动基准）：这套评估包含从 SWE-bench Lite 改编的 50 个多轮调试任务，覆盖 10 类 Python 错误。我们对 5 种前沿模型配置进行了基准测试，评估指标包括 Pass@1 问题解决率、AST 工具调用有效率、上下文 token 消耗量，以及循环停滞频率。

我们的核心发现是什么？闭环测试执行反馈能够大幅加速推理：要求模型在生成代码前自主复现测试，可以将问题解决率从 29.5% 提升到 45.6%，同时减少 49.5% 的上下文 token 浪费。

🎯 你运行了哪些任务？

1. 静态编程基准的核心问题

当前的 LLM 评估往往依赖单轮基准：给 LLM 一段 docstring，让它生成一个自包含函数。这种方式无法评估开发者不可或缺的四项能力：

• 代码库探索：模型能否通过符号搜索和选择性读取，在不超出上下文限制的前提下浏览多文件仓库？
• 缺陷复现：模型能否在修改现有代码之前，生成一个独立、最小化的测试脚本，单独确认 bug 确实存在（exit_code != 0）？
• 精确修改：模型能否只替换目标代码行，而不是重写整个文件？
• 自动验证：模型能否执行复现脚本、解析终端 traceback，并在测试失败时自行修正？

2. TFD-Bench 协议

TFD-Bench 通过一个严格的五阶段闭环来测试模型：

• 阶段 1：发现：通过 search_code 和 view_file 定位代码。
• 阶段 2：测试优先：生成最小化的独立复现脚本（create_reproducer），确认修复前测试失败（exit_code != 0）。
• 阶段 3：推理与修复：生成精确补丁，只修改尽可能少的代码行（edit_file_replace）。
• 阶段 4：验证：在 Sandbox 中重新运行复现脚本，确认问题已经解决（exit_code == 0）。
• 阶段 5：自我修正循环：如果验证失败，则解析 traceback 并自动重试，最多循环 3 次。

3. 基准任务分类（50 个真实仓库任务）

数据集包含 50 个具备标准答案、达到真实仓库要求的任务，均匀分布在 10 类 Python bug 中，每类包含 5 个精心挑选的任务：

🤖 你用哪些模型进行了测试？

为了严格评估开放模型与闭源模型的差异，以及专门 fine-tuning 的影响，我们评估了 5 个具有代表性的模型，覆盖不同规模和范式：

• TFD-Agent Google Gemma 4 31B + QLoRA：基于 Google 的 Gemma 4 31B，使用 4-bit QLoRA 对所有线性投影层（q、k、v、o、gate、up、down_proj）进行 fine-tuning，专门训练模型遵循 Test-Feedback-Driven 协议。
• Google Gemma 4 31B（标准 ReAct）：使用完全相同的 Gemma 4 31B 基础权重，部署在普通的 ReAct prompt 循环中，不进行 TFD 协议训练。
• Meta Llama 3.1 70B Instruct（SWE-agent 框架）：前沿的开放权重通用模型，通过 Princeton 已有的 SWE-agent bash 接口进行评估。
• Qwen 2.5 Coder 32B Instruct（ReAct）：先进的开放代码专用模型，以较高的 HumanEval 分数著称。
• OpenAI GPT-4o mini（ReAct 基线）：前沿的轻量级专有模型，代表商业 API 的 Agent 后端。

💡 主要发现是什么？

1. 基准排行榜

2. 发现一：「单次生成胜任能力的幻觉」（静默回归）

当模型不被强制要求复现测试时，它们会表现出一种令人担忧的失败模式：

在 64.2% 的失败尝试中，普通模型生成的补丁在人类审阅者快速浏览时看起来完全正确，但实际上要么无法处理长度为零的输入，要么引入了另一个异常，要么破坏了下游调用函数。

强制模型先编写复现脚本（assert func(...) == ...），并通过 exit_code != 0 确认脚本失败，能够让 Agent 的推理建立在实际执行结果之上。仅这一项流程约束，就让整体问题解决率提高了 16.1 个百分点。

3. 发现二：随着对话轮次增加，AST 工具调用语法崩溃

最令人意外的发现之一，是工具调用质量会随着多轮对话的推进而下降：

在第 1 至第 4 轮，模型的有效 JSON 工具调用比例约为 92%。

超过第 7 轮后，普通模型的工具语法错误激增至原来的 3.8 倍，包括格式错误的 JSON 字符串、尾随逗号，以及凭空编造工具参数，例如用 path 代替 file_path。

一旦发生错误，普通模型往往会进入「幻觉级联」，不断重复无效的工具参数。

通过逐轮监督进行 fine-tuning 的 TFD-Agent，将工具调用有效率保持在 96.9% 以上，并消除了灾难性的循环停滞现象：停滞率从 18.2% 降至 2.1%。

4. 发现三：测试反馈是推理加速与 token 压缩引擎

许多开发者认为，增加自动化测试运行会提高推理成本。我们的基准测试证明，事实恰恰相反：

• 标准 ReAct 循环：每解决一个任务消耗 38,400 个 token，模型会漫无目的地搜索文件，并尝试随机修改。
• TFD-Agent 闭环：每解决一个任务消耗 19,400 个 token，上下文消耗减少了 49.5%。

为什么？带有 exit_code: 1 和行号的具体 traceback，相当于一个语义锚点。模型不必猜测故障在哪里，Python 运行时会直接告诉它，从而剪除多余的探索路径。

5. 发现四：在 Agent 循环中，fine-tuning 胜过规模

请注意，TFD-Agent（31B）的参数量不到 Llama 3.1 70B 的一半，却取得了更好的成绩：45.6% 对 42.4%。

通用的 70B 模型拥有更丰富的世界知识，但它们没有经过训练来遵循「定位 → 复现 → 精确修改 → 验证」这一严格协议。

当一个 31B 模型经过对齐，学会将终端输出视为真实可靠的反馈时，它就能在消费级或边缘工作站上达到先进的软件工程能力水平。

🔍 案例研究：剖析一次自主修复

下面是任务 tfd_zerodivisionerror_1 中的一个真实示例，展示了这一闭环的作用：

第 1 步：定位故障

json
{"tool": "search_code", "arguments": {"query": "def calculate_precision_recall"}}

部分评论已被文章作者隐藏，了解更多。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。