首测GPT-4.1/Claude Sonnet 4适配能力：LLM多智能体在SE领域的潜力与局限

论文信息

• 论文原标题：Multi-Agent Systems for Dataset Adaptation in Software Engineering: Capabilities, Limitations, and Future Directions（软件工程中用于数据集适配的多智能体系统：能力、局限与未来方向）
• 主要作者及研究机构：
  • JINGYI CHEN（共同第一作者），香港科技大学（The Hong Kong University of Science and Technology, China）
  • XIAOYAN GUO（共同第一作者），中国科学技术大学（University of Science and Technology of China, China）
  • SONGQIANG CHEN，香港科技大学
  • SHING-CHI CHEUNG（通讯作者），香港科技大学
  • JIASI SHEN（通讯作者），香港科技大学
• 引文格式（GB/T 7714）：
  CHEN J, GUO X, CHEN S, et al. Multi-Agent Systems for Dataset Adaptation in Software Engineering: Capabilities, Limitations, and Future Directions[EB/OL]. (2025-11-26)[2025-11-30]. arXiv:2511.21380v1 [cs.SE].
• 其他信息：论文发布于arXiv预印本平台，研究聚焦LLM驱动的多智能体系统在软件工程数据集适配中的应用，是该领域首份实证研究。

一段话总结

这篇论文是首个针对LLM-based多智能体系统在软件工程（SE）数据集适配任务的实证研究：以搭载GPT-4.1和Claude Sonnet 4的GitHub Copilot为研究对象，针对ROCODE、LogHub2.0等基准仓库，通过“文件理解→代码编辑→命令生成→验证→最终执行”五阶段流程评估性能。结果显示，当前系统虽能识别关键文件、生成部分适配代码，但几乎无法产出功能正确的实现；而“提供错误信息”“补充参考代码”等提示干预，能将生成代码与基准真值的结构相似度从7.25%提升至67.14%。研究最终揭示了现有系统的局限，并为构建更可靠的SE多智能体提供了明确方向。

思维导图

研究背景：为什么需要LLM多智能体做SE数据集适配？

咱们先从软件工程（SE）的研究痛点说起——研究员开发一个新的SE技术（比如代码生成工具、bug修复算法），不能只在一个数据集上测效果，得在多个数据集上验证，才能证明技术“通用”。但问题来了：每个数据集的格式、依赖、执行流程都不一样，要让技术在新数据集上跑起来，得手动改代码、装依赖、调脚本。

举个具体例子：假设研究员开发了一个“代码漏洞检测工具”，先在A数据集（比如HumanEval）上跑通了。现在要测B数据集（比如MBPP），得手动改工具的输入读取代码（因为A和B的代码格式字段不一样）、调整执行脚本（B数据集需要额外的环境变量）、甚至补测试用例——这一套下来，少则几小时，多则几天。如果数据集多了，研究员光在“适配”上花的时间，可能比改进技术本身还多。这就是SE领域的“适配瓶颈”：人工适配效率低、难扩展，严重拖慢研究进度。

后来LLM火了，像GitHub Copilot能写代码、ChatGPT能理解命令，人们发现：把多个LLM智能体组合起来（也就是“多智能体系统”），或许能自动化适配——比如一个智能体读项目结构，一个改代码，一个调命令，分工协作。但问题是：这事儿到底行不行？当前最牛的多智能体系统（比如Copilot的Agent模式），真能搞定数据集适配吗？有没有数据支撑？

之前没人做过系统的实证研究，这篇论文就瞄准了这个空白：用真实的SE数据集和技术，测一测LLM多智能体的适配能力，再看看有没有办法帮它们“提分”。

创新点：这篇论文的独特之处在哪？

1. 填补领域空白：首份LLM多智能体SE适配实证研究
   在此之前，没人系统评估过“LLM多智能体能否做SE数据集适配”，论文第一次用标准化流程（五阶段）、真实数据集（ROCODE/LogHub2.0）、主流系统（Copilot）做实验，给出了量化结果。

