评测驱动开发是什么？LangChain 用一个 Agent 改造案例说明：先定义成功，再验证改动
给 Agent 增加一个工具，整体得分提高了，原本正确的行为却可能退步。 @LangChain 团队 @divyasan0 这篇文章讨论的评测驱动开发（eval-driven development），就是把“感觉变好了”变成可验证的开发流程：先定义预期行为、建立评测和基线，再修改系统、逐项比较。
https://www.langchain.com/blog/what-is-eval-driven-development
先写清楚什么算对，再动手开发
以内部文档助手为例：已有文档搜索和联网搜索，现在要增加创建 IT 工单的能力。“笔记本连不上 VPN”应该开单，“怎么连接 VPN”只是咨询，不该开单；原来的查询能力也不能受影响。
这些要求要变成具体、可判定的评测，而不是笼统的“回答有帮助”。数据优先来自真实对话，没有流量时可以手写。能用代码检查的就用代码，例如是否调用了正确工具；需要模型判断时，先确认评分与人工判断一致。修改前跑一遍基线，才能知道后续改动究竟改善了什么。
总分提高，不代表每种行为都变好
用 8 条样例演示：没有工单工具时通过 5 条；加入工具后通过 7 条，却把“怎么连接 VPN”也开成了工单。
查看执行记录后发现，工具说明写成“用于 VPN 和笔记本问题”，范围太宽。收窄说明后，8 条全部通过。问题不一定出在模型能力，也可能只是工具说明让它误解了适用范围。