返回博客2026年1月20日

Agent 开发的核心挑战：如何从海量 Traces 中发现问题

LangChainLangSmithAgent可观测性生产环境

LangChain 创始人 Harrison Chase 今天发布了一篇文章，讨论 Agent 开发中的一个问题：当你的 Agent 在生产环境中每天产生成千上万条 Traces 时，你该如何理解它到底在做什么？

原文链接：From Traces to Insights: Understanding Agent Behavior at Scale

现状

Harrison 在文章开头引用了一段对话：

"可观测性是最简单的部分。真正困难的是分析和理解你观察到的东西。我接触过的团队每天记录超过 10 万条 traces。他们用这些 traces 做什么？什么都没做。因为在任何人类尺度上，阅读和总结 10 万条 traces 是不可能的。"

— Dev Shah

这种情况并不少见。很多团队部署了 Tracing，收集了数据，但没有进一步分析。

Agent 为什么不同于传统软件

Harrison 指出了 Agent 与传统软件的三个本质区别：

graph TB
    subgraph "传统软件"
        A1[确定性] --> A2[相同输入 = 相同输出]
        B1[鲁棒性] --> B2[小改动 ≠ 大变化]
        C1[有界输入] --> C2[UI 限制了用户能做的事]
    end

    subgraph "Agent"
        D1[非确定性] --> D2[相同输入 ≠ 相同输出]
        E1[Prompt 敏感性] --> E2[小改动 = 大变化]
        F1[无界输入] --> F2[自然语言，用户可以问任何事]
    end

1. 非确定性（Non-determinism）

传统软件运行多次，结果相同。Agent 不是这样。每次调用 LLM 都可能产生不同结果。当 Agent 连续调用上百次 LLM 时，同样的输入很可能走出完全不同的路径。

2. Prompt 敏感性（Prompt Sensitivity）

传统软件对输入的小变化具有鲁棒性。LLM 有一个特性叫 Prompt 敏感性—Prompt 空间中的微小变化可能导致输出的巨大变化。

3. 无界输入空间（Unbounded Input Space）

传统软件通过 UI 结构化用户输入，输入空间天然是有界的。Agent 接受自然语言，这是无界的—用户可以输入任何东西。

核心洞察：你无法在上线前预测 Agent 的行为

这三个特性叠加在一起，导致了一个根本性的问题：传统软件开发和 Agent 开发的迭代模式完全不同。

flowchart LR
    subgraph "传统软件开发"
        S1[写代码] --> S2[写测试] --> S3[上线] --> S4[监控指标]
        S2 -.->|测试覆盖大部分场景| S3
    end

    subgraph "Agent 开发"
        A1[写 Prompt] --> A2[写 Evals] --> A3[上线] --> A4[发现真正的问题]
        A2 -.->|只能覆盖已知场景| A3
        A4 -->|迭代| A1
    end

传统软件：确定性 + 鲁棒性 + 有界输入 = 你可以在上线前通过测试确保行为符合预期。上线后的产品分析主要是观察用户行为，但这被 UI 所限制。

Agent：非确定性 + Prompt 敏感性 + 无界输入 = 你不知道 Agent 在生产环境中会做什么，直到它真的上线。自然语言接口意味着有更多用户意图需要捕获和分析。

💡 构建 Agent 时，你需要在生产数据上迭代的程度远超传统软件。

Harrison 强调了两点：

  1. 你需要迭代 Agent 的失败模式：传统软件通过测试在上线前捕获正确性问题，可能有少数边缘情况漏网。Agent 正好相反—大多数失败是在生产环境中才暴露的。

  2. 你需要迭代用户实际如何使用 Agent：传统软件中，用户只能按你允许的方式使用产品。Agent 的自然语言接口意味着用户可以用更多方式使用它。

传统产品分析为什么不够用

传统软件产生大量事件（点击、页面浏览、会话）。产品分析工具（Mixpanel、Amplitude 等）通过以下方式解决"数据太多"的问题：

  • 将离散事件聚合成指标
  • 构建漏斗和用户群组
  • A/B 测试

Agent 也可以（也应该）这样做。Harrison 发现大多数生产环境中的团队会追踪：

  • 终端用户反馈
  • 延迟
  • 工具调用

但这些指标只能告诉你"发生了什么"，不能告诉你"为什么"。

要理解为什么这些指标在变化，你需要分析 Traces 本身。

graph TB
    subgraph "传统产品分析"
        M1[离散事件] --> M2[聚合指标]
        M2 --> M3[漏斗/群组/A/B]
        M3 --> M4[发现 WHAT]
    end

    subgraph "Agent 分析需求"
        A1[非结构化对话] --> A2[模式发现]
        A2 --> A3[聚类分析]
        A3 --> A4[发现 WHY]
    end

    M4 -.->|不够| A4

