跳到主要内容

A7.3 评测驱动开发：像调试概率机器一样开发

传统调试方法失灵了​

写传统软件，调试流程很清爽：写代码 → 跑测试 → 绿了就对，红了就改。这套流程有个隐含前提——同样的输入，永远给同样的输出。

智能体把这个前提砸了。同一个任务跑两遍，轨迹可能不同、结果可能一次对一次错（A0 讲过：每步都是采样）。你没法写一个「输入 X 就断言输出 Y」的确定性测试——它是个概率机器。

于是开发方式必须变。吴恩达在 Agentic AI 课里给的答案是四个字：评测驱动开发。核心一句话——先建一个评测集，再用数据说话地改进，而不是改一句提示词、手动试两下、觉得「好像变好了」就提交。凭手感调智能体，和用评测调智能体，做出来的可靠性不在一个量级。

两类评测：能自动判的优先​

评测驱动的第一步，是把「好不好」拆成能测量的东西。两类：

  • 客观评测：能用代码自动判对错的——格式对不对、数值对不对、测试过没过、订单建没建（回扣 A7.2 的「基于状态判定」）。优先用这类，便宜、可靠、可大规模自动跑。
  • 主观评测：开放质量，如回复是否得体、报告是否清晰。只能上 模型裁判或人评——记得它们带着上篇 7.2/7.3 讲的全部偏差（长度、自信、位置）。

能拆成客观评测的，绝不留给主观评测。 「回答有没有包含正确的退款金额」是客观的（提取数字比对），别偷懒丢给模型裁判去「感觉一下」。

核心动作：Error Analysis​

评测跑完，你会得到一个数字：「成功率 62%」。新手到这里就开始瞎调提示词了——这正是最大的浪费。

真正拉开差距的动作叫 error analysis：把失败的案例一条条捞出来，读它的轨迹，归类根因。是工具选错了？参数填错了？规划跑偏了？上下文溢出了（A3）？还是被提示注入了（A8）？

只有归好类，你才知道该修哪儿。发现「38% 的失败都是工具参数填错」，就该去改工具描述或加参数校验，而不是笼统地把系统提示词又改长一段。

而 error analysis 的微观动作，就是一件事：在一条失败轨迹里，找出第一处真正出错的步骤。亲手练两道：

🎮 动手实验
轨迹排错游戏：找出第一张倒下的多米诺
下面是一条最终失败的智能体轨迹。你的任务：点出「第一处真正出错的步骤」——不是最后崩溃的那步，而是让后面全盘皆错的根因步。（轨迹为教学构造）
任务：帮用户订一张 7 月 20 日北京飞上海的机票，预算 1000 元以内。
❌ 最终结果是错的。第一处出错的是哪一步？
💡 要点：智能体排错的核心手艺是定位根因步，而不是盯着最后的错误结果。因为一旦某步错了，后面每一步都会"正确地"基于错误前提继续推进——错误会被后续步骤伪装得天衣无缝。这就是为什么完整的轨迹日志是智能体工程的命根子（A4 组合系统那节也强调过）：没有轨迹，你只能看到"订错了票"，有轨迹，你才能看到"第 2 步日期填错了"。

两道题都藏着同一个陷阱——最后崩溃的那一步，往往不是出错的那一步：

  • 订机票：崩在最后订错了票，但根因在第 2 步——日期填成了 07-02 而不是 07-20。此后每一步（查到的航班、下的单、给用户的答复）都在「正确地」基于那个错误日期往下走，所以看起来毫无破绽。
  • CSV 统计：结果是「3 月销售额 0 元」，根因在筛选前缀 2026-3 对不上文件里补零的 2026-03。更惊悚的是模型没有质疑这个可疑的 0，反而给它编了个「这个月可能没数据」的合理解释。

这就揭示了智能体排错的铁律：盯根因步，不是盯崩溃步。而要能盯到根因步，前提是你手里有完整的轨迹日志——没有轨迹，你只看得到「它订错了票」；有轨迹，你才能定位到「第 2 步日期打错了」。这也是 A4 组合系统那节反复强调「每块积木都要留轨迹」的原因。

留轨迹这件事，2024-2026 年已经有成熟的工具生态专门在做——这类 LLM 可观测性 / tracing 工具（如 LangSmith、Langfuse，以及基于 OpenTelemetry 的 LLM 追踪方案）会把每一次模型调用、每一次工具调用的输入输出、耗时、token、父子关系全都记下来，让你能像回放录像一样一步步复盘一条失败轨迹。自己搭智能体时，尽早接上一个这类工具，比事后靠 print 大海捞针强得多。

开发闭环​

把上面几件事串起来，就是评测驱动开发的循环——它长得像做科学实验，而不像写传统代码：

建评测集  →  跑一遍  →  读失败轨迹、做 error analysis
    ↑                              │
    │                              ↓
 回归重跑  ←  针对性改（改提示 / 加校验 / 换工具 / 加纠错）

每一轮改动都有数据支撑：改之前成功率 62%、error analysis 说主要死于工具参数错、加了参数校验后重跑到 78%——清清楚楚，而不是「我觉得好像顺了」。社区里已经有开源的智能体评测平台专门支撑这套流程（做参数化变体、自动判分、断点续跑等），比如 agent-eval-platform，想看一套真实实现长什么样可以参考。

评测集本身会过时、会过拟合

只盯着一个固定评测集反复改，最后会像上篇 7.2 讲的刷榜一样自欺——你的智能体在这个集上 95%，一上线还是拉胯，因为它过拟合了这几十个案例。解药：持续把线上真实失败案例回收进评测集，保持「考题新鲜」。评测集是活的，不是一次建好就供起来的。

小结​

本节要点
  • 智能体是概率机器，确定性测试失灵——改用评测驱动开发：先建集，再用数据说话地迭代。
  • 能自动判的客观评测优先；开放质量才用带偏差的模型裁判/人评。
  • 核心动作是 error analysis：读失败轨迹、归类根因；排错铁律是盯根因步不盯崩溃步——所以完整轨迹日志是命根子。
  • 评测集会过拟合，要持续回收线上真实失败案例保持新鲜。
📝 动手自测0/3
1. 为什么传统的「输入 X 断言输出 Y」的确定性测试，用在智能体上会失灵？
2. 智能体评测跑出「成功率 62%」后，最该做的下一步是？
3. 一条失败轨迹：第 2 步把日期填错，第 6 步据此订错了票。排错时应该重点看哪一步？

延伸阅读​