引言

当一个 AI Agent 从 Demo 走向 7×24 小时的生产环境后，团队最先遇到的问题往往不是“模型不够聪明”，而是“我不知道它到底在干什么”。传统的 APM（应用性能监控）只能捕获 HTTP 延迟与错误码，却无法回答几个关键问题：

  • 这次回答为什么花了 12 秒？是检索慢、模型慢，还是工具调用重试了三次？
  • 同一个问题昨天答案正确，今天为什么错了？是 prompt 漂移还是记忆污染？
  • 这次调用烧掉了多少 token、花了多少美元？哪个子 Agent 是成本黑洞？

要回答这些，需要一套面向 Agent 的可观测性与在线评估体系。本文基于 2026 年的生产实践，梳理其核心架构、OpenTelemetry 语义约定、LLM-as-Judge 在线评估流水线以及指标体系。

一、为什么 Agent 可观测性比传统 APM 更难

Agent 的一次请求不再是简单的“服务→数据库→返回”，而是一条非确定性、多分支、可自循环的执行图：

  1. 非确定性：同样的输入可能走不同的推理路径，Trace 无法用固定模板匹配。
  2. 多层级嵌套：Orchestrator → Worker → 工具调用 → 子 LLM 调用，形成多层 Span 树。
  3. 长尾与自循环：Agent 可能自我反思、重试、回溯，单次请求的 Span 数从个位数到上百不等。
  4. 语义正确性：延迟低不代表成功，“快速给出错误答案”是最危险的失败模式。

因此，Agent 可观测性必须同时覆盖性能（Performance）与正确性（Correctness）两个维度。

二、OpenTelemetry 语义约定：Span / Trace / Event 三层模型

2026 年最主流的做法是复用 OpenTelemetry（OTel）协议，并对 Agent 场景扩展一层语义约定：

  • Trace（链路）：一次用户请求的完整生命周期。
  • Span（跨度）：一个原子操作单元，如一次 LLM 调用、一次工具执行、一次检索。
  • Event（事件）：Span 内的离散时点，如 token_stream_start、tool_retry、guardrail_blocked。
from opentelemetry import trace

tracer = trace.get_tracer("littlecorn.agent")

def run_agent_task(task_id: str, user_input: str):
    # 根 Span：整个 Agent 任务
    with tracer.start_as_current_span("agent.task") as root:
        root.set_attribute("agent.task_id", task_id)
        root.set_attribute("agent.input_tokens_estimate", len(user_input) // 4)

        # 子 Span：规划阶段
        with tracer.start_as_current_span("agent.plan") as plan:
            plan.set_attribute("agent.phase", "planning")
            steps = planner(user_input)
            plan.set_attribute("agent.plan_steps", len(steps))

        # 子 Span：工具调用（可循环）
        for i, step in enumerate(steps):
            with tracer.start_as_current_span(f"agent.tool.{step.name}") as span:
                span.set_attribute("tool.name", step.name)
                span.set_attribute("tool.attempt", i)
                try:
                    result = execute_tool(step)
                    span.set_attribute("tool.status", "ok")
                except Exception as exc:
                    span.add_event("tool_retry", {"error": str(exc)})
                    span.set_attribute("tool.status", "error")
                    raise
        return result

关键实践：

  1. 统一属性命名：如 agent.task_id、llm.model、llm.prompt_tokens、tool.name，便于跨服务聚合。
  2. 记录 token 与成本而非仅耗时：在 LLM Span 上直接写入 llm.cost_usd。
  3. 采样策略分层：正常链路按 5% 采样，错误链路与超长链路 100% 保留。

三、LLM-as-Judge 在线评估流水线

性能指标可以靠 Trace，但“答案对不对”需要在线评估（Online Evaluation）。2026 年生产级方案通常采用双轨评估：

1. 规则与断言（Deterministic Checks）

对结构化输出、格式约束、禁止词、工具调用合法性做零成本确定性检查，作为第一道闸门。

2. LLM-as-Judge（语义评分）

用一个更强的“评委模型”对 Agent 输出进行多维度打分，维度通常包括：

  • 忠实度（Faithfulness）：答案是否有检索依据，有无幻觉。
  • 相关性（Relevance）：是否真正回答了用户问题。
  • 完整性（Completeness）：是否遗漏关键步骤或边界条件。
  • 安全性（Safety）：是否触碰护栏与合规红线。
JUDGE_PROMPT = """你是严格的评审专家。请依据【用户问题】【检索证据】【Agent 回答】
对回答的忠实度、相关性、安全性各打 1-5 分，并只用 JSON 输出：
{"faithfulness": int, "relevance": int, "safety": int, "reason": str}"""

def online_evaluate(sample: dict) -> dict:
    resp = judge_llm.chat(JUDGE_PROMPT.format(**sample), temperature=0.0)
    score = parse_json(resp)
    # 低于阈值即进入人工复核队列
    if score["faithfulness"] < 3 or score["safety"] < 4:
        push_to_review_queue(sample, score)
    return score

3. 采样而非全量

Judge 调用本身有成本，因此只对关键流量（高价值用户、付费场景、随机 1%~5% 抽样）做语义评估，其余依赖确定性检查。

四、生产指标体系与告警阈值

一套可落地的 Agent 指标体系可归纳为四层：

层级代表指标典型阈值
可用性任务成功率、工具错误率成功率 < 95% 告警
性能P50/P95 端到端延迟、Span 深度P95 > 30s 告警
成本单任务 token 数、单任务美元成本环比突增 50% 告警
质量Judge 忠实度均值、护栏拦截率忠实度 < 3.5 告警
经验法则：质量指标必须以滑动窗口 + 环比方式监控，单点绝对值极易被流量结构变化误导。

五、与多智能体容错架构的协同

可观测性不是孤立的监控，而应与多智能体协作与容错架构形成闭环：

  1. Trace 驱动自愈：当某个 Worker 的 tool.error_rate 连续 3 个窗口超阈值，调度器自动将其降级或隔离。
  2. 评估驱动演进：Judge 分数周报回流至 Prompt 与 RAG 语料优化，形成“评估→优化→再评估”飞轮。
  3. 成本驱动路由：结合 llm.cost_usd 与质量分，动态为不同任务选择性价比最优的模型。

六、总结与展望

AI Agent 的可观测性与在线评估，本质上是把“黑盒智能”转变为“可度量、可归因、可自愈”的工程系统。通过 OpenTelemetry 语义约定、LLM-as-Judge 在线评估以及四层指标体系，团队第一次能够像运营分布式微服务一样运营 Agent。

未来，随着标准化 Agent Trace 协议与可解释评估模型的成熟，我们有望实现完全自动化的质量回归检测与根因定位，让自主智能体真正成为可信赖的生产力基础设施。