2. 拆解评估流程：把“适配”拆成可落地的5个步骤
   没直接测“端到端能不能成”，而是把适配拆成“读文件→编代码→生命令→验修复→判结果”，每个步骤都有明确的评估标准（比如“读文件”要对比人类标注的必要文件列表），能精准定位系统卡在哪一步。

3. 设计实用提示干预：3类提示解决不同痛点
   不是乱试提示，而是针对系统的失败模式设计：语法错了给“错误信息”，不懂项目结构给“参考代码”，找不到bug给“位置标注”，层层递进，效果可量化（用JPlag测结构相似度）。

4. 对比两大LLM后端：揭示模型差异
   同时测了GPT-4.1和Claude Sonnet 4，发现Claude在“读文件”“主动测试”上更优，GPT-4.1常漏关键文件，为后续选择模型提供了参考。

研究方法：怎么测LLM多智能体的适配能力？

论文的研究方法很严谨，咱们拆成4步讲，一看就懂：

第一步：选对“测试素材”——筛选可复用的SE工件

不是随便找个数据集就测，而是按3个标准筛选：

1. 来源靠谱：2024-2025年SE顶会（FSE/ICSE/ASE/ISSTA）的论文，且带“可复用工件徽章”（保证能拿到代码）；
2. 语言统一：只选Python实现的（避免不同语言的环境干扰，聚焦适配本身）；
3. 适配价值高：要么“一个技术测多个数据集”，要么“多个技术测一个新数据集”（保证有适配需求）。
   最后选出两个核心工件：ROCODE（代码生成相关）、LogHub2.0（日志解析相关）。

第二步：造“适配任务”——模拟真实场景

1. 整合仓库：把“数据集仓库（R_D）”和“技术仓库（R_T）”合并（比如把ROCODE的数据集复制到技术代码目录）；
2. 挖个“坑”：删掉针对“目标数据集”的适配代码（比如删掉ROCODE适配MBPP的代码），但保留其他数据集的适配代码（比如ROCODE适配HumanEval的代码，作为参考）；
3. 定“标准答案”：被删掉的适配代码就是“基准真值”，最后看智能体能不能复原。

第三步：跑“五阶段测试”——评估RQ1

给Copilot发指令，让它完成适配，同时按5个步骤打分：

步骤	做什么？	怎么算过？
Step1：读文件	智能体浏览仓库，找必要文件	对比人类研究员标注的“必要文件列表”，读全才算过
Step2：编代码	改现有文件/建新文件	①能找到要改的文件（过子步骤1）；②改后的代码功能和基准真值一致（过子步骤2）
Step3：生命令	生成执行脚本（如bash）并运行	①脚本命令和基准真值一致（过子步骤1）；②能自动执行脚本（过子步骤2）
Step4：验修复	找bug、修bug	①能测出代码问题（过子步骤1）；②能修好至少一个问题（过子步骤2）
Step5：判结果	对比最终输出	在相同环境下跑，输出和基准真值完全一致才算过

第四步：加“提示干预”——评估RQ2

如果智能体卡壳了，按顺序加3类提示，看能不能救回来：

1. Prompt1：给错误信息：把终端报错（比如Python的“语法错误：字符串未闭合”）复制给智能体；
2. Prompt2：给参考代码：把“其他数据集的适配代码”（比如ROCODE适配HumanEval的代码）发给智能体；
3. Prompt3：标bug位置：人工找到第一个错的代码行，告诉智能体“你这里写错了”。

主要成果和贡献：LLM多智能体到底行不行？

1. RQ1：当前多智能体系统的适配能力——“会开头，难收尾”

论文用表格总结了核心结果（节选关键数据）：

智能体后端	数据集	Step1（读文件）	Step2（编代码）	Step5（最终适配）
GPT-4.1	所有	全失败	全失败	全失败
Claude Sonnet 4	ROCODE-HE	成功	部分成功（能找文件，代码不全对）	失败
Claude Sonnet 4	Logparser-AEL	失败	部分成功	成功（仅1例）

