AI Agent Observability: The 8 Best Tools for Production Agents AI Agent 可观测性：生产环境 Agent 的 8 款最佳工具

Your AI agents work fine in a demo. Then they hit production, and something breaks. An agent that used to complete a task correctly now stalls on a tool call, hallucinates an answer, or loops between two steps and burns through tokens for 10 minutes before timing out. No one on the team can say why because no one can see what the agent actually did.你的 AI Agent 在演示环境中运行良好，但一旦进入生产环境，就会出现问题。一个原本能正确完成任务的 Agent，现在可能会在调用工具时卡住、给出幻觉答案，或者在两个步骤之间陷入死循环，耗尽 10 分钟的 Token 后才超时。团队中没人能解释原因，因为没人能看到 Agent 到底做了什么。

That gap shows up because agentic AI doesn't behave like the code most observability tools were built to watch. Frameworks like LangGraph, CrewAI, AutoGen, and the OpenAI Agents SDK all produce non-deterministic systems where the same input can take a different path on different runs. This is something traditional monitoring, built around predictable request paths, doesn't handle. That means watching them requires tracking traces, tool calls, and model behavior instead of basic request-and-response codes. Without that level of visibility, agents remain black boxes where you can see something went wrong but not why. 这种差距之所以出现，是因为 Agentic AI 的行为方式与大多数可观测性工具所针对的代码逻辑不同。LangGraph、CrewAI、AutoGen 和 OpenAI Agents SDK 等框架产生的都是非确定性系统，相同的输入在不同运行过程中可能会走不同的路径。传统监控围绕可预测的请求路径构建，无法处理这种情况。这意味着要监控它们，需要追踪链路、工具调用和模型行为，而不是仅仅依靠基本的请求-响应代码。如果没有这种可见性，Agent 就像黑盒一样，你只能看到出错了，却不知道原因。

Fixing that visibility gap starts with identifying which operational problem you are trying to solve. Some teams need basic execution tracing: identifying which tool calls fired, where latency piled up, or why a handoff between two agents failed. Other teams already have trace visibility but can't tell if output quality is degrading, whether a model hallucinated, or if a prompt update made things worse. Below are eight platforms engineering teams are using to solve one or both gaps, along with guidance on how to choose the right fit for your stack.弥补这种可见性差距，首先要确定你试图解决的是哪种运维问题。有些团队需要基础的执行追踪：识别哪些工具调用被触发、延迟堆积在哪里，或者为什么两个 Agent 之间的交接失败了。而另一些团队已经具备了链路可见性，但无法判断输出质量是否在下降、模型是否产生了幻觉，或者提示词更新是否让情况变得更糟。以下是工程团队用于解决其中一个或两个差距的八个平台，以及如何为你的技术栈选择合适工具的指导。

The best AI agent observability tools for production teams生产环境团队的最佳 AI Agent 可观测性工具

Every tool below does some mix of tracing what your agents did and judging whether what they did was correct. We evaluated each one against four criteria: trace and span depth across multi-agent workflows (not just single LLM calls), evaluation and quality scoring (including hallucination and bias detection), integration with the telemetry you already collect (APM, infrastructure, logs), and deployment model, including whether self-hosting or VPC deployment is available.以下每款工具都结合了追踪 Agent 行为与评估其结果正确性的功能。我们根据四个标准对它们进行了评估：多 Agent 工作流中的链路和 Span 深度（不仅仅是单个 LLM 调用）、评估和质量评分（包括幻觉和偏见检测）、与你现有的遥测数据（APM、基础设施、日志）的集成，以及部署模式（包括是否支持自托管或 VPC 部署）。

New RelicNew Relic

New Relic built its AI monitoring on top of an observability platform most engineering teams already run for APM, infrastructure, and logs. Because of this, agent traces show up alongside telemetry instead of in a separate tool.New Relic 的 AI 监控构建在大多数工程团队已用于 APM、基础设施和日志的可观测性平台之上。因此，Agent 链路会与遥测数据一同显示，而无需使用单独的工具。

Key features:核心功能：

