AI Agent 生产运维指南：可观测性、成本与持续评估

前言

2026 年，一个 AI Agent 系统最常见的崩溃场景不是「模型不够聪明」。

是凌晨两点，你被报警叫醒，发现 API 响应时间从 200ms 飙升到 8 秒。你打开日志，看到的是一长串 token 消耗记录，但不知道哪一步出了问题。是月初结算时发现 LLM 调用成本是预期的三倍，但不知道是哪个 Agent、哪个场景在浪费 token。

AI Agent 运维的核心挑战不是 AI 本身，是可观测性。这篇文章给出生产级 AI Agent 运维的三层框架：可观测性层、成本控制层、效果评估层。每个层次给出具体工具选型和实操建议。

第一层：可观测性——你得先知道 Agent 在做什么

AI Agent 的可观测性比传统软件更难，因为 Agent 的行为是非确定性的——同样的输入，模型推理路径可能不同。这种不确定性让传统的「请求 → 响应 → 状态码」监控范式完全失效。

AI Agent 的可观测性需要回答四个问题：

1. Trace：Agent 的完整决策链路是什么（调用了哪些工具、以什么顺序、输入输出是什么）
2. Cost：每次 LLM 调用的 token 消耗是多少，分布在哪个 Agent、哪个场景
3. Quality：Agent 的输出质量如何，是否符合业务预期
4. Latency：端到端响应时间是多少，哪一步是瓶颈

工具层可观测性：LangSmith vs Langfuse vs Phoenix

实战：Langfuse 自托管部署

大多数需要数据主权的团队，Langfuse 是最实际的选择。Docker Compose 一键部署：

1
title="docker-compose.yml"
2
version: '3.8'
3
services:
4
  langfuse:
5
    image: langfuse/langfuse:latest
6
    ports:
7
      - "3000:3000"
8
    environment:
9
      DATABASE_URL: postgresql://langfuse:langfuse@db:5432/langfuse
10
      NEXTAUTH_SECRET: your-secret-key
11
      NEXTAUTH_URL: http://localhost:3000
12
    depends_on:
13
      - db
14
  db:
15
    image: postgres:16
16
    environment:
17
      POSTGRES_DB: langfuse
18
      POSTGRES_USER: langfuse
19
      POSTGRES_PASSWORD: langfuse
20
    volumes:
21
      - postgres_data:/var/lib/postgresql/data
22

23
volumes:
24
  postgres_data:

1
# 启动
2
docker-compose up -d
3

4
# 接入 SDK
5
pip install langfuse
6

7
# 在你的 Agent 代码中
8
from langfuse import Langfuse
9
langfuse = Langfuse()
10

11
# 装饰你的 LLM 调用
12
@langfuse.observe()
13
def your_agent(...):
14
    ...

Langfuse 的 trace 视图会给你每个 Agent 执行步骤的完整链路图，包括：

• 每个 tool call 的输入输出
• LLM 调用的 token 消耗和延迟
• 会话级别的聚合统计

可观测性的常见误区

误区一：「先跑起来，以后再加观测」

这是最常见的错误。AI Agent 系统的可观测性债务累积极快——当你发现需要加 trace 的时候，系统里已经有几十个 LLM 调用点散落在各处，加一个需要改几十个地方。

正确的做法：从第一个原型开始就接入可观测性工具，哪怕只是一个简单的 token 计数。

误区二：「可观测性是开发的事，运维不需要参与」

AI Agent 的可观测性设计需要开发、运维、数据三方的协作。开发定义 trace 粒度，运维定义告警阈值，数据定义质量评估标准。把这三件事全交给开发团队，结果是 trace 打了，但没人看。

误区三：「trace 越细越好」

Trace 越细，存储成本越高，排查问题时噪音越多。最有效的 trace 是业务关键节点的 trace，而不是「每个函数调用都打点」。建议关键节点：Agent 决策点、工具调用点、外部 API 调用点、人工审批节点。

第二层：成本控制——LLM 调用的钱花在哪里了

AI Agent 系统的 LLM 成本通常是传统 API 调用的 10-100 倍，因为 Agent 需要多次调用（规划一次、工具执行后确认一次、生成响应一次）。不知道成本在哪里，是大多数团队在生产阶段被账单震惊的原因。

成本分析的三层结构

第一层：Token 层

每次 LLM 调用的 input token + output token，按模型单价计算。这是成本的基础单位。

1
成本 = (input_tokens × input_price) + (output_tokens × output_price)

但 Token 层只是基础。真正的问题在第二层。

第二层：Agent 层

在多 Agent 系统里，每个 Agent 的 LLM 调用成本是独立的。你需要知道：

• 哪个 Agent 消耗最多 token
• 哪个 Agent 的 token 消耗在增长（可能说明上下文在膨胀）
• 每个 Agent 的 cost 与其业务价值是否匹配

第三层：场景层

Token 成本按场景分解才是有效的成本分析：

1
客服 Agent：月均 1.2M input tokens，800K output tokens
2
数据提取 Agent：月均 3.8M input tokens，200K output tokens
3
内容生成 Agent：月均 500K input tokens，1.5M output tokens

场景分解的价值是发现「哪个场景的 ROI 最低」——如果数据提取 Agent 消耗了最多的 token，但业务价值最低，你应该优先优化它。

成本优化的四个方向

方向一：模型分流

用大模型做复杂推理，用小模型做简单分类。不同样本用不同成本的模型处理：

1
def classify_task(task: str) -> str:
2
    """用小模型判断任务复杂度"""
3
    response = client.chat.completions.create(
4
        model="gpt-4o-mini",
5
        messages=[
6
            {"role": "system", "content": "判断以下任务的复杂度：简单/中等/复杂"},
7
            {"role": "user", "content": task}
8
        ]
9
    )
