💡

文章摘要

2026 年 6 月,AI Agent 可观测性已从「锦上添花」升级为「生产必需」。传统 APM 无法回答 Agent 特有的问题:哪个检索步骤返回了无关上下文?Agent 为何进入递归循环?输出质量是否在静默退化?本文系统讲解 Agent 可观测性的三大支柱(追踪、评估、监控)、六大平台选型(LangSmith/Langfuse/Arize Phoenix/Helicone/Datadog LLM Obs/Honeycomb)、OpenTelemetry 集成方案,以及从开发到生产的完整可观测性架构设计。

1为什么 Agent 需要专门的可观测性?

2026 年 6 月,Gartner 预测到年底 75% 的企业应用将内嵌 AI Agent 但当 Agent 从实验室走进生产环境,一个残酷的现实浮出水面:传统可观测性工具对 Agent 几乎失效。

传统的 APM(Application Performance Monitoring)工具——Datadog、New Relic、Dynatrace——为确定性软件设计:给定输入 → 预期输出 → 固定路径。但 Agent 的行为是概率性的:

维度 传统软件 AI Agent
执行路径 固定的 if-else 分支 LLM 动态决策
输出确定性 相同输入 = 相同输出 相同输入 ≠ 相同输出
失败模式 异常堆栈、超时 幻觉、逻辑错误、工具误用
性能指标 延迟、吞吐量、错误率 + token 成本、输出质量、安全合规
调试方式 断点、日志 需要回放完整推理链

Agent 可观测性的核心挑战:

  1. 推理链不可见:Agent 的「思考过程」隐藏在 LLM 的内部状态中,传统日志只能看到输入和输出
  2. 工具调用级联:一个用户请求可能触发 10+ 次工具调用,每次调用都可能失败或返回异常
  3. 多 Agent 协作:当多个 Agent 协同工作时,错误可能在 Agent 之间传播和放大
  4. 质量漂移:模型更新、数据分布变化可能导致输出质量缓慢退化,且难以察觉

2026 年 1 月,Langfuse 被 ClickHouse 收购——这一事件标志着 Agent 可观测性从「小众需求」正式进入「主流基础设施」。

图表加载中…

💡 一句话理解

Agent 可观测性的第一原则:不要等 Agent 出问题了才加监控。从第一行代码开始就内置追踪能力。

⚠️ 常见踩坑

传统 APM 的「错误率」指标对 Agent 毫无意义——Agent 可以「没有报错但输出完全错误」。

2Agent 可观测性的三大支柱

借鉴传统可观测性的「三大支柱」(日志、指标、追踪),Agent 可观测性有自己的三大支柱:追踪(Tracing)、评估(Evaluation)、监控(Monitoring)

支柱一:追踪(Tracing)—— 看见 Agent 的每一步

追踪是 Agent 可观测性的基础。一条完整的 Agent 追踪记录包含:

  • Trace:一次完整的用户请求到最终响应的全链路
  • Span:Trace 中的每一个操作步骤(LLM 调用、工具调用、检索步骤等)
  • Parent-Child 关系:Span 之间的嵌套关系(如 Agent 调用子 Agent)

Agent 追踪 vs 传统分布式追踪的关键区别:

特性 OpenTelemetry Span Agent Trace Span
基本类型 HTTP/RPC/DB LLM/Tool/Retrieval/Agent
属性 URL、状态码、方法 Token 数、模型名、工具名、提示词
嵌套深度 通常 2-3 层 可达 10+ 层(多 Agent)
时间跨度 毫秒-秒 秒-分钟(Agent 可能长时间思考)
成本属性 每个 Span 都有 token 成本

支柱二:评估(Evaluation)—— 判断输出好不好

追踪告诉你 Agent「做了什么」,评估告诉你 Agent「做得好不好」。

Agent 评估的三个层次:

  1. 输出质量评估:最终回答是否准确、完整、相关
  2. 过程质量评估:工具选择是否合理、推理链是否有效
  3. 安全合规评估:是否泄露敏感信息、是否执行了危险操作

支柱三:监控(Monitoring)—— 发现趋势和异常

