当 Agent 应用从 Demo 走向真实生产环境，零星问题会演变为海量请求下的系统性挑战。本期播客 LangChain 联合创始人深度揭秘 LangSmith 最新推出的 Insights（洞察） 与 Thread Evals（线程评估） 功能设计思考，分享如何从海量的生产数据中自动发现有价值的模式，如何构建数据驱动的、系统性的质量保障体系，真正提升 Agent 在生产环境中的可靠性。​本文作者 莫尔索，文章转载请联系作者。

欢迎订阅合集 AI 播客捕手：专门面向文字内容爱好者分享 AI 领域优质播客。

目录

• Insights (洞察) - 自动发现海量数据中的模式
• Thread Evals (线程评估) - 评估完整的用户交互
• 离线评估已死？离线评估与在线评估的真正价值
• 个人思考

Insights (洞察) - 自动发现海量数据中的模式

Harrison（LangChain 的联合创始人兼 CEO ） 首先介绍了 LangSmith 平台的演进背景。虽然 LangChain 以其开源库而闻名，但公司从一开始就在构建 LangSmith，一个专为 Agent 工程和 LLMOps (大模型运维) 打造的平台。LangSmith 的功能是逐步构建起来的：最开始是 Tracing 追踪，它帮助开发者理解 Agent 内部的每一步决策，类似于传统软件开发的调试工具。接着，团队构建了离线评估，开发者可以创建数据集、定义指标并运行测试，这类似于软件开发中的单元测试。为了让产品经理和其他非技术人员也能参与到流程中，团队又添加了 Prompt Playground 提示词游乐场 和 Prompt Hub 提示词中心，用于迭代提示词和启动实验。

随着行业的发展，越来越多的开发者开始将他们的 Agent 应用推向生产环境。此时，Tracing 功能（追踪）自然地延伸到了生产环境的 Observability （可观测性） 领域。但新的问题也随之而来：当用户每天向 LangSmith 发送数百万甚至更多的追踪数据时，他们该如何从这些海量信息中挖掘出真正的价值？

这就是新功能 Insights 洞察诞生的背景，现在的客户已经度过了从 0 到 1 构建 Agent 的阶段，他们面临的是生产环境中的海量数据。客户开始询问：“我在 LangSmith 中有这么多丰富的信息，你能告诉我一些关于我的用户如何与 Agent 互动、我的 Agent 表现如何、它在哪里做得好或不好的信息吗？”

Insights 的核心理念，就是自动在这些海量的追踪数据中发现趋势。这些趋势大致可以分为两类：第一类是关于终端用户的行为，例如他们主要在问什么类型的问题，他们试图使用哪些功能；第二类是关于 Agent 自身的行为，例如它在哪里容易犯错，在哪里可能产生了幻觉。

为了满足这些需求，Insights 功能提供了一些内置模式，如产品使用分析和错误分析。但更重要的是，它也向 LangSmith 用户开放了许多自定义功能，用户可以进行配置，去发现他们自己最感兴趣的特定模式。

那么，这个模式是如何工作的呢？其灵感来源于 Anthropic 公司早先发表的一篇论文。当时 Anthropic 团队也面临类似问题：如何理解用户与 Claude 进行的数百万次对话？他们开发了一种名为 Quo 的算法，能够遍历所有对话，并生成一个层次化的主题类别结构，让分析师可以清晰地缩放和查看人们谈论的话题。LangSmith 团队受到了这个想法的启发，但彻底重构了内部实现。因为 LangSmith 处理的追踪数据远比标准聊天机器人的对话记录要广泛和复杂，它需要被泛化以适应各种形态的 Agent。

实现过程中最困难的部分，就是处理任意的 Agent 负载。今天的 Agent 形态极其多样化，并且还在不断演变。它们不仅仅是聊天机器人；许多 Agent 可能在后台运行，根本没有明确的聊天记录可供分析。如何从这些五花八门、结构各异的数据中通用地生成有价值的洞察，是团队目前仍在努力改进的重大挑战。

Insights 算法本身在底层也是一个 Agent。用户越能清晰、具体地描述他们自己的 Agent 是做什么的，以及他们最希望生成哪一类型的洞察，Insights 算法就能返回越好、越有趣的结果。

当获得了这些洞察后。。。。

欢迎订阅合集 AI 播客捕手：专门面向文字内容爱好者分享 AI 领域优质播客。

