跳至正文返回首页LangChain 发布 Agent Evals 实践指南：代码评估优先于 LLM 裁判
- 为什么 Agent 难测：同一输入多次运行结果不同；多个回答都可能正确，无法做字符串精确匹配；Agent 自选执行路径，最终答案正确但过程可能调用多余工具或未经授权行动。
- 最小闭环：读一批真实 trace → 选定一个行为 → 建 10–20 条小数据集 → 跑基线实验，此后所有改动与基线对比。失败回流机制（一次失败 → 加入数据集 → 改进 → 重跑全量）让数据集随系统演化增长。
- 离线 / 在线分层：离线评估在发布前对新 prompt、模型、工具做防回归；在线评估在生产真实流量 trace 上持续监控，线上标出的失败转化为线下新样本。
- 评估器优先级：代码评估器（确定性检查）能用则必用；代码判不了的主观维度用 LLM-as-a-judge；人工审核用于抽样校准。Pairwise 成对比较比绝对打分更稳定。
- LLM 裁判三条操作建议：用人工标注对照校准裁判 prompt；问窄问题（“是否提到每一个中转站”优于“这是好回复吗”）；用二元判定或分类标签，避免 1–10 打分。
- 成本数据：在二元判定任务上，小模型裁判与人类标注一致性与旗舰模型接近，总成本 0.34 美元，对比 Claude Sonnet 4.6 的 28.17 美元。
- Eval ≠ Benchmark：Benchmark 本质是重型离线 eval——长链路任务、每个任务独立容器化隔离环境、评分检查运行后的环境终态（订票记录、测试是否通过），而非比对文本。生态已有 agentevals 包、Eval Engineering Skill、LangSmith Engine 等现成件，且与具体框架解耦。
🔗 LangChain 官方博客 | 整理速查表