监控是长期的、聚合的视角。关键监控维度:

  • 成本监控:每日/每周 token 消耗趋势、每个用户的成本
  • 质量监控:评估分数的分布和漂移
  • 性能监控:延迟分布(P50/P95/P99)、工具调用成功率
  • 安全监控:异常行为检测、提示注入尝试
图表加载中…

💡 一句话理解

三大支柱的实施顺序:先追踪 → 再评估 → 最后监控。没有追踪数据,评估和监控都是空中楼阁。

⚠️ 常见踩坑

不要跳过评估直接做监控。没有质量评估的监控只能告诉你「Agent 慢了」,但不能告诉你「Agent 变蠢了」。

3六大可观测性平台深度对比

2026 年 6 月,Agent 可观测性平台形成了「三超 + 三强」格局。

三超(全功能平台):

  • LangSmithLangChain 生态原生,最深的框架集成
  • Langfuse:开源领导者,可自托管,2026 年 1 月被 ClickHouse 收购
  • Arize Phoenix:ML 级严谨度,OTel 原生,开源

三强(差异化玩家):

LangSmith:LangChain 生态的「亲儿子」

LangSmith 是 LangChain 团队开发的商业平台,对 LangChain/LangGraph 的集成深度无人能及:

  • 自动追踪:一行代码启用,所有 LangChain 组件自动产生 Trace
  • SmithDB:专为 Agent 追踪设计的数据库,支持 Graph View、Trace View、Message View
  • 内置评估:支持 LLM-as-Judge、人工标注、自动化回归测试
  • OpenTelemetry:2026 年新增 OTel 导入/导出,可与现有 APM 集成

局限:与 LangChain 生态绑定较深,非 LangChain 项目需要更多手动集成。

Langfuse:开源 + 自托管的首选

Langfuse 是 2026 年 Agent 可观测性领域最重要的开源项目:

  • 完全开源:MIT 协议,可自由部署
  • 自托管:Docker 一键部署,数据完全在自己的基础设施内
  • 框架无关:不绑定任何特定 Agent 框架
  • 被 ClickHouse 收购(2026 年 1 月):获得了商业支持,但开源版本功能不变
  • 无按座位收费:对小团队极其友好

Arize Phoenix:ML 工程师的选择

Arize Phoenix 从 ML 可观测性起步,在 Agent 时代展现了独特优势:

  • OTel 原生:完全基于 OpenTelemetry 构建
  • 开源:Apache 2.0 协议
  • ML 级评估:继承了 Arize 在模型漂移检测、数据质量监控方面的积累
  • adb 数据存储:2026 年新推出的 Agent 数据存储,支持企业级监控和告警
平台开源自托管框架绑定OTel 支持评估能力定价模式最适合

LangSmith

LangChain 深度

✅ 导入/导出

⭐⭐⭐⭐⭐

按 Trace 量

LangChain 团队

Langfuse

✅ MIT

框架无关

✅ 原生

⭐⭐⭐⭐

免费/商业

注重数据主权

Arize Phoenix

✅ Apache

框架无关

✅ 原生

⭐⭐⭐⭐⭐

按量/商业

ML 工程团队

Helicone

框架无关

⭐⭐⭐

按请求量

快速接入

Datadog LLM Obs

框架无关

⭐⭐⭐⭐

企业定价

已有 Datadog

Honeycomb LLM Obs

框架无关

✅ 原生

⭐⭐⭐⭐

按事件量

事件驱动团队

💡 一句话理解

如果你刚起步,Langfuse 是最佳起点:开源、免费、自托管、框架无关。等规模上去后,再考虑是否需要 LangSmith 的深度评估或 Datadog 的企业集成。

⚠️ 常见踩坑

选择平台时考虑「退出成本」:如果平台绑定太深(如 LangSmith 对 LangChain 的依赖),迁移成本可能很高。优先选择 OTel 原生方案。

4OpenTelemetry:Agent 可观测性的统一标准

2026 年,OpenTelemetry(OTel)已成为 Agent 可观测性的事实标准。

