跳到主要内容

第 2.12.1 节：先设计日志、Tracing 和 Metrics 的观测边界

进入实现之前，先围绕“先设计日志、Tracing 和 Metrics 的观测边界”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出日志、Tracing 与 Metrics 的适用场景、不适用场景、前置条件和进入工程实现的判断标准。

本章要解决什么问题​

前面章节已经把企业客服知识库与工单 Agent（智能体） 工作台的主要能力串起来了：用户提问进入会话，系统用 RAG（检索增强生成） 查资料，用 Tool Calling（工具调用） 查订单、建工单、发起审批，再用状态图控制多步骤流程。

读图重点：Logs 回答“这一次发生了什么”，Trace 回答“卡在哪一段”，Metrics 回答“整体是否异常”，成本、告警和回放据此落地。

做到这里，系统已经可以演示。但演示能跑，不代表能上线。

真实上线后，最麻烦的问题通常不是“系统完全不可用”，而是这些说不清的问题：

  • 用户说 Agent 回答错了，但你不知道它用了哪段资料。
  • 客服说工单没有创建成功，但你不知道工具到底有没有被调用。
  • 主管说审批一直卡住，但你不知道卡在模型、工具、人工还是权限。
  • 老板说模型账单突然升高，但你不知道哪个租户、哪个用户、哪个流程烧掉了成本。
  • 运营说响应变慢，但你不知道是检索慢、模型慢、工具慢，还是被限流了。
  • 安全同事说有人尝试越权查询订单，但你不知道系统有没有拦住。
  • 客户问“你们这个系统一个月大概多少钱”，你只能凭感觉报价。

可观测性要解决的就是这些问题：让 Agent 上线后的行为、错误、成本、延迟、风险和业务结果都能被看见、解释和复盘。

本章通过日志、Trace 与指标体系，讲清工程设计：

  • 应该记录哪些 logs（日志）。
  • 如何用 Trace ID（追踪编号） 串起一次请求。
  • metrics（指标）和 tracing（调用链追踪）分别看什么。
  • 如何追踪 Token（文本计量单位）、模型成本和租户预算。
  • rate limit（限流）如何保护成本、服务稳定性和公平使用。
  • alert（告警）和 dashboard（看板）如何帮助团队运营系统。
  • replay（复盘）如何还原一次客服对话和 Agent 决策链路。

面试时，可观测性是很好的分水岭。很多候选人只会说“我接了模型 API（应用程序接口）”。更成熟的说法是：我知道 Agent 上线后会出现不可预测行为，所以我设计了日志、调用链、指标、成本账本、限流、告警、看板和复盘，让系统能被运营、能被排障、能被报价。

学习目标​

读完本章后，你应该能够：

  • 用人话解释 logs（日志）、tracing（调用链追踪）、metrics（指标）、cost tracking（成本追踪）、rate limit（限流）、alert（告警）、dashboard（看板）和 replay（复盘）的区别。
  • 为一次客服 Agent 请求设计 trace_id（追踪编号）和 span_id（片段编号）。
  • 说明一次请求从用户入口、检索、模型、工具、审批到回答的完整观测链路。
  • 设计字段契约，覆盖用户、租户、模型、Token（文本计量单位）、检索命中、工具调用、延迟、成本、限流、告警和错误码。
  • 判断应该记录完整内容、摘要、引用编号还是脱敏字段。
  • 设计按用户、租户、模型、工具和业务流程统计成本的方法。
  • 设计限流规则，防止单个用户、租户、工具或模型调用把系统拖垮。
  • 设计告警规则，发现检索无命中、工具失败、审批卡住、成本异常和安全事件。
  • 用 dashboard（看板）支撑客服主管、工程师、运营和销售的不同视角。
  • 面试时把可观测性讲成“企业 Agent 落地能力”，而不是只说“我会打日志”。

贯穿业务场景​

本章继续使用“企业客服知识库与工单 Agent 工作台”。

假设客户是一家电商或 SaaS（软件即服务）企业。客服 Agent 要处理这些任务：

  • 回答售后政策、发票、退款、物流和账号问题。
  • 检索企业知识库，引用最新资料。
  • 查询订单、物流和历史工单。
  • 创建投诉、售后、技术支持工单。
  • 对退款、发券、短信通知等高风险动作发起人工审批。
  • 帮客服主管复盘“为什么这次回答错了”。
  • 帮运营和销售估算“每个租户使用这个系统的成本”。

从可观测性角度看，一次看似普通的客服对话，背后可能包含很多节点。

节点可能发生的问题可观测性要回答
用户入口用户反复提交、恶意刷请求、会话丢失是哪个用户、哪个租户、哪个会话触发的？
RAG无命中、命中过期资料、命中无权限资料检索命中了什么，为什么没命中？
模型调用输出错误、延迟高、Token（文本计量单位）过多用了哪个模型，输入输出多少，花了多少钱？
工具调用查订单失败、建工单重复、工具超时调了哪个工具，参数摘要是什么，结果如何？
审批流程退款审批卡住、审批过期、审批人不对当前审批状态是什么，卡在哪个节点？
安全护栏越权查询、提示注入、敏感字段泄露系统拦截了吗，记录了什么安全事件？
最终回答用户不满意、答案无依据、转人工失败最终给用户看了什么，依据是什么？

可观测性不是工程师的内部装饰。它会直接影响客服项目能不能交付、能不能续费、能不能扩租户、能不能报价。

新手为什么会卡住​

很多新手做 Agent 项目时，会把可观测性做得很浅。

常见误解问题在哪里正确理解
只要打印错误日志就够了Agent 错误常常不是崩溃，而是检索错、工具错、成本高、审批卡住要同时记录日志、调用链、指标、成本、限流和业务状态。
只记录最终回答看不到模型为什么这么答要记录检索命中、模型调用、工具结果、护栏判断和引用来源。
日志越多越好可能泄露隐私、密钥、订单信息和内部策略要做脱敏、摘要、权限和保留周期。
trace_id（追踪编号）可有可无没有链路编号就无法串起一次请求每次用户请求必须有统一追踪编号，并传到检索、模型、工具和审批。
成本上线后再看账单一高就无法解释来源成本字段要从初始版本开始按用户和租户记录。
限流只是防攻击限流也保护预算、公平使用和模型稳定性要按用户、租户、工具、模型和高风险流程分层限流。
告警只看服务宕机Agent 质量问题不一定导致服务宕机要看检索无命中率、工具失败率、审批超时、成本异常和安全事件。
dashboard（看板）就是图表看板不按角色设计就没人用工程师、客服主管、运营、销售看的指标不同。

新手最大的卡点是：把可观测性当成“技术监控”，而不是“Agent 项目上线后的运营系统”。本章会把它放回客服工作台里讲。

继续学习​