为什么智能体必须在生产环境中观察与评估

摘要

1) 一句话总结 智能体因其无限的自然语言输入和非确定性行为，无法依赖传统软件监控，必须采用专门的可观测性工具来追踪完整交互轨迹、结合人工标注与大模型在线评估，以实现生产环境下的持续改进。

2) 关键要点

核心差异：智能体接受无限的自然语言输入，且底层大语言模型（LLM）对提示词微小变化敏感，输出具有非确定性，导致开发环境表现与生产环境可能不符。
监控对象转变：传统APM工具侧重系统指标（延迟、错误率），而智能体监控需捕获完整的提示词-响应对、多轮对话上下文以及多步推理轨迹（含工具调用）。
结构化人工审查：由于人工审查难以扩展（每小时仅能评估50-100条），需引入“标注队列”机制，将特定高价值或高风险的追踪记录路由给人工进行结构化评分。
LLM在线评估：将LLM作为人类判断的代理，建议对10-20%的生产流量进行采样评估，自动检查无参考质量指标、安全性、格式验证及主题分类。
自动化模式发现：利用聚类系统（如Insights Agent）自动分析海量追踪记录，以发现用户真实使用模式、常见故障模式（如工具选择错误）及边缘情况。
开发闭环集成：智能体可观测性必须与开发工作流打通，实现“发现生产问题 → 加入标注队列 → 补充至评估数据集 → 实验修复 → 重新部署”的无缝流转。
跨职能协作：智能体监控工具的用户不再局限于SRE/DevOps，而是扩展至AI工程师、产品经理、领域专家和数据科学家等跨职能团队。

3) 风险与缺口

评估器的准确性与可靠性：现成的LLM评估器并不完美，可能无法准确反映特定应用中“好”的标准，且随着生产流量变化会出现“评估漂移”，需要定期重新调整或结合人工审查。
规模化成本与延迟：对所有追踪记录运行LLM评估会显著增加推理成本，并为每条记录增加数秒延迟，不适用于同步的用户反馈场景。
隐私与合规性挑战：为了实现可观测性而完整捕获提示词与响应对，增加了处理敏感数据和满足隐私限制的基础设施复杂性。

正文

你不能像监控传统软件那样监控智能体（Agent）。它们的输入是无限的，行为是非确定性的，而质量则体现在对话本身之中。本文将解释需要监控什么、如何扩展评估规模，以及生产环境的追踪记录（traces）如何成为持续改进的基础。

当你将传统软件发布到生产环境时，你对其表现会有很好的预期。用户点击按钮、填写表单、在预设的路径中导航。你的测试套件可能覆盖了 80-90% 的代码路径，而监控工具则会追踪常见的指标：错误率、响应时间、数据库查询。当出现故障时，你会查看堆栈跟踪和日志。

智能体的运作方式截然不同。它们接受自然语言输入，可能的查询空间是无限的。它们由大语言模型（LLM）驱动，对提示词的细微变化非常敏感，并且可能对相同的输入产生不同的输出。此外，它们通过多步推理链、工具调用和检索操作来做出决策，而这些在开发阶段是很难完全预料到的。

这意味着智能体的生产环境监控需要与传统可观测性不同的能力。在这篇文章中，我们将探讨为什么智能体的可观测性面临独特的挑战、你需要监控什么，以及我们从大规模部署智能体的团队那里学到了什么。

为什么智能体不同于传统软件

在与将智能体部署到生产环境的团队合作时，我们观察到了影响监控方法的两个关键区别。

智能体拥有无限的输入空间

传统软件具有有限且受约束的输入空间。用户通过具有特定格式的按钮、下拉菜单、表单和 API 调用进行交互。当你设计一个结账流程时，你清楚地知道屏幕的确切顺序和可能的用户操作。你的错误处理可以非常全面，因为你可以枚举出所有的故障模式。

相比之下，智能体接受自然语言作为其主要输入。自然语言没有固定的有效输入集。用户可以用无数种方式表达同一个请求——模糊或具体、正式或随意、在一条消息中结合多个意图，或者将一个请求分散在多个轮次中。

考虑一个客户支持智能体。在传统软件中，用户会导航到“订单历史”，点击一个订单，点击“申请退款”，最后填写一个带有预设选项的表单。这个路径是固定的且可测试的。

而对于智能体，用户可能会说：

“我想退掉我的订单”
“你能帮我把上周买的鞋退款吗？”
“我收到的商品损坏了，我有哪些选择？”
“订单 #12345 请退款”

每一句话都代表了相同的潜在意图，但智能体需要理解这些变化，提取相关信息，并确定适当的操作。这种无限的输入空间意味着，在真实用户开始与智能体交互之前，你无法完全预测它将如何被使用。

