<!-- title: 盲飞即烧钱：多智能体可观测深拆 -->

# 盲飞即烧钱：多智能体可观测深拆

## 概述

多智能体系统正在以远超配套监控工具的速度被部署上线。AgentMarketCap 与 LangChain《State of Agent Engineering》的联合数据指出：企业级多智能体架构采用率在 2024→2025 一年内从 23% 跃升到 72%，49% 的企业同时在生产环境跑 10 个以上智能体——但只有 37.3% 的团队对其跑在线评测。这意味着六成以上的多智能体部署在"盲飞"。

盲飞的代价是双重的。一是**钱**：一个五步的保险理赔工作流，单次执行成本从第一步 $0.012 滚雪球到第五步 $0.203，每天跑一万次就是 $2,030，十个这类工作流年烧 $60 万，其中 67% 的输入 token 是模型在反复重读上下文。二是**锅**：传统可观测性假设确定性——记一条日志、重放请求、复现 bug——而多智能体每一步的提示词、工具返回、推理路径都非确定，没有结构化 trace，"哪个 agent 改坏了最终结果"根本无从归因。本文拆解多智能体可观测的四个层面——Token 经济学、成本归因、追踪栈选型、故障归因，给出可落地的工程方案。

## 多智能体可观测栈横向对比

| 工具/平台 | 版本/规模 | 核心架构 | 上手难度 | 变现潜力 | 适用场景 |
|-----------|-----------|----------|----------|----------|----------|
| **LangFuse** | v4（2026.03）/ 19k★ / MIT | 观察优先（observations-first）扁平表 | 低，一行 SDK 接入 | 高，自托管零授权费 | 多智能体 trace 规模化、LLM-as-judge 评测 |
| **Arize Phoenix** | OTel 原生 / OpenInference | 建于 OpenTelemetry 之上，可移植导出 | 中，需懂 OTel | 高，可接既有监控栈 | 已有 OTel 基础设施、跨后端导出 |
| **LangSmith** | 闭源 SaaS / LangChain 官方 | 与 LangGraph 深度绑定 | 最低，LangChain 生态零配置 | 中，按席位计费 | LangChain/LangGraph 全家桶 |
| **AgentOps** | 轻量 / 会话回放 | 录制式回放 + 计费 | 低 | 中 | 快速原型、成本复盘 |
| **Helicone** | 开源代理网关 | 请求代理层拦截 | 低 | 中 | 网关级 token 统计、限流 |
| **Braintrust** | 评测优先 | 实验+评测+追踪一体 | 中 | 高 | 持续评测、Prompt 实验 |

> 注：94% 的生产级 agent 团队都装了"某种"可观测，但"有日志"与"有完整工具调用 trace"之间的差距，恰恰决定了能不能定位故障。

## 深度分析

### 一、复利烧钱：五步从 $0.012 滚到 $0.203

工程师估算 LLM 成本时，通常按"单次调用 2000 token、几分钱"线性外推，这在多智能体里是致命的失真。TuringPulse 给出的一个真实生产级五步保险理赔工作流：检索保单 → 分析覆盖 → 查知识库 → 起草结论 → 合规校验，token 是这样滚的：

| 步骤 | 对话历史 | 工具结果 | 输入总计 | 输出 | 累计成本 |
|------|----------|----------|----------|------|----------|
| 1 检索 | 0 | 0 | 3,000 | 400 | $0.012 |
| 3 查KB | 5,800 | 4,500 | 13,300 | 500 | $0.078 |
| 5 合规 | 13,800 | 7,200 | 24,000 | 800 | $0.203 |

关键反直觉点：**67% 的输入 token 是"上下文"，不是"生成"**。系统提示词五个步骤里重复投喂了 9000 token（占 13%），而到第五步，模型要先付费重读 13,800 token 的历史对话才生成第一个新 token。这意味着优化"最后一步"几乎没有杠杆——真正的杠杆在前三步放进去什么。变现角度：这是一个可以直接包装成"多智能体成本优化训练营"的硬核选题，单条 context 压缩（3000→400 token 的摘要）一年就能省 $9.5 万。

### 二、四层拆账：单一"input token"桶的谎言

把所有输入塞进一个 `input_tokens` 字段，是成本看板永远对不上供应商账单的头号原因。DigitalApplied 给出的生产级实践是每个 span 记四列 usage：`prompt_tokens`（系统+用户+few-shot）、`tool_tokens`（工具 schema + 工具返回）、`memory_tokens`（RAG 片段+对话史）、`response_tokens`（含隐藏 thinking token）。

