3 篇博文 含有标签「agent-observability」

一个 Agent 运行了。计划步骤（plan-step）崩溃了。工具调用（tool-call）步骤在经历了两次 500 错误重试后，在第四次尝试时成功了。用户得到了他们的答案。

那算是多少个事件？问产品，这是一个事件 —— 用户得到了有效结果，因此转化漏斗统计了一次转化。问 SRE，那是三个失败加上一个成功，底层步骤的错误率是 75%。问财务，那是四次计费推理，两次重试的工具调用，以及大约四倍于产品部门预测的单位成本。每个团队的仪表盘都是正确的。但它们也是不可调和的，一旦有人试图调和它们 —— 通常是在事故回顾期间 —— 他们会发现团队已经基于三个相互矛盾的可信度图景运行了数月之久。

用户报告 Agent 给出了错误答案。你打开 Trace。模型的推理过程看起来没问题。工具调用全部返回 200 OK。Harness 日志显示没有重试、没有截断、没有异常。然而，答案就是错的。于是你花了接下来的两个小时，将三个具有不同格式、不同时钟的独立日志流缝合在一起，最终发现某个工具针对特定的查询形状静默返回了 {"result": null}，模型将这个 null 合理化为一个听起来合乎逻辑的事实，而 Harness 则愉快地将这个幻觉转发给了用户。这三个层级中的任何一个都没有单独记录任何警报。故障发生在连接处。

这是生产级 Agent 系统中最主要的故障模式，而大多数团队都在使用单层工具进行调试。模型团队归咎于工具。工具团队归咎于模型。平台团队归咎于 Harness。每个人都部分正确，因为 Agent 故障几乎从来不是单一组件的 Bug —— 它是三个组件之间的失配，而每个组件都在不同的“步骤”心理模型上运行。在你的 Trace 基础设施反映这一现实之前，你将不断为披着不同外衣的同类事故买单。

你的 Datadog 仪表板显示零错误。延迟正常。所有服务都返回 HTTP 200。与此同时，你的 AI agent 刚刚在错误的时区预订了一个会议，幻觉了一个客户的订单历史，并为此烧掉了 4 美元的 token。

这正是让 agent 可观测性变得异常困难的原因：你现有的指标几乎无法告诉你 agent 是否真的在正常工作。

传统的分布式追踪建立在关于软件如何失效的一系列假设之上。LLM agent 违反了所有这些假设，而“我的基础设施是健康的”与“我的 agent 做出了正确的事情”之间的差距，正是大多数调试痛苦的根源。