Thread Evals (线程评估) - 评估完整的用户交互

Threads 是完全由用户根据自身产品交互模式来定义的。例如，如果你的应用有一个类似 ChatGPT 的聊天界面，那么每一个独立的聊天窗口或对话，都可以被定义为一个 Thread，如果你的应用是一个 Copilot 助手，一个 Thread 可能会代表一次完整的用户会话，追踪该用户在应用中与 Agent 发生的所有交互。从技术上讲，这只是一个附加到每条追踪数据上的唯一 UUID，用于建立不同追踪数据之间的关联关系。

为什么要引入 Threads 的概念呢？因为传统的评估方式（即 Single-turn evals，单轮评估)在很多情况下是远远不够的，单轮评估可能只关注“一条用户消息”和“一条 AI 回复”的组合。但很多关键的性能指标，只有在完整的交互上下文中才能被衡量。

Thread Evals 的必要性。第一个例子是评估端到端的用户交互，比如用户情绪，如果你想知道用户在整个对话过程中的情绪变化，或者用户是否在某个时刻表现出了沮丧，你必须拥有完整的 Thread 上下文才能做出判断。第二个例子是评估“工具调用的轨迹”。在一个长对话中，Agent 的工具调用轨迹是怎样的？它是否卡在了某个地方，陷入了重复调用同一个工具的循环？这些问题同样需要端到端的完整视角。

Offline Evals (离线评估)——即构建一个已知的数据集并运行评估器，它与 Thread Evals 与之有何不同？离线评估是针对一套已知示例 运行的，它们测试的是你期望 Agent 表现出的特定行为。当你将产品发布到生产环境时，真实用户的行为方式和提出的问题，并不总是与你最初构建产品时的意图一致。

这就是 Thread Evals 发挥作用的地方，假设你刚刚修改了 Agent 的一个 Prompt (提示词)，并想知道这个改动是否真的提升了用户交互的质量或改善了用户情绪。你可以使用 Thread Evals，在生产数据上实时运行评估器，来衡量这一变化带来的真实影响。

除了运行评估，Threads 这一新概念还带来了其他额外的能力。首先是指标和分析 (Metrics & Analytics)。当分析的粒度上升到 Threads 级别，开发者就可以开始关心一些新的指标，比如“每一次用户交互的平均成本”是多少，或者评估数据（如用户情绪）随时间的变化趋势。

其次是操作和流程 (Actions & Flows)。目前，LangSmith 允许用户将追踪数据导出到数据集，或者让审核人员审查数据。未来，这些自动化流程也将支持 Threads。例如，团队可以设置自动化规则，当系统检测到一个 Thread 中包含负面用户反馈时，自动将其标记，并触发人工抽查这段完整的对话，以便深入分析问题所在。

离线评估已死？离线评估与在线评估的真正价值

近来网上有一种声音，认为离线评估已死，认为开发者所需要的只是 A/B testing 和在线测试，这种说法的逻辑似乎是：在许多 Agent 应用中，你永远无法完全覆盖终端用户可能采取的每一种交互方式。因此，离线评估永远无法 100% 保证 Agent 在生产环境中的行为，既然无法 100% 保证，那么离线评估就是无用的。

这个逻辑站不住脚，在某些定义非常狭窄的 Agent 任务中，开发者完全有可能在部署前就定义好绝大多数的交互行为。其次，也是更重要的一点，无法实现完全覆盖并不意味着不值得枚举已知的交互，你当然应该通过离线评估来确保，至少在你已知的、并且希望 Agent 表现出色的那些核心交互上，它能够出色地完成任务。

离线评估在 Agent 开发中扮演着至关重要的回归测试角色。每当你想要发布一个新版本的 Agent（比如修改了 Prompt 或模型请求参数）时，你都需要运行这些离线评估，以确保新的改动没有破坏那些之前已知能正常工作的功能。

此外，离线评估也可以是一个动态发展的过程。你可以将在生产环境中发现的“坏”交互（比如通过 Insights 功能发现的失败模式）添加回你的离线数据集中。这样，这个离线数据集就会随着时间推移而不断丰富，成为未来回归测试的宝贵资产。

许多团队刚开始构建 Agent 时。。。。。。

欢迎订阅合集 AI 播客捕手：专门面向文字内容爱好者分享 AI 领域优质播客。