<!-- title: 黑盒即赌：六框架可观测横评 -->

> 2026 年中实测：把同一个"查账单→对账→生成报告"任务灌进六个主流 Agent 框架，只看一行报错（"工具调用返回了非预期 JSON"），谁能在一分钟内定位到是第几跳、哪条工具、prompt 还是 schema 出了问题——这就是本期的横评标尺。

## 概述

本期聚焦 Agent 框架最被低估、却决定能否上线的维度：**可观测性（Observability）**。过去三轮我们已经把方差税、流式延迟、沙箱、成本天花板拆透，但当 agent 跑偏时，"看得见"才是止损的前提。2026 年中，主流框架的可观测路线已分裂成两派：**私有 Trace 树派**（LangGraph→LangSmith、OpenAI Agents SDK→内置面板）调试体验最好，但绑定税重；**OpenTelemetry 传输派**（AutoGen 0.4 原生、CrewAI 多后端、Semantic Kernel）可移植性强，但语义层参差。横评三轴是：**是否默认开启 trace、能否在生产/本地双跑、是否支持 replay 回放重跑**。结论先行——闭源强绑定的框架"开箱即玻璃盒"，但代价是数据出境和二次开发受限；OTel 派"一次埋点多后端"正在成为生产标配，但需要自己拼语义层。下面逐栈拆。

## 六框架可观测横评对比

| 框架 / 工具 | 传输协议 | 默认开启 | 后端锁定 | Trace 语义模型 | Replay 回放 | 接入成本 |
|---|---|---|---|---|---|---|
| **LangGraph → LangSmith** | 私有 run 树（可导 OTel） | 是（配 API key 即收） | 强（LangSmith，可自建） | Run/Span 嵌套树 | 强（trace→数据集→重跑评估） | 极低 |
| **OpenAI Agents SDK** | 内置 trace（可接 OTel processor） | 是（server-side 默认开） | 强（OpenAI 面板，可自定义） | Span：generation/tool/handoff/guardrail | 中 | 极低 |
| **AutoGen 0.4 / AG2** | OpenTelemetry 原生 | 否（需显式 `enable_telemetry`） | 弱（Phoenix/Langfuse/Jaeger 任选） | Actor 消息事件流 | 中（事件日志可重演） | 中 |
| **CrewAI** | OTel + OpenInference | 否（手动配 processor） | 弱（15+ 后端：Langfuse/Phoenix/Portkey/AgentOps） | Crew→Task→Agent 三层 | 弱 | 中低 |
| **Pydantic AI → Logfire** | OTel 原生 | 是（接 Logfire） | 中（Logfire / 任意 OTel） | 强类型 Span + 结构化字段 | 中 | 低 |
| **Semantic Kernel / Google ADK** | OTel + GenAI 约定 | 否（配 exporter） | 中（GCP Cloud Trace / 自选） | 函数调用 + 插件调用语义 | 中 | 中 |

> 注：版本以 2026-07 公开主线为准（AutoGen 已演进到事件驱动的 0.4/AG2，OpenAI Agents SDK tracing 默认 server-side 启用，CrewAI 文档观测页锚定 v1.15.x）。Star 数与定价随时间波动，本文不引用快照数字，避免误导。

## 深度分析：六栈可观测机制逐拆

### 1. LangGraph → LangSmith：私有 Trace 树的"玻璃盒"标杆

**架构原理**：LangGraph 把 agent 编排成状态机图（节点=函数，边=条件路由），每一次状态迁移、每一次 LLM 调用、每一次工具触发都被 LangSmith 捕获成 **Run 树**——根 run 下挂子 run，逐层嵌套，天然就是一棵可折叠的调用树。它的杀手锏是：trace 不仅是"看"，更是"用"——任何一条 trace 可以一键转成 **数据集**，挂上评估器做回归，等于把一次线上事故直接变成一个测试用例。

