超越 Vibe Coding：使用 DeepEval 驱动智能体开发循环
在开发基于 LLM 的智能体（agents）的早期阶段，许多开发者依赖于“vibe coding”——即通过微调提示词、运行几次手动测试，并根据输出是否“感觉”正确来做决定。虽然这种直觉式方法在原型设计阶段很快，但它从根本上是不可扩展的，且容易出现回归问题。随着智能体复杂度的增加，引入 RAG 流水线、多种工具和多轮对话后，“感觉”就不再是衡量质量的可靠指标了。
DeepEval 通过将评估套件从被动的质量关卡转变为开发的积极驱动力，引入了一种范式转变。通过将强大的评估框架直接集成到编码智能体的流程中，开发者可以从猜测转向结构化的、迭代的测量与改进循环。
反馈循环：没有“感觉”的 Vibe Coding
DeepEval 在评估套件与编码智能体之间建立了一个紧密的反馈循环。编码智能体不再需要人类开发者手动解释日志，而是由智能体本身运行评估、分析失败原因并实施针对性的修复。这一过程遵循五个阶段的循环：
- 数据集生成：智能体识别或生成金标准数据集（gold dataset）。使用
deepeval generate，智能体可以从文档、现有追踪记录或示例中合成测试用例，确保智能体是在一组基于事实的要求下进行测试。 - 套件构建：智能体使用预定义的模板构建基于 pytest 的评估套件。通过从超过 50 种指标（例如
FaithfulnessMetric或AnswerRelevancyMetric）中进行选择，智能体可以为成功建立客观的阈值。 - 执行：智能体通过
deepeval test runCLI 命令执行套件。这提供了一个可复现的、非随机波动的信号，比基于 UI 的测试要可靠得多。 - 失败定位：利用 span 级别的观察，智能体不仅能看到测试失败了，还能看到哪里失败了。如果“Faithfulness”得分较低，智能体可以将失败追溯到特定的检索器 span，而不是猜测提示词的哪一部分出了问题。
- 修复与验证：智能体应用尽可能小的改动——例如优化检索器过滤器或调整工具 schema——并重新运行评估，以验证修复效果且不引入回归问题。
为什么这适用于编码智能体
并非所有的评估框架都适合自主编码智能体。DeepEval 提供了三个特定属性，使其成为智能体开发的高信号源：
- 结构化输出：每个指标都会返回一个数值分数和自然语言形式的
reason。这使得智能体能够解析失败背后的原因，而无需抓取非结构化日志。 - Span 级别定位：通过使用
@observe装饰器，失败会被映射到特定的文件和函数。这可以防止智能体进行“散弹式调试”（shotgun debugging），而是将其引导至导致问题的确切代码行。 - 可复现的 CLI：单一且一致的命令 (
deepeval test run) 允许智能体在不同的迭代中客观地确认改进。
实现智能体循环
要从手动评估转向智能体驱动的循环，思维方式必须从要求智能体“添加测试”转变为要求它“驱动循环”。此工作流的有效提示词包括：
"Run
deepeval test run tests/evals/and fix the lowest-scoring metric. Don't change thresholds. Re-run to confirm."
"The Faithfulness metric is failing on cases 3, 7, and 12. Open the retriever span for each, find the common pattern, and patch the retriever—not the metric."
通过实施护栏机制——例如禁止智能体降低阈值以掩盖失败或删除困难的测试用例——开发者可以确保智能体实际上是在改进系统性能，而不是在刷指标。
从本地扩展到团队
虽然该循环可以完全离线工作，但连接到像 Confident AI 这样的集中式平台可以使这种智能体工作流在团队中扩展。当编码智能体运行测试套件时，生成的报告可以通过 deepeval view 由人类进行审查。此外，生产环境的监控可以将真实的失败案例反馈到本地数据集，从而确保智能体的下一次迭代能够自动解决实际的用户痛点。