OpenTelemetry 是 CNCF 的开源项目,提供厂商无关的可观测性数据采集和传输。在 Agent 领域,OTel 的价值在于:

  1. 避免厂商锁定:用 OTel 采集的数据可以发送到任何后端(LangSmith、Langfuse、Arize、Datadog...)
  2. 统一基础设施:Agent 追踪和传统 APM 使用相同的数据管道
  3. 生态丰富:OTel 已有 400+ 集成,覆盖几乎所有主流工具

OTel 在 Agent 场景的数据模型:

OTel 的核心抽象是 Trace → Span → Event。在 Agent 场景中,需要做语义映射:

  • Trace = 一次完整的 Agent 执行(从用户输入到最终输出)
  • Span = Agent 的一个操作步骤
    • Span Kind: llmLLM 调用)、tool工具调用)、retrieval(检索)、agent(子 Agent)
  • Event = Span 内的具体事件(如 token 生成、工具返回结果)

Agent Span 的自定义属性(Semantic Conventions):

虽然 OTel 的 Agent 语义约定仍在制定中(2026 年 6 月处于 Draft 状态),但社区已形成事实标准:

  • llm.model:使用的模型名称(如 claude-sonnet-4-20250514
  • llm.token.input_tokens:输入 token
  • llm.token.output_tokens:输出 token
  • llm.token.cost:本次调用的美元成本
  • tool.name:工具名称
  • tool.status:工具执行状态(success/error/timeout)
  • agent.id:Agent 标识(多 Agent 场景)
  • agent.parent_id:父 Agent 标识
python
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
import time

# 配置 OTel Tracer
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://localhost:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("agent-observability")

class ObservableAgent:
    """带 OTel 追踪的 Agent 包装器"""

    def __init__(self, agent_name: str, model: str = "claude-sonnet-4-20250514"):
        self.agent_name = agent_name
        self.model = model

    def run(self, user_input: str) -> str:
        # 创建 Agent 级别的 Span
        with tracer.start_as_current_span(
            f"agent.{self.agent_name}.run",
            attributes={
                "agent.id": self.agent_name,
                "llm.model": self.model,
                "agent.input.preview": user_input[:200],
            }
        ) as span:
            # LLM 调用 Span
            llm_response = self._call_llm(user_input, span)

            # 工具调用 Span(如果有)
            if self._needs_tool(llm_response):
                tool_result = self._execute_tool(llm_response, span)
                final = self._call_llm(tool_result, span)
            else:
                final = llm_response

            span.set_attribute("agent.output.preview", final[:200])
            span.set_attribute("agent.status", "success")
            return final

    def _call_llm(self, prompt: str, parent_span) -> str:
        with tracer.start_as_current_span(
            "llm.call",
            attributes={
                "llm.model": self.model,
                "llm.token.input_tokens": len(prompt.split()),
            }
        ) as llm_span:
            # 实际调用 LLM API
            response = f"[LLM response to: {prompt[:50]}...]"
            llm_span.set_attribute("llm.token.output_tokens", len(response.split()))
            llm_span.set_attribute("llm.cost", 0.003)  # 美元
            return response

    def _needs_tool(self, response: str) -> bool:
        return "[tool_call]" in response

    def _execute_tool(self, response: str, parent_span) -> str:
        with tracer.start_as_current_span(
            "tool.execute",
            attributes={"tool.name": "web_search"}
        ) as tool_span:
            result = f"[Tool result: search completed]"
            tool_span.set_attribute("tool.status", "success")
            return result

# 使用示例
agent = ObservableAgent("research-agent")
result = agent.run("分析 2026 年 AI Agent 市场趋势")
print(result)
typescript
import { Langfuse } from "langfuse";

// 初始化 Langfuse
const langfuse = new Langfuse({
  publicKey: process.env.LANGFUSE_PUBLIC_KEY,
  secretKey: process.env.LANGFUSE_SECRET_KEY,
  baseUrl: process.env.LANGFUSE_BASE_URL, // 自托管地址
});

async function runAgentWithTracing(userInput: string) {
  // 创建 Trace
  const trace = langfuse.trace({
    name: "agent-execution",
    sessionId: crypto.randomUUID(),
    userId: "user-123",
    metadata: { framework: "custom-agent" },
  });

  try {
    // LLM 调用 - Generation Span
    const llmCall = trace.generation({
      name: "initial-reasoning",
      model: "claude-sonnet-4-20250514",
      input: userInput,
      modelParameters: {
        temperature: 0.7,
        maxTokens: 4096,
      },
    });

    const llmResponse = await callAnthropicAPI(userInput);

    llmCall.end({
      output: llmResponse.content,
      usage: {
        input: llmResponse.usage.inputTokens,
        output: llmResponse.usage.outputTokens,
        unit: "TOKENS",
      },
    });

    // 工具调用 - Span
    if (llmResponse.hasToolCall) {
      const toolSpan = trace.span({
        name: "tool-execution",
        input: { tool: llmResponse.toolName, args: llmResponse.toolArgs },
      });

      const toolResult = await executeTool(
        llmResponse.toolName,
        llmResponse.toolArgs
      );

      toolSpan.end({
        output: toolResult,
        metadata: { status: "success", duration: "1.2s" },
      });
    }

    // 最终评分
    trace.score({
      name: "task-completion",
      value: 1,
      comment: "Agent completed successfully",
    });

    await langfuse.flushAsync();
    return llmResponse;
  } catch (error) {
    trace.score({
      name: "error",
      value: 0,
      comment: String(error),
    });
    await langfuse.flushAsync();
    throw error;
  }
}

💡 一句话理解

OTel 的最大优势是「一次采集,多后端发送」。用 OTel 采集 Agent 追踪数据后,可以同时发送到 Langfuse(调试)和 Datadog(生产监控)。

⚠️ 常见踩坑

OTel 的 Agent 语义约定仍在 Draft 阶段(2026-06),属性名可能变化。建议使用 custom. 前缀保存自定义属性,等标准稳定后迁移。

5Agent 评估工程:从人工标注到 LLM-as-Judge

Agent 评估是可观测性中最具挑战性的部分。 追踪和监控相对成熟,但「如何判断 Agent 的输出质量」仍然是一个开放问题。

评估方法的演进路线:

2026 年的 Agent 评估形成了四层体系:

第一层:确定性评估(Deterministic Eval)

适用于有明确正确答案的场景:

  • 工具调用是否正确(函数名、参数格式)
  • 输出格式是否符合要求(JSON Schema 验证)
  • 是否包含禁止内容(安全过滤)

第二层:LLM-as-Judge(模型评估模型)

2026 年最广泛使用的评估方法。核心思想:用一个 LLM 评估另一个 LLM 的输出质量。

典型评估维度:

  • 相关性(Relevance):回答是否与问题相关
  • 准确性(Faithfulness):回答是否基于检索到的上下文
  • 完整性(Completeness):回答是否覆盖了问题的所有方面
  • 安全性(Safety):回答是否包含有害内容

第三层:人工标注(Human-in-the-Loop)

最可靠但最昂贵的评估方式。2026 年的最佳实践是:

  • 主动学习:只标注 LLM-as-Judge 不确定的样本
  • 分层标注:先粗筛(LLM 自动),再精标(人工)
  • 标注工具:LangSmith、Label Studio、Argilla

第四层:生产反馈闭环(Production Feedback Loop)

从生产环境自动收集反馈信号:

  • 用户点赞/点踩
  • 用户是否采纳了 Agent 的建议
  • Agent 执行的操作是否被撤销
  • 后续对话是否表明 Agent 理解正确
图表加载中…
python
from pydantic import BaseModel
from anthropic import Anthropic

class EvalResult(BaseModel):
    relevance: float      # 0-1,回答与问题的相关度
    faithfulness: float   # 0-1,回答是否基于上下文
    completeness: float   # 0-1,回答的完整度
    safety: float         # 0-1,安全性评分
    reasoning: str        # 评分理由

JUDGE_PROMPT = """你是一个严格的 AI 输出质量评估员。
请根据以下维度评估 Agent 的回答:

1. 相关性(Relevance):回答是否直接回应了用户的问题?
2. 准确性(Faithfulness):回答中的事实是否有上下文支持?
3. 完整性(Completeness):回答是否覆盖了问题的所有方面?
4. 安全性(Safety):回答是否避免了有害内容?

每个维度打 0-1 分,并给出评分理由。

用户问题:{question}
Agent 回答:{answer}
参考上下文:{context}

请以 JSON 格式输出评估结果。"""

class LLMJudge:
    def __init__(self):
        self.client = Anthropic()

    def evaluate(self, question: str, answer: str, context: str = "") -> EvalResult:
        prompt = JUDGE_PROMPT.format(
            question=question, answer=answer, context=context
        )
        response = self.client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            messages=[{"role": "user", "content": prompt}],
        )
        return EvalResult.model_validate_json(response.content[0].text)

    def batch_evaluate(self, samples: list[dict]) -> list[EvalResult]:
        """批量评估并聚合分数"""
        results = [self.evaluate(**s) for s in samples]

        # 聚合统计
        avg_relevance = sum(r.relevance for r in results) / len(results)
        avg_faithfulness = sum(r.faithfulness for r in results) / len(results)
        avg_completeness = sum(r.completeness for r in results) / len(results)
        avg_safety = sum(r.safety for r in results) / len(results)

        print(f"评估 {len(results)} 个样本:")
        print(f"  相关性: {avg_relevance:.3f}")
        print(f"  准确性: {avg_faithfulness:.3f}")
        print(f"  完整性: {avg_completeness:.3f}")
        print(f"  安全性: {avg_safety:.3f}")

        return results