大语言模型对微小的变化不够稳健

第二个关键区别是，LLM 表现出对提示词的敏感性和非确定性行为。即使是输入的微小变化也可能导致不同的输出，而且相同的输入有时也会产生不同的结果。

发生这种情况有几个原因。LLM 在生成过程中使用概率采样，这引入了方差。最重要的是，LLM 对措辞、上下文或指令顺序的细微变化会做出不同的反应。

这种非确定性意味着你在开发中观察到的行为可能与生产环境中发生的情况不符。在测试中可靠运行的提示词可能会在你未曾遇到的边缘情况中失败。在评估期间正确使用工具的智能体，可能会在面对措辞略有不同的用户查询时偶尔选择错误的工具。

智能体的生产环境监控截然不同

传统的应用性能监控 (APM) 工具侧重于延迟、流量、错误和饱和度等指标。它们追踪 HTTP 请求、数据库查询和系统资源。它们是为结构化、确定性的系统设计的，在这些系统中你知道可能的代码路径。

智能体的可观测性要求监控输入和输出本身，而不仅仅是围绕它们的系统指标。

监控自然语言交互

当你的智能体与用户进行对话时，主要的信号就存在于对话本身之中。你需要捕获：

完整的提示词-响应对：不仅要记录请求发生了，还要记录用户问了什么以及智能体回答了什么。
多轮上下文：智能体通常在一次对话中跨越多次交流进行操作，因此你需要将相关的交互分组在一起。
智能体轨迹和中间步骤：智能体可以采取多步路径来达到最终输出，包括调用工具和推理选项。你需要对轨迹的每一步都具有可见性，而不仅仅是最终的响应。

这在本质上不同于传统的日志记录。一个传统的 Web 请求可能被概括为 “POST /api/checkout 200 OK 342ms”。而一次智能体交互是一场可能包含几十个步骤的自然语言对话——它进行得是否顺利，是无法从状态码中得出答案的。

大规模人类判断的挑战

自然语言交互通常需要人类的判断才能进行适当的评估。这个回答有帮助吗？智能体理解用户的意图了吗？语气合适吗？它检索到相关信息了吗？

在开发阶段，这是可控的——你可以手动审查追踪记录、调整提示词并进行迭代。但在生产环境中，你可能要处理成千上万甚至数百万次交互。人类审查员每小时可以有意义地评估 50-100 条追踪记录，但如果每天有 1,000 个请求，全面的手动审查每天将需要 10-20 小时的专职人力时间。这就提出了一个重要的问题：当手动审查无法扩展时，如何将人类智能引入生产数据？

我们发现有两种互补的方法非常有效。

用于结构化人类审查的标注队列

标注队列（Annotation queues）有助于使人类审查尽可能高效。标注队列不是让审查员在生产日志中搜寻，而是以结构化的格式和预定义的评分标准呈现特定的运行记录。

一个有效的标注队列系统让你能够：

路由特定的追踪记录进行审查：与其审查所有内容，不如将特定的子集发送到队列（带有负面反馈的运行、高成本的交互或来自特定时间窗口的查询）。
定义审查标准：设置评分标准，以便审查员确切知道要评估什么（相关性、正确性、语气、安全性）。
实现团队协作：多个审查员可以通过进度跟踪和角色分配来处理队列。
创建反馈循环：可以将更正信息标注到已审查的数据上，并将其添加到评估数据集中。

当你试图理解一种新的故障模式、为评估器建立训练数据，或者获取针对特定查询的专家领域反馈时，标注队列尤其有价值。

需要考虑的权衡：标注队列需要专门的审查员时间，并且可能会在改进周期中引入延迟。我们发现，当它们专注于特定的高价值追踪记录，而不是试图实现全面覆盖时，效果最好。

将 LLM 作为人类判断的代理

第二种方法是使用 LLM 本身来扩展人类判断。虽然 LLM 不是完美的评估器，但它们可以在人类无法企及的规模上评估许多质量维度。

特别是，你可以配置在线评估器（online evaluators），使其在生产流量上自动运行，可以是在所有运行记录上，也可以是在采样的子集上。这些评估器可以检查：

无参考质量指标：如连贯性和语气等不需要基准事实（ground truth）答案的属性。
安全性和合规性：响应是否包含敏感信息、违反政策或表现出有害行为。
格式验证：输出是否遵循预期的结构或包含必需的元素。
主题分类：用户正在提出哪些类别的请求。

LLM 能够以超越人类审查的规模评估自然语言。人类可能只能审查几十条追踪记录，而 LLM 评估器可以评估数千条，标记潜在问题并提供汇总指标。

