5种代理失败模式对比LangSmith、Langfuse和Phoenix：各工具的捕获与遗漏

一个常见的例子：代理在链条中途选择了错误的工具，因为输入格式漂移了一两个字段，而追踪仍然显示每个步骤都是绿色的，全部'成功'。运行最终到了错误的位置，但追踪中没有任何部分看起来损坏。许多代理失败都发生在这里：追踪看起来干净，但运行做了错误的事情。 以下五种常见的失败模式，对比了大多数团队已经使用的三种工具： 失败模式 LangSmith Langfuse Phoenix 链中途错误工具调用（仍追踪为成功） 事后标记，通过追踪/评估 事后标记，通过追踪/评估 事后标记，通过追踪/评估 模型更新后格式漂移导致解析失败 评估回归，评分后 评估后 评估后 一个护栏持续数周后让一个通过 事后分析；网关在调用前编辑PII 仅在外部护栏标记时记录 无原生护栏，调用后评估 失控循环/令牌预算爆炸 网关在路径中设置上限和速率限制 事后可见，未限制 事后可见，未限制 检索返回自信但无关上下文的块 相关性评估后 接地评估后 检索评估后 前两种和最后一种可以通过运行后读取追踪来捕获。中间两种需要其他东西。一个悄然退化的护栏，或一个耗尽令牌预算的循环，需要在请求路径中有东西可以在调用发出前采取行动，在任何评分之前。这是与追踪和评估不同的层面。 Langfuse和Phoenix是观察和评分的工具，因此它们会显示这些问题，但将阻止留给外部网关或护栏库。LangSmith今年夏天添加了一个LLM网关，可以在路径中设置上限和速率限制，这涵盖了失控循环的情况，尽管一个滑动的护栏仍然倾向于在滑动后才显示。 Future AGI就是为那个中间层面构建的：它像其他工具一样进行追踪和评估，但它的护栏和模型-工具网关是内联运行的，因此它可以在预算上限处截断失控循环，并在调用发出前阻止标记的调用。Langfuse和Phoenix将阻止步骤交给单独的库，而LangSmith的网关涵盖模型路由和支出，Future AGI的还能决定每个请求中调用可以访问哪些工具。你可以在一个地方获得追踪、评估、护栏和每个调用的工具控制，基于Apache-2.0核心，可以自托管。链接在第一条评论中。 那么对于调用前的类别，失控循环和退化的护栏，人们今天如何捕获这些？路径中的网关、外部护栏库，还是干脆承受并在事后清理追踪？