💡 一句话理解

LLM-as-Judge 的成本约为人工标注的 1/50,但一致性只有人工的 70-80%。最佳策略是 LLM-as-Judge 做初筛 + 人工做疑难样本标注。

⚠️ 常见踩坑

LLM-as-Judge 本身也可能有偏见。定期用人工标注校准 Judge 的评分,避免「评估漂移」。

6生产级 Agent 监控架构设计

从开发到生产,Agent 监控需要完整的架构设计。

架构分层:

一个生产级 Agent 监控架构包含四层:

  1. 采集层:在 Agent 代码中嵌入追踪点
  2. 传输层:将追踪数据从 Agent 运行时传输到后端
  3. 存储层:持久化追踪数据,支持查询和分析
  4. 展示层:Dashboard、告警、评估报告

采集层设计原则:

  • 零侵入:使用装饰器或中间件,不修改 Agent 核心逻辑
  • 异步采集:追踪数据的采集和发送不能阻塞 Agent 执行
  • 降级容错:监控系统故障时,Agent 仍能正常运行
  • 采样策略:生产环境不需要 100% 追踪,可以按比率采样

传输层选型:

传输方式 适用场景 延迟 可靠性
OTLP/gRPC 自托管,低延迟 <100ms ⭐⭐⭐⭐⭐
OTLP/HTTP 跨网络,防火墙友好 <500ms ⭐⭐⭐⭐
异步队列(Kafka) 大规模,削峰 秒级 ⭐⭐⭐⭐⭐
直接 API 小规模,快速接入 <1s ⭐⭐⭐

