Agent 可观测性（Agent Observability）

传统 Web 服务的一次请求通常对应一条可预期的调用路径，而智能体在运行时自主决定调用哪些工具、调用多少次、是否委派给子智能体。同样的输入可能产生截然不同的执行路径，故障也更难复现。据 OpenTelemetry 官方博客的举例，一个智能体回答简单问题耗时 45 秒，可能源于模型本身、某次缓慢的工具调用，也可能是一个重试循环——没有遥测就只能逐一猜测。

此外，智能体的成本结构与传统应用不同：每一次模型调用都按令牌计费，而一次看似简单的任务背后可能是十几轮模型往返。没有按调用粒度的令牌计量，成本既无法归因，也无法预算。

智能体遥测的基本单元是跨度（span）。一次典型的智能体运行会产生一棵树：顶层是 invoke_agent 跨度，其下每个模型调用对应一个 chat 跨度，每次工具执行对应一个 execute_tool 跨度，子智能体交接则表现为嵌套的 invoke_agent 节点。每个跨度携带耗时、令牌数与错误状态。

有了这棵树，「45 秒的回答慢在哪」就有结构性答案：展开树即可看到时间花在哪一层。结构化追踪还让常见故障模式可以被自动检测——同一工具被反复以相同参数调用往往意味着智能体卡死在循环里；令牌用量相对历史基线异常飙升可能意味着提示词膨胀；工具错误沿子智能体链路传播则形成错误级联。

语义约定解决的问题是命名：每个可观测性厂商都曾为同一事实发明自己的字段名——调了哪个模型、用了多少令牌、温度是多少——导致仪表盘、告警与成本报表都要按厂商重建。OpenTelemetry 的 GenAI 语义约定把这些名字标准化：chat 调用的跨度携带 gen_ai.operation.name、gen_ai.provider.name、gen_ai.request.model、gen_ai.usage.input_tokens 等属性；工具执行与智能体调用有各自的操作名。

据官方仓库信息，该约定目前处于 Development 状态，尚未稳定，属性名在版本间有过更名（如提供方属性与令牌用量键），内容记录也从事件迁移到跨度属性。实践上建议通过跟踪规范演进的插桩库来产出遥测，而不是凭记忆手写属性名；升级插桩库前应查阅变更记录，避免仪表盘因属性改名而失效。

默认情况下，GenAI 遥测不包含提示词内容与工具参数，只记录模型名、令牌数、耗时等元数据。这是刻意的隐私设计：提示词中往往含有用户数据与业务机密。开启内容捕获后，系统指令、输入输出消息、工具模式与工具结果会以结构化属性形式写入跨度，对调试对话质量很有价值，但也意味着把敏感内容送进了遥测管道。

工程上的通行做法是分级：开发环境开启全量捕获便于排障；生产环境默认关闭，或仅在抽样与脱敏后开启。选择后端时也应确认其访问控制能力，因为开启内容捕获的遥测本质上是一份完整的对话记录。

AI 工作负载的遥测体量远超传统服务：每次模型调用都产生令牌级指标、消息事件与嵌套工具跨度，有工程实践总结指出体量可达传统服务的 10 至 50 倍。存储成本随追踪深度上升，全量保留既不经济也常常没必要。

务实的选择是对信号分级：令牌用量与时延是保底信号，几乎不占空间却支撑成本与性能两类核心报表；工具输入输出与模型参数能显著提升排障深度，但应配合采样；完整对话内容则按需开启。另一个常被忽略的事实是，语义约定标准化的是「一次模型调用长什么样」，并不规定「一次智能体运行的好追踪长什么样」——采样、脱敏与评估分数的呈现仍需团队自行设计。

GenAI 语义约定仍处 Development 状态，智能体框架、工具与 MCP 相关的跨度类型还在快速演进；评估分数与智能体轨迹如何进入标准化遥测尚无定论。可预期的是，随着主流编码智能体与智能体框架原生导出 OpenTelemetry 遥测，智能体可观测性将逐步从可选实践变成生产部署的默认组成部分。后续规范演进动态将持续跟进。