为什么要分？因为四层各有不同的优化杠杆和价格结构。响应层单价是输入层的 4-5 倍，且受 effort/reasoning 控制影响最大；工具层会随工具数量和返回冗余度静默膨胀——常见病灶是工具返回完整 API 响应（含元数据、分页、未用字段）而非过滤结果。内存层随会话长度增长，可单独调 RAG 预算而不动核心提示词。**供应商只返回合并的 input 计数，四层拆分必须在打包 prompt 之前、在 harness 层完成。** 实操中，大多数团队发现 3-5 个 span 就占掉 60-80% 的总 token 花销——找到这几个"耗子 span"就是优化的全部。

```python
# 每个 span 记四列 usage，在打包 prompt 之前拆分
def record_usage(span, prompt, tools, memory, response):
    span.set_attributes({
        "gen_ai.prompt_tokens":     count(prompt),
        "gen_ai.tool_tokens":       count(tools),    # schema + 结果
        "gen_ai.memory_tokens":     count(memory),   # RAG + 对话史
        "gen_ai.response_tokens":   count(response), # 含 thinking
        "gen_ai.cost.usd":          cost_of(prompt, tools, memory, response),
    })
```

### 三、归因三维：3% 的租户烧掉 60% 的 token

成本"平均值"是生产事故的温床。报告指出，按"客户平均成本"汇报会把长尾熨平——**3% 的租户消耗掉 60% 的 token**。没有百分位报表，定价团队就是在优化虚构。三条归因维度几乎覆盖所有业务问题：**per-user**（谁在账户内驱动消耗，用于席位定价和升级）、**per-task**（哪个产品界面烧钱，标记 `task_id`+`route` 如 `inbox-triage`/`report-gen`）、**per-tenant**（这个客户赚不赚钱，决定续约与止损）。

三个维度必须并行埋点，否则换个视角就要重埋。最常见的生产事故模式有三类：一是平均值掩盖长尾；二是**重试与工具调用循环未被计数**——agent 反复重试失败的工具调用，烧掉数百次 prompt-cached 读取，如果遥测只统计用户面向的那次请求，真实燃烧率对你完全不可见；三是免费层欠埋点——团队精细追踪付费用户，却把免费层流量当成一笔糊涂账，结果一个没设好闸门的免费层悄悄变成最大单项支出。变现提示：对外做 AI 交付的代理商，成本归因是**计费前置条件**而非优化项，做不好就做不了多租户产品。

### 四、观察优先：LangFuse v4 的架构重构

LangFuse（YC W23、MIT、19k★）在 2026 年 3 月发布 v4，架构变化直击多智能体痛点。旧模型把 trace 当作层级容器，单条观察（LLM 调用、工具执行、agent 步骤）嵌套在 trace 树里——普通工作负载没问题，但**单条 agent trace 可能有成百上千个操作**，层级遍历成了性能瓶颈。

v4 改成"观察优先"数据模型：每个 LLM 调用、工具执行、agent 步骤都是统一 observations 表里的一行，无需遍历 trace 树即可查询。实测影响：图表加载大幅下降，新的 Observations API v2 / Metrics API v2 通过"选择性字段取回 + 游标分页"消除昂贵 join，号称**比旧版快一个数量级**；observation 级 LLM-as-judge 评测现在几秒内完成。agent 调试的真正瓶颈从来不是"怎么抓 trace"，而是"在百万次工具调用里怎么找到那个引起失败的观察"——扁平表正是为这个而生。定价上，Hobby 层（5 万单元/月、30 天留存）免费且号称比多数竞品慷慨 10 倍，溢出 $8/10 万单元，且 token 追踪不消耗计费单元。MIT 授权意味着自托管零授权费、零厂商锁定——这是面向训练营和企业内训的最强卖点。

### 五、OTel 原住民：Arize Phoenix 的可移植性

LangFuse 是"LLM 专用可观测 + 后加 OTel 导出"，Arize Phoenix 则**从第一天就建在 OpenTelemetry 之上**，核心仪表层用 OpenInference（Arize 开源的 OTel 扩展，定义 LLM 专用语义）。关键差异是可移植性：Phoenix 抓的 trace 数据留在你的栈里，可导出到任何 OTel 兼容后端——Jaeger、Tempo、Datadog 或既有可观测设施。

2026 年的框架支持面已经很广：OpenAI Agents SDK、Claude Agent SDK、LangGraph、Vercel AI SDK、Mastra、CrewAI、LlamaIndex、DSPy。每个集成产出结构化 trace（模型调用、检索步骤、工具使用、推理链、自定义逻辑），可视化 trace 视图逐步呈现多智能体交互，专治复杂多智能体工作流的调试。**Phoenix 的差异化护城河是"不另起一套并行监控栈"**：如果你的团队已经为传统服务投了 OTel 基础设施，Phoenix 让 AI agent 追踪并入同一后端，而不是再养一套。这对有遗留监控资产的中大型企业是决定性优势，也是它在训练营话术里区别于 LangFuse 的核心定位。