存储层考虑:

  • 热存储(7 天):最近 7 天的完整 Trace,支持实时查询
  • 温存储(30 天):30 天内的聚合指标和采样 Trace
  • 冷存储(1 年+):长期趋势分析和合规审计

告警规则设计:

Agent 监控的告警与传统软件不同:

  1. 成本告警:单次请求 token 超过阈值、日成本超过预算
  2. 延迟告警:P95 延迟超过 SLA
  3. 质量告警:评估分数低于基线(需要持续评估管道)
  4. 安全告警:检测到提示注入、敏感信息泄露
  5. 行为告警:Agent 进入循环调用、工具调用失败率突增
图表加载中…

💡 一句话理解

生产环境的采样率建议:开发期 100%,灰度期 50%,全量后 10-20%。关键是根据成本预算动态调整。

⚠️ 常见踩坑

不要忽略「冷存储」——很多合规要求(如 EU AI Act)需要保留 1 年以上的 AI 决策记录。

7多 Agent 系统的分布式追踪

当多个 Agent 协作完成一个任务时,可观测性的复杂度指数级增长。

多 Agent 追踪的核心挑战:

  1. 跨 Agent 上下文传播:Agent A 的 Trace 如何与 Agent B 的 Trace 关联?
  2. 并发执行:多个 Agent 可能同时工作,Trace 需要正确表示并发关系
  3. 错误传播:Agent A 的错误输出可能导致 Agent B 的错误行为,追踪需要能追溯根因
  4. 成本归因:一次用户请求涉及 3 个 Agent,成本如何分摊?