• Automatically captures model name, token usage, tool calls, and message content for supported agent frameworks, including LangGraph, Strands, and AutoGen自动捕获支持的 Agent 框架（包括 LangGraph、Strands 和 AutoGen）的模型名称、Token 使用量、工具调用和消息内容
• Accepts OpenTelemetry data mapped to the GenAI semantic conventions, allowing custom agents built outside the supported frameworks to show up in the same traces接受映射到 GenAI 语义约定的 OpenTelemetry 数据，使支持框架之外构建的自定义 Agent 也能显示在相同的链路中
• Employs an Agents Service Map that visualizes multi-agent handoffs and call relationships in real time, with a drill-down into the underlying traces采用 Agent 服务映射（Agents Service Map），实时可视化多 Agent 交接和调用关系，并支持深入查看底层链路
• Features distributed tracing across tool calls and MCP server calls, correlated with the APM, infrastructure, and log data already in New Relic to eliminate tool-hopping during root-cause analysis具备跨工具调用和 MCP 服务器调用的分布式追踪功能，并与 New Relic 中现有的 APM、基础设施和日志数据相关联，避免在根本原因分析时频繁切换工具
• Accepts OpenTelemetry spans so teams can instrument checks like prompt injection detection within standard trace views接受 OpenTelemetry Span，以便团队在标准链路视图中对提示词注入检测等检查进行插桩

The trade-off: Framework coverage is still expanding — confirm your specific framework is on the current supported list before committing, and evaluation capabilities are lighter than dedicated platforms.权衡：框架覆盖范围仍在扩展中——在确定使用前，请确认你的特定框架是否在当前支持列表中；此外，其评估能力比专用平台稍弱。

Best for: Teams that already run New Relic (or that want one platform instead of several) and need immediate agent visibility without standing up a second tool. 适用场景：已经在使用 New Relic（或希望使用单一平台而非多个工具）且需要立即获得 Agent 可见性，而不想额外搭建一套工具的团队。

DatadogDatadog

Datadog takes the same basic approach as New Relic by extending a general observability platform to cover agent tracing, then correlating it with APM, infrastructure, and real user monitoring data.Datadog 采取了与 New Relic 相同的基本方法，通过扩展通用可观测性平台来覆盖 Agent 追踪，并将其与 APM、基础设施和真实用户监控数据相关联。

Key features:

• Traces prompts, retrieval steps, and tool calls end to end, tracking latency, token usage, retries, and errors at each step端到端追踪提示词、检索步骤和工具调用，跟踪每一步的延迟、Token 使用量、重试次数和错误
• Supports OpenAI, Anthropic, Gemini, and Bedrock models, as well as frameworks like LangChain, CrewAI, Pydantic, and Strands Agents支持 OpenAI、Anthropic、Gemini 和 Bedrock 模型，以及 LangChain、CrewAI、Pydantic 和 Strands Agents 等框架
• Features built-in and custom evaluators, dataset versioning pulled from production traces, and experiments comparing prompts and models against real traffic具备内置和自定义评估器、从生产链路提取的数据集版本控制，以及对比真实流量下提示词和模型效果的实验功能
• Offers billing per LLM span, with tool, agent, embedding, and retrieval spans included free按 LLM Span 计费，工具、Agent、嵌入和检索 Span 免费包含在内

The trade-off: Datadog's broader platform has a reputation for being expensive and hard to forecast on top of agent tracing.权衡：Datadog 的更广泛平台以昂贵且在 Agent 追踪之外难以预测成本而著称。

Best for: Teams already standardized on Datadog for APM and infrastructure that want agent tracing plus real evaluation without adding a vendor.适用场景：已经在 APM 和基础设施方面标准化使用 Datadog，且希望在不增加供应商的情况下获得 Agent 追踪和真实评估功能的团队。

LangfuseLangfuse

Langfuse functions as an open-source, framework-agnostic telemetry platform designed for teams that prioritize full data ownership. It focuses on tracing and execution monitoring first, providing a clean foundation to layer on evaluations and prompt managementLangfuse 是一个开源且与框架无关的遥测平台，专为优先考虑完整数据所有权的团队设计。它首先专注于追踪和执行监控，为后续叠加评估和提示词管理提供了坚实的基础。

Key features:

• Runs on an MIT-licensed core (with a small enterprise-edition module under separate terms) that's available as a hosted cloud service or self-hosted in your own VPC核心部分采用 MIT 许可（企业版模块遵循单独条款），既可作为托管云服务使用，也可在你的 VPC 中自托管
• Traces every LLM call, tool call, and retrieval step in a hierarchy, with cost and latency attached在层级结构中追踪每个 LLM 调用、工具调用和检索步骤，并附带成本和延迟信息
• Scores output using LLM-as-a-judge, heuristic evaluators, and human review使用“LLM 作为评判者”（LLM-as-a-judge）、启发式评估器和人工审核来对输出进行评分
• Separates prompt management from your codebase with one-click rollbacks, integrating across 100+ model providers and frameworks将提示词管理与代码库分离，支持一键回滚，并集成 100 多种模型提供商和框架