### 六、归一之线：OpenTelemetry GenAI 语义约定

多智能体可观测最大的混乱不是"没有工具"，而是"每个工具的 trace 格式都不一样"——LangSmith 一套、LangFuse 一套、各家 SDK 一套，trace 一旦想跨平台流动就要手工转换。OpenTelemetry 在 2026 年 5 月从 CNCF 毕业，其 GenAI 语义约定（semantic-conventions-genai）随之稳定，正在成为 agent trace 的事实线协议（wire format）。

这套约定把 GenAI span 分四类：**LLM 调用 span**（prompt、completion、token 计数、模型名、温度）、**Tool 调用 span**（工具名、入参、返回、是否成功）、**Agent/Workflow span**（agent 标识、步骤、handoff）、**Retriever span**（检索的文档、相似度）。标准化 span 命名和属性后，厂商锁定被消除——同一段 instrumentation，今天导到 Phoenix，明天导到 LangFuse，后天导到 Datadog，trace 结构一致。这直接改写了选型逻辑：**埋点一次，后端任意切换**，企业不必再为"可观测锁定"焦虑。

```python
# OTel GenAI 语义约定：厂商中立的 span
from opentelemetry.semconv._incubating.attributes import gen_ai_attributes as GenAi

with tracer.start_as_current_span("agent.step") as span:
    span.set_attribute(GenAi.GEN_AI_OPERATION_NAME, "chat")
    span.set_attribute(GenAi.GEN_AI_SYSTEM, "openai")
    span.set_attribute(GenAi.GEN_AI_REQUEST_MODEL, "gpt-4o")
    span.set_attribute("gen_ai.agent.id", "claim-reviewer-3")
    span.set_attribute("gen_ai.tool.name", "query_policy")
    # 后端可以是 Phoenix / LangFuse / Jaeger，trace 结构一致
```

### 七、谁的锅：多智能体故障归因

多智能体最难的问题不是"任务失败了"，而是"**哪个 agent 改坏了**"。ICML 2025 的 spotlight 论文《Which Agent Causes Task Failure?》（ag2ai/Agents_Failure_Attribution）专门攻这个问题——在 agent 链里，一个上游 agent 给了看似合理实则错误的中间结果，下游 agent 据此产出最终错误答案，传统评估只看输入输出两头，根本定位不到责任节点。

ICLR 2026 的多篇多智能体失败研究进一步揭示：级联错误（cascading errors）是多智能体特有失效模式——错误在 handoff 间被放大而非纠正，且高度非确定，同一输入不同次运行可能在不同节点崩。可观测侧的解法是**逐 span 留存中间产物**（提示词、工具入参出参、LLM 原始输出），并支持 trace 回放（replay）。Arize Phoenix 的逐步可视化、LangFuse v4 的 observation 级查询、AgentOps 的会话录制都是为这一步服务。没有这一层，agent 团队的平均故障修复时间（MTTR）会因"无法复现"而暴涨——而带结构化 trace + AI 诊断的团队，受控实验里 60% 的 bug 可自动定位，MTTR 相对纯日志基线最多降 90%。

### 八、在线评测缺口：94% 装了观测，37% 在跑评测

最反讽的数据组合：94% 的生产 agent 团队有"某种"可观测，但只有 37.3% 跑在线生产评测。装 trace 不等于跑评测——trace 告诉你"发生了什么"，评测告诉你"对不对"。多智能体尤其需要在线评测，因为非确定性让离线基准（benchmark）迅速失效：模型一升级、提示词一改、工具一换，离线分数就和线上表现脱节。

LLM 可观测市场本身在狂奔：2025 年 $1.97B，预计 36.5% CAGR 到 2029 年 $6.8B。结构化观测 + AI 驱动诊断能自动解决 60% 的 bug（受控实验），完整 trace + AI 事件管理最多把 MTTR 降 90%。但行业正在从"反应式日志解析"转向"主动结构化追踪"——把工具调用、检索步骤、护栏检查都打成带语义类型的 observation，给实时洞察。落地建议：**评测和 trace 同源埋点**，用 observation 级 LLM-as-judge 对每条中间产物打分，把"盲飞"变成"实时仪表盘"。

## 多智能体可观测参考架构

