AI 智能体的可观测性与评估

随着 AI 智能体（AI Agents）从实验原型转向现实世界的应用，理解其行为、监控其性能并系统性地评估其输出的能力变得至关重要。

学习目标

完成本课程后，你将了解/掌握：

• 智能体可观测性与评估的核心概念，
• 提升智能体性能、成本和有效性的技术，
• 评估 AI 智能体的内容与系统化方法，
• 在将 AI 智能体部署到生产环境时如何控制成本
• 如何对使用 Microsoft Agent Framework（微软智能体框架）构建的智能体进行检测（Instrument）

本课程的目标是为你提供必要的知识，将你的“黑盒”智能体转化为透明、可管理且可靠的系统。

注意： 部署安全且值得信赖的 AI 智能体至关重要。请同时参考“构建值得信赖的 AI 智能体”课程。

追踪（Traces）与跨度（Spans）

Langfuse 或 Microsoft Foundry 等可观测性工具通常将智能体的运行表示为追踪和跨度。

• 追踪 (Trace)： 代表一个完整的智能体任务，从开始到结束（例如处理一次用户查询）。
• 跨度 (Spans)： 是追踪内的单个步骤（例如调用一次语言模型或检索数据）。

如果没有可观测性，AI 智能体感觉就像一个“黑盒”——其内部状态和推理过程是不透明的，导致难以诊断问题或优化性能。有了可观测性，智能体就变成了“玻璃盒”，提供的透明度对于建立信任并确保其按预期运行至关重要。

为什么生产环境中的可观测性至关重要

将 AI 智能体过渡到生产环境会引入一套新的挑战和要求。可观测性不再是“可有可无”，而是一项关键能力：

• 调试与根因分析： 当智能体失败或产生意外输出时，可观测性工具提供的追踪能够精准定位错误源头。这在可能涉及多次 LLM 调用、工具交互和条件逻辑的复杂智能体中尤为重要。
• 延迟与成本管理： AI 智能体通常依赖于按 Token 或按次计费的 LLM 和其他外部 API。可观测性允许对这些调用进行精确跟踪，帮助识别那些过度缓慢或昂贵的操作。这使团队能够优化提示词、选择更高效的模型或重新设计工作流，以管理运营成本并确保良好的用户体验。
• 信任、安全与合规： 在许多应用中，确保智能体行为安全且符合伦理是非常重要的。可观测性提供了智能体动作和决策的审计轨迹。这可以用于检测和缓解诸如提示词注入、有害内容生成或个人身份信息（PII）处理不当等问题。例如，你可以通过查看追踪记录来理解智能体为什么提供某种特定回复或使用了某个特定工具。
• 持续改进循环： 可观测性数据是迭代开发过程的基础。通过监控智能体在真实世界中的表现，团队可以识别改进点、收集用于微调模型的数据，并验证变更的影响。这创造了一个反馈闭环，即来自线上评估的生产洞察为线下实验和改进提供参考，从而使智能体性能逐步提升。

需要追踪的关键指标

要监控并理解智能体行为，应该追踪一系列指标和信号。虽然具体指标可能因智能体的用途而异，但有一些是普遍重要的。

以下是可观测性工具监控的一些最常见指标：

