Agent 可观测性别只看最终答案真正难排查的是“它为什么这么做”同一个 Agent 任务昨天还能完成今天突然失败最终回答只有“查询失败请稍后重试。”根因可能是模型理解错了、工具选错了、参数错误甚至只是数据库超时。Agent 不能只看最终答案必须看完整执行过程。一、为什么普通日志不够传统后端大致是HTTP → Controller → Service → Database → ResponseAgent 却可能是用户问题 → LLM → Tool A → 结果 → LLM → Tool B → 失败/重试 → 最终回答只记录successfalse基本无法排障。一次 Agent 任务应该有完整的TraceTrace ├── LLM Call ├── Tool Call ├── Tool Result ├── LLM Call └── Final Answer简单理解Trace一次完整任务。Span其中一个步骤如 LLM、RAG、数据库、Tool。Eventretry、error 等具体事件。最小日志可以是{trace_id:abc123,tool:query_database,latency_ms:328,success:True}LLM 还应记录模型、Token、耗时和工具调用。二、Agent 应该监控哪些指标除了错误率、P95 等普通后端指标Agent 至少还要看Tool Success Rate Retry Rate Task Completion Rate Token Cost End-to-End Latency例如工具调用从 3 次变成 8 次通常意味着规划、参数校验或工具设计出了问题而真正重要的结果指标仍然是用户目标有没有完成。总耗时也不能只看 LLM总耗时 LLM 检索 工具 数据库 重试三、为什么只评最终答案还不够两个 Agent 都回答订单总数1250但过程可能完全不同A查询数据库 → 正确返回 → 1250 B查询失败 → 猜测 → 再搜索 → 碰巧得到 1250结果一样可靠性完全不同。所以 Agent Evaluation 可以拆成过程质量 → 结果质量 → 任务质量过程看工具选择、参数正确率、调用次数结果看答案正确率、引用准确率、结构化输出任务看用户目标是否真正完成。四、怎么做最小评测集先准备固定 Casecases[{q:查询本月销售额,tool:query_sales},{q:统计退款订单,tool:query_refund}]每次修改 Prompt、Model、Tool Schema、Memory 或 RAG 后重新运行比较任务完成率 工具选择准确率 平均工具调用次数 平均 Token P95 延迟这样才能知道改动到底有没有让 Agent 变好。五、可观测性最有价值的地方定位根因一次任务失败可以这样查Task Failed ↓ Trace ↓ 第 2 次 LLM Call 选错工具 ↓ 查看 Context ↓ 发现 RAG 返回无关文档 ↓ 检查 Retriever最后发现问题可能根本不在模型而在RAG / Tool Schema / Prompt / Memory / Database所以可观测性不是告诉你“失败了”而是帮助你找到为什么失败。六、常见坑日志太少只记录开始、结束、失败基本无法排障。日志太多完整保存 Prompt、工具结果和用户数据会增加成本和隐私风险应做脱敏、采样和分级。没有 Trace ID至少需要trace_id、run_id、tool_call_id否则并发任务很容易串日志。只评模型换模型可能提高回答质量却让工具调用次数暴涨。真正应该评估的是整个 Agent System。七、从零落地第一阶段先记录trace_id LLM Call Tool Call Token 延迟第二阶段增加 Trace、错误统计和日志检索。第三阶段建立 Evaluation Dataset、自动评测和回归测试。最后再做质量看板、成本分析和异常告警。不要一开始就做巨大平台先做到出问题时我能知道是哪一步出了问题。最后Agent 不是黑盒聊天机器人而是一条动态执行链最终答案 ≠ Agent 质量真正需要回答的是为什么选这个工具 为什么调用这么多次 为什么失败后没有恢复 为什么 Token 暴涨能回答这些问题Agent 才真正进入可工程化、可迭代的阶段。标签#Agent#Agent可观测性#LLMOps#Agent评测#大模型应用#后端开发#AI工程
