TraceLLM 在追踪中捕获了什么？

它可以捕获会话、跨度、生命周期事件、提供商/模型元数据、延迟、令牌使用情况和错误。启用后可进行提示/输出捕获，捕获行为可通过项目策略进行控制。

如何将 TraceLLM 添加到现有应用程序？

TraceLLM 提供了一种嵌入式 SDK 方法，因此您可以在不改变模型请求运行位置的情况下封装真实的 AI 调用。官方网站强调通过 SDK 包 @use-tracellm/sdk-node 从 Node 开始。

TraceLLM 可以追踪哪些类型的应用程序？

TraceLLM 旨在追踪聊天机器人、多步骤代理工作流、RAG 服务、内部工具、模型路由器和自定义提供商封装器，包括跨多个提供商的设置。

TraceLLM 如何帮助调试错误或糟糕的模型响应？

TraceLLM 为每个 AI 工作流提供单一时间线：您可以打开用户会话，检查模型跨度（提供商、模型、延迟、令牌使用情况、状态），读取围绕工具/检索/应用程序逻辑捕获的事件，并跟踪仍然附加到同一追踪的任何错误。

我可以控制 TraceLLM 存储哪些数据（例如，提示）并应用编辑/采样吗？

是的。TraceLLM 支持项目级控制，例如打开/关闭内容捕获、保留元数据、启用编辑和配置采样（例如，采样一定比例的追踪）。

TraceLLM 支持将追踪导出到其他可观测性工具吗？

是的。TraceLLM 支持 OpenTelemetry (OTLP) 导出，并且可以将追踪转发到 SigNoz，从而允许您在 TraceLLM 中保留产品级追踪，同时将相同的工作流导出到 SigNoz。

TraceLLM 中如何管理项目和访问？

TraceLLM 使用项目 API 密钥。每个项目都会获得一个密钥，该密钥包含 SDK 行为、捕获策略和所有权。

TraceLLM

WebsiteFreemiumAI DevOps Assistant

TraceLLM 是一个本地优先的 LLM 可观测性平台，它跨 AI 工作流跟踪会话、跨度、提示/输出（可选）、令牌、延迟和错误，并支持策略控制和 OpenTelemetry (OTLP) 导出。

访问网站

推广此工具

https://tracellm.in/?ref=producthunt&utm_source=aipure

概述
替代方案

产品信息

更新于：2026年08月07日

什么是 TraceLLM

TraceLLM 是一款用于生产 LLM 应用程序的可观测性和调试产品，它将模型调用和周围的应用程序活动整合到单个可查询的跟踪中。它专为现代 AI 系统（聊天机器人、代理工作流和 RAG 服务）而设计，在这些系统中，单个用户请求可以触发多个模型调用、工具调用和中间步骤，而这些在事后很难检查。TraceLLM 提供“每个 AI 工作流一个时间线”的体验，捕获关键操作信号（延迟、令牌使用、错误、元数据），并在启用时捕获提示和模型输出，以便团队能够准确了解问题运行期间发生的情况。

TraceLLM 的主要功能

TraceLLM 是一款 LLM 可观测性与追踪产品，它将端到端 AI 工作流的执行捕获为单一的、可查询的时间线——涵盖会话、跨度、生命周期事件、令牌使用、延迟、提供商/模型调用和错误——具有可配置的捕获/修订策略，并可选择将 OpenTelemetry (OTLP) 导出到现有监控堆栈（例如 SigNoz）。它旨在通过保留调查错误答案、性能退化、令牌激增以及跨提供商和框架的故障所需的上下文，使多步骤 LLM 应用程序（聊天机器人、代理、RAG、使用工具的工作流、路由器/网关）可调试。

会话 + 跨度时间线（“一个追踪，一个故事”）: 将每个 AI 工作流记录为包含会话、跨度和事件的统一追踪，因此您可以准确地看到发生了什么——从请求开始到模型完成——而无需拼接供应商仪表板和分散的日志。

使用情况、延迟和错误可观测性: 捕获令牌计数、时间/延迟、请求状态和异常，并将其附加到同一追踪中，以快速诊断生产中的瓶颈、成本激增和故障模式。