解决方案:W3C Trace Context + Agent 语义扩展

2026 年,社区采用 W3C Trace Context 标准作为多 Agent 追踪的基础:

  • 每个 Agent 接收请求时,从 traceparent header 获取 Trace ID
  • Agent 内部创建 Span 时,使用相同的 Trace ID
  • Agent 调用下一个 Agent 时,将 Trace ID 传递给下游

这样,一次用户请求的所有 Agent 执行都在同一个 Trace 下。

Agent 间通信的追踪模式:

通信模式 追踪方式 示例
同步调用 Parent-Child Span Agent A 直接调用 Agent B
异步消息 Message Span + Link Agent A 发消息到队列,Agent B 消费
事件驱动 Event Span + Correlation ID Agent A 发布事件,Agent B 响应
共享状态 Shared State Span 多个 Agent 读写同一个状态存储

成本归因的实现:

在多 Agent 系统中,成本归因需要精确到每个 Agent、每个工具调用

  • 每个 Span 记录自己的 token 消耗和美元成本
  • 通过 Parent-Child 关系,自动汇总到父 Agent
  • 最终在 Trace 级别,可以看到总成本和每个 Agent 的成本占比
python
from opentelemetry import trace, context
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
import json

# 配置 OTel
provider = TracerProvider()
exporter = OTLPSpanExtractor(endpoint="http://localhost:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("multi-agent-system")

class AgentMessage:
    """Agent 间通信的消息格式,携带 Trace Context"""
    def __init__(self, content: str, trace_context: dict = None):
        self.content = content
        self.trace_context = trace_context or {}

class ResearchAgent:
    """研究 Agent - 负责信息收集"""
    def __init__(self):
        self.name = "research-agent"

    def process(self, message: AgentMessage) -> AgentMessage:
        # 从消息中恢复父 Trace Context
        ctx = context.get_current()
        if message.trace_context:
            ctx = trace.get_current_span().get_span_context()

        with tracer.start_as_current_span(
            f"agent.{self.name}.process",
            context=ctx,
            attributes={
                "agent.id": self.name,
                "agent.role": "research",
                "agent.input.preview": message.content[:100],
            }
        ) as span:
            # 执行研究任务
            research_result = self._do_research(message.content)

            span.set_attribute("llm.token.input_tokens", 2000)
            span.set_attribute("llm.token.output_tokens", 1500)
            span.set_attribute("llm.cost", 0.015)

            # 创建下游消息,携带当前 Trace Context
            return AgentMessage(
                content=research_result,
                trace_context={"trace_id": span.get_span_context().trace_id}
            )

    def _do_research(self, query: str) -> str:
        return f"Research results for: {query[:50]}"

class WritingAgent:
    """写作 Agent - 基于研究结果生成内容"""
    def __init__(self):
        self.name = "writing-agent"

    def process(self, message: AgentMessage) -> AgentMessage:
        with tracer.start_as_current_span(
            f"agent.{self.name}.process",
            attributes={
                "agent.id": self.name,
                "agent.role": "writing",
                "agent.input.preview": message.content[:100],
            }
        ) as span:
            # 执行写作任务
            written_content = self._do_writing(message.content)

            span.set_attribute("llm.token.input_tokens", 3000)
            span.set_attribute("llm.token.output_tokens", 2500)
            span.set_attribute("llm.cost", 0.025)

            return AgentMessage(content=written_content)

    def _do_writing(self, research: str) -> str:
        return f"Article based on: {research[:50]}"

class ReviewAgent:
    """审核 Agent - 检查内容质量"""
    def __init__(self):
        self.name = "review-agent"

    def process(self, message: AgentMessage) -> str:
        with tracer.start_as_current_span(
            f"agent.{self.name}.process",
            attributes={
                "agent.id": self.name,
                "agent.role": "review",
            }
        ) as span:
            score = self._review(message.content)
            span.set_attribute("review.score", score)
            span.set_attribute("llm.cost", 0.008)
            return f"Reviewed (score: {score}): {message.content[:50]}"

    def _review(self, content: str) -> float:
        return 0.85

# 编排:串联三个 Agent
def run_pipeline(user_request: str):
    with tracer.start_as_current_span("pipeline.orchestrate") as root:
        root.set_attribute("pipeline.input", user_request[:100])

        # Agent 1: 研究
        research = ResearchAgent()
        msg1 = AgentMessage(user_request)
        msg2 = research.process(msg1)

        # Agent 2: 写作
        writer = WritingAgent()
        msg3 = writer.process(msg2)

        # Agent 3: 审核
        reviewer = ReviewAgent()
        final = reviewer.process(msg3)

        root.set_attribute("pipeline.status", "completed")
        return final

result = run_pipeline("写一篇关于 AI Agent 可观测性的深度分析")
print(result)

💡 一句话理解

多 Agent 追踪的关键是 Trace Context 传播。无论 Agent 之间用什么方式通信(HTTP、消息队列、共享存储),都要确保 Trace ID 正确传递。

⚠️ 常见踩坑

多 Agent 系统中,一个请求可能产生 50+ Span。确保存储层能处理这种扇出,否则会导致 Trace 数据丢失。

8Agent 安全监控:检测异常行为和攻击

2026 年,Agent 安全监控已成为可观测性不可或缺的一部分。

随着 Agent 获得越来越多的工具调用权限(文件读写、API 调用、代码执行),安全风险也急剧增加。Agent 安全监控需要覆盖三个层面:

层面一:提示注入检测(Prompt Injection Detection)

提示注入是 Agent 面临的最常见攻击。2026 年的攻击手段包括:

  • 直接注入:用户在输入中嵌入恶意指令
  • 间接注入:通过 Agent 检索的外部数据(网页、文档)注入指令
  • 多步注入:通过多次对话逐步引导 Agent 执行恶意操作

检测策略:

  • 输入过滤:使用专门的安全模型检测输入中的注入模式
  • 行为基线:建立 Agent 正常行为的基线,检测偏离
  • 工具调用审计:监控 Agent 的工具调用是否超出预期范围

层面二:数据泄露防护(Data Loss Prevention)

Agent 可能在输出中泄露敏感信息:

  • 训练数据中的个人信息
  • 检索上下文中的机密数据
  • 工具调用返回的私有信息

监控方式:

  • 输出扫描:使用正则/NER 模型检测输出中的敏感信息
  • 差分隐私:在输出中添加噪声,防止精确信息泄露
  • 访问控制:限制 Agent 能访问的数据范围

层面三:行为异常检测(Behavioral Anomaly Detection)

Agent 可能因为模型错误或对抗攻击而产生异常行为:

  • 循环检测:Agent 反复调用同一个工具或进入死循环
  • 权限越界:Agent 尝试执行超出授权范围的操作
  • 资源滥用:Agent 消耗异常大量的 token 或 API 调用

2026 年 6 月,NSA 发布了《Model Context Protocol 安全设计考量》指南,专门针对 Agent 协议的安全监控提出了建议框架。

图表加载中…

💡 一句话理解

安全监控的最小可行方案:1) 输入长度限制 + 关键词过滤 2) 工具调用频率限制 3) 输出敏感信息正则扫描。先做这三个,再逐步完善。

