如何像new relic一样调试llm agent

现状

随着LLM在日常生产中的使用，越来越多的agent产品也应运而生。agent在使用的过程也会有一些性能问题，在用户问了一个问题的时候，一个agent在产生结果的时候会经过很过个pipeline。这些pipeline有的会调用tavily api来获取最新数据，每次获取数据的时候同时还会调用LLM接口整理数据，最后调用类似slack这种内部沟通工具的开放api。这个pipeline不算太长，如下图所示。
每个节点都会耗费一定的时间，就像微服务调用链一样需要找到链路中耗时较长的环节。我们知道在微服务中我们可以使用new relic或者Zipkin一样的工具来可视化每个服务调用的耗时。对于LLM的agent中的pipeline也需要对调用进行监控，所以一些LLM的observation的工具也随之诞生了。

LLM tracing框架

tracing框架都有一个通性，都需要对代码做侵入性操作。目前很多的LLM框架都是将python设置为基础编程语言，进而其中修饰器特性将用来包装一个函数的执行的过程，这样就可以做到对一个函数的执行效率的监控。主流的LLM tracing框架可以按照类型分为：OTEL、PROXY、SDK以及SaaS四类，具体不同的类型工具如下表格所示：

集成方式 / 部署风格	工具	典型集成方式	特点 / 适用场景
OpenTelemetry 路线（OTEL / OTLP）	Langfuse	内置 OTEL exporter，可通过 OTLP 或 SDK 自动生成 trace	端到端链路追踪，支持 LLM、Agent、RAG 步骤；可 self-host 或 hosted
	Arize Phoenix	OTEL instrumentation / Python SDK	与现有 OTEL stack 兼容（Jaeger、Tempo）；可捕获模型调用与链路
	Traceloop OpenLLMetry	OTEL instrumentation / Python 或 JS SDK	标准化 tracing，可发送 span 到任意 OTEL backend
代理 (Proxy) 模式	Helicone	改写 LLM API Base URL → 代理到 Helicone	零代码接入；快速获取请求日志、token、延迟；链路粒度有限
SDK / Library 包装	TruLens	Python SDK / wrap LLM Pipeline	聚焦输出质量评估（coherence、groundedness）；无法自动追踪全链路
	Galileo	Python SDK + API	生产监控 + Guardrail + CI 测试；可以记录 prompt / output / token
	W&B Weave	Python SDK / decorator	追踪函数调用 / LLM 输出 / prompt 版本管理；偏实验管理
	Langfuse	Python/JS SDK
平台 / 服务 (PaaS / SaaS + 本地)	LangSmith	LangChain 官方平台；启用 tracing 即可自动记录	专为 LangChain 用户设计，全链路追踪 + prompt/version/eval
	Langfuse	SDK / self-host 或 cloud	同时支持 SDK 与 OTEL；可视化链路、prompt、token；可用于生产环境

小Demo-Langfuse

为什么选用langfuse？

agent的框架很多，但是像langsmith这类langchain原生的ai debugging工具，在市场上还是不多的。如果想找到一个类似与newrelic这类能够监控agent全链路调用链的OTEL平台工具。目前是看了一下langfuse官网介绍，比较容易上手、提供私有部署和PaaS以及监控的指标较多。综上所诉，我采用了langfuse作为demo平台。到后续如果要做生产级别的ai debugging，我会对市面主流的框架做一次全面的spike。来自官网的Langfuse

Demo

langfuse将会被使用来作为Demo的LLM trace debug的工具，langfuse是一个遵循OTEL准则的一个AI agent debugging工具，对于python他提供了三种集成方式，手动、装饰器以及上下文管理器with语法。下面将仔细的说明一下这三种方式的实现。当然在使用之前，可以通过官网提供的小Demo来验证如何使用

pre-requirement

python，pip install langfuse
docker
docker compose，下载docker-compose.yml文件通过wget https://github.com/langfuse/langfuse/blob/main/docker-compose.yml，运行docker-compose up，在浏览器中访问http:\\localhost:3000
使用官网提供的验证步骤
三种方式，对于手动和上下文管理器就不做过多的展开，有兴趣可以看一下官方文档

装饰器`observe()`

手动方式就是，定义手动的定义一个span的开始和结束，这里要注意的是，span开始以后，一定要定义结束点。所以这就是上下文管理器出现的意义，让开发者着重关心业务开发。那这里主要是想简单介绍一下observe的用法，装饰器会将所有的函数包裹然后做一些magic的事情比如我写了一个最简单的agent

@observe()
def call_llm():
 xxxx
@observe()
def call_tool():
 xxxx

@observe()
def run_react_agent():
	call_llm()
	if need to call tool
		call_tool()

if __name__ == "__main__":
	run_react_agent()

这样经过调用之后，打开Langfuse就可以看到具体的每个函数的出参入参以及调用时间，如下图所示，可以看到每个函数调用次数以及过程中的调用时间
Langfuse除了上述基础的tracing功能，还有Evaluation和Prompt Management，这些会在后续的spike中深入研究。

总结

随着ai类的相关应用产品的爆发式的增长，对应的周边的配套设施也在逐渐完善。在AI当时刚刚出来的时候，还没有agent这些概念的技术，随着相关技术的复杂度越来越大，相关的性能问题也就会亟待解决，所以类似于Langfuse这样的agent debugging工具也就随之而生。开发的周边工具让agent的开发工程化，规范化以及常规化。

Reference

Top 9 LLM Observability Tools in 2025