从可运行代码到可发布应用：面向全栈 Web 应用生成的测试驱动开发框架 From Runnable to Shippable: Multi-Agent Test-Driven Development for Generating Full-Stack Web Applications from Requirements

TDDev 的执行流程严格按三阶段闭环组织。阶段一(Acceptance Test Generation):输入自然语言需求 $T_0$,首先让 LLM 想象多个具体用户角色及其目标,产生候选测试需求集合;然后对每个候选,调用 LLM 把它细化为三元组 $\langle \text{feature}, \text{ordered steps}, \text{expected outcome} \rangle$,其中 expected outcome 必须在浏览器中可观察;所有生成的测试 $C(T_0)$ 在编码开始前就作为显式产物暴露,允许用户在开发前审查调整。阶段二(Interactive Validation, 算法 1):编码代理输出应用 $S$ 后,TDDev 自动检测框架、部署到本地 URL,用 Playwright + Chromium 打开;测试代理在每个时间步读取当前页面的可访问性树 $o_t$ 与测试上下文 $c$,查询 LLM $M$ 决定下一步动作(生成 Playwright 代码)或返回 verdict;每执行一步就把 (动作, 结果) 追加到轨迹 $\tau$,最终输出 verdict $\in \{\text{pass, fail, partial}\}$ 与轨迹。阶段三(Failure Translation):当 verdict 非 pass 时,BuildFailureReport 把轨迹、自然语言解释、测试上下文压缩成结构化报告 $f$,包含 attempted steps、failure location、observed behavior 三段,作为修复输入。协议层面,四种协议把这套工具用不同强度接入开发流程:Non-TDD 完全不暴露工具、单次评估;Agentic-TDD 通过 MCP 服务器把工具注入代理,代理自主决定何时调用(算法不外加循环);Whole-Project(算法 2)先一次性实现全应用,再进入最多 $K=5$ 轮的 deploy-test-repair 循环,所有测试一起跑;Incremental(算法 3)逐个特性处理,每个特性部署后只跑当前测试 + 已通过的回归套件,直到通过才进入下一个。

技术新颖性主要体现在三个层面。第一是'测试来源'的革新——传统 LLM agent 的测试反馈直接来自编译器或单元测试,而 TDDev 通过浏览器交互代理+可访问性树+Playwright 三件套,创造了一种全新的'浏览器级反馈信号',既不是文本也不是图像,而是结构化的交互轨迹。第二是反馈信号的'翻译机制',这是论文相对 AutoCodeRover、SWE-agent 等工作的最大区别——后者直接消费编译/测试日志,前者必须把'按钮点击没反应'这种体验级问题逆向映射为'某个 handler 没绑定'这种代码级修复指令,BuildFailureReport 就是承担这一翻译职责的核心组件。第三是协议维度的研究设计,论文首次把'基础设施是否提供'与'是否强制执行'两个变量解耦,形成 4 协议对比,并首次发现模型生成风格(holistic vs read-then-extend)与协议结构之间的可预测交互作用,这是一个有理论贡献的实证观察。

独立分析可识别几个改进方向。第一,测试代理对'正确应用'的判分存在 25% 假阴性,根因有二:一是 selector 生成错误(LLM 生成的 Playwright 选择器与渲染元素不匹配,如 `text=Add` vs 渲染符号 `+`),可通过接入元素属性 fuzzy match 或允许测试代理在 selector 失败时自动 fallback 修复;二是过度保守判分(对轻微措辞差异直接 reject),可通过引入语义相似度阈值(如对 expected outcome 做 embedding 比对)放宽通过条件。第二,Incremental 协议对 holistic 模型无效的核心是它强迫 Sonnet 反复重写整应用,导致回归套件每轮暴露新缺陷。改进方向:让协议检测代理每次实现的 diff,若 diff 是 full-rewrite 而非增量则自动切换到 Whole-Project 行为,实现'自适应协议'。第三,Qwen 在 Incremental 下 token 消耗是 Sonnet 同条件的 18 倍(108.7M vs 5.9M),主要源于每特性最多 5 轮 × 6 特性的笛卡尔展开与累积上下文,可考虑增量上下文压缩或只对失败的测试保留完整描述。第四,失败报告目前是纯文本结构化字段,缺乏指向具体文件/行/元素的精确锚点,可考虑让 BuildFailureReport 附带元素 DOM 路径和最可能的源码位置。第五,MCP 服务器在 Agentic-TDD 下把工具塞给代理,但工具描述质量决定了代理自主决策的成败,论文未给出工具描述细节,复现时容易踩坑。

作者在结论中提出三个明确方向:一是把浏览器验证扩展到认证多用户工作流,目前 TDDev 假设应用是无状态的匿名交互,对需要登录/会话保持的应用尚未支持;二是验证 protocol-风格 交互是否在更大模型家族(不只是 Sonnet 和 Qwen)上仍然成立,这关系到结论的可外推性;三是研究自适应执行策略,即在运行时根据模型行为(如检测到 full-rewrite 模式)动态选择协议。基于论文结果,我认为可延伸的方向还有:(1) 把验收测试生成从 LLM 想象用户角色扩展为可对接产品规格文档、用例库或用户访谈记录,减少对 LLM 创造性的依赖;(2) 引入 execution trace 重放机制,让失败报告携带'上一次能通过的代码版本'作为参考,降低修复时的全局回滚风险;(3) 把 TDDev 接入 CI 流水线,实现人类只参与需求审查和最终验收,中间全闭环;(4) 探索更细粒度的协议,如'feature-grouped incremental'(按功能耦合度分批)或'criticality-first'(按安全/数据完整性优先级排序);(5) 引入 human-in-the-loop 的最小化触发机制,在修复轮连续 2 轮无改进时主动请求人工干预,而不是继续空转 token。

复现评估整体偏正面。作者明确在 Data Availability 部分给出代码与数据存档地址(Zenodo DOI:10.5281/zenodo.19251377),框架、实验数据、评估 fixture 全部开源。代码层面,TDDev 的三大模块(测试生成、浏览器验证、失败翻译)以模块化设计呈现,算法 1-3 是可以直接照搬的伪代码,MCP 服务器接口也是标准化的。实验配置层面,论文给出了完整的 2 代理 × 2 模型 × 2 基准矩阵(表 2),所有 LLM 设置为 temperature=0 和最大上下文,WebGen-Bench 固定 seed=42 抽 50 例、ArtifactsBench 同样方式抽 100 例,可直接复用。算力门槛较低:MacBook Pro M-series + 32GB RAM 即可运行,无需 GPU 集群,主要消耗是 API 调用 token。复现难度中等:需要 API key(Anthropic + OpenRouter)、能跑 Playwright 的 Node/Python 环境、能调 Claude Agent SDK 和 OpenCode,以及对 LLM 工具调用链的基本调试能力。潜在风险是不同 API 版本下 Sonnet 4.6 的行为可能漂移、OpenCode 版本迭代可能影响工具接口、Playwright 与 Chromium 的版本组合会影响 selector 解析。建议复现时优先验证 RQ1 模块可靠性(只需 fixture 应用,不需要跑完整实验),确认测试代理准确率和测试生成覆盖率与论文一致后再展开 RQ2-4。