带策略控制的提示/输出捕获: 支持可选的提示和模型输出捕获，由项目级控制（捕获开/关、仅元数据模式、修订、采样）管理，以平衡调试价值与隐私/合规性需求。

嵌入式 SDK 检测 (Node): 提供了一个轻量级 SDK，它封装了实际的模型调用，而无需更改请求运行的位置，支持常见的 LLM 应用程序模式，例如代理、RAG、工具和网关。

与提供商和框架无关的工作流追踪: 旨在追踪异构堆栈和模型提供商（例如，提及的 OpenAI/Claude/Gemini 模式），即使团队使用多个模型和运行时，也能实现统一的操作视图。

OpenTelemetry (OTLP) 导出管道: 通过 OTLP（例如 SigNoz）将相同的产品级追踪导出到外部可观测性系统，让团队能够将 LLM 工作流遥测集成到现有的监控和警报管道中。

TraceLLM 的使用场景

客户支持聊天机器人调试: 当用户报告错误或不安全的答案时，工程师可以打开确切的会话，检查模型跨度（提供商/模型/令牌/延迟），并审查周围的事件以查明基础/检索/工具问题。

代理工作流可靠性（工具 + 多步骤规划）: 跟踪模型调用链和工具调用，以便团队可以识别代理在哪里循环、选择了错误的工具、悄无声息地失败，或者尽管延迟/令牌“健康”却产生了自信的错误响应。

RAG 质量和基础调查: 通过将检索/工具事件与最终响应关联起来，帮助诊断检索-答案失败，从而更容易查看是否获取了正确的上下文以及它如何影响输出。

生产 AI 的成本和性能优化: 使用每个跨度的令牌使用量和延迟来查找昂贵的提示、回归和热点，从而在成本或尾部延迟影响用户之前实现有针对性的提示/路由/模型更改。

多提供商模型路由和 A/B 操作: 在使用多个提供商/模型的环境中，TraceLLM 提供了跨路由行为的单一视图，从而更容易比较跨部署的可靠性、成本和延迟。

优点

跨模型调用、应用程序事件、使用情况和错误的统一追踪时间线——减少了关联不同日志和供应商仪表板所需的时间。

策略驱动的捕获（采样/修订/仅元数据）加上 OTLP 导出支持隐私需求和与现有可观测性堆栈的集成。

专为实际的 LLM 应用程序模式（代理、RAG、工具、网关）和多提供商设置而设计。

缺点

如果策略配置不当，捕获提示/输出可能会引入隐私/合规风险；需要仔细的修订和采样。

所示的 SDK 覆盖范围主要在提供的来源中是 Node；其他运行时的团队可能需要额外的支持或自定义检测。

可观测性增加了操作开销（检测、存储和审查工作流），尤其是在高追踪量时。

如何使用 TraceLLM

1) 选择您指的是哪个“TraceLLM”（可观测性与研究框架）: “TraceLLM”这个名称在源中被多个项目使用：(A) TraceLLM 可观测性产品 (tracellm.in)，用于跟踪提示/跨度/令牌/错误并通过 OTLP 导出；(B) 基于 MCP 服务器的日志记录器，公开 log_action/get_logs/get_summary 等工具；(C) 名为 TraceLLM 的研究代码库（例如，微服务跟踪生成；需求可追溯性）。以下步骤侧重于 TraceLLM 可观测性产品，因为它提供了最终用户“如何使用”文档和源中的 SDK 片段。

2) 创建 TraceLLM 项目并获取 API 密钥: 在 TraceLLM Web 应用程序（从 tracellm.in/app 链接）中，创建一个项目。复制项目 API 密钥（显示为 trllm_live_••••••••••••••）。该密钥控制所有权以及 SDK 行为，例如捕获策略、修订和采样。

3) 安装 Node SDK: 按照网站上的说明将 SDK 添加到您的 Node 项目中：`pnpm add @use-tracellm/sdk-node`。

