北京
“最难的部分并不是构建智能体，而是当它们出错时，弄清楚到底发生了什么。”StackGen 首席工程师 Sabith K Soopy 在 8 月 4 日发布的一篇 CNCF 博文中这样写道。这句话点出了一个被很多团队忽略的现实：智能体可以反复调用错误的工具，却不会触发任何可用性告警。
这篇博文基于数月在生产环境运行智能体的实践经验。标准应用监控只能判断服务是否正常响应，却解释不了自主工作流为何陷入循环、调用无效接口，或是声称已完成实际跳过的任务。服务“活着”，不代表它做对了事。
把每一次调用都记成一条链路
StackGen 的做法是用 Langfuse 采集嵌套会话追踪数据。每一次大语言模型调用、工具执行和子智能体委派，都会被记录为一个独立的 span，并附带执行延迟和 token 成本。把子 span 嵌套在父 trace 之下，复杂的多智能体工作流里就能保留完整的委派链。
博文还建议采用异步批量导出器：让 span 先在内存中排队，再定期刷新。这样即便遥测后端发生临时故障，丢掉的也只是追踪数据，而不会阻塞正在运行的智能体。
成本是防止失控的主要抓手
成本控制被这篇博文视为防止执行失控的主要运维保障。具体做法包括：
- 在执行开始前强制执行严格的迭代上限
- 设置单工具调用次数限制
- 配合执行前检查，阻止重复的相同工具请求
阻止连续重复调用能处理简单的重复场景，但团队还需要把它和统计监控结合起来。把会话成本与每个智能体的滚动平均值做比较，可以发现相对隐蔽的异常，包括模型路由错误、工具幻觉，以及多轮交互中上下文的无限膨胀。博文的判断是：对于快速运行的并行智能体而言，仅仅依靠被动触发警报往往为时已晚。
追踪用于调试，指标用于告警
事后复盘方面，博文建议将工具调用、治理决策和内存操作写入仅支持追加且可搜索的日志中，并在存储前对凭据和个人身份信息（PII）进行脱敏处理。StackGen 还提供了一个命令行诊断工具，可在单次执行中验证模型 API 访问、向量数据库可达性、待处理的审批、内存计数、追踪后端连接以及集成健康状况。
已完成的追踪会经过自动化分析器处理，标记出执行时长、工具故障、重试次数和 token 效率问题，供人工审查。博文建议将有限的运维指标导出到 Prometheus，例如工具错误率和审批延迟直方图。
这里有一条明确的警示：把动态会话 ID 放进指标标签，会产生高基数时间序列，可能导致指标服务器崩溃。细粒度的会话上下文应严格保留在追踪或结构化日志中。正如博文所言：“追踪用于调试，指标用于告警。”
跨厂商的标准化路径
其他配套工具为跨生产环境评估追踪数据提供了结构化路径。OpenTelemetry 的生成式 AI 语义约定定义了模型操作、token 消耗和工具调用的标准化属性，在不同遥测后端之间建立一致的规范结构。
追踪记录执行历史，评估工具则验证输出质量。LangSmith 可将生产环境中的异常追踪转换为测试数据集，用于回归基准测试和质量监控。开源的 Arize Phoenix 把原生支持 OpenTelemetry 的追踪，与自托管的 LLM 评审器评估能力和提示词实验结合在一起。OpenTelemetry 项目在一个单独的代码库中维护这些规范，涵盖客户端、服务器和模型上下文协议的 span，以此支持一致的多厂商可观测性。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
