多智能体系统正在以远超配套监控工具的速度被部署上线。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"之间的差距，恰恰决定了能不能定位故障。
工程师估算 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_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"就是优化的全部。
# 每个 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。没有百分位报表，定价团队就是在优化虚构。三条归因维度几乎覆盖所有业务问题：per-user（谁在账户内驱动消耗，用于席位定价和升级）、per-task（哪个产品界面烧钱，标记 task_id+route 如 inbox-triage/report-gen）、per-tenant（这个客户赚不赚钱，决定续约与止损）。
三个维度必须并行埋点，否则换个视角就要重埋。最常见的生产事故模式有三类：一是平均值掩盖长尾；二是重试与工具调用循环未被计数——agent 反复重试失败的工具调用，烧掉数百次 prompt-cached 读取，如果遥测只统计用户面向的那次请求，真实燃烧率对你完全不可见；三是免费层欠埋点——团队精细追踪付费用户，却把免费层流量当成一笔糊涂账，结果一个没设好闸门的免费层悄悄变成最大单项支出。变现提示：对外做 AI 交付的代理商，成本归因是计费前置条件而非优化项，做不好就做不了多租户产品。
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 授权意味着自托管零授权费、零厂商锁定——这是面向训练营和企业内训的最强卖点。
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 的核心定位。
多智能体可观测最大的混乱不是"没有工具"，而是"每个工具的 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 结构一致。这直接改写了选型逻辑：埋点一次，后端任意切换，企业不必再为"可观测锁定"焦虑。
# 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% 的生产 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 对每条中间产物打分，把"盲飞"变成"实时仪表盘"。
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 同源，把"盲飞"变"仪表盘"。
[!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 等场景全覆盖。