JaydenAI的博客

对于利用LangGraph构建的工作流，前面的文章介绍了不需要LLM参与，通过将提取的执行轨迹与评估基准进行比较的方式来评估。我们不经介绍了AgentEvals原生的评估方案，还介绍我们经过改进和优化的方案（上篇下篇），以及如何从持久化的Checkpoint中提取执行轨迹。出来这种依赖我们手工比较的方式，我们也可以利用LLM-as-a-Judge的形式来评估其执行轨迹。

若要对利用LangGraph创建的基于工作流的Agent进行轨迹评估，前提条件是得提取代表节点流程得执行轨迹。在[前文]中，我们利用在每个节点函数中注入的`RunnableConfig`提取出`PregelScratchpad`对象，并利用此对象提取当前的Superstep编码，在进一步将它与当前节点名称的映射保存下来，进而得到完整的节点流转轨迹。这无疑是一种**丑陋**的编程方式：我们不应该将与业务功能无关的评估逻辑定义在节点函数中。这篇文章提供一种更好的方式：从`Checkpointer`持久化的快照中

为了彻底解决AgentEvals针对LagnGraph轨迹评估无法解决同一Superstep内多个节点并发执行的问题，我通过定义一个全新的`graph_trajectory_match`和`graph_trajectory_match_async`函数提供一种更加灵活的评估方案。[上篇]提供了针对这种方案的编程体验，本篇介绍这这两个函数涉及的轨迹评估究竟是如何实现的。

AgentEvals利用`graph_trajectory_strict_match`和`graph_trajectory_strict_match_async`这两个函数完成基于工作流节点流转的轨迹评估。它提供的解决方案具有一个很大的问题：由于将待评估的执行轨迹表示为简单的节点名称列表，导致无法解决基于并发节点执行的场景（并发节点执行顺序不可控，应该在忽略执行顺序的前提下实施评估）。为了我通过重写评估方法提过一种给全新的评估方案。

LangChain体系还有另一个重要的分支，那就是LangGraph，而且它是前两者的基础。LangGraph可以构建任意结构的工作流，所谓的轨迹就成了工作流中各节点的流程，这是OpenEvals默认没有的，我们来看看如何利用AgentEvals来完成这种类型的轨迹评估，背后的原理有时怎样？

在OpenEvals基础上基础上LangChain团队又推出了一个名为**AgentEvals**评估框架。AgentEvals完全建立在OpenEvals之上，目前只提供了两种基于Agent执行轨迹的评估，一种是面向**OpenAI**消息风格的轨迹评估，正好可以应用到**LangChain**和**DeepAgents**构建的Agent上，另一种则是专门针对**LangGraph**执行轨迹的评估。