TDD 管代码，谁管 Agent？评测驱动开发：分级门禁 + 基线对比，改坏立刻拦

过去AI Agent研发长期陷入无休止的修复循环：用户反馈问题后紧急修改上线，没多久再次出现同类问题，反复修补既消耗研发资源，也容易让隐患累积到生产环境才爆发。而传统软件开发领域已验证有效的测试驱动开发（TDD）模式，此前始终未能覆盖Agent研发的全流程质量管控需求。

无限修Bug循环催生Agent开发新范式

传统TDD通过“红-绿-重构”的闭环，要求开发者先编写 failing 的测试用例，再编写刚好能让测试通过的代码，最后重构代码保证整洁，从源头避免了代码改坏、回归难检测的问题。但这一模式长期仅适用于常规代码开发，AI Agent的行为由模型、代码、 prompt 共同决定，仅靠单元测试无法覆盖其全链路行为的校验，导致Agent研发的质量管控长期处于空白状态。过去行业普遍采用的“出现问题再修复”的模式，本质是事后补救，不仅效率极低，还容易让小的行为偏差累积成严重的生产事故。

评测驱动开发流程替代传统试错模式

随着Evals（评测体系）的成熟，Agent开发也形成了适配自身特性的“评测驱动开发（Test-Driven Agent Development）”闭环：开发者首先定义明确的Task（任务）、配套的Grader（评分器），跑通初始Eval查看基线成功率，再对代码或模型进行调整，调整后再次跑Eval确认效果提升，达标后方可上线。这套流程和传统TDD的核心理念一脉相承，都是先定义“完成标准”再推进开发，确保每一步变更都可量化、可验证。
Evals体系为Agent研发带来了多重价值：所有变更都可追溯，回归问题可被自动检测，大幅降低迭代焦虑；新模型的评估周期从几周压缩到几天，加速模型选型迭代；还能自动追踪延迟、Token用量、成本等基线指标，成为产品与研发团队的高带宽沟通渠道，避免“我觉得功能好了”的主观判断。
在评测执行层面，行业普遍遵循优先级建议：State Check（状态校验）> Tool Call（工具调用校验）> Transcript（对话日志校验）> LLM Rubric（大模型评分）。其中专家审查是公认的校验金标准，但成本高、速度慢，适合用来校准自动化评分模型；A/B测试能拿到真实用户场景下的结果，但需要足够的流量支撑，适合生产环境的效果验证。

分级门禁加基线对比构建Agent质量防线

为了让“改坏立刻拦”的机制落地，业界落地了分级门禁+基线对比的双重校验机制：分级门禁按照校验粒度和成本从低到高设置多层关卡，每层设置明确的通过阈值，任一关卡不通过则变更直接被打回；基线对比则要求每次变更的效果不得低于历史最优基线，若出现性能下降、成本上涨、准确率降低等情况，系统会自动拦截上线请求。
这套机制的本质是TDD理念在Agent研发领域的延伸：TDD本身是一份开发契约，先写的测试定义了“什么叫完成”，Agent开发中通过前置的评测用例，让“测试通过=行为符合预期”有据可查，一旦后续代码修改导致测试不通过，开发者能立刻定位到问题模块，避免问题流出到生产环境。

多场景落地路径适配不同研发需求

目前这套质量管控机制已经在不同类型的Agent研发场景中跑通落地路径：

• 对于存量老代码的迭代，无需追求100%测试覆盖率，优先采用三种高ROI策略：一是“改哪里测哪里”，每次修改老代码时先为待修改部分编写测试用例；二是“新功能用TDD，老代码暂缓”，优先给高频修改的模块补全测试；三是“提取和替换”，若老代码实在难以测试，可提取核心逻辑到新模块，用评测驱动的方式重写，兼顾迭代效率和代码质量。
• 对于UI类Agent，不需要用TDD覆盖视觉呈现，优先保障业务逻辑的校验：单元测试覆盖组件逻辑、事件处理（占比60%），集成测试覆盖组件交互、状态流转（占比30%），E2E测试覆盖关键用户流程（占比10%），样式变化检测用专门的视觉回归工具按需触发即可。

此外这套模式还能和SDD（规格驱动开发）、DDD（领域驱动开发）形成混合开发策略，既保障Agent的行为符合预期，也兼顾业务架构的合理性，成为AI时代Agent研发的主流质量管控方案。