LangSmith 推出 AI Search，用自然语言按行为搜索 agent 轨迹

Agent traces 体量大、多模态且信息密集。它们记录了用户输入、agent 如何响应以及逻辑失败等关键细节。这使得 traces 对于理解用户行为和提升 agent 性能具有独特价值，但传统数据平台并非为这种大型、非结构化负载而构建。

要让 trace 数据发挥作用，团队需要能够支撑完整生命周期的基础设施：摄取并存储高并发的运行数据、灵活查询 traces，并将其转化为用于调试、产品分析以及标注等运营工作流的视图。这就是我们构建 SmithDB 的原因——它是专为 LangSmith 中的 trace 数据打造的数据库，以及最近的 Custom Apps，让团队能够在 traces 之上创建定制化视图。

今天，我们新增了 AI Search，一种使用自然语言查询 traces 的新方式。

我们为什么构建 AI Search

每个 trace 都包含用户输入、agent 推理、工具调用和响应，这些信息足以理解 agent 在哪些方面表现良好、在哪些方面失败。使用 LangSmith 的团队经常挖掘他们的 agent traces，为 eval dataset 寻找示例，或为 annotation queue 中的审核人员寻找对话。

然而，找到合适的 traces 可能很繁琐。像“是否泄露了 PII？”或“用户是否感到沮丧？”这样的问题，并不能清晰地映射到 tags 或 metadata 这样的单一 trace 属性上，也无法通过全文搜索来回答。它们需要理解 trace 的内容。在此之前，这意味着要提前设置一个 evaluator，或者手动翻阅 traces。

这就是我们构建 AI Search 的原因。你描述你所寻找的行为，LangSmith 就会返回发生该行为的 traces。这使你能够找到大海捞针般的 traces，并临时搜索棘手的模式。

你可以搜索什么

你可以搜索 trace 内容中出现的任何内容。你可能会寻找一个声称完成了任务但实际并未完成的 agent、一个似乎感到沮丧或对答案提出反驳的用户、一个泄露了 PII 的模型请求，或一个试图取消订阅的人。产品团队可以搜索“对我们不支持的集成的请求”、“提到了竞争对手”或“用户对 onboarding 感到困惑”，并以用户自己的话看到产品在哪些方面存在不足。

AI Search 还可以与你已经在使用的过滤器配合使用，因此搜索可以仅针对出错的 traces 运行，或仅针对带有特定 tag 的 traces 运行。

我们是如何构建的

为什么让模型读取每一个 trace

向量搜索是按语义而非精确词语进行搜索的常用方式。它将你的查询和每个 trace 转换为一个 embedding，即一串捕捉文本主题的简短数字列表。然后它返回 embedding 与你的查询最接近的 traces。这对于主题搜索很有效，比如查找关于账单的对话。但一个 embedding 将整个 trace 压缩进一个小向量中，而这种压缩是有损的。与你的查询相关的重要细节可能会丢失。一个 agent 成功完成工作的 trace 和一个只是声称完成了工作的 trace，最终可能得到几乎相同的 embedding。要区分它们，需要一个模型同时读取 trace 的实际文字和你的问题，从而对发生了什么进行推理。

直到最近，在搜索时这样做仍然太慢、太昂贵。快速决策模型改变了这一点。它们能针对输入快速且低成本地回答一个狭窄的问题，足以大规模运行。AI Search 将决策模型推理与 SmithDB 配对，后者是我们用于智能体可观测性的数据层。当追踪数据到达时，SmithDB 会将其转化为轨迹。当你运行搜索时，你的过滤器会缩小候选范围，决策模型则根据你的描述逐一检查剩余的轨迹。

追踪数据体积庞大且格式繁多

追踪数据来自多种来源：OpenAI 和 Anthropic SDK、LangChain、LangGraph、Vercel AI SDK、OpenTelemetry 等。每种来源记录消息的方式都略有不同。追踪数据还会自我重复。智能体通常会在每次 LLM 调用时重新发送对话历史，因此第一条消息会在其后的每次调用中再次出现。

SmithDB 会将这些追踪数据转化为每个会话的轨迹。轨迹是智能体工作的精炼视图：每条消息、工具调用和工具结果都只列出一次。SmithDB 在追踪数据到达时构建它，并将所有支持的格式统一为相同的形态。

AI Search 分析的是轨迹而非原始追踪数据。由于每种格式都具有相同的轨迹形态，一次搜索即可适用于基于不同 SDK 构建的智能体。移除重复消息可减少上下文膨胀，从而使搜索运行更快。轨迹还覆盖整个会话，因此如果你搜索“用户试图取消”，模型会看到用户问了什么、智能体做了什么，以及对话如何结束。

轨迹仍然很长

移除重复内容有所帮助，但智能体轨迹仍然很长。为了了解到底有多长，我们从 Open SWE 中随机抽取了 150 段对话，这是 LangChain 团队每天使用的开源编码智能体。每个任务都在自己的沙箱中运行，可访问 shell，并可将工作移交给子智能体，因此对话会变得很大。

即便样本如此之小，其中几段对话也超过了一百万个 token。搜索罕见行为意味着要通读大量对话，因此 AI Search 经常遇到这种规模的对话，无法读取每一个 token。

不过，大多数问题并不需要所有这些 token。许多问题关乎用户问了什么以及智能体如何回复。在中位对话中，其 72K 个 token 中约有 2K 来自用户消息和智能体回复。约 85% 是工具输出，主要是文件读取和 shell 命令。

💡 即使追踪数据超过一百万 token，许多关于智能体行为的问题也可以用几千个 token 来回答。

‍

每条轨迹都会获得固定的 token 预算，按优先级顺序填充。用户消息和智能体对用户的回复优先放入。剩余预算分配给其他所有内容：中间 AI 消息（智能体的推理和工具调用）、工具结果和系统消息。如果下一条消息只能部分放入，则对其进行裁剪以填满预算，其后的内容则被丢弃。

搜索必须在大规模下保持快速

SmithDB 旨在摄取并扫描大量 agent trace 数据。当你运行搜索时，结构化过滤器会先缩小候选范围。随后，决策模型会根据你的描述逐一检查剩余的轨迹，许多检查是并行进行的。当模型检查一批轨迹时，SmithDB 已经在获取并准备下一批。匹配结果一经发现便会流式返回，因此你无需等待完整扫描结束。

接下来是什么

我们仍在了解人们最常提出哪些问题。最难分类的对话是那些差异微妙的对话。区分“用户放弃了”和“用户得到了所需内容后离开”，可能取决于一段长轨迹中的几个回合。我们想看看，一个在轨迹上微调过的模型能否更可靠地区分它们。

当答案存在于用户和 agent 所说的话中时，token 预算效果很好。其他问题则需要不同的证据。agent 忽略工具错误，只会体现在工具结果中。我们正在探索根据问题选择上下文的方法，以及能显示模型何时不确定的信号，以便它能带着更多上下文进行第二轮处理。

我们还希望超越简单的匹配列表，通过将相似结果分组或总结它们的共同点来实现。

开始使用

AI Search 已在 LangSmith Cloud 的 GCP 美国、欧盟和亚太区域公开测试，无需额外费用。组织管理员可以在设置中开启它，随后它便会出现在 tracing 页面上。AI Search 文档中有详细信息。告诉我们你搜索了什么。

‍