**代码示例**（接入只需环境变量，零侵入）：
```python
import os
os.environ["LANGSMITH_API_KEY"] = "ls__***"
os.environ["LANGSMITH_TRACING"] = "true"   # tracing v2 默认开启
# 之后任何 LangGraph graph.invoke() / graph.stream() 自动上报
for chunk in graph.stream({"messages": [...]}, stream_mode="values"):
    print(chunk)  # 每个状态快照可观测
```

**优缺点**：优点是调试体验断层领先——run 树、token 分解、延迟瀑布图、prompt diff 全在一个面板；缺点是 **绑定税**：trace 数据默认落 LangSmith 云端，企业数据合规场景必须自建或走 OTel 导出，自建版的 UI/评估能力会打折。

**变现/训练营评估**：**最高优先级素材**。"事故→trace→数据集→回归"闭环是 LangChain 生态最硬的护城河，可包装成"线上 Agent 排障训练营"或"Agent 评估体系课"，客单价可对标 SRE 培训。

### 2. OpenAI Agents SDK：默认开启的"开箱可观测"

**架构原理**：OpenAI Agents SDK（Responses API 之上的高层运行时）把 **tracing 当一等公民**——官方文档明示"built-in, enabled by default in the normal server-side SDK path"。它把 agent 生命周期拆成几类语义 span：`generation`（模型调用）、`tool`（工具调用）、`handoff`（智能体交接）、`guardrail`（输入/输出护栏）。一次多智能体跑完，你在面板里能看到完整交接链：谁交给了谁、交的时候传了什么、护栏拦没拦。

**代码示例**：
```python
from agents import Agent, Runner, trace

researcher = Agent(name="研究员", tools=[search_tool])
writer = Agent(name="撰稿人", handoffs=[researcher])
# tracing 默认开；可显式加 span 做业务埋点
with trace("财报分析工作流"):
    result = Runner.run_sync(writer, "分析Q2财报")
```

**优缺点**：优点是 **零配置默认开**，handoff 这种多智能体最难调试的环节被一等公民化；缺点是后端强绑定 OpenAI 面板，想接自家 Jaeger/Tempo 需要写自定义 `processor`，且 trace 数据同样有出境问题。语义 span 是 OpenAI 自己定义的，与 OTel GenAI 约定并不完全对齐。

**变现评估**：适合做"OpenAI 原生 Agent 实战课"，门槛低、官方背书强，但深度有限（生态单一），适合引流入门营。

### 3. AutoGen 0.4 / AG2：OpenTelemetry 原生的"事件流"派

**架构原理**：AutoGen 0.4 完全重写为 **事件驱动运行时**——agent 之间不直接互调，而是通过消息总线发事件。可观测性也因此天然 OTel 化：内置 `enable_telemetry` 把 runtime 的 actor 生命周期、消息收发都打成 OTel span，trace_provider 可直接换成 `opentelemetry.trace`，后端完全开放。调试靠的是 **事件流重放**：把一次会话的事件序列存下来，离线逐条回放，定位"是哪个 actor 在哪条消息上跑飞了"。

**代码示例**：
```python
from autogen_core import trace_provider
import opentelemetry.trace as otel_trace
trace_provider.set_provider(otel_trace.get_tracer_provider())  # 接任意 OTel 后端
runtime.start()  # actor 消息、工具调用自动成 span
```

**优缺点**：优点是 **零锁定**——同一份 trace 既能进 Phoenix 看可视化，又能进 Langfuse 做评估，还能进企业现有 Jaeger/Grafana 与微服务链路打通；缺点是语义层较"裸"，OTel GenAI 约定尚未覆盖 AutoGen 的 actor 模型全部语义，自己拼可视化成本不低。

**变现评估**：适合做"OTel + Agent 可观测体系"中高阶营，受众是企业平台/SRE 团队，复购潜力高。

### 4. CrewAI：多后端灵活但 Replay 弱

