LLM评估与AI可观测性：Agent监控指南

您唯一需要的 Python IDE。

Tutorials

用于 Agent 监控的 LLM 评估与 AI 可观测性

2026 年 5 月 19 日

_本文是客座文章，作者为__[Naa Ashiorkor](https://blog.jetbrains.com/pycharm/2026/05/llm-evaluation-and-ai-observability-for-agent-monitoring/#author)__，她是一位数据科学家和技术社区建设者。_

人工智能正在以惊人的速度持续发展。AI，特别是 LLM 的最新主要应用是 AI agents。这些系统利用其对环境、流程和输入的感知来采取行动以实现特定目标，并且它们是基于 LLM 构建的。

日益复杂的 AI agents 正越来越多地被应用于真实世界场景。尽管使用单个 agent 完成目标的简单 agent 应用仍然存在，但组织现在正转向多 agent 系统，该系统由一个主 agent 协调多个子 agent。这些系统适应性更强，在执行数据分析、合规性、客户支持等专业任务时，能够模拟人类团队的工作方式。AI agents 的推理和自主性得到了提升；因此，它们能够收集数据、进行交叉引用并生成分析报告。

随着我们朝着这些复杂的、真实世界的 agent 应用迈进，如何观察 AI agents 以及如何评估构建它们的 LLM，正受到越来越多的关注。AI agents 表面之下的复杂性、交互和自主流程，使得严格的监控和评估成为构建和维护这些应用必不可少的一环。LLM 评估决定了 AI agent *能否*正常工作，而 AI agent 可观测性则决定了它*是否正在*正常工作。LLM 评估在部署前后测试 agent 的基本能力，而 agent 可观测性则在 agent 上线后，为其内部推理和运行健康状况提供深入的实时可见性。很明显，只具备其中之一是一种损失，也是导致失败的根源。

在这篇博文中，我们将探讨如何使用高级指标和可观测性工具来评估 agents。本文旨在为那些希望超越演示、在真实的线上环境中实际运行 AI agents 的团队，提供一个实用的端到端参考，以避免在生产环境中导致失败的常见陷阱。

现代人工智能系统的核心 LLM 评估指标

由于 LLM 现在被广泛应用于各种用例，因此对它们的评估必须涵盖其可能执行的任务及其潜在风险。评估指标有助于更好地理解 LLM 的优势和劣势，影响人机交互的指导方向，并强调了确保 LLM 安全性和可靠性的重要性。因此，用于评估 LLM 性能的评估指标在现代 AI 系统中是不可或缺的。没有明确定义的评估指标，模型质量的评估将变得主观。

有多种关键的评估指标，每种指标的目的各不相同，下表总结了其中一些。

评估指标该指标评估的内容 幻觉率 生成内容的事实准确性和真实性 毒性评分 有害、冒犯性或不当内容 RAGAS (检索增强生成评估)衡量 RAG 系统是否检索到正确的文档，并生成忠实于这些来源的答案 DeepEval 在整个 LLM 应用中，测试从基本准确性和安全性到复杂 agent 行为和安全漏洞的所有方面

幻觉率

LLM 中的幻觉会产生看似令人信服但缺乏事实依据的输出，可以分为内在幻觉和外在幻觉。内在幻觉指输出与源内容相矛盾，外在幻觉则指输出内容根本无法被验证。幻觉的产生可能源于数据、训练和推理等多个阶段的多种因素，从用于初始训练的大型数据集和用于微调模型行为的数据中的质量问题，到使模型过于急于提供响应的后训练技术，再到推理时不完美的解码策略。由于幻觉是一个贯穿模型开发各个阶段的未解挑战，因此对其进行衡量和评估仍然是 LLM 评估的重要组成部分。

检测幻觉的技术多种多样，包括：

• 事实核查： 从模型输出中提取独立的事实陈述（事实提取），然后根据可信的知识来源进行验证（事实验证）。
• 不确定性估计： 利用模型内部状态提供的确定性，来评估某项事实内容是幻觉的可能性。
• 忠实性幻觉检测： 确保 LLM 对所提供的上下文或用户指令的忠实性。

用于幻觉检测的指标有多种。一些最常用的指标包括：

• 基于事实的指标： 通过衡量生成内容与源内容之间的事实重叠度来评估忠实度。
• 基于分类器的指标： 利用训练好的分类器来区分生成内容与源内容之间的蕴含关系。
• 基于问答的指标： 使用问答系统来验证源内容与生成内容之间的信息一致性。
• 基于不确定性的指标： 通过衡量模型对其生成输出的置信度来评估忠实度。
• 基于 LLM 的指标： 使用 LLM 作为评估器，通过特定的提示策略来评估生成内容的忠实度。

PyCharm 的 Hugging Face 集成功能 让您无需离开 IDE 即可发现评估模型和数据集。使用 _Insert HF Model_ 功能搜索幻觉或毒性分类器，并将鼠标悬停在代码中的任何模型或数据集名称上，即可即时预览其模型卡片，其中包括训练数据、预期用途和局限性。这意味着您可以在一个地方导入数据集、评估您的 LLM，并验证您正在使用的工具。

_在 PyCharm 中从__代码__菜单打开 Hugging Face 模型浏览器，然后选择__Insert HF Model__._

_搜索特定的幻觉模型并选择一个。__Use Model__会将一个即用型代码片段插入编辑器。_

_编辑器中插入了__Vectara 幻觉评估模型__的即用型代码片段。_

_在代码中将鼠标悬停在__Vectara 幻觉评估模型__上，以在 PyCharm 中预览其模型卡片。_

信任对于技术的接受和采用至关重要。在医疗、金融、个人助理、自动驾驶等领域，对 AI 的信任尤为重要。幻觉对用户对 LLM 的信任有着巨大影响。

2023 年，一个故事广为流传，讲述了一位曼哈顿律师提交了一份主要由 ChatGPT 生成的法律简报。法官很快注意到它与人类撰写的提交文件有很大不同，暴露了明显的幻觉迹象。此类事件凸显了 LLM 错误在现实世界中的风险及其对用户信任的影响。随着人们遇到更多幻觉的例子，对 LLM 可靠性的怀疑与日俱增。

毒性评分

在网络上大型数据集上预训练的 LLM，倾向于生成有害、冒犯和无礼的内容，以及有毒语言，例如仇恨言论、骚扰、威胁和有偏见的语言，这对它们的安全部署产生了负面影响。毒性检测是通过将开源工具或 API 集成到 LLM 工作流中，来分析用户输入和 LLM 输出，从而识别和标记有毒内容的过程。一些可用的毒性工具包括免费的 OpenAI Moderation API，它适用于任何文本，并且实现快速。Google 的 Perspective API 也被广泛使用，其方法论透明，但将在 2026 年后停止服务。Detoxify 是开源的，没有 API 成本，并且对 Python 友好。Microsoft 的 Azure AI Content Safety 是可定制的，最适合企业部署和现有的 Azure 用户。Hugging Face Toxicity Models 提供了多种模型选项，并且可以轻松与 Transformers 集成。

毒性检测已成为一道护栏；因此，在面向用户的应用中它非常重要。它们可以阻止有毒内容触达用户，从而保护个人和组织。在面向用户的应用中，毒性检测通过输入过滤、输出监控和实时评分来运作。这可以防止用户通过协调的有毒输入来故意训练 AI 产生有毒内容的攻击；即使底层 AI 产生了有毒内容，它也永远不会触达用户，因此系统可以根据对话内容和不断升级的风险动态调整其行为。未设防的 AI 可能被利用，从而导致声誉损害。

对于毒性评估，PyCharm 的 Hugging Face _Insert HF Model 功能_ 可以帮助您直接在 IDE 中发现像 s-nlp/roberta_toxicity_classifier 这样的分类器。将鼠标悬停在模型名称上会显示其模型卡片，您可以在其中看到它是在 Jigsaw 有毒评论数据集上训练的，这有助于您在编写任何一行评估代码之前就了解该模型能检测什么和不能检测什么。

_在 PyCharm 中从__代码__菜单打开 Hugging Face 模型浏览器，然后选择__Insert HF Model__._

_搜索特定的毒性模型并选择一个。__Use Model__会将一个即用型代码片段插入编辑器。_

编辑器中插入了 roberta_toxicity_classifier 的即用型代码片段。

将鼠标悬停在代码中的 roberta_toxicity_classifier 上，以在 PyCharm 中预览其模型卡片。

LLM 评估框架

LLM 评估框架改变了游戏规则；团队不再需要依赖人工审查、直觉和主观判断来评估模型质量。这些框架使用标准化、可量化的指标来自动化模型质量的测量。它们为输出分配数值分数，以衡量忠实度、相关性、毒性以及其他重要维度。这种自动化带来了可复现性、速度和客观性。

因此，相同的输入总是会产生相同的分数；评估运行速度快了 10-100 倍，因此只需几分钟而不是几天；并且不再有关于输出质量的争论。其中一些框架包括 DeepEval 和 检索增强生成评估框架 (Ragas)。DeepEval 是一个开源的评估框架，其构建遵循了七项原则，例如能够像 Pytest 一样轻松地对 LLM 输出进行“单元测试”，以及即插即用超过 50 种由 LLM 评估的指标，其中大多数指标都有研究支持，并且所有指标都是多模态的。

通过两种评估模式，即端到端 LLM 评估和组件级 LLM 评估，构建和迭代 LLM 应用变得极其容易。它用于对 RAG、agents 和聊天机器人进行全面测试。Ragas 是一个用于对 RAG 管道进行无参考评估的框架。需要考虑的维度有几个，例如检索系统识别相关且专注的上下文段落的能力，以及 LLM 以忠实的方式利用这些段落的能力；因此，评估 RAG 系统具有挑战性。Ragas 提供了一套指标，用于在不依赖真实人工标注的情况下评估这些维度。

静态提示评估的局限性

传统的 LLM 评估方法适用于单个提示-响应对、衡量输出质量、具有简单检索的 RAG 系统，以及使用固定输入的静态评估。但它们对于多步 agents 来说存在局限性，因为 LLM 评估关注的是最终输出的质量，而非产生该输出的决策过程。多步 agents 展现出一种不同的复杂性，因为它们将多个决策链接在一起。

为什么传统的 LLM 评估对 agents 来说还不够

Agents 在复杂的工作流中独立运行，而这种独立性会带来一些挑战，例如偏离预期行为、生产环境中的错误，以及比传统软件应用更多的故障点。因此，一个 agent 在测试中可能表现良好，但在生产中却可能失败。传统的 LLM 评估没有能力测试此类用例。测试通常在受控环境中进行，场景有限，而生产环境则涉及真实用户、边缘情况、不可预测的输入和规模。这意味着 agents 可能会做出在测试中未曾见过的决策，并且在生产环境中，任务可能被完成（尽管是错误的），却不会产生错误信号。这时，高级的评估和监控实践就派上用场了！它们提供了部署 agents 所需的可见性和系统性测量，使你能够充满信心地进行部署，而不是依赖反复试错。

Agent 行为的复杂性

传统的 LLM 评估衡量的是单个提示-响应对：提供一个输入提示，接收一个输出响应，并通过准确度、相关性和忠实度等指标来衡量质量。由于 AI agents 的复杂性、非确定性和多步推理，它们无法使用传统的评估指标进行可靠的评估。

Agent 行为是复杂的，这种复杂性带来了挑战。Agents 在动态环境中运行，API 可能宕机，数据库在查询之间可能发生变化，并且“正确”的答案取决于当前条件。它们可以使用外部工具和 API 来完成任务，但可能会用错工具，或者用对了工具但参数或输入类型错误。它们的内部推理轨迹除非被明确记录，否则保持隐藏状态，因此可能很难判断一个 agent 的成功是通过逻辑还是偶然。一个 agent 的输出可能在内部决策很差的情况下却完全正确，或者整个任务可能在步骤执行正确的情况下却失败了。

这时，可观测性工具就变得至关重要。PyCharm 的 AI Agents Debugger 打开了智能系统的黑箱，让你无需编写任何额外代码，就可以直接在 IDE 中追踪 LangGraph 工作流，并检查每个 agent 节点的输入、输出和推理过程。只需安装插件，运行你的 agent，调试器就会自动捕获执行轨迹。点击 _Graph_ 按钮即可可视化完整的工作流，从而轻松发现 agent 在何处选错了工具、传递了错误的参数，或是靠运气而非逻辑取得了成功。

为了实际演示，我使用 LangGraph 构建了一个简单的旅行规划 agent，它包含两个步骤：一个研究节点，根据我的偏好推荐夏季目的地；一个规划节点，选择最佳方案并制定为期三天的行程。借助 AI Agents Debugger，你可以精确追踪这两个步骤之间流动的信息——研究节点推荐了什么，以及规划器如何利用这些建议来构建最终的行程。

AI Agents Debugger 展示了 agent 如何从初始化阶段进入研究阶段，并显示了传入和传出的数据，以及用于生成研究结果的 LLM 调用。

_AI Agents Debugger展示了规划步骤如何处理输入并产生输出，它通过调用 LLM 来构建最终的旅行行程。_

_图视图提供了 Agent 工作流的高级概览，描绘了它如何从初始步骤，经过研究和规划，最终到达成结果的整个过程。_

高级 Agent 评估指标

AI Agent 的复杂性要求评估不能只看最终输出的质量，即衡量其准确性、相关性和事实依据性。专门的 Agent 评估会审视完整的决策过程，包括规划逻辑、工具选择、参数构建、推理连贯性和资源效率，这些因素共同导致了最终的输出。因此，高级 Agent 评估指标旨在让这一过程变得可见且可衡量。其中一些指标包括任务完成率、工具使用、推理质量、效率和错误处理。

任务完成率

任务完成率衡量 Agent 成功达成最终目标的任务百分比。其计算方式为：完成的任务数除以尝试执行的任务总数。“完成”的定义因用例而异。任务完成率在现实世界中有多种用例。让我们从一个基础的用例开始。假设一个客服 Agent 正在处理一个特定的外卖订单：“我的订单 #0001 在哪里？还没有送达。”完成率意味着成功查询订单号、获取跟踪信息并提供准确的预计送达时间，因此这三个步骤都必须成功。如果 Agent 查询了错误的订单或未能评估跟踪系统，即使它产生了相同的输出，也算作任务失败。

接下来，我们看一个中等复杂度的用例：连续的 API 调用。假设一个 Agent 的任务是创建一个 Jira 支持工单并在 Slack 中通知相关团队。该 Agent 调用 Jira API 创建工单，解析响应以获取工单 ID，然后使用工单链接调用 Slack API，最后验证两者是否都成功。如果 Agent 成功创建了 Jira 工单，但 Slack 通知失败，那么即使工单存在于 Jira 中，这也算作一个失败的任务，因为团队没有被通知到。

最后，我们来审视一个高复杂度的用例：一个 Agent 被赋予完成在线购买的任务，这意味着它必须处理从结账到订单确认的所有环节。这涉及六个步骤：验证商品是否仍有库存、使用信用卡或借记卡处理支付、预留或减少库存、创建订单记录、生成订单确认号以及向客户发送确认邮件。如果 Agent 成功扣除了客户的卡费，但确认邮件发送失败，那么即使支付已处理且订单已创建，这仍然是一个失败的任务。在这种情况下，客户没有购买凭证，他们很可能会联系客服或尝试再次购买。

工具使用正确性

工具使用正确性评估 Agent 是否正确识别并调用了相关的工具和 API。它是一个确定性度量，像大多数 LLM 评估指标一样，使用“以 LLM 为评判者”等技术进行评估。它包含三个维度：

• Agent 是否为任务选择了正确的工具（工具选择）？
• 参数是否构建正确（输入参数）？
• Agent 是否正确使用了工具的结果（输出处理）？

因此，它对于可靠性和功能正确性至关重要。

逐步推理准确性

在现实世界的用例中，LLM Agent 的推理过程所受的影响远不止模型本身。像 LangChain 这样的现代框架，通过对中间推理步骤的结构化日志记录，将 Agent 的内部“思考”过程暴露出来。这是通过 ReAct（推理和行动）模式完成的，该模式涉及 Agent 思考要做什么、使用工具、观察工具结果，然后重复此过程直到任务完成。每个“思考”都会以文本形式记录下来，从而创建一个从初始查询到最终答案的完整推理过程追踪记录。这些追踪记录可以被程序化提取和评估，以判断 Agent 的逻辑是否合理，即使最终输出看起来是正确的。评估规划步骤涉及评估诸如整体方法的逻辑性、步骤的排序以及是否有任何步骤是不必要或冗余的等方面。评估执行则检查实现是否有效，例如工具是否以正确的参数调用、每个步骤是否成功完成、错误是否得到妥善处理以及输出是否被正确解读。在 PyCharm 中，可以使用 AI Agents Debugger 无缝地进行此操作。

事实依据性（忠实性）

事实依据性，也称为忠实性，是检索增强生成（RAG）最关键的指标，而 RAG 是 Agent 应用中的一个常见组件。它评估 Agent 的响应是否真正由检索到的源文档支持，或者说，模型是否产生了幻觉信息。不同的评估技术包括：

• 原子化声明验证： 将响应分解为原子化声明，并根据检索到的上下文逐一核对。这种方法速度较慢，但最适合用于生产环境的 RAG 和全面评估。
• 语义相似度： 比较响应和源文档的嵌入向量。这种方法速度快，因此最适合用于快速检查和初步筛选。
• LLM 即裁判： 通过提示 LLM 从响应中提取事实陈述，然后根据检索到的上下文核对每个陈述，从而对事实依据进行评分。它的速度中等，最适合用于灵活的自定义标准。

AI 可观测性及其重要性

AI 可观测性旨在洞察代理正在做什么。这涵盖了记录任务执行时发生的所有事情，包括代理在每个步骤的推理、调用了哪些工具及参数、检索了什么数据，以及从头到尾是如何做出决策的。有了这样一个透明的系统，每个决策都可以被记录和追踪，团队能够理解代理为何失败、行为异常或运行成本高昂，因为问题可以被调试，行为可以被审计。因此，系统设计得到改进，猜测被消除。

AI 可观测性的定义

AI 可观测性是对代理行为、思维和环境交互的实时监控：输入了什么，输出了什么，代理如何思考问题，以及使用了哪些工具、API 和数据。AI 可观测性建立在 DevOps 可观测性的三大支柱之上，即指标、日志和追踪，但针对 AI 的独特需求对每一项都进行了扩展。DevOps 指标跟踪 CPU 和延迟，而 AI 指标则跟踪 Token 使用量和每次交互的成本。DevOps 日志捕获系统错误，而 AI 日志捕获推理轨迹和决策点。DevOps 追踪跟随请求在服务间的流转，而 AI 追踪则跟随推理在代理步骤、工具调用和观察中的过程。

代理监控的优势

代理监控具有巨大的优势——以下是一些最重要的方面：

• 它有助于调试推理错误： 当代理失败或产生意外输出时，监控能提供其决策过程的完整追踪，精确显示逻辑在何处出错。因此，无需再花费数小时猜测原因。
• 它衡量随时间变化的性能和延迟： 由于跟踪了所有查询的平均延迟、Token 使用量、每次交互的成本和完成率等指标，因此可以在问题影响用户之前识别出性能下降的模式。因此，性能问题可以在用户投诉之前被识别和解决。
• 它在模型或提示词更新后识别回归： 首先建立完成率、忠实度分数、延迟和成本等基线指标，然后在部署后监控其偏差。如果新的提示词导致完成率下降，或者模型更新增加了幻觉率，自动警报会立即捕捉到。因此，问题在影响用户之前就能被发现。

主流的代理监控工具

已经出现了多个框架和平台为 AI 代理提供内置的可观测性，每个平台都有不同的优势和集成方法，匹配不同的功能和需求。选择合适的工具取决于所用的框架、部署偏好和主要需求。下表列出了一些流行的工具，以及它们是否匹配不同的功能和需求。

| 工具 | 追踪代理步骤？ | 跟踪成本？ | 检测回归？ | 可自托管？ | 开源？ | 易于集成？ | |---|---|---|---|---|---|---| | Helicone | 是 | 是 | 是 | 是 | 是 | 是 | | LangSmith | 是 | 是 | 是 | 有限 | 否 | 是 | | LangFuse | 是 | 是 | 是 | 是 | 是 | 中等 | | OpenLLMetry | 是 | 有限 | 有限 | 是 | 是 | 中等 | | Phoenix | 是 | 有限 | 是 | 是 | 是 | 中等 | | TruLens | 是 | 有限 | 是 | 是 | 是 | 中等 | | DataDog | 有限 | 是 | 是 | 否 | 否 | 中等 |

生产环境中评估代理的最佳实践

评估在部署后并未结束；恰恰相反，它得到了加强。这种持续评估跟踪系统运行成本、在不同负载下的响应速度，以及它如何处理错误或异常输入。没有这样的评估，问题只能在用户受到影响后才能被发现。一个代理可能通过了所有质量检查，拥有出色的忠实度分数、高完成率和强大的推理能力，但如果成本失控、延迟增加或边缘案例导致系统不稳定，它仍然会在生产环境中失败。因此，持续进行评估和监控至关重要，这将使系统变得可靠、可扩展且财务上可持续。

监控成本和延迟

监控成本和延迟对于生产环境的可持续性至关重要。必须持续跟踪 Token 使用量和响应时间，因为微小的低效会随着时间的推移而急剧放大，并且用于代理的强大推理模型其每个 Token 的成本可能很高。生产工作负载需要成本和延迟监控，以便在用户体验和预算受到影响之前识别问题。成本监控在不同层面跟踪 Token 使用量，例如每次请求、每种查询类型以及随时间变化。如果没有对这些产生的模式的可见性，团队最终会通过意外的账单才发现成本问题。有了监控，他们可以主动缓存常见查询并优化提示词以减少 Token 使用。延迟监控则揭示响应时间和组件分解，以识别瓶颈。

在生产工作负载中，成本控制至关重要，因为生产成本可能迅速失控，未受监控的系统可能会超出预算，而延迟则会影响用户体验和用户留存。

结合离线与在线评估

有效的 Agent 评估需要结合离线与在线评估，因为两者可以互补对方的不足。离线评估使用固定的测试数据库进行可复现的基准测试，这使得在受控环境中无需承担生产风险，即可快速迭代提示和模型。在线评估监控生产环境中的真实用户交互，能够揭示测试中从未预料到的边界情况，因此对于实时反馈、用户数据和可观测性工具非常有用。将两者结合，可以得到一种最优策略：先通过离线评估在部署前验证变更，再通过在线评估监控生产环境的实际情况。

在必要时使用人机协同

LLM Agent 因其在不同生态系统中发挥的积极作用而备受赞誉，但并非每个 Agent 都应自主运行，因为它们可能会误解提示、越界或做出仅靠自动化无法捕获的严重错误。因此，人机协同的故障保护机制是必要的。在初始设置阶段，人机协同也至关重要：除非团队已经拥有用于监控 Agent 的特定领域评估数据集，否则就需要通过评估 Agent 的表现来手动创建这些数据集。当关键决策需要人工验证时，例如批准交易、修改敏感数据或触发不可逆的工作流，就需要采用混合方法。在这种方法中，关键在于决策在继续执行前需要经过人工检查点。其目的并非减慢自动化进程，而是确保正确的决策包含适当的监督。一个设计良好的人机协同系统会随着时间的推移带来复合回报。每一次人工修正都会成为反馈，从而提高 Agent 的准确性，并逐渐减少人工审查的需要。人工监督不被视为一种失败，而是一个安全网，它能让系统在使用中变得越来越好。

总结

从根本上说，AI Agent 与单次提示的 LLM 不同。它们需要处理多步骤工作流、做出自主决策并使用外部工具，这引入了需要持续评估而非仅仅是静态测试的复杂性。评估必须从部署前的检查点演变为持续的监控。生产就绪的 Agent 不仅要经过充分测试，还需要根据实际行为被持续观察和改进。LLM 评估和 AI 可观测性通过及早发现问题并将生产环境的洞察反馈到开发中，从而实现更快、更安全的迭代。

PyCharm 通过集成的调试、性能分析和测试功能简化了 Agent 的开发流程。使用断点逐步跟踪推理过程，找到成本瓶颈，并快速迭代评估测试。这些工作流程将数小时的调试工作转变为数分钟的系统性调查。探索 PyCharm 的 AI 开发功能，了解其集成工具如何帮助您构建、评估和部署可靠的 AI Agent。

关于作者

#### Naa Ashiorkor

Naa Ashiorkor 是一名数据科学家和技术社区建设者。她深度参与 Python 社区，并担任包括 EuroPython 在内的多个会议的组织者。她目前正在筹建 PyLadies Tampere。

[](https://blog.jetbrains.com/pycharm/2026/05/llm-evaluation-and-ai-observability-for-agent-monitoring/#)

1. 现代 AI 系统的核心 LLM 评估指标
2. 幻觉率
3. 毒性分数
4. LLM 评估框架
5. 静态提示评估的局限性

1. 为何传统的 LLM 评估对 Agent 来说还不够
2. Agent 行为的复杂性

1. 高级 Agent 评估指标
2. 任务完成率
3. 工具使用正确性
4. 逐步推理准确性
5. 事实依据性（忠实度）

了解更多

1. AI 可观测性为何重要
2. AI 可观测性的定义
3. 智能体监控的益处
4. 智能体监控的常用工具

1. 在生产环境中评估智能体的最佳实践
2. 监控成本和延迟
3. 结合离线与在线评估
4. 必要时使用人在回路

1. 总结
2. 关于作者