然而，基于 LLM 的评估也引入了其自身的成本和限制：

延迟：评估器可能会为每条追踪记录增加几秒钟的延迟，这对于异步批量评估可能是可接受的，但对于同步的用户反馈则不然。
成本：评估所有追踪记录会增加你的推理成本，这就是为什么我们通常建议对 10-20% 的流量进行采样。
准确性：现成的评估器可能无法反映你的特定应用中“好”的含义。通常需要与你的用例对齐的自定义“LLM 作为裁判 (LLM-as-judge)”评估器，但确保它们与人类判断保持一致也很困难。我们构建了 Align Evals，以帮助团队在规模化信任自定义评估器之前，验证它们是否已根据人类标签进行了校准。
评估漂移：随着生产流量的变化，评估器可能需要重新调整或替换。

出于这些原因，我们建议将自动化评估与定期的人类审查结合起来，而不是仅仅依赖 LLM 评估器。

生产环境智能体可观测性工具

为智能体构建有效的生产环境可观测性需要一组特定的能力，而大多数通用监控工具在设计时并未提供这些能力。基于我们在数十个生产部署中观察到的模式，我们在 LangSmith 中构建了以下功能。

Insights Agent：发现使用和错误模式

在生产环境中最具挑战性的方面之一，仅仅是了解用户在使用你的智能体做什么。

当我们分析团队如何使用生产追踪记录时，我们发现他们需要一种方法来自动发现模式，而无需预先指定要寻找什么。这促使我们构建了 Insights Agent，它使用自动聚类系统将相似的追踪记录分组，以识别：

使用模式：用户最常提出的请求类型是什么？他们试图使用哪些功能或能力？
错误模式：智能体在哪里犯错？是否存在常见的故障模式，如工具选择错误、检索失败或误解用户意图？
边缘情况：用户发送了哪些你没有考虑到的意外查询？

Insights Agent 可以配置为按使用模式、故障模式或特定于你领域的自定义属性对追踪记录进行分组。你还可以将分析过滤到特定的子集（时间窗口、用户群组、功能区域），并保存配置以供重复分析。

例如，一家拥有嵌入式 Copilot 的公司的产品经理可能会问：“用户最常尝试使用 Copilot 来处理我们产品的哪些部分？” Insights Agent 可以分析数千条追踪记录，按意图对它们进行分组，并呈现最主要的使用类别。

一位调试质量问题的工程师可能会问：“我的智能体在哪里选择了错误的工具？” Insights Agent 可以识别工具选择失败中的常见模式，并提供代表性的示例。

这种自动化的模式发现有助于使海量的生产追踪记录变得更易于管理和更具可操作性。

在线评估：持续的质量监控

我们之前提到在线评估是扩展人类判断的一种方式。让我们看看它们在实践中是如何工作的。

借助在线评估，你可以设置在生产追踪记录上自动运行的评估器。你可以配置：

评估哪些追踪记录：所有追踪记录、采样的百分比（通常为 10-20%）或特定的过滤子集。
评估什么：质量指标、安全检查、格式验证或自定义标准。
何时发出警报：当指标下降时触发通知的阈值。

在线评估除了传统的“测试”之外，还有几个目的：

质量监控：你可以跟踪智能体随着时间的推移产生有用、相关、正确响应的频率。这使你能够检测到质量何时因模型更新、数据漂移或新的用户模式而下降。
主题标记：你可以自动将生产查询分类到不同的类别中，以进行产品分析。这让你能够了解用户实际想要完成什么。
轨迹评估：对于使用多个工具或推理步骤的智能体，你可以评估智能体是否采取了适当的路径来获得答案。它是否以合理的顺序调用了正确的工具？它是否检索到了相关信息？
安全与防护：你可以实时检查输出中的敏感信息、政策违规或其他安全问题。

在生产流量上持续运行评估的能力实现了一种开发工作流：你可以深入研究特定的失败追踪记录，将它们添加到标注队列中供人类审查，将它们合并到评估数据集中，并在重新部署之前测试修复方案。

仪表板和警报：监控重要事项

最后，生产环境可观测性需要针对你特定用例中重要指标的仪表板和警报。有效的可观测性平台提供：

用于领域特定洞察的自定义仪表板，允许你跟踪不同工作流的成功指标（例如任务完成率或用户满意度得分）。你还可以比较不同模型版本的性能，并按功能区域监控成本和延迟。
当指标越过阈值时，通过 Webhooks 或 PagerDuty 提供灵活的警报。
从聚合指标向下钻取到特定追踪记录的能力。