**架构原理**：CrewAI 是"角色扮演"多智能体框架，底层用 LangChain 或 LiteLLM 调模型，因此可观测性走的是 **OpenInference + OTel 路线**——靠给底层模型库插桩来捕获。官方观测页一长串后端：Langfuse、Arize Phoenix、Portkey、Weave、Langtrace、AgentOps、OpenLIT……覆盖 15+ 平台。trace 语义是 `Crew → Task → Agent → Tool` 的清晰三层，但 replay/回放能力偏弱，更适合"事后看"而非"重跑验证"。

**代码示例**（接 Phoenix）：
```python
import phoenix as px
px.launch_app()  # 本地起 Phoenix
# CrewAI 经 OpenInference 自动插桩，crew.kickoff() 后即可在面板看三层 trace
result = crew.kickoff(inputs={"topic": "Q2 对账差异"})
```

**优缺点**：优点是 **后端自由度最高**，企业可挑自家栈；缺点是默认不开、需手动配 processor，新人常踩"配了不收 trace"的坑；且因为是"插桩底层模型库"，框架自身的编排逻辑（如任务委派）不一定成 span，调试编排 bug 时仍要回到日志。

**变现评估**：适合做"多智能体编排实战"营，强调角色设计而非排障。

### 5. Pydantic AI → Logfire：强类型 Span 的"工程派"

**架构原理**：Pydantic AI 把 **类型安全**贯彻到底——工具的入参出参、agent 的输出 schema 全是 Pydantic 模型，可观测性也因此强类型化：接 Logfire（同团队出品，OTel 原生）后，每个 span 携带结构化字段，trace 查询能直接按字段过滤（如 `output.status=='error'`）。它不像 LangSmith 那样大而全，但胜在"trace 字段即 schema"，适合对数据规整度要求高的金融/数据团队。

**代码示例**：
```python
import logfire
logfire.configure()  # agent 自动上报，工具参数/返回按 schema 结构化
result = await agent.run("生成对账报告", deps=ctx)
```

**优缺点**：优点是 **trace 与代码类型同源**，排查 schema 不匹配类 bug（上期"传参即失真"）极快；缺点是生态小，可视化/评估面板不如 LangSmith 丰富。

**变现评估**：适合做"类型安全 Agent 工程"小众精课，受众是 Python 后端工程师。

### 6. Semantic Kernel / Google ADK：企业云栈的 OTel 收口

**架构原理**：Semantic Kernel（微软）和 Google ADK 都面向企业生态，可观测性统一收口到 **OTel + GenAI semantic conventions + 云厂商 Trace 后端**（Azure Monitor / GCP Cloud Trace）。语义层覆盖函数调用、插件调用、内存操作，能与企业现有 APM 链路无缝并轨——这是它的核心卖点：agent trace 和微服务 trace 在同一个 Grafana 面板里。

**优缺点**：优点是 **企业合规与统一栈**，缺点是接入门槛偏高、本地快速调试体验不如 LangSmith/OpenAI 那般开箱即用。

**变现评估**：适合 ToB 售前/架构师认证方向，非大众训练营首选。

## 可观测架构图：传输协议与后端的解耦

```mermaid
flowchart TB
    subgraph FW["框架插桩层（一次埋点）"]
        L1[LangGraph/LangSmith]
        L2[OpenAI Agents SDK]
        L3[AutoGen 0.4]
        L4[CrewAI]
        L5[Pydantic AI]
        L6[SK / Google ADK]
    end
    subgraph TP["传输协议层（解耦点）"]
        P1[私有 Trace 树<br/>LangSmith run]
        P2[内置 span<br/>OpenAI 语义]
        P3[OpenTelemetry<br/>+ GenAI 约定]
    end
    subgraph BK["后端层（可替换）"]
        B1[LangSmith 云/自建]
        B2[OpenAI 面板]
        B3[Phoenix]
        B4[Langfuse]
        B5[Logfire]
        B6[Jaeger/Grafana/Cloud Trace]
    end
    L1 --> P1
    L2 --> P2
    L3 --> P3
    L4 --> P3
    L5 --> P3
    L6 --> P3
    P1 --> B1
    P2 --> B2
    P3 --> B3 & B4 & B5 & B6
    FW -. 默认开启?.-> TP
    TP -. 数据出境?.-> BK
```

