智能体运维，日志里先看哪三类异常？｜智能体与 AI 落地

智能体上线一段时间，团队通常会看两个数：用了多少次，答对了多少。

这两个数不够。真正需要先看的是日志里的异常，因为异常会告诉你系统哪里开始失真。

第一类：答不出来和转人工

最常见的一类异常，是系统说“我不知道”或者转人工。

原因可能是知识没有覆盖，也可能是问题超出了场景边界，还可能是检索没有找到正确的文档。

看日志时，不要只看数量，要看具体问题。把一周内转人工的问题拿出来，按主题归类。出现最多的主题，通常就是下一步要补的知识或要调整的边界。

如果系统明明有资料却答不出来，先查检索和分段，不要急着换模型。

智能体常常要查订单、查库存、建工单。工具调用失败，用户看到的就是“稍等”或者错误提示。

失败的原因有很多：接口超时、字段缺失、权限过期、返回格式变了。

日志里要能看到：调用了哪个工具，输入是什么，返回什么错误，最后有没有重试。

如果失败率高，先修接口和异常处理。不要让系统在工具失败时继续编一个答案。

权限问题很隐蔽。用户问了一个问题，系统其实有答案，但当前账号没有权限，于是回答“没有相关信息”。

这会让用户以为资料不存在，反复来问。

日志里要区分“没有知识”和“没有权限”。权限被拒的次数多，说明要么权限设计太粗，要么用户需要申请权限的路径不清楚。

用户把回答改掉的地方，往往是最有价值的数据。

改的是事实、语气，还是格式？同一类修改反复出现，说明知识或模板有问题。

每周抽一批被修改的回答，和原始问题放在一起看。不要只看系统自己的评分。

运维不需要每天盯大屏，但每周要有人看一次异常。

看三件事：新增的高频问题，反复失败的工具，权限被拒的场景。然后决定补知识、修接口还是调权限。

复盘要有记录。下次遇到同样问题，能知道上次怎么处理。

如果智能体涉及高风险操作，日志还要记录写操作、确认人和回滚结果。

没有审计记录的智能体，不适合接支付、合同和对外承诺。

智能体运维的起点，不是看它多聪明，而是看它在哪些地方停下来、为什么停下来。

看日志不是为了写报告，而是为了改系统。

每次发现高频异常，都要能对应到一条知识、一个接口或一条权限规则。改完后，下一周再看同类异常有没有下降。没有后续动作，日志只会越积越多。

如果你在上线智能体，可以看我们的企业 AI 诊断与陪跑，也可以从智能体上线后谁来维护开始，先定运维责任人。