LangChain提出评估驱动开发：先写评估再构建AI Agent
LangChain博客介绍一套面向非确定性AI Agent的三步开发流程：定义良好行为、先写评估、改动后对比实验。文中以内部文档Agent增加工单工具为例，说明平均分上升时仍需逐条检查回归。
AI解读：这套流程针对的是AI Agent的非确定性：同一问题每次回答可能不同，多个措辞不同的答案都可能正确，Agent还会自行决定调用哪些工具，因此传统测试不够用。
LangChain称其在构建自家Agent时使用了评估驱动开发，并把流程概括为三步：定义什么是好、在构建前写评估、做出改动后对比。这是公司自述的实践，不是第三方验证。
关键操作是先写评估并确认它在当前版本上失败，再改代码。文章提醒，看到新输出后再补评估，容易写出为通过而设计的评估。
文章用一个内部文档Agent举例：新增create_ticket工具后，工单类样例通过，但“如何连接VPN”被误开工单，平均分上升掩盖了单项回归；追查发现是工具描述过宽，收窄后全部样例通过。
文章还提醒小数据集满分可能意味着过拟合，建议保留不用于调参的留出集；若调参集分数上升而留出集持平，就可能是过拟合。
评估可接入pytest和Vitest，在每次拉取请求时运行；生产环境可用在线评估器、人工标注队列和仪表盘抽样检查，但文章未给出这些做法的效果数据。
LangChain在博客中介绍“评估驱动开发”（eval-driven development，EDD），用于构建和迭代AI Agent。文章称LangChain在构建其较先进的Agent时使用了这套方法，并把它拆成三步：定义Agent的良好行为、在构建前写评估、做出改动后对比实验结果。
文章指出，Agent与传统代码不同：输出会变化，同一个问题每次可能得到不同答案；多个自然语言答案可能都算正确；Agent还会自行选择步骤，可能多调用或漏调用工具却仍给出正确答案。因此需要按一组样例给Agent的运行打分，而不是只做传统断言测试。
三步流程与文档Agent示例
第一步是定义“好”的标准。文章建议先写Agent的产品需求文档，列出需要处理的行为及各自要求，并一次只针对一个行为推进，避免多个改动互相干扰。每个行为先写简短规格：何时触发、应该做什么、不应该做什么、哪些已有行为必须保持。规格要明确到可以判定通过或失败。
文章举例：一个内部文档Agent有search_docs和web_search两个工具，计划新增create_ticket用于提交IT工单。规格是：用户报告东西坏了（如“我的笔记本连不上VPN”）时调用create_ticket；如何操作类问题（如“如何连接VPN”）不应开工单；原有的两个搜索工具行为要保持。
先写评估再改代码
第二步是建数据集并写评估器。数据集由输入和可选的参考输出组成，文章建议优先用真实Agent运行记录作为输入来源，因为用户措辞和边缘情况难以自行预料。在LangSmith中可以把真实运行直接加入数据集。
评估器要对应规格中的“好”。确定性检查用代码评估，非确定性检查可用LLM-as-a-judge。文章示例中，工具选择容易用代码检查，因此评估器检查每个样例是否调用了参考输出中的工具。改动前要先跑一次基线实验，记录当前通过和失败的情况。
文章还提到，对于会在环境中产生改动的Agent（如沙箱中的编程Agent），只检查工具调用和最终回复不够，还要检查Agent留下的系统状态，并让每次运行使用干净环境。LangChain称其用开源框架Harbor运行这类任务，Harbor也是Terminal-Bench等基准背后的执行框架。
对比实验与回归检查
第三步是改动后重跑同一评估并对比实验。文章把这一过程称为向评估“爬山”：每次改动生成一个实验，与上一次对比，查看哪些样例变好、哪些变差。LangChain提醒不能只看平均分，还要看是否有原本通过的行为被覆盖。
文档Agent的例子中，加入create_ticket后，工单样例通过，平均分上升，但“如何连接VPN”开始误开工单。查看运行轨迹发现，工具描述写的是处理“VPN和笔记本问题”，范围过宽，导致提到VPN的问题都匹配到工单工具。把描述收窄为需要IT实际处理的请求后，所有样例通过。
文章同时提醒，在小数据集上拿到满分不一定是正确目标。反复针对同一批样例调整Agent可能过拟合：在调参样例上分数上升，在未查看的留出集上却持平。建议保留一套迭代时不看的样例用于检查。
持续运行评估的方式
文章建议把评估自动化接入开发流程：较快的代码检查可以阻止有问题的合并，较慢的LLM评审评估可以夜间运行或发布前运行；迭代时用数据集拆分只跑当前行为的样例，发布前再跑全量。LangSmith可与pytest和Vitest集成，让评估随每次拉取请求运行并记录为实验。
生产环境中，文章列出几种做法：在线评估器对实时运行轨迹抽样打分；标注队列供团队人工复核被标记的运行，也用于核对LLM评审与人工判断是否一致；仪表盘跟踪评估分数、反馈、成本和延迟随时间的变化；Insights把生产轨迹聚类以发现新问题模式。LangSmith Engine则称可把问题聚类转成带断言的数据集样例供人工复核。
文章最后列出常见错误：成功标准定义过松，例如“回复有帮助”无法判定通过或失败；在修复之后才写评估；只看平均分；添加不需要的评估；以及未经人工核对的LLM评审。