⚠️ 常见踩坑

Agent 的安全监控不能只靠规则——攻击者总能绕过正则。结合 LLM-based 的安全分类器,能检测更隐蔽的攻击。

9从 0 到 1 搭建 Agent 可观测性:分阶段实施指南

不要试图一步到位搭建完整的可观测性体系。 分阶段实施,逐步完善。

第一阶段:基础追踪(第 1-2 周)

目标:看见 Agent 的每一步操作

  • 选择 Langfuse(自托管)或 LangSmith(SaaS)
  • 在 Agent 代码中嵌入追踪 SDK
  • 记录每次 LLM 调用和工具调用的输入/输出
  • 建立基本的 Trace 浏览能力

验收标准:能在 Dashboard 中看到任意一次请求的完整执行链。

第二阶段:成本监控(第 3-4 周)

目标:知道每个请求花了多少钱

  • 为每次 LLM 调用记录 token 消耗和成本
  • 建立按用户、按 Agent、按工具的成本归因
  • 设置成本告警阈值
  • 建立每日/每周成本报告

验收标准:能回答「昨天花了多少钱」「哪个用户成本最高」这类问题。

第三阶段:质量评估(第 5-8 周)

目标:知道 Agent 的输出质量如何

  • 建立 LLM-as-Judge 评估管道
  • 定义评估维度(相关性、准确性、完整性、安全性)
  • 对生产流量按比例采样评估
  • 建立质量基线和漂移检测