关键洞察：**传输协议层（P3 = OTel）正在成为最大公约数**。一旦框架把 trace 打成 OTel span，后端就是可替换的商品——这正是 2026 年企业最看重的"不被锁定"能力。私有协议（P1/P2）胜在语义完整、开箱即用，但把数据主权一并交了出去。

## Trace 树嵌套：一次"对账"任务的可观测剖面

```mermaid
sequenceDiagram
    participant U as 用户
    participant O as 编排 Agent
    participant R as 研究 Agent
    participant T as 工具(账单API)
    participant TR as Trace 后端
    U->>O: 分析Q2对账差异
    Note over O,TR: root span 开始
    O->>R: handoff（交接 span）
    R->>T: 调账单API（tool span）
    T-->>R: 非预期 JSON ⚠️
    Note over TR: span 标记 error + 原始返回体
    R-->>O: 报错（generation span 带 retry）
    O->>TR: 上报完整 run 树
    Note over U,TR: 一分钟内定位：第2跳/工具/schema
```

上图把"工具返回非预期 JSON"这种典型事故，映射成可观测剖面：每个 span 都带 raw payload、错误标记和 token 计费。**能否看到 raw payload**，是区分"真可观测"和"伪可观测"的硬指标——OpenAI/LangSmith 默认留全量，CrewAI 经插桩有时只留摘要。

## 推荐方案：按场景选栈

| 场景 | 首选 | 理由 |
|---|---|---|
| 快速原型 / 教学 demo | **OpenAI Agents SDK** | 默认开 trace，零配置看 handoff 链 |
| 重度多智能体 + 线上排障 | **LangGraph + LangSmith** | run 树 + trace 转数据集做回归，闭环最强 |
| 企业合规 / 数据不出境 | **AutoGen 0.4 + Phoenix 自建** | OTel 原生，后端完全自主 |
| 多智能体编排灵活性优先 | **CrewAI + Langfuse** | 15+ 后端任选，角色设计友好 |
| 类型安全 / 金融数据 | **Pydantic AI + Logfire** | trace 字段即 schema，schema bug 一眼定位 |
| 企业云统一 APM | **Semantic Kernel / Google ADK** | 与微服务链路同面板 |

一句话选型：**追求"开箱玻璃盒"选私有派，追求"不被锁定"选 OTel 派，追求"事故转资产"非 LangSmith 莫属。**

## 参考来源

1. [Tracing — OpenAI Agents SDK 官方文档](https://openai.github.io/openai-agents-python/tracing/) — 内置 tracing 默认开启、generation/tool/handoff/guardrail span 语义
2. [Open Telemetry — AutoGen 官方文档](https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/framework/telemetry.html) — 事件驱动运行时 + trace_provider 接任意 OTel 后端
3. [Observability for CrewAI with Langfuse Integration](https://langfuse.com/integrations/frameworks/crewai) — CrewAI 多后端观测路线与 OpenInference 插桩
4. [AutoGen Tracing — Arize Phoenix](https://arize.com/docs/phoenix/integrations/python/autogen/autogen-tracing) — OTel 原生 + Phoenix 可视化实践
5. [Agent Observability in 2026: Langfuse, Phoenix, OpenTelemetry](https://agentmarketcap.ai/blog/2026/04/11/agent-observability-distributed-tracing-langfuse-arize-opentelemetry-2026) — 2026 年可观测三栈路线对比（Phoenix OTel-native / Langfuse LLM-specific）

---

*本期为"AI 智能体实战分析"系列第 1 轮·框架可观测横评。下期将转向自主智能体（Autonomous Agent）实战案例与工具链。*

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)