• 延迟 (Latency)： 智能体响应有多快？漫长的等待时间会负面影响用户体验。你应该通过追踪智能体运行来测量任务和单个步骤的延迟。例如，一个在所有模型调用上花费 20 秒的智能体，可以通过使用更快的模型或并行运行模型调用来加速。
• 成本 (Costs)： 每次智能体运行的开销是多少？AI 智能体依赖于按 Token 计费的 LLM 调用或外部 API。频繁的工具使用或多次提示会迅速增加成本。例如，如果一个智能体为了微小的质量提升而调用了五次 LLM，你必须评估这种成本是否合理，或者是否可以减少调用次数或使用更便宜的模型。实时监控还有助于发现意外的激增（例如导致过度 API 循环的 Bug）。
• 请求错误 (Request Errors)： 智能体失败了多少次请求？这可以包括 API 错误或失败的工具调用。为了使你的智能体在生产环境中对此更具鲁棒性，你可以设置回退机制（Fallbacks）或重试机制。例如，如果 LLM 供应商 A 宕机了，你可以切换到 LLM 供应商 B 作为备份。
• 用户反馈： 实施直接的用户评估可提供宝贵的洞察。这可以包括显式评分（👍点赞/👎点踩，⭐1-5 星）或文字评论。持续的负面反馈应该引起你的警觉，因为这是智能体未按预期工作的迹象。
• 隐式用户反馈： 即使没有显式评分，用户行为也能提供间接反馈。这可以包括立即重新表述问题、重复查询或点击重试按钮。例如，如果你看到用户反复询问相同的问题，这就是智能体未按预期工作的迹象。
• 准确率 (Accuracy)： 智能体产生正确或理想输出的频率是多少？准确率的定义各不相同（例如：问题解决的正确性、信息检索的准确性、用户满意度）。第一步是为你的智能体定义什么是“成功”。你可以通过自动化检查、评估分数或任务完成标签来追踪准确率。例如，将追踪标记为“成功”或“失败”。
• 自动化评估指标： 你还可以设置自动化评估（Evals）。例如，你可以使用一个 LLM 为智能体的输出打分（如是否具有帮助性、是否准确等）。还有几个开源库可以帮助你为智能体的不同方面打分。例如，针对 RAG 智能体的 RAGAS，或用于检测有害语言或提示词注入的 LLM Guard。

在实践中，结合这些指标可以最好地涵盖 AI 智能体的健康状况。在本章的示例 Notebook 中，我们将向你展示这些指标在真实案例中的样子，但首先，我们将学习典型的评估流程是什么样的。

对你的智能体进行检测 (Instrument your Agent)

为了收集追踪数据，你需要对代码进行检测。目标是让智能体代码发出追踪和指标，这些数据可以被可观测性平台捕获、处理和可视化。

• OpenTelemetry (OTel)： OpenTelemetry 已成为 LLM 可观测性的行业标准。它提供了一套用于生成、收集和导出遥测数据的 API、SDK 和工具。

有很多检测库封装了现有的智能体框架，使导出 OpenTelemetry 跨度到可观测性工具变得简单。Microsoft Agent Framework 原生集成了 OpenTelemetry。以下是检测 MAF 智能体的示例：

Python

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
# 智能体执行会被自动追踪
pass

本章的示例 Notebook 将演示如何检测你的 MAF 智能体。

• 手动创建跨度： 虽然检测库提供了良好的基础，但通常在需要更详细或自定义信息的情况下，你可以手动创建跨度来添加自定义应用逻辑。更重要的是，它们可以用自定义属性（也称为标签或元数据）来丰富自动或手动创建的跨度。这些属性可以包括业务特定数据、中间计算或任何可能对调试或分析有用的上下文，例如 user_id、session_id 或 model_version。

使用 Langfuse Python SDK 手动创建追踪和跨度的示例：

Python

from langfuse import get_client

langfuse = get_client()
span = langfuse.start_span(name="my-span")
# 执行逻辑
span.end()

智能体评估

可观测性赋予我们指标，而评估则是分析这些数据（并进行测试）以确定 AI 智能体表现如何以及如何改进的过程。换句话说，一旦你拥有了这些追踪和指标，你如何利用它们来评判智能体并做出决策？

定期评估非常重要，因为 AI 智能体通常是非确定性的，并且会发生演变（通过更新或模型行为漂移）——如果没有评估，你将无法知道你的“聪明智能体”是否真的表现良好，或者是否发生了退化。

AI 智能体的评估分为两类：线上评估 (Online Evaluation) 和 线下评估 (Offline Evaluation)。两者都有价值且互补。我们通常从线下评估开始，因为这是部署任何智能体之前最起码的必要步骤。

