不知道你有没有这种体验刚开始跟大模型聊需求那叫一个爽代码写得飞起指哪打哪。聊着聊着大概二三十轮之后味道就变了。它开始犹豫老反问你「确定要这样吗」之前说好的事也忘了。再到五六十轮一个小功能给你绕来绕去动不动跑偏。一百轮左右token 明明没撞顶它的行为已经开始飘了。你说它笨了吧好像也不是但就是不得劲。更烦的是越往后它想得越久吐字越慢。刚开始 3 秒出结果的东西聊久了能等十几二十秒心流全断。我踩了一圈坑之后发现这事的根儿其实特简单——问题就出在多轮会话本身。一、多轮会话的加载机制本身就是个死穴现在几乎所有大模型的聊天接口都是全量加载历史记录的。什么意思你每发一句话它不会只带着你这句话去思考而是把你俩从第一轮开始说的每一句话、每一次工具调用、每一个报错信息原封不动地重新打包全部塞进去。不是选择性加载没有注意力预算没有优先级。你给多少 token它看多少 token。这就导致一个什么问题你聊得越久上下文越长。上下文越长里面攒的垃圾就越多。写错的代码、被否掉的方案、同一个文件反复读了好几次的旧内容、一堆「继续」「好的」「再改改」全堆在里面。模型根本分不清哪些是已经作废的、哪些是当前有效的它没这个能力。它只能一视同仁。结果就是你上下文里真正有用的东西可能就占一小部分剩下全是噪声。它只能在噪声里扒拉那点有用的不跑偏才怪。二、token 是省不下来的缓存再牛也白搭有人会说不是有 KV-cache 吗命中缓存的话 token 不是能省吗这里面有个很容易搞混的点。缓存省的是计算不是输入量。命中缓存意味着之前算过的 token 不用重新算一遍了这点确实能加快首 token 的响应速度。但是你该传多少 token 还是得传多少。你开了 1M 的上下文窗口聊爽了就往里填填到 900K 的时候缓存命中率再高它也是实打实的 900K token 要处理。而且每生成一个新 token它都得把整个上下文的缓存全过一遍。900K 的时候吐一个字要扫 900K 的缓存100K 的时候只扫 100K。这速度能一样吗所以哪怕你缓存优化到极致token 量上去之后吐字速度必然断崖式下跌。短对话 3 秒出结果的东西长对话等十几二十秒甚至半分钟一点不奇怪。你是来做开发的需要高频交互。等这么久心流早断了。三、越聊越畏手畏脚小事都反复思考这个是最让人抓狂的。刚开始聊的时候模型很果断说改就改该重构就重构。聊到后面呢让它改个变量名它都要先跟你确认三遍让它动个小逻辑它能给你列出五种方案让你选就是不自己动手。为什么会这样因为上下文里躺着太多相互矛盾的东西了。之前试错的路径、被否决的替代方案、半途放弃的重构方向全在上下文里。模型看到这些它就会觉得「这些是不是也该考虑一下」之前犯过的错会影响现在的判断之前试探性提过的方案会被重新当成选项。它看得越长就越容易选那种最安全、最绕远路的策略。说白了你之前的烂摊子全成了它现在的心理包袱。这不是模型变笨了是信噪比跌穿了。噪声太多信号太少模型已经没法高效做决策了只能在那反复磨叽。四、那怎么办说白了别跟一个会话死磕。聊到一定轮数果断切新会话。把中间的关键结论整理一下新会话里直接用别把几十轮的对话历史全带过去。长多轮会话不一定是最好的很多时候反而是体验最差的方案。你既等得久又得到更差的结果图啥呢1M 上下文窗口的真正的价值是让你能一次性处理超大文件、跑复杂单轮任务时不爆窗口而不是让你一个会话死撑两百轮。多轮会话的全量加载机制注定它会越聊越慢、越聊越笨。别迷信大窗口短会话才是王道。
