Agent 监控：先看清轨迹，再谈自动定位

很多关于 Agent 监控的文章，开头就会讲：

• •自动告警聚合
• •自动根因定位
• •自动故障传播分析
• •自动预测风险

这些能力当然有价值，但它们都建立在一个更基础的前提上：

你得先看得见 Agent 到底做了什么。

如果连一条请求里：

• •进来了什么输入
• •模型做了哪些决策
• •调了哪些工具
• •哪一步最慢
• •哪一步失败

都看不清，那“智能监控”很容易退化成新的猜谜游戏。

所以对 Agent 系统来说，监控的起点不是“分析”，而是 observability。

传统服务监控很依赖：

• •QPS
• •延迟
• •错误率
• •资源使用

这些当然仍然重要，但对 Agent 系统来说还不够。因为同样一个“请求失败”，可能对应完全不同的问题：

• •模型选错了工具
• •工具参数格式不对
• •外部 API 超时
• •轨迹步数失控
• •结果其实成功了，但最后总结答错了

所以 LangChain / LangGraph 当前官方 observability 文档强调 trace 和 run，是很合理的。trace 记录的是一整次执行过程，run 则是这条过程中每个步骤的单元。

这类数据能回答一个普通 APM 指标回答不了的问题：

这次 Agent 到底是怎么走到这个结果的？

LangChain 当前官方 observability 文档的最小启用方式非常直接：

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=<your-api-key>

如果你用的是 create_agent，官方文档也明确说明它会自动支持 LangSmith tracing。也就是说，你至少可以先把完整轨迹采集起来，而不必一开始就自己造一整套追踪基础设施。

一个最小示例：

from langchain.agents import create_agent


def search_web(query: str) -> str:
    """搜索资料。"""
    return f"Search results for: {query}"


agent = create_agent(
    model="gpt-4.1",
    tools=[search_web],
    system_prompt="你是一个只在必要时调用搜索的助手。",
)


result = agent.invoke(
    {"messages": [{"role": "user", "content": "搜索最新的 Agent 测试方法"}]}
)

从监控角度看，这段代码的价值不是“能跑”，而是它会把模型调用和工具调用完整记下来，给你后续的排障和评估打基础。

官方 observability 文档里还专门强调了 metadata 和 tags。这一步对生产排查非常关键，因为没有业务上下文的 trace，通常很难做真正有效的过滤和对比。

例如：

result = agent.invoke(
    {"messages": [{"role": "user", "content": "帮我整理本周告警"}]},
    config={
        "tags": ["production", "ops-agent", "v2"],
        "metadata": {
            "tenant_id": "tenant_42",
            "workflow": "weekly-ops-summary",
            "plan_type": "enterprise",
        },
    },
)

这些字段看起来像小事，但它们决定了后面你能不能快速回答：

• •哪个租户问题最多
• •哪个 workflow 延迟最高
• •哪个版本上线后工具失败率升高

没有这些维度，监控面板往往只能停留在“感觉最近不太对”。

在 trace 打通后，再谈指标才有意义。对 Agent 来说，我更建议至少盯下面几组：

1. 结果指标

• •任务成功率
• •拒绝率
• •人工接管率

2. 过程指标

• •平均步数
• •工具调用次数
• •工具失败率
• •重试次数

3. 资源指标

• •请求总延迟
• •模型延迟
• •工具延迟
• •token 消耗
• •单任务成本

4. 质量信号

• •用户反馈
• •在线评估分数
• •高风险输出占比

这四类指标一起看，才比较像一个完整的 Agent 运行画像。

Agent 系统流量一大，trace 很快就会非常多。这个时候最有价值的，不是把所有运行都看一遍，而是尽快把“值得看”的运行筛出来。

比较实用的筛选条件包括：

• •工具调用失败的 trace
• •步数异常长的 trace
• •成本异常高的 trace
• •用户给了差评的 trace
• •命中了特定高风险工具的 trace

LangSmith 的 online evaluations 文档也强调了这一点：在线评估可以用于生产监控、异常检测和把线上坏例子沉淀回线下数据集。

这意味着监控不应该只停留在“看板”，而应该进入反馈闭环。

对 Agent 系统来说，很多问题很难只靠固定规则捕捉，比如：

• •回答虽然语法通顺，但没有真正解决问题
• •工具调用表面成功，但选型明显绕远
• •多轮对话里主题已经偏掉

这种时候，LangSmith 的 online evaluations 或 OpenAI 的 trace grading 这类机制会比手写一堆静态告警更有用。因为它们能在生产流量上持续打质量标签。

一个更合理的监控闭环应该是：

• •tracing 采集完整轨迹
• •用规则和元数据筛出高风险运行
• •对关键流量跑在线评估
• •把坏例子沉淀成离线测试集

这样“监控”和“评估”才真正接起来。

LangGraph 官方 observability 文档还提到 anonymizers，这个提醒非常重要。因为 Agent trace 往往会包含：

• •用户输入
• •工单内容
• •内部文档片段
• •账号和业务标识

如果你在生产环境里直接全量记录这些内容，没有脱敏和访问控制，监控系统本身就会变成新的风险源。

所以真正的 Agent 监控设计，除了“看得见”，还要确保：

• •能按需脱敏
• •能控制访问权限
• •能区分开发、测试、生产项目

如果你正在给 Agent 项目补监控，我更建议按这个顺序做：

• •先开启 tracing
• •给 trace 补 tags 和 metadata
• •先做成功率、延迟、成本、工具失败率几个核心面板
• •再为高风险流量加在线评估和告警

别一上来就做“智能根因分析平台”。大多数团队最先缺的，其实只是一个能看清轨迹的地方。

Agent 监控的第一步，不是让系统替你解释一切，而是先把执行轨迹完整留下来。只有这样，你后面做的这些事情才会真正有依据：

• •定位失败点
• •发现成本异常
• •比较版本差异
• •在线评估质量
• •把生产问题回流到测试和评估

把 tracing、metadata、核心运行指标和在线评估串起来，才算真正建立起 Agent 的监控闭环。

• •LangChain Observability
• •LangGraph Observability
• •LangSmith Observability
• •LangSmith Online Evaluations