ExecuGraph：一种基于执行的多智能体框架，用于利用大型语言模型进行可靠的后端代码合成

# 一种基于执行的多智能体框架，用于使用大型语言模型进行可靠的后端代码合成¹  ¹源代码、配置、基准定义以及产生本文中所有数值声明的每次试验结果日志均可在 https://github.com/rohithreddybc/multi-agent-dsa-backend-logic-synthesis 获取。来源：https://arxiv.org/html/2607.20499 ###### 摘要 大型语言模型能够生成看似合理的后端代码，但单次通过范式无法保证正确性或运行时可靠性。我们提出了 *ExecuGraph*，一个将基于执行的验证置于后端代码合成核心的多智能体框架。六个专门的智能体——规划器、代码生成器、逻辑审查器、评估器、优化器和解释器——由一个带有有界重试预算的类型化有向工作流协调，该工作流基于 LangGraph 实现，使用本地托管的模型 (Ollama) 和可选的检索层用于算法技术回忆。一个具有定时超时的子进程隔离沙箱保护每次评估。我们在一个精心策划的 30 题 DSA 套件 (internal-30)、HumanEval (n=64) 和一个 APPS-introductory 子集上进行评估，将 ExecuGraph 与单智能体一次性基线和单智能体执行重试基线（一种 Reflexion 风格的消融实验，用于分离多智能体分解的贡献）进行对比。在 internal-30 上，三种条件在统计上没有显著差异 (n=30；配对 Wilcoxon p=0.59 MF vs. SO, p=0.08 SR vs. SO)；所有配对均值差异的 95% 自助置信区间包含零。在 HumanEval 上，多智能体完整流程领先 +3.1 个百分点。最强的信号是跨模型：使用 DeepSeek-Coder-V2-Lite，图形类别准确率从 57.5%（一次性）提高到 80.0%（多智能体完整），跃升了 +22.5 个百分点，这支持了一个扩展假设——多智能体分解的价值随着基础模型能力的增强而增长。该框架的主要贡献是方法论上的：一个单一的代码库，通过配置可以收缩为一次性、执行重试和每智能体消融条件，从而能够控制测量每个杠杆的边际贡献。报告了每智能体消融、重试预算扫描、错误分类法和测试源代码审计。所有配置、每次试验的 JSON 日志和表格生成脚本均已发布，因此每个数值声明都是可重现的。###### 关键词：代码生成，大型语言模型，多智能体系统，基于执行的验证，检索增强生成，软件可靠性，工作流编排 ††期刊：Information Sciences \\affiliation[kitsaiml]organization=Department of Computer Science and Engineering (AI & ML), Kakatiya Institute of Technology and Science, city=Warangal, state=Telangana, country=India\\affiliation[kits]organization=Department of Computer Science and Engineering, Kakatiya Institute of Technology and Science, city=Warangal, state=Telangana, country=India\\affiliation[indep]organization=Independent Researcher, country=India\\affiliation[bu]organization=Boston University, city=Boston, state=MA, country=USA ## 1 引言 大型语言模型 (LLMs) 已迅速成为自动代码生成的默认工具，在包括后端代码合成和算法问题解决在内的广泛编程任务上取得了有竞争力的性能[3 (https://arxiv.org/html/2607.20499#bib.bib1),4 (https://arxiv.org/html/2607.20499#bib.bib2),13 (https://arxiv.org/html/2607.20499#bib.bib10)]。通过学习自然语言描述和源代码之间的统计映射，LLMs 能够从最少的人工输入生成语法有效的实现，并且它们在快速原型设计、编码辅助和教育方面越来越被依赖[4 (https://arxiv.org/html/2607.20499#bib.bib2),10 (https://arxiv.org/html/2607.20499#bib.bib11),31 (https://arxiv.org/html/2607.20499#bib.bib12)]。尽管有这些优势，可靠性仍然是一个显著的局限性。大多数生产级 LLM 编码系统仍然采用*单智能体、单次通过*范式，其中一个模型负责问题理解、解决方案生成和隐式验证。虽然这对于简短或常规代码有效，但对于依赖于数据结构不变量、算法效率或精确边界情况处理的后端代码，这种策略经常失败。生成的程序通常看起来正确，但包含语义缺陷、效率低下的算法选择或缺少边界处理，这些只有在运行时才会显现[4 (https://arxiv.org/html/2607.20499#bib.bib2),13 (https://arxiv.org/html/2607.20499#bib.bib10)]。一个常见的根本原因是缺少执行级别的验证。许多方法依赖于文本自检或思维链式推理来评估正确性[32 (https://arxiv.org/html/2607.20499#bib.bib3),30 (https://arxiv.org/html/2607.20499#bib.bib6)]，但纯文本检查不足以检测只有在执行下才会显现的运行时错误和性能问题[6 (https://arxiv.org/html/2607.20499#bib.bib15),12 (https://arxiv.org/html/2607.20499#bib.bib14)]。迭代细化系统如 Reflexion[29 (https://arxiv.org/html/2607.20499#bib.bib4)] 应用带有情节记忆的言语自我批评，以及执行过滤系统如 AlphaCode[21 (https://arxiv.org/html/2607.20499#bib.bib16)] 根据测试验证采样候选，但这些方法没有将执行反馈嵌入到具有类型化共享状态的显式结构化多智能体工作流中。 ### 1.1 贡献 本文提出了 *ExecuGraph*，一个图结构的多智能体框架，将基于执行的验证置于后端代码合成的核心。具体来说，我们贡献了： 1. 一个基于执行的多智能体工作流，将角色分解与执行反馈解耦，正式指定为一个类型化转换系统，基于具有显式决策谓词和有界重试的共享状态对象 (第3节 (https://arxiv.org/html/2607.20499#S3))。该框架通过配置可以在单一代码库和评估框架内收缩为单智能体一次性、单智能体执行重试 (Reflexion 风格) 和每智能体消融条件，从而实现了首次对每个杠杆的边际贡献进行受控的实证测量——而不是通常将执行反馈与多智能体分解混为一谈。 2. 一个混合评估协议，结合了用于规范算法问题的确定性不变量测试和用于未见过的任务的 LLM 生成边界情况测试，在具有定时超时和受限导入策略的子进程隔离沙箱内执行。 3. 一个实证研究，涵盖精心策划的 30 题套件、HumanEval 基准和 APPS-introductory 子集，将 ExecuGraph 与单智能体一次性基线和单智能体执行重试基线进行比较。我们报告了通过率、重试次数、执行失败率、挂钟时间、LLM 调用总数、总计 token 数以及每个类别的配对 Wilcoxon p 值。 4. 一个每智能体消融实验，量化了规划器、逻辑审查器、优化器和检索层的边际贡献，以及对 {0,2} 的重试预算扫描。 5. 一个可重现的工件：结果表中的每个数值声明都是由随附的 analysis/build_tables.py 脚本从每次试验的 JSON 日志生成的，并且实验中使用的每个配置、模型摘要和种子都已提交到仓库中。 本文的其余部分组织如下。第2节 (https://arxiv.org/html/2607.20499#S2) 回顾了关于 LLM 代码生成、迭代细化、多智能体编码流程、基于执行的验证和检索增强生成的相关工作。第3节 (https://arxiv.org/html/2607.20499#S3) 形式化了所提出的框架。第4节 (https://arxiv.org/html/2607.20499#S4) 描述了评估协议。第5节 (https://arxiv.org/html/2607.20499#S5) 报告了定量结果。第6节 (https://arxiv.org/html/2607.20499#S6) 讨论了启示和局限性。第7节 (https://arxiv.org/html/2607.20499#S7) 总结。第8节 (https://arxiv.org/html/2607.20499#S8) 提供了完整的可重现性细节。 ## 2 相关工作 我们将先前的工作组织成五个方面，并在每个小节末尾给出区分 ExecuGraph 的设计选择。 ### 2.1 用于代码生成的 LLM 基础 LLM 工作表明，规模和大型代码语料库能产生强大的代码生成能力[3 (https://arxiv.org/html/2607.20499#bib.bib1),4 (https://arxiv.org/html/2607.20499#bib.bib2),7 (https://arxiv.org/html/2607.20499#bib.bib17)]。专门的预训练目标改进了代码理解和合成[10 (https://arxiv.org/html/2607.20499#bib.bib11),31 (https://arxiv.org/html/2607.20499#bib.bib12)]，并且开源代码 LLMs 扩大了访问范围[23 (https://arxiv.org/html/2607.20499#bib.bib18),11 (https://arxiv.org/html/2607.20499#bib.bib19)]。功能性基准如 HumanEval[4 (https://arxiv.org/html/2607.20499#bib.bib2)]、MBPP[1 (https://arxiv.org/html/2607.20499#bib.bib20)] 和 APPS[13 (https://arxiv.org/html/2607.20499#bib.bib10)] 通过测试执行而非表面相似性来形式化正确性。然而，实证上，这些相同的研究也记录了持续存在的语义错误和脆弱的边界情况处理，这激发了超越原始解码的机制。**ExecuGraph 的不同之处**在于将现成的代码 LLM 视为工作流中的一个*组件*，而不是一个自包含的求解器，并且将执行结果作为关键的接受信号。 ### 2.2 迭代细化和自我调试 思维链提示[32 (https://arxiv.org/html/2607.20499#bib.bib3)] 和自一致性采样[30 (https://arxiv.org/html/2607.20499#bib.bib6)] 改善了中间推理，但依赖于同一模型进行生成和判断。Reflexion[29 (https://arxiv.org/html/2607.20499#bib.bib4)] 引入了带有情节记忆的言语自我批评；Self-Debug[5 (https://arxiv.org/html/2607.20499#bib.bib21)] 提示同一模型使用执行轨迹来检查和修复自己的程序。两者都证明反馈循环有帮助，但混淆了“模型作为批评者”和“分解的角色”：目前尚不清楚收益是来自反馈本身，还是来自任何形式的角色分解。**ExecuGraph 的不同之处在于**将批评者角色分离为两个不同的智能体——一个静态的逻辑审查器（咨询性）和一个评估器（权威性，基于执行）——并将审查器的输出视为一个结构化的、咨询性的人工制品，而不是一个有约束力的判断。这一设计选择得到了最近关于 LLM 评判稳定性的实证工作的支持：JudgeSense 基准[2 (https://arxiv.org/html/2607.20499#bib.bib30)] 报告了在十三个前沿和开放权重评判者中，语义等价提示改写下的连贯性评判-决策翻转率为 8.5% 到 61.3%，并且发现前沿规模不是一致性的可靠代理。因此，让 LLM 批评者基于可能对改写敏感的裁决来否决原本正确的代码，会引入非平凡的假阴性风险；ExecuGraph 通过仅将接受权限定在执行结果上来避免这种情况。第4节 (https://arxiv.org/html/2607.20499#S4) 报告了一个单智能体执行重试基线（同一框架的 Reflexion 风格配置），以便能够隔离归因于多智能体分解本身的收益。 ### 2.3 多智能体编码流程 几个近期系统明确地将代码合成分解为多个角色。AgentCoder[15 (https://arxiv.org/html/2607.20499#bib.bib22)] 引入了测试设计和程序员智能体；MapCoder[17 (https://arxiv.org/html/2607.20499#bib.bib23)] 使用检索-规划-编码-调试阶段；MetaGPT[14 (https://arxiv.org/html/2607.20499#bib.bib24)] 围绕软件开发元过程组合角色扮演智能体；AutoGen[33 (https://arxiv.org/html/2607.20499#bib.bib25)] 提供了一个对话式多智能体运行时。ReAct[34 (https://arxiv.org/html/2607.20499#bib.bib5)] 和 Auto-GPT[27 (https://arxiv.org/html/2607.20499#bib.bib8)] 探索了智体推理和自主工具使用。AgentBench[22 (https://arxiv.org/html/2607.20499#bib.bib7)] 记录了多步骤智体设置中的可靠性下降，特别是当成功依赖于精确状态传播时。**ExecuGraph 的不同之处在于**三个轴线：(i) 它使用一个*编译的、确定性的*工作流图 (LangGraph) 以及一个类型化的共享状态记录，而不是自由形式的对话；(ii) 决策谓词专门定义在执行结果上，而不是文本自我评估上；(iii) 该框架暴露了消融切换，以便可以直接测量每个角色的边际贡献。 ### 2.4 基于执行的验证和程序辅助方法 执行引导的神经程序合成将运行时信号注入解码以过滤无效候选[6 (https://arxiv.org/html/2607.20499#bib.bib15)]。程序辅助语言模型 (PAL) 将符号计算委托给解释器[12 (https://arxiv.org/html/2607.20499#bib.bib14)]。竞赛级系统如 AlphaCode 使用大规模采样与基于执行的过滤[21 (https://arxiv.org/html/2607.20499#bib.bib16)]。Toolformer[28 (https://arxiv.org/html/2607.20499#bib.bib13)] 学习何时调用外部工具。**ExecuGraph 的不同之处在于**将执行从*过滤器*提升为工作流本身的*决策谓词*。无论静态审查器的裁决如何，该图都不能接受未通过运行时评估的代码。 ### 2.5 用于代码的检索增强生成 RAG[20 (https://arxiv.org/html/2607.20499#bib.bib9)] 通过将生成植根于检索到的文档来改善知识密集型任务。向量存储如 ChromaDB[8 (https://arxiv.org/html/2607.20499#bib.bib33)] 和编排器如 LangChain[18 (https://arxiv.org/html/2607.20499#bib.bib31)] 及 LangGraph[19 (https://arxiv.org/html/2607.20499#bib.bib32)] 使得实用的 RAG 和工具流程得以实现，而本地优先推理平台如 Ollama[24 (https://arxiv.org/html/2607.20499#bib.bib34)] 支持可重现的部署。然而，这些原语都没有规定检索应该何时在代码合成工作流中触发。**ExecuGraph 的不同之处在于**将检索视为仅面向规划器的*可选*、配置切换输入，并且报告了检索层的显式开/关消融实验 (第5节 (https://arxiv.org/html/2607.20499#S5))，以便可以评估其贡献，而不是假设。 ## 3 ExecuGraph 框架 我们首先介绍高层架构 (第3.1节 (https://arxiv.org/html/2607.20499#S3.SS1))，然后将工作流指定为一个类型化转换系统 (第3.2节 (https://arxiv.org/html/2607.20499#S3.SS2))，描述每个智能体 (第3.3节 (https://arxiv.org/html/2607.20499#S3.SS3))，并记录执行沙箱 (第3.5节 (https://arxiv.org/html/2607.20499#S3.SS5))。 ### 3.1 高层架构 ExecuGraph 遵循分层设计 (图1 (https://arxiv.org/html/2607.20499#S3.F1))。*用户交互层*接受后端 / DSA 问题陈述。*工作流编排层* (LangGraph) 编译一个由类型化共享状态调度智能体调用和路由控制的有向图。*智能体层*包含六个专门的智能体 (规划器、代码生成器、逻辑审查器、评估器、优化器、解释器)。*执行与评估层*在子进程隔离的沙箱中运行生成的代码，并应用混合测试策略。*可选的知识记忆层* (