The trade-off: Self-hosting for VPC or compliance requirements means running infrastructure yourself, and Langfuse doesn't correlate with your broader APM or infrastructure telemetry.权衡：为了满足 VPC 或合规性要求而进行自托管意味着需要自行运维基础设施，且 Langfuse 无法与你更广泛的 APM 或基础设施遥测数据相关联。

Best for: Teams that want a dedicated, open source tracing and evaluation layer they can self-host, independent of whatever platform they use for the rest of their stack.适用场景：希望拥有一个可自托管的专用开源追踪和评估层，且独立于其余技术栈所用平台的团队。

LangSmithLangSmith

LangSmith is the native observability platform built by the team behind LangChain and LangGraph. Because of that shared origin, it offers the deepest, lowest-friction integration for teams already using the LangChain framework. LangSmith 是由 LangChain 和 LangGraph 背后的团队构建的原生可观测性平台。得益于这一共同起源，它为已经使用 LangChain 框架的团队提供了最深入、最顺畅的集成体验。

Key features:

• Delivers native framework support for LangChain alongside OpenTelemetry ingestion for custom setups 提供 LangChain 原生框架支持，同时支持自定义设置的 OpenTelemetry 摄取
• Tracks costs, online evaluations, tool execution, and alerting跟踪成本、在线评估、工具执行和警报
• Surfaces automatic pattern detection through trace clustering通过链路聚类自动发现模式
• Uses SmithDB, a purpose-built trace database, to deliver fast queries across millions of traces, with self-hosting options available for enterprise tiers使用专为追踪设计的数据库 SmithDB，实现对数百万条链路的快速查询，企业版提供自托管选项

The trade-off: Confirm self-hosting details with your rep before assuming it's included at your tier. Also, like other eval-first tools, it doesn't correlate with APM or infrastructure telemetry.权衡：在假设自托管包含在你的层级之前，请与销售代表确认细节。此外，与其他以评估为先的工具一样，它无法与 APM 或基础设施遥测数据相关联。

Best for: Teams building specifically on LangChain or LangGraph that want the tracing and evaluation tool built by the same team as the framework.适用场景：专门基于 LangChain 或 LangGraph 构建，且希望使用由框架原班人马打造的追踪和评估工具的团队。

Arize (Phoenix / AX)Arize (Phoenix / AX)

Arize comes from traditional ML observability, monitoring embeddings and model drift before the current wave of LLM agents, and that heritage shows in its evaluation tooling.Arize 源于传统的机器学习可观测性，在当前 LLM Agent 热潮之前就开始监控嵌入和模型漂移，这种背景在其评估工具中体现得很明显。

Key features:

• Ships as Phoenix, a source-available version under the Elastic License 2.0 (more restrictive than MIT or Apache terms), and Arize AX, the commercial platform提供 Phoenix（采用 Elastic License 2.0 的源码可用版本，比 MIT 或 Apache 条款更严格）和商业平台 Arize AX
• Uses OpenInference and OpenTelemetry semantic conventions使用 OpenInference 和 OpenTelemetry 语义约定
• Organizes three functions: Observe (tracing), Evaluate (span, trace, and session-level scoring), and Learn (testing prompt or harness changes before you ship them)组织了三个功能：Observe（追踪）、Evaluate（Span、链路和会话级评分）和 Learn（在发布前测试提示词或方案变更）
• Adds an AI agent in Arize AX that automates parts of debugging and a GenAI-optimized datastore integrating with BigQuery, Databricks, and Snowflake在 Arize AX 中增加了一个 AI Agent，用于自动化调试的部分环节，并提供与 BigQuery、Databricks 和 Snowflake 集成的 GenAI 优化数据存储

The trade-off: Phoenix's license terms mean it isn't unrestricted open source, so check whether Elastic License 2.0 works for your deployment plans. The breadth across Observe, Evaluate, and Learn also means a longer ramp-up if all you need is basic tracing.权衡：Phoenix 的许可条款意味着它并非不受限制的开源软件，请检查 Elastic License 2.0 是否符合你的部署计划。其涵盖 Observe、Evaluate 和 Learn 的广度也意味着如果你只需要基础追踪，上手门槛会更高。