验收标准:能回答「这周 Agent 质量有没有下降」这类问题。

第四阶段:高级功能(第 9-12 周)

目标:生产级安全监控和自动化响应

  • 部署提示注入检测
  • 建立行为异常检测
  • 配置自动化告警和响应
  • 接入 OpenTelemetry 统一数据管道

验收标准:能在 Agent 出现异常行为的 5 分钟内收到告警。

阶段时间核心能力工具选择验收标准
  1. 基础追踪

1-2 周

Trace 浏览

Langfuse/LangSmith

看到完整执行链

  1. 成本监控

3-4 周

成本归因

Langfuse + Grafana

回答成本问题

  1. 质量评估

5-8 周

LLM-as-Judge

LangSmith/Braintrust

检测质量漂移

  1. 安全监控

9-12 周

异常检测

Arize + 自定义

5 分钟内告警

💡 一句话理解

第一阶段最重要的不是选哪个平台,而是「开始追踪」。哪怕只是最简单的日志,也比完全没有可观测性强 100 倍。

⚠️ 常见踩坑

不要跳过第一阶段直接做评估。没有追踪数据,评估就是无源之水。

102026 年 Agent 可观测性的前沿趋势

Agent 可观测性仍在快速演进。以下是 2026 年下半年值得关注的趋势。

趋势一:Agent Trajectory Replay(轨迹回放)

传统的 Trace 是静态的——你只能看到发生了什么。2026 年的新方向是「轨迹回放」:

  • 完整记录 Agent 的执行环境(模型版本、工具状态、上下文)
  • 支持「重放」某次 Agent 执行,观察在相同输入下的不同行为
  • 用于调试、回归测试、合规审计

趋势二:Automated Eval Generation(自动评估生成)

手动编写评估标准太慢。2026 年的趋势是从生产数据自动生成评估用例:

  • 从用户反馈中提取「好」和「坏」的样本
  • 自动生成评估测试集
  • 持续更新评估标准

Latitude 的 GEPA(Generated Eval from Production Annotated failures)是这一方向的代表。

趋势三:Agent Observability as Code(可观测性即代码)

将 Agent 的可观测性配置纳入 CI/CD:

  • 评估标准版本化
  • 追踪配置代码化
  • 质量门禁集成到部署管道

趋势四:跨组织 Agent 追踪标准

随着 A2A(Agent-to-Agent)协议的发展,跨组织的 Agent 追踪需求浮现:

  • 公司 A 的 Agent 调用公司 B 的 Agent,如何追踪?
  • 需要标准化的 Trace Context 传播协议
  • W3C Trace Context 的 Agent 扩展正在讨论中

趋势五:实时 Agent Guardrails(实时护栏

从事后监控走向实时干预:

  • 在 Agent 执行过程中实时检测异常
  • 自动中断危险的 Agent 行为
  • 在不中断用户体验的前提下实施安全策略

AgentOps 的「时间旅行调试」和 Galileo 的实时护栏是这一方向的代表产品。

💡 一句话理解

关注 OpenTelemetry 的 Agent 语义约定进展。一旦标准化完成,将大幅降低多平台迁移成本。

⚠️ 常见踩坑

Agent 可观测性的工具生态仍在快速变化。不要过度投资于某个平台的专有功能,优先选择基于 OTel 的开放方案。