面向多 Agent 协作的可观测性工作台：执行轨迹追踪与成本归因的工程实现

多 Agent 协作正成为复杂任务自动化的主流架构，但随之而来的可观测性盲区却让运维团队措手不及。当用户请求在多个 Agent 之间流转，经过工具调用、LLM 推理、外部 API 交互的层层嵌套后，传统的单点日志已无法还原完整的执行路径。近期 Launch HN 上的 BitBoard 项目提出了一个关键洞察：将 AI 生成的分析转化为可追溯、可复现的持久化资产。这一理念恰好映射了多 Agent 可观测性建设的核心诉求 —— 不是简单记录日志，而是构建能够支撑调试、优化与成本治理的分析工作台。

核心挑战：跨 Agent 的上下文断层

多 Agent 系统的可观测性难点在于调用链的断裂。一个顶层请求可能触发编排器（Orchestrator）调度三个专业 Agent，每个 Agent 又可能发起多次工具调用和嵌套 LLM 请求。如果缺乏统一的追踪标识，这些分散的调用将形成信息孤岛。BitBoard 强调的 "可追溯" 特性在此场景下意味着：从用户输入到最终输出的完整决策树必须被结构化记录，包括 Agent 间的数据传递、工具返回结果以及每个节点的推理上下文。

更棘手的是成本归因。多 Agent 工作流的费用分散在多个模型调用、工具执行和重试逻辑中，传统的按 API Key 汇总已无法满足精细化运营需求。团队需要知道每个业务任务、每个 Agent 角色、甚至每个用户会话的具体消耗。

工程实现：基于 OpenTelemetry 的追踪架构

解决上述问题的工程方案是采用分布式追踪范式，将每个 Agent 调用建模为 Span，通过 Trace ID 贯穿整个工作流。

Trace 结构设计

根 Span 对应顶层用户请求，每个 Agent 调用作为子 Span，工具调用和 LLM 推理作为嵌套 Span。关键是在 Span 属性中注入以下元数据：

• agent.id：Agent 唯一标识
• agent.role：Agent 承担的角色（如 planner、executor、critic）
• task.id：业务任务标识，用于跨 Trace 聚合
• user.id：最终用户标识，支持按用户成本分析
• model.name 与 model.provider：模型信息
• tokens.input / tokens.output：Token 消耗
• cost.usd：实时计算的成本（基于模型定价）

上下文传播机制

Trace Context 必须在 Agent 间显式传递。对于异步消息队列（如 Celery、RabbitMQ），需将 Trace ID 和 Span ID 序列化到消息头；对于直接函数调用，通过参数透传。OpenTelemetry 的 Propagators 提供了标准化实现，确保跨进程边界上下文不丢失。

存储与查询优化

Trace 数据量巨大，建议采用分层存储：热数据（24-48 小时）存于 Jaeger/Tempo 支持实时查询，冷数据经聚合后存入数据仓库支持成本分析。BitBoard 类产品的价值在于将这种技术细节封装为可交互的仪表盘，让非技术团队也能洞察 Agent 行为。

成本归因：多维度追踪与实时预算

成本归因需要在消费点即时记录，而非事后解析日志。推荐在 LLM 客户端拦截层统一采集：

采集点设计

在每次模型调用返回时，立即提取 usage 字段中的 prompt_tokens 和 completion_tokens，结合模型单价计算 cost。对于流式响应，需在流结束时汇总 token 数。

归因维度

• 按 Agent：识别高消耗 Agent，优化提示词或切换模型
• 按任务类型：对比不同业务场景的成本基线
• 按用户 / 团队：支持内部计费与配额管理
• 按工作流阶段：定位 planning、execution、verification 各阶段的消耗占比

实时预算告警

建立动态基线：计算过去 7 天同类型任务的平均成本，当单次调用超出基线 20% 时触发告警；当用户会话累计成本超过阈值（如 $5）时中断并人工审核。

性能瓶颈定位：从延迟热力图到异常检测

性能分析需关注三个层面：

延迟分解

在 Trace 视图中标注每个 Span 的耗时，识别长尾请求。常见瓶颈包括：工具调用超时（建议设置 30s 上限）、LLM 首 token 延迟（监控 TTFT）、以及 Agent 间同步等待。

Token 效率分析

监控 input/output 比例，异常高的 input 可能提示提示词膨胀，异常高的 output 可能提示模型生成冗余。建立每千 token 产出的业务价值指标（如处理的任务数）。

异常模式检测

利用 Trace 结构识别异常模式：循环调用（同一 Agent 被重复调用超过 5 次）、级联失败（工具错误导致多个 Agent 重试）、以及决策树过度展开（单个任务触发超过 20 个 Span）。

可落地参数清单

基于上述分析，以下是可直接实施的参数配置：

结语

多 Agent 可观测性不是日志系统的简单扩展，而是需要重新设计追踪语义、成本模型和性能指标的工程体系。BitBoard 类产品展示了将技术数据转化为业务洞察的可能性 —— 当执行轨迹、成本归因和性能指标被结构化呈现，团队才能真正掌控复杂 Agent 系统的运行状态。上述参数清单提供了可立即实施的起点，但真正的价值在于持续迭代：根据实际运行数据调整阈值，根据业务变化优化归因维度，最终构建适应自身场景的 Agent 可观测性工作台。

资料来源

• BitBoard 产品官网: https://bitboard.work
• OpenTelemetry for AI Agents: Observability, Tracing 技术文档
• AI Agent Cost Attribution: Tracking LLM Spend by Team and Project 工程实践

ai-systems