重构Agent的“DNA”！LangChain创始人提出“可靠性”新架构，终结“随机性”噩梦。

程序猿李巡天

1070人浏览 · 2025-11-17 14:26:31

程序猿李巡天 · 2025-11-17 14:26:31 发布

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

一、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 工程师如果发现某个失败模式（例如，检索步骤总是无法返回正确的上下文）发生的频率远高于其他模式，他们就知道应该集中精力解决这个特定问题。如果 Insights 显示用户总是在问某一类问题，而 Agent 目前缺乏回答这些问题的工具，开发者可能就需要更新 Agent 的架构，为其增加新的能力。

Insights 与 Evals (评估) 之间的区别，Insights 的核心是发现，它处理的是“已知之未知”或“未知之未知”；而 Evals 的核心是验证，是你预先知道要检查什么，并定义好标准。Insights 往往是 Evals 的前导步骤：你通过 Insights 发现了一个新的失败模式，然后就可以将这个模式转化为一个 Eval，以便在未来持续地监控它。

二、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 时，选择的用例通常具有较高的容错率，比如有人类在循环中 (human in the loop) 进行干预。但是，随着 Agent 被用于更关键的用例，测试所需的严谨性必然会随着时间推移而大幅增加。人们将不得不对测试变得“更加有条不紊” (much more methodical)。这就是评估发挥作用的地方。这不再是仅仅依靠 vibe testing (凭感觉测试) 来比较两个版本的好坏，投入更多严谨性进行系统性测试正变得越来越重要。

四、个人思考

1.发现与验证的闭环

Agent 运维的成熟路径是从验证走向发现再回到验证，早期我们使用评估来验证已知的假设 (单元测试)，但面对海量的生产数据，我们需要 Insights 来自动发现未知的模式和失败案例，然后，再将这些新发现的模式固化为新的评估，形成持续监控和回归测试的闭环。

2.选择正确的评估单元

评估 Agent 性能时，必须找对评估单元。传统的单轮对话评估是孤立的，无法捕捉真实的用户体验。Thread Evals 的理念是，评估单元应该是完整的交互或会话。只有在端到端的线程上，我们才能评估如用户情绪变化、工具调用轨迹等真正影响体验的关键指标。

3.离线与在线评估的互补性

离线评估永远不会死，它是质量保证的基础，核心价值在于扮演回归测试的角色，确保新版本不会破坏已知功能，而在线评估则是实时雷达，用于衡量 Agent 在真实、不可预测的用户流量中的即时表现，两者结合，才是完整的 Agent 质量评估体系。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述