一句话回答
日志负责记录发生了什么,监控负责发现哪里不正常,可追踪负责把整条任务链路串起来。真正上线的 Agent 不只是会执行,还要在出错时能发现、能定位、能追溯、能修复。
01 为什么 Agent 特别需要日志?
many steps
用户提出任务
AI 理解
调用工具 A
获得结果
AI 再次判断
调用工具 B
工具失败
重试
继续执行
步骤越多,只看最后一句“任务失败”就越难定位问题。
02 什么是日志?
work record
22:01用户提交订单查询
22:01AI 识别订单号 A10086
22:01调用订单查询工具
22:02查询成功
22:02调用物流工具
22:03物流接口超时
22:03第一次重试
22:04查询成功
22:04返回用户
03 日志应该记录什么?
fields
任务是谁发起的
什么时间开始
当前任务是什么
调用了哪个模型
调用了哪些工具
工具是否成功
错误发生在哪一步
重试了几次
最终结果是什么
04 日志不是为了“看起来专业”
useful logs
error / failed
低价值日志
只知道出错了,不知道哪个任务、哪个工具、什么参数、失败原因是什么。
任务 + 工具 + 原因
可排查日志
记录订单号、工具名、状态、失败原因和重试次数,问题能快速定位。
05 什么是监控?
system health
任务成功率系统是不是能完成任务?
API 失败率外部工具是不是稳定?
平均响应时间用户等得久不久?
Token 消耗成本有没有异常上涨?
工具失败次数哪个工具最容易出问题?
转人工比例AI 是否真的解决问题?
06 监控的价值是提前发现问题
spike
平时订单工具失败率 1%
今天失败率 35%
提醒订单接口可能异常
07 监控最重要的几个维度
four dimensions
稳定性
成功率、失败率、超时率。
速度
平均响应时间、首字时间、任务完成时间。
成本
Token 消耗、模型调用次数、每日成本。
业务结果
解决率、转人工比例、重复提问比例。
08 什么叫“可追踪”?
trace
用户请求
AI 判断
第一次创建工单
返回超时
Agent 误以为失败
再次调用工具
第二个工单创建
可追踪,就是能还原一次任务从开始到结束经历了什么。
09 为什么只看最终答案不够?
not enough
AI 判断错误
用户没有权限
订单不存在
退款接口失败
已退款但返回超时
系统触发风控
10 给每个任务一个唯一编号
trace id
TASK-20260813-000128
用户请求
模型调用
工具 A
工具 B
失败重试
最终结果
11 日志里要注意隐私
masking
密码
API Key
私钥
身份证号
银行卡信息
高敏感客户数据
日志要够用,但不要把日志变成新的数据泄露风险。
13 模型调用也要监控
model metrics
使用了哪个模型
输入 Token
输出 Token
响应耗时
是否触发重试
输出格式是否正确
14 什么时候应该触发告警?
alert rules
任务失败率 > 10%告警
订单 API 连续失败告警
平均响应时间 > 20 秒告警
Token 成本突然翻倍告警
高风险工具连续失败告警
15 一个完整的 Agent 观测链路
observability
用户发起任务
生成 Trace ID
记录模型调用
记录工具调用
记录每一步状态
统计耗时和成本
记录成功 / 失败
监控指标
发现异常
触发告警
16 Demo 和正式系统的差距
debug gap
谁执行的?
执行了什么?
用了哪个模型?
调用了什么工具?
花了多少钱?
用了多久?
在哪一步失败?
为什么失败?
是否发生重复执行?
17 日志、监控、追踪三者不要混
three roles
某个工具超时了
日志
记录一件事情发生了什么。
今天工具超时率升到 30%
监控
看整个系统现在是不是正常。
这个用户的任务为什么最终失败
追踪
把一次任务的所有步骤串起来。
本节练习
给订单查询 Agent 设计观测链路
从用户请求生成 Trace ID 开始,记录模型识别、订单工具、物流工具、失败重试、耗时成本、最终结果和告警条件。
Trace ID每次任务唯一编号是什么?
模型用了哪个模型,Token 花了多少?
工具调用了哪些工具,参数是什么?
状态每一步成功、失败还是重试?
告警什么指标异常时提醒?
隐私哪些字段必须脱敏?
本节小结
一个无法观察内部运行过程的 Agent,出了问题很难知道坏在哪里。
- 日志记录每一步发生了什么,解决“怎么查”。
- 监控观察整体是否正常,解决“哪里异常”。
- 追踪把一次任务的所有步骤串起来,解决“这次为什么失败”。
- 上线 Agent 不可能永远不出错,但必须做到能发现、能定位、能追溯、能修复。