Agent 可观测性怎么做：追踪任务结果，同时避免记录敏感内容

模型生成完成，工具调用成功，业务任务完成是三件事。模型完成只代表生成结束；工具返回成功可能只代表受理；业务完成需要权威系统状态或用户确认。把它们都写成 success，会让报表误报质量。

例如工单工具返回对象编号，说明工单创建；客户问题是否解决要看后续处理。追踪系统应保留这层差异，避免把 API 成功率当作业务解决率。

任务标识连接整个过程，每次尝试和调用另有标识，必要时关联外部业务对象。标识用于追踪，不能替代访问授权。

这些是本文自定义字段，不是 OpenTelemetry 的完整标准。真正接入时按当前 SDK 和语义约定核对字段、稳定性及支持范围。

OpenTelemetry 的 GenAI 介绍展示模型与工具的调用层级，以及模型、token、时长等遥测。它也说明完整输入与参数可能包含敏感信息；旧语义约定页面现已指向新的官方仓库，接入时不能只照搬旧页面。

在请求入口创建追踪上下文，传到检索、模型与工具封装，外部调用保留关联标识和结果。后台作业、回调或恢复任务也应能与原任务关联，但每次恢复记录新的尝试与当前配置。

注意并行调用的总耗时不能简单相加当作用户等待时间。分别观察墙钟时间、各阶段时间和累计资源用量，才能判断加并行是否真的改善体验。

默认不保存完整消息与工具参数。确有诊断需要时，限定任务、字段和访问人员，并设置明确保留方式。采集器、导出器、后台、下载和备份都要检查，不能只在日志显示页面遮挡。

对凭证采用不采集或删除策略；对身份信息按必要性做脱敏。部分敏感信息藏在正文或工具返回中，单纯删除 Authorization 头不够。脱敏规则也需要测试，防止遗漏和误删诊断所需结构。

跨租户记录按当前权限隔离。不要让普通业务人员因为能打开追踪界面，就看到其他客户的资料。调试权限和业务权限分别约定，导出的报告同样受限制。

教学工单任务耗时 40 秒，记录显示检索 2 秒、两次模型调用共 8 秒、工单接口尝试与等待约 28 秒，其余是收尾。这个证据提示优先查看工具与重试，而非只压缩提示词。数字仅用于演练。

继续检查接口是否已经受理、是否发生重复尝试，以及客户端超时与总任务预算是否一致。如果记录只有最终错误字符串，补上阶段与尝试信息，才能解释等待从哪里来。

对于错误回答，查看实际证据标识、对象和版本；需要正文核对时通过受控内容入口读取。避免为每次普通诊断打开全部内容采集。

阈值与通知频率由业务需求决定。同一故障聚合通知，并给出任务范围、当前状态和处理入口。没有行动对象的告警容易变成噪音。

统计时保留样本数与任务类别。少量短查询与少量长分析混合，平均时延可能掩盖两者差异；按相同任务组查看分布更容易行动。指标标签采用有限类别，把具体任务标识放在受控追踪记录中，避免大量唯一标识造成监控开销，也避免把客户名称写进长期指标标签。

先为一条重要任务连接入口、检索、模型、工具和业务结果，验证能解释一次失败与一次超时。确认记录不含凭证和无权内容，再扩展覆盖。

本文适合企业 Agent 与多步工作流。可观测性支持诊断，但不能替代业务正确性检查，也不需要记录模型私密推理过程。保留政策与访问范围遵循企业既有要求。