别再凭感觉调Agent：DSPy+MLflow构建可衡量的LLM应用

当Agent的"改进"只是感觉良好

很多在生产环境维护AI Agent的工程师都遇到过一个尴尬处境：改了一版提示词，模型好像变好了，但说不清到底是哪里变好、变好了多少。下一次再改，效果可能又莫名其妙地退步。这种"prompt-and-pray"（写提示词然后祈祷）的开发方式，本质上是把系统的可靠性建立在直觉和运气之上。

一场由 AI 工程师 Serj Smorodinsky 和 Brett Kennedy 主讲的三小时实操工作坊，正是针对这一盲区。两人是一本关于 LLM 应用书籍的合著者，主题聚焦于如何用结构化的方法构建 Agent 和 LLM 应用，而不是靠反复试探提示词。

从手写提示词到 DSPy 结构化编程

工作坊的核心思路，是用 DSPy 的 signatures 和 modules 替代手工编写的提示词。DSPy 把"我想让模型完成什么任务"抽象成可组合、可优化的程序单元，而不是一段脆弱的自然语言文本。

这一转变的意义在于：当任务被结构化地定义后，提示词的具体措辞不再是你需要反复手动调试的对象，而是可以由框架根据评估结果自动优化的产物。工作坊会覆盖 few-shot 和 instruction-level 两个层面的优化，让模型行为的改进有据可依。

先建立可衡量的基线

结构化开发的第一步不是优化，而是建立一个可测量的基线分类器。没有基线，任何"改进"都无从比较。工作坊会带着参与者从零构建一个基线，并在此之上做量化对比——这正是解决"凭感觉"问题的起点。

DSPy（Declarative Self-improving Python）是斯坦福大学 NLP 团队开发的开源框架，其核心理念是将 LLM 调用抽象为可编程的模块，而非依赖手写提示词。在 DSPy 中，Signature 定义了任务的输入输出类型（类似函数签名），例如"输入一段文本，输出情感分类标签"；Module 则是执行该任务的基本单元，类似神经网络中的层。多个 Module 可以串联组合成更复杂的 Pipeline。

DSPy 最关键的能力是自动优化：它内置了多种优化器（如 BootstrapFewShot、MIPRO），能够根据你提供的评估指标，自动搜索更好的少样本示例或指令措辞，从而替代人工反复调试提示词的过程。这意味着提示词从"人手工艺品"变成了"可被算法优化的参数"，整个优化过程有明确的目标函数，而非依赖工程师的主观判断。

在 LLM 应用开发中，"基线"（baseline）特指系统在优化之前的初始性能水平，通常用一个固定的评估数据集和一组任务相关指标来衡量。常见的误区是直接在直觉驱动下修改提示词，却没有一个数值锚点来判断修改是否真的有效——这使得所有"改进"都处于不可证伪的状态。

建立基线的标准流程包括：选取或标注一批有代表性的测试样本、定义与业务目标对齐的评估指标（如准确率、F1、或自定义的 LLM-as-judge 分数），然后在当前系统上跑一遍得到基准分数。这个分数此后成为所有后续优化的参照点，任何提示词修改或模型替换都必须在相同数据集上对比，才能判断是真实提升还是随机波动。

用评估数据集把失败模式看清楚

仅有基线还不够，你还需要知道系统在什么情况下会出错。工作坊安排了构建带有任务特定指标的评估数据集这一环节，并强调如何直接从评估输出中读取失败模式。

这是许多团队容易忽略的能力：与其笼统地说"模型不太行"，不如通过评估数据集定位到具体的错误类别——是在长文本上出问题，还是在某类边缘输入上崩溃。把失败模式可视化出来，改进才有明确方向。

MLflow：让实验可追溯、可复用

光有评估还不够，实验过程本身也需要被记录。工作坊引入 MLflow 做实验跟踪与 trace 管理，这样每一次调整都能留下可回溯的记录。

配合 DSPy 的另一个实用能力——保存和复用已优化的 DSPy 程序——团队可以把"调好的成果"沉淀为资产，而不是每次重新开始。这意味着优化的成果具备了可复现性和工程化管理的基础。

MLflow 是 Databricks 主导的开源 MLOps 平台，最初为传统机器学习实验管理而设计，近年来已扩展出对 LLM 和 Agent 的原生支持。在 LLM 应用场景下，MLflow 的 Tracking 模块可以记录每次实验的参数（如使用的模型版本、优化器配置）、评估指标分数，以及完整的输入输出日志；Tracing 功能则能捕获 Agent 每一步的调用链——包括调用了哪个工具、LLM 的原始输入输出是什么——方便事后回溯排查异常行为。

将 MLflow 与 DSPy 结合使用的实际价值在于：DSPy 负责生成经过优化的程序（包含最佳 few-shot 示例和指令），MLflow 负责将该程序的版本、对应的评估得分和实验上下文一并持久化存储。这样团队成员可以复现任意历史版本的实验，也可以在不同优化策略之间做量化比较，而不是只凭记忆中的"那次好像比较好"来决策。

向不关心提示词历史的人解释可靠性

工作坊议程里有一条很有意思：如何向那些根本不在乎你提示词修改历史的利益相关者解释 LLM/Agent 的可靠性。

这触及了一个现实痛点。业务方或管理者不会关心你改了哪个词，他们只想知道系统到底靠不靠谱、这次改动带来了什么可量化的收益。当你手里有基线、有评估指标、有实验记录时，这种沟通才能建立在数据而非说辞之上。

谁适合参加

主办方给出的定位很清晰：如果你正在生产环境维护 Agent，却说不清某次改动为什么有帮助或有害，那这场活动就是为填补这个盲区而设计的。三小时的 hands-on 形式意味着它偏重动手实操而非纯理论讲授。

对于已经在用 LLM 搭建应用、并开始被可维护性和可靠性问题困扰的工程师来说，DSPy + MLflow 这套组合代表了一种更工程化的思路：把 Agent 开发从"艺术"拉回到"可测量的工程"。当然，工作坊的完整议程和细节需要参考原帖评论区，本文仅基于公开的概要信息整理。