# LangChain explains eval-driven development with an agent tool example

> Original title: 评测驱动开发是什么？LangChain 用一个 Agent 改造案例说明：先定义成功，再验证改动

- Source: meng shao
- Published: 2026-11-10T11:33:29.000Z
- Bad Influence: https://badinfluence.news/items/lxomjsim85h4emnp7aid1lg6s
- Original: https://x.com/shao__meng/status/2120117639125348470

## Summary

LangChain's Divya Sanjeevan says eval-driven development defines expected agent behavior, builds evals and a baseline, then compares each change. In an internal IT-helpdesk example, adding a ticket-creation tool raised the pass rate from 5 to 7 of 8 cases, but also opened a ticket for a how-to question. Narrowing the tool description fixed all 8 cases.

## Post

评测驱动开发是什么？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 条全部通过。问题不一定出在模型能力，也可能只是工具说明让它误解了适用范围。

![](https://badinfluence.news/api/img-proxy?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHWwrv7AbwAEcmoI.jpg&mode=thumb&exp=1794528000&sig=4d18acafe2fcc3b8)

## Quoted post @LangChain

> How do you improve your agents? @divyasan0 from the LangChain Academy team walks through how the three steps of eval-driven development, a strategy for using evals to help build agents that improve over time.  https://www.langchain.com/blog/what-is-eval-driven-development?

https://x.com/LangChain/status/2119837532502315503