可观测性实践：追踪、日志与成本核算

一句话定义

多智能体的可观测性把每次运行记录为一棵 trace 树（运行 → 步骤 → LLM/工具调用的 span 层级），配合结构化日志与成本核算，回答四个运维问题：这次运行做了什么、每个环节花了多少 token 与钱、失败发生在哪条边、哪里存在循环浪费。

直观类比

飞机黑匣子 + 财务账本：出事后能逐帧回放每个动作（trace），同时每一笔油钱都记在账上（成本核算）。没有黑匣子的航空公司无法做事故调查，没有账本的系统无法做成本优化。

为什么重要

多智能体的失败与浪费大多发生在「看不见的地方」：僵尸分支在后台烧 token（kp-019 取消未传播）、两个智能体暗中循环（kp-020）、某条交接边持续产出低质量包（kp-012）。没有 trace 树，kp-023 的排错工作流无从执行——「先有观测，后有优化」是多智能体运维的第一顺序。

前置知识

kp-024（评估产出质量数字——可观测产出过程数据，二者互补）；kp-018（检查点——trace 与快照配合支撑回放）。

核心概念

• Trace（轨迹）：一次完整运行的结构化记录；
• Span（跨度）：树上的一个计时区间——运行级、智能体级、步骤级、单次 LLM 调用级、工具调用级；
• 关联字段：thread_id（会话）、run_id（本次运行）、parent_span（父子关系）——跨智能体串联的钥匙；
• 结构化日志：每次 LLM 调用记录输入摘要、输出摘要、模型、token 数、延迟、费用；
• 成本核算（Cost Accounting）：按运行/按智能体/按任务三视角的 token 与费用归集。

原理与机制

埋点层次：最小可用配置是「每次 LLM 调用 + 每次工具调用」两条埋点，配合框架自动插桩（主流编排框架原生导出 trace）；进阶配置加上黑板读写事件（kp-013 的事件日志天然是观测数据源）。四个看板指标：(1) 成本分布——token 按智能体/按步骤的直方图，一眼找出吞钱大户；(2) 循环检测——对 prompt 做相似度聚类，同一 run 内高度相似的调用簇即循环嫌疑（直接对应 kp-020 循环失败的检测信号）；(3) 失败热图——按图的节点/边统计失败率，暴露系统性弱边（哪条交接边最常出问题）；(4) 延迟瀑布——关键路径的可视化，配合 kp-019 的 P95 分析并行收益。工具生态（以名称索引，均可在其文档站检索）：LangSmith、Langfuse、Arize Phoenix、Weights & Biases Weave 等均提供 trace 树与成本看板；OpenTelemetry 的 GenAI 语义约定正在统一埋点字段，选型时优先支持该约定的方案以避免锁定。存档策略：trace 与检查点同寿命保存（kp-018 的重放依赖），生产系统按合规要求脱敏后留存。

图示

run #a1b2 (报告任务, 总成本 ¥3.4, 12m41s)
├─ span: planner ×3 (0.6 万 tok)          ─┐
├─ span: worker-retrieval ×5 (4.1 万 tok)  │ 成本分布: 检索工人占 62% ← 优化首选
├─ span: worker-analysis ×2 (1.8 万 tok)   │
│   └─ LLM call ×9 (相似度聚类: 6/9 高相似) ┘ ← 循环嫌疑: 分析智能体在原地打转
├─ span: reviewer ×1 (0.4 万 tok)
└─ 失败热图(近30天): planner→worker 边失败率 2%, worker→reviewer 边 11% ← 弱边

实例或案例

月度运维例会看板：成本分布显示夜间批处理任务中检索工人平均每次运行 8 万 token，是白天的 3 倍；循环检测聚类发现其中 40% 的调用 prompt 相似度超过 0.95——定位为某类查询的重试风暴（kp-022 的重试无变化反模式）；失败热图显示 worker→reviewer 边失败率 11%，抽 trace 发现该边的交接包长期缺「验收标准」字段。三个看板各抓出一个问题——这正是可观测性的日常用法：不看感觉，看数据。

公式或模型

成本归集：Cost(run) = Σᵢ tokensᵢ × price(modelᵢ)，按 span 属性聚合出 Cost(agent)、Cost(task)；浪费率 W = 1 - 有效产出 token / 总 token，其中「有效」以进入最终交付的产出近似。循环检测的形式化：对同一 run 内的 LLM 调用 prompt 计算 embedding 相似度，簇内相似度 > θ（如 0.95）且次数 > n（如 3）即标记为循环嫌疑。

常见误区

• 误区一：等出事再补埋点。 没有历史 trace 的排错只能靠回忆；埋点是上线前置项；
• 误区二：只记日志不建视图。 原始日志的检索成本极高，trace 树与看板才是可用形态；
• 误区三：记录全量原文不脱敏。 trace 会包含用户数据与内部文档，留存策略必须含脱敏与期限。

与其他知识点的关系

trace 树的骨架就是 kp-017 的图结构；重放（kp-018）消费存档 trace 与检查点；kp-023 的每一步都以 trace 为工作介质；黑板事件日志（kp-013）是最便宜的观测源。

自测题

1. trace 树的 span 层级与三个关联字段？

要点：运行/智能体/步骤/LLM 调用/工具调用；thread_id、run_id、parent_span。

1. 四个看板指标各自抓哪类问题？

要点：成本分布→吞钱大户；循环检测→原地打转；失败热图→系统性弱边；延迟瀑布→并行长尾。

1. 循环检测的形式化判据？

要点：同 run 内 prompt 聚类，簇内相似度超阈值且重复次数超限即标记嫌疑。

延伸阅读

Langfuse 与 LangSmith 的文档展示了 trace 数据模型的典型实现；OpenTelemetry GenAI 语义约定是跨工具统一的埋点参考。