线下评估 (Offline Evaluation)

这涉及在受控环境中评估智能体，通常使用测试数据集，而不是实时的用户查询。你使用经过策划的数据集，其中你已知期望的输出或正确的行为，然后在这些数据上运行你的智能体。

例如，如果你构建了一个数学应用题智能体，你可能会有一个包含 100 个已知答案的问题的测试数据集。线下评估通常在开发期间进行（也可以作为 CI/CD 流水线的一部分），以检查改进情况或防范退化。其优点是可重复性，并且由于你拥有标准答案（Ground Truth），你可以获得明确的准确率指标。你还可以模拟用户查询，并根据理想答案测量智能体的响应，或使用上述自动化指标。

线下评估的关键挑战是确保你的测试数据集具有全面性且保持相关性——智能体可能在固定的测试集上表现良好，但在生产环境中遇到完全不同的查询。因此，你应该不断更新测试集，加入能反映现实场景的新边缘案例和示例。将小型“烟雾测试”案例与较大型的评估集结合使用是很有帮助的：小型集用于快速检查，大型集用于更广泛的性能指标。

线上评估 (Online Evaluation)

这指的是在真实的生产环境中评估智能体，即在实际使用过程中。线上评估涉及监控智能体在真实用户交互中的表现，并持续分析结果。

例如，你可以追踪实时流量中的成功率、用户满意度分数或其他指标。线上评估的优势在于它能捕捉到你在实验室环境下可能无法预见的情况——你可以观察随时间推移的模型漂移（如果智能体的有效性随着输入模式的转变而下降），并捕捉测试数据中未包含的意外查询或情况。它提供了智能体在“野外”行为的真实图景。

线上评估通常涉及收集显式和隐式的用户反馈（如前所述），并可能运行影子测试（Shadow Tests）或 A/B 测试（即新旧版本的智能体并行运行以进行对比）。挑战在于，为实时交互获取可靠的标签或评分可能很困难——你可能需要依赖用户反馈或下游指标（例如用户是否点击了结果）。

两者结合

线上评估和线下评估并不是相互排斥的；它们高度互补。来自线上监控的洞察（例如智能体表现不佳的新型用户查询）可以被用来扩充和改进线下测试数据集。反之，在线下测试中表现良好的智能体可以更自信地进行部署和线上监控。

事实上，许多团队采用了一个循环：

线下评估->部署->线上监控->收集新的失败案例->添加到线下数据集->精炼智能体-> 重复。

常见问题

当你将 AI 智能体部署到生产环境时，可能会遇到各种挑战。以下是一些常见问题及其潜在解决方案：

通过建立可观测性，可以更有效地识别许多此类问题。我们之前讨论的追踪和指标有助于精确定位智能体工作流中发生问题的具体位置，使调试和优化变得更加高效。

成本管理

以下是在生产环境中部署 AI 智能体时管理成本的一些策略：

• 使用较小的模型： 小型语言模型 (SLMs) 在某些智能体用例中表现良好，并将显著降低成本。如前所述，构建评估系统来确定并比较 SLM 与大型模型的性能，是了解 SLM 在你的用例中表现如何的最佳方法。考虑将 SLM 用于意图分类或参数提取等简单任务，而将大型模型留给复杂的推理。
• 使用路由模型 (Router Model)： 一种类似的策略是使用多样化的模型和规格。你可以使用一个 LLM/SLM 或无服务器函数（Serverless Function）根据任务复杂度将请求路由到最合适的模型。这在确保正确任务性能的同时，也有助于降低成本。例如，将简单查询路由到更小、更快的模型，仅对复杂的推理任务使用昂贵的大型模型。
• 缓存响应： 识别常见的请求和任务，并在它们进入智能体系统之前提供响应，是减少相似请求量的好方法。你甚至可以实施一个流程，使用更基础的 AI 模型来识别当前请求与缓存请求的相似程度。对于常见问题解答或常规工作流，此策略可以显著降低成本。