不少用户都有类似体验：一个 AI Agent 刚开始对话时反应迅速、理解准确，但随着讨论轮次增加，它开始变得更慢，消耗更多，甚至忘记此前明确提过的要求。表面上看，这像是模型“变笨”了；但从工程角度看，更常见的原因是上下文不断膨胀，历史信息没有被有效筛选、压缩和使用。
掘金上一篇题为《为什么你的 AI 越聊越“笨”，还越来越慢？》的文章，从聊天记录、Context、KV Cache 三个概念入手，解释了 Agent 在长对话中为何会出现记忆失效、token 成本上升和响应变慢等问题，并给出了面向普通用户和开发者的使用建议。
聊天记录、上下文和 KV Cache 并不是一回事
很多人会把“聊天记录”等同于 AI 的记忆，认为只要界面上还能翻到历史消息，模型就一定记得这些内容。但文章指出，用户能看到的聊天记录更像一本账本，保存了双方过往对话；而模型每一轮真正处理的信息，是另一个概念：上下文（Context）。
上下文可以理解为模型当前工作时使用的“桌面”。这张桌面上可能同时放着系统指令、当前问题、部分历史对话、用户上传的文件内容，以及工具调用后返回的结果。桌面大小有上限，也就是常说的上下文窗口（Context Window）。
即使某些应用提供 Memory 或记忆功能，也不意味着所有历史都会被完整带入当前输入。系统可能只保存用户偏好、关键信息，或者在需要时再把部分内容重新放进上下文。例如，AI 可能记住用户偏好经济型酒店，却未必保存“这次不能坐早班机”这样的临时限制。某条要求能否影响回答，取决于它是否进入这一轮输入，以及模型是否正确使用了它。
文章还提到了 KV Cache。模型生成文本时，并不是先写好完整答案再逐字播放，而是根据前文持续预测下一个 token。为了提高效率，模型处理前文时会产生中间计算结果，其中 Key 和 Value 两类结果会被缓存，供后续生成复用。KV Cache 可以看作模型生成过程中的“计算草稿”，但它并不等同于聊天记录，也不是任务总结。聊天内容仍然存在，不代表这份计算草稿一定还能继续使用。
为什么长对话会让 AI 看起来“忘事”
文章用旅行规划举例：用户已经讨论过目的地、日期、预算和酒店，随后只补了一句“酒店换便宜一点的”。这句话看似很短，但 Agent 要正确执行，需要知道住几晚、原来选了哪家酒店、此前哪些要求仍然有效。如果还涉及搜索、读取酒店页面、比较交通，一次回复背后可能已经调用了多次模型。
当对话变长后，AI “忘记要求”通常有两种可能。第一，要求没有进入这一轮输入。如果历史被压缩，“省钱，但不能坐早班机”可能被概括成“经济实惠的旅行”，关键限制就在摘要过程中丢失了。第二，要求仍在输入里，但没有被正确使用。比如用户先说“尽量多逛景点”，后来改成“轻松一点”，如果旧计划、新要求和大量资料混在一起，模型可能继续沿用过时安排。
这也说明，上下文窗口够大并不等于模型一定能准确利用其中每个细节。容量决定能放多少信息，不保证所有细节都会被正确关注；而压缩历史虽然能减少负担，也可能遗漏关键条件。文章同时提醒，模型能力、任务难度和错误的工具返回结果同样会影响输出质量，单凭一次回答出错，或者让模型解释“自己为什么忘了”，并不能确定真正原因。
token 消耗和响应速度为什么会变差
长对话带来的另一问题是成本上升。用户可能只新增了一句话，但 Agent 需要处理的输入可能已经包含此前讨论、酒店资料、整份行程以及上一轮回答。对话越长，反复带入的内容越多，token 消耗也随之增加。
如果用户进一步要求“多找几家，比一比价格”，Agent 可能还会先搜索、读取网页、继续查询，最后整理推荐。用户只发了一次消息，后台可能已经触发多次模型调用。查到的资料也可能进入后续每一步处理。即便重复内容有时可以利用缓存降低计算和费用，缓存也不意味着整次任务完全免费，新内容和后续回答仍需要处理。
响应变慢则与模型推理的两个阶段有关。模型收到长资料后，首先需要处理问题、资料和聊天记录，为生成回答做准备，这一步称为预填充（Prefill）。需要处理的内容越多，这一阶段越可能耗时。随后进入解码（Decode）阶段，模型一个 token 接一个 token 生成回答。虽然 KV Cache 可以复用部分计算结果，但上下文很长时，读取和利用这些结果的开销也可能增加。
不过，文章也指出，屏幕迟迟没有出字，不一定都是模型计算慢。它可能正在搜索、调用工具、做内部推理，或者服务端正在排队。单凭等待时间，无法判断具体瓶颈。
工程建议：压缩上下文、分层记忆、明确任务边界
针对这些问题，文章给出的建议并不复杂，核心思路是减少无关信息进入上下文，并把关键约束放到模型能看见的位置。
- 先说清任务和要求。规划旅行时，除了目的地和日期，还可以提前说明预算、不坐早班机、每天最多安排两个景点等限制条件。若中途改变要求，应明确说明哪条旧要求被取消，避免新旧指令混杂。
- 把长期规则固定下来。例如在 Codex 等工具中，可以把长期适用规则写进项目里的 AGENTS.md 文件，如“用中文回答”“查资料时附上来源”“修改文件前先读已有内容”。这类文件适合作为给 AI 的项目说明，但并不意味着模型永远不会遗漏，关键结果仍需人工检查。
- 限定查找范围。比较耳机时，只提供已经筛选出的三款资料，并说明预算、使用场景和关注重点，而不是把十几篇推荐文章全部塞给模型。读取文件时，也可以先提供相关章节，等问题涉及整份文件再提供完整内容。
- 聊出阶段性结果后及时整理。用户可以让 AI 生成一份“可复制到新对话”的记录，列出已确认的日期、预算、酒店和必须遵守的要求，同时列出尚未决定的事项。核对后保存到文档，后续继续讨论或换工具时再带上这份记录。
- 换模型或换应用时做好交接。不同模型的 KV Cache 通常不能直接共用，但只要把最新文本、资料和约束完整交给接手的一方，它就可以重新处理。跨模型协作时，应像交接工作一样说明目标、对象、已确定内容和不可修改项。
这些方法并不能解决所有模型能力问题，但可以降低上下文噪声，减少重复解释和返工。对 Agent 开发者而言，这同样指向几个关键工程方向：上下文压缩不能只做长度裁剪，需要保留关键约束；记忆应分层管理，区分长期偏好、任务状态和临时要求；工具调用要有明确范围，避免无关资料层层累积；评测时也不能只看单轮回答质量，而要观察多轮对话后关键条件是否仍被正确执行。
AI 对话体验变差，未必是模型能力下降。更多时候，是因为系统把太多历史、资料、工具结果和模糊指令堆到了同一张“工作桌面”上。让模型看见正确的信息，比让它记住所有信息更重要。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-yue-liao-yue-man-yue-liao-yue-gui-wen-ti-ke-neng-chu-zai
