LangChain 推出 LangSmith Engine

agent 开发生命周期现在可以推进得更快。LangSmith Engine 取代了过去那种手动读取 trace、发现模式再编写修复方案的循环，转而持续自动完成这些工作——将生产环境中的失败聚类为具名 issue，结合你的代码诊断根因，并起草 PR 和 evaluator 供你审阅。

每解决一个 issue，都会让你的 eval 套件更强。当 Engine 提供修复方案时，它还会提出一个自定义在线 evaluator，并将失败 trace 拉入你的离线 eval 数据集——这样同一个失败就不会在你发布后悄悄复现。

它构建在你现有的 LangSmith 设置之上。Engine 可以接入你当前的 tracing project、evaluator 结果和代码仓库——无需新增基础设施。连接一个项目，可选择连接你的代码仓库，它就会开始自动从生产环境中发现 issue。

今天，我们正式推出 LangSmith Engine。

在此之前，改进你的 agent 一直是一个手动过程：阅读 trace、寻找模式、编写 eval，并创建修复方案。现在，LangSmith Engine 可以替你运行这一循环。它会观察你的生产 trace，将失败聚类为命名的问题，对照你的代码诊断根因，并提出修复方案和 eval 覆盖，以防止回归问题再次出现。你只需审查并合并这些改进。

LangSmith Engine 今天以公开测试版形式上线。

典型的 agent 开发周期如下：

追踪你的 agent，了解它正在做什么

识别失败模式或功能缺口

调整 prompt、工具、逻辑或结构

基于生产环境 trace 创建标准答案数据集

运行实验以确认改进效果，并检查是否出现回归

LangSmith 已经提供了 trace 视图、快速数据集创建和实验功能，用来支持每一步工作。但我们不断从客户那里听到同样的摩擦点：

很难知道该修哪里，因为逐条查看 trace 无法揭示模式。

在大规模场景下，很难看出某个错误在不同 trace 中反复出现的频率。

从生产数据中为离线评估创建 ground truth 样例既繁琐，又很容易被跳过。

修复上线后，通常并没有针对性的评估器来捕捉同一问题是否再次出现。

Engine 覆盖了整个流程。团队可以在按优先级排序的列表中看到聚类后的失败案例，自动获得修复草案，并收到可加入测试套件的离线评估样例建议。

假设你的 agent 是一个客服机器人。Engine 检测到一组 traces：用户在询问如何取消订阅。你的 agent 做出了回复，但在线评估将这些回复判定为失败，用户反馈也很负面。延迟正常，所以没有触发系统告警。

Engine 会将其呈现为一个命名问题：“Agent fails to handle subscription cancellation requests accurately.” 它会展示严重程度（高，本周影响了 12% 的支持会话）、时间线（四天前开始，与最近一次部署相关），并链接到具体 traces 作为证据。

连接你的代码仓库后，Engine 会读取相关代码并找出根本原因。取消工具的描述存在歧义，导致 agent 在用户只是询问可选方案时也会尝试执行取消操作。Engine 会起草一个 PR，对该工具描述进行有针对性的修复。

为了持续跟踪这一行为，Engine 会提出一个针对该具体问题的自定义在线评估器。这样一来，如果修复上线后同类失败模式再次出现，该问题会带着更新后的细节自动重新浮现。

Engine 还会把这些失败 trace 拉入你的离线 eval 套件，并为每个样例附上判定标准，定义正确输出应包含的内容。那些进入生产环境的失败，会变成防止它们再次出现的测试用例。

这就是完整闭环：自主运行，并呈现给你审核。生产信号会变成聚类后的问题，随后是诊断出的根因、建议的修复方案，以及 eval 覆盖。

对于它发现的每个问题，Engine 都会提出三种解决动作。

打开一个 PR。获得仓库访问权限后，Engine 会起草一项有针对性的代码或 prompt 修改，并向你的仓库提交 PR。你负责审查并合并。

创建一个自定义在线评估器。Engine 会提出一个针对具体问题的评估器。如果问题再次触发，它会带着更新后的细节自动重新浮现。

加入你的离线 eval 套件。Engine 会把失败的生产 traces 拉入一个由真实标注样例组成的数据集，可直接用于你的离线 eval 套件。

每解决一个问题，你的评测覆盖范围也会随之提升。当你确认某个修复有效时，也是在生成一个用于持续监控后续性能的 evaluator。随着时间推移，你已经解决的问题会让评测套件更加完整，从而让未来的改进更稳健。

LangSmith Engine 由一个深度 agent 驱动，它可以访问你的 trace 数据、evaluator 反馈，以及你的 agent 源代码（如果已连接到你的代码仓库）。

它会监控多种 trace 信号：显式错误（工具调用失败、超时）、在线 evaluator 失败、trace 异常（延迟飙升、token 暴涨、异常的步骤数量）、负面用户反馈，以及一些不寻常行为，例如用户询问了 agent 原本并不用于回答的问题。当 Engine 在多条 trace 中发现某种模式时，它会将这些 trace 聚类为一个有名称的问题，而不是逐条暴露每一次失败。

LangSmith Engine 构建在 LangSmith 现有的追踪与评测基础设施之上。它会将你现有的 evaluator 结果作为输入，因此你的评测捕获到的失败会直接进入问题检测流程。当 Engine 提出一个新的 evaluator 时，是因为它发现了你当前覆盖范围中的空白。当它创建一个数据集样例时，该样例会直接进入你现有的离线评测工作流。

Cogent、Harmonic 和 Campfire 等团队已经使用 Engine 解决了影响数千条 trace 的问题。他们能够更早发现回归，更快发布修复，并减少花在分诊上的时间。

到目前为止，我们非常喜欢它。我们的 deepagent trace 可能包含数十甚至数百轮交互，这让审查和识别模式变得很繁琐。LangSmith Engine 不仅能识别新出现的失败模式，还能主动建议 eval 和代码变更，帮助我们快速解决问题，为团队省下了数小时的排查时间。‍——Austin Berke，Harmonic 创始工程师

长期以来，agent 开发生命周期一直过于依赖手动操作。我们正在迈向这样一个未来：更多流程可以在没有手动触发的情况下持续运行，已充分理解的问题类型无需人工审查即可解决，而 harness 也会随着时间推移更了解你的特定 agent。LangSmith Engine 是迈出的第一步。

LangSmith Engine 现已开放 public beta。连接一个 tracing 项目，也可以选择连接你的代码仓库，Engine 就会开始自动从你的生产 trace 中呈现问题。

LangSmith 是我们的 agent 工程平台，帮助开发者调试每一次 agent 决策、评估变更，并一键部署。