北京
上下文窗口已经冲到百万token级别，AI还需要独立的记忆系统吗？这个问题最近在开发者社区里反复出现，争论双方都有不少支持者。与其跟着最新看到的帖子站队，不如把几方的核心论据摆出来，看看这场争论到底在争什么。
窗口已经大到什么程度了？
几年前，几千token的上下文就算慷慨。现在，100万token成了基线。Meta去年发布的Llama 4 Scout支持1000万token，一家名为Magic的创业公司做出了1亿token的模型（LTM-2-mini）。换算一下，这意味着大约1000万行代码，或者750本小说，可以塞进一次提示词里。到这个份上，确实要问一句：独立的记忆系统还能干什么？
第一派：窗口已经够用，记忆系统是多余的
Fabio Akita指出，从泄露的Claude Code源代码来看，Anthropic自己的编程代理压根没用向量数据库，只用文件系统和grep。按他的计算，一次20万token的查询，算上缓存成本大约0.63美元，长期来看比维护一套向量数据库管道更便宜。Meta也押了同样的赌注，宣传Llama 4 Scout能装下多年的聊天记录，而且“不需要向量存储”。
这个论点很有吸引力，成本优势确实是它最强的地方。但仔细想想，这一派回答的问题比现实要窄。“需不需要向量数据库”和“需不需要记忆”是两个问题。Akita的观点本质上是关于搜索复杂度的——用grep替代embedding——而不是关于状态是否需要在会话之间持续。Meta的宣传也巧妙地跳过了这样一个事实：一次1000万token的聊天会话终会结束，下一次会话从零开始。
第二派：记忆解决的是完全不同的问题
Mem0把上下文窗口比作RAM而不是存储：会话一结束，里面的东西全部消失。Redis说得更直接：代理失败不是因为单次调用空间不够，而是因为缺乏连续性——它们没法把一次会话中学到的东西带到下一次。窗口再大也解决不了这个问题。哪怕是一个1亿token的模型，你开一个新对话，它照样完全不记得你。
这里最可靠的证据是Chroma的“上下文腐烂”研究。他们测试了18个模型（包括GPT-4.1、Claude 4、Gemini 2.5、Qwen3），发现随着输入变长，性能会下降，而且远在触及模型实际上限之前就开始了。一条无关的干扰信息就能明显拉低准确率。在某些测试里，信息乱成一团的表现反而比组织有序的更好。这一点真正说服了我：塞进窗口和模型真正用好窗口，是两码事。卖更大窗口的人，有充分的动机模糊这条界线。
第三派：窗口还是太小
Factory.ai指出，目前100万到200万token的模型，已经比他们的企业级上下文要小了。对于处理整个代码库或长期运行的项目来说，这个容量依然捉襟见肘。这一派认为，记忆系统不是要不要的问题，而是窗口本身就不够用，必须靠外部记忆来补足。
三派的分歧到底在哪
仔细看这三派的争论，会发现他们其实在回答不同的问题。第一派回答的是“要不要向量数据库”，第二派回答的是“会话之间要不要连续性”，第三派回答的是“窗口容量够不够用”。这三个问题被混在一起讨论，才造成了看似对立的局面。
从实际应用的角度看，如果AI代理只是处理单次任务，窗口确实够用，记忆系统是多余的。但如果要让代理跨会话积累知识、持续学习，那记忆系统就是刚需，窗口再大也替代不了。Chroma的研究恰好证明了这一点：模型在长上下文中的实际利用率远低于理论容量，这给“窗口够用论”泼了一盆冷水。
这场争论短期内不会有定论。窗口还在变大，记忆方案也在进化。但有一点是明确的：把东西塞进窗口，和让模型真正用好这些东西，是两码事。厂商宣传的容量数字，和实际效果之间，还有不小的距离。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
