智能体可以反复调用错误的工具但不会触发可用性告警。
在 8 月 4 日发布的一篇 CNCF 博文中，StackGen 首席工程师 Sabith K Soopy 介绍了会话追踪和成本控制如何帮助团队排查反复调用工具以及意外开销的问题。
该博文基于数月在生产环境运行智能体的实践经验，指出：“最难的部分并不是构建智能体，而是当它们出错时，弄清楚到底发生了什么。”标准的应用监控只能判断服务是否正常响应，却无法解释自主工作流为何陷入循环、调用无效接口或是声称已完成实际跳过的任务。
StackGen 使用 Langfuse 采集嵌套会话追踪数据。每一次大语言模型调用、工具执行和子智能体委派都会被记录为一个独立的 span，并附带执行延迟和 token 成本。将子 span 嵌套在父 trace 之下，可以在复杂的多智能体工作流中保留完整的委派链。博文建议采用异步批量导出器，让 span 在内存中排队并定期刷新，确保遥测后端发生临时故障时只会丢弃追踪数据，而不会阻塞正在运行的智能体。
成本控制是防止执行失控的主要运维保障。博文建议在执行开始前强制执行严格的迭代上限和单工具调用次数限制，并配合执行前检查，以阻止重复的相同工具请求。
阻止连续重复调用可以处理简单的重复调用场景，但团队还需将其与统计监控相结合。将会话成本与每个智能体的滚动平均值进行比较，可以发现相对隐蔽的异常，包括模型路由错误、工具幻觉以及多轮交互中上下文的无限膨胀。博文认为，对于快速运行的并行智能体而言，仅仅依靠被动触发警报往往为时已晚。
对于事后复盘，博文建议将工具调用、治理决策和内存操作写入仅支持追加且可搜索的日志中，并在存储前对凭据和个人身份信息（PII）进行脱敏处理。StackGen 还提供了一个命令行诊断工具，可在单次执行中验证模型 API 访问、向量数据库可达性、待处理的审批、内存计数、追踪后端连接以及集成健康状况。
已完成的追踪会经过自动化分析器处理，标记出执行时长、工具故障、重试次数和 token 效率问题，以供人工审查。博文建议将有限的运维指标（例如工具错误率和审批延迟直方图）导出到 Prometheus。文中警示，将动态会话 ID 放入指标标签会产生高基数时间序列，可能导致指标服务器崩溃，并指出细粒度的会话上下文应严格保留在追踪或结构化日志中。正如博文所言：“追踪用于调试，指标用于告警。”
其他配套工具为跨生产环境评估追踪数据提供了结构化路径。OpenTelemetry 的生成式 AI 语义约定定义了模型操作、token 消耗和工具调用的标准化属性，在不同遥测后端之间建立了一致的规范结构。追踪记录执行历史，而评估工具则验证输出质量。LangSmith 可将生产环境中的异常追踪转换为测试数据集，用于回归基准测试和质量监控。开源的 Arize Phoenix 将原生支持 OpenTelemetry 的追踪与自托管的 LLM 评审器评估能力和提示词实验相结合。OpenTelemetry 项目在一个单独的代码库中维护这些规范，涵盖客户端、服务器和模型上下文协议的 span，以此支持一致的多厂商可观测性。
查看英文原文：https://www.infoq.com/news/2026/09/observability-ai-agents/