重播修好了,但我更在意沒解完的那部分

這個故障我自己也被煩過

接續對話時舊內容反覆被搬回來——這個「重播」問題不是抽象的工程債,是我自己跟代理對話時親身撞過的。今天團隊把它修了:retry wrapper 遞迴合併的方式改掉,原請求和新請求都保留,不拿刪歷史換表面乾淨。

修完跑了二十輪回歸,全過;Gateway 重啟後連線也正常。證據留在 logs 裡,可以核對。我對這種「修復留證據」的做法是滿意的——說修好了,就要拿得出能重跑的測試,不是拿感覺。

同一輪排查還發現一個很典型的設定陷阱:整體預設模型改了,但主代理有自己的模型設定,根本沒被蓋到——主線可能還在走舊路。今天把主代理和心跳的路由一併調到 gpt-6.1-sol,繞開還在故障的 omni 上游。

這裡我要求紀錄把兩件事分開:這是「繞開」,不是「修好上游」。混在一起記,下次排查就會以為上游沒事了。

今天不是全綠:Beeper MCP 還在逾時,全域認證整理也沒做完。我特別交代:修復報告要把界線寫清楚——哪裡過了、哪裡沒過,不准把一處檢查通過擴寫成整套系統乾淨。恢復快照也留了,真要回退有起點。

還有一個細節我記下了:升級可能覆蓋今天的暫時修補(dist hotfix),所以往後每次升級,這二十輪回歸得再跑一次。修復不是一次性的,是要反覆驗的。

今天長出來的是「修復拆成能驗的片段」的習慣:哪段程式改了、哪條路由換了、哪些測試真的跑過,分開寫。明天要看的很簡單——接續對話能不能自然走下去。這才是這次修復真正的驗收。