那有没有更好的方法？很多团队会想到用 Online Evals。

Online Evals 的局限

Online Evals 对已知问题有帮助。你可以运行评估器来给 Traces 打分—用户挫败感、话题标签、成功标准。

但 Online Evals 要求你预先知道要找什么。

那探索性问题呢？

  • "用户实际上是怎么使用我的 Agent 的？"
  • "存在哪些失败模式？"

你无法为尚未发现的模式编写评估器。

Agent 分析应该是什么样的

Harrison 提出，真正的 Agent 分析工具需要：

  1. 分析非结构化对话，而不是离散事件
  2. 发现你不知道要找的模式
  3. 大规模浮现聚类

这正是 LangSmith Insights Agent 要解决的问题。

LangSmith Insights Agent：用聚类发现模式

LangSmith Insights Agent 使用聚类自动发现 Traces 中的模式。它不需要你预先定义要找什么，而是分析成千上万的对话，浮现出重要的聚类—使用模式、错误模式，或任何你指定的维度。

flowchart TB
    subgraph "输入"
        T[海量 Traces<br/>10万+/天]
    end

    subgraph "Insights Agent 处理"
        C1[一级聚类<br/>顶层模式]
        C2[二级聚类<br/>详细分组]
        C3[具体 Runs<br/>单个案例]
        C1 --> C2 --> C3
    end

    subgraph "输出"
        R[分析报告<br/>可逐层下钻]
    end

    T --> C1
    C3 --> R

两种最常见的分析场景

Harrison 提到团队最常问的两个问题：

问题目的
用户是怎么使用我的 Agent 的？发现使用模式
我的 Agent 可能在哪些方面失败？发现失败模式

LangSmith 为这两种场景提供了预设 Prompt，但你也可以指定任意 Prompt—因为每个 Agent 都不同，你可能关心合规性、语气、准确性或特定领域的失败。

与定量信号结合

有时你只想对特定子集的 Runs 运行 Insights Agent。这让你可以将 Insights Agent 与 Online Evals 或传统产品分析结合使用。

例如：你可能只想调查收到负面用户反馈（如 👎）的 Runs。

flowchart LR
    A[所有 Traces] --> B{用户反馈}
    B -->|👎 负面| C[Insights Agent]
    B -->|👍 正面| D[暂不分析]
    C --> E[发现负面反馈<br/>背后的模式]

这样就把定量信号（👎）和定性分析（这些 👎 背后存在什么模式）结合起来了。

动态过滤

你甚至可以按尚不存在的属性过滤。

例如："为什么用户感到沮丧？"

LangSmith Insights Agent 可以即时计算"用户感到沮丧"，然后基于它进行过滤和聚类。

聚合属性发现异常

当产生聚类时，系统会聚合这些分组中与 Traces 相关的属性，让你快速发现异常聚类。你还可以指定即时计算的属性（然后也包含在聚合统计中）。

发现你不知道要追踪的模式。

核心方法论总结

把上面的内容整合起来，Agent 可观测性可以分为三个层次：

graph TB
    subgraph "Agent 可观测性金字塔"
        L1[基础指标<br/>延迟/错误率/反馈]
        L2[Online Evals<br/>已知问题检测]
        L3[Insights Agent<br/>未知模式发现]
        L1 --> L2 --> L3
    end

    subgraph "适用场景"
        S1[监控健康状态]
        S2[检测预定义问题]
        S3[探索性分析]
    end

    L1 --- S1
    L2 --- S2
    L3 --- S3
层级工具回答的问题局限
基础指标Dashboards发生了什么？不知道为什么
Online EvalsLLM-as-Judge预定义的问题存在吗？只能检测已知问题
Insights Agent聚类分析存在什么模式？为什么？—

写在最后

Harrison 的这篇文章讨论了一个很多团队面临的问题：

Agent 产生的是非结构化的 Traces，传统指标只能告诉你有事发生，但不能告诉你是什么或为什么。手动审查无法扩展。

当你的 Agent 上线后，你需要的不只是可观测性，而是可理解性。

Harrison 在文章开头的引用点出了一个普遍现象：很多团队在收集 Traces，但能从中获得洞察的不多。LangSmith Insights Agent 是 LangChain 针对这个问题给出的解决方案。

参考链接

往期回顾

准备开始了吗？

先简单说明目标，我会给出最合适的沟通方式。

预约 30 分钟邮件联系