10
    return response.choices[0].message.content
11

12
def route_task(task: str) -> str:
13
    complexity = classify_task(task)
14
    if complexity == "简单":
15
        return "gpt-4o-mini"  # $0.15/1M input
16
    elif complexity == "中等":
17
        return "gpt-4o"       # $2.5/1M input
18
    else:
19
        return "gpt-4.5"      # $10/1M input

方向二：缓存相似的 RAG 检索

对于 RAG 场景，相似问题可能会被重复检索。简单的向量缓存可以显著降低 RAG 部分的 token 消耗：

1
from langchain.cache import InMemoryCache
2
from langchain.globals import set_llm_cache
3

4
set_llm_cache(InMemoryCache())
5

6
# 相同问题在 cache hit 时完全不产生 LLM 调用

方向三：Prompt 压缩

input token 成本通常远大于 output token 成本。对输入进行压缩是有效的成本优化手段：

• 简单压缩：去掉 prompt 中的冗余示例
• 语义压缩：用一个小模型先提炼用户输入的意图，过滤掉无关信息
• 结构化压缩：用 JSON Schema 而非自然语言描述输入格式

方向四：工具调用优化

工具调用是最容易浪费 token 的地方。常见的浪费场景：

• 过度检索：Agent 在不确定时倾向于再次检索，而不是利用已有上下文
• 批量操作分散：应该一次批量处理的任务被拆成了多次单独调用
• 无缓存的外部 API 调用：每次调用都重新请求，而不是缓存结果

LangSmith 的 trace 分析功能可以帮助你识别这些浪费点。查看工具调用的频率和模式，你会看到明显的优化空间。

第三层：效果评估——怎么知道 Agent 好不好

可观测性告诉你「Agent 在做什么」，效果评估告诉你「Agent 做得对不对」。这是两个不同的问题。

评估的三层体系

第一层：功能测试（Does it work?）

最基本的测试：给定一个输入，Agent 是否给出了正确的输出。这与传统软件的功能测试没有本质区别。

1
def test_agent():
2
    result = agent.run("用户的具体问题")
3
    expected = "期望的答案内容"
4
    # 简单的字符串包含检查，或者用更复杂的相似度判断
5
    assert expected in result or semantic_similarity(result, expected) > 0.8

第二层：质量评估（Is it right?）

功能正确不代表质量好。「提取了正确的信息但表述混乱」是常见的问题。

质量评估需要定义指标：

第三层：业务评估（Does it help?）

功能测试和质量评估都是技术指标，业务评估问的是：Agent 的输出是否实际帮助了业务目标？

客服 Agent 的业务指标：问题解决率、用户满意度评分、转人工率 代码生成 Agent 的业务指标：代码接受率、Code Review 通过率、线上 bug 率变化

业务评估是最难做的，也是最有价值的。大多数团队只做到第二层，缺少第三层导致的问题是：技术团队觉得 Agent 很好，但业务方觉得「没什么用」。

持续评估的机制

评估不能是一次性的，需要持续运行：

1
# 定期采样生产流量，人工标注 + 指标计算
2
import random
3
from datetime import datetime, timedelta
4

5
def sample_production_eval(window_hours=24, sample_size=100):
6
    """从过去 N 小时的 production logs 中采样，生成评估集"""
7
    logs = fetch_production_logs(
8
        start_time=datetime.now() - timedelta(hours=window_hours)
9
    )
10
    samples = random.sample(logs, min(sample_size, len(logs)))
11

12
    for sample in samples:
13
        # 发送给人工标注
14
        human_label = request_human_label(sample)
15
        # 计算指标
16
        metrics = compute_metrics(sample.model_output, human_label)
17
        log_eval_result(sample, metrics)

这个机制的价值是让 Agent 的质量有客观数据可循，而不是靠「感觉还行」来判断。

三层联动的运维视角

可观测性、成本控制、效果评估不是三个独立的系统。它们需要联动才能形成有效的运维闭环。

联动一：可观测性 → 成本控制

LangSmith 或 Langfuse 的 trace 数据是成本分析的基础。没有完整的 trace，你无法知道哪个 Agent 消耗了多少 token。将 trace 数据导入成本分析管道，按 Agent、场景、时间段聚合，才能发现优化点。

联动二：成本控制 → 效果评估

成本优化往往会影响输出质量。切换到更小的模型可以降低成本，但可能降低质量。这需要用效果评估系统来监控「成本优化是否以牺牲质量为代价」。

联动三：效果评估 → 可观测性

当效果评估发现质量下降，需要在可观测性系统里找到对应的 trace，分析质量下降的原因——是模型问题、prompt 问题、还是工具调用问题。

一个完整的 AI Agent 运维系统：

1
[可观测性] ←→ [成本控制] ←→ [效果评估]
2
     ↑              ↑              ↑
3
     └──────────────┴──────────────┘
4
              持续改进循环

实操建议：先建哪个

对于刚进入生产阶段的 AI Agent 团队，建议按以下顺序建设：

第一阶段（0 → 1）：接入 LangSmith 或 Langfuse

不管用哪个框架，先把 trace 打通。这是所有后续运维能力的基础。

第二阶段（1 → 3个月）：建立成本监控

在 trace 基础上加 token 计数和成本聚合仪表盘。先看到钱花在哪里，再决定怎么优化。

第三阶段（3个月+）：建立效果评估体系

生产流量采样 + 人工标注 + 指标持续跟踪。这个阶段需要业务方参与，定义什么是「好」的业务标准。

最常见的错误是跳过第一阶段直接做第二阶段——没有 trace 的成本监控只能看到总数，看不到分布，找不到优化点。

相关阅读：

• AI Agent 工具链分层架构：从原语到平台
• 九大 AI Agent 框架实地横评：谁真正能交付生产