日前，DeepSeek最新版V3.1被發(fā)現(xiàn)存在嚴(yán)重Bug，會(huì)在代碼生成中隨機(jī)插入“極/極/extreme”等token，導(dǎo)致代碼無(wú)法正常編譯。這一問題不僅出現(xiàn)在第三方量化部署中，官方全精度版本也受影響，給依賴自動(dòng)化編碼的團(tuán)隊(duì)帶來極大困擾。此前DeepSeek曾出現(xiàn)過寫作任務(wù)語(yǔ)言混雜、代碼任務(wù)過擬合等問題，但此次“極”字Bug更為嚴(yán)重，直接導(dǎo)致系統(tǒng)崩潰或代理流程卡死。

開源社區(qū)用戶復(fù)現(xiàn)了多種場(chǎng)景，發(fā)現(xiàn)即便在保守解碼參數(shù)下，該問題依然無(wú)法避免。初步推測(cè)可能是解碼概率分布偏移所致，模型在機(jī)械地基于概率拼湊文本，而非真正理解文本含義，導(dǎo)致高頻token錯(cuò)誤插入標(biāo)識(shí)符中。類似穩(wěn)定性問題在AI領(lǐng)域并非個(gè)例，Gemini也曾出現(xiàn)過代碼場(chǎng)景下的“自我否定無(wú)限循環(huán)”Bug，最終被定性為安全層、對(duì)齊層、解碼層交互問題。

大模型的穩(wěn)定性一直是行業(yè)痛點(diǎn)。今年年初，OpenAI社區(qū)就曾大量反饋記憶體系異常導(dǎo)致用戶歷史上下文丟失。Gemini的人像生成功能也曾因“多樣化”需求，將歷史人物生成為風(fēng)格不符的樣貌，最終不得不臨時(shí)下線。此外，模型提供商常做的“熱修”也可能引發(fā)問題，如換系統(tǒng)提示、微調(diào)溫度、更新tokenizer等，這些看似無(wú)害的調(diào)整可能打破原本的平衡，導(dǎo)致代理鏈在函數(shù)簽名、JSON嚴(yán)格性、工具返回格式等細(xì)節(jié)處崩潰。

越來越多的Agent與工具鏈結(jié)合，其脆弱性也逐漸暴露。多智能體系統(tǒng)往往在“工具調(diào)用—狀態(tài)清理—重試策略”鏈條中出現(xiàn)問題，如超時(shí)無(wú)兜底、失敗后無(wú)法還原上下文等。DeepSeek和Gemini的案例提醒我們，AI從“能干活”到“能托付”，最關(guān)鍵的并非僅僅是模型層的SOTA，而是產(chǎn)品層面工程的穩(wěn)定性，即那種即使犯錯(cuò)也能被預(yù)測(cè)和控制的“確定性”。