FullStack-Agent：通过面向开发的测试和仓库反向翻译增强智能体全栈网页编程能力 FullStack-Agent: Enhancing Agentic Full-Stack Web Coding via Development-Oriented Testing and Repository Back-Translation
多智能体框架+仓库反向翻译自训练+全栈评测基准，解决LLM生成网站缺失后端的问题
前置知识
Agentic Coding（智能体编程）
智能体编程是指利用大语言模型（LLM）作为核心推理引擎，配合代码编辑、文件读写、命令执行等工具，以自主循环的方式完成软件开发任务。与传统的单次代码生成不同，智能体可以读取项目文件、执行命令、观察输出、调试错误，形成「观察-思考-行动」的迭代闭环。在本文的语境中，智能体被用于从自然语言指令出发，自主完成包含前端、后端、数据库的完整网站开发。
本文的核心就是构建一个高效的全栈智能体系统，理解智能体编程的基本范式是理解 FullStack-Dev 多智能体架构的前提。
全栈网站开发（Full-Stack Web Development）
全栈网站开发涵盖前端（用户界面，如 React/Next.js）、后端（服务端逻辑与 API，如 Node.js/NestJS）和数据库（数据存储，如 PostgreSQL）三个层次。与仅生成 HTML 页面的前端开发不同，全栈开发需要处理数据在三层之间的流动：前端通过 API 调用后端，后端读写数据库，数据再反馈回前端展示。这要求开发者理解包管理、依赖关系、API 设计、数据建模等多个方面。
论文的核心论点是现有代码智能体只会生成前端页面，而真正的全栈开发远比这复杂。理解全栈开发的三层架构是理解本文动机和评测体系的基础。
Repository Back-Translation（仓库反向翻译）
这是本文提出的一种数据生成方法。核心思路是：从 GitHub 上爬取真实的网站代码仓库，然后用一个智能体将这些已有的仓库「逆向工程」为开发轨迹——即模拟从零开始构建该仓库的完整过程。具体来说，先用 Information Gathering Agent 阅读仓库结构和功能，生成摘要和开发计划；再用 Trajectory Back-Translation Agent 在空模板上按照计划重新实现仓库内容；最后用规则化程序清理轨迹中对原仓库的引用，使其看起来像正常的开发过程。
这是 FullStack-Learn 的核心技术。与直接让 LLM 生成开发轨迹不同，反向翻译能利用真实世界代码库的丰富知识，生成高质量的训练数据，是本文自改进方法区别于已有工作的关键。
Supervised Fine-Tuning (SFT，监督微调)
SFT 是大模型训练的常见范式之一。在预训练模型的基础上，使用高质量的标注数据对模型进行进一步训练，使其适应特定任务。在本文中，SFT 使用的是由仓库反向翻译生成的智能体开发轨迹数据，每条轨迹包含用户指令、工具调用序列、工具返回结果等完整信息。训练时模型学习如何根据上下文选择正确的工具调用和代码编辑操作。
FullStack-Learn 最终通过 SFT 将生成的轨迹知识注入 backbone LLM，SFT 的训练策略（学习率、batch size、epoch 数）直接影响最终模型的全栈编程能力。
GUI-Agent Testing（GUI 智能体测试）
GUI 智能体测试是一种自动化评测方法：让一个 LLM 驱动的 GUI 智能体像真实用户一样在浏览器中与网站交互——点击按钮、填写表单、导航页面——然后根据交互结果判断功能是否正确。与传统的单元测试不同，GUI 测试从用户视角出发，能发现界面级别的问题。但其局限在于只能观察前端表现，无法验证后端逻辑和数据库操作是否真正执行。
本文的 FullStack-Bench 在 GUI-Agent 测试的基础上增加了后端和数据库测试层，解决了 GUI 测试无法检测「假后端」（前端有反应但后端没有实际处理）的问题。
研究动机
现有 LLM 驱动的网站生成智能体（如 Bolt.diy、WebGen-Agent、TDDev 等）存在一个严重的系统性问题：即使用户明确要求生成需要数据处理和存储的交互式网站，这些智能体仍然倾向于只生成前端页面，用精美的视觉效果掩盖后端缺失的事实。例如，在一个生成的网站中，用户可以提交表单并看到成功提示，但实际上没有任何数据被处理或存储——因为根本没有后端和数据库实现。此外，这些方法通常只生成单个 HTML 文件或非常简单的代码库，缺乏生产环境所需的可扩展性。WebGen-Bench 等现有评测基准主要通过 GUI 智能体交互来评判网站，这种评测方式无法检测到上述「假阳性」案例——前端看起来正常但后端完全是假的。同时，构建生产级全栈网站面临三大技术挑战：（1）Next.js、NestJS 等真实开发框架涉及大规模复杂代码库，需要高效的代码导航和准确的错误定位；（2）全栈开发的复杂工作流要求长期推理、熟练的工具调用和对 Web 包的专家级理解；（3）评测全栈网站生成仍然是开放问题，现有基准无法全面覆盖前端、后端和数据库三个层面。
本文的目标是本文的目标是构建一个统一的全栈智能体系统 FullStack-Agent，从三个维度系统性地解决上述问题：（1）设计一个高效的多智能体开发框架（FullStack-Dev），能够协调规划、前端开发、后端开发的完整工作流，并配备专门的调试工具来定位和修复隐蔽的错误；（2）提出一种可扩展的数据生成和模型自改进方法（FullStack-Learn），利用真实世界代码仓库通过反向翻译和数据增强来提升 backbone LLM 的全栈编程能力；（3）构建一个全面的全栈评测基准（FullStack-Bench），通过前端 GUI 测试、后端 API 测试和数据库结构测试三个层面来准确评估生成网站的完整功能。最终目标是在 FullStack-Bench 上显著超越现有方法，并通过自改进训练使较小的模型也能获得强大的全栈开发能力。
与已有工作不同的是，本文的独特切入角度在于同时解决了「框架」、「模型」和「评测」三个层面的缺失。在框架层面，现有方法缺乏专门为全栈开发设计的工具——特别是后端调试工具（类似 Postman 的 API 测试）和前端调试工具（能精确定位错误触发动作的 GUI 测试），而本文为编码智能体配备了这些专用工具。在模型训练层面，现有方法（如 WebGen-Agent 的 GRPO）要么依赖更强的模型来蒸馏，要么无法利用已有的真实代码库；本文的仓库反向翻译方法巧妙地将 GitHub 上丰富的网站仓库转化为智能体训练轨迹，无需依赖更强模型即可实现自改进。在评测层面，现有基准只关注前端交互，本文首次提出了前端-后端-数据库三层评测体系，并通过数据库日志验证来检测「假后端」问题。这三个层面的协同设计是已有工作从未尝试过的。
核心方法
FullStack-Agent 的整体思路可以用建筑工地来类比：Planning Agent 是总建筑师，负责设计整体蓝图（前端页面布局和后端 API 设计）；Backend Coding Agent 和 Frontend Coding Agent 分别是后端工程师和前端工程师，按照蓝图各自施工；而调试工具则是质量检测员，能精确定位施工中的问题。技术路线分为三个紧密耦合的子系统：FullStack-Dev 负责执行层——多智能体协作完成网站开发；FullStack-Learn 负责能力层——通过仓库反向翻译和数据增强迭代提升 backbone LLM 的全栈编程能力；FullStack-Bench 负责评测层——通过前端、后端、数据库三层测试全面评估生成网站的质量。这三个子系统形成闭环：FullStack-Learn 训练出更强的 LLM 作为 FullStack-Dev 的 backbone，FullStack-Dev 生成的网站在 FullStack-Bench 上评测，评测结果又指导进一步优化。
本文最核心的创新是 Repository Back-Translation（仓库反向翻译）的概念及其与 Repository Augmentation（仓库增强）的协同。已有工作在训练代码智能体时面临一个困境：让 LLM 直接从用户指令生成开发轨迹质量很低（因为模型本身不够强），而依赖更强模型来蒸馏则成本高昂且受限。FullStack-Learn 的关键洞察是：GitHub 上已经有大量高质量的网站代码仓库，与其从零生成，不如将这些仓库「逆向工程」为开发轨迹。具体来说，Information Gathering Agent 先阅读仓库的目录结构和关键文件，生成包含仓库描述、质量评分、前端/后端开发计划和用户指令的结构化摘要；然后 Trajectory Back-Translation Agent 在一个空的框架模板上，按照摘要中的计划重新实现仓库内容——这个过程的工具调用序列就自然形成了开发轨迹。通过规则化程序清理所有对原仓库的引用后，这些轨迹就可以用于 SFT 训练。与直接生成轨迹相比，反向翻译利用了真实代码库的丰富知识和成熟的架构模式，生成的轨迹质量显著更高——实验表明训练在反向翻译轨迹上的模型比训练在直接生成轨迹上的模型，前端准确率高 6.1 个百分点（42.3% vs 36.2%）。
方法步骤详情
FullStack-Dev 的开发流程分为四步：（1）模板选择——根据用户指令自动选择最合适的前端框架（Next.js）和后端框架（NestJS），并判断是否为纯前端项目；（2）规划——Planning Agent 分析用户指令，输出 JSON 格式的前端计划（页面、组件、数据流）和后端计划（实体、API 端点、业务规则），所有数据结构细化到最底层类型（如 integer），确保前后端数据流的无缝对接；（3）后端开发——Backend Coding Agent 按照后端计划实现 API 和数据库操作，每完成一个功能就用 Backend Debugging Tool 自动启动服务、发送 HTTP 请求、验证响应，类似于开发者使用 Postman 调试 API；（4）前端开发——Frontend Coding Agent 根据后端 API 摘要实现前端页面，用 Frontend Debugging Tool 自动启动网站、驱动 GUI 智能体交互、监控终端和浏览器控制台输出来定位错误。FullStack-Learn 的训练流程分三步：（1）Round 1——用初始 LLM 对爬取的 GitHub 仓库进行反向翻译，生成 2K 条轨迹，训练得到 M1；（2）Round 2——用 M0 对原始仓库执行增强操作（简化、扩展、平行应用转换，每个仓库生成 5 个变体），再用 M1 对增强仓库进行反向翻译，生成 8K 条新轨迹，加上 Round 1 的 2K 共 10K 条训练数据；（3）最终训练——在 10K 条轨迹上从头训练 M0，得到最终模型 Mfinal。
技术新颖性
FullStack-Agent 的技术新颖性体现在三个层面。首先，在智能体架构设计上，与现有方法将所有代码塞进上下文窗口不同，FullStack-Dev 通过 list directory、glob、search file content 等工具实现动态代码导航，能够处理大规模复杂代码库。更重要的是两个专用调试工具的设计：Frontend Debugging Tool 不是盲目的 GUI 交互，而是实时监控终端和浏览器控制台输出，精确定位哪个用户操作触发了哪个错误，然后反馈给编码智能体；Backend Debugging Tool 类似 Postman，一条命令完成服务启动、请求发送、响应接收和控制台日志收集。实验表明，移除 Backend Debugging Tool 后，后端编码智能体的平均迭代次数从 74.9 增加到 115.5（增加 54%），证明了其关键作用。其次，在数据生成上，仓库反向翻译解决了「如何从已有代码库生成开发轨迹」这个非平凡问题——通过全局规划（Information Gathering Agent）和局部实现（Trajectory Back-Translation Agent）的巧妙结合，生成的轨迹不仅逻辑连贯，而且工具调用顺序与真实开发过程高度一致。最后，在评测上，FullStack-Bench 首次在 GUI 测试中引入数据库日志验证：前端测试时提取 GUI 交互期间写入的数据库日志条目，判断是否与前端操作所需的数据库交互一致，从而检测「前端看起来正常但后端是假的」的假阳性案例。
实验结果
论文在三个维度上进行了全面的实验验证。在 FullStack-Dev 的主实验中（Table 2），使用 Qwen3-Coder-480B-A35B-Instruct 作为 backbone LLM，FullStack-Dev 在前端测试（需验证数据库交互）上达到 64.7%，后端测试 77.8%，数据库测试 77.9%，分别超越之前最好的 WebGen-Agent（56.0%、39.6%、62.0%）8.7、38.2 和 15.9 个百分点。后端准确率的 38.2% 提升尤为显著，说明 FullStack-Dev 在生成有真实后端功能的网站方面具有巨大优势。值得注意的是，FullStack-Dev 的后端准确率（77.8%）高于前端准确率（64.7%），而大多数基线方法的后端准确率远低于前端——这表明现有方法倾向于只生成前端，而 FullStack-Dev 的全栈网站大多拥有功能完整的后端。外观评分方面，FullStack-Dev 达到 3.72（5 分制），同样最高，这归功于前端调试工具对渲染问题的实时调整能力。在使用较小的 Qwen3-Coder-30B-A3B-Instruct 时，FullStack-Dev 同样全面领先，前端 37.2%、后端 38.7%、数据库 50.9%。在 FullStack-Learn 的自改进实验中（Table 3），经过两轮迭代训练，30B 模型的前端准确率从 37.2% 提升到 46.9%（+9.7%），后端从 38.7% 提升到 48.2%（+9.5%），数据库从 50.9% 提升到 53.7%（+2.8%），外观评分从 2.97 提升到 3.40。整个过程完全自改进，不依赖任何更强的模型。消融实验（Table 4）表明：移除多智能体机制后三项指标均下降；移除后端调试工具主要影响后端准确率（从 77.8% 降到 57.9%）；移除前端调试工具主要影响前端准确率（从 64.7% 降到 51.9%）；同时移除两个调试工具导致全面大幅下降。仓库反向翻译的消融（Table 5）表明，在反向翻译轨迹上训练的模型（42.3% 前端）远优于在直接生成轨迹上训练的模型（36.2%），证明了反向翻译方法的有效性。评测可靠性分析（Table 6）显示，前端、后端和数据库测试的人机对齐准确率分别为 90.5%、94.0% 和 97.5%，证明 FullStack-Bench 的测试流水线是可靠的。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 前端功能测试（含数据库验证） | FE Acc. w/ Valid DB | 64.7% | WebGen-Agent 56.0% | +8.7% |
| 后端功能测试（含数据库验证） | BE Acc. w/ Valid DB | 77.8% | WebGen-Agent 39.6% | +38.2% |
| 数据库结构测试 | DB Acc. | 77.9% | WebGen-Agent 62.0% | +15.9% |
| 前端功能测试（30B模型） | FE Acc. w/ Valid DB | 37.2% | 无训练 37.2%（基线） | FullStack-Learn 后 +9.7% → 46.9% |
| 后端功能测试（30B模型） | BE Acc. w/ Valid DB | 38.7% | 无训练 38.7%（基线） | FullStack-Learn 后 +9.5% → 48.2% |
| 数据库测试（30B模型） | DB Acc. | 50.9% | 无训练 50.9%（基线） | FullStack-Learn 后 +2.8% → 53.7% |
| 外观评分（480B模型） | Appearance Score (1-5) | 3.72 | WebGen-Agent 3.63 | +0.09 |
| 人机对齐-前端 | Human Alignment % | 90.5% | N/A | N/A |
| 人机对齐-后端 | Human Alignment % | 94.0% | N/A | N/A |
| 人机对齐-数据库 | Human Alignment % | 97.5% | N/A | N/A |
局限与改进
论文在多个方面存在局限性。首先，FullStack-Bench 的 101 个用户指令全部来自 WebGen-Bench，而非独立构建，这可能导致评测集的多样性和覆盖面受限——例如可能缺乏某些特定类型的全栈应用（如实时通信、文件上传处理、复杂权限系统等）。其次，实验仅在 Next.js + NestJS 的技术栈上进行了主实验，虽然附录中展示了添加 Vue.js 和 Django 的扩展实验，但评估的框架组合仍然有限，无法全面代表真实世界全栈开发的技术多样性。第三，FullStack-Learn 的自改进过程需要在 32 张 H800 GPU 上训练（2 epoch，batch size 32，学习率 2e-5），计算成本不低，且目前只在 30B 模型上验证了效果，能否推广到更大模型（如 480B）尚不确定。第四，论文承认错误分析中「功能未实现」（29.7%）和「组件无响应」（23.7%）占前端错误的一半以上，说明即使使用 FullStack-Dev，仍有大量功能需求未被正确实现。后端错误中「无数据库交互」（34.3%）和「API 未实现」（33.3%）各占约三分之一，表明智能体在理解用户指令中的数据处理需求方面仍有明显不足。数据库错误中「数据库为空」高达 46.7%，说明很多情况下数据库根本没有被初始化。此外，论文未报告 FullStack-Dev 在推理时的延迟和 token 消耗，400 次工具调用上限意味着复杂网站的生成可能非常耗时。
独立分析的弱点
从独立分析的角度，本文存在以下几个值得关注的弱点。第一，FullStack-Bench 的测试用例完全依赖 LLM 判官（judge agent）来判定通过与否，虽然人机对齐准确率超过 90%，但仍有近 10% 的误判率。对于后端和数据库测试，这种误判可能导致对方法性能的高估或低估。改进方向是引入更结构化的测试框架——例如将后端测试转化为可自动执行的 API 测试脚本，将数据库测试转化为 schema 验证规则，减少对 LLM 判断的依赖。第二，仓库反向翻译的质量严重依赖 Information Gathering Agent 的摘要质量。如果摘要遗漏了关键的 API 端点或数据流，生成的轨迹就会有缺陷。论文未分析摘要质量对最终轨迹质量的影响，也未提供摘要的评估指标。可以考虑引入多轮信息收集或交叉验证机制来提高摘要的完整性。第三，FullStack-Dev 的多智能体架构中，后端开发先于前端开发，这意味着前端编码智能体必须等待后端完全完成后才能开始。在实际开发中，前后端可以并行开发（通过 API 契约先行），这种串行设计可能成为效率瓶颈。第四，实验中的 trajectory 过滤规则（5-gram Jaccard > 0.6 或 cosine similarity > 0.7）可能过于保守，导致部分有价值的训练数据被丢弃；也可能过于宽松，导致评测集污染。论文未分析去污染策略的精确率和召回率。
未来方向
基于本文的工作，有几个有前景的研究方向。首先，仓库反向翻译的方法具有很强的通用性，可以扩展到其他类型的软件开发任务，如移动端应用开发、CLI 工具构建、数据处理管道等——核心思路都是从已有代码库反向生成开发轨迹。其次，FullStack-Bench 可以扩展更多的框架组合（如 React + Express、Vue + Flask、Angular + Spring Boot）和更复杂的应用场景（如涉及 WebSocket 实时通信、文件上传/下载、多用户权限系统、支付集成等），以更全面地评测全栈开发能力。第三，FullStack-Learn 的迭代自改进过程可以探索更高效的训练策略，如课程学习（先简单仓库后复杂仓库）、在线强化学习（利用评测结果作为奖励信号）等。第四，当前的调试工具是基于规则的错误监控，可以考虑引入学习型调试策略——让模型自主决定何时调试、调试什么、如何根据调试结果调整代码。第五，可以探索将 FullStack-Learn 的方法应用到更大的模型（如 480B），验证自改进方法的可扩展性。最后，论文提到的错误分析表明「数据库为空」是最常见的数据库错误（46.7%），这提示可以在规划阶段增加数据库初始化的显式步骤。
复现评估
从复现角度来看，本文的复现条件相对友好但也存在挑战。代码方面，论文明确表示代码已在 GitHub 上开源（https://github.com/mnluzimu/FullStack-Agent），并且承诺会发布基线实现代码，这大大降低了复现门槛。数据方面，FullStack-Bench 的 101 个用户指令来自 WebGen-Bench，后端和数据库测试用例是新构建的，论文未明确说明这些测试用例是否随代码一起开源。训练数据方面，FullStack-Learn 依赖从 GitHub 爬取的网站仓库，论文未提供爬取的具体仓库列表，但提供了数据过滤和去污染的详细算法（Algorithm 2、Appendix C/D），理论上可以复现数据生成过程。算力方面，训练在 32 张 H800 GPU 上进行，2 个 epoch，batch size 32，这对大多数实验室来说是可承受的（相比训练 backbone LLM 本身所需算力小得多）。推理时使用 131,072 的上下文长度和最多 400 次工具调用，需要较大的推理资源。总体而言，具备中等规模 GPU 集群的团队应该能够复现 FullStack-Learn 的训练过程，而 FullStack-Dev 的框架设计可以较为容易地适配到其他技术栈。
论文图表