Best for: Teams already using Arize for traditional ML monitoring that want the same platform extended to LLM agents or teams that want a mature evaluation framework built on open standards.适用场景：已经在使用 Arize 进行传统 ML 监控，希望将同一平台扩展到 LLM Agent 的团队，或者希望基于开放标准构建成熟评估框架的团队。

BraintrustBraintrust

Braintrust built its platform around an evaluation-first workflow, making output quality and regression testing the core focus. Rather than treating production tracing as a separate task, it connects live traces directly into test datasets to help engineering teams catch model failures before release. Braintrust 围绕“评估优先”的工作流构建平台，将输出质量和回归测试作为核心重点。它没有将生产追踪视为独立任务，而是将实时链路直接连接到测试数据集中，帮助工程团队在发布前捕获模型故障。

Key features:

• Traces production runs in real time, capturing tool execution, latency, and cost across agent workflows实时追踪生产运行，捕获 Agent 工作流中的工具执行、延迟和成本
• Establishes baseline quality criteria prior to deployment to run comparative experiments across prompts and models在部署前建立基准质量标准，以便跨提示词和模型运行对比实验
• Converts production traces into evaluation datasets with one click, catching regressions against real user failures rather than synthetic tests 一键将生产链路转换为评估数据集，针对真实用户故障而非合成测试进行回归捕获

The trade-off: Braintrust provides less depth when correlating agent behavior with your infrastructure and APM telemetry than a full-stack observability platform offers.权衡：与全栈可观测性平台相比，Braintrust 在将 Agent 行为与基础设施和 APM 遥测数据相关联方面深度不足。

Best for: Teams whose main problem is proving and improving output quality over time, especially regression-testing prompts and models against real production failures.适用场景：主要痛点在于证明和持续改进输出质量，特别是针对真实生产故障进行提示词和模型回归测试的团队。

Comet (Opik)Comet (Opik)

Comet extends its machine learning experiment tracking background into agentic workflows through Opik. It combines open-source tracing with automated prompt optimization, targeting teams that want end-to-end evaluation without relying on closed commercial suites. Comet 通过 Opik 将其机器学习实验追踪背景扩展到了 Agent 工作流。它将开源追踪与自动化提示词优化相结合，针对的是那些希望在不依赖封闭商业套件的情况下实现端到端评估的团队。

Key features:

• Traces agent behavior across development, testing, and production追踪开发、测试和生产环境中的 Agent 行为
• Scores output with LLM-as-a-judge across 30+ metrics, including answer relevance, context precision, task completion, and hallucination detection使用“LLM 作为评判者”通过 30 多项指标对输出进行评分，包括答案相关性、上下文精确度、任务完成度和幻觉检测
• Uses a Prompt Optimizer with six algorithms that tune tool calling, orchestration, and model parameters automatically使用具有六种算法的提示词优化器，自动调整工具调用、编排和模型参数
• Distributes under an Apache 2.0 open-source license with a self-hostable core, alongside a free cloud tier and an enterprise tier for larger teams 采用 Apache 2.0 开源许可分发，具有可自托管的核心，同时提供免费云层和大型团队适用的企业层

The trade-off: Comet has less name recognition specifically for agent observability than Langfuse or LangSmith, and like other eval-first tools, it lacks native correlation with APM or infrastructure telemetry.权衡：Comet 在 Agent 可观测性方面的知名度不如 Langfuse 或 LangSmith，且与其他以评估为先的工具一样，它缺乏与 APM 或基础设施遥测数据的原生关联。

Best for: Teams already using Comet for ML experiment tracking that want the same platform for LLM evaluation or teams that want genuinely open source tracing plus a built-in prompt optimizer.适用场景：已经在使用 Comet 进行 ML 实验追踪，希望将同一平台用于 LLM 评估的团队，或者希望获得真正的开源追踪外加内置提示词优化器的团队。

Confident AIConfident AI

Confident AI builds on top of DeepEval, an open-source testing framework designed to bring software unit-testing patterns to LLM outputs. It targets engineering teams that want to embed output evaluation and security checks directly into their CI/CD pipelines before code hits production.Confident AI 构建在 DeepEval 之上，这是一个旨在将软件单元测试模式引入 LLM 输出的开源测试框架。它针对的是希望在代码进入生产环境之前，将输出评估和安全检查直接嵌入 CI/CD 流水线的工程团队。

Key features:

• Adds team collaboration, dataset management, tracing, and real-time monitoring on top of local and CI testing in DeepEval在 DeepEval 的本地和 CI 测试基础上，增加了团队协作、数据集管理、追踪和实时监控功能
• Scores output for faithfulness, relevancy, and coherence, including support for G-Eval对输出的忠实度、相关性和连贯性进行评分，包括对 G-Eval 的支持
• Automatically converts production traces into eval datasets, and categorizes failure modes and edge cases自动将生产链路转换为评估数据集，并对故障模式和边缘情况进行分类
• Runs red-teaming aligned with the OWASP Top 10 for Agentic Applications, useful for stress-testing agents against prompt injection before they reach users运行符合 OWASP Agent 应用十大风险（Top 10）的红队测试，有助于在 Agent 到达用户前对其进行提示词注入压力测试

The trade-off: The framing is testing and CI-first rather than an always-on dashboard, and it's less useful if your actual gap is visibility into agent behavior rather than output quality.权衡：其定位是测试和 CI 优先，而非全天候仪表盘；如果你的实际差距在于对 Agent 行为的可见性而非输出质量，那么它的用途有限。

Best for: Teams that need to catch hallucinations, bias, and other failure modes before code ships, with the option to run the same checks continuously once agents are live.适用场景：需要在代码发布前捕获幻觉、偏见和其他故障模式，并有能力在 Agent 上线后持续运行相同检查的团队。

What to look for in an AI agent observability tool选择 AI Agent 可观测性工具时应关注什么

Choosing between these tools comes down to how they solve real production problems. Here's why those problems matter and how to test for them.在这些工具之间做出选择，归根结底取决于它们如何解决实际的生产问题。以下是这些问题的重要性以及测试方法。

Multi-agent trace and hand-off visibility多 Agent 链路和交接可见性

Multi-agent systems create a failure mode single-call tracing wasn't built for. When two or three agents pass a task back and forth and call tools or APIs along the way, the number of possible paths through the system multiplies fast. 多 Agent 系统产生的故障模式是单次调用追踪无法应对的。当两个或三个 Agent 来回传递任务并调用工具或 API 时，系统内可能的路径数量会迅速倍增。

A trace has to capture that whole chain, not just isolated spans. Test this by tracing a real multi-agent workflow end to end and checking whether you can find where a handoff broke down in a couple of clicks, not by digging through logs.链路必须捕获整个链条，而不仅仅是孤立的 Span。测试方法是追踪一个真实的端到端多 Agent 工作流，并检查你是否能在几次点击内找到交接失败的位置，而不是翻阅日志。

Evaluation and quality scoring depth评估和质量评分深度

Tracing tells you what an agent did. It doesn't tell you whether the answer was right. Because agents are non-deterministic, the same input can take a different path and land on a different, possibly wrong, answer on two separate runs. 追踪能告诉你 Agent 做了什么，但不能告诉你答案是否正确。由于 Agent 是非确定性的，相同的输入在两次不同的运行中可能会走不同的路径，并得出不同的、可能是错误的答案。

Testing before launch isn't enough; you need ongoing evaluation of live traffic, and LLM-as-a-judge is what makes that practical at scale, but only when it's set up well. Galileo's 2026 State of AI Evaluation report found that untuned LLM judges agree with human experts only 66-68% of the time, a gap that closes significantly with techniques like multi-judge consensus, calibration, and fine-tuning. That's the real case for a dedicated evaluation layer over a DIY judge prompt: calibrated automated scoring paired with human review is what actually catches hallucinations, bias, and other regressions before a bad prompt update reaches most users.发布前的测试是不够的；你需要对实时流量进行持续评估，“LLM 作为评判者”使得大规模评估变得可行，但前提是配置得当。Galileo 的《2026 AI 评估状况报告》发现，未经调优的 LLM 评判者与人类专家的共识率仅为 66-68%，而通过多评判者共识、校准和微调等技术，这一差距可以显著缩小。这就是选择专用评估层而非 DIY 评判提示词的真正理由：校准后的自动化评分配合人工审核，才是真正能在糟糕的提示词更新触达大多数用户之前，捕获幻觉、偏见和其他回归问题的手段。

Integration with your existing stack与现有技术栈的集成

Agent tracing that lives in its own disconnected tool only tells half the story. If an agent is slow, is that latency coming from the model, a tool call to an internal API, a vector database lookup, or the infrastructure it runs on? Without that correlation, root-cause analysis turns into manually cross-referencing timestamps across tools during an incident. 孤立于其他工具的 Agent 追踪只能揭示一半事实。如果 Agent 运行缓慢，延迟是来自模型、内部 API 调用、向量数据库查询，还是它运行的基础设施？没有这种关联，根本原因分析就会变成在事故期间手动交叉比对不同工具的时间戳。

