1、实时生成的聊天代理模型，如果线上出问题了，怎么定位这种问题一般先按链路拆。如果是实时生成类聊天代理，通常一条请求会经过网关、会话层、Prompt 拼装、模型推理、工具调用、结果后处理和流式返回几个阶段。线上出问题时，先判断是全量故障还是部分故障，是所有请求都失败，还是只有某一类请求延迟高、返回空、内容异常。定位时先看监控和日志。监控上看 QPS、平均延迟、P95/P99、错误率、超时率、GPU 利用率、显存占用、容器重启次数。日志上重点看 request_id，把一次请求链路串起来，看是卡在 Prompt 构造、模型推理、下游工具调用，还是 SSE/流式返回阶段。如果是模型输出异常，要回看...

😅😅😅😅

只招目前在公司所在地的吗？

"线上CPU使用率突破85%，请立即处理。" 手机震动的那一刻，我从床上弹了起来。 这是我负责的模块上线后的第三天，也是我第一次在凌晨收到生产环境的告警。 我打开电脑，手指在键盘上有点抖。 监控大盘上，那条红色的曲线像心电图一样跳动着。 我深吸一口气，开始排查： 先看日志——发现某个接口的调用量突然暴增。 再看链路追踪——发现是一个查询语句在循环执行。 最后定位到代码——我上周优化的那个缓存逻辑，在某个边界条件下失效了。 "找到了。"我在群里发了条消息，然后开始写hotfix。 十分钟后，代码提交。 二十分钟后，灰度验证通过。 三十分钟后，全量发布。 凌...