2026 年 4 月 15 日面向 AI agent 的评估驱动开发（EDD）
为什么交付可靠的 AI agent 需要一个由离线实验、在线监控以及持续增长的评估数据集构成的紧凑闭环 —— 以及如何在实践中真正落地。
如果你曾经尝试把一个 AI agent 从 demo 推向真实交付，你大概体会过那种不太舒服的事实：你没办法把整个系统装进脑子里。一次请求可能分支出几十次 LLM 调用、工具调用和自我修正。同一个 prompt 周一能跑通，周五却失败 —— 不是因为代码改了，而是因为模型变了，或者来了一类新的用户。传统软件开发预设的是确定性。agent 打破了这个预设。
评估驱动开发（Evaluation-Driven Development，EDD） 是对这种情况的一种务实回应。与其依赖临时的 prompt 微调和”感觉对了”，你应该像测试驱动开发的工程师对待单元测试那样对待评估：把它当成驱动迭代的主要产物。每一次 prompt 改动、模型替换或新工具的引入，都要在一个能代表用户真实行为的数据集上被度量 —— 上线前度量一次，上线后再度量一次。
这篇文章会讲清楚 EDD 是什么、为什么 agent 特别需要它，以及一个健康的 EDD 闭环在实践中应该长什么样。
为什么 agent 不一样
传统的后端工程师写测试，是因为代码有边界情况。而 agent 工程师需要评估，是因为 系统本身 是非确定的。有三件事让 agent 格外难做对：
- 输出是随机的。 同样的输入在不同运行中可能产生不同的输出。一次跑通并不能证明正确。你需要的是统计意义上的结论，而不是单次绿色的对勾。
- 多步推理。 agent 的最终答案是许多中间决策的乘积 —— 选哪个工具、检索哪个文档、把什么写进记忆。第三步的失败会污染第七步，而对最终答案做单元测试根本无法告诉你问题出在哪里。
- 开放的输入空间。 不像有固定 schema 的 REST API，agent 接受的是自然语言。用户会用你没规划过的方式提问，使用你没规划过的语言，输入分布还在持续漂移。
合在一起，“它能用吗？“就不再是一个是/否的问题。它是一个关于”在真实输入分布上整体表现如何”的问题 —— 而那个分布还在不停变化。
评估闭环
EDD 建立在一个简单的闭环之上，它在 离线 和 在线 评估之间交替进行。单靠任何一半都不够。
离线评估 是在你部署前，把 agent 跑在一个固定的测试用例数据集上。你改一个 prompt，跑一次实验，看分数，决定这次改动是否值得上线。这是你在用户之前发现回归的地方。
在线评估 给真实生产流量的 trace 打分。这是你发现”你没想过要写的测试用例”的地方 —— 那条你从没测过的法语提问、那个 retriever 返回的格式损坏的 JSON、那个一百次里超时一次的工具。当你发现这样一例时，把它加进数据集，下一次离线运行就比上一次更强。
核心概念 文档里有这两半如何拼起来的具体走读。简短版本是：
你更新一个 prompt。你针对数据集跑一次 实验（离线）。你审查分数、迭代，结果看上去够好时部署。然后在线评估开始给线上 trace 打分。某个用户问了一个出乎意料的问题 —— 你把这条 case 加进数据集。下一次实验就能抓住它。日积月累，你的数据集会从几个手写示例成长为一份真实使用场景的代表性样本。
整个事情的关键在于，数据集永远不会”完工”。它是一份活着的产物，记录了你的 agent 曾经失败过的每一种方式 —— 并且保证以后不会再用同样的方式悄无声息地失败一次。
跑 EDD 实际需要什么
最少需要四个构件：
| 构件 | 是什么 | 为什么重要 |
|---|---|---|
| Dataset | 一组输入，可选附带期望输出。 | 你迭代时对照的 ground truth。 |
| Task | 你 agent 的代码，封装成可以针对每个 dataset item 执行的形式。 | 让”被测的东西”和”被部署的东西”保持完全一致。 |
| Evaluation method | 把输出转化为分数的函数 —— 确定性检查、LLM-as-a-judge，或人工标注。 | 你无法改进你无法度量的东西。 |
| Experiment run | task 在 dataset 上的一次执行，产出带分数的输出。 | 不同版本之间比较的基本单位。 |
核心概念 页面对每一项都有更详细的介绍。
不同的问题需要不同的评估方法。对可以用代码表达的东西（JSON schema 合规、抽取实体的精确匹配、延迟上限），确定性检查既便宜又可靠。对”是否有帮助”或”语气是否合适”这种主观属性，LLM-as-a-judge 更合适。人工标注慢，但在构建 ground truth 以及处理自动评估意见不一致的长尾 case 时不可替代。一个成熟的 EDD 流程会把这三种方法分层叠在一起使用。
把闭环拉紧
一个跑一次要一天的评估闭环不会有人去跑。让 EDD 真正被团队用起来、而不是腐烂掉，靠的是三个属性：
- 离线实验要快。 数据集跑一次需要五分钟而不是五小时，工程师才会在每次有意义的改动后都跑一遍。要并行、要缓存、要让数据集保持聚焦 —— 你不需要一万条样本去抓你担心的那个回归。
- 在线打分要自动。 生产 trace 应该不需要任何人记得按按钮就被评估。在采样流量上持续运行的 LLM-as-a-judge 流水线，能让你发现那些原本只会通过客户投诉才知道的回归。
- 从生产到数据集的路径要顺畅。 当你在生产里发现一条糟糕的 trace 时，把它加进数据集应该是几秒钟的事，而不是一张工单。这条路径越顺畅，你的数据集就越快收敛到真实输入分布。
一个合理的起点
如果你从零开始，请抵制第一天就构建宏大评估框架的诱惑。在实践中真正能跑通的曲线更像是：
- 手写十条样本。 真实的样本，最好是从早期用户对话里挖出来的。其中至少要有几条你知道是难的。
- 挑一个真正重要的分数。 不是五个，是一个。任务完成度、对检索上下文的忠实度，或者 agent 是否调用了正确的工具 —— 看哪一个对应你最害怕的失败模式。
- 每次改 prompt 都跑一次实验。 看 diff。注意哪些 case 动了。
- 在一部分流量上打开在线评估。 哪怕只是 5%，也足够开始让”意外”浮出水面了。
- 每次生产里出现糟糕的 trace，就把它加进数据集。 这就是那个习惯。其它的一切都是围绕它搭建的脚手架。
数据集和分数会复利增长。半年之后，你会拥有一份”工作正常”对你 agent 而言究竟意味着什么的活规范，写就于你的用户真实给你的那些样本里。这正是 EDD 存在的意义所在 —— 也是那些认真对待它的团队比依靠感觉走的团队交付得更快（而不是更慢）的原因。
Litefuse 在这其中的位置
Litefuse 就是围绕这个闭环构建的。Dataset、实验、分数与在线评估都是一等的原语，而可观测性侧捕获的 trace 数据直接喂给数据集侧 —— 这样每一条糟糕的生产 trace 都距离成为你下一个回归测试只有一次点击。
如果你今天就想开始跑自己的 EDD 闭环，评估文档 是接下来该去的地方。