关键结论：

• 整体拉胯：仅1例（Claude+Logparser-AEL）完成最终适配；
• 瓶颈明显：Step2（编代码）是最难的——所有案例都没完全写出功能正确的代码（比如把MBPP的“自然语言描述”当成“可执行代码”填进字段）；
• 模型差异大：Claude比GPT-4.1强太多——Claude会主动读README（找执行流程）、会生成测试用例，GPT-4.1常漏关键脚本（如run.sh）、写完代码就终止，不验证。

2. RQ2：提示干预的效果——“参考代码最管用”

提示类型	解决的问题	量化效果
Prompt1（错误信息）	语法错、运行时错（如字符串未闭合）	3次内解决90%以上语法问题，除了缩进错误
Prompt2（参考代码）	不懂项目结构、漏改文件	结构相似度从7.25%→67.14%，修复15个漏改文件中的9个
Prompt3（bug定位）	找不到具体错在哪	效果有限：8次尝试仅3次成功，复杂问题搞不定

3. 对SE领域的3大贡献

1. 实践指导：想让多智能体做适配？优先用Claude当后端，加“参考代码”提示，能大幅提效；
2. 问题诊断：明确了当前系统的3个核心局限——不会协调多文件编码、自主调试弱、对数据集字段理解浅；
3. 未来方向：指出要做“执行反馈循环”（让智能体实时看运行结果）、“自适应提示”（按任务难度调提示）、“智能体协作”（分工处理读文件、编代码、验修复）。

注：论文未提及开源代码或数据集，相关实验素材可联系作者获取。

关键问题：你关心的都在这

Q1：当前LLM多智能体在SE数据集适配中，最致命的问题是什么？

A：是“生成代码的功能正确性不足”（Step2的第二个子步骤）。比如在MBPP数据集适配中，智能体明明该填“可执行Python代码”，却填了“自然语言问题描述”，导致最终跑不起来；再比如不会正确调用技术框架——适配ROCODE时，GPT-4.1不用ROCODE的回溯机制，反而用普通LLM生成代码，完全偏离需求。

Q2：为什么“参考代码提示”效果比“bug定位”好？

A：因为“参考代码”能给智能体“全局视角”——不仅告诉它“怎么写”（比如函数参数格式），还告诉它“项目结构是什么”（比如哪个脚本负责执行），从根源上解决“不懂项目”的问题；而“bug定位”只能解决“局部问题”，如果智能体没理解整体逻辑，就算改对了这个bug，还会出其他错（比如改了字段名，却没改引用这个字段的其他文件）。

Q3：这篇研究对普通SE研究员有什么用？

A：有两个直接价值：①如果想自动化适配数据集，现在可以用“Claude+参考代码提示”的组合，能省60%以上的手动改代码时间；②不用再盲目试多智能体——知道了GPT-4.1当前不适合做适配，避免踩坑。

Q4：未来LLM多智能体要怎么改进，才能真正替代人工适配？

A：至少要解决3个问题：①能“全局协调”——改一个文件时，自动同步改其他关联文件；②能“自主迭代”——跑失败后，不用人工给提示，自己分析日志、调代码；③能“理解数据集语义”——不光认字段名，还懂字段的含义（比如知道“prompt”字段在HumanEval里是“输入指令”，在MBPP里是“问题描述”）。

总结

这篇论文是LLM多智能体在SE数据集适配领域的“开山之作”——它没有夸大其词说“多智能体能完全替代人工”，而是用严谨的实验告诉我们：当前系统有潜力（能读文件、生成部分代码），但也有明显局限（功能正确性差、调试弱）；而“提示干预”是低成本提效的好办法，尤其是“参考代码”提示。

对SE研究员来说，这篇论文像一张“地图”：既标出了当前能走的“捷径”（Claude+参考代码），也指出了未来要修的“路”（反馈循环、智能体协作）。相信顺着这个方向走，再过1-2年，LLM多智能体或许真能帮研究员把“适配数据集”的时间从几天缩到几小时。