跨国深谈← 返回←用一个智能体去修智能体:LangChain 如何打造 Engine v2

用一个智能体去修智能体:LangChain 如何打造 Engine v2

关联

人物 Ben

公司 LangChain · LangSmith

概念 Engine · 智能体 · trace · 评估 · 基准测试 · 红队测试

做智能体（agent）的人都熟悉那套痛苦流程：翻看运行轨迹找错误、归类问题、分析根因、写修复、写评测。

LangChain 把这整条流水线做成了一个产品叫 Engine——它自己去扫轨迹、发现问题、提出修复和测试用例。

今年 5 月发布后，它已经扫描了超过 7000 万条轨迹，创建了超过 21000 个问题 。这场演讲讲的是团队怎么把 Engine 从 v1 打磨成更快、更强、更便宜的 v2。

为什么给 Engine 做评测特别难？

Engine 本身就是个复杂智能体：

它要找出有问题的轨迹并聚类，要写人能读懂的问题描述，要对照源代码写修复，要生成测试数据，还要监控问题是否复发 。

这些任务彼此差别很大，混在一起测不出好坏。

团队的做法是给每个环节单独做基准测试。

比如测找问题轨迹的能力，就造一批埋了已知问题的轨迹，让 Engine 在一堆干草里找针 。

测聚类归因则给它一批已知错误轨迹和已有问题列表，看它能不能正确配对或新建问题。

光靠基准测试不够，还得自己吃自己的狗粮

基准分数高不代表生产环境好用，所以 LangChain 在自家的一堆智能体上跑 Engine——包括做外呼、客户调研的市场智能体，和在 Slack 和 GitHub 里调用的编程智能体 。

Engine 找到的问题会发到 Slack，相关团队直接反馈这问题靠不靠谱。

更有意思的是，他们让 Engine 跑在 Engine 自己上面：

Engine 分析轨迹时也会产生轨迹，这些轨迹由另一个实例（他们叫它 meta-engine）来扫描，出问题同样发 Slack 通知 。

这成了团队发现 Engine 改进机会的主要渠道之一。

小模型有时反而更好用

一个反直觉的经验：不是所有任务都需要最强的前沿模型。

对于简单的笨任务，用更小、更便宜的模型不光省钱，效果有时反而更好 。团队会不断给不同环节换模型做实验。

所有实验都跑在 LangSmith 平台上，记录成本和基准分数随时间的变化。

结果也拿得出手：在主基准 IssueBench 上，错误识别能力提升了 2 倍 。

单看一条轨迹，有些问题永远发现不了

V1 的 Engine 擅长在单条轨迹里找错：幻觉、坏掉的函数调用、循环调用、上下文爆炸 。但有些问题必须跨轨迹才能看出来。

单看某条轨迹，一切正常——一条轨迹里 6 次函数调用，另一条 19 次，看起来都不算异常。

但把统计拉通，发现函数调用次数整体暴涨，很可能这个新模型在疯狂乱调工具 。

另一类是低效路径：比如 5% 的情况下，智能体处理一个普通请求时会绕岔路，去调用一堆不该碰的工具和数据源 。

这类问题也只有在更大的图景下才现形。V2 对这两类都强了很多。

从提建议到验证过的修复

V1 只给你一个问题描述加修复提示，测试靠自己。V2 的核心新功能是经过验证的修复，流程像软件工程里的复现 bug：

Engine 找到问题后，先把出问题的输入重新发给线上版本的智能体，确认 bug 依然存在 ；

然后在 LangSmith 部署平台上开一个预览分支跑修复版，用同样的破坏性输入验证修复真的有效；

最后再跑一遍你配置的更大数据集，确认没有引入别的退化 。

最终交付的不再是一个提示，而是一个确认存在的问题、一个确认有效且不退化的修复。

Ben 认为这是迈向持续学习的第一步——智能体不断自我改进，人仍然在环里把关 。该功能目前在私测阶段，面向 LangSmith 部署客户。

红队测试：在用户受伤之前先打自己

另一个新能力是主动红队：

Engine 根据智能体的系统提示词和运行框架，自己猜测什么样的输入可能搞坏它，然后拿这些输入去轰击线上部署，把不满意的结果聚类、打包成问题加修复建议 。

这样问题在被真实用户碰到之前就被发现和修掉。同样在私测中。

v3 想做什么：更大胆的建议

团队已经在做 v3，方向有三个：让验证修复和红队支持更多部署方式；让 Engine 能自动生成一套基线评测而不只是补充回归用例 ；

以及北极星目标——不再只提小修小补，而是给出大建议，比如「这个模型太贵太笨重，换这个，我已经用你的评测验证过它更快更便宜」。

此外，Engine 也会在下一个版本支持自带密钥的自托管部署。

本集带走

• 评估复杂智能体要拆成环节，每个环节单独建基准测试，再用真实生产环境的狗粮验证基准是否可信。
• 让 Engine 监控 Engine 自己，成了团队发现产品问题的主渠道之一。
• 简单任务用小模型，不仅省钱，有时效果反而更好。
• 单条轨迹看不出的问题（指标趋势、低效路径）需要跨轨迹的统计视角，这是 v2 的重要升级。
• V2 的核心是从提建议走向验证过的修复：复现 bug、预览部署验证、跑数据集防退化，全程人可介入。

从那以后，Engine 已经扫描了超过 7000 万条追踪记录，并为今天正在使用它的众多客户创建了超过 21000 个问题。
And since then, Engine has scanned over 70 million traces and has created over 21,000 issues for the many customers that are using it today.
—— Ben · [01:31]

但也许这种内部使用最有趣的地方在于，我们实际上是在 Engine 之上运行 Engine。
But maybe the most interesting of this dogfooding is that we actually run Engine on top of Engine.
—— Ben · [05:57]

如果是一个所谓的「愚蠢」任务，有时候用一个更笨或更小的模型反而更好，而不是用那些非常昂贵、非常臃肿的最先进模型。
If it’s a quote-unquote dumb task, it’s sometimes better to use a dumber or a smaller model as opposed to these state-of-the-art models that are really expensive and really bulky.
—— Ben · [07:18]

但我们对 Engine 的愿景是：发现问题、修复这些问题、测试那个修复方案，全部自主完成。
But the vision that we have for Engine is the finding of problems, the fixing of those problems, and the testing of that fix all autonomously.
—— Ben · [13:42]