结论先放这儿：线上智能体半夜报错，我没急着翻日志，先把那一坨堆栈丢给大模型让它先给个诊断，省了我至少四十分钟。后来干脆搭了个小助手专门干这活，零代码，拖拖配配就成了。下面是经过。

那天凌晨一点多，告警群弹消息。我们一个跑了三个月的对话服务，QPS 不高，平时挺稳，突然开始 502。我爬起来连上跳板机，docker logs 拉出来一看，好家伙，Python 的 traceback 叠了七八层，最底下还套着一个 asyncio 的 CancelledError，中间夹着一段 httpx.ReadTimeout。

我盯着看了两分钟，眼睛是花的。

平时这种我会一行行往上捋，找哪个调用栈是真凶。但那天实在困，我就把整段日志复制下来，扔给手边开着的大模型，前面加了句话：

下面是一段线上 Python 服务的报错日志，
帮我判断最可能的根因，按可能性排序，
每条给一个最小验证动作。

说实话我当时没抱太大期望，就当个橡皮鸭。结果它回得挺具体：第一可能是下游某个 HTTP 接口超时引发连锁取消，建议我去查那个 httpx client 的 timeout 配置和目标地址的响应延迟；第二才是协程被外部取消。还顺手指出我那段 ReadTimeout 的目标域名，是我们一个第三方天气 API——对，这服务里有个挺无厘头的功能，用户问天气它去调和风天气，跟主业务八竿子打不着，当初产品硬塞的。

我去 ping 了一下那个域名，平均延迟从平时的 80ms 飙到 3 秒多。根因找着了。对方在做迁移。

那一刻我有点恍惚。倒不是模型多神——它给的第二第三条其实有点凑数，根因排第一也有运气成分。但它把我从"读一坨乱码"里捞出来，直接给了我一个能验证的方向，这个体感很好。

后来我就想，这事能不能固化下来。总不能每次出错我都手动复制粘贴、手动写那段提示词吧。我们运维同学也不都会写提示词。

于是我找了个零代码就能配智能体的工具，搭了个内部用的"日志诊断小助手"。整个过程比我想象的省事，没写一行后端代码：

• 拖一个对话节点进去，作为入口；

• 挂上一个现成的大模型，负责读日志、出诊断；

• 把我们的报错码对照表、几篇历史故障复盘传进去做知识库（就是那个 RAG），让它回答时能引用我们自己踩过的坑；

• 提示词里钉死格式：根因排序 + 每条配验证命令 + 引用到的历史 case 编号；

• 最后发布成一个 API。

配完我对着它贴了条上次那段 502 日志测了下，它真就把和风天气那条又拎出来了，还附了我们复盘文档里同类问题的处理记录。那一下我承认是有点小得意的。

接进告警流程之后，现在告警触发，先过这个小助手跑一遍初诊，结论直接发到群里。我半夜被叫起来的概率低了不少。

当然不是没毛病。第一版我提示词写得太干，它回得像教科书，废话多，我删删改改试了五六轮才顺。响应也不算快，知识库一大，吐结果得等个十几秒。而且说白了，它只干"初诊"这种杂活，真正下判断、改代码还得人来——它给的方向偶尔也跑偏，不能照单全收。它更像个帮你把日志读顺、把可能性列出来的实习生，不是医生。

但杂活也是活。一个不用编程、自己拖几个节点配个提示词就能跑起来、还能喂自家文档的小助手，对我这种懒得重复造轮子的人来说，够用了。

（模型这块我直接调的讯飞星辰MaaS，现成的大模型 API，没自己部署算力，省心。）

你们处理线上报错，是硬刚日志，还是也开始让大模型先帮你读一遍了？评论区聊聊，特别是有没有谁也踩过第三方依赖偷偷迁移这种坑。