智能体在生产环境中可能反复调用错误工具却不触发可用性告警。在8月4日发布的一篇CNCF博文中，StackGen首席工程师Sabith K Soopy介绍了会话追踪和成本控制如何帮助团队排查反复调用工具以及意外开销的问题。博文基于数月生产环境运行智能体的实践，指出最难的部分并非构建智能体，而是当它们出错时弄清楚发生了什么。

StackGen使用Langfuse采集嵌套会话追踪数据。每一次大语言模型调用、工具执行和子智能体委派都会被记录为独立的span，并附带执行延迟和token成本。将子span嵌套在父trace之下，可在复杂的多智能体工作流中保留完整委派链。博文建议采用异步批量导出器，让span在内存中排队并定期刷新，确保遥测后端临时故障时只丢弃追踪数据，而不阻塞正在运行的智能体。

成本控制方面，博文建议在执行开始前强制执行严格的迭代上限和单工具调用次数限制，并配合执行前检查阻止重复的相同工具请求。团队还需将统计监控与重复调用拦截结合，把会话成本与每个智能体的滚动平均值比较，以发现模型路由错误、工具幻觉以及多轮交互中上下文无限膨胀等隐蔽异常。对于快速运行的并行智能体，仅靠被动触发警报往往为时已晚。

对于事后复盘，博文建议将工具调用、治理决策和内存操作写入仅支持追加且可搜索的日志，并在存储前对凭据和个人身份信息进行脱敏。StackGen还提供命令行诊断工具，可在单次执行中验证模型API访问、向量数据库可达性、待处理审批、内存计数、追踪后端连接及集成健康状况。已完成的追踪会经过自动化分析器处理，标记执行时长、工具故障、重试次数和token效率问题供人工审查。

博文建议将有限的运维指标导出到Prometheus，并警示将动态会话ID放入指标标签会产生高基数时间序列，可能导致指标服务器崩溃，细粒度会话上下文应严格保留在追踪或结构化日志中。OpenTelemetry的生成式AI语义约定定义了模型操作、token消耗和工具调用的标准化属性，LangSmith可将生产环境异常追踪转换为测试数据集，开源的Arize Phoenix则结合了原生支持OpenTelemetry的追踪与自托管LLM评审器评估能力。