产品 LangChain Blog·原文 2026年11月3日本站收录 2026年11月4日

LangChain提出代理评估三原则，LangSmith标注队列支持按完整会话审查

LangChain博客称，代理承担更长、更复杂的任务后，单看最终回答不足以评估表现；其提出以专家判断定义质量、在完整会话上下文中审查、把人工反馈转为可复用评估数据三条原则，并介绍LangSmith标注队列新增以「线程」为单位的审查方式。Fetch Rewards的用法是文中给出的案例。

AI解读：LangChain博客提出以人为中心的代理评估思路，核心论点是：只检查AI最终回答不够，人工审查用于定义「好」的标准、在上下文中判断表现，并把专家判断变成可复用的评估数据。

博客介绍LangSmith标注队列中的队列项可以是单次运行（单个步骤或span），也可以是线程（完整多轮会话）；对多轮代理，审查单位应是整段对话，以免漏掉前几轮导致最终回答出错的上下文。

人工标注的产出被描述为「评分加理由」：这些标签可用于校准LLM裁判、更新在线评估器、以及把高质量人工标注样本提升为黄金数据集，用于离线实验。

文中以Fetch Rewards为案例：审查员评估AI Rewards Assistant的单轮输入输出时会查看trace元数据，核对工具调用与返回数据是否一致、商品卡图片是否对应正确商品、以及推荐优惠是否对用户可用。

上述内容来自LangChain自家博客，属公司对产品能力和方法的说明；文中未给出人工审查提升代理表现的具体量化数据，案例也仅描述流程，未披露效果指标。

LangChain博客发文讨论代理（agent）开发中的人工审查，提出三条原则：由专家判断定义什么是好的表现、在完整交互上下文中评估代理、把人工反馈转成可复用的评估数据。文章同时介绍LangSmith标注队列中的线程（thread）功能，并给出Fetch Rewards的使用案例。

文章对代理trace的定义是：一次尝试中代理所做全部事情的记录，包括用户消息、模型回复、工具调用和中间步骤。团队用trace调试行为、给质量打分并决定要修什么。

标注队列里，人工补的是自动化给不出的判断

博客称，工程师或在线评估器标记一条trace时，这个标记是信号而非解释，通常不足以说明该如何修改代理。被标记的trace进入标注队列，由人工审查者打开交互并留下反馈：代理做得对不对，以及为什么。文章的原话是「自动化选择审查什么，人提供构建者据以行动的判断」。

在LangSmith中，队列项可以是一次运行（单个步骤或span），也可以是一个线程（完整的多轮会话）。文章称，以线程为队列项时，审查者看到的是用户实际经历的对话，而不是被切出来的单独一步。

第一条原则是人的视角定义「好」的样子。文章称，审查者带来trace本身不含的领域判断：在这项工作里「好」意味着什么、用户想做什么、代理本应怎么做。专家审查中最有价值的部分之一是理由，即说明输出为什么对或错、高质量代理应如何表现。文章还提到，审查者可能发现评估器打错了行为，或评分标准存在缺口。

第二条原则是上下文决定判断是否站得住。文章称，如果只看多轮会话中的一步，审查者可能漏掉解释最终回答的早期消息、工具调用和决策；一个回复单看没问题，却可能因为用户早先说过的话而是错的，错误可能发生在几轮之前，直到最后一条消息才显现。文章因此主张多轮代理的审查单位应是整段对话。

第三条原则是把专家判断变成高质量评估数据。文章描述的操作是：审查者在队列中按评分标准给运行或线程打分（通过/不通过、1 至 5 分、「共情」、「工具正确」等），通常附一句理由；这条带标签的样本成为该交互的真实基准，不只记录「不好」，还记录哪个维度失败、什么算「好」。

文章以Fetch Rewards为例，称其用标注队列把人工判断变成自动裁判的参照点。审查员评估AI Rewards Assistant的单个轮次（一条输入和一条输出），但对话记录只是起点；要判断回复好不好，往往需要进一步查证。

文章给出的具体做法包括：审查员查看trace元数据，确认助手调用了哪些工具、回答是否与工具返回结果一致；核对商品卡图片是否对应正确商品，例如 20 盎司可口可乐的卡片不能配 2 升瓶装图；由于推荐只有用户实际能用才有用，审查员还会查用户的可用优惠，确认建议对用户可用。

文章称，遇到模棱两可的情况，例如图片差一点对、优惠技术上有效但没帮助、回答准确却偏离用户意图，审查员会权衡证据，并在标注队列评论中记录查了什么、哪里仍不清楚、为什么给这个分。工程师再据此找出自动裁判逻辑与人工审查的差异并调整。