[[Agent]] 上线后最容易出问题的地方,我会分成几类看。第一类是规划决策层,典型问题是 [[ReAct]] 死循环、目标漂移、工具选择错误。比如模型一直“思考-调用-再思考”,任务没完成但 token 和时间耗光。
第二类是工具执行层,这是影响最直接的。外部 API 超时、返回格式变化、权限过期、工具参数错误,都会让 Agent 后续步骤失败。更麻烦的是写操作,比如发券、退款、发消息,如果没有幂等和确认机制,可能造成真实业务损失。
第三类是上下文和记忆层。历史消息不断膨胀会让延迟和成本上升;摘要压缩如果删掉关键约束,模型会突然决策变差;长期记忆如果没有时效和权限过滤,还可能拿到过期或不该看的信息。
第四类是模型服务层,比如 LLM 首 token 延迟变高、队列堆积、限流、输出格式不稳定。Agent 是多次调用模型的系统,一个请求里可能调用好几轮,所以模型服务的小抖动会被放大。
监控体系我会分三层。基础设施层看 GPU 利用率、队列长度、模型调用延迟、错误率。Agent 运行时层看单任务迭代次数、工具调用次数、工具成功率、上下文 token 数、重试次数、循环中断次数、成本每任务。业务层看任务完成率、人工接管率、用户满意度、错误执行率和投诉率。
除了指标,还必须有 trace。每个任务生成 trace_id,把用户输入、状态变化、模型输出、tool call、tool result、耗时和最终答案串起来。没有 trace 的 Agent 很难排查,因为你只看到最后答案错了,却不知道是哪一步错。
日志要结构化,至少包括 session_id、turn_id、prompt 版本、模型版本、上下文 token、解析出的 action、工具参数摘要、工具结果状态、延迟拆解。异常时最好保存上下文快照,支持离线回放。
定位问题时,我会按链路拆。延迟高,就拆成模型推理慢、工具慢、串行步骤多,还是上下文太长。答案错,就看规划是否选错工具、工具结果是否正确、模型是否忠实使用 observation。成本高,就看循环次数、重试次数和上下文长度。定位后要用相同 trace 回放,确认问题能稳定复现,再改 prompt、工具、路由或状态机。
告警也要对应风险。比如单任务迭代超过阈值就熔断;工具失败率持续升高就切备用工具;上下文 token 接近窗口上限就压缩或拒绝继续;高危工具调用异常就触发人工审核。
我还会做混沌演练,主动注入工具超时、模型错误、返回格式变化、上下文膨胀,验证熔断、降级、回滚和人工接管是不是真的能工作。Agent 的可靠性不能只靠线上出事后再修。