LangChain 详解评测驱动开发：给 Agent 加新工具前，先定义什么算成功
LangChain 用一个 8 条样例的真实案例讲清楚了 Agent 开发里最容易被忽略的事：总分从 5 涨到 7 的同时，原来对的样例被改坏了。排查后发现是工具描述写得太宽。正在做 Agent 的开发者可以直接照这套流程抄。
LangChain Academy 的 Divya Shan 发布文章介绍评测驱动开发（eval-driven development），核心流程分三步：先定义预期行为、建立评测集和基线，再修改系统并逐项比较验证。
文章以内部文档助手为例：已有文档搜索和联网搜索，现在要增加创建 IT 工单的能力，并要求"笔记本连不上 VPN"开单而"怎么连接 VPN"只作咨询。评测数据优先来自真实对话，能用代码判定的就用代码检查，需要模型评分时先确认评分与人工判断一致。
文章用 8 条样例演示了典型陷阱：加入工单工具后通过条数从 5 提升到 7，但"怎么连接 VPN"却被误开成工单；查看执行记录发现是工具说明写成"用于 VPN 和笔记本问题"导致范围过宽，收窄描述后 8 条全部通过。
这说明问题不一定出在模型能力，可能只是工具描述让 Agent 误解了适用范围。
评测驱动开发是什么？LangChain 用一个 Agent 改造案例说明：先定义成功，再验证改动 给 Agent 增加一个工具，整体得分提高了，原本正确的行为却可能退步。 @LangChain 团队 @divyasan0 这篇文章讨论的评测驱动开发（eval-driven development），就是把“感觉变好了”变成可验证的开发流程：先定义预期行为、建立评测和基线，再修改系统、逐项比较。 langchain.com/blog/what-is-e… # 先写清楚什么算对，再动手开发 以内部文档助手为例：已有文档搜索和联网搜索，现在要增加创建 IT 工单的能力。“笔记本连不上 VPN”应该开单，“怎么连接 VPN”只是咨询，不该开单；原来的查询能力也不能受影响。 这些要求要变成具体、可判定的评测，而不是笼统的“回答有帮助”。数据优先来自真实对话，没有流量时可以手写。能用代码检查的就用代码，例如是否调用了正确工具；需要模型判断时，先确认评分与人工判断一致。修改前跑一遍基线，才能知道后续改动究竟改善了什么。 # 总分提高，不代表每种行为都变好 用 8 条样例演示：没有工单工具时通过 5 条；加入工具后通过 7 条，却把“怎么连接 VPN”也开成了工单。 查看执行记录后发现，工具说明写成“用于 VPN 和笔记本问题”，范围太宽。收窄说明后，8 条全部通过。问题不一定出在模型能力，也可能只是工具说明让它误解了适用范围。 LangChain @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. langchain.com/blog/what-is-e… ? 🔗 View Quoted Tweet
This report is categorized under AITOP's "How-to" desk, focusing on US frontier AI labs and Silicon Valley technology leaders. Within our cross-regional analytical framework, it directly maps to AI developer toolchains, coding agents, and engineering workflows and US-China foundation model benchmarks and commercialization comparison. Key entities and technical topics under continuous tracking include LangChain, Agent, 评测, 智能体开发.
Source attribution: curated from shao__meng (@shao__meng).