4) 使用 TraceLLM 跨度包装实际模型调用（即插即用跟踪）: 使用 SDK 在实际提供商调用周围创建跨度，而无需更改请求运行的位置。网站上的示例模式：在执行 LLM 请求的代码周围使用 `trace.span({ provider: "openai", model: "gpt-4.1-mini" })`。这将捕获一个包含跨度、生命周期事件、延迟和令牌使用（当 OpenAI 兼容响应可用时）的单个工作流记录。

5) 捕获完整的工作流上下文（会话、跨度、事件、错误、令牌、元数据）: 组织跟踪，使一个用户工作流成为一个调试记录：使用会话名称（例如，chatbot.request），然后记录模型跨度（例如，openai.chat.complete），并添加生命周期事件（provider.request.started、provider.response、工具/检索事件）。确保错误记录在同一跟踪上，以便故障始终附加到会话时间线。

6) 在执行期间添加自定义属性和事件（可选）: 如果您的 SDK 支持活动跨度访问（如源中所示），请添加运行时属性和事件：获取活动跨度，设置 `custom.metric` 等属性，并添加 `cache_hit` 等事件，其中包含结构化字段（例如，`{ key: "user_context" }`）。这有助于将应用程序级信号与模型行为相关联。

7) 使用嵌套跨度跟踪多步工作流（链）: 对于代理/RAG/工具管道，创建一个父工作流跨度（一个“链”），并为 LLM 调用、检索和工具嵌套子跨度。源显示了一种模式，其中嵌套跨度自动成为父跨度的子跨度，从而为整个工作流生成一个连贯的时间线。

8) 配置捕获策略、修订和采样: 在 TraceLLM UI 中（或通过与 API 密钥绑定的项目设置），配置要捕获的内容：内容捕获开/关、元数据开/关、修订开和采样（示例显示：70%）。这控制是否存储提示/输出以及如何处理敏感数据。

9) 在跟踪浏览器中查看跟踪（会话和实时跟踪）: 打开 TraceLLM 应用程序，并使用会话/实时跟踪通过会话名称、状态（正常/错误）或时间戳查找工作流。检查模型跨度以查看提供商/模型、延迟、令牌使用和请求状态。查看事件时间线和任何附加错误。

10) 使用 TraceLLM 调试报告的错误答案（推荐工作流）: 遵循网站上描述的调查路径：(1) 打开用户会话；(2) 检查模型跨度的延迟/令牌/状态；(3) 阅读捕获的工具/检索/提供商调用周围的事件；(4) 跟踪故障——错误始终附加消息/类型/堆栈/元数据。

11) 通过 OpenTelemetry (OTLP) 将跟踪导出到 SigNoz（可选）: 启用 OTLP 导出，以便可以将相同的工作流跟踪转发到 SigNoz 等 OTLP 目的地。网站描述了一个导出管道：TraceLLM API → OTLP Collector → SigNoz，允许您将产品级跟踪保留在 TraceLLM 中，同时也将它们发送到您的可观测性堆栈。

12) (替代) 如果您指的是 MCP 服务器“Tracellm”日志记录器，请运行它并调用其工具: 一些源描述了一个纯 MCP 服务器，它公开了三个工具：`log_action`、`get_logs` 和 `get_summary`，并带有 SSE-over-HTTP 传输（端口 8001）。在这种设置中，您的应用程序/代理在有意义的交互（用户消息、LLM 响应、工具调用、错误）之后调用 `log_action`。日志记录旨在非阻塞：如果服务器不可用，主要的 LLM 流将继续而不中断。

13) (替代) 如果您指的是研究 TraceLLM 存储库，请设置环境并运行预处理: 其他源描述了研究代码库（例如，微服务调用图跟踪生成），其设置如下：创建一个 conda 环境 (python=3.8)，安装 poetry，运行 `poetry install`，然后在 `trace_gen` 下安装其他要求。它们还描述了用于将跟踪转换为调用图并计算统计数据（例如，`trace_to_cg_stats.py`、`merge_cg_stats.py`）以及将调用图转换为文本表示（并适当设置 task_type）的预处理脚本。