LangSmith 上线 AI Search，可用自然语言检索 agent trace

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？”或“用户是否感到沮丧？”这样的问题并不能清晰地映射到单个 trace 属性（如 tags 或 metadata），也无法通过全文搜索来回答。它们需要理解 trace 的内容。在此之前，这意味着要提前设置评估器，或者手动浏览 traces。

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

你可以搜索什么

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

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（LangChain 团队每天使用的开源编码智能体）中随机抽取了 150 段对话。每个任务都在自己的沙箱中运行，具有 shell 访问权限，并且可以将工作交给子智能体，因此对话会变得很大。

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

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

💡 即使追踪数据超过百万 token，许多关于智能体行为的问题只需几千 token 就能回答。

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

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

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

下一步

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

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

我们还希望超越简单的匹配列表，对相似结果进行分组，或总结它们的共同点。

开始使用

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

‍