Deployment model matters here too: if agent and prompt data must stay inside a VPC for compliance reasons, confirm the tool supports self-hosting before you evaluate anything else about it. Fragmented tooling is exactly what operational leaders say they want to reduce, with PagerDuty’s State of AI-First Operations survey showing that 51% of respondents feel consolidating multiple tools into a single platform improves operational resilience.部署模式在这里也很重要：如果出于合规性原因，Agent 和提示词数据必须保留在 VPC 内，请在评估其他功能之前先确认工具是否支持自托管。碎片化的工具正是运维领导者想要减少的，PagerDuty 的《AI 优先运维状况调查》显示，51% 的受访者认为将多个工具整合到一个平台能提高运维韧性。

Extending your stack vs. adopting a dedicated eval platform扩展现有技术栈 vs. 采用专用评估平台

Teams that already run full-stack observability and just need to see what their agents are doing are usually better served by extending that platform rather than adding a disconnected tool. Teams doing heavy prompt and output quality evaluation at scale, such as testing against edge cases and running red-team checks for prompt injection, often benefit from an AI-native eval platform alongside their existing observability tool and whatever guardrails they've built.对于已经运行全栈可观测性且只需了解 Agent 行为的团队，扩展现有平台通常比增加一个孤立工具更好。而对于大规模进行深度提示词和输出质量评估的团队（例如针对边缘情况进行测试和运行提示词注入的红队检查），在现有可观测性工具和已建防护措施的基础上，引入 AI 原生评估平台通常更有利。

New Relic's approach fits the first case: agent tracing correlated with the APM, infrastructure, and log data your team is already collecting, added to a platform you already run. It isn't a replacement for a dedicated evaluation platform, but for teams whose problem is "we can't see what our agents are doing," it closes that gap without a new system to deploy and pay for separately. One team used this approach to take an AI travel agent from a working demo to a production-ready service, setting SLAs and alerts once the agent handled real traffic.New Relic 的方法适用于前者：将 Agent 追踪与团队已收集的 APM、基础设施和日志数据相关联，并添加到现有平台中。它不是专用评估平台的替代品，但对于那些痛点在于“我们看不见 Agent 在做什么”的团队，它无需部署和付费购买新系统即可弥补这一差距。某团队曾利用此方法将一个 AI 旅行 Agent 从演示版本转变为生产级服务，并在 Agent 处理真实流量后设置了 SLA 和警报。

Matching the tool to the gap you actually have将工具与你实际的差距相匹配

Before comparing vendors feature by feature, answer one question honestly: What can't you do today?在逐项比较供应商功能之前，请诚实地回答一个问题：今天你做不到什么？

If nobody on your team can explain what an agent did during an incident, that's a visibility gap. The fix is extending your existing observability platform to cover agents as one more telemetry source next to your metrics and logs, not standing up a new system to babysit. If you can already see every trace but still can't tell whether the agent's answers are getting worse over time, that's an evaluation gap, and a dedicated AI-native platform built around scoring, datasets, and online evaluations will get you there faster. Most teams end up needing some of both. Start with whichever gap is costing you the most right now.如果团队中没人能解释事故期间 Agent 做了什么，那就是可见性差距。解决方法是扩展现有的可观测性平台，将 Agent 作为与指标和日志并列的遥测数据源，而不是搭建一套新系统来监管。如果你已经能看到每条链路，但仍无法判断 Agent 的答案是否在随时间变差，那就是评估差距，此时围绕评分、数据集和在线评估构建的 AI 原生平台会让你更快达成目标。大多数团队最终都需要两者结合。从目前对你成本影响最大的那个差距开始着手。

New Relic extends the observability platform many engineering teams already run to cover LangChain- and LangGraph-based agents, correlating traces with the APM, infrastructure, and log data you already collect. See how New Relic's AI monitoring works against your own agents, or request a demo to walk through it with your own stack.New Relic 将许多工程团队已经在运行的可观测性平台扩展到覆盖基于 LangChain 和 LangGraph 的 Agent，并将链路与你已收集的 APM、基础设施和日志数据相关联。查看 New Relic 的 AI 监控如何针对你的 Agent 工作，或申请演示以了解它如何与你的技术栈结合。