生产环境可观测性需要跟踪特定于智能体实际行为方式的指标。除了标准的延迟和错误率之外，这意味着要监控诸如工具调用失败率和按工具划分的运行次数等指标。这些信号告诉你智能体是否真的在按预期工作，而不仅仅是系统是否在运行。

关键是监控业务关键型指标，而不仅仅是技术指标。是的，你关心延迟和错误率。但你也关心用户满意度等指标，以及智能体是否被用于预期目的。

为什么通用工具显得不足

此时，你可能会想：我不能用 Datadog 或 New Relic 等传统可观测性工具来构建这个吗？为什么我需要一个专门的平台？

许多团队最初尝试使用传统的 APM 工具来监控智能体。我们发现这对于基本指标（延迟、错误率）是有效的，但在满足智能体特定需求时会遇到局限性。差距出现在三个领域：有效载荷、连接性和用户。

有效载荷：自然语言数据

传统的 APM 工具针对结构化日志和数字指标进行了优化。当你需要存储、搜索和分析具有多轮上下文的完整对话线程时，你会遇到不同的需求：

存储规模：生产规模的完整提示词-响应对需要大量的存储空间。你需要对提示词进行语义搜索功能，而不仅仅是关键字匹配。并且你需要保留完整的上下文，包括系统消息和少样本示例（few-shot examples）。
数据模型：维护对话线程和状态需要与传统追踪记录不同的数据结构。

我们见过团队在 APM 工具之上构建这些功能，但这需要大量的定制开发。

连接性：与开发循环的集成

智能体可观测性与智能体开发工作流紧密相连，在这个工作流中，你应该在生产监控、评估数据集、实验和重新部署之间不断移动数据。这个循环看起来像这样：

生产追踪记录揭示了失败案例或边缘情况
标注队列让你审查并标记它们
数据集纳入这些示例用于测试
实验测试修复是否改善了行为
在线评估在生产环境中验证修复效果

这需要你的可观测性平台、评估框架和开发工具之间紧密集成。与传统的可观测性工具不同，LangSmith 提供了这种连接性。你可以点击一条失败的生产追踪记录，立即将其添加到数据集中，在 Playground 环境中修改你的提示词，运行一个比较新旧版本的实验，然后充满信心地重新部署。

用户：跨职能团队

最后，需要访问智能体可观测性的人员不同于通常使用 APM 工具的人员。传统的可观测性主要面向 SRE 和 DevOps 团队，他们专注于改善系统健康状况、性能回退和基础设施问题。

智能体可观测性面向跨职能团队，包括：

调试提示词问题和模型行为的 AI/ML 工程师
了解使用模式和功能请求的产品经理
审查特定领域准确性和质量的领域专家（SME）
分析模式并构建评估的数据科学家

我们观察到，智能体可观测性成为这些团队如何协同工作以改善用户体验的核心。他们定期对生产追踪记录进行数据审查，讨论模式，并根据观察到的情况做出关于优先级的决策。

这需要一个专为这些角色之间的协作而设计的界面和工作流，而不仅仅是为基础设施工程师设计的。

尚未解决的挑战

虽然我们描述的方法已被证明对大规模部署智能体的团队有效，但仍然存在重大挑战：

评估器的准确性和可靠性：随着模型变得更好，LLM 评估器也在不断改进，但它们并不完美。了解何时信任自动化评估与何时需要人类审查仍然取决于上下文。
规模化成本：对高容量生产系统进行全面监控可能会很昂贵。在采样、自动化评估和人类审查之间找到适当的平衡是一项持续的优化工作。
隐私和合规性：在尊重隐私限制和妥善处理敏感数据的同时捕获完整的提示词-响应对，增加了可观测性基础设施的复杂性。

结论

智能体的运作方式不同于传统软件。它们接受自然语言输入，表现出非确定性行为，并通过复杂的推理链做出决策。这些特征将生产环境监控的重点从系统指标转移到了实际的输入和输出本身。

我们描述的方法（结构化标注队列、自动化模式发现和持续评估）代表了我们目前关于如何使生产环境智能体行为在大规模下可观测和可改进的思考。基于我们在与部署智能体的团队合作时观察到的模式，我们构建了 LangSmith 来满足这些需求。

如果你正在从事智能体可观测性方面的工作，我们很想听听你发现了哪些有效的方法。了解更多关于 LangSmith Observability 的信息，或阅读我们的可观测性文档。

致谢

感谢 LangSmith 工程团队构建了这些功能，并感谢提供反馈以塑造这种方法的客户。

加入我们的时事通讯

来自 LangChain 团队和社区的更新

正在处理您的申请…

成功！请检查您的收件箱并点击链接以确认您的订阅。

抱歉，出了点问题。请重试。

wsl-docs

探索