内容
当你将传统软件部署到生产环境中时，你对其行为有一个清晰的预期。用户点击按钮、填写表单、导航到预定的路径。你的测试套件可能覆盖了 80-90% 的代码路径，监控工具跟踪了常见的指标：错误率、响应时间、数据库查询。当出现问题时，你会查看堆栈跟踪和日志。
代理程序运作方式不同。它们接受自然语言输入，可能的查询空间是无限的。它们由大型语言模型驱动，这些模型对小的输入变化非常敏感，并且可能为相同的输入产生不同的输出。它们通过多步推理链、工具调用和检索操作进行决策，这些操作难以在开发期间完全预测。
这意味着代理程序的生产监控需要不同于传统可观察性的能力。在本文中，我们将探讨代理程序可观察性的独特挑战、需要监控的内容以及我们从部署代理程序的团队中学习到的经验。
代理程序与传统软件的区别
与部署代理程序的团队合作，我们观察到两个关键区别，这些区别影响监控方法。
代理程序有无限的输入空间
传统软件有一个有限的、受限的输入空间。用户通过按钮、下拉菜单、表单和特定的 API 调用进行交互。当你设计一个结帐流程时，你知道具体的屏幕序列和可能的用户操作。你的错误处理可以全面，因为你可以枚举失败模式。
代理程序，相反，接受自然语言作为主要输入。自然语言没有固定的有效输入集。用户可以以无数种方式表达相同的请求——模糊或具体、正式或随意、将多个意图组合在一个消息中或将单个请求分散在多个回合中。
考虑一个客户支持代理程序。在传统软件中，用户将导航到“订单历史”，点击一个订单，点击“请求退款”，然后填写一个预定义的选项表单。路径是固定的和可测试的。
与代理程序相比，用户可能会说：
- “我想退回我的订单”
- “可以帮助我退回我上周购买的鞋子的钱吗？”
- “我收到的物品有问题，什么是我的选项？”
- “订单 #12345 退款，请”
每个表达都代表相同的潜在意图，但代理程序需要理解变异、提取相关信息并确定适当的操作。这意味着你无法完全预测你的代理程序如何被使用，直到真正的用户开始与它互动。
LLMs 对小变化不敏感
第二个关键区别是 LLMs 显示出提示敏感性和非确定性行为，即使是小的输入变化也可能导致不同的输出，相同的输入也可能在某些情况下产生不同的结果。
这发生的原因有几个。LLMs 在生成过程中使用概率采样，这引入了方差。最重要的是，LLMs 对于微小的变化在提示、背景或指令顺序上都有反应。
这种非确定性意味着开发期间观察到的行为可能与生产环境中的行为不符。一个在测试中可靠的提示可能在边缘案例中失败。一个在评估期间正确使用工具的代理程序可能偶尔选择错误的工具来处理用户查询，仅仅因为提示的措辞有所不同。
代理程序的生产监控
传统的应用程序性能监控（APM）工具关注指标，如延迟、流量、错误和饱和度。它们跟踪 HTTP 请求、数据库查询和系统资源。它们是为结构化、确定性的系统设计的，知道可能的代码路径。
代理程序可观察性需要监控输入和输出本身，而不是围绕它们的系统指标。
监控自然语言交互
当你的代理程序与用户进行对话时，主要信号存在于对话本身。需要捕获：
- 完整的提示-响应对 : 不仅仅是请求发生了，而是用户问了什么和代理程序回复了什么
- 多轮上下文 : 代理程序通常在多个交换中操作，以实现一个对话，因此需要将相关的交互组合在一起
- 代理程序的轨迹和中间步骤 : 代理程序可以通过多步路径到达最终输出，调用工具并通过选项进行推理。需要对每个轨迹步骤有可见性，而不是仅仅关注最终响应
这与传统日志记录有本质区别。一个传统的 Web 请求可能被总结为“POST /api/checkout 200 OK 342ms”。一个代理程序的交互是一个自然语言对话，可能有几十个步骤——并且问题是它是否成功的答案不能从状态代码中得出。
人类判断的挑战
自然语言交互通常需要人类判断才能评估得当。这个响应是否有帮助？代理程序是否理解了用户的意图？响应的语气是否合适？是否检索了相关信息？
在开发期间，这是可管理的——你手动审阅跟踪，调整提示并迭代。但是在生产环境中，你可能处理成千上万的交互。人类审阅员可以评估 50-100 个跟踪，但在 1,000 个请求的日常情况下，全手动审阅将需要 10-20 小时的专门人力。这引发了一个重要的问题：如何将人类智慧带入生产数据，当手动审阅不再可行时？
我们发现两种补充方法有效。
注释队列用于结构化的人类审阅
注释队列有助于使人类审阅尽可能高效。不是要求审阅员在生产日志中寻找特定跟踪，而是将特定的跟踪呈现给审阅员，按照预定义的评估标准。
一个有效的注释队列系统让你：
- 将特定的跟踪发送到审阅 : 而不是审阅所有内容，将特定的子集发送到队列（带有负反馈、高成本交互或来自特定时间窗口的请求）
- 定义审阅标准 : 设置评估标准，让审阅员知道要评估什么（相关性、准确性、语气、安全性）
- 启用团队合作 : 让多个审阅员通过队列进行合作，跟踪进度和角色分配
- 创建反馈循环 : 审核数据可以被标记为错误并添加到评估数据集中
注释队列在尝试了解新故障模式、建立评估数据集或获取专家领域反馈时特别有价值。
需要考虑的权衡：注释队列需要专门的审阅员时间，并可能会引入改进周期的延迟。我们发现它们在专注于特定高价值跟踪而不是尝试全面覆盖时最有效。
LLMs 作为人类判断的代理
第二种方法是使用 LLMs 来扩大人类判断的范围。虽然 LLMs 不是完美的评估者，但它们可以评估许多质量维度的数量远远超过人类。
具体来说，你可以配置在线评估来在生产流量上自动运行，或者在所有跟踪中采样。这些评估者可以检查：
- 参考自由质量指标 : 不需要真实答案的属性，如一致性和语气
- 安全性和合规性 : 是否包含敏感信息、违反政策或展现有害行为
- 格式验证 : 是否遵循预期结构或包含必需元素
- 主题分类 : 用户正在做什么样的请求
LLMs 可以在人类审阅无法做到的规模上评估自然语言。虽然人类审阅员可能审阅几十个跟踪，但 LLM 评估者可以评估数千个跟踪，标记潜在问题并提供汇总指标。
然而，LLM 基于评估也会引入自己的成本和约束：
- 延迟 : 评估者可能会在每个跟踪上添加几秒钟的延迟，这可能在异步批量评估中是可接受的，但在同步用户反馈中则不是
- 成本 : 评估所有跟踪可能会增加你的推理成本，这是为什么我们通常建议采样 10-20% 的流量
- 准确性 : 直接购买的评估者可能不会反映你特定应用程序的“好”的含义。自定义 LLM 作为评估者需要与人类判断一致的 LLM 可能很难确保。我们构建了 Align Evals 来帮助团队验证他们的自定义评估者与人类标签一致之前信任它们。
- 评估漂移 : 生产流量的变化可能需要重新调整或更换评估者
因此，我们建议将自动评估与定期人类审阅结合起来，而不是仅仅依赖 LLM 评估者。
构建有效的代理程序生产可观察性需要特定的能力，许多通用监控工具并未设计为提供这些能力。基于我们在数十个生产部署中观察到的模式，我们在 LangSmith 中构建了以下内容。
代理程序见解：发现使用模式和错误模式
在生产环境中理解用户如何使用你的代理程序是其中一个更具挑战性的方面。
当我们分析团队如何使用生产跟踪时，我们发现他们需要一种自动发现模式而不需要指定要查找的方法。这种挑战激发了我们构建 Insights Agent 的想法，它使用自动聚类系统来组合相似的跟踪以识别：
- 相似跟踪的群集 : 不同跟踪的共同模式
- 异常跟踪 : 与其他跟踪不同的模式
- 高频跟踪 : 在生产中出现频率最高的跟踪
产品环境下的挑战
生产环境下的一个更具挑战性的方面是简单地理解用户如何使用你的代理。
当我们分析团队如何使用生产跟踪时，我们发现他们需要一种自动发现模式的方法，而不需要事先指定要查找的内容。这促使我们构建了Insights Agent，它使用自动聚类系统将相似跟踪分组以识别：
- 使用模式：用户发出的请求类型最常见的是什么？他们试图使用的功能或能力是什么？
- 错误模式：代理在哪里出错？是否有常见的失败模式，如工具选择错误、检索失败或理解用户意图错误？
- 边缘案例：用户发送的意外查询是什么？你没有考虑到的？
Insights Agent可以配置为根据使用模式、失败模式或特定于你的领域的自定义属性分组跟踪。你还可以过滤分析以特定子集（时间窗口、用户群、功能区域）并保存配置以重复分析。
例如，一家公司的产品经理可能会问：“我们的产品中哪些部分用户最常试图使用copilot？”Insights Agent可以分析数千个跟踪，根据意图分组，并显示顶级使用类别。
一名工程师可能会问：“我的代理在哪里选择了错误的工具？”Insights Agent可以识别工具选择失败的常见模式并提供代表性示例。
这种自动模式发现有助于使生产跟踪的数量更可管理和可操作。
在线评估：持续质量监控
我们之前提到在线评估作为一种扩展人类判断的方法。让我们看看它在实践中的工作原理。
在线评估中，您可以设置自动评估器来在生产跟踪上运行。您可以配置：
- 评估哪些跟踪：所有跟踪、样本百分比（通常为10-20%）或特定过滤子集
- 评估什么：质量指标、安全检查、格式验证或自定义标准
- 警报何时触发：当指标下降时触发通知
在线评估在传统“测试”之外具有以下目的：
- 质量监控：您可以跟踪代理产生有帮助、相关、正确的响应的频率。这样您就可以检测到由于模型更新、数据漂移或新用户模式而降低质量。
- 主题标签：您可以自动将生产查询分类为类别以进行产品分析。这为您提供了了解用户实际试图实现什么的可见性。
- 轨迹评估：对于使用多个工具或推理步骤的代理，您可以评估代理是否采取了合适的路径来回答问题。它是否调用了正确的工具？它是否检索了相关信息？
- 安全和安全性：您可以检查输出中是否有敏感信息、政策违规或其他安全问题。
能够在生产流量上持续运行评估使开发工作流程成为可能，您可以深入到特定失败跟踪中，添加它们到注释队列中进行人类审查，将它们纳入评估数据集，并在重新部署之前测试修复。
面板和警报：监控关键指标
最后，生产观察性需要面板和警报来监控特定于您的具体用例的指标。有效的观察性平台提供：
- 自定义面板以获得领域特定的见解，允许您跟踪成功指标（如任务完成率或用户满意度分数）以不同的工作流程。您还可以比较不同模型版本的性能并监控成本和延迟以功能区域为单位
- 可以通过 webhook 或 PagerDuty 进行灵活警报的指标跨阈值
- 从聚合指标到特定跟踪的下钻能力
生产观察性需要跟踪代理实际行为的特定指标。除了标准延迟和错误率之外，这意味着监控指标如工具调用失败率和工具运行次数。这些信号告诉您代理是否实际上正在按照预期工作，而不是仅仅系统正在运行。
关键是监控业务关键指标，而不是仅仅技术指标。是的，您关心延迟和错误率。但您还关心用户满意度，以及代理是否被用于预期的目的。
此时，您可能会问：我不能使用传统的观察性工具，如 Datadog 或 New Relic 来构建它吗？为什么我需要一个专门的平台？
许多团队最初尝试使用传统 APM 工具监控代理。我们发现这对于基本指标（延迟、错误率）有效，但在代理特定要求方面遇到了限制。差距出现在以下三个领域：负载、连接性和用户。
负载：自然语言数据
传统 APM 工具优化为结构化日志和数字指标。当您需要存储、搜索和分析完整的会话线程，包括多轮上下文时，您会遇到不同的要求：
- 存储规模：生产规模下全提示-响应对需要大量存储。您需要在提示中进行语义搜索，而不是仅仅关键字匹配。您还需要保留完整的上下文，包括系统消息和少量示例。
- 数据模型：维护会话线程和状态需要不同于传统跟踪的数据结构。
我们看到团队在 APM 工具上构建了此类功能，但这需要大量的定制开发。
连接性：与开发循环的集成
代理观察性与代理开发工作流程密切相关，开发人员应该不断将数据从生产监控、评估数据集、实验和重新部署之间移动。循环如下：
- 生产跟踪揭示失败案例或边缘案例
- 注释队列允许您审查并标记它们
- 数据集将这些示例纳入测试
- 实验测试修复是否改善了行为
- 在线评估在生产中验证修复
这需要您的观察性平台、评估框架和开发工具之间的紧密集成。与传统观察性工具不同，LangSmith 提供了此连接性。您可以单击失败的生产跟踪并立即将其添加到数据集、修改提示在沙盒环境中、运行实验以比较旧和新版本并重新部署时具有信心。
用户：跨功能团队
需要访问代理观察性的用户不同于通常使用 APM 工具的用户。传统观察性主要是为 SRE 和 DevOps 团队使用的，他们关注改善系统健康、性能回归和基础设施问题。
代理观察性是为跨功能团队使用的，包括：
- AI/ML 工程师调试提示问题和模型行为
- 产品经理理解使用模式和功能请求
- 主题专家（SME）审查准确性和质量在特定领域
- 数据科学家分析模式并构建评估
我们观察到代理观察性成为这些团队之间合作改善用户体验的中心。他们经常进行数据审查、讨论模式并根据观察到的内容做出决策。
这需要一个为跨功能团队设计的界面和工作流程，而不是仅仅为基础设施工程师。
开放挑战
虽然我们描述的方法在部署代理的团队中已经证明有效，但仍存在许多挑战：
- 评估准确性和可靠性：LLM 评估程序继续改进，但它们不是完美的。理解何时信任自动评估而何时需要人类审查仍然取决于上下文。
- 成本：全面监控高容量生产系统的成本很高。找到采样、自动评估和人类审查之间的平衡是一个持续的优化。
- 隐私和合规：捕获完整的提示-响应对，同时尊重隐私约束并处理敏感数据的方式增加了观察性基础设施的复杂性。
结论
代理以与传统软件不同的方式运行。它们接受自然语言输入、表现出非确定性行为并通过复杂的推理链进行决策。这些特性使生产监控从系统指标转向实际输入和输出本身。
我们描述的方法（结构化注释队列、自动模式发现和持续评估）代表了我们目前对如何使生产代理行为在规模上可观察和可改进的思考。我们基于与部署代理的团队合作的模式构建了LangSmith。
如果您正在工作于代理观察性，我们很感兴趣地知道您发现有效的方法。了解更多关于LangSmith Observability或阅读我们的观察性文档。
附加阅读
如果您正在工作于代理可观察性，我们很想知道您发现有效的方法是什么。 了解更多关于 LangSmith Observability 或阅读我们的 可观察性文档。
附加阅读
学习如何：
- 周一使用在线评估 来监控他们面向客户的代理
- Appfolio 利用 LangSmith 来监控并定位生产中的问题
- Podium 收集用户反馈 并进行在线评估以改进响应质量
- Jimdo 监控代理指标，包括质量评分和工具质量输出
致谢
感谢 LangSmith 工程团队为这些功能的建设，感谢提供反馈并塑造了这一方法的客户。