```mermaid
flowchart TB
    subgraph Agent["多智能体运行时"]
        A1[Agent 1 规划] --> A2[Agent 2 检索]
        A2 --> A3[Agent 3 工具调用]
        A3 --> A4[Agent 4 起草]
        A4 --> A5[Agent 5 校验]
    end

    subgraph Harness["Harness 层:埋点拆分"]
        T1[四层token拆分<br/>prompt/tool/memory/response]
        T2[三维归因<br/>user/task/tenant]
        T3[中间产物留存<br/>提示词/工具IO/原始输出]
        T1 & T2 & T3 --> Spans[结构化 Span]
    end

    Agent -.采集.-> Harness

    subgraph Wire["线协议:OTel GenAI语义约定"]
        Spans --> GenAI[gen_ai.* 属性<br/>厂商中立]
    end

    GenAI --> B1[LangFuse v4<br/>observation扁平表]
    GenAI --> B2[Phoenix<br/>OTel原生/可移植]
    GenAI --> B3[Datadog/Jaeger<br/>既有栈]

    B1 & B2 --> Views[成本热力图<br/>token增长曲线<br/>Top-N耗子span]
    B1 & B2 --> Eval[在线评测<br/>observation级LLM-as-judge]
    B1 & B2 --> FA[故障归因<br/>trace回放/谁改坏的]

    Views -.触发.-> Kill[Kill-switch<br/>单租户预算熔断]
    Eval -.反馈.-> Opt[上下文压缩<br/>滑动窗口/分层记忆]

    style Wire fill:#e8f4f8,stroke:#2196f3
    style Kill fill:#ffebee,stroke:#f44336
```

## 推荐方案

**场景一：初创/原型（<50 万次调用/月）**——选 **AgentOps + Helicone**。AgentOps 的会话回放让两人在车库阶段就能复盘"哪一步跑偏"，Helicone 网关层做 token 统计和限流，零运维成本。重点先跑通四层 token 拆分，别等流量来了才补。

**场景二：多智能体规模化生产（首选）**——选 **LangFuse v4 自托管**。observations-first 扁平表专治"百万工具调用里找那个坏观察"，MIT 授权零授权费，Hobby 层免费且 token 不计费，observation 级 LLM-as-judge 几秒出分。最适合 10+ agent 并发、需要成本热力图和 Top-N 耗子 span 定位的团队。

**场景三：有遗留 OTel 监控的中大型企业**——选 **Arize Phoenix**。建在 OpenTelemetry 之上，用 OpenInference 仪表，trace 导到既有 Jaeger/Tempo/Datadog 后端，不另起一套并行监控栈。已支持 OpenAI Agents SDK / Claude Agent SDK / LangGraph 等主流框架。

**场景四：所有场景的埋点基线**——无论后端选谁，**埋点统一走 OpenTelemetry GenAI 语义约定**（`gen_ai.*` 属性）。埋一次，后端任意切换，彻底规避可观测厂商锁定，这是 2026 年选型逻辑的根本变化。

**跨场景铁律**：① 四层 token 拆分在打包 prompt 之前完成；② 三维归因（user/task/tenant）并行埋点，尤其是免费层；③ 重试与工具调用循环必须单独计数，否则真实燃烧率不可见；④ 设 per-tenant kill-switch，3% 租户烧 60% token 时不至于烧穿季度毛利；⑤ 在线评测与 trace 同源，把"盲飞"变"仪表盘"。

## 参考来源

1. [Agent Observability in 2026: LangFuse, Arize Phoenix, OpenTelemetry — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/11/agent-observability-distributed-tracing-langfuse-arize-opentelemetry-2026) — 72%采用率/37.3%在线评测、$1.97B→$6.8B市场、LangFuse v4与Phoenix架构、60%/90% MTTR数据
2. [Token Economics: Profiling and Reducing LLM Costs in Multi-Agent Systems — TuringPulse](https://turingpulse.ai/blog/token-economics-llm-cost) — 五步工作流$0.012→$0.203复利表、67%上下文占比、上下文压缩年省$9.5万
3. [LLM Agent Cost Attribution: Complete Production 2026 Guide — DigitalApplied](https://www.digitalapplied.com/blog/llm-agent-cost-attribution-guide-production-2026) — 四层token记账、三维归因、3%租户烧60%、重试循环未计数事故模式
4. [What ICLR 2026 Taught Us About Multi-Agent Failures — LLMs Research](https://llmsresearch.substack.com/p/what-iclr-2026-taught-us-about-multi) — 级联错误、handoff间放大、非确定性失效模式
5. [Which Agent Causes Task Failure? — ag2ai/Agents_Failure_Attribution (ICML 2025 Spotlight)](https://github.com/ag2ai/Agents_Failure_Attribution) — 多智能体故障责任节点归因方法与实现
6. [OpenTelemetry GenAI Semantic Conventions — GitHub open-telemetry](https://github.com/open-telemetry/semantic-conventions-genai) — gen_ai.* span/metric/event 语义约定，2026年成事实线协议

> [!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)