LLM Observability

Agent 会引入非确定性——相同的输入可能产生不同的输出。当 Agent 做出次优行为时，即便是仅因prompt模糊导致的问题，用户也会将其标记为“bug”。调试这类问题需要追踪复杂的多步骤工作流，但标准日志工具（如CloudWatch、Lambda日志）的导航操作十分繁琐。工程师需要能便捷获取工作流执行细节以快速开展调试，否则Agent将无法得到推广应用。

集成可提供Agent工作流span级追踪（span-level tracing）的LLM可观测性平台（如Datadog LLM Observability、LangSmith等）。无需在原始日志中费力排查，即可通过可视化UI查看Agent执行的每一个步骤。

核心功能：

• Span可视化：查看每一次LLM调用、工具使用以及中间结果
• 工作流链路关联：从用户输入出发，追踪覆盖所有子步骤直至最终输出的完整路径
• 仪表盘聚合：汇总成本、延迟、成功率等关键指标
• 便捷调试：非技术人员无需访问日志即可开展调试工作

相较于标准日志方案的演进历程：

1. 打印至标准输出（stdout） → 日志被捕获到Lambda日志中（访问难度高）
2. 推送至Slack频道 → 发送运行摘要+AWS日志链接（体验有所改善，但仍需手动排查日志）
3. LLM可观测性平台 → 可视化span追踪，导航操作便捷

graph LR
    A[Agent运行实例] --> B[可观测性SDK]
    B --> C[Span：LLM调用1]
    B --> D[Span：工具调用]
    B --> E[Span：LLM调用2]
    C --> F[追踪UI]
    D --> F
    E --> F
    F --> G[调试视图]

    style F fill:#e8f5e9,stroke:#388e3c,stroke-width:2px

集成步骤：

1. 选择可观测性平台：如 Datadog LLM Observability、LangSmith、Arize 等
2. 安装SDK：将其添加至你的Agent代码中（通常仅需1-2行代码）
3. 配置追踪：为工作流、用户、环境打标签
4. 访问控制：向更广泛的团队开放访问权限（不局限于工程师群体）

Datadog 示例代码：

from ddtrace import tracer

# 自动追踪LLM调用
@tracer.wrap("agent_workflow")
def run_agent(query):
    result = agent.run(query)
    # 每次LLM调用、工具使用都会生成一个追踪跨度（span）
    return result

最佳实践：

• 全面打标签：覆盖工作流名称、用户ID、环境（生产/预发布）
• 关联仪表盘：确保可观测性UI能从聊天界面便捷访问
• 开放共享访问：不要局限于工程部门；工作流创建者也需要可见性
• 监控聚合指标：长期跟踪成功率、延迟时长、成本数据

优势：

• 快速调试：以可视化方式梳理复杂工作流
• 易上手：非技术人员无需日志权限即可开展调试工作
• 聚合指标：查看多轮运行中的规律模式
• Span级细节：深入到执行流程的任意步骤

劣势：

• 供应商依赖：受限于特定可观测性平台
• 成本高昂：企业级可观测性工具通常定价不菲
• 性能开销：会增加延迟（通常影响极小）
• 访问控制难题：难以平衡可见性与安全性

不适用场景：

• 简单的确定性工具（无Agent行为）
• 单步骤操作（标准日志已足够满足需求）
• 预算有限，无法承担可观测性相关开支