可观测性

用一个下午就能搭出一个像样的 Agent demo。接个大模型、写几个工具、调通 ReAct 循环,跑十条 case,全过。截图发群里,大家鼓掌。 两周后,一个客户在工单里贴出对话记录:你的 Agent 把退款金额算成了原价的三倍,还信誓旦旦地说"已为您处理"。你翻监控面板——CPU 正常、接口 P99 40ms、错误率 0.02%,一片绿。 这就是 Agent 工程里最反直觉的地方:搭出来是最简单的一步,知道它到底好不好,才是真正的工程。传统软件你写完测试、跑通 CI,基本就放心了;Agent 不行——它每次的输出都不一样,它"出错"的方式根本不会触发任何异常。这篇讲讲上线之后那部分:看什么指标、怎么评、怎么防回归。 为什么你那套监控不管用 先说清楚传统监控为什么在这里失灵。 传统软件的故障是二值的:要么 200,要么 500;要么返回了,要么超时了。你的告警系统盯着这些信号,出事就响。Agent 的故障是语义的:HTTP 200,JSON 合法,字段齐全,延迟正常——内容是错的。Agent 自信地编了一个不存在的退货政策,调了正确的工具但传错了参数,绕了七步才完成一件三步能干完的事。这些在传统监控眼里全是"成功请求"。 更麻烦的是 Agent 是非确定性的。同样一句"帮我查下上个月的账单",今天它走两步给出答案,明天可能走五步还问你要确认。你没法用"输入 X 必然输出 Y"来断言。所以 Agent 的评估,本质上是在做概率系统的质量管理——你管的不是单次对错,是一个分布。 还有一层:Agent 是多步的。一次任务里,规划器把目标拆成子步骤,工具选择器挑了几个工具,检索器拉了上下文,模型可能还重试了两次,最后才有一个回答。出了问题,你得知道是哪一步坏的。只盯着最终输出,等于只看考试总分不看错题——你知道它考砸了,但不知道为什么。 flowchart TD A[用户请求] --> B[规划拆解子任务] B --> C[工具选择] C --> D[工具调用] D --> E{结果够了吗} E -->|不够| B E -->|够了| F[生成回答] F --> G[返回用户] style B fill:#fde7c2,stroke:#e8b23c style C fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色那三块——规划、选工具、调工具——是 Agent 区别于"一次 LLM 调用"的地方,也是大多数故障的发生地。你的可观测性必须能看进这三块,而不只是看进出。 ...