(资料图)

日前，DeepSeek最新版V3.1被发现存在严重Bug，会在代码生成中随机插入“极/極/extreme”等token，导致代码无法正常编译。这一问题不仅出现在第三方量化部署中，官方全精度版本也受影响，给依赖自动化编码的团队带来极大困扰。此前DeepSeek曾出现过写作任务语言混杂、代码任务过拟合等问题，但此次“极”字Bug更为严重，直接导致系统崩溃或代理流程卡死。

开源社区用户复现了多种场景，发现即便在保守解码参数下，该问题依然无法避免。初步推测可能是解码概率分布偏移所致，模型在机械地基于概率拼凑文本，而非真正理解文本含义，导致高频token错误插入标识符中。类似稳定性问题在AI领域并非个例，Gemini也曾出现过代码场景下的“自我否定无限循环”Bug，最终被定性为安全层、对齐层、解码层交互问题。

大模型的稳定性一直是行业痛点。今年年初，OpenAI社区就曾大量反馈记忆体系异常导致用户历史上下文丢失。Gemini的人像生成功能也曾因“多样化”需求，将历史人物生成为风格不符的样貌，最终不得不临时下线。此外，模型提供商常做的“热修”也可能引发问题，如换系统提示、微调温度、更新tokenizer等，这些看似无害的调整可能打破原本的平衡，导致代理链在函数签名、JSON严格性、工具返回格式等细节处崩溃。

越来越多的Agent与工具链结合，其脆弱性也逐渐暴露。多智能体系统往往在“工具调用—状态清理—重试策略”链条中出现问题，如超时无兜底、失败后无法还原上下文等。DeepSeek和Gemini的案例提醒我们，AI从“能干活”到“能托付”，最关键的并非仅仅是模型层的SOTA，而是产品层面工程的稳定性，即那种即